[Motorola Droid X2] mostKnownUnknown:
Hello again,

Here are some conclusions I came up when I researched Atrix Pudding:

1. Pudding bootloader has the component that issues the unlock command (fastboot oem unlock #).

2. The unlock command causes a "fuse" to be burned in the phone's hardware.

3. Pudding bootloader has the component that recognizes the phone as unlocked.

Here are my thoughts:

1. The Pudding bootloader can take in the phone id to issue the unlock. Whereas the DX2 bootloader has the command (fastboot oem unlock) but no implementation if you send it your phone id number (fastboot oem unlock #).

2. When the unlock is issued, a bit in your hardware changes. (Most people call it a "fuse". I think it's probably a small EEPROM since as a company, I would probably like to re-lock it if I could.) People who have worked on Pudding have found an indication to see if you are unlocked (see http://xdaforums.com/showthread.php?p=16003820&highlight=fuse#post16003820). You can look up that same indication on the DX2 (adb shell, su, cat /sys/firmware/fuse/ReservedOdm) and mine reads 10000000000010001000100000000. I think this file is only a place holder for the fuse indications since overwriting it does not work.

3. I asked around if SBF-ing to original after unlocking re-locks you. Apparently, it sorta does and it sorta doesn't. SBF-ing to original after unlock removes the UNLOCKED at boot up and prevents you from flashing custom kernels and recovery. But when you re-flash Pudding again, the UNLOCKED appears and you can flash custom kernels and recovery without having to re-issue the unlock command (fastboot oem unlock #). This means that there is something in the Pudding bootloader which recognizes the unlock fuse.

This actually depresses me a bit. My initial thought about the bootloader is that the unlocked indication was held in a hidden partition that isn't SBFed. So if I verified the Atrix partitions before and after the unlock, I could determine what changed in a partition and attempt to apply the change to the DX2.

But since #2 is true and the unlocked indication is located external to the partition, the only way to unlock the DX2 is to feed the "fuse" component with the right commands to "burn". There's no coping a file/partiton that will give you the unlock.

#3 is interesting in that the bootloader needs to have the processing to test if you are unlocked and allow for the unlock. Which means that we need to mess with the bootloader in order to add this processing (since I'm pretty sure the DX2 bootloader doesn't have it). This was another item that I kinda wanted to avoid since I don't think we can easily inject new code into the bootloader because of the signature. Also, if we mess up with the bootloader partition, there is a strong possibility that the phone won't make it to the fastboot or rsd protocol setup and we'd be stuck with a hard brick.

I still have plenty of questions which are still good investigates/discussion points from here.

- What are the commands the bootloader gives to the "fuse" component to request an unlock?

- Is there a way to log/monitor bootloader commands?

- Can you instruct the "fuse" component a request for an unlock after the kernel is loaded? (Holy grail here - an APK-packaged unlocker)

- In the pudding bootloader, where is the check for the unlocked indication? (possible exploit to always indicate to the bootloader that the phone is unlocked without calling the external fuse check)

- Where in the DX2 bootloader does the signature check occur?

Again, I'm not a pure dev so I'm not thinking of implementation of anything here. I'm taking the academic approach of trying to discover some loophole and then asking a dev later to package and implement it. Also, I ask you to think and analyze for the sake of understanding our phone. The more info definitely helps no matter how little it is.

Thanks,

mostKnownUnknown