Trim Area Tool
Hello! First of all sorry for my bad english words I will try to explain what this tool mean. I am working on trim area dump .ta to .img converter. Whole idea is to dump drm key which is stored in ta unit 1046b and dump the rest of units and further convert (reconstruct) that .ta dump to fully functional .img dump. Whole idea is based on thing which I found in my trim area dump unit 1046b which is somehow doubled on my unmodified locked TA and by the way not deleted after unlocking. I thinked to root phone by unlocking device, get backup unit 1046b, reconstruct trim area, flash reconstructed trim area to make phone locked as before unlocking. Inded it can be done (unconfirmed curently) but... Later things is confirmed on other phones that not all phones have that doubled unit so that mean not all phones have the same trim area. In general my idea was to decode that mistic trim area. I have done things, its decoded partialy but not all since some devices don't have the same headers of the units, for example some device headers starts with C1E9F83Bffffffff but some with C1E9F83Bffffff32 and some with C1E9F83B32323234... I have done some tests to an device (z3) which have broken screen. That phone had that diferent unit headers which is not like on my phone c1e9f83bffffffff, I have reconstructed trim area, flashed back, and this is a report -> http://forum.xda-developers.com/showpost.php?p=69926765&postcount=117 and this one -> http://forum.xda-developers.com/showpost.php?p=69928391&postcount=119 and this one -> http://forum.xda-developers.com/showpost.php?p=70003707&postcount=153
Whole story starts at page http://forum.xda-developers.com/xperia-x-performance/how-to/dirtycow-temp-root-t3503918/page5 please read all posts if you are interesting for trim area things and things which I thinked to do! By that way you will understand better about our tool and idea about a tool!
Trim area format is explained in this post -> http://forum.xda-developers.com/showpost.php?p=69865938&postcount=64 . Problem by now is we don't know how safe is reconstructing some trim area, for example that mistic diferencies in bytes (ffffffff) on some phones and (32323234) on some phones and also some diferent on some phones is a problem by now. What that bytes mean and or why it differs on some devices, I don't know. My tool reconstruct that and makes all ffffffff. The same things can be seen in unused blocks, for example on some devices its filled with 0xff and on some devices with 0x10 and on some devices with 0x32. Why I don't know. My tool makes it all 0xff.
I can reconstruct all units from .ta and can produce .img, but I can not confirm if it will work since testers for that thing is need! Tool is in early stage and not all features is implemented with reason: need to be confirmed one by one. Curently I have done only basic reconstruction which didn't change units data.
Only change headers and unused blocks and make them all with 0xff. At the end tool regenerates hashes of the partitions, thats all by now. I don't know how safe it is at all!
I have done trimarea_tool (command line tool), and that tool nothing change in trim area dump other than unit headers (I have not implemented the rest of my tools since undocumented trim area is still undocumented and very risky is touching trim area, so I not included the rest, it will be public somedays when things gone fully tested), partition hashes and unused blocks, it cleans that 32323234 bytes and writes ffffffff instead and regenerates hashes, thats all by now. Unit data is the same. I have included ton of checks, for example if you try to modify your original ta dump, tool will not generate reconstructed trim area, if size is different, if trim area is not 0x200000 bytes long... and many more. Since we are at initial stage about trim area in general we can't know how safe is playing with trim area, @itsux is only one who flashed reconstructed trim area and reported no hard brick. I must notify you now with red words DO NOT FLASH IF YOU NO WANT TO RISK!!! THIS IS VERY DANGEROUS AND MAY HARD BRICK YOUR PHONE - MEANS KILL FOREVER!!! DO NOT USE ON A WORKING PHONE, THAT IS A RISK!!! Use only if you have broken phone for example working phone with not working or broken screen and you no need that phone, don't flash on daily phone! Itsux is only one who tested on his Z3 phone which is with broken screen, I have modified his trim area the same way, he flashed back that trim area and reported here that his phone is not hard bricked. Again I don't know how safe things is so I am not responsible if tool kills your phone, use at your own risk!! But if you realy want to risk and probably kill your own phone please report what happened at least, it would help further development on this tool!
How to run tool:
First of all this tool is not a standard application so you can't open it like a regular application by double click! Tool is a command line tool so it must be run trught your windows command prompt or trought an batch file! Tool reguires only one parameter, parameter is you TA.img file, e.g:
Code:
trimarea_tool TA.img
Great progress.
I'll think about letting you mess with my Z5s TA [emoji14] Also I'll PM you the Z3 and Z3C TA images as promised in the PM later.
Sent from my D6603 using Tapatalk
Sorry, I don't really understand the purpose of this project, since TA backup is already achieved on new series?
Yes thats a true, dump is achieved, but somedays for example when new xperia lines comes out and there was no root possible (android is more and more secure) we can use further tool to convert unlocked trim area to locked one for example. What we can do with unlocked bootloader that is a very clean I'm in hope
p0kemon said:
Yes thats a true, dump is achieved, but somedays for example when new xperia lines comes out and there was no root possible (android is more and more secure) we can use further tool to convert unlocked trim area to locked one for example. What we can do with unlocked bootloader that is a very clean I'm in hope
Click to expand...
Click to collapse
So u are trying to fix already UB phone with no ta backup to return to completely fixed drm key? wow now i understand XDD Appreciate your work
KWOKSFUNG said:
So u are trying to fix already UB phone with no ta backup to return to completely fixed drm key? wow now i understand XDD Appreciate your work
Click to expand...
Click to collapse
No...the purpose of this tool would be to reconstruct the trim area from a locked bootloader phone so you don't have to wait for an exploit to be found to root (temp root) on future firmwares to backup your TA when all known exploits are patched..
If you already unlocked there nothing that can be done
-DM- said:
No...the purpose of this tool would be to reconstruct the trim area from a locked bootloader phone so you don't have to wait for an exploit to be found to root (temp root) on future firmwares to backup your TA when all known exploits are patched..
If you already unlocked there nothing that can be done
Click to expand...
Click to collapse
Thats right! By the way we still need system user at least in order to dump unit 1046b trought libta.so Hope we get better way when it need.
One more thing, we don't know for sure if drm key is maybe just an generic key for example one which we can enter for example, right? It must be tested first before things gets comfirmed.
p0kemon said:
Thats right! By the way we still need system user at least in order to dump unit 1046b trought libta.so Hope we get better way when it need.
One more thing, we don't know for sure if drm key is maybe just an generic key for example one which we can enter for example, right? It must be tested first before things gets comfirmed.
Click to expand...
Click to collapse
Even better
By the way I got a Z3 with a detached front panel, which is just collecting dust right now as I bought a Z5p after the Z3 broke...
The Z3 is fully functional (the screen colors are just washed out), it is rooted with a locked bootloader (never was unlocked)...I can totally test things on it for you, no problem if it bricks
-DM- said:
Even better
By the way I got a Z3 with a detached front panel, which is just collecting dust right now as I bought a Z5p after the Z3 broke...
The Z3 is fully functional (the screen colors are just washed out), it is rooted with a locked bootloader (never was unlocked)...I can totally test things on it for you, no problem if it bricks
Click to expand...
Click to collapse
That would be great realy! I have done some updates to tool right now, forgot to disable "supported device" check, by now all 2mb trim areas is supported. If you going to try please report what happened!
Some updates... now tool generates two reconstructed formats .img and .ta
.img format is the same like your ta.img dump, just reconstructed
.ta format is just an text file which contains the same data like one from your dump from flashtool, one to four .ta files is created and every one contain its data coresponded to trim area partition number, just reconstructed
Today I have received xperia z1 compact with broken screen, on my supprise I started momentaly working on tests to ta, first thing which I done was reconstruction. What I have done? Since unit 8b2 is unit which is created after unlocking, unit with the same size, unit in the same partition 2 like unit 1046b which get deleted after unlocking... what I tested? Partition 020002 (mean partition 2, part 0), unit 1046b was in partition 020002, now it is in partition 020202 (which is seccond part of the partition 2, in most case), unit 1046b is now in partition 020202 as a replacement to unit 0b2, comfirmed sucess! Just replaced unit 8b2 with one 1046b, reconstructed hashes and I can finally say its success, first device successfuly relocked! Device is locked again the same like before unlocking, all drm keys is with status OK! So guys project is sucesfull! Next thing which I going to test right now is that 32323234 bytes and things...
One more thing! Next test was now:
unit headers which was on xperia z1 compact as C1 E9 F8 3B FF FF FF FF is changed to C1 E9 F8 3B 32 32 32 34, which is totaly the same like z3, and unused blocks which was filled with FF now is changed to 10, reconstructed trim area, updated hashes, flashed, what happened??
Whola!! Done.
Drm keys and thing is with status OK which mean success on z1c, comfirmed successfull reconstruct on z1 compact. I am still afraid to other device models, how safe is on other devices or newer devices I don't know! Probably these bytes which differs on other models (32 32 32 34 on some and on some diferent...), I think can be changed to whatever we want. Maybe these bytes is just an idication for unit changes. On other device I think changing these bytes to FFFFFFFF probably must work the same, I don't know realy how safe is. Be warned again, TOOL IS STILL NOT A SAFE UNTILL SOMEBODY CONFIRM SAFE, HARD BRICK CAN HAPPEN, DO IN MIND THAT! I'm still need somebody confirm before I finalize tool.
p0kemon said:
Today I have received xperia z1 compact with broken screen, on my supprise I started momentaly working on tests to ta, first thing which I done was reconstruction. What I have done? Since unit 8b2 is unit which is created after unlocking, unit with the same size, unit in the same partition 2 like unit 1046b which get deleted after unlocking... what I tested? Partition 020002 (mean partition 2, part 0), unit 1046b was in partition 020002, now it is in partition 020202 (which is seccond part of the partition 2, in most case), unit 1046b is now in partition 020202 as a replacement to unit 0b2, comfirmed sucess! Just replaced unit 8b2 with one 1046b, reconstructed hashes and I can finally say its success, first device successfuly relocked! Device is locked again the same like before unlocking, all drm keys is with status OK! So guys project is sucesfull! Next thing which I going to test right now is that 32323234 bytes and things...
Click to expand...
Click to collapse
You meant that you repair TA area of unlocked device without original TA backup?
Desperanto86 said:
You meant that you repair TA area of unlocked device without original TA backup?
Click to expand...
Click to collapse
Yes!
p0kemon said:
Yes!
Click to expand...
Click to collapse
Dude, its the epic win! In future all sony users can forget about TA backup! You should do DONATE button in your profile!
Desperanto86 said:
Dude, its the epic win! In future all sony users can forget about TA backup! You should do DONATE button in your profile!
Click to expand...
Click to collapse
There is only one problem though, reconstruction need drm key which we need to dump first
I'm analysing now cryptography and can not understand some thing. For example..
1. Unit 8b2 is unit created after unlocking.
2. Unit 1046b is unit which is deleted, it had drm key.
Unit 8b2 is just a key which hash is in unit 7DA (RCK_H= sha256 hash), if we convert 8b2 unit data which is in hex to binary and use it to get sha256 hash we get the same sha256 hash as one in unit 7DA. Unit 8b2 have size the same like unit 1046b, only main diferencie is 8b2 is hex string but 1046b is binary, booth have same size. Unit 1046b after unlocking is replaced with unit 8b2. I am pretty sure there is something tricky between unit 1046b and unit 8b2 since one is hex string and seccond is bin, booth units have the same size! What you think? Do we can reconstruct drm key somehow?
http://newandroidbook.com/Articles/aboot.html Ok. Found some articles how to disasemble aboot, tommorow I will see what aboot says about 1046b
Soo complicated for my head, can't get . Anybody look in .c what is a usage of the ta unit 1046b?? @the_laser , @Androxyde ..anybody?
p0kemon said:
There is only one problem though, reconstruction need drm key which we need to dump first
Click to expand...
Click to collapse
but to dump a BL-locked TA partition we still need a temporary root exploit right?
I can't get it, sorry XD
EDIT: reading better in the original thread, i understand that you can dump the interesting units (NOT the whole TA) using flashtool even on locked devices.
so even without a root exploit, the DRM key could be dumped using Flashtool, TA reconstructed and flashed back after unlocking the bootloader.
And, if i understand well, the TA reconstruction would not include the unit that relocks the bootloader (like it happens when you simply restore the TA backup).
Is it right?
Related
Hi all,
I was following the "main thread" a while ago before these phones had their own section, but hadn't checked for updates since early to mid January (before the bootloader was unlocked). Now I see that it's unlocked, there is unfortunately no support for the Canadian (Bell) variant, the E617G.
I extracted the bootloader from my wife's phone and did a binary comprison to the various unlocked bootloaders for the E610, 612 and 615 and it's almost identical byte for byte to the E610. Aside from the edited messages and the tail end of the files where the checks appear to be located, there is one location (byte 0xB476) that is different.
I'm not really experienced in this sort of work, but could that one byte be what's causing the random reboots for the E617 variants? Before I try truncating the file I extracted to removed what appears to be the secure checks and flashing it, does anybody have any other reasons why the E617 has been "left out in the cold"?
I've attached some screenshots of the comparison to the E610 emmc_appsboot.bin
First Difference
Differences in Messages
Apparent Secure Checks?
In the 3rd screenshot, you can see in the E610 file, after 0x40F07 the file is blank, but in mine the file continues on (it's 4MB of null padding by the looks of it).
Skellums said:
Hi all,
I was following the "main thread" a while ago before these phones had their own section, but hadn't checked for updates since early to mid January (before the bootloader was unlocked). Now I see that it's unlocked, there is unfortunately no support for the Canadian (Bell) variant, the E617G.
I extracted the bootloader from my wife's phone and did a binary comprison to the various unlocked bootloaders for the E610, 612 and 615 and it's almost identical byte for byte to the E610. Aside from the edited messages and the tail end of the files where the checks appear to be located, there is one location (byte 0xB476) that is different.
I'm not really experienced in this sort of work, but could that one byte be what's causing the random reboots for the E617 variants? Before I try truncating the file I extracted to removed what appears to be the secure checks and flashing it, does anybody have any other reasons why the E617 has been "left out in the cold"?
I've attached some screenshots of the comparison to the E610 emmc_appsboot.bin
First Difference
Differences in Messages
Apparent Secure Checks?
In the 3rd screenshot, you can see in the E610 file, after 0x40F07 the file is blank, but in mine the file continues on (it's 4MB of null padding by the looks of it).
Click to expand...
Click to collapse
Hey, I have the E617-G too and I'm looking for a way to unlock the bootloader. have you made any progress on doing it? I would forever be in debt to you if you did hahahahh!
KingDaedrix said:
Hey, I have the E617-G too and I'm looking for a way to unlock the bootloader. have you made any progress on doing it? I would forever be in debt to you if you did hahahahh!
Click to expand...
Click to collapse
Sorry for the lack of reply, I've been busy for the past few weeks!
I went ahead and truncated the backup I made, and changed the one byte that was different... So far I haven't had any problems. I was able to flash the recovery image and make a CWM backup.
I made a few other slight modifications (changed the messages in the file, from "Russia" to "Canada" ), but other than that the files are identical.
I've attached my modified file if you want to give it a go. The instructions are the same as the other unlock instructions here.
Make sure you don't skip making a backup just in case!!!
As usual with things of this nature: I claim no resposibility for any damage to your phone, loss of data, etc!! Flash at your own risk!
All credit to the original devs of the unlock, fix is the same, just different source files were used.
Skellums said:
Sorry for the lack of reply, I've been busy for the past few weeks!
I went ahead and truncated the backup I made, and changed the one byte that was different... So far I haven't had any problems. I was able to flash the recovery image and make a CWM backup.
I made a few other slight modifications (changed the messages in the file, from "Russia" to "Canada" ), but other than that the files are identical.
I've attached my modified file if you want to give it a go. The instructions are the same as the other unlock instructions here.
Make sure you don't skip making a backup just in case!!!
As usual with things of this nature: I claim no resposibility for any damage to your phone, loss of data, etc!! Flash at your own risk!
Click to expand...
Click to collapse
thanks a lot! I was looking to put a Windows Phone 7 ROM on it, is that possible? Sorry, I'm kind of a noob with phones, more into building computers and such.
KingDaedrix said:
thanks a lot! I was looking to put a Windows Phone 7 ROM on it, is that possible? Sorry, I'm kind of a noob with phones, more into building computers and such.
Click to expand...
Click to collapse
Unfortunately no. Windows Phone 7 is not open source so there is no easy/legal way to port the OS over. There are launchers that have been made so the Android interface mimics Windows Phone 7, but it's still Android running under the hood.
Help!
Skellums said:
Sorry for the lack of reply, I've been busy for the past few weeks!
I went ahead and truncated the backup I made, and changed the one byte that was different... So far I haven't had any problems. I was able to flash the recovery image and make a CWM backup.
I made a few other slight modifications (changed the messages in the file, from "Russia" to "Canada" ), but other than that the files are identical.
I've attached my modified file if you want to give it a go. The instructions are the same as the other unlock instructions here.
Make sure you don't skip making a backup just in case!!!
As usual with things of this nature: I claim no resposibility for any damage to your phone, loss of data, etc!! Flash at your own risk!
Click to expand...
Click to collapse
I have followed the instruction you posted but i still cant boot into recovery. I have used adb command reboot bootloader and it gets stuck on a black and white screen tht says fastboot processing.
I am not sure if there something wrong with my device.
Thanks!
Me again, just replying to confirm that following the steps posted I successfully unlocked the bootloader of the phone. Not very much use however as there is very few ROMs for the model. Thanks a lot though OP!
I also successfully unlocked the bootloader using your binary. Thank you!
I wrote an article here on getting it all running with CM10.1 on the L5 E617G!
Hi! Yesterday I done stupid thing to my phone which hard bricked my phone Played with GPT gdisk, restored wrong gpt backup which killed my device, phone was dead after reboot, had no fastboot, had no bootloader, only had led blinking red-green . But good news I have repaired my phone sucesfully ! Was a bit lucky since I saved my GPT backup so after unbricking I restored my GPT, than restored TA, rebooted and flashed everything normaly. Device finaly booted :highfive:
WARNING TO ALL:
1. DO NOT PLAY WITH FDISK OR GDISK IF YOU NOT KNOW WHAT YOU ARE DOING SINCE YOUR DEVICE WILL BE HARD BRICKED !!! If you mess your gpt table or change them your device can not be flashed using pc companion or flashtool!!! If you brick gpt table than you will notice hard brick, so my segestion is: do not be stupid like me!!! I was very stupid yesterday and done very bad thing to my new phone using these tools.
2. DO NOT PLAY WITH TRYING TO ENTER YOU PHONE INTO DIAG OR ENGINERING MODE IF YOU HAVE NO RIGHT QCOM USB DRIVERS, IT WILL HARD BRICK YOUR PHONE
3. NEVER TOUCH YOU TA PARTITION SINCE YOU WILL NOT BE ABBLE TO UNBRICK YOU PHONE IN ANY WAY!!!
If trim area is damaged you can try this tool -> http://forum.xda-developers.com/showpost.php?p=56571770&postcount=53 to repair your TA partition if possible
Searched for about an hour for pins on my phone and finaly found test point pins, hope picture will save your time, nerve and your device! Use my tool to unbrick you phone, enjoy!
Download Z1C_hard_brick_repair.exe :
- https://mega.co.nz/#!8FBQkbqK!GK2gQgq1li5Ez4lzijMMMUTkuOz0fowUHB1n1NItEaY
Which part is the testpoint @munjeni ? Is it the top one or the one below? Just curious what are you doing with GPT partition? lol!
Also since you opened your Z1C already... Mind if I ask but is there any trigger button or something on the hooks of the flaps? Can't really tell how the phone detects the flap cause on my device it keeps on popping up even when flaps are closed. I think I have some broken flap sensor or something lol!
munjeni said:
Hi! Yesterday I done stupid thing to my phone which hard bricked my phone Played with GPT gdisk, restored wrong gpt backup which killed my device, phone was dead after reboot, had no fastboot, had no bootloader, only had led blinking red-green . But good news I have repaired my phone sucesfully ! Was a bit lucky since I saved my GPT backup so after unbricking I restored my GPT, than restored TA, rebooted and flashed everything normaly. Device finaly booted :highfive:
WARNING TO ALL:
1. DO NOT PLAY WITH FDISK OR GDISK IF YOU NOT KNOW WHAT YOU ARE DOING SINCE YOUR DEVICE WILL BE HARD BRICKED !!! If you mess your gpt table or change them your device can not be flashed using pc companion or flashtool!!! If you brick gpt table than you will notice hard brick, so my segestion is: do not be stupid like me!!! I was very stupid yesterday and done very bad thing to my new phone using these tools.
Searched for about an hour for pins on my phone and finaly found test point pins, hope picture will save your time, nerve and your device! I will not write full tutorial, but if some one need help than please ask here I will help you! ENJOY!
Click to expand...
Click to collapse
Riyal said:
Which part is the testpoint @munjeni ? Is it the top one or the one below? Just curious what are you doing with GPT partition? lol!
Also since you opened your Z1C already... Mind if I ask but is there any trigger button or something on the hooks of the flaps? Can't really tell how the phone detects the flap cause on my device it keeps on popping up even when flaps are closed. I think I have some broken flap sensor or something lol!
Click to expand...
Click to collapse
Test point is "right pin", "left pin" is gnd. To get into emergency flashmode you need to connect gnd with testpoint.
What I done? I tried to resize userdata + create vfat on remaining free space so after unsucesfull atempt I restored wrong gpt backup thats killed my phone.
About flap... I captured only one picture and I no looked into hook on the flaps, my phone is asembled, hope I will not open them again
Ahh I see thanks for this valuable info! Yeah I know about the gnd thing I usually make the usb port the ground when I do testpoint in the past haha! Hopefully though this info won't come in handy to me in the near future! Are you trying to split userdata so you're able to create a mountable internal storage? Hmm I'm not sure if thats possible just by splitting userdata partition though... I think bootloader checks for the hex size and partition list of the partitions. Altering it might hard brick your device. You would have to reverse engineer the bootloader first before you'll be able to alter partitions in mmcblk0 I think.
munjeni said:
Test point is "right pin", "left pin" is gnd. To get into emergency flashmode you need to connect gnd with testpoint.
What I done? I tried to resize userdata + create vfat on remaining free space so after unsucesfull atempt I restored wrong gpt backup thats killed my phone.
About flap... I captured only one picture and I no looked into hook on the flaps, my phone is asembled, hope I will not open them again
Click to expand...
Click to collapse
Riyal said:
Ahh I see thanks for this valuable info! Yeah I know about the gnd thing I usually make the usb port the ground when I do testpoint in the past haha! Hopefully though this info won't come in handy to me in the near future! Are you trying to split userdata so you're able to create a mountable internal storage? Hmm I'm not sure if thats possible just by splitting userdata partition though... I think bootloader checks for the hex size and partition list of the partitions. Altering it might hard brick your device. You would have to reverse engineer the bootloader first before you'll be able to alter partitions in mmcblk0 I think.
Click to expand...
Click to collapse
On Xperia Go it was possible without needs for patching bootloader, so I thinked its possible on Z1C but I was fataly wrong. On X-Go I have resized system,cache,userdata and increased internal storage with sucess. You are right about Z1C since there is a check by bootloader, and allso there is check by bootloader about gpt! So if your gpt is not original than your phone will have fastboot and s1boot but you will not be abble to flash since you will get internal error message by flasher (tried sony pc companion, tried sony flasher, tried s1tool, tried flashtool and no one was abble to flash, only had a luck after restoring my gpt backup which I had saved)! So guys do not touch partitions!
As far as I know this bootloader security thing already exist on Xperia 2011 line so really weird that Xperia Go doesn't have such. I actually did what you have done on Z1C before on the Xperia Pro since that device has a large system partition and no userdata partition. Thankfully though I noticed the bootloader security before doing anything. It's a little bit possible to hex edit the bootloader to adjust the partition size but I didn't pursue it Don't have guts
munjeni said:
On Xperia Go it was possible without needs for patching bootloader, so I thinked its possible on Z1C but I was fataly wrong. On X-Go I have resized system,cache,userdata and increased internal storage with sucess. You are right about Z1C since there is a check by bootloader, and allso there is check by bootloader about gpt! So if your gpt is not original than your phone will have fastboot and s1boot but you will not be abble to flash since you will get internal error message by flasher (tried sony pc companion, tried sony flasher, tried s1tool, tried flashtool and no one was abble to flash, only had a luck after restoring my gpt backup which I had saved)! So guys do not touch partitions!
Click to expand...
Click to collapse
good to hear that i restored wrong TA partition and had the same problem
how u restored ur TA Files ???
my device is Z1 and i know where is the testpoint
escoda said:
good to hear that i restored wrong TA partition and had the same problem
how u restored ur TA Files ???
my device is Z1 and i know where is the testpoint
Click to expand...
Click to collapse
Huh, I don't know how you can restore TA back to phone! I had broken gpt disk and not TA! Since your TA is broken probably you will need jtag since testpoint method can not restore TA, I don't have jtag pinouts so I can not help you, sorry!
munjeni said:
Huh, I don't know how you can restore TA back to phone! I had broken gpt disk and not TA! Since your TA is broken probably you will need jtag since testpoint method can not restore TA, I don't have jtag pinouts so I can not help you, sorry!
Click to expand...
Click to collapse
is there any way to restore TA with testpoint ???
escoda said:
is there any way to restore TA with testpoint ???
Click to expand...
Click to collapse
Maybe if you have flashtool based TA_backup.ta so maybe you can inject that into fota-reset.ta for example. If you have no these backup we can try to generate them based on your raw ta backup, I think thats not hard generating them!
munjeni said:
Hi! Yesterday I done stupid thing to my phone which hard bricked my phone Played with GPT gdisk, restored wrong gpt backup which killed my device, phone was dead after reboot, had no fastboot, had no bootloader, only had led blinking red-green . But good news I have repaired my phone sucesfully ! Was a bit lucky since I saved my GPT backup so after unbricking I restored my GPT, than restored TA, rebooted and flashed everything normaly. Device finaly booted :highfive:
WARNING TO ALL:
1. DO NOT PLAY WITH FDISK OR GDISK IF YOU NOT KNOW WHAT YOU ARE DOING SINCE YOUR DEVICE WILL BE HARD BRICKED !!! If you mess your gpt table or change them your device can not be flashed using pc companion or flashtool!!! If you brick gpt table than you will notice hard brick, so my segestion is: do not be stupid like me!!! I was very stupid yesterday and done very bad thing to my new phone using these tools.
Searched for about an hour for pins on my phone and finaly found test point pins, hope picture will save your time, nerve and your device! I will not write full tutorial, but if some one need help than please ask here I will help you! ENJOY!
Click to expand...
Click to collapse
Whats is gpt gdisk
munjeni said:
Maybe if you have flashtool based TA_backup.ta so maybe you can inject that into fota-reset.ta for example. If you have no these backup we can try to generate them based on your raw ta backup, I think thats not hard generating them!
Click to expand...
Click to collapse
You can make a TA backup in FlashTool? How? Also, how do you run gdisk on your phone?
If you're not aware about it then don't even bother asking for it cause I'm pretty sure you won't have any proper use of it Regardless it's a partition on your phone.
Riyal said:
If you're not aware about it then don't even bother asking for it cause I'm pretty sure you won't have any proper use of it Regardless it's a partition on your phone.
Click to expand...
Click to collapse
To know something its not necessary that u must need to have some work with it.. And who know what knowledge will be needed in future??
Sent from my Xperia Z1 Compact (D5503)
Riyal said:
If you're not aware about it then don't even bother asking for it cause I'm pretty sure you won't have any proper use of it Regardless it's a partition on your phone.
Click to expand...
Click to collapse
Yeah because it's impossible to learn about new things and everyone knows that those who have any use for it are all born with intimate knowledge about the filesystem on the Xperia Z1 Compact... I'm a curious guy, and believe me I'm quite technical.
So "partition-image.sin" is just a GPT partition map?
Rekoil said:
Yeah because it's impossible to learn about new things and everyone knows that those who have any use for it are all born with intimate knowledge about the filesystem on the Xperia Z1 Compact... I'm a curious guy, and believe me I'm quite technical.
So "partition-image.sin" is just a GPT partition map?
Click to expand...
Click to collapse
Actually GPT partition is so basic that I would assume people without that much knowledge should not touch that part of the phone. I once tried giving knowledge to a basic user here in xda that he decided to do it on his phone and permanently brick it then ended up blaming me lol!
Anyways no! GPT is the same as MBR(Master boot record) on windows OS. GPT means GUID Partition Table which stores the details of the partitions in the device. It is the data which tells the hardware for example that partition 1 = userdata, partition 2 = system, partition 3 = cache and so on.
To make it plain and simple don't use fdisk on mmcblk0 Cause there's another security check in the phone that verifies the partition table.
Riyal said:
Actually GPT partition is so basic that I would assume people without that much knowledge should not touch that part of the phone. I once tried giving knowledge to a basic user here in xda that he decided to do it on his phone and permanently brick it then ended up blaming me lol!
Anyways no! GPT is the same as MBR(Master boot record) on windows OS. GPT means GUID Partition Table which stores the details of the partitions in the device. It is the data which tells the hardware for example that partition 1 = userdata, partition 2 = system, partition 3 = cache and so on.
To make it plain and simple don't use fdisk on mmcblk0 Cause there's another security check in the phone that verifies the partition table.
Click to expand...
Click to collapse
Man next time please quote the user whom u r replying.. Ur text was confusing and I thought u have replied to the peeson who have asked about ta backup using flashtool.. Anyway thank for ur explanation about gpt..
Sent from my Xperia Z1 Compact (D5503)
Riyal said:
Actually GPT partition is so basic that I would assume people without that much knowledge should not touch that part of the phone. I once tried giving knowledge to a basic user here in xda that he decided to do it on his phone and permanently brick it then ended up blaming me lol!
Anyways no! GPT is the same as MBR(Master boot record) on windows OS. GPT means GUID Partition Table which stores the details of the partitions in the device. It is the data which tells the hardware for example that partition 1 = userdata, partition 2 = system, partition 3 = cache and so on.
To make it plain and simple don't use fdisk on mmcblk0 Cause there's another security check in the phone that verifies the partition table.
Click to expand...
Click to collapse
I know what GPT and MBR are, I'm just wondering how you're interacting with the map on mmcblk0. Are you running gdisk on the phone itself, or are you just dd'ing the first blocks of mmcblk0, modifying them on the computer and writing them back?
Also, this whole thing about protecting noob users I don't buy. Give ample warning and if they break their phones then tough ****, nobody learns anything if we're all being treated like a piece of glass.
coolkoushik07 said:
Man next time please quote the user whom u r replying.. Ur text was confusing and I thought u have replied to the peeson who have asked about ta backup using flashtool.. Anyway thank for ur explanation about gpt..
Sent from my Xperia Z1 Compact (D5503)
Click to expand...
Click to collapse
I did ask that initially, haven't had time to check it out myself so an answer to that would be appreciated as well.
Rekoil said:
I know what GPT and MBR are, I'm just wondering how you're interacting with the map on mmcblk0. Are you running gdisk on the phone itself, or are you just dd'ing the first blocks of mmcblk0, modifying them on the computer and writing them back?
Also, this whole thing about protecting noob users I don't buy. Give ample warning and if they break their phones then tough ****, nobody learns anything if we're all being treated like a piece of glass.
I did ask that initially, haven't had time to check it out myself so an answer to that would be appreciated as well.
Click to expand...
Click to collapse
"dd" command on linux won't alter the partition table though... Like you can't dd a 2gb dump into a 1gb partition it would mess up the content of the dump cause allocated data on a disk is scattered throughout random blocks. And yes the only way to alter it is thru gdisk, gparted, fdisk,fsdisk or there might be some other programs other than I mentioned.
Riyal said:
"dd" command on linux won't alter the partition table though... Like you can't dd a 2gb dump into a 1gb partition it would mess up the content of the dump cause allocated data on a disk is scattered throughout random blocks. And yes the only way to alter it is thru gdisk, gparted, fdisk,fsdisk or there might be some other programs other than I mentioned.
Click to expand...
Click to collapse
No but if you run "dd if=/dev/mmcblk0 of=gpt.img count=10" you'll get the first 10 blocks of mmcblk0, which should contain the partition map. That's what I was referring to. Or are you simply running gdisk on the phone itself?
It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Ps : sorry for my bad eng
Sent from my D5803 using XDA Free mobile app
This is flash memory. If they delete it and afterwards send the command to trim or gc then it's gone for good.
The unlocking process is too fast, I do not think they are rewriting the partition. I think they only remove the DRM then dalvik cache / cache and reboot the phone.
But I could be wrong.
I tried different software, they are effective on my SD card.
But my problem is that I do not see the internal hard disk of the phone, so I can not try it.
My phone is boot unlocked. No root / No recovery
If it was possible this would have been done already.
Skickat från min LG-V500 via Tapatalk
I don't talk about "if we can, if it's possible", i talk about doing this, to trying this.
for now, no one has tried.
Being negative without trying, is the best way of failing
dahod said:
It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Click to expand...
Click to collapse
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.
cschmitt said:
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.
Click to expand...
Click to collapse
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?
matapo said:
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?
Click to expand...
Click to collapse
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.
i thought with towelroot you can root without bootloader unlock ? if not, we just need a possibility to root without bootloader unlock and than we can backup the keys ?
yelp, only that needing JUST a way to root without unlock sounds so easy while it's not.
dahod said:
The unlocking process is too fast
Click to expand...
Click to collapse
TA.img is exatcly 2MB, writing 2MB of zeros to flash memory only takes fractions of a second.
cschmitt said:
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.
Click to expand...
Click to collapse
Thanks for the explanation - much appreciated! Hopefully, someone will attempt the 'almost impossible' and find an exploit or two like towelroot, allowing for root access without compromising the bootloader then. Seems like our only option. Sony hasn't made this easy...I can understand why our fellow users are upset.
Just so people don't get confused: that doesn't mean that the DRM keys can be recovered when the phone was already unlocked, but they can be restored if a backup is made before.
PS: and restoring the keys automatically relocks the bootloader which means they can only be used by stock roms iirc. At least that was the case with RomAur I've been using, restoring the keys resulted in a bootloop.
Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app
For the root exploit on the older Z devices, did the exploit work only on certain firmware versions, or could it work on most or all of the versions?
I'm asking this because I've for the notification for a system update, but I've been holding back on installing the update, thinking that perhaps any exploit might be patch in newer versions.
Thanks.
Only specific versions. But it was possible to downgrade, root and then upgrade while keeping root. Towelroot then worked with various versions that used an affected kernel version.
My brain wouldn't let me sleep last night over this (probably stupid) idea:
If /system can be written to by certain tools (correct me if I'm wrong, but afaik you can flash .ftfs with flashtool with a locked bootloader), would it not be easier to find an exploit there (in the .ftfs)?
Much easier said than done, yes, but sounds much easier than finding an exploit in Android, imo.
I guess tampering with an FTF changes its checksum so it cannot be used anymore.
Iruwen said:
I guess tampering with an FTF changes its checksum so it cannot be used anymore.
Click to expand...
Click to collapse
Well yes, you cannot alter an ftf, but what if we somehow made a small img of system and tricked flashtool into tricking it's actually just the system part of an ftf?
Flashtool then flashes the rooted system image and viola, root achieved!
You know, just how Nexus devices have a recovery (factory) image for each partition? Why not make this work?
Ofc just a (probably wayy off) theory, but it seems plausible.
dahod said:
Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app
Click to expand...
Click to collapse
I wouldn't bet on it. The 'issue' has been there since the Xperia Z, the only solution has been to backup the partition before unlocking, else it's gone for good.
Dear readers,
Lets start from the beginning, roughly six months ago:
1) My trusty GT-I9300 died, had two for spare parts but ... SDS;
2) I got a Note 2, got blown off the road and ended up in the canal Phone was soaked, dead;
2) I bought an Xperia Z3+;
3) I unlocked the bootloader;
4) flashed AOSP.
Result: warranty void on day one!
I picked this phone for modability, sadly there are not that any developers active for this device and I have been slowly patching AOSP from Sony with some changes here and there trying to get a CM13 build going. But due to the dive into the water with my car, I have no desktop PC/laptop (both were i7 quad's) and my dualcore iMac makes development kinda tiresome.
Anyway, little did I know that upon unlocking the bootloader my DRM keys would be lost and on that note I did not really care either.
But today I accidentally started working on CM again and figured that the DRM messages about Widevine in logcat should be eliminated. So I looked into solutions, but the DRM "fix" wasn't creative enough (no sources, wtf?) for me and I set my aim on the culprit of it all: the TA partition!
I've probably been looking at it for at least half a day now and hallucinating due to sleep deprivation. BUT, I do NOT believe Sony just scrapped the DRM keys because you unlocked the device. The keys have come from somewhere, and the best thing about keys is: they can be reproduced!
So I have been looking through dumps, comparing things and found out that the keys are most likely "destroyed". I say "destroyed", because I believe there is a good chance of restoring them!
Gory details about the TA partition (post mortem):
CKb keys look like they are "blanked" with:
00XX 0000 0000 YY00
00XX 0000 0000 YY00
(I think XX represents the date (04-02, second of April) and YY represents the time (22:29) when I voided my warranty!
A CKb key is a simple Counter Key, so most likely easily recovered given enough data...
I noticed that there was a SQLite3 database file inside the TA partition, I extracted it and it holds the following data:
CREATE TABLE keytable ( dbAppId BLOB, dbUserId BLOB, dbKeyId BLOB UNIQUE, dbEncKeyType BLOB, dbData BLOB);
Looking at the last column of the table I noticed this:
The first entry = 31
The second entry is 313038
The third 323135
And the fourth 333232...
The dbData column increases with 10097 every time, could it be related to the CKb?
For the rest it looks like everything in the TA partition everything is in fact intact, except for CKb and AUTHCERT="UNKNOWN" for Marlin (not 100% sure if that is present pre-unlock)!
Marlin X509 certificates are intact.
HUK is the Hardware Unique Key, stored on a quite a few places.
Widevine looks intact.
So, why do I focus on the CKb? Simple, look at these reasons:
CBk is used in TLS/SSL authentication (requirement for NEMO (Marlin));
It is used in QSEE. < this is patched with the DRM "Fix";
It can be encoded as RSA and/or SHA1, and is easily verified in SBL with CRC.
TA unlock/lock data is passed as 0x0000000000000000.
If you use 10097 as a CRC polinomal, the last bit of your message changes (in this case your UID for ScubaKey and drm-client swap).
So, my question is:
Is there anyone with a backup of his TA partition that could send me a dump of this folder:
/dev/block/platform/soc.0/<bootdevid>.sdhci/by-name
You can leave userdata, system abd apps_log for what they are. I just want to compare bits spread over the other partitions.
I will need a dump from a locked state and one from an unlocked state where TA is not restored to see what actually gets changed.
You can PM me on the forum or sent an e-mail to my username at gmail.com, I will make you an account on my PC to drop the files!
sfjuocekr said:
Dear readers,
Lets start from the beginning, roughly six months ago:
1) My trusty GT-I9300 died, had two for spare parts but ... SDS;
2) I got a Note 2, got blown off the road and ended up in the canal Phone was soaked, dead;
2) I bought an Xperia Z3+;
3) I unlocked the bootloader;
4) flashed AOSP.
Result: warranty void on day one!
I picked this phone for modability, sadly there are not that any developers active for this device and I have been slowly patching AOSP from Sony with some changes here and there trying to get a CM13 build going. But due to the dive into the water with my car, I have no desktop PC/laptop (both were i7 quad's) and my dualcore iMac makes development kinda tiresome.
Anyway, little did I know that upon unlocking the bootloader my DRM keys would be lost and on that note I did not really care either.
But today I accidentally started working on CM again and figured that the DRM messages about Widevine in logcat should be eliminated. So I looked into solutions, but the DRM "fix" wasn't creative enough (no sources, wtf?) for me and I set my aim on the culprit of it all: the TA partition!
I've probably been looking at it for at least half a day now and hallucinating due to sleep deprivation. BUT, I do NOT believe Sony just scrapped the DRM keys because you unlocked the device. The keys have come from somewhere, and the best thing about keys is: they can be reproduced!
So I have been looking through dumps, comparing things and found out that the keys are most likely "destroyed". I say "destroyed", because I believe there is a good chance of restoring them!
Gory details about the TA partition (post mortem):
CKb keys look like they are "blanked" with:
00XX 0000 0000 YY00
00XX 0000 0000 YY00
(I think XX represents the date (04-02, second of April) and YY represents the time (22:29) when I voided my warranty!
A CKb key is a simple Counter Key, so most likely easily recovered given enough data...
I noticed that there was a SQLite3 database file inside the TA partition, I extracted it and it holds the following data:
CREATE TABLE keytable ( dbAppId BLOB, dbUserId BLOB, dbKeyId BLOB UNIQUE, dbEncKeyType BLOB, dbData BLOB);
Looking at the last column of the table I noticed this:
The first entry = 31
The second entry is 313038
The third 323135
And the fourth 333232...
The dbData column increases with 10097 every time, could it be related to the CKb?
For the rest it looks like everything in the TA partition everything is in fact intact, except for CKb and AUTHCERT="UNKNOWN" for Marlin (not 100% sure if that is present pre-unlock)!
Marlin X509 certificates are intact.
HUK is the Hardware Unique Key, stored on a quite a few places.
Widevine looks intact.
So, why do I focus on the CKb? Simple, look at these reasons:
CBk is used in TLS/SSL authentication (requirement for NEMO (Marlin));
It is used in QSEE. < this is patched with the DRM "Fix";
It can be encoded as RSA and/or SHA1, and is easily verified in SBL with CRC.
TA unlock/lock data is passed as 0x0000000000000000.
If you use 10097 as a CRC polinomal, the last bit of your message changes (in this case your UID for ScubaKey and drm-client swap).
So, my question is:
Is there anyone with a backup of his TA partition that could send me a dump of this folder:
/dev/block/platform/soc.0/<bootdevid>.sdhci/by-name
You can leave userdata, system abd apps_log for what they are. I just want to compare bits spread over the other partitions.
I will need a dump from a locked state and one from an unlocked state where TA is not restored to see what actually gets changed.
You can PM me on the forum or sent an e-mail to my username at gmail.com, I will make you an account on my PC to drop the files!
Click to expand...
Click to collapse
DO NOT USE another xperia devices ta keys on your own device unless you want a nice looking permanent paperweight.
Once you unlock the bootloader without backing them up they are gone forever there's no getting them back.
Sent from my Xperia XA using XDA Labs
aidy.lucas said:
DO NOT USE another xperia devices ta keys on your own device unless you want a nice looking permanent paperweight.
Once you unlock the bootloader without backing them up they are gone forever there's no getting them back.
Sent from my Xperia XA using XDA Labs
Click to expand...
Click to collapse
Exactly and so many times told.
@sfjuocekr
Wrm lees je gwn niet beter man, je kan geen TA van een andere Xperia op jouwe zette, das zo vaak gezegd !
sfjuocekr said:
Dear readers,
Lets start from the beginning, roughly six months ago:
1) My trusty GT-I9300 died, had two for spare parts but ... SDS;
2) I got a Note 2, got blown off the road and ended up in the canal Phone was soaked, dead;
2) I bought an Xperia Z3+;
3) I unlocked the bootloader;
4) flashed AOSP.
Result: warranty void on day one!
I picked this phone for modability, sadly there are not that any developers active for this device and I have been slowly patching AOSP from Sony with some changes here and there trying to get a CM13 build going. But due to the dive into the water with my car, I have no desktop PC/laptop (both were i7 quad's) and my dualcore iMac makes development kinda tiresome.
Anyway, little did I know that upon unlocking the bootloader my DRM keys would be lost and on that note I did not really care either.
But today I accidentally started working on CM again and figured that the DRM messages about Widevine in logcat should be eliminated. So I looked into solutions, but the DRM "fix" wasn't creative enough (no sources, wtf?) for me and I set my aim on the culprit of it all: the TA partition!
I've probably been looking at it for at least half a day now and hallucinating due to sleep deprivation. BUT, I do NOT believe Sony just scrapped the DRM keys because you unlocked the device. The keys have come from somewhere, and the best thing about keys is: they can be reproduced!
So I have been looking through dumps, comparing things and found out that the keys are most likely "destroyed". I say "destroyed", because I believe there is a good chance of restoring them!
Gory details about the TA partition (post mortem):
CKb keys look like they are "blanked" with:
00XX 0000 0000 YY00
00XX 0000 0000 YY00
(I think XX represents the date (04-02, second of April) and YY represents the time (22:29) when I voided my warranty!
A CKb key is a simple Counter Key, so most likely easily recovered given enough data...
I noticed that there was a SQLite3 database file inside the TA partition, I extracted it and it holds the following data:
CREATE TABLE keytable ( dbAppId BLOB, dbUserId BLOB, dbKeyId BLOB UNIQUE, dbEncKeyType BLOB, dbData BLOB);
Looking at the last column of the table I noticed this:
The first entry = 31
The second entry is 313038
The third 323135
And the fourth 333232...
The dbData column increases with 10097 every time, could it be related to the CKb?
For the rest it looks like everything in the TA partition everything is in fact intact, except for CKb and AUTHCERT="UNKNOWN" for Marlin (not 100% sure if that is present pre-unlock)!
Marlin X509 certificates are intact.
HUK is the Hardware Unique Key, stored on a quite a few places.
Widevine looks intact.
So, why do I focus on the CKb? Simple, look at these reasons:
CBk is used in TLS/SSL authentication (requirement for NEMO (Marlin));
It is used in QSEE. < this is patched with the DRM "Fix";
It can be encoded as RSA and/or SHA1, and is easily verified in SBL with CRC.
TA unlock/lock data is passed as 0x0000000000000000.
If you use 10097 as a CRC polinomal, the last bit of your message changes (in this case your UID for ScubaKey and drm-client swap).
So, my question is:
Is there anyone with a backup of his TA partition that could send me a dump of this folder:
/dev/block/platform/soc.0/<bootdevid>.sdhci/by-name
You can leave userdata, system abd apps_log for what they are. I just want to compare bits spread over the other partitions.
I will need a dump from a locked state and one from an unlocked state where TA is not restored to see what actually gets changed.
You can PM me on the forum or sent an e-mail to my username at gmail.com, I will make you an account on my PC to drop the files!
Click to expand...
Click to collapse
I really have to admit that this is hearing very interesting, how you got all extracted? When I had my ta.dd from TA partition of my ZU I couldn't extract anything and I also tried to search a bit about the TA partition, where I was 100% sure was that 1 line is cause for UB able or not (was something with rooting_allowed).
The problem is I don't like so much to share the TA partition because I think u know there is the IMEI inside and with that u can do.... Some bad things for the phone
When I get my Z5P on Christmas I will take a look on it too
What I can do is to give u the databases u need from the TA partition now if u tell me how u extracted them because I seem to be too stupid for that xD
Thanks already for your efforts
Your PDesire
I found a whole collection of interesting things
If you have a backup from before unlocking the bootloader and one after, that would be great to study which bits have changed.
And to the two morons who can not read or did not read, I am NOT planning to flash someone else his TA partition. I just want to analyze it! Je kunt het ook nog zo vaak zeggen, maar ik ben dat niet van plan.
I know that the whole key set is "bound" to your device, namely because it uses a set of "counter keys" for SSL. I have ran so many hashes over "interesting" things found in the partitions, but have yet to strike that illusive "10097" that is being added to the SQLite3 DB INSIDE the TA partition.... It has to come from somewhere, the only bits that are repeating in the file are what I translated into the date + time that I flashed my phone, which is right on the money.
So if that 10097 is indeed a "left over" from the handoff between SBL1 and S1SBL, evidence for this comes from the S1SBL itself:
"Something" from "somewhere" is compared against the HW and SW keys (SHA1 + SHA256) in S1SBL, which is likely saved as a cookie in SBL1. SBL1 also mentions a SHA1 and SHA256 routing, but also this:
DDR: Computed CRC checksum retrieved from flash is %d
DDR: Checksum to be stored on flash is %d
DDR: Checksum on flash is %d
DDR: Recomputed checksum is %d
DDR: The serial number is %d
Hey, there is finally that CRC reference (actually further up in the blob)!
So until I have a good specimen to study further, I'm guessing that the SBL1 calculates the CRC that goes into the SQLite DB with two other keys keys and a "dbEncKeyType".
But I simply do not know, as what I have on those CB spots is 04-02 @ 22:29! The day I got my phone, and did not visit a friends birthday because I "forgot to go" (please, don't tell her )!
It might just be a dumb coincidence, but it would not be the first time multiple layers of security have been put up ... just to be broken by a guy (or girl) who looked the wrong way at the right time! In my case I noticed repetition on a few places while scrolling through the partition dumps!
Besides, I don't even care about the DRM keys at all. I am using an AOSP build on my phone which is able to record phone calls and plays Pokemon GO just fine. Snapping a photo is problematic, unless you like the #nofilter effect of a busted CRT! Had not checked dev progress on the Z3+ at all lately, which is still nowhere to be found, and I decided to take a stab myself.
Also if you look at the data in DDR it contains three values @ 0x800, 0x8e0 and 0x980. Some ones and two, some sequential data but nothing that jumps out at me....
Until I spotted the CRC check in S1SBL.
This is the "10097" column I was talking about:
31303731
31313738
31323835
31333932
31343939
31363036
31373133
31383230
31393237
32303334
32313431
32323438
32333535
32343632
32353639
32363736
32373833
32383930
32393937
33313034
33323131
33333138
33343235
33353332
33363339
33373436
33383533
33393630
34303637
34313734
34323831
34333838
34343935
34363032
34373039
34383136
34393233
35303330
35313337
35323434
35333531
35343538
35353635
35363732
35373739
35383836
35393933
36313030
36323037
36333134
36343231
36353238
36363335
36373432
36383439
36393536
37303633
37313730
37323737
37333834
37343931
37353938
37373035
37383132
37393139
38303236
38313333
38323430
38333437
38343534
38353631
38363638
38373735
38383832
38393839
39303936
39323033
39333130
39343137
39353234
39363331
39373338
39383435
39393532
Click to expand...
Click to collapse
Of which I first thought the response to one of the Marlin certs would be significant, but that does not make sense for a bootloader handover which can end at: IGNORE_CRC
sfjuocekr said:
"Something" from "somewhere" is compared against the HW and SW keys (SHA1 + SHA256) in S1SBL, which is likely saved as a cookie in SBL1. SBL1 also mentions a SHA1 and SHA256 routing, but also this:
Click to expand...
Click to collapse
Which I know ta contain RCK_H (which is sha1 hash), that hash is something like:
sha1("your unlock bootloader key");
unlock bootalader key is stored in 0x8B2 ta unit.
I am more interested where PBL lives, do you have idea where is it stored?
Have not had much time to look at it over the past days, but you will need to solder on a JTAG interface to get the PBL to execute the boot process in secure again (it is a fuse).
The chipset probably has a GPIO PIN you can force high to get back into secure too.
The PBL is stored in ROM, not on flash.
dont bother with warranties.. they do not check for bootloader until or unless you have modified firmware installed... i had got my d6653 repaired twice.. else if you need your bravia engine etc, you can flash kernels with drm fix included..
Do not blindly flash this device without knowing what you are doing. While the device is hard to brick in general, it is very easy for someone new to brick it by flashing the wrong partitions.
I will write a generalized tutorial that will cover the basics and hopefully make everyone feel better about flashing the device. At first I was skeptical but after understanding everything, I have to say it really isn't that bad, and I am here doing all the leg work for these fake 2gb (its really 1gb ram) and 16gb hdd
OK I am goin gto try and put all of this information in one place because these units say android 10 or 10.1 but in reality cpu-z they are android 9 with api of 27 (will double check to be sure. This unit says it is 2gb ram but it is indeed 1024 MB (q GB). I am not sure if the other custom firmwares dumps from 1gb yt9213aj models will work without problems on these yt9213aj units that say 2gb.
In order to try anything you need to first make a scatter file for your unit. I messaged the manufacture of my unit for a firmware and they sent it. I unzipped it and looked at the scatter file and it is of a different formatting than one that comes from mtk droid tool.
So, mtk droid tool doesn't work with OS versions 9 or higher. It is the problem of adb. But we can follow this guide https://forum.xda-developers.com/t/...not-revealed-error-in-mtkdroid-tools.3582571/ and get it to work.
Once you have your device connected and recognized in droid tools you should first create the scatter file, as this is the most important step to do a full readback in SP flash tools.
Once you have a backup, you are in the clear for the most part. I am still trying to figure out how to backup preloader and etc if possible.
Now you will also need to connect some kind of wire or some small buttons taken from something disassembled. Just something that you can use as a mock button because there is no hardware button on the device for up/down and OK and you cannot use the touch buttons. So you need to short these traces while in recovery in order to get further/
The main point of this thread is to update the existing ones and to add tools and stuff nmeeded in one location because it has taken me over 5 days to search for all fo this, and I am still not done, so lets make it a little easier on the new comers because the last thing we want to do is brick each others devices by using old outdated guides that don't fully work.
Flow chart of process: install mtk droid tools and sp flash tools ->enable oem debugging and oem unlock on device -> follow guide to get mtk droid tools to work -> get scatter file using mtk droid tools -> make a full readback in sp flash tools -> solder wires/buttons onto test points -> boot to fastboot and unlock bootloader -> fastboot flash recovery <image name> -> boot into recovery and install root and/or custom firmware.
Anyone more skilled knows any better?
This post is a WIP and will be updated periodically as I source information. The main idea behind this post is to bring all resources for yt9213aj in one spot. There is plenty of information, its just very hard to navigate especially for someone new to flashing these devices, and even worse to someone who has never flashed any device
OK after trying what seems like 300 twrp's I finally found one that does work with this device. I thin kthe main difference here is that the board is a new revision and some arch changes caused older version that were ported to not work. This one booted right into it but was in russian, which is easily fixable within the twrp gui.
I will add all of these files to the op when I have collected everything.
I do not think that this version board I have has hifi? Maybe I am mistaken? I have an audio glitch at 19-20 when playing music, the sound will get louder and sound good for a fraction of a second then return to sounding ****ty. So I will look into this more. What sucks is that there are so many of the same **** that doesn't work for this model so its like... I would rather garggle gasoline than have to sift through forums that were translated on the fly
Anyway here is the twrp for this particular device - https://www.dropbox.com/s/vogg7854a7ln2zu/twrp-9213aj.img?dl=0
EDIT: also you can boot to fastboot (adb reboot bootloader) and use fastboot getvar all to get factory partition sizes that's needed to create scatter file (you will need to use a hex calculator to create it, or wait for me to upload my scatter file once I have it done). You need to be making dumps in sp flash tool way before you are ever writing anything. Make plenty of readbacks and get to know how to read it before you write anything. Blindly flashing is not what you really want to do lol
Mtk drivers for pc
to install, you will need to disable signature verification and I had to turn on test signing as well
I have successfully rooted this thing. I did encounter something kind of strange though. When I patched the boot.img I had from the device and the one I got in ota update and patched with magisk. When I booted and checked the root with magisk it said there was an unsupported root using su already. It did this for both boot.imgs.
Anyone ever heard of this on stock firmwares? I am able to grant root permissions to busybox and etc so it seems to be working OK. Maybe the root that is there is the chinese root for backdoor tracking and surveillance xD
Wonder how to see what unsupported su commands are being sent?
EDIT: i also took a lot of pictures of the board. It is yt9213aj v1.2 board. I will update the original post in the few days with everything needed for this model including testpoints etc. The test points are a little different but its pretty much the same. The only two you need in the end are the two bigger ones (for unlocking bootloader) then your set. You could drill some holes and run wire down to the trace and put some hardware buttons for the mcu to use to select things in fastboot and official recovery.
There is also another port/connector on this thing above the touch sensor board. I think we could buy a ribbon cable to connect here and run it to another board with hardware button. Actually I think the connector is for hardware buttons specifically but I don't know for sure. Must do more research
These things have are rooted from the factory. When I try to use magisk it says there is another unsupported su. The Unsu.zip floating around cures that. Then you can install magisk.
Also another thing about these things being prerooted... I think you can dump and flash without any extra sp flash tools or mtkdroid. I was dumping the partitions using adb pull function. Adb pull /dev/block/platform/soc/11230000.mmc/by-name/<insert partition name here>"
And
"/dev/block/mmcblk0pxx" where xx is the specific partition to read/write to.
I had got a scatter.txt in the ota update I obtained from the manufacturer which had all the partition layouts. I used this and a log from a failed supersu.zip install to create a scatter.txt for this particular device. The supersu log can be obtained by trying to flash the supersu zip in recovery, then in adg just pull the log file adb shell cat /tmp/recovery.log. Once you have this, you will have to use brain.exe to make your own scatter for sp flash tools.
All in all its pretty easy to actually root the device, and they are actually rooted from the factory, most likely for some functions within the os to work (like surveillance and spying xD) but that can easily be removed with the unsu.zip then install magisk.
I will be writing up a guide for this specific model in a few more days. If you read this thanks for listening to the rumbling of a mad man
Just discovered another problem. When I try to edit anything in /system it says its read only. Mounting is or remounting it shows as successful with no errors, but something is blocking it from mounting as system. I am trying to rename this audio_effects.conf and it willnt let me. I think it might be some proprietary code in the kernel designed to block mounting or remounting of certain or all partitions.
I think that a lot of them are software locked, like the fader and balance and volume level. Notice how some of these have glitches when turning the volume up and down. I think that there is some code that disables some functions of higher end units, depending on the model. If you buy a cheaper 100 dollar head unit, maybe it is indeed just software locked down.
I know for fact the amp chip in my head unit, YD7388, sec sheet says 4 channel. But my device is only 2 channel, no fader. Also the spec sheet says it needs no output capacitor but mine has one I think (there is a huge capacitor soldered next to the chip. I have some pics of the board and test points and chip markers etc. Once I have everythign ready I will make a nice guide
Wow I think I found the reason this thing outputs as 2 channel on 4 speakers. I need someone with a real 4 channel version to message me so I can get a few files for comparison. If this is the case, a simple magisk module would fix the fixed 2 channel problem we have. In the audio_policy_configuration.xml they have all output set as
XML:
<devicePort tagName="FM Tuner Out" type="AUDIO_DEVICE_OUT_FM" role="sink">
<profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
samplingRates="44100" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
</devicePort>
I wonder if you set AUDIO_CHANNEL_OUT_STEREO to multichannel or maybe like "AUDIO_CHANNEL_OUT_QUAD " as described in the official android docs say, I wonder if that would enable true 4 channel (or 5.1)?
If someone who has a 4 real 4 channel stereo and it is around the model of yt9213aj, then send me a message so we can collaborate. If you are not rooted do not worry I will help you