[Dev Notes] Locked Bootloader 101

I think now that everyone seems to be empowered about the phone, I've been seeing some posts about thoughts to unlock the bootloader. But I'm finding some ideas have misunderstandings of what the phone is doing.

So I decided to make this post to clear up alot of confusion about the locked bootloader. It's literally most of my notes on the subject. It's almost enough to teach a class on it.

Phone Basics
- The phone's flashable memory space is broken into data sets called partitions
- Each partition is used for a different function on the phone
- Access to the partitions is found in /dev/block/
- The main partitions are mmcblk0 and mmcblk1
- mmcblk0 is the main internal flash memory
- mmcblk0 is broken into parts (e.g. mmcblk0p1, mmcblk0p2, etc...)
- mmcblk1 is the internal sd card
- Notable partitions:
--- Bootloader and Microboot - mmcblk0p1
--- CDT Table - mmcblk0p2
--- Recovery - mmcblk0p10
--- Boot (kernel and ramdisk) - mmcblk0p11
--- System - mmcblk0p12
--- Userdata - mmcblk0p16
- Certain partitions are file system mountable (e.g. System and Userdata)
- Mountable partitions are defined in /proc/mount
- Partitions can be flashed in a number of ways:
--- SBF files via RSD
--- Direct byte-by-byte (e.g. dd if=/scdard/boot.img of=/dev/block/mmcblk0p11)
--- Some partitions via fastboot (e.g. fastboot flash recovery recovery.img)
- SBF files contain data sets known as code groups
- SBF files can be unpacked with MotoAndroid Depacker (http://modmymobile.com/forums/402-general-motorola-android/530781-sbf-depacker-1-3-03-22-2011-a.html)
- When an SBF is flashed with RSD, the code groups flash onto the assigned partitions in flash memory
- Notable code group to partition mappings:
--- Bootloader - CG42 -> mmcblk0p1
--- Microboot - CG47 -> mmcblk0p1
--- CDT Table - CG3 -> mmcblk0p2
--- Recovery - CG58 -> mmcblk0p10
--- Boot (kernel and ramdisk) - CG59 -> mmcblk0p11
--- System - CG60 -> mmcblk0p12
- A "full" SBF does NOT include all CG groups. Not all partitions will be flashed with an SBF.

Digital Signing Basics
- The goal of digital signing is to assert that a set of data is generated by one authorized source
- A digital signature is:
--- An encrypted data string that expresses that a set of data is from one source
--- Comprised of a representation of the data (hash) and a cryptographic component of the signer (private key)
- A digital certificate is a data package that contains the signature of the data set and other cryptographic information that verifies the signature
- A signature verification algorithm verifies that the signed data has not been tampered with:
--- A hash is performed on the data set
--- Using the public key provided from the certificate, a hash is generated from signature
--- If the two hashes match, the signature check passes
- You fail a signature check if:
--- The hashes don't match meaning either the data or the signature has been tampered with
--- The certificate is tampered with via cryptographic checks on the certificate (unknown to us on this phone)

Locked Bootloader
- A bootloader is said to be "locked" when a regular user does not have the complete authority to change all of the phone's flash memory
- In the case of Motorola Tegra-based phones, digital signature (NOT encryption) is used on some partitions. (In some Motorola OMAP phones, some partitions are encrypted. Blah).
- The digital certificate asserts to the phone that the partition is "From Motorola"
- A signed partition has an attached digital certificate near the end of the data
- A signature check algorithm is run at phone startup to check the signed partitions
- In most cases (so far), a failed signature check at bootup leads to a soft brick with the ability to use RSD to SBF
- Notable signed partitions:
--- Bootloader and Microboot - mmcblk0p1
--- CDT Table - mmcblk0p2
--- Recovery - mmcblk0p10
--- Boot (kernel and ramdisk) - mmcblk0p11

Atrix Notes that should apply the DX2
- Unlock-capable bootloaders were found through development leaks. Thus, the bootloaders are signed by Motorola which allows them to be run before the fastboot oem unlock command is issued. To my knowledge, no unlock method for a Motorola phone has been found without a development leak.
- The fastboot oem unlock command issues something in a phone to "burn" a fuse on the board which indicates that the phone is unlocked. The "burn" process is said to be irreversible.
- You can check for the unlock fuse by reviewing /sys/firmware/fuse/ReservedOdm
- Atrix has the same partition map (including signed partitions) as the DX2
- Atrix has the same SBF flashing map (CDT) for the most part with the DX2 (sometimes different CG number but the same map)

Some Notable Results
- A signature failure on the CDT Table partition produces a "Failed to boot 1" error
- A signature failure on the Recovery partition produces a "Failed to boot 2" error
- Locked bootloader prevents flashing of an unsigned partition via fastboot. However, flashing a signed partition with a tampered signature is allowed through fastboot but will fail the signature check upon phone startup.
- Despite having the same partition and certificate format, flashing the Photon 4G boot image causes a signature failure. Certificate must have some kind of identification to determine the uniqueness of the phone (model/carrier).

Potential Unlock/Trick/Bypass Approaches
- Find the command force unlock fuse to be set (unlock command outside of the bootloader fastboot)
- Trick the phone to not check the unlock fuse and always report the phone as unlocked
- Trick the phone never to run the signature checking code
- Trick the phone to assume that the boot and recovery partitions are "regular" partitions and not signed ones
- Find a flaw in the signature such that you can sign the partition as if you are Moto
- Get kexec to work so that a new custom kernel can be loaded after kernel is first loaded (kinda like 2nd-init)

Currently at the end of the day
Bootloader unlocks for Motorola phones have been through development leaks. Motorola's bootloader locking system is quite complicated (and surprisingly well thought out). No Motorola unlock has been achieved solely through the external development community. The best possible chance for an unlock today is through supporting Project Pudding or Project Cheesecake for a development leak. I'm not saying you shouldn't try to work on a locked bootloader workaround. The technical expertise necessary is quite advanced for most people and if you don't understand half the stuff I mentioned, I think your help is best served through something like Project Cheesecake.

For some light reading
Digital Signature on Wikipedia - http://en.wikipedia.org/wiki/Digital_signature
kexec on Wikipedia - http://en.wikipedia.org/wiki/Kexec
EternityProject Kexec method for Motorola Olympus (Atrix 4G) - http://xdaforums.com/showthread.php?t=1079097
Project Pudding: http://xdaforums.com/showthread.php?t=1225072
Project Cheesecake: http://xdaforums.com/showthread.php?t=1226664

Just wanted to add:

• mmcblk0p13 - osh
• mmcblk0p15 - cache
• mmcblk0p17 - preinstall

I got it from /proc/config.gz and yes its what is running its actually a .gz if you want your kernels .config run
cp /proc/config.gz /sdcard/
I tried to echo c to /proc/sysrq-trigger which you force a kexec but all it did was reboot
Sent from my DROID X2 using XDA App

Strange because it works for me, I will see if I can link to full site not mobile site. That's probably the problem

Edit: try this

http://www.cnn.com/2011/09/19/tech/mobile/verizon-att-innovation/index.html

Sent from my DROID X2 using XDA App

iBolski said:

I'm hoping if/when the Google/Moto merger occurs, that maybe Google will force Moto's hand to unlock it.

We can only hope.

Click to expand...

Click to collapse

If you read some news articles, Google is going to operate Motorola mobility as a separate company. They are not acquiring it for us, they are only doing it so they can go to war with Microsoft in court. Don't expect anything to change.

Sent from my DROID X2 using XDA App