Remove All Ads from XDA

Unlocking the bootloader

222 posts
Thanks Meter: 9
By waffleb051, Senior Member on 28th February 2014, 05:31 AM
Post Reply Email Thread

Ok. So all my android phones up to this one have had the ability to have their bootloader unlocked. I know that this specific phone has only been out for about 8 months now and we are seeing little to no progress on the unlocking of the bootloader.

My question is, how?
Where do you even start to unlock a bootloader?
What tools are needed?
Once you find a way to unlock your device (the one you have been working on) how do you package it and test it on other devices?

The reason I ask is because I have a bit of time on my hands and I know a bit about code.

I understand that trying to do something like this is EXTREMELY hard or it would have been done by now, but the way I see it the more heads banging against the same wall. Sooner or later the wall is going to give.
2nd March 2014, 09:45 AM |#2  
Senior Member
Thanks Meter: 425
If you want to look into trying to do this I would guess the threads Adam Outler left in the VZW Note 2 forums on how he did it.

Sent from my SM-N900V using Tapatalk
2nd March 2014, 08:20 PM |#3  
Senior Member
Thanks Meter: 1,041
The N3 takes full advantage of ARM Trustzone technology in the Snapdragon 800 SoC. This involves a microkernel running on a separate ARM core from processor ROM space and SoC private memory to do things like key storage and crypto computations, as well as chain-of-trust bootstrapping where each image loaded in the boot sequence is cryptographically verified before loading.

There is a portion of the eMMC flash memory chip (rpmb - Replay Protected Memory Block) which can only be accessed via a hardware protocol that re-keys every read-write transaction. So, even if you could sniff the eMMC (hardware) bus, you might be able to passively read data, but the key used to generate the transaction nonce is never exposed... meaning you won't gain control of it.

In addition, as of the MJ7 release, part of this boot sequence (aboot - the part which interacts with Odin) stores & uses anti-rollback protection information which disallows even valid *prior* Samsung firmware from being re-flashed onto the device. This is to prevent vulns discovered in prior releases from becoming a gateway to device customization.

Sounds complicated, right? Well, that's only the start of it. In addition there are "trustzone applets" that are running during the normal boot that continuously perform a variety of attribution measurements that detect tampering of kernel memory, changes to certain partition signatures, etc. It is sort of unknown at this point whether or nor these live "tripwires" also blow irreversible tamper fuses on the SoC or merely write tamper detection into the rpmb via the TZ api. In either case though, the possibility exists that "harmless" activity such as a kernel exploit that writes into volatile private kernel memory could result in semi-permanent disabling of the device.

In any event, there isn't a playbook for exploit discovery, other than this: understand approximately how a given subsystem works, and look for/test against implementation errors. If one is found, the dev needs to create and test hypotheses that might allow a minor exploit to be leveraged up into increasing privilege or control.

I'm not optimistic that a "class break" exploit of the hardware trustzone technology will occur; but the normal OS requires services from the trustzone, so perhaps there are implementation errors that exist that are close to the exposed APIs.

Probably there are private methods known to Samsung ARCs (Authorized Repair Centers) for reprogramming/resetting devices. These are probably low-hanging fruit in the sense that (a) if known they would enervate devs to experiment, knowing they have a rescue method, and (b) are the type of thing which could be exposed through social methods, and (c) are close in function to the goal of loading altered images onto the phone.

This phone has a *ton* of security stuff going on compared to phones that are only one year old. Given Samsung's dominance in the Android "premier device" segment, if I were CyanogenMod's new investors, I would be worried about what this portends for the future for aftermarket ROMs which require a custom kernel.

Maybe the right approach is to beat Samsung up over their horrid track record for making developer devices available - or maybe it is time to start rewarding OEMs who are happy to allow opt-out of device lockdown through market mechanisms. Samsung boycott, anyone?

Personally, I find it objectionable that my phone needs to be locked down and bristling with security armament on the off-chance that it might someday become a corporate BYOD device. That puts the interests of a low-probability straw-man ahead of the actual device owner... namely, me.

The Following 6 Users Say Thank You to bftb0 For This Useful Post: [ View ] Gift bftb0 Ad-Free
3rd March 2014, 12:51 PM |#4  
Senior Member
Thanks Meter: 425
I agree with you that it is a load of rubbish that our phones are locked down, but I still have hope that we will get an unlock procedure. Adam Outler, despite saying he was done with Samsung devices, has somehow managed to get past Secure aboot and turn it off. He posted a picture of it on his G+, which he promptly deleted because people were sending massive amounts of hate simply because they didn't understand that bypassing aboot was not an unlock.

I still have hope for an unlock but it fades everyday, I think one of our best hopes would be Outler if he is truly looking into to bootloader unlock us. There are so many devs looking into it though that any one of them could do it any day.

Sent from my SM-N900V using Tapatalk
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes