[VIDEO] Xperia Z1 TA backup (DRM keys) - Xperia Z1 General

Here is a video highlighting the TA Backup process with all the basic questions answered. If you have any more questions do let me know

Related

EVERYTHING you need to know about backing up your PPC

Hey people, make sure you don’t miss my latest article on EVERYTHING backup-related – the latest information on the current backup applications, a lot of tips & tricks etc.
It’s available at http://forum.xda-developers.com/viewtopic.php?p=366977
(Sorry for cross-posting the link to this forum; I just want to make sure no one misses the article just because it’s posted to a different forum on this board.)
Article slightly updated:
- I’ve elaborated a lot more on SKTools + WM2003(SE) password protected Dell Axim scheduled backup problems
- I’ve added a discussion of PDA-based and desktop-based restoration
- Added some discussion & tips on keeping multiple backup files on the same PDA for FSC Backup users
- Added some new discussion links
I use Sprite Backup.
Don't have to worry about anything.
I backup with it alot and have restored several times from it.
NO problems. 8)

Step-by-step guide for turning NST to a fully fledged Android e-reader

I purchased a Nook Simple Touch during Black Friday for $40 from Sears. The first step for me is to learn from XDA Nook forum on how to root the device. There are lots of posts and confusion is inevitable for a newbie like me. Finally I figured out what's the best approach and rooted the device quite successfully.
To save time and effort for those newbies like me, I think I shall share what I learned and what I tested here. Therefore, I wrote a post on my personal blog and the link is below:
Step-by-step guide for turning NST to a fully fledged Android e-reader
The tutorial covers:
COmplete backup and restore of your NST
Root
Multi-touch and NoRefresh improvements
The main XDA posts from which I learned a lot are:
http://forum.xda-developers.com/showthread.php?t=1346748
http://forum.xda-developers.com/showpost.php?p=22800284&postcount=10
The authors of these posts are greatly appreciated!
Enjoy your rooted NST!!!
hi, thanks for the easy guide! one correction though, on step #2 of the actual rooting process, you mention "sdcard,XUFullTouch-PART-1-START.zip" twice instead of using the END zip.
thanks for your blog it will help since the information in this forum can be harsh to gather.
But it is necessary to add a step: Check the backup before the step #3
a lot of noobs (included me) fall into the trap of a wrong backup (76Mg instead of ~2G).
The purpose of the backup is to come back to something safe. There is already another blog that details everything to root, but omits to check the backup.
You need to add a section to check if the backup is correct:
- size (must be more than 1,8G,
- must contains 8 partitions
- must have the rom partition with the serial
some people here in this forum gives the procedure for all of this. What we need now is an updated procedure and your blog could be the beginning and then the wiki of xda should be also modified.
I get an acess denied when I try to use the link you give

[DANGEROUS TOOL][DO NOT USE!][READ FIRST!!!] Trim Area Tool

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?

I think I found a way to get DRM keys

Hey guys, so as the title states, this is a method in which we can possibly obtain DRM keys from NAND (UFS 2.1). This of course will be pulled off with a locked bootloader.
Here's the method:
1. Extract NAND from Xperia XZ Premium (or any DRM-locked phone) via desoldering.
2. Use a NAND chip reader to dump the contents of the NAND chip.
3. Analyse contents and find DRM keys.
We'll be requiring the following:
1. A donor phone (or a spare NAND)
2. NAND chip reader
But there are some obstacles:
1. FDE is enabled by default, we'll need to find a way to decrypt the data
What are your thoughts guys, is this even possible?
Hmm, interesting idea, but according my understanding it will not work because each DRM key is slightly different. What you need is to find the location of the DRM key in the NAND so it can be backup some way
Wow good idea! .but if we can make universal drm key? Its possible ?
thipok17 said:
Wow good idea! .but if we can make universal drm key? Its possible ?
Click to expand...
Click to collapse
No
PM_ME_YOUR_TATAS said:
Hey guys, so as the title states, this is a method in which we can possibly obtain DRM keys from NAND (UFS 2.1). This of course will be pulled off with a locked bootloader.
Here's the method:
1. Extract NAND from Xperia XZ Premium (or any DRM-locked phone) via desoldering.
2. Use a NAND chip reader to dump the contents of the NAND chip.
3. Analyse contents and find DRM keys.
We'll be requiring the following:
1. A donor phone (or a spare NAND)
2. NAND chip reader
But there are some obstacles:
1. FDE is enabled by default, we'll need to find a way to decrypt the data
What are your thoughts guys, is this even possible?
Click to expand...
Click to collapse
Anythings possible, but this is probably impossible for 99.99% of users. As someone said above, TA keys are device specific. If you flashed my TA backup to your handset, you would have a pretty paperweight.

[Help] FSC script found, do you want to add it?

Hi,
Please be kind to answer a few queries below.
Here is what I did (and fear may have done something incorrectly):
So I downloaded a firmware using latest flashtool (0.9.25.0)
Then following advice here I deleted the fwinfo.xml file
Then during Tools=>Bundles=>Create, skipped all TA files (again following advise on above link)
When flashing the generated ftf file I got a pop-up saying FSC script found, I clicked Yes -- this thread shows screenshot
The flashing went fine. It was Orea Central Europe CE1.
---
Now about to flash Pie, I opened the fsc file before doing anything and it has steps like:
Code:
Write-TA:2:2212
Write-TA:2:2316
Write-TA:2:2330
Write-TA:2:2473
Write-TA:2:2486
Write-TA:2:2553
flash:LTALabel:elabel-H8216-row-demo_201803120045218.1_51.1.A.2.183_X-FLASH-LTALABEL-B6B5.sin
set_active:a
Write-TA:2:10021
Write-TA:2:10100
This worried me.
Q 1: What happened when I flashed Oreo, and the FSC script ran these commands? Did it wipe/write zeroes to the TA DRM keys?
Q 2: If I am safe, and my TA keys are OK, how do I check? My Service Menu=>Service Tests=>Security is attached
Q 3: In Service Menu=>Configuration the part about Available Speech Codecs is missing (please see screenshot) -- I see it in my Z3c, but not in my XZ2 now (not sure if it was there before I flashed Oreo)
Q 4: When I now flash Pie, should I skip FSC when prompted as this guy says for M2?
Why you not use newflasher ?
Okay I just heard its name the second time. I'll read and try it.
But any comment to my questions? Anything odd in screenshots? Have I messed up?
Pandemic said:
Why you not use newflasher ?
Click to expand...
Click to collapse
Something to be concerned about Newflasher?
arslanon.e said:
Something to be concerned about Newflasher?
Click to expand...
Click to collapse
No work like a charm.
Pandemic said:
No work like a charm.
Click to expand...
Click to collapse
Thank you, and with your experience, can you tell if my DRM keys are intact?
Is it normal that Speech Codecs part and the missing extries for SOMC Fido and SOMC Attest keys?
Or is it that you don't know?

Categories

Resources