By having probed the hardware1), we know the OMAP processor works in High Security mode upon booting (as opposed to General Purpose mode). We know the XT701 is working in HS mode too. In HS mode the mbmloader's cryptographic signature is be checked before booting, and since the signatures are being checked in later stages of the boot process, so both mbmloader and mbm are probably signed and verified too. Static code analysis seem to confirm the signatures are in place. Mbmloader itself checks for mbm's signature before passing control to it, and then mbm checks signatures of the partitions based on cdt. The idea of this attack is simply to replace mbmloader and mbm with XT701 version, where XT701 mbm doesn't check for any signatures. We know that the root key hash of the XT701 mbmloader is same as the Milestone ones.
User Tobiwan replaced the mbmloader and mbm with the XT701 version. The result was that the phone failed to boot but there was no activity over USB implying that the mbmloader was verified by the boot ROM.
We can find some mbmloader that is signed with the same key as the Milestone's but that does not enforce the signature chain on mbm. We are also able to write to the NAND area where mbmloader is stored, so as to replace it.
Janneg's test has sadly demonstrated that there are problems regarding the ECC mechanism when generating them by the kernel. The decision was to dump the OOB from the XT701 too and just write it. Alternatively one can have a look on u-boot sources to see how x-loader ECC is written.
When janneg's phone was unfortunately bricked, it ended up with a corrupted mbmloader and trying to boot from USB (expecting a signed image in some unknown format). In this mode, the phone's boot ROM sends the ASIC ID to the USB host. In janneg's case, the ASIC ID was:
05010501 34300757 13020100 12150136 66e176b7 00efa289 0d53bd71 93627710 b01bbe14 15011d3f b662794d 8c70fb57 b4cb492e 27f66f15 2e4f1509 01f7488f 28a027e5 b3
This has been decomposed into the following information by user [mbm], based on table 1-8 in the 1.4.4.1 section of the sprufd6.pdf TRM document:
ASIC ID Item Size [bytes] Description Items 1 Number of subblocks ID sub block 7 Device identification information Secure mode subblock 4 Secure identification data Public ID subblock 23 Public identification data generated by secure ROM Root key hash subblock 23 Root key hash generated by a secure ROM service Checksum Subblock 11 4 bytes: CRC of public ROM. 4 bytes: CRC of secure ROM ITEMS: 05 ID[01] 05 [01][34 30 07 57] SECURE[13] 02 [01][00] PUBLIC[12] 15 [01][36 66 e1 76 b7 00 ef a2 89 0d 53 bd 71 93 62 77 10 b0 1b be] ROOT[14] 15 [01][1d 3f b6 62 79 4d 8c 70 fb 57 b4 cb 49 2e 27 f6 6f 15 2e 4f] CRCS[15] 09 [01][f7 48 8f 28][a0 27 e5 b3]
It seems user kokone has been able to guess how the key verification process works. Using his tool for exporting mbmloader keys into .PEM format, he realized that the SHA1 verification hash of the “Public Key in LBL Format including the 0x14 bytes status info in front” results in value “1d3fb662794d8c70fb57b4cb492e27f66f152e4f”, which is precisely the same value as the ROOT[14] field decoded from the ASIC ID. It is verified that kokone calculated the sha1 hash based on this formula:
root_pk_hash = sha1_hash(20_bytes_key_info + modulus)
Modulus's length is specified in the key info. For instance, a 1024-bits modulus would require only 1024-bits to be hashed due to the least significant byte order of modulus.
The content can be extracted by mbmloader using this command:
dd if=mtd_00_mbmloader.img skip=1076 bs=1 count=276 of=pk.bin sha1sum pk.bin 1d3fb662794d8c70fb57b4cb492e27f66f152e4f *pk.bin
A sample file can be downloaded → milestone_public_key.zip.
It has also been found that droid001's pkhash kernel module returns this same value (reversed order is normal due to different presentation method of sha1sum and pkhash) in its CONTROL_RPUB_KEY_H[4:0] field.
Running droid001's pkhash in Latam Milestone phones shows that those phones have the same hardware key as the European Milestone.
Sadly, the Droid hash stored in hardware is different from the Milestone's: it is “75ed7020641333dd7bc3aecb9857683c2422efe1”2). Thus, we won't be able to use Droid's mbmloader on the Milestone. It's strange that the root pk hash is different from the value calculated by hand according to the method above.3)
XVilka's developer phone, mbmloader version 90.804), does NOT run in HS mode. It does have a hash key stored in hardware5), but it is not used in GP mode.
In the event of a mistake in the process, or if our hypothesis is wrong, the device would be bricked beyond repair (at least with the resources we have, namely RSD Lite). The person trying this attack should be aware of this risk, and would probably be willing to try it on a device which could be sent to Motorola for repair without much hassle or cost (e.g., a Milestone that has some obvious warranty-covered issue such as a defective keyboard, etc). A German Motorola service agent is said to have quoted 89 euros for repairing firmware tampering.
#include <mach/cpu.h>
main () {
printk(KERN_INFO "omap type: %d\n", omap_type());
}