Database Users

[Q] Bootloader 2.3.15

So, anybody knows any rumors, or facts about new moto bootloader to be cracked anytime soon?

*chirp chirp*

@nenolod from twitter has just now-ish posted a link to the documentation to the secure boot platform. Some of his other tweets from tonight:
"@_mrbirdman_ working theory is that the efuse trigger value is a permutated form of the boot block md5sum. (toasted against private key?)"
"ok, the source code basically proves that the IPL ROM guards mbmloader with a *static* sha1sum permutated in some way."
"this means that we can replace mbmloader with an ENG patched mbmloader once we know the permutation value, which is a matter of bruteforcing"
And lastly
"we've decided to establish an IRC channel for unlocking these motorola devices: irc.freenode.net #sholesunlock"
This guy was working closely with birdman to get the bootloader cracked for a while (at least until the 2.2 OTA came out, when moto screwed everything up with the key changing). It looks to me that they have something real going on again.

clubsilencio said:
@nenolod from twitter has just now-ish posted a link to the documentation to the secure boot platform. Some of his other tweets from tonight:
"@_mrbirdman_ working theory is that the efuse trigger value is a permutated form of the boot block md5sum. (toasted against private key?)"
"ok, the source code basically proves that the IPL ROM guards mbmloader with a *static* sha1sum permutated in some way."
"this means that we can replace mbmloader with an ENG patched mbmloader once we know the permutation value, which is a matter of bruteforcing"
And lastly
"we've decided to establish an IRC channel for unlocking these motorola devices: irc.freenode.net #sholesunlock"
This guy was working closely with birdman to get the bootloader cracked for a while (at least until the 2.2 OTA came out, when moto screwed everything up with the key changing). It looks to me that they have something real going on again.
Click to expand...
Click to collapse
Hope...............is in the air!

http://nenolod.net/~nenolod/sholes/README

Excellent post, InfamousDX. Really informative read. May take a partial college degree in Electrical Engineering, or some googling to understand though
Glossary:
NVRAM = Non Volatile Random Access Memory
A form of ram on the phone which persists when the phone is powered off
MBM magnetic bubble memory (i think)
a nonvolatile storage device that holds information in the form of bubbles on a thin film of magnetic silicate; no longer used in most computersnon-volatile storage, nonvolatile storage - computer storage that is not lost when the power is turned off
The idea is... there's a piece of software that is in the phone's flash memory which resides outside of the normal phone's operational space (ie, you can't see it in ADB) which loads the operating system and kernel when you boot. This piece of software checks one (or more) bytes of "checksum" when loading.
The checksum that it checks is part of a signature mechanism. Each ROM must be signed. It is mathematically hard to fake the signature because it uses private key cryptography, where only the person knowing the private key can sign things. The brute force space is too huge for today's computers to crack.
Back to the idea. The idea is to change the checksum in the NVRAM so that it accepts all signatures. 0x00 and 0xFF are sort of special values, depending on what the algorithm they use to check the checksum. 0xFF => dec 255

Tab SBK burning logic in boot loader and other thoughts

After stupidly doing OTA update and getting SBK flashed on my tab I have been analyzing what how it happened. I figured I would put info here in hopes it might help someone else. Now this is basically my theories based on analysis of the bootloader code. I could be 150% wrong, Caveat emptor.
Useful resource was the Uboot git repository that has some Tegra 2 support:
git.denx.de/?p=u-boot.git;a=summary
Also Ac100 kernel tree gave some insight into fuse logic:
gitorious.org/ac100/kernel/trees/cd81507c9c1075b363f5af1222fa93deee09a13e/arch/arm/mach-tegra/include
Onto the boot loader itself. Even on the unlocked tablet (First thing I did is copied everything using nvflash) the bootloader has logic to burn the fuse settings from FOTA mode. There seem to be 3 modes:
1. Static Key hardcoded in the bootloader
2. Production key that is passed through some parameters area
3. Random key
Now if I am understanding the code right. If the last case is what is used then ultimate unlock does not seem likely as every unit would have its own key.
I am still hoping it is the case #2 that is usually used.
Another avenue of getting SBK I was thinking is getting an unlocked tab to get to fetch update but not let it install. If it is case #2 and key is shared by tablets this could be the way to get hands on it.

