Related
Hi all,
Has anyone followed Rayman's excellent article the-inner-workings-of-secure-boot-key-and-nvflash and fully recovered a N7 from APX only mode?
I have this situation which I think resulted from the battery dying during the 4.4.2 update - Doh I know, but thought I had enough juice to complete the update.
Rayman says the required files will be made available but I cannot find them anywhere
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Erovia said:
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Click to expand...
Click to collapse
Did you read the article? Sounds like you can use the sbk which is a hash of the cpuid...
Nope, but why don't you ask around in the flatline topic?
Erovia said:
Nope, but why don't you ask around in the flatline topic?
Click to expand...
Click to collapse
too much of a noob to post on the forum, but thanks for the pointer.
FYI Raymans article. It does sound possible to bring it back, but there was no follow up with the required files;
What is Secure Boot Key and how does it work?
I've been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It's a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more "secure".
When the SBK is set, it's stored in a one-time-programmable "fuse". This also means that now that the key is out, they can't change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.
So what happens when it boots into APX/Nvflash mode?
The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that's not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded "0x4" error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won't be available. I'm still not entirely sure why (and I can't rule out it will change).
What *is* available, is the nvflash --create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.
So what do we need for nvflash?
In order to get a working (e.g. --create) nvflash, we need a few bits of information as well as some files:
◦Secure Boot Key
◦BCT file (boot device setup, ram configuration and a bit more)
◦ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
◦flash.cfg (e.g. list of settings and names/identifiers of partitions.
On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools
The first four peices aren't readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don't expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.
I hope this helps give a better understanding of how and what secure boot key is and what it gives us.
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.
This guide is for those who have lost their IMEI, have corrupted EFS, or erased EFS partition. So, follow these under your own risk, it may or may not work, and if something happens or doesn't happen, then i am not to blame. So, once again i will not take credit for bricked phones or something along those lines, however i will take full credit if this works for you. I will also provide assistance to those who could not restore their EFS following this guide.
Before proceeding with this guide, backup what you have left. Use twrp to backup and in case something goes wrong and your problem escalates, you can restore using twrp backup.
Restore EFS
Change IMEI Number
Restore EFS
Do this if and only if you believe your EFS is corrupted, or you somehow erased it. If you are not sure about it, then simply follow the next guide to change you IMEI number. In most cases people loose their IMEI only and not the whole partition. Again, it may or may not work, so do this on your risk, and i am not to blame if anything bad happens, but if you do succeed, then don't forget to give me credit.
Note:
If your EFS is erased or corrupted, your IMEI and Baseband will be shown as unknown. In this case recover the EFS following this post, and then change the IMEI following the next post. If your IMEI is shown as 0, then you EFS is safe and most probably your IMEI is gone. In that case, no need to recover EFS, only change the IMEI number following my next post.
In TWRP, backup of kate wont show on kenzo and the backup up kenzo wont show on kate. In case no backup is shown even if you are using the right device, then try the dump flashing method or try changing the TWRP recovery.
Flashing this will only restore your EFS partition, but the IMEI will still be gone, so you will have to follow the next guide to change your IMEI.
Even after flashing a new EFS, you Mac and BT address will not recovery. The android system will assign a software generated address to both devices. Dont worry cause even without the EFS partition there will be a Mac and BT address assigned to your device and both the things will work normally.
If your Baseband is still unknown, even after flashing a new EFS, then try flashing latest radio file. It can be found in any firmware update package, either the official or the one from the strix.
1. Download the required files from the link given below.
EFS Backup[Kenzo] - Contact me if someone has backup of this.
EFS Backup[Kate] - Contact me if someone has backup of this.
2. Extract the Dump Backup files and flash them using the following commands.
Code:
fastboot flash modemst1 modemst1
fastboot flash modemst2 modemst2
3. Now reboot and voila you have you a new EFS partition at your disposal.
Change IMEI Number
Requirements:
Root
USB Debugging is turn on
Windows Driver Signature is turned off
ADB and Fastboot Binary Files
Latest MiFlash Installed for the latest drivers
1. Connect your device to pc and open the adb folder. Then open a command promt window.
Code:
>> [B]Shift + Right Click[/B] anywhere in the adb folder
>> Click on [B]Open Command Window Here[/B]
2. Type the following command to enable Diagnostics mode. Allow debugging if asked.
Code:
adb shell
su
setprop sys.usb.config diag,adb
4. Download the IMEI Changer from the link given below.
IMEI Changer [Credit: Archeolot]
5. Now, open the imei changer, and enter imei number in both the fields. And click on start. After a moment it will show as passed. If it fails make sure that you have followed the points i stated.
Note: Make sure that the driver in driver management under ports is listed as "Qualcom HS-USB Android DIAG 901D" and not as "Marshall London HS-USB Android DIAG 901D". If it is listed in any other name, then go to driver management and update driver. Select browse driver, then let me pick driver from a list. Then select "Qualcom HS-USB Android DIAG 901D" and then finish.
WOW.. Thanks mate..
It's gonna very Helpful for me & other ppl.. ??
Sent from my Redmi Note 3 using Tapatalk
didn't work..
showing error as no diag even after typing those commands
kindly help me
nuk.nama said:
showing error as no diag even after typing those commands
kindly help me
Click to expand...
Click to collapse
At what part, the imei change or flashing.
The simplest, and the fastest guide to restoring EFS and IMEI! I haven't backed up my EFS and this revived my phone! Much apprecieated!
Broski32 said:
The simplest, and the fastest guide to restoring EFS and IMEI! I haven't backed up my EFS and this revived my phone! Much apprecieated!
Click to expand...
Click to collapse
Glad i could help mate. Can you confirm your mac address and bluetooth address, whether it is same or changed.
archit.bajpai.ab said:
Glad i could help mate. Can you confirm your mac address and bluetooth address, whether it is same or changed.
Click to expand...
Click to collapse
Can't confirm. My EFS partition was so corrupted from trying other tutorials to restore my IMEI that I didn't even bother backing it up because I thought that it could have been changed already (tried writing to NVRAM with QPST). Since I don't have my original mac and bluetooth addresses written down anywhere (I haven't written them down myself and I don't think they are to be found anywhere on the box or on the phone) I think the only way to check it would be to compare my current addresses on the phone to the addresses contained in your EFS backup. Can you extract them so I can check if they match or not?
Broski32 said:
Can't confirm. My EFS partition was so corrupted from trying other tutorials to restore my IMEI that I didn't even bother backing it up because I thought that it could have been changed already (tried writing to NVRAM with QPST). Since I don't have my original mac and bluetooth addresses written down anywhere (I haven't written them down myself and I don't think they are to be found anywhere on the box or on the phone) I think the only way to check it would be to compare my current addresses on the phone to the addresses contained in your EFS backup. Can you extract them so I can check if they match or not?
Click to expand...
Click to collapse
The mac address and bluetooth address in the efs are my own. I only changed the imei so that no one else can copy it, i didnt know anyway to change mac address. Besides the mac address doesnt matter that much, and i dont think that we will ever be on the same wifi network.
If you dont know then i can explain, that the mac address is required to maintain switches and broadcast in the router, so it technically does not matter.
You can change it later with some apps or use it like that if you wish, if i find any way to restore you mac i will post it too. In the mean time just post a snapshot of wifi mac and bluetooth address so that i can compare them with my own.
So, using this way, one can change the IMEI no. also?
mGforCe said:
So, using this way, one can change the IMEI no. also?
Click to expand...
Click to collapse
Yes, just use the imei changer in the rar file to change your imei. But make sure to backup or atleast note down your imei before doing so.
archit.bajpai.ab said:
The mac address and bluetooth address in the efs are my own. I only changed the imei so that no one else can copy it, i didnt know anyway to change mac address. Besides the mac address doesnt matter that much, and i dont think that we will ever be on the same wifi network.
If you dont know then i can explain, that the mac address is required to maintain switches and broadcast in the router, so it technically does not matter.
You can change it later with some apps or use it like that if you wish, if i find any way to restore you mac i will post it too. In the mean time just post a snapshot of wifi mac and bluetooth address so that i can compare them with my own.
Click to expand...
Click to collapse
Current addresses on my phone:
MAC - 00:0a:f5:a9:XX:XX
Bluetooth - 7C:7F:F0:82:XX:XX
Left out some numbers just in case they are mine. For the purpose of checking that will still be enough
Broski32 said:
Current addresses on my phone:
MAC - 00:0a:f5:a9:XX:XX
Bluetooth - 7C:7F:F0:82:XX:XX
Left out some numbers just in case they are mine. For the purpose of checking that will still be enough
Click to expand...
Click to collapse
Yup, they are not mine. Mine start with 64:cc and so on for both mac and bluetooth. They may be software generated or may be your own, technically i am not sure.
Edit: did you use imei changer to change imei no. Or are you using the default values. If you are using the default values, pls post them too. If you change them, then give your review, ie was it hard or easy, did you encointer any problem, stuff like that.
archit.bajpai.ab said:
Yup, they are not mine. Mine start with 64:cc and so on for both mac and bluetooth. They may be software generated or may be your own, technically i am not sure.
Edit: did you use imei changer to change imei no. Or are you using the default values. If you are using the default values, pls post them too. If you change them, then give your review, ie was it hard or easy, did you encointer any problem, stuff like that.
Click to expand...
Click to collapse
After flashing your EFS backup both IMEI values were set to "0". On the default values I don't think the phone would be able to register on any network with the sim inside, but I haven't tried that. Then I flashed my IMEI with the app you provided in the .rar. Set my IMEI same for both slots because I've got only one written down on the box so I think it is set how it should be out of the box. After that I've rebooted to EDL and flashed global developer rom. And it's all working, I'm able to make calls from both sim slots, however didn't try having 2 sims inside.
All in all the process is very easy, definitely the easiest out there. I haven't encountered any problems, however I think others may have a problem with drivers to get "Qualcom HS-USB Android DIAG 901D" working. Mine was working already because I tried this tutorial before. Thank you for this guide, and providing your backup
Broski32 said:
After flashing your EFS backup both IMEI values were set to "0". On the default values I don't think the phone would be able to register on any network with the sim inside, but I haven't tried that. Then I flashed my IMEI with the app you provided in the .rar. Set my IMEI same for both slots because I've got only one written down on the box so I think it is set how it should be out of the box. After that I've rebooted to EDL and flashed global developer rom. And it's all working, I'm able to make calls from both sim slots, however didn't try having 2 sims inside.
All in all the process is very easy, definitely the easiest out there. I haven't encountered any problems, however I think others may have a problem with drivers to get "Qualcom HS-USB Android DIAG 901D" working. Mine was working already because I tried this tutorial before. Thank you for this guide, and providing your backup
Click to expand...
Click to collapse
Enjoy your revived phone buddy.
Thanks buddy!!!!! you saved my phone
pandyajoe said:
Thanks buddy!!!!! you saved my phone
Click to expand...
Click to collapse
It do what i can do buddy...
Guys. I messed up my phone by restoring a nandroid backup from a different one.
I was able to restore my IMEI using some qualcomm tools. My problem now is that fingerprint scanner won't work on any rom, even official.
Any idea what else I have messed Up? I don't think restoring this efs will fix my fingerprint scanner. Is fingerprint scanner info in a different partition?
chr0m said:
Guys. I messed up my phone by restoring a nandroid backup from a different one.
I was able to restore my IMEI using some qualcomm tools. My problem now is that fingerprint scanner won't work on any rom, even official.
Any idea what else I have messed Up? I don't think restoring this efs will fix my fingerprint scanner. Is fingerprint scanner info in a different partition?
Click to expand...
Click to collapse
Have you checked with miui7 stock rom. As far as i know there are three sensor modules for fingerprint, on of them is goodfix which is currently not supported by many roms. If your is goodfix then it will not be supported too. You can flash miui rom to check whether the fingerprint works or not...
If it doesnot work, then try to resotre your nandroid backup agaian. This tym simply untick efs.
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..
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?