I'm trying to flash the stock splash image back onto my eris before I set it back to stock to sell it. Can it even be done via something like root explorer so I can do it right through my phone?
Hint: I mean splash image, not animation. ( I want to go back to the 3 skateboarding androids)
I suppose you merely reverse this process:
http://forum.xda-developers.com/showthread.php?p=6012336#post6012336
Because it uses fastboot, you obviously need the S-OFF bootloader. So, if you are trying to get rid of a custom splash image and the S-OFF bootloader, you would want to get rid of the splash image first.
Thanks a ton. ADB was being a apin in the ass but I finally got it to push the image. Now I just need to get back to the stock rom and I'm done.
CGriffiths86 said:
Thanks a ton. ADB was being a apin in the ass but I finally got it to push the image. Now I just need to get back to the stock rom and I'm done.
Click to expand...
Click to collapse
I wish I understood this a little better. (This is a bit of a tangent, I'm hoping someone will jump in here).
I have never flashed anything to "splash1" (= sp1) on my Eris - so I always get "3 skateboarding Androids" no matter what I (cold-)boot
What I have done, though, is dumped the "splash1" image two different ways:
(1)
Code:
fastboot oem savepart2sd sp1 -n sp1.img -a
(only works with S-OFF bootloader)
and
(2)
using a customized version of Amon_RA which creates all 12 Eris Partitions (hboot, misc3, mfg, sp1, misc2, mfg2, recovery, boot, system, cache, userdata, misc, radio)
Code:
dump_image sp1 /sdcard/sp1-dump.img
In both the above cases - using two independent methods, the file is 768 KB - the full partition size...
...and it is featureless - entirely filled with 0xFFs:
Code:
$ hexdump -C sp1.img
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000
Sort of strange; I'm not exactly sure what is going on. It might be that the "3 skating droids" image is actually stored inside the bootloader, and is used as a default if the "splash1" partition is erased, or contains garbage that the bootloader does not recognize as a rgb565 image. But it would have to be pretty small if that were the case: all bootloaders from HTC that we are aware of were only 512 KB in size.
If that is not the case, then that means some tomfoolery memory protection scheme was taking place in both the bootloader and the Amon_RA kernel (which is the Leak-V1 kernel, BTW). I don't know why anybody would do that for a splash image, though.
I suppose this could be tested out by writing a 768 KB file (or possibly even a very small file) of all 0xFF bytes and using the fastboot method of flashing "splash1" to see if you get the "3 skating droids".
That would prove or disprove the theory that the default image is actually stored in the bootloader. (Hint, Hint.)
bftb0
DE
bftb0 said:
I wish I understood this a little better. (This is a bit of a tangent, I'm hoping someone will jump in here).
I have never flashed anything to "splash1" (= sp1) on my Eris - so I always get "3 skateboarding Androids" no matter what I (cold-)boot
What I have done, though, is dumped the "splash1" image two different ways:
(1)
Code:
fastboot oem savepart2sd sp1 -n sp1.img -a
(only works with S-OFF bootloader)
and
(2)
using a customized version of Amon_RA which creates all 12 Eris Partitions (hboot, misc3, mfg, sp1, misc2, mfg2, recovery, boot, system, cache, userdata, misc, radio)
Code:
dump_image sp1 /sdcard/sp1-dump.img
In both the above cases - using two independent methods, the file is 768 KB - the full partition size...
...and it is featureless - entirely filled with 0xFFs:
Code:
$ hexdump -C sp1.img
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000
Sort of strange; I'm not exactly sure what is going on. It might be that the "3 skating droids" image is actually stored inside the bootloader, and is used as a default if the "splash1" partition is erased, or contains garbage that the bootloader does not recognize as a rgb565 image. But it would have to be pretty small if that were the case: all bootloaders from HTC that we are aware of were only 512 KB in size.
If that is not the case, then that means some tomfoolery memory protection scheme was taking place in both the bootloader and the Amon_RA kernel (which is the Leak-V1 kernel, BTW). I don't know why anybody would do that for a splash image, though.
I suppose this could be tested out by writing a 768 KB file (or possibly even a very small file) of all 0xFF bytes and using the fastboot method of flashing "splash1" to see if you get the "3 skating droids".
That would prove or disprove the theory that the default image is actually stored in the bootloader. (Hint, Hint.)
bftb0
Click to expand...
Click to collapse
I have an rgb565 converter that pushes a new splash. U can use any pic u choose, use it on ur computer, works beautifully....
Anyone interested in it?
Works flawless
Sent from my Eris using XDA App
Related
I'm running low on options for what is wrong with this kindle fire, so maybe someone can point out something I am missing. My friend flashed google apps on it after they rooted and somehow something was botched and I've been playing doctor to it remotely over VNC and running commands on adb. Anyways, it's stuck at the splash screen and not booting and this is everything I've tried and all the information I've gathered:
1) reflashed the last updated boot.img from amazon in fastboot
2) reflashed the recovery.img in fastboot
3) verified the md5sum and permissions on every file & directory in /system (all check out okay).
4) Verified there are no files missing or added to anywhere in /system
5) cannot get it to rerun the update after pushing the update to /sdcard/kindleupdates (it ignores it despite it being there, either because of the condition of the tablet currently or the fact it's already updated).
After doing the above, the state of the device doesn't change a bit. Same errors, same slash screen.
Only idea I might have to what is wrong (but I have no idea how it would have happened) is the boot image (mmcblk0) is corrupted somehow (not to be confused with boot.img which has the kernel and ramdisk [mmcblk0p2]). If it is that, then flashing u-boot.bin might solve it, but I'm not sure how to do that exactly and would want to be sure since it could really screw things up.
Issues:
1) Stuck at the load splash screen
2) su will not work (says segmentation fault, etc), however running the temp root exploit manually will give back root for things I need and allow me to mount/unmount, etc.
3) lots of errors in log cat see the link (started at boot and ran a min or so): http://pastebin.com/LcXU3cxz
root method was zergRush : http://rootkindlefire.com/kindle-fire-root/how-to-root-kindle-fire/
partition sizes (from running cat /proc/partitions ):
179 0 7553032 mmcblk0
179 1 128 mmcblk0p1
179 2 256 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 196608 mmcblk0p4
179 5 16384 mmcblk0p5
179 6 65536 mmcblk0p6
179 7 10240 mmcblk0p7
179 8 5120 mmcblk0p8
179 9 524288 mmcblk0p9
179 10 1164288 mmcblk0p10
179 11 262144 mmcblk0p11
179 12 5254144 mmcblk0p12
Click to expand...
Click to collapse
If anyone can shed any light on what might be wrong or what else can be done, let me know.
Some problems I see.
I'm not as much an android expert as a linux one, but I went over your paste bin and here's a few of the lines that were of concern.
298: E/AndroidRuntime( 1397): *** FATAL EXCEPTION IN SYSTEM PROCESS: ConnectivityThread
Fatal exceptions are never good. After that, until line 334, you are getting error after error.
550 E/System ( 1443): Failure starting core service
568 E/SystemServer( 1443): Failure starting Input Manager Service
580 E/AndroidRuntime( 1443): *** FATAL EXCEPTION IN SYSTEM PROCESS: ConnectivityThread same error again as the first.
It looks like something is crashing dalvik, and right after that all loaded apks die.... I don't have a kindle yet, that's why I'm surfing these forums so I'm not sure if you can with the recovery. Is it possible to wipe the dalvik cache?
If you have fastboot setup run fastboot -w .. it takes a long time.. I guess you could cancel it halfway safely. It'll be enough to trigger the kindle recovery on reboot which will wipe your dalvik cache.
Actually if you can get root (without the broken su) try deleting /data/dalvik-cache then reboot
transfuntioner said:
If you have fastboot setup run fastboot -w .. it takes a long time.. I guess you could cancel it halfway safely. It'll be enough to trigger the kindle recovery on reboot which will wipe your dalvik cache.
Actually if you can get root (without the broken su) try deleting /data/dalvik-cache then reboot
Click to expand...
Click to collapse
wiping in fastboot took care of everything and did a reset on it. thanks!
How to fastboot with wipe?
Can you share with how to fastboot and wipe for factory reset (effectively)?
knitterb said:
Can you share with how to fastboot and wipe for factory reset (effectively)?
Click to expand...
Click to collapse
I mentioned to my friend they should write it up and post how to do it since it would be easier for them to describe the steps in more detail since they actually physically have a kindle fire and I do not; so I think they will be later. It's rather easy to do though once you have the steps (basically a handful of steps and the rest is waiting).
It should provide a recovery for anyone that bricks their tablets though.
EDIT: link for unbricking is up now: http://forum.xda-developers.com/showthread.php?t=1356257
yareally said:
I'm running low on options for what is wrong with this kindle fire, so maybe someone can point out something I am missing. My friend flashed google apps on it after they rooted and somehow something was botched and I've been playing doctor to it remotely over VNC and running commands on adb. Anyways, it's stuck at the splash screen and not booting and this is everything I've tried and all the information I've gathered:
1) reflashed the last updated boot.img from amazon in fastboot
2) reflashed the recovery.img in fastboot
3) verified the md5sum and permissions on every file & directory in /system (all check out okay).
4) Verified there are no files missing or added to anywhere in /system
5) cannot get it to rerun the update after pushing the update to /sdcard/kindleupdates (it ignores it despite it being there, either because of the condition of the tablet currently or the fact it's already updated).
After doing the above, the state of the device doesn't change a bit. Same errors, same slash screen.
Only idea I might have to what is wrong (but I have no idea how it would have happened) is the boot image (mmcblk0) is corrupted somehow (not to be confused with boot.img which has the kernel and ramdisk [mmcblk0p2]). If it is that, then flashing u-boot.bin might solve it, but I'm not sure how to do that exactly and would want to be sure since it could really screw things up.
Issues:
1) Stuck at the load splash screen
2) su will not work (says segmentation fault, etc), however running the temp root exploit manually will give back root for things I need and allow me to mount/unmount, etc.
3) lots of errors in log cat see the link (started at boot and ran a min or so): pastebin.com/LcXU3cxz
root method was zergRush : rootkindlefire.com/kindle-fire-root/how-to-root-kindle-fire/
partition sizes (from running cat /proc/partitions ):
If anyone can shed any light on what might be wrong or what else can be done, let me know.
Click to expand...
Click to collapse
It says you flashed the boot.img and recovery.img, I believe I have problems with those two areas on my kindle, are you able to give any tips on flashing those?
I'm not trying to get my hopes up too high but i think i might of got my partial SBK.I was reading this guide i found on recovering it and decided to try it.
http://forum.xda-developers.com/showthread.php?t=1751978
This is what i came up with on my phone:
0x00000012a33080
Basically most of it seems correct besides all the zeros at the beginning.Not really sure why it won't connect the key in nvflash.Any ideas?When i run it in the sbcalc program i get something similar to the how it should look from an android device.The tutorial says you should have a 64 bit ubuntu/linux system,but there is an option to change the code for 32 bit.If someone out there that has a 64 bit machine maybe they could try it out:
make sure your phone is plugged into the usb port,and the phone is off.
open a terminal,then sudo su(make sure your root)
then this command watch -n2 lsusb (apx doesnt always show up so this keeps checking until it does)
hold down u+s+b plus power on the phone (sometimes i hold then let go of the power while holding the buttons)
once you see something like (Bus 001 Device 031: ID 0955:7416 NVidia Corp) you are in apx mode(ctrl + c to stop the watch command)
after that you need to make the apx.c file.Go back to this guide and follow the instructions on the top on how to make it.The most important thing to do is to change the code ( 0x0955, 0x7820 ) to whatever it says from the lsusb command.Mine is like this( 0x0955, 0x7416 )Once you make the .apx file just open another terminal (make sure its root)then run ./apx
It should pop out a number similar to mine.If you end up with a code something else besides all those zero at the beginning,then there is a chance it make work when we run it in Nvflash
From there goto this website and enter the code in there (delete the x)
http://a500bootloaderflash.tk/sbkcalc/
It should spit out a code like this: 0x07B91000 0x204AF201 0xD09B1103 0xF768F302
So after that you would go back into terminal (sudo su) then run nvflash like this:
./nvflash --sbk 0x07B91000 0x204AF201 0xD09B1103 0xF768F302
If were lucky then it should pop up a whole bunch of info.My hope is that someone will know a little bit more on what i might be doing wrong with the code to get this working correctly.I believe it must be doing something though as it will only display that code when in apx mode.It's getting late over here and spent too many hours trying to figure this out tonight.lol.Let me know if anyone needs help.Good luck.
update
I setup another computer with ubuntu 12.04 x64 and configured a new apx file once again:
0x00fcfe12a33080
It looks like i got closer but still need 15 digits past the 0x to make a correct SBK.Nvflash wasnt having anything i tried so far.I'm still looking for a way to fix this.
Keep up the good work. Glad to see some love coming back to the kin
Sent from my DROID RAZR using xda app-developers app
I found some new commands off a older version of nvflash i was using :
nvflash action [options]
action (one or more) =
--help (or -h)
displays this page
--cmdhelp cmd(or -ch)
displays command help
--resume (or -r)
send the following commands to an already-running bootloader
--quiet (or -q)
surpress excessive console output
--wait (or -w)
waits for a device connection (currently a USB cable)
--create
full initialization of the target device using the config file
--download N filename
download partition filename to N
--setboot N
sets the boot partition to partition N
--format_partition N
formats contents of partition N
--read N filename
reads back partition N into filename
--getpartitiontable filename
reads back the partition table into filename
--getbit filename
reads back BIT into filename
--getbct
reads back the BCT from mass storage
--odm C Data
ODM custom 32bit command 'C' with associated 32bit data
--go
continues normal execution of the downloaded bootloader
options =
--configfile filename
indicates the configuration file used with the following commands:
--create, --format_all
--bct filename
indicates the file containing the BCT
--sbk 0x00000000 00000000 00000000 00000000
indicates the secure boot key for the target device
--bl filename
downloads and runs the bootloader specified by filename
--odmdata N
sets 32bit customer data into a field in the BCT, either hex or
decimal
--diskimgopt N
sets 32bit data required for disk image convertion tool
--format_all
formats all existing partitions on the target device using the config file,
including partitions and the bct
--setbootdevtype S
sets the boot device type fuse value for the device name.
allowed device name string mentioned below:
emmc, nand_x8, nand_x16, nor, spi
--setbootdevconfig N
sets the boot device config fuse value either hex or decimal
--verifypart N
verifies data for partition id = N specified. N=-1
indicates all partitions
Intended to be used with --create command only.
--setbct
updates the chip specific settings of the BCT in mass storage to
the bct supplied,used with --create, should not be with --read,and
--format(delete)_all,format(delete)_partition,--download, and--read
--sync
issues force sync commad
--rawdeviceread S N filename
reads back N sectors starting from sector S into filename
--rawdevicewrite S N filename
writes back N sectors from filename to device starting from sector S
--updatebct <bctsection>
bctsection should refer to the section of the bct we are updating.
Curently we suport updates for following sections
<SDRAM> updates SdramParams and NumSdramSets fields
<DEVPARAM> updates DevParams, DevType and NumParamSets
<BOOTDEVINFO> updates BlockSizeLog2, PageSizeLog2 and PartitionSize
Apart from that i tried everything i could really think of for getting that key.This phone seems to be very locked down and without enough info on the system or where that sbk might be located,i think were back to a dead end again.I know on bitpim there are some files on there that can be downloaded and maybe decompiled or something.(maybe the key is in there)
I was figuring the key would be the same setup as the later tegra devices but i believe its different now.My only guess now is too have someone with a lot of electronics knowledge to find the uart on the board and we could read the nand like that.
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
What exactly lies in the mmcblk0p7 partition?
MOVZX said:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
Click to expand...
Click to collapse
PER - Per device provisioned data or per device calibration.
A cursory scout around XDA suggests this contains sensor calibration and such like.
http://forum.xda-developers.com/showthread.php?t=1739119
(edit: checkout the last posts by osm0sis - this guy knows his stuff when it comes to partitions).
I'm pretty sure it isn't the BOOTLOADER partition...
I would tentatively suggest you're OK for a reboot. I can't think of what else you can do, to be honest.
-----------
If you must flash a recovery using the dd command use the by-name syntax...
su
dd if=/sdcard/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS
Rgrds,
Ged.
@GedBlake
Thanks for the info. I was asking, because if it didn't vary from device to device I could probably dd up a backup of the partition and upload it here for the user to dd into his partition in his tablet.
That being said, I'll keep an eye on this thread for further consequences or the like.
@MOVZX
Please state whether you have a Grouper or Tilapia device, and the approximate manufacturing date, if known.
The PER partition is formatted as a FAT filesystem**. It seems to contain measurement data created during factory testing procedures. See here.
Note that there seem to be differences from device to device (compare the two posts in the above link). Here are the two critical questions:
1) What is the exact FAT format? (There are a couple of different FAT variants)
2) Does the bootloader read this partition during hardware initialization?
I seem to remember a thread here in the Nexus 7 forums where someone was claiming to adjust the ambient light sensor by altering a file in the PER partition. If that is correct, then indeed this partition *could* be critical to correct operation of the device.
I think you are being prudent about not rebooting. I also think that you should find someone to volunteer to give you a raw image dump (dd) from a device that is as close to yours as possible. Note that like many other devices, the N7 has hardware variants, and the PER partition seems to reflect that.
The calibration data for your device is now permanently lost, and you are the unfortunate experimenter who will find out the consequences of that.
**If you can not get someone to help you, the issue of the filesystem formatting can be solved by one of us by:
- raw dumping our PER partition, loopback mounting it, removing all files, unmounting it, and then giving that to you.
At least you would then have the correct filesystem formatting, but empty.
Also, please do a
dd bs=1024 of=/dev/null if=/dev/block/platform/sdhci-tegra.3/by-name/PER
to let us know what size your partition is.
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
bftb0 said:
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
Click to expand...
Click to collapse
Interesting stuff, bftb0, as always...
So what, in your opinion, is the worst case scenario?
If the bootloader is still accessible, couldn't the OP just fastboot flash back to stock?
(Assuming a simple reboot doesn't fix it).
Or does this not touch the PER partition? I would have thought that running the flash-all.* script would reset all partitions back to their default values.
I'm probably missing something here, so apologies - just a suggestion.
Rgrds,
Ged.
@GedBlake
The factory install procedure doesn't touch anything but the "usual suspects".
We sort of already know what the worst case is. As to whether to bootloader "needs" the PER partition or not, I don't really know. At this point my bet is that it does not, but that is purely an educated guess.
@MOVZX
I am attaching a "PER-empty.zip" file to this post. It is tiny because it is an almost empty FAT32 filesystem image (PER.img), so it compressed by nearly 100%. (When you unzip it, the "PER.img" image file should be 5,242,880 bytes, or 5120 kB) If you want to, feel free to un-zip it, and then flash the extracted "PER.img" file to the PER partition on your device.
Assuming you are using adb from your PC with the custom recovery still running:
Unzip PER-empty.zip, then
Code:
adb push PER.img /sdcard/PER.img
adb shell dd if=/sdcard/PER.img bs=1024 of=/dev/block/platform/sdhci-tegra.3/by-name/PER
What this will do is install an almost empty FAT32 filesystem which was created with the exact parameters used on my device. (I assume that your device also has a 5120 kB PER partition, but you have not replied.) The almost part is that I truncated every file in my image to zero length.
That's not much, but at least you will have a valid filesystem and most files of the correct name, even if they are zero length.
Note that once you have a filesystem in the PER partition, you are free to mount it using the custom recovery, and do whatever you please, e.g.:
Code:
adb shell mkdir /data/local/tmp/permount
adb shell mount -t vfat /dev/block/mmcblk0p7 /data/local/tmp/permount
adb shell
$ cd /data/local/tmp/permount
... do whatever you want in here...
$ sync
$ exit
adb shell umount /data/local/tmp/permount
adb shell rmdir /data/local/tmp/permount
good luck with your tablet - let us know how everything turns out.
.
I'm using Nexus 7 WiFi 16GB.
I almost have all the required files. The sensors and lightsensor directories were found mounted at /data/sensors and /data/lightsensor, so I copied it.
Here is the content of my sensors & lightsensore files:
lightsensor/AL3010_Config.ini
1476
Click to expand...
Click to collapse
sensors/AMI304_Config.ini
921368
2048 2048 2048
0 0 0
600 600 600
210 42 -256
0 0 0
0 0 0
103 100 101
0
Click to expand...
Click to collapse
sensors/KXTF9_Calibration.ini
1071 -1035 1034 -1030 -1097 1213
Click to expand...
Click to collapse
The FAT partitions is now Ok.
Now, I'm missing these files:
adc-rawdata.csv
ISN
KXTF9_Calibration.ini
prom-filter-rawdata.txt
rawdata.csv
rek-prom-rawdata.txt
SSN
Click to expand...
Click to collapse
I'm having no confidence to reboot this device yet
Disclaimer:
Xflasher tool was made for testing and educational purposes, ME is not responsible for what you do on/with your device using xflasher, you must agree that you using xflasher on your own risk, I am not responsible if you brick your device or anything!
How to use:
(2017 phones like xz premium which have usb vid : pid = 0fce : b00b is not supported since use new flashing protocol! Use newflasher tool if your device usb pid is B00B!!)
1. (this step only for windows version!) install usb drivers the same like one which you using with flashtool
2. simple put xflasher.XXX in firmware dir which is created by great @IgorEisberg tool caled XperiFirm, double click xflasher.exe (or execute xflasher.XXXX in case non windows version) it will create xflasher.bat (or xflasher.sh in case non windows version)
3. modify xflasher.bat (or xflasher.sh in case non windows version) for your needs
4. put your phone into flashing mode (do in mind its not fastboot mode, must be in flash mode!)
5. make sure your battery is enought charged at least 30 percent charged!!!
6. double click xflasher.bat (or run xflasher.sh in case non windows version) and wait until xflasher flash your rom
7. done
8. enjoy
Supported platforms:
- there is 3 versions, one is for Linux, one is for Windows, and one for Android! You can now flash phone trought another phone, so no more needs for PC!!!
Credits:
- @shoey63 for helping me deeply testing xflasher, thanks a lot man!
Source code:
- https://github.com/munjeni/xflasher
is it support for zeus mode xperia m ?
MOD EDIT @gregbradley
Quote removed, not needed and had large images
sorry if im wrong, but this will eventually be able to unlock bootloader?
inunxelex said:
is it support for zeus mode xperia m ?
Click to expand...
Click to collapse
No, this tool use s1 protocol so all phones which use s1 protocol can use this tool!
ayuready1989 said:
sorry if im wrong, but this will eventually be able to unlock bootloader?
Click to expand...
Click to collapse
Only on bootloader unlock allowed phones!
New version is out!
Changelog (v2):
- support for safety unlocking device bootloader (sha256 key check + check rooting alowed yes or no before unlocking)
- support for flashing all sin files from bundle but NOT BOOT BOOTBUNDLE! I will implement boot boondle soon (boot bondle mean: boot delivery from boot folder aka sbl1, s1sbl, dbi, aboot... so please do not flash them since if you flash wrong file you will hard brick your device!)!
- you can change usb VID and PID parameter (but in usb driver do it manualy by self)
Log about success in flashing some sin files is in attachment
After the experience you acquired writing this tool and with the previous research , do you think it would be possible to make backups of TA partition (or at least that area of TA partition that stores DRM keys) even from an unrooted phone?
I mean, personally I have an Xperia S, but I was especially thinking to our friends with a Z3 that aren't able to preserve them atm.
Good question! I thinked the same like you, but there is some problems, for example I have analysed ta and found 4 partitions inside ta, first one is 0100 (aka 01) and seccond one is 0200 (aka 02), booth 1 and 2 can be dumped trought special command to bootloader (flash tool dumping only partition 2 and not all units). But there is other two partitions which is 0101 and another one 0201, I have no idea how to send command to bootloader in order to dump them, for example for dumping first two partitions I need to send command OPEN_TA with partition number as parameter before sending command READ_TA unit, have tried many combinations for opening parrition 0101 but getting error reaply from bootloader which mean parameter error It will be a great having possibility dumping ta in full form without a needs having root, but seems its not possible by now, maybe in future we can do it.
Allso found something interesting. Dump.ta maded by our tool dumping partition 1 and 2, but flashing ta file only partition 1 data is writen since fitst parameter in file is 01 which mean "open partition 1", but to open seccond partition and write seccond partition data we must separate one file into two files since each partition and partition data must be separated since flashtool or s1tool can't see seccond partition parameter, so one file must be cut into 2 files before flashing! In any way you can not brick your phone by not separated files, but only partition 1 will be flashed.
Edit:
Drm keys and all things lives in partition 2 (on rooting allowed devices), I will need to compare s1 dump with ta dump and see what was not dumped from ta. Drm keys for sure missing, probably can not be dumped with reason since it will be easy way tricking Sony bootloader unlocking policy He have designed unlocking procedure to delete drm and probably his bootloader is designed to skip drm dumping Some units magic bytes is masked with ffffffff00000000, have no defined size in header...etc, which probably is with reason hiden to unit dumper command
munjeni, nice work. As fas as I researched, DRM keys are located in Unit 0x1046B. At least this is the unit which the bootloader deletes when it recognizes the device as rooted. I was not able to dump this unit via flashtool. Trying to flash it resulted in:
Code:
ERROR - ERR_SEVERITY="MINOR";ERR_CODE="0026";ERR_DYNAMIC="Not authenticated";
So I guess it's somehow special protected.
I was able to dump the unit with miscta_read_unit (you need atleast system privilegues) but not write to via miscta_write_unit (resulted in error code 3).
We should be able to dump all TA units with system user (in regards to the recent exploit which theoretically allows privilegue escalation to system user).
Problem is we can not simply restore them unless we find a way to generate a TA.img (with correct unit layout) out of unit data.
. .
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
zxz0O0 said:
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
Click to expand...
Click to collapse
You are right, its on partition 1! Will try something now related to our tool (seems I have s1 dump of unlocked ta since I can not see these unit by now in dump). But if my tool can dump these unit than probably we can reconstruct ta img from s1 dump, see my previous post (explained everything related to partitions and units)!
Tool can not read these unit
Log:
Want read ta unit 0001046B...
Sending command...
Command raw[13]:
00000000 00 00 00 0C 00 00 00 03 00 00 00 04 12 .............
Sending command...
Want unit raw[4]:
00000000 00 01 04 6B ...k
CRC32[4]:
00000000 BF CE 17 E3 ....
Writing crc32 for want read ta unit...
Verifying crc32...
Error: device reported that wanted ta unit is not found or can not be read!
Success: bulk read 4 bytes
Raw reply[4]:
00000000 00 00 00 00 ....
Error reading unit 0001046B!
Click to expand...
Click to collapse
So non rooted device have no chance having full ta dump since unit 1046B will be missed in s1 dump Maybe we can generate these unit? And how? Its probably MD5??? Or probably 3 x crc32 of the MARLIN+CKB+WMLA + 1 x crc32 of the crc32+crc32+crc32 ??
zxz0O0 said:
I was able to dump the unit with miscta_read_unit (you need atleast system privilegues) but not write to via miscta_write_unit (resulted in error code 3).
We should be able to dump all TA units with system user (in regards to the recent exploit which theoretically allows privilegue escalation to system user).
.
Click to expand...
Click to collapse
Ahh I see, how you dump these unit trought system user?
munjeni said:
Tool can not read these unit
Log:
So non rooted device have no chance having full ta dump since unit 1046B will be missed in s1 dump Maybe we can generate these unit? And how? Its probably MD5??? Or probably 3 x crc32 of the MARLIN+CKB+WMLA + 1 x crc32 of the crc32+crc32+crc32 ??
Click to expand...
Click to collapse
There is a command 0x19 (hook), I will try with hooking first and see whats happening!
zxz0O0 said:
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
Click to expand...
Click to collapse
You need to change first argument in ta "02" to "01" since these unit is in partition 01 but be carefull since I do not know if some units from partition 02 exist in partition 01 since if you flash wrong data you can get brick! My tool was helper tool only for unbricking devices, I need to modify my tool a bit for that since I was not know about partitions in ta!
You can use miscta_read_unit from libmiscta.so to read this unit.
Code:
static int (*_miscta_read_unit)(int TAUnit, void* buf, int* size)
But you need system or root privileges.
Hopefully you can update your ta_gen tool since it could not unbrick my device. There should be a command to format TA (maybe 0x0B?). Maybe we can send this command before restoring TA backup for successful unbrick.
zxz0O0 said:
You can use miscta_read_unit from libmiscta.so to read this unit.
Code:
static int (*_miscta_read_unit)(int TAUnit, void* buf, int* size)
But you need system or root privileges.
Hopefully you can update your ta_gen tool since it could not unbrick my device. There should be a command to format TA (maybe 0x0B?). Maybe we can send this command before restoring TA backup for successful unbrick.
Click to expand...
Click to collapse
Which device you have? If your ta partition is bricked or formated you will have chance to unbrick only by emmc tool or by jtag tool!
Commands in s1 protocol:
Code:
#define CMD_LOADER_INFO "\x00\x00\x00\x01" /* loader info (hook phone in flashmode) */
#define CMD_FLASHMODE_OFF "\x00\x00\x00\x04" /* Kick device off flashmode */
#define CMD_WRITE_SIN_HEADER "\x00\x00\x00\x05" /* write SIN header */
#define CMD_WRITE_SIN "\x00\x00\x00\x06" /* write SIN */
#define CMD_GET_LAST_ERROR "\x00\x00\x00\x07" /* Get last error */
#define CMD_OPEN_TA "\x00\x00\x00\x09" /* open TA (takes the partition number as parameter) */
#define CMD_CLOSE_TA "\x00\x00\x00\x0A" /* close TA */
#define CMD_READ_TA "\x00\x00\x00\x0C" /* read TA */
#define CMD_WRITE_TA "\x00\x00\x00\x0D" /* write TA */
#define CMD_DISABLE_VERIFICATION "\x00\x00\x00\x19" /* Disable Final Verification check ? */
Not sure about 0B and allso not going to try them since I allready changed my mainboard after bricking ta partition
Tried to read unit 1046B after writing coomand hook but stil no chance dumping them trought s1. In next few days I will focus on generating ta.img from s1 dump and will analyse things more
I have Z1 Compact and tried to recover using your ta_gen and s1tool. But still dead I don't own a jtag device nor have any experience using it.
https://accounts.google.com/signin/...dSession#folders/0B9t5VvCjiCO-Qm9Bb29PdzdHajQ
That's the link. You get the shortcode link when trying to flash the Turbo 2 using fastboot Linux command line. I first found some other cool tricks I have never seen mentioned about the fastboot oem command and some certain characters, but I suspect it is not related.
I got in, I noticed they just did an update to all the files, I downloaded everything, aa zip of all of it, and promply lost access. I have a spreadsheet open in google docs describing the updates. You can see at the top that it says that permissions have changed.
binwalk: Did I really find a boot img? Also: Legal advice?
Here's what binwalk just found (edit's mine til I know legal deal):
Code:
1###1#0 0x1#ABC# Android bootimg, kernel size: 1871876996 bytes, kernel addr: 0x###4#F#E, ramdisk size: 1953406600 bytes, ramdisk addr: 0x6###6##0, product name: "reating boot image..."
1##6##0 0x10#ABC Unix path: /../../target/product/%s/%s
The hexadecimals (mem addrs?) are actuallly there. I have adjusted the sizes, but if you know them you could figure out they are legit and my edits were simple.
can you please upload this onto this post or zippyshare or some other place. dumbass google made it so you have to have a Motorola email address to login