FreeCalypso > hg > freecalypso-tools

comparison doc/Compal-unlock @ 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 21eec7569eb8
comparison
equal deleted inserted replaced
-1:000000000000 0:e7502631a0f9
1 Using FreeCalypso tools to unlock Motorola C1xx phones
2 ======================================================
3
4 The ultimate goal of the FreeCalypso project is to produce our own complete GSM
5 dumbphone firmware which We the People fully own, control and compile from
6 source ourselves, running at first on some selected pre-existing hardware
7 targets, and then ultimately on our own Free Dumb Phone hardware. While that
8 goal is still far past the visible horizon, what can we do in the meantime to
9 make our current forced use of existing proprietary dumbphone firmwares a
10 little more tolerable? This article presents one such hack: using FreeCalypso
11 loadtools to dump the flash content of Compal phones for analysis, including
12 TIFFS, and to replace one existing proprietary fw version with another, e.g.,
13 to remove carrier branding and the associated SIM restriction.
14
15 Serial access
16
17 Mot C1xx (Compal) phones have a 2.5 mm headset jack that dual-functions as a
18 debug/programming serial port. In hardware terms, there is an electrically
19 controlled switch (MUX) inside that switches the external jack between the
20 analog headset signals and the digital serial ones; this switch is controlled
21 by a GPIO signal from the Calypso. The hardware power-up state of this switch
22 is serial; Mot/Compal's standard fw switches it to headset upon boot, but the
23 serial setting persists long enough to use it to break into the bootloader.
24
25 Bootloader
26
27 The Calypso DBB (digital baseband) chip used in these phones has an on-chip
28 boot ROM, but it also has a hardware pin that enables or disables this boot
29 ROM, and unfortunately these phones have it disabled. If the boot ROM were
30 enabled in hardware, it would provide an unstoppable and unbrickable way to
31 take control of the device through the externally-accessible serial port like
32 we have on Openmoko and Pirelli phones, but unfortunately the hardware we have
33 available is not wired that way.
34
35 However, Mot/Compal's standard firmware on these phones includes a bootloader,
36 a part that executes before any of the rest of the fw image is allowed to
37 execute or is made use of in any way, and this Compal-specific bootloader has a
38 provision for interrupting the boot process and diverting it to an externally-
39 supplied piece of code loaded over the serial line. Older fw versions have
40 this feature enabled unconditionally, but some of the newer versions have a
41 malfeature whereby the serial boot interrupt and code download possibility may
42 be disabled. Some C1xx phones out in the wild, particularly all North American
43 C139s with TracFone branding and some of the Cingular-branded ones as well,
44 have such maliciously-locked firmware in them.
45
46 Fortunately though, these maliciously-locked firmwares (or at least all versions
47 we've encountered so far) have been found to have another hole through which we
48 can break in, as described in the TFC139-breakin article. We can exploit this
49 hole in the firmware to gain code execution access to the Calypso, and then use
50 the latter to reprogram the flash, replacing the ultra-malicious firmware with
51 some other version that, although still proprietary, is a little less evil.
52
53 Making first contact
54 ====================
55
56 If you have a C1xx phone which you are seeking to free, your first step should
57 be to try breaking in with fc-loadtool, using the Compal bootloader method.
58 With the phone powered off, but containing a charged battery (SIM present or
59 absent, doesn't matter), proceed as follows:
60
61 1. Connect the serial or USB-serial cable between your PC or other host and the
62 target phone's headset jack.
63
64 2. On the host end, run fc-loadtool like this:
65
66 C11x/123: fc-loadtool -h compal /dev/ttyXXX
67 C139/140: fc-loadtool -h compal -c 1003 /dev/ttyXXX
68 C155/156: fc-loadtool -h c155 /dev/ttyXXX
69
70 3. Press the power button on the phone. A momentary press is sufficient and
71 recommended: the hardware powers up and causes the boot code to run exactly
72 the same whether the power button is pressed momentarily or held down.
73
74 Normal phone power-up requires the button to be held down because the
75 standard firmware does a check fairly late in the boot process to see if the
76 power button is still held down, and commands the hardware (the ABB) to
77 power off if it is not - it is a standard feature to prevent phones from
78 turning themselves on inadvertently from accidental momentary presses of
79 that button. But if the goal is to cause the boot code to run, but not to
80 boot the regular fw all the way, a momentary press is ideal.
81
82 If your phone has a bootloader without the malicious lock in it, the above
83 procedure should result in fc-loadtool gaining full access to the target and
84 landing you at a loadtool> prompt. You can dump the flash content and analyse
85 it, etc. If you would like to change to a different fw version (to remove the
86 SIM lock / carrier branding or for any other reason), see the corresponding
87 later section of this article.
88
89 Alternative method
90 ==================
91
92 If the above procedure fails to gain access to the Calypso because the boot
93 code in the phone never offers a serial download opportunity, the alternate
94 break-in method should be tried, going through the full running firmware
95 instead of just the bootloader part thereof. Proceed as follows:
96
97 1. Remove the SIM (if there was one to begin with) and put the charged battery
98 back in. Charge the battery if necessary, using the standard charging
99 function of the existing fw.
100
101 2. Power the phone up for normal boot: hold the power button down like a
102 regular user would, without fc-loadtool or other serial break-in tools.
103 The fw will boot up, notice the lack of a SIM, and the display will read
104 "SIM card absent" or something to that effect, depending on the fw version.
105
106 3. Key in this magic sequence: **16379#. A hidden "Trace Switch" menu should
107 appear, with the choices being "Trace On" and "Earphone". Select "Trace On".
108 The electrically controlled hardware switch mentioned earlier in this article
109 should now be set back to the UART, bringing the latter out to the headset
110 jack. Because Mot/Compal's firmware is based on TI's reference architecture,
111 the interface presented by the running fw on this serial port is TI's RVTMUX,
112 albeit at 57600 baud instead of TI's default of 115200.
113
114 4. Connect the headset jack serial cable if it wasn't already connected, and
115 run this FreeCalypso utility:
116
117 tfc139 /dev/ttyXXX
118
119 (The name tfc139 is historical; the current version is expected to work with
120 all Mot C1xx firmwares.)
121
122 Compal's TI-based firmware implements some of TI's Test Mode commands, and one
123 of these commands is a raw memory write. It also implements some of TI's GPF
124 "system primitive" commands, including the MEMCHECK command that causes the
125 firmware to report some info on all running GPF tasks, including the location
126 of each task's stack. Our tfc139 utility will try to break into the phone
127 (gain code execution access) by querying the target fw for the location of the
128 L1A task's stack, and then using Test Mode memory write commands to write a
129 piece of shellcode into an unused RAM location and to make this code execute by
130 overwriting a function return address on the stack of the L1A task that
131 processes these Test Mode commands.
132
133 If the stack smashing hack succeeds, the shellcode injected by tfc139 will send
134 a message out the serial port indicating this success, and then re-enable the
135 Calypso boot ROM and jump to it. Once the boot ROM code gains control, it will
136 wait forever for a serial code download following its standard protocol. If
137 tfc139 gets the success indication from the target, it will announce this
138 success and direct you to run:
139
140 fc-loadtool -h compal -c none /dev/ttyXXX
141
142 Do as it says. The -c none option tells fc-loadtool to skip compalstage and
143 proceed directly to feeding loadagent to the Calypso boot ROM. You should now
144 be in full control of the phone via fc-loadtool.
145
146 There is one additional quirk worth mentioning. It appears that Mot/Compal's
147 main fw keeps resetting the RTC alarm registers in the Calypso DBB as it runs,
148 always keeping the alarm time in the near future relative to the current time.
149 When one breaks into this firmware with tfc139 and takes over the control of
150 the device with fc-loadtool, this alarm time will almost certainly be reached,
151 and the RTC alarm will go off. This alarm has no effect on loadtool operation
152 (i.e., it cannot reset the CPU or otherwise wrestle control away from loadtool,
153 so it doesn't add any bricking risk), but it has one quite surprising effect
154 upon exit, i.e., when you are done with your loadtool session and give it the
155 exit command.
156
157 Loadtool's configured default exit action for this target is to send a power-off
158 command to the Iota ABB, leaving the device cleanly powered off. However, if
159 the RTC alarm has gone off previously during the session, the ABB will instantly
160 power the phone back on, and put it through a new boot cycle. The firmware
161 handles this special form of boot rather oddly: it proceeds to the same end
162 state it would have reached via a normal power button hold-down boot (powered
163 on with the "Insert SIM" message on the LCD), but it reaches this state almost
164 instantly, without going through the power-on LCD logo and buzz phase. Odd,
165 but harmless. This explanation has been included to save other hackers the
166 hours of bewildered head-scratching I spent chasing this quirk down.
167
168 Dumping and reloading flash
169 ===========================
170
171 Once you break in with fc-loadtool (either through the bootloader or through
172 tfc139), the first step you should do is make a dump (backup) of the flash:
173
174 loadtool> flash dump2bin flashdump.bin
175
176 Before you do any flash write (erase or program) operations, please realise
177 that these phones are brickable. Because the Calypso boot ROM is disabled at
178 the board level (Calypso DBB's nIBOOT configuration input is tied high directly
179 underneath the BGA package!), when the phone powers up, the ARM7 core starts
180 executing instructions directly out of the flash, from address 0. Therefore,
181 flash sector 0 must contain good working boot code (one that allows serial code
182 download access for recovery) at all times. If you erase this sector or fill
183 it with some garbage (anything other than good working boot code) and then power
184 the phone off or otherwise lose control of it, the phone will be unrecoverably
185 bricked!
186
187 On most C1xx models there seems to be no way to access the Calypso's JTAG
188 signals, hence no possibility of using JTAG to unbrick a bricked phone. And
189 because the flash chip is a micro-BGA, it is quite unlikely that one could
190 successfully desolder it, program it in a standalone flash chip programmer,
191 and then put it back on the board. Thus if you brick your C1xx phone, then
192 most likely it is truly toast. You've been warned!
193
194 That being said, if your phone came with a maliciously locked bootloader, such
195 that you had to use tfc139 to break in, then replacing that bootloader with a
196 non-malware version is pretty much a necessity, and taking the chance of
197 bricking the phone becomes a necessary risk. Even if the bootloader version in
198 your C1xx is free of the locking malfeature, if you need to reflash the main fw
199 to a different version, one still needs to erase and reprogram the dangerous
200 sector: on C11x/123 and C139/140 the main fw image starts at 0x2000, but the
201 erase block boundary doesn't come until 0x10000.
202
203 The good news, however, is that fc-loadtool has special support for rewriting
204 the boot sector on Compal phones with minimal risk of bricking. The command is:
205
206 flash erase-program-boot binfile [length]
207
208 The first argument is the name of the file (in straight binary format)
209 containing the new boot code; the second argument (always interpreted as hex)
210 is the number of bytes to program, always starting at 0. If only one argument
211 is given, the length of the file is used instead, which must not exceed the
212 length of flash sector 0: 64 KiB on C11x/123 and C139/140, or 8 KiB on C155/156.
213
214 This special command minimizes the bricking vulnerability window by loading the
215 entirety of the new boot code to be programmed into a scratchpad RAM buffer on
216 the target first (no problem because it's 64 KiB max), then commanding loadagent
217 (the code that actually runs on the Calypso when you use fc-loadtool) to perform
218 the "atomic" operation of erasing flash sector 0, then immediately reprogramming
219 it with the bits that are already in scratchpad RAM on the phone.
220
221 With this approach the phone will only be bricked if the battery dies or is
222 physically yanked out of the phone in the time window between the beginning of
223 the erase operation and the last critical bit of the new boot code being
224 programmed - on the order of a second or two, or if the flash operations fail
225 for some reason. However, the phone will *not* be bricked with this approach
226 if the serial connection between fc-loadtool or the target gets broken during
227 the window in question, or if the host machine running fc-loadtool crashes: no
228 flash operations start until loadtool gives the go-ahead command to loadagent,
229 and once loadagent receives the latter command, it will proceed till completion
230 without caring if loadtool is still there or not.
231
232 Of course the conventional flash erase and flash program-bin commands will be
233 happy to operate on flash sector 0 just like any other sector, but doing so is
234 NOT recommended, as the window of vulnerability for bricking would then be
235 considerably greater.
236
237 Unlocked firmware for C139
238 ==========================
239
240 If your phone is a North American (1900+850 MHz) C139, and you are reading this
241 article because it came with Cingular or TracFone branding, whereas you would
242 like to use it with SIMs and networks of your own choosing instead, you've come
243 to the right place. We have an unlocked and non-carrier-branded (Mot branding
244 only) version of the fw that runs on these phones, and you can use FreeCalypso
245 loadtools to flash this version into your C139 whether it came with Cingular or
246 TF branding originally. Download this file:
247
248 ftp.freecalypso.org:/pub/GSM/Compal/c139-unlocked-fw.zip
249
250 Unzip it, and you'll get c139-unlocked-fw.bin - that is the image you'll need
251 to flash into your phone. Get in with fc-loadtool (using tfc139 if necessary
252 for bootloader-locked phones) and make a backup of the original flash content.
253 Then reflash the firmware as follows:
254
255 flash erase-program-boot c139-unlocked-fw.bin 2000
256 flash erase 10000 360000
257 flash program-bin 2000 c139-unlocked-fw.bin 2000
258
259 The 3 commands given above will reflash the phone as follows:
260
261 * The first 0x2000 bytes of the firmware image in c139-unlocked-fw.bin comprise
262 the boot code. This fw version features the "good" boot code *without* the
263 access locking malfeature. The erase-program-boot command will erase flash
264 sector 0 (the entire 64 KiB sector, as the physics of the flash chip dictates)
265 and then immediately reprogram its first 8 KiB with the "good" boot code from
266 the unlocked fw image file. The remaining 56 KiB of this sector will be blank
267 after this step.
268
269 * The following "regular" flash erase command is to erase the following 54
270 sectors (also of 64 KiB each) in preparation for programming the main fw
271 image in there.
272
273 * The last command programs the bulk of the fw image into blank flash that has
274 been erased by the first two commands.
275
276 I also recommend erasing the old FFS that was maintained by the old fw version,
277 so that the new fw will automatically format a "virgin" FFS the first time it
278 boots:
279
280 flash erase 370000 50000
281
282 After this procedure the phone should retain its original IMEI and factory RF
283 calibration values, as these are stored in the 8 KiB sector at 0x3FC000 which
284 is not touched per the above procedure - not in the FFS.
285
286 The same procedure should be followed for flashing all firmwares for C11x/123
287 and C139/140 phones. In the case of C11x/123, adjust the length for the "main"
288 erase and program operations appropriately for the flash configuration in your
289 phone.
290
291 Flashing newer firmware versions
292 ================================
293
294 The flashing procedure given above, where the first 0x2000 bytes of the new fw
295 image (the bootloader part) are written with the flash erase-program-boot
296 command and the regular flash program-bin command writes everything from 0x2000
297 onward, is only correct for older firmware versions whose bootloader portion is
298 completely free from the access locking malfeature: not only unlocked, but with
299 no provision for locking at all. In these older fw versions the boot code is
300 fully contained in the first 0x2000 bytes and nothing from 0x2000 onward affects
301 the ability to perform a new serial boot, hence the bricking vulnerability
302 window ends at 0x2000. However, this flashing procedure should NOT be used for
303 newer fw versions that have the provision for locking the bootloader - it's the
304 provision that matters in this case, even if the lock hasn't been activated -
305 if you flash one of these newer fw versions as above, you will risk bricking
306 your phone!
307
308 If you need to flash one of the newer fw versions that includes the bootloader
309 lock provision, you need to take some additional precautionary steps:
310
311 1. Examine the fw image you wish to flash with a hex dump viewer. Look starting
312 at offset 0x2000. You should see 3 identifying ASCII strings: one right at
313 0x2000, another at 0x2020 and one more at 0x2040. Then look at 4 bytes at
314 offset 0x2060. If they contain 0xFFFFFFFF (blank flash) like the surrounding
315 unused bytes, then you have an older fw version without the bootloader lock
316 provision - you can safely flash it as in the previous section. If it's a
317 newer fw version with the bootloader lock provision, the word at 0x2060 will
318 contain either 0x00000000 or 0xDDDDDDDD, corresponding to the activated
319 (access disabled) and non-activated (access enabled) states of the lock,
320 respectively.
321
322 2. If the fw image you wish to flash has 0x00000000 at 0x2060, you must patch
323 it to 0xDDDDDDDD with a hex editor before flashing. Just because our tfc139
324 utility can recover phones with maliciously locked bootloaders does NOT mean
325 that you should *ever* deliberately flash such a bootloader-locked fw image
326 into your phone! Recovery of locked phones via tfc139 depends on the
327 complete fw image being present and working, not just the bootloader part,
328 hence if you were to flash an image that has a lockable bootloader with the
329 lock activated, the bricking vulnerability window will extend until the
330 *entire* fw image has been programmed - far too dangerous.
331
332 3. When flashing the image with fc-loadtool, use a slightly different command
333 sequence compared to the previous section:
334
335 flash erase-program-boot new-fw-image.bin 10000
336 flash erase 10000 360000
337 flash program-bin 10000 new-fw-image.bin 10000 360000
338
339 The difference is that the boundary between the part handled with flash
340 erase-program-boot and the part handled with flash program-bin has been moved
341 from 0x2000 to 0x10000. Because the word at 0x2060 is part of the bricking
342 vulnerability window with these newer fw versions, one should rewrite the
343 entire boot sector of the flash (including the beginning of the main fw image)
344 with flash erase-program-boot for safety.
345
346 Unlocking while keeping the same fw version
347 ===========================================
348
349 Suppose you have a phone with a locked bootloader such that you had to break in
350 with tfc139, you would like to unlock it so you can use RAM-based (non-flash)
351 tools such as c139explore or OsmocomBB with it, but you have no particular need
352 to change the main fw from the original version to a different one. If you
353 need to perform such a cisversion unlock, you can do it as follows:
354
355 1. Break in with tfc139;
356 2. Use fc-loadtool's flash dump2bin command to save the first 64 KiB sector
357 of the flash to a file;
358 3. Using a hex editor, patch the word at 0x2060 from 0x00000000 to 0xDDDDDDDD;
359 4. Use fc-loadtool's flash erase-program-boot command to flash the patched
360 (unlocked) boot sector back into the phone.
361
362 C155/156 differences
363 ====================
364
365 C155/156 phones are nicer than the others in that they use a flash chip with a
366 "bottom boot" configuration. C11x/123 and C139/140 use "top boot" flash chips,
367 which is why the boot code and the first 56 KiB of the main fw image live in
368 the same erase block on those phones. The boot code and the control hand-off
369 interface between it and the main fw have also been revamped in C155/156 fw,
370 and the new structure is:
371
372 8 KiB sector at 0: contains the boot code
373 7 more 8 KiB sectors starting at 0x2000: blank and unused
374 64 KiB sector at 0x10000: also blank and unused
375 64 KiB sector at 0x20000: beginning of main fw image
376
377 With this new flash layout, it is now possible to erase and program the main fw
378 region starting at 0x20000 without ever erasing the boot code sector or doing
379 any writes to it, so there is no bricking vulnerability window at all. (The
380 phone can still be bricked though if one types the wrong command and erases the
381 boot sector inadvertently, so be careful.)
382
383 So far the only phones in this family that I laid my hacking hands on have been
384 North American C156 units, all from the same seller and batch (hence identical),
385 so I don't know if there exist any maliciously-locked boot code versions in
386 this family - the boot code in my C156 is free of any malfeatures. But if "bad"
387 versions of C155/156 boot code do exist, and if you can break into the phone
388 somehow, you can use the flash erase-program-boot command to rewrite the boot
389 code with minimal risk of bricking just like on the other Compal families.