FreeCalypso > hg > freecalypso-tools

comparison doc/TFC139-breakin @ 0:e7502631a0f9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 11 Jun 2016 00:13:35 +0000
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:e7502631a0f9
1 Maliciously locked bootloader
2 =============================
3
4 When Compal (Motorola's ODM who designed and built their C1xx phones for them)
5 designed the firmware architecture and flash memory layout for their phones,
6 they made a bad design decision by putting the boundary between their bootloader
7 and the main fw image at 0x2000, even though the flash erase block boundary
8 doesn't come until 0x10000 - thus every time the main fw needs to be reflashed
9 to a different version, the dangerous boot sector has to be reflashed too.
10
11 But then they made things even worse in the newer versions of their fw by
12 introducing a bootloader lock malfeature whereby the ability to interrupt boot
13 and load code serially may be artificially disabled. This malfeature is
14 implemented as follows:
15
16 * In the original firmware layout (before the addition of the malfeature in
17 question) the boot code occupies the flash range from 0 through 0x1FFF, then
18 there are some ID strings at 0x2000, 0x2020 and 0x2040, and then the part of
19 the firmware that used to be at 0x10000 in TI's reference fw starts at 0x20A0,
20 with the entry point at 0x20F8 (corresponding to TI's 0x10058).
21
22 With the addition of the bootloader lock malfeature the 32-bit word at 0x2060
23 (previously unused and filled with 0xFFFFFFFF) became a control word telling
24 the bootloader whether diversion of the boot path to serial code download
25 should be allowed or not.
26
27 * When firmware images with this malfeature present are first built, the word
28 at 0x2060 contains 0xDDDDDDDD. (Does D stand for debug or development, or
29 was the developer who implemented this malfeature fascinated by large bra
30 cups? We may never know.) This word MUST read as 0xDDDDDDDD in order for
31 the boot code to allow serial download: if it reads as any other value (e.g.,
32 if it contains 0xFFFFFFFF because only the 8192 byte boot code has been
33 programmed into flash sector 0, with blank flash from 0x2000 onward), no
34 serial download opportunity will ever be offered and the phone is effectively
35 bricked!
36
37 * For as long as the word at 0x2060 still contained 0xDDDDDDDD, Compal's
38 developers could continue gaining access through the bootloader and reflashing
39 their firmware. But when phones were to be shipped to customers with the
40 malicious bootloader lock activated, they probably sent some Test Mode command
41 (see RVTMUX write-up) to their running fw that caused it to write 0x00000000
42 into the flash word at 0x2060. (Remember that any bit in a NOR flash memory
43 can be programmed from 1 to 0 at any time in any combination, but changing
44 bits from 0 back to 1 is only possible with full sector erasure.)
45
46 * Once the word at 0x2060 has been programmed (in the flash memory sense) from
47 0xDDDDDDDD down to 0x00000000, the phone is irreversibly locked and has lost
48 its ability to ever run a different firmware version, like a kamikaze pilot's
49 plane that has discarded its landing gear and can only crash now.
50
51 Recovery procedure
52 ==================
53
54 While it probably was Compal's, Motorola's and various carriers' intent that the
55 bootloader lock on their phones be truly irreversible, the unlocking community
56 has now developed a method for recovering these phones (restoring their ability
57 to run any firmware of the user's choice) which (we hope) will work with all of
58 the existing locked-down firmware versions. It works as follows:
59
60 * Even though the bootloader is locked down, if one boots the full fw regularly,
61 one can still access the RVTMUX interface which the TI-based fw implements
62 for debug trace and factory programming functions. One needs to key in the
63 magic sequence **16379# into the running fw, and a hidden menu will appear,
64 giving the operator the option to enable trace. Selecting this option will
65 cause the fw to switch the headset jack to the UART carrying RVTMUX.
66
67 * Mot/Compal's firmware is based on a quite old version of TI's chipset
68 reference fw (relative to late TCS211 from the Openmoko/Pirelli era), and it
69 does not feature the Enhanced Test Mode (ETM) component with which we are
70 most familiar. However, it does implement the older set of non-enhanced
71 Test Mode commands, and these TM commands just happen to include raw memory
72 read and write operations at an arbitrary address. (For a while we were
73 under a mistaken belief that these commands were Compal's inventions, until
74 we discovered TI's original TM predating ETM.)
75
76 * The ability to write arbitrary bytes into arbitrary RAM locations while the
77 phone firmware is running means that we can inject a piece of shellcode into
78 an unused RAM location and then cause this shellcode to gain execution by
79 overwriting a function return address on the stack.
80
81 * Once you can execute your own code on the Calypso, everything becomes possible
82 once again. At that point one can trivially reverse the bootloader lock by
83 erasing flash sector 0 and rewriting it with 0xDDDDDDDD in the 0x2060 word,
84 or even better, rewriting this boot sector with an older version of the boot
85 code that lacks the locking malfeature altogether.
86
87 Procedure variations: old mot931c.exe vs. new tfc139
88 ====================================================
89
90 We first became aware of the possibility of recovering locked-down phones as
91 described above in the spring of 2014 when FreeCalypso developer Space Falcon
92 became aware of the existence of Windows utility mot931c.exe (binary w/o source)
93 that performs a variant of this unlocking procedure specific to one particular
94 locked-down firmware version: C139 phones with TracFone branding, fw version
95 8.8.17. At first we had replicated the operation of this Windows tool verbatim
96 in our own Unix/Linux-based tfc139 libre tool; this variant of the shellcode-
97 based unlocking procedure worked well on TFC139 units, but could not crack other
98 locked-down fw versions, e.g., Cingular-branded C139 phones with fw version
99 1.9.24.
100
101 Subsequent investigation revealed that whoever wrote that mot931c.exe Windows
102 tool had not studied the operation of Motorola/Compal's TI-based firmware deeply
103 enough, and implemented their shellcode injection quite suboptimally: the stack
104 smashing process is hitting the wrong stack (not the stack of the L1A task in
105 whose context the Test Mode commands sent over the UART are executing), and it
106 is only through dumb luck that this version of the break-in procedure worked
107 at all. The limitation of working only with one specific fw version results
108 from this poor method of shellcode injection (mindless choice of the wrong stack
109 for smashing), and instead of adapting it in a version-specific manner to other
110 particular locked-down fw versions at hand, I (Space Falcon) reimplemented our
111 tfc139 utility to smash the right stack (that of the L1A task), and thereby
112 made it generic to all Mot C1xx firmware versions.
113
114 Our Compal firmware break-in utility is still called tfc139, but it is no longer
115 specific to TFC139 phones; instead it should work with all Mot C1xx firmwares.
116 The shellcode injected by tfc139 re-enables the Calypso chip's own boot ROM and
117 jumps to it; this boot ROM will endlessly wait for a serial download because
118 the word at 0x2000 contains neither 0 nor 1 (it is part of an identifying ASCII
119 string in Mot/Compal's fw), and the operator can then run fc-loadtool to
120 perform arbitrary flash operations.