I spent some time looking into this a few months ago and came to more or less the same conclusion. My feeble attempt at throwing the bootloader into IDA didn't pan out, especially since I'm a tightass and was trying to trick the free version into letting me load it, and messing around in objdump got nowhere. There's a lot to be gathered from the strings and looking at the Android-side FOTA code though. It seems that one of the partitions (can't remember which) holds a structure used to send messages back to the bootloader, one of which can contain the SBK and other keys. However, some people managed to get their SBK burned by asking to be repartitioned in ODIN, so in that case either a random or predefined SBK must be used. I have my doubts that the FOTA mechanism is being used, and was likely left in for possible future use.
I am curious to see how options 1 & 3 are determined. One possibility is that the SBK may be hashed from the emmc's CID (a unique 128-bit key hardcoded into the onboard flash chip), as that's checked and printed early on in the serial output of the bootloader. (on the other hand, my GS2 does the same thing, it may just be force of habit for Sammy).
The SBK flash code in the bootloader appears to print the SBK to burn during the burning process. IF someone were to still have an unlocked tablet AND they were willing to lock it in the name of science, someone could capture the serial output during the process. One of four things will result: No useful output at all and the tab gets locked, an SBK is printed and it doesn't work on that tab, an SBK is printed and it works on that tab and no others, or an SBK is printed and it's valid for all tabs.
In all likelihood it is completely random. There are probably very few Tabs that come back to Sammy for service that validly need a complete reflash under warranty. In that case it would be most secure to lock the door and throw away the key, and just bite the bullet on the few boards that need to be trashed and replaced.

There seems to be a trigger file written to EFS partition with parameters of what to write to the fuse from a quick look at some strings.
On a separate note. I was thinking on how to tell which option Samsung chose. If the same version of boot loader in encrypted with the same key would it not result in the same encrypted partition? If so then collecting bootloader version with say first 32 bytes of encrypted partition from users should tell if same encryption key is used. Unless some sort of per machine is combined with SBK.

We know the encryption is AES, so it's symmetrical and therefore any keys won't be randomly salted. However, like you said it's likely that the encryption key includes the device serial number or something else that would keep partitions on identically keyed devices from matching. A quick test of this would be to compare bootloader partition dumps from two devices locked with the same SBK, i.e. two Transformers. What's important to realize is that the decryption of the bootloader is driven by firmware built into the Tegra2 that's identical for all chips, so what applies to one Tegra2 device applies to the rest.

Ideas to recover DRM

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.

