--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/TFC139-breakin	Sun Nov 15 03:47:19 2015 +0000
@@ -0,0 +1,95 @@
+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.