FreeCalypso > hg > freecalypso-sw
view doc/TFC139-breakin @ 985:8109185528c1
tfc139: new logic actually works
author | Mychaela Falconia <falcon@ivan.Harhan.ORG> |
---|---|
date | Sat, 12 Dec 2015 03:24:52 +0000 |
parents | 3f67d5bf96ef |
children | 7a55a3eb985a |
line wrap: on
line source
Maliciously locked bootloader ============================= When Compal (Motorola's ODM who designed and built their C1xx phones for them) designed the firmware architecture and flash memory layout for their phones, they made a bad design decision by putting the boundary between their bootloader and the main fw image at 0x2000, even though the flash erase block boundary doesn't come until 0x10000 - thus every time the main fw needs to be reflashed to a different version, the dangerous boot sector has to be reflashed too. But then they made things even worse in the newer versions of their fw by introducing a bootloader lock malfeature whereby the ability to interrupt boot and load code serially may be artificially disabled. This malfeature is implemented as follows: * In the original firmware layout (before the addition of the malfeature in question) the boot code occupies the flash range from 0 through 0x1FFF, then there are some ID strings at 0x2000, 0x2020 and 0x2040, and then the part of the firmware that used to be at 0x10000 in TI's reference fw starts at 0x20A0, with the entry point at 0x20F8 (corresponding to TI's 0x10058). With the addition of the bootloader lock malfeature the 32-bit word at 0x2060 (previously unused and filled with 0xFFFFFFFF) became a control word telling the bootloader whether diversion of the boot path to serial code download should be allowed or not. * When firmware images with this malfeature present are first built, the word at 0x2060 contains 0xDDDDDDDD. (Does D stand for debug or development, or was the developer who implemented this malfeature fascinated by large bra cups? We may never know.) This word MUST read as 0xDDDDDDDD in order for the boot code to allow serial download: if it reads as any other value (e.g., if it contains 0xFFFFFFFF because only the 8192 byte boot code has been programmed into flash sector 0, with blank flash from 0x2000 onward), no serial download opportunity will ever be offered and the phone is effectively bricked! * For as long as the word at 0x2060 still contained 0xDDDDDDDD, Compal's developers could continue gaining access through the bootloader and reflashing their firmware. But when phones were to be shipped to customers with the malicious bootloader lock activated, they probably sent some Test Mode command (see RVTMUX write-up) to their running fw that caused it to write 0x00000000 into the flash word at 0x2060. (Remember that any bit in a NOR flash memory can be programmed from 1 to 0 at any time in any combination, but changing bits from 0 back to 1 is only possible with full sector erasure.) * Once the word at 0x2060 has been programmed (in the flash memory sense) from 0xDDDDDDDD down to 0x00000000, the phone is irreversibly locked and has lost its ability to ever run a different firmware version, like a kamikaze pilot's plane that has discarded its landing gear and can only crash now. TFC139 recovery =============== While it probably was Compal's, Motorola's and TracFone's intent that the bootloader lock on their phones be truly irreversible, some genius out there (we may never know who this person was/is) has found a way to recover the reflashing capability on at least one very common flock of locked-down phones: North American C139 units (1900+850 MHz hardware) sold with TracFone branding, firmware version 8.8.17. Here is how it goes: * Even though the bootloader is locked down, if one boots the full fw regularly, one can still access the RVTMUX interface which the TI-based fw implements for debug trace and factory programming functions. One needs to key in the magic sequence **16379# into the running fw, and a hidden menu will appear, giving the operator the option to enable trace. Selecting this option will cause the fw to switch the headset jack to the UART carrying RVTMUX. * Mot/Compal's firmware is based on a quite old version of TI's chipset reference fw (relative to late TCS211 from the Openmoko/Pirelli era), and it does not feature the Enhanced Test Mode (ETM) component with which we are most familiar. However, it does implement the older set of non-enhanced Test Mode commands, and these TM commands just happen to include raw memory read and write operations at an arbitrary address. (For a while we were under a mistaken belief that these commands were Compal's inventions, until we discovered TI's original TM predating ETM.) * The ingenious idea our hero came up with is that one can use the RVTMUX TM memory write command to write a piece of "shellcode" into an unused RAM location, and then use those very same memory write commands to cause a transfer of control to this code by overwriting a function return address on the stack! * Once you can execute your own code on the Calypso, everything becomes possible once again. At that point one can trivially reverse the bootloader lock by erasing flash sector 0 and rewriting it with 0xDDDDDDDD in the 0x2060 word, or even better, rewriting this boot sector with an older version of the boot code that lacks the locking malfeature altogether. In the FreeCalypso suite the tfc139 host utility performs the break-in using the RVTMUX TM memory write and stack smashing method just described. The "shellcode" injected by tfc139 re-enables the Calypso chip's own boot ROM and jumps to it; this boot ROM will endlessly wait for a serial download because the word at 0x2000 contains neither 0 nor 1 (it is part of an identifying ASCII string in Mot/Compal's fw), and the operator can then run fc-loadtool to perform arbitrary flash operations.