[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?

XT1528 (Moto E2 LTE Surnia) bootloader unlock

I`m sorry if I created new thread that already exist .
I think, there is the way to unlock bootloader on this device. laginimaineb posted awesome information on blogger a couple years ago and I`m wondering ,if can somebody apply this on xt1528.
I don`t know how to insert link on that post. Try to google first sentence .It is better to read original post.
And i am sorry for my English
Unlocking the Motorola Bootloader
In this blog post, we'll explore the Motorola bootloader on recent Qualcomm Snapdragon devices. Our goal will be to unlock the bootloader of a Moto X (2nd Gen), by using the TrustZone kernel code execution vulnerability from the previous blog posts. Note that although we will show the complete unlocking process for this specific device, it should be general enough to work at-least for most modern Motorola devices.
Why Motorola?
After reporting the previous TrustZone kernel privilege escalation to Qualcomm, I was gifted a shiny new Moto X. However... There was one little snag - they accidentally sent me a locked device. This was a completely honest mistake, and they did offer many times to unlock the device - but where's the fun in that? So without further ado, let's dive into the Motorola bootloader and see what it takes to unlock it.
Setting the Stage
Before we start our research, let's begin with a short introduction to the boot process - starting right at the point at which a device is powered on.
First - the PBL (Primary Boot Loader), also known as the "BootROM" is executed. Since the PBL is stored within an internal mask ROM, it cannot be modified or provisioned, and is therefore an intrinsic part of the device. As such, it only serves the very minimal purpose of allowing the device to boot, and authenticating and loading the next part of the boot-chain.
Then, two secondary bootloaders are loaded, SBL1 (Secondary Boot Loader), followed by SBL2. Their main responsibility is to boot up the various processors on the SoC and configure them so that they're ready to operate.
Next up in the boot-chain, the third and last secondary bootloader, SBL3, is loaded. This bootloader, among other tasks, verifies and loads the Android Bootloader - "aboot".
Now this is where we get to the part relevant for our unlocking endeavours; the Android Bootloader is the piece of software whose responsibility is, as its name suggests, to load the Android operating system and trigger its execution.
This is also the piece of boot-chain that OEMs tend to customize the most, mainly because while the first part of the boot-chain is written by Qualcomm and deals with SoC specifics, the Android bootloader can be used to configure the way the Android OS is loaded.
Among the features controlled by aboot is the "bootloader lock" - in other words, aboot is the first piece of the boot-chain which can opt to break the chain of trust (in which each bootloader stage verifies the next) and load an unsigned operating system.
For devices with an unlockable bootloader, the unlocking process is usually performed by rebooting the device into a special ("bootloader") mode, and issuing the relevant fastboot command. However, as we will later see, this interface is also handled by aboot. This means that not only does aboot query the lock status during the regular boot process, but it also houses the code responsible for the actual unlocking process.
As you may know, different OEMs take different stances on this issue. In short, "Nexus" devices always ship with an "unlockable" bootloader. In contrast, Samsung doesn't allow bootloader unlocking for most of its devices. Other OEMs, Motorola included, ship their devices locked, but certain devices deemed "eligible" can be unlocked using a "magic" (signed) token supplied by the OEM (although this also voids the warranty for most devices).
So... it's all very complex, but also irrelevant. That's because we're going to do the whole process manually - if aboot can control the lock status of the device, this means we should probably be able to do so as well, given an elevated enough set of privileges.
Getting Started
Now that we have a general grasp of the components involved and of our goal, the next stage is to analyse the actual aboot code.
Since the binaries for all stages of the boot-chain are contained within the factory firmware image, that would naturally be a good place to start. There are several download links available - here are a few. In case you would like to follow along with me, I'm going to refer to the symbols in the version "ATT_XT1097_4.4.4_KXE21.187-38".
After downloading the firmware image, we are faced with our first challenge - the images are all packed using a proprietary format, in a file called "motoboot.img". However, opening the file up in a hex-editor reveals it has a pretty simple format we can deduce:
As you can see above, the sought-after aboot image is stored within this file, along with the TrustZone image, and various stages of the boot-chain. Good.
After analysing the structure above, I've written a python script which can be used to unpack all the images from a given Motorola bootloader image, you can find it here.
Much ado aboot nothing
We'll start by inspecting the aboot image. Discouragingly, it is 1MB large, so going over it all would be a waste of time. However, as we've mentioned above, when booting the device into the special "bootloader" mode, the actual interaction with the user is provided by aboot itself. This means that we can start by searching for the strings which are displayed when the unlocking process is performed - and continue from there.
A short search for the "unlock..." string which is printed after starting the unlock process brings us straight to the function (@0xFF4B874) which deals with the unlocking logic:
That was pretty fast!
As you can see, after printing the string to the console, three functions are called consecutively, and if all three of them succeed, the device is considered unlocked.
Going over the last two functions reveals their purpose is to erase the user's data partitions (which is always performed after the bootloader is unlocked, in order to protect the device owner's privacy). In any case, this means they are irrelevant to the unlocking process itself and are simply side-effects.
This leaves us with a single function which, when called, should unlock the bootloader.
So does this mean we're done already? Can we just call this function and unlock the device?
Actually, not yet. Although the TrustZone exploit allows us to achieve code-execution within the TrustZone kernel, this is only done after the operating system is loaded, at which point, executing aboot code directly could cause all sorts of side-effects (since, for example, the code might assume that there is no operating system/the MMU could be disabled, etc.). And even if it were that simple, perhaps there is something interesting to be learned by fully understanding the locking mechanism itself.
Regardless, if we can understand the logic behind the code, we can simply emulate it ourselves, and perform the meaningful parts of it from our TrustZone exploit. Analysing the unlocking function reveals a surprisingly simple high-level logic:
Unfortunately, these two functions wreak havoc within IDA (which fails to even display a meaningful call-graph for them).
Manually analysing the functions reveals that they are in fact quite similar to one another. They both don't contain much logic of their own, but instead they prepare arguments and call the following function:
This is a little surprising - instead of handling the logic itself, this function issues an an SMC (Supervisor Mode Call) in order to invoke a TrustZone system-call from aboot itself! (as we've discussed in previous blog posts). In this case, both functions issue an SMC with the request code 0x3F801. Here is the relevant pseudo-code for each of them:
At this point we've gleaned all the information we need from aboot, now lets switch over to the TrustZone kernel to find out what this SMC call does.
Enter Stage Left, TrustZone
Now that we've established that an SMC call is made with the command-code 0x3F801, we are left with the task of finding this command within the TrustZone kernel.
Going over the TrustZone kernel system calls, we arrive at the following entry:
This is a huge function which performs widely different tasks based on the first argument supplied, which we'll call the "command code" from now on.
It should be noted an additional flag is passed into this system-call indicating whether or not it was called from a "secure" context. This means that if we try invoking it from the Android OS itself, an argument will be passed marking our invocation is insecure, and will prevent us from performing these operations ourselves. Of course, we can get around this limitation using our TrustZone exploit, but we'll go into that later!
As we've seen above, this SMC call is triggered twice, using the command codes #1 and #2 (I've annotated the functions below to improve readability):
In short, we can see both commands are used to read and write (respectively) values from something called a "QFuse".
QFuses
Much like a real-life fuse, a QFuse is a hardware component which facilitates a "one-time-writeable" piece of memory. Each fuse represents a single bit; fuses which are in-tact represent the bit zero, and "blown" fuses represent the bit one. However, as the name suggests, this operation is irreversible - once a fuse is blown it cannot be "un-blown".
Each SoC has it's own arrangement of QFuses, each with it's own unique purpose. Some fuses are already blown when a device is shipped, but others can be blown depending on the user's actions in order to change the way a specific device feature operates.
Unfortunately, the information regarding the role of each fuse is not public, and we are therefore left with the single option of reversing the various software components to try and deduce their role.
In our case, we call a specific function in order to decide which fuse we are going to read and write:
Since we call this function with the second syscall argument, in our case "4", this means we will operate on the fuse at address 0xFC4B86E8.
Putting it all together
Now that we understand the aboot and the TrustZone logic, we can put them together to get the full flow:
First, aboot calls SMC 0x3F801 with command-code #1
This causes the TrustZone kernel to read and return the QFuse at address 0xFC4B86E8
Then, iff the first bit in the QFuse is disabled, aboot calls SMC 0x3F801 once more, this time with command-code #2
This causes the TrustZone kernel to write the value 1 to the LSB of the aforementioned QFuse.
Turns out to be very simple after all - we just need to set a single bit in a single QFuse, and the bootloader will be considered unlocked.
But how can QFuses be written?
DIY QFuses
Luckily the TrustZone kernel exposes a pair of system-call which allow us to read and write a restricted set of QFuses - tzbsp_qfprom_read_row and tzbsp_qfprom_write_row, respectively. If we can lift those restrictions using our TrustZone exploit, we should be able to use this API in order to blow the wanted QFuse.
Lets take a look at these restrictions within the tzbsp_qfprom_write_row system-call:
So first, there's a DWORD at 0xFE823D5C which must be set to zero in order for the function's logic to continue. Normally this flag is in fact set to one, thus preventing the usage of the QFuse calls, but we can easily enough overwrite the flag using the TrustZone exploit.
Then, there's an additional function called, which is used to make sure that the ranges of fuses being written are "allowed":
As we can see, this function goes over a static list of pairs, each denoting the start and end address of the allowed QFuses. This means that in order to pass this check, we can overwrite this static list to include all QFuses (setting the start address to zero and the end address to the maximal QFuse relative address - 0xFFFF).
Trying it out
Now that we have everything figured out, it's time to try it out ourselves! I've written some code which does the following:
Achieves code-execution within TrustZone
Disables the QFuse protections
Writes the LSB QFuse in QFuse 0xFC4B86E8
In this blog post we went over the flow controlled by a single QFuse. But, as you can probably guess, there are many different interesting QFuses out there, waiting to be discovered.
On the one hand, blowing a fuse is really "dangerous" - making one small mistake can permanently brick you device. On the other hand, some fuses might facilitate a special set of features that we would like to enable.
One such example is the "engineering" fuse; this fuse is mentioned throughout the aboot image, and can be used to enable an amazing range of capabilities such as skipping secure boot, loading unsigned peripheral images, having an unsigned GPT, and much more.
However, this fuse is blown in all consumer devices, marking the device as a "non-engineer" device, and disabling these features. But who knows, maybe there are other fuses which are just as important, which have not yet been discovered...

Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.

programmargorp said:
Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.
Click to expand...
Click to collapse
I don't know if it will helps, but there in comment section of "Full TrustZone exploit for MSM8974" post , one user mentioned about tz_service of msm8916
also on MSM 8916 there is a function called
tz_service <0x3F802, aTzbsp_oem_svc, 0xF, 0x86500ECB, 1> ; "tzbsp_oem_svc"
which doesnt check the ranges and write 3 dwords to an arbitrary address
int __fastcall tzbsp_oem_svc(int a1, int a2)
{
int v2; // [email protected]
v2 = a2;
*(_DWORD *)a2 = 0xC;
*(_DWORD *)(a2 + 4) = get_tzbsp_params(); =>returns 0x0F
*(_DWORD *)(v2 + 8) = sub_865164FE(); =>returns 0x0
return 0;
}
this can be used to neutralise range check.

3max3 said:
I don't know if it will help, but there in comment section of "Full TrustZone exploit for MSM8974" post , one user mentioned about tz_service of msm8916
also on MSM 8916 there is a function called
tz_service <0x3F802, aTzbsp_oem_svc, 0xF, 0x86500ECB, 1> ; "tzbsp_oem_svc"
which doesnt check the ranges and write 3 dwords to an arbitrary address
int __fastcall tzbsp_oem_svc(int a1, int a2)
{
int v2; // [email protected]
v2 = a2;
*(_DWORD *)a2 = 0xC;
*(_DWORD *)(a2 + 4) = get_tzbsp_params(); =>returns 0x0F
*(_DWORD *)(v2 + 8) = sub_865164FE(); =>returns 0x0
return 0;
}
this can be used to neutralise range check.
Click to expand...
Click to collapse
Yes, that gives you a arbritary write gadget but doesn't bring you any closer to blowing the required qfuse.
You may or may not be able to use the other trustzone exploit (CVE-2016-2431) to trigger trustzone call 0x3000A0A with the provided parameters to force an unlock.

Good exploit, but too bad it was not converted into a more general tool ...
There is low single digit number of people who can use the instructions, and unlock other models.

bibikalka said:
Good exploit, but too bad it was not converted into a more general tool ...
There is low single digit number of people who can use the instructions, and unlock other models.
Click to expand...
Click to collapse
You`re absolutely right! Unfortunately , this device is not so popular and chances to practical use any of these exploits are close to zero.
But hope dies last.
P.S. : I really appreciate your attempt to use Dirty COW exploit on this device.

3max3 said:
You`re absolutely right! Unfortunately , this device is not so popular and chances to practical use any of these exploits are close to zero.
But hope dies last.
P.S. : I really appreciate your attempt to use Dirty COW exploit on this device.
Click to expand...
Click to collapse
Actually, I never posted this, but if your phone still has an older ROM where Dirty Cow works (5.0.2 or 5.1.1?), you should try Kingoroot as per these exact extractions:
https://forum.xda-developers.com/hd8-hd10/general/tut-fire-hd-10-7th-gen-2017-root-box-t3726443
This was the most stable temporary root I've seen on XT1528, since I was using XT1528 to debug my Fire HD how-to, and I was very pleased with how well the temporary root stuck around on XT1528, and it also survived soft reboots very well. So then you can do Titanium Backup and any other software that wants root to access /data, and other parts of the system. But of course, it cannot write into /system.
Then, there is a russian dude on the Internet selling Sunshine unlock for (1300 roubles ~$20) vs the usual $25. I'd guess Sunshine does the exact the same unlock, as that blog posted copy-pasted in post #1.
Update: here is the 1300 roubles Sunshine unlock - http://1droid.ru/?page_id=51

programmargorp said:
Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.
Click to expand...
Click to collapse
The blog post seems to say that the issue was reported and fixed back in 2014. It's unlikely that XT1528 has this bug since it's a later device, and the Android versions for XT1528 are some flavor of Lollipop, not KitKat.

bibikalka said:
The blog post seems to say that the issue was reported and fixed back in 2014. It's unlikely that XT1528 has this bug since it's a later device, and the Android versions for XT1528 are some flavor of Lollipop, not KitKat.
Click to expand...
Click to collapse
AFAIK Widevine exploit and the QSEE exploit both weren't patched until late 2015/early 2016. If you have a firmware version previous to the last update, then it's very likely at least the Widevine exploit still exists.
In fact, the bootloader unlock exploit did not rely on either the Widevine OR QSEE exploits, but was completely a trustzone exploit.

programmargorp said:
AFAIK Widevine exploit and the QSEE exploit both weren't patched until late 2015/early 2016. If you have a firmware version previous to the last update, then it's very likely at least the Widevine exploit still exists.
In fact, the bootloader unlock exploit did not rely on either the Widevine OR QSEE exploits, but was completely a trustzone exploit.
Click to expand...
Click to collapse
I see what you mean:
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html
If only we could get that Project Zero dude to start unlocking our phones, LOL
Btw, my ancient xt1028 with 4.4.4 is a great candidate for this original route : http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html
I plan to try to replicate exactly what the guy in the post was doing (IDA Pro package, his exact phone firmware version, etc), to understand if I am even able to follow his instructions first, and see the same output that he was getting. If I won't even get that far - no reason to proceed with any any other devices
Edit: btw, any suggestions what's the best package to compile his code? https://github.com/laginimaineb/Alohamora It's all provided as source files.

bibikalka said:
I see what you mean:
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html
If only we could get that Project Zero dude to start unlocking our phones, LOL
Btw, my ancient xt1028 with 4.4.4 is a great candidate for this original route : http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html
I plan to try to replicate exactly what the guy in the post was doing (IDA Pro package, his exact phone firmware version, etc), to understand if I am even able to follow his instructions first, and see the same output that he was getting. If I won't even get that far - no reason to proceed with any any other devices
Edit: btw, any suggestions what's the best package to compile his code? https://github.com/laginimaineb/Alohamora It's all provided as source files.
Click to expand...
Click to collapse
FYI the base address and probably fuse values will be completely wrong. His code runs directly in Python.

programmargorp said:
FYI the base address and probably fuse values will be completely wrong. His code runs directly in Python.
Click to expand...
Click to collapse
Would that be Python on Android, I guess ? Something like QPython3?
There is a small piece that needs to be compiled, shellcode.S. It wants arm-eabi-gcc to work. Is there an Android version, or would I need to do it in Linux or Windows?

Well, I tried to open the same TZ as in the blog (for XT1095) in IDA, and for now cannot even find the relevant addresses which should be the same as in the blog (SECURE_BOOT_FUSE = 0xfC4B86E8).
Overall, there are about 20 things that need to be filled for a different model/TZ version:
https://github.com/laginimaineb/Alohamora/blob/master/symbols.py
Anyway, it looks like people who could re-trace the unlocking steps fully don't hang out on this thread

programmargorp said:
Spent the last day or so looking at this. The surnia bootloader attempts to call the SMC function 0x3000A0A. That's as far as I got without the symbols for the trustzone kernel.
Click to expand...
Click to collapse
I've spent some time staring at IDA here - with me being a total IDA novice. I gotta say, @laginimaineb instructions on the blog are incomplete, and have quite a few gaps.
I could locate the fuse address for XT1098 (just to repeat his steps), and then for XT1028 that I have. Overall, I decompiled the whole TZ into a big *.c file, and then text searched for similar strings as in the blog. His variable/function names were cleaned up, only operands look the same.
But the challenge is that his exploit for bootloader unlock seems to rely on the kernel module being compiled and loaded (his "/data/local/tmp/fuzz_zone" utility), which seems to imply having root access at the very least. @beaups says exactly the same here : link
Also, I did not pursue searching for the memory addresses that enable fuse writing, since that code seems to sit in aboot which I was not able to decompile yet due to its non-standard format (TZ is a standard ELF). The blog never talks how he loaded aboot into IDA, and addressed this non-ELF format.
Anyway, now I don't understand how he unlocked bootloader in XT1098, he never mentions that he had root access, while his code is using the fuzz_zone program, which relies on the kernel module to talk to TZ via SCMs. It just seems a bit circular.
Then @laginimaineb posted some later exploits which could escalate from a normal user access all the way to SCMs and TZ, but the later exploits never loop back to the bootloader unlock. The code he uploaded is very research-y, inconsistent, and tough to take forward.
Technically, one could be unlocking a bunch of MOTOs and other phones just like peanuts, with a bit of skill/time. How come nobody bothered to collect misc bounties, especially back in 2016? No skill? Or the blog instructions were not so good after all?

bibikalka said:
I've spent some time staring at IDA here - with me being a total IDA novice. I gotta say, @laginimaineb instructions on the blog are incomplete, and have quite a few gaps.
I could locate the fuse address for XT1098 (just to repeat his steps), and then for XT1028 that I have. Overall, I decompiled the whole TZ into a big *.c file, and then text searched for similar strings as in the blog. His variable/function names were cleaned up, only operands look the same.
But the challenge is that his exploit for bootloader unlock seems to rely on the kernel module being compiled and loaded (his "/data/local/tmp/fuzz_zone" utility), which seems to imply having root access at the very least. @beaups says exactly the same here : link
Also, I did not pursue searching for the memory addresses that enable fuse writing, since that code seems to sit in aboot which I was not able to decompile yet due to its non-standard format (TZ is a standard ELF). The blog never talks how he loaded aboot into IDA, and addressed this non-ELF format.
Anyway, now I don't understand how he unlocked bootloader in XT1098, he never mentions that he had root access, while his code is using the fuzz_zone program, which relies on the kernel module to talk to TZ via SCMs. It just seems a bit circular.
Then @laginimaineb posted some later exploits which could escalate from a normal user access all the way to SCMs and TZ, but the later exploits never loop back to the bootloader unlock. The code he uploaded is very research-y, inconsistent, and tough to take forward.
Technically, one could be unlocking a bunch of MOTOs and other phones just like peanuts, with a bit of skill/time. How come nobody bothered to collect misc bounties, especially back in 2016? No skill? Or the blog instructions were not so good after all?
Click to expand...
Click to collapse
That answer is easy. The bugs you've seen publicly disclosed are long patched. In fact the E2 (and E for that matter) were never vulnerable.

beaups said:
That answer is easy. The bugs you've seen publicly disclosed are long patched. In fact the E2 (and E for that matter) were never vulnerable.
Click to expand...
Click to collapse
How about an ancient XT1028 with 4.4.4 ? It's ROM dates to about mid-2014.

bibikalka said:
How about an ancient XT1028 with 4.4.4 ? It's ROM dates to about mid-2014.
Click to expand...
Click to collapse
No publicly disclosed tz bugs impacted that device past 4.4.3

bibikalka said:
I've spent some time staring at IDA here - with me being a total IDA novice. I gotta say, @laginimaineb instructions on the blog are incomplete, and have quite a few gaps.
I could locate the fuse address for XT1098 (just to repeat his steps), and then for XT1028 that I have. Overall, I decompiled the whole TZ into a big *.c file, and then text searched for similar strings as in the blog. His variable/function names were cleaned up, only operands look the same.
But the challenge is that his exploit for bootloader unlock seems to rely on the kernel module being compiled and loaded (his "/data/local/tmp/fuzz_zone" utility), which seems to imply having root access at the very least. @beaups says exactly the same here : link
Also, I did not pursue searching for the memory addresses that enable fuse writing, since that code seems to sit in aboot which I was not able to decompile yet due to its non-standard format (TZ is a standard ELF). The blog never talks how he loaded aboot into IDA, and addressed this non-ELF format.
Anyway, now I don't understand how he unlocked bootloader in XT1098, he never mentions that he had root access, while his code is using the fuzz_zone program, which relies on the kernel module to talk to TZ via SCMs. It just seems a bit circular.
Then @laginimaineb posted some later exploits which could escalate from a normal user access all the way to SCMs and TZ, but the later exploits never loop back to the bootloader unlock. The code he uploaded is very research-y, inconsistent, and tough to take forward.
Technically, one could be unlocking a bunch of MOTOs and other phones just like peanuts, with a bit of skill/time. How come nobody bothered to collect misc bounties, especially back in 2016? No skill? Or the blog instructions were not so good after all?
Click to expand...
Click to collapse
The aboot image should be a standard ELF image.
Getting root on the xt1528 is possible (without system rw) with initrd root.

beaups said:
No publicly disclosed tz bugs impacted that device past 4.4.3
Click to expand...
Click to collapse
Interesting. Not even the Widevine QSEE issue? How can it be? Or is Widevine too difficult to exploit?
programmargorp said:
The aboot image should be a standard ELF image.
Getting root on the xt1528 is possible (without system rw) with initrd root.
Click to expand...
Click to collapse
Yes, root is very easy. But it's getting further, to bootloader unlock that is the big challenge. Can you double check your "aboot", it does not look like ELF ...

bibikalka said:
Interesting. Not even the Widevine QSEE issue? How can it be? Or is Widevine too difficult to exploit?
Yes, root is very easy. But it's getting further, to bootloader unlock that is the big challenge. Can you double check your "aboot", it does not look like ELF ...
Click to expand...
Click to collapse
Correct, the device does not have that widevine vulnerability.