[Asus  Eee Pad Transformer Prime] kokopuphz:
Just an update to dev/analysis that I'm currently working on.

A simple check of all the various releases that ASUS have done shows that the EBT partition (bootloader) have had various changes made to them in the past. For example, .17 and below will not show the "bootloader is unlocked" message whilst on boot, versions prior to the ICS release does not have the unlock alogrithm, etc.

Rumor has it that the JB version of the TF300 have fastboot enabled, thus this might be of some help for us in the future, yet at the current moment, it helps us none.

Anyhow, back to topic. Since there's been various changes in the bootloader itself, there may be a slight chance that ASUS left out one of the signature checks in one of the bootloader versions. Thus one angle that we could go is to keep trying different bootloaders and checking to see either if the blob signature check is in effect or if the AES engine has been disabled properly in the bootloader. If the blob signature check has been let out, then we would theoretically be able to flash a modified bootloader to bypass the various checks that happen in the bootloader. The AES engine part, if we can verify if it has forgotten to be disabled, we would be able to generate the NVflash files needed for wheelie, and we'd have more avenues to try.

The other angle that I'm currently looking at is somehow figuring out the private key for RSA signature. I've looked into RSA signatures, and theoretically it is pretty much impossible to crack, specially in the case of RSA encryption. In RSA, the public key is used to encrypt, the private key is used to decrypt. In the case of RSA signatures, the private key is used to "decrypt" a string, usually the sha1 hash of the file needed to be signed. Then the public key is used to "encrypt" this signature, and compare the result with the hash of the file we want to check.

Since we have various files from ASUS that have signatures, we have the "decrypted" strings which are the signatures, and the "encrypted" strings which would probably be the hash file checksums of the various blobs.

In order to determine this logic, we need a few things. 1. we need to disassemble the bootloader binary file to determine whether it is in fact the sha file checksum that is being used as the string. 2. we need to disassemble the bootloader to get hold of the public key that is being used. I've tried the certificate in the zip files, however these appear to be a different certificate than the one that is being used for blob checking.

I'm currently working mostly on a way to figure out the private key exponent that is being used to decrypt the strings. This is a very complex task, and possibly impossible, however having various combinations of signatures and strings should help. Once the signature can be figured out, we'd be able to sign the modified bootloader and load that into the system, effectively giving us an unlocked bootloader.

The only problem is, I have not experience with disassembly of the bootloader binary. I believe I need a linux box with the arm toolchain installed at the least. On the other hand if any devs here already have disassembled the bootloader binary (for example android.root mobi team), then it would help in speeding things up.