FreeCalypso > hg > freecalypso-sw
comparison doc/Compal-unlock @ 425:f81a931f9172
doc/Compal-unlock write-up
author | Michael Spacefalcon <msokolov@ivan.Harhan.ORG> |
---|---|
date | Thu, 19 Jun 2014 20:17:28 +0000 |
parents | |
children | 1060bf70d95d |
comparison
equal
deleted
inserted
replaced
424:1ec83a5fa8b3 | 425:f81a931f9172 |
---|---|
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 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, have such maliciously-locked firmware in them. | |
44 | |
45 Fortunately though, these maliciously-locked firmwares (or at least the most | |
46 common TFC139 one) have been found to have another hole through which we can | |
47 break in, as described here: | |
48 | |
49 http://lists.osmocom.org/pipermail/baseband-devel/2014-May/004451.html | |
50 http://lists.osmocom.org/pipermail/baseband-devel/2014-May/004455.html | |
51 | |
52 We can exploit this hole in the TFC139 firmware to gain code execution access | |
53 to the Calypso, and then use the latter to reprogram the flash, replacing the | |
54 ultra-malicious firmware with some other version that, although still | |
55 proprietary, is a little less evil. | |
56 | |
57 Making first contact | |
58 ==================== | |
59 | |
60 If you have a C1xx phone which you are seeking to free, your first step should | |
61 be to try breaking in with fc-loadtool, using the Compal bootloader method. | |
62 With the phone powered off, but containing a charged battery (SIM present or | |
63 absent, doesn't matter), proceed as follows: | |
64 | |
65 1. Connect the serial or USB-serial cable between your PC or other host and the | |
66 target phone's headset jack. | |
67 | |
68 2. On the host end, run fc-loadtool like this: | |
69 | |
70 C11x/123: fc-loadtool -h compal /dev/ttyXXX | |
71 C139/140: fc-loadtool -h compal -c 1003 /dev/ttyXXX | |
72 C155/156: fc-loadtool -h c155 /dev/ttyXXX | |
73 | |
74 3. Press the power button on the phone. A momentary press is sufficient and | |
75 recommended: the hardware powers up and causes the boot code to run exactly | |
76 the same whether the power button is pressed momentarily or held down. | |
77 | |
78 Normal phone power-up requires the button to be held down because the | |
79 standard firmware does a check fairly late in the boot process to see if the | |
80 power button is still held down, and commands the hardware (the ABB) to | |
81 power off if it is not - it is a standard feature to prevent phones from | |
82 turning themselves on inadvertently from accidental momentary presses of | |
83 that button. But if the goal is to cause the boot code to run, but not to | |
84 boot the regular fw all the way, a momentary press is ideal. | |
85 | |
86 If your phone has a bootloader without the malicious lock in it, the above | |
87 procedure should result in fc-loadtool gaining full access to the target and | |
88 landing you at a loadtool> prompt. You can dump the flash content and analyse | |
89 it, etc. If you would like to change to a different fw version (to remove the | |
90 SIM lock / carrier branding or for any other reason), see the corresponding | |
91 later section of this article. | |
92 | |
93 Alternative method | |
94 ================== | |
95 | |
96 If the above procedure fails to gain access to the Calypso because the boot | |
97 code in the phone never offers a serial download opportunity, the alternate | |
98 break-in method should be tried, going through the full running firmware | |
99 instead of just the bootloader part thereof. Proceed as follows: | |
100 | |
101 1. Remove the SIM (if there was one to begin with) and put the charged battery | |
102 back in. Charge the battery if necessary, using the standard charging | |
103 function of the existing fw. | |
104 | |
105 2. Power the phone up for normal boot: hold the power button down like a | |
106 regular user would, without fc-loadtool or other serial break-in tools. | |
107 The fw will boot up, notice the lack of a SIM, and the display will read | |
108 "SIM card absent" or something to that effect, depending on the fw version. | |
109 | |
110 3. Key in this magic sequence: **16379#. A hidden "Trace Switch" menu should | |
111 appear, with the choices being "Trace On" and "Earphone". Select "Trace On". | |
112 The electrically controlled hardware switch mentioned earlier in this article | |
113 should now be set back to the UART, bringing the latter out to the headset | |
114 jack. Because Mot/Compal's firmware is based on TI's reference architecture, | |
115 the interface presented by the running fw on this serial port is TI's RVTMUX, | |
116 albeit at 57600 baud instead of TI's default of 115200. | |
117 | |
118 4. Connect the headset jack serial cable if it wasn't already connected, and | |
119 run this FreeCalypso hack-utility: | |
120 | |
121 tfc139 /dev/ttyXXX | |
122 | |
123 Compal's firmware has some non-standard commands of their own invention added | |
124 to TI's RVT/ETM interface, and one of these commands is a raw memory write. | |
125 Our tfc139 hack-utility will try to break into the phone (gain code execution | |
126 access) by using this Compal ETM command to write a little payload into a | |
127 particular RAM location (beginning of IRAM), and then doing more memory writes | |
128 by the same method, seeking to smash the stack and cause control to be | |
129 transferred to the sent payload by overwriting a function return address on the | |
130 stack. | |
131 | |
132 If the stack smashing hack succeeds, the code injected by tfc139 will send a | |
133 message out the serial port indicating this success, and then re-enable the | |
134 Calypso boot ROM and jump to it. Once the boot ROM code gains control, it will | |
135 wait forever for a serial code download following its standard protocol. If | |
136 tfc139 gets the success indication from the target, it will announce this | |
137 success and direct you to run: | |
138 | |
139 fc-loadtool -h compal -c none /dev/ttyXXX | |
140 | |
141 Do as it says. The -c none option tells fc-loadtool to skip compalstage and | |
142 proceed directly to feeding loadagent to the Calypso boot ROM. You should now | |
143 be in full control of the phone via fc-loadtool. | |
144 | |
145 Dumping and reloading flash | |
146 =========================== | |
147 | |
148 Once you break in with fc-loadtool (either through the bootloader or through | |
149 tfc139), the first step you should do is make a dump (backup) of the flash: | |
150 | |
151 loadtool> flash dump2bin flashdump.bin | |
152 | |
153 Before you do any flash write (erase or program) operations, please realise | |
154 that these phones are brickable. Because the Calypso boot ROM is disabled at | |
155 the board level (Calypso DBB's nIBOOT configuration input is tied high directly | |
156 underneath the BGA package!), when the phone powers up, the ARM7 core starts | |
157 executing instructions directly out of the flash, from address 0. Therefore, | |
158 flash sector 0 must contain good working boot code (one that allows serial code | |
159 download access for recovery) at all times. If you erase this sector or fill | |
160 it with some garbage (anything other than good working boot code) and then power | |
161 the phone off or otherwise lose control of it, the phone will be unrecoverably | |
162 bricked! | |
163 | |
164 On most C1xx models there seems to be no way to access the Calypso's JTAG | |
165 signals, hence no possibility of using JTAG to unbrick a bricked phone. And | |
166 because the flash chip is a micro-BGA, it is quite unlikely that one could | |
167 successfully desolder it, program it in a standalone flash chip programmer, | |
168 and then put it back on the board. Thus if you brick your C1xx phone, then | |
169 most likely it is truly toast. You've been warned! | |
170 | |
171 That being said, if your phone came with a maliciously locked bootloader, such | |
172 that you had to use tfc139 to break in, then replacing that bootloader with a | |
173 non-malware version is pretty much a necessity, and taking the chance of | |
174 bricking the phone becomes a necessary risk. Even if the bootloader version in | |
175 your C1xx is free of the locking malfeature, if you need to reflash the main fw | |
176 to a different version, one still needs to erase and reprogram the dangerous | |
177 sector: on C11x/123 and C139/140 the main fw image starts at 0x2000, but the | |
178 erase block boundary doesn't come until 0x10000. | |
179 | |
180 The good news, however, is that fc-loadtool has special support for rewriting | |
181 the boot sector on Compal phones with minimal risk of bricking. The command is: | |
182 | |
183 flash erase-program-boot binfile [length] | |
184 | |
185 The first argument is the name of the file (in straight binary format) | |
186 containing the new boot code; the second argument (always interpreted as hex) | |
187 is the number of bytes to program, always starting at 0. If only one argument | |
188 is given, the length of the file is used instead, which must not exceed the | |
189 length of flash sector 0: 64 KiB on C11x/123 and C139/140, or 8 KiB on C155/156. | |
190 | |
191 This special command minimizes the bricking vulnerability window by loading the | |
192 entirety of the new boot code to be programmed into a scratchpad RAM buffer on | |
193 the target first (no problem because it's 64 KiB max), then commanding loadagent | |
194 (the code that actually runs on the Calypso when you use fc-loadtool) to perform | |
195 the "atomic" operation of erasing flash sector 0, then immediately reprogramming | |
196 it with the bits that are already in scratchpad RAM on the phone. | |
197 | |
198 With this approach the phone will only be bricked if the battery dies or is | |
199 physically yanked out of the phone in the time window between the beginning of | |
200 the erase operation and the last critical bit of the new boot code being | |
201 programmed - on the order of a second or two, or if the flash operations fail | |
202 for some reason. However, the phone will *not* be bricked with this approach | |
203 if the serial connection between fc-loadtool or the target gets broken during | |
204 the window in question, or if the host machine running fc-loadtool crashes: no | |
205 flash operations start until loadtool gives the go-ahead command to loadagent, | |
206 and once loadagent receives the latter command, it will proceed till completion | |
207 without caring if loadtool is still there or not. | |
208 | |
209 Of course the conventional flash erase and flash program-bin commands will be | |
210 happy to operate on flash sector 0 just like any other sector, but doing so is | |
211 NOT recommended, as the window of vulnerability for bricking would then be | |
212 considerably greater. | |
213 | |
214 Unlocked firmware for C139 | |
215 ========================== | |
216 | |
217 If your phone is a North American (1900+850 MHz) C139, and you are reading this | |
218 article because it came with Cingular or TracFone branding, whereas you would | |
219 like to use it with SIMs and networks of your own choosing instead, you've come | |
220 to the right place. We have an unlocked and non-carrier-branded (Mot branding | |
221 only) version of the fw that runs on these phones, and you can use FreeCalypso | |
222 loadtools to flash this version into your C139 whether it came with Cingular or | |
223 TF branding originally. Download this file: | |
224 | |
225 ftp.ifctf.org:/pub/GSM/Compal/c139-unlocked-fw.zip | |
226 | |
227 Unzip it, and you'll get c139-unlocked-fw.bin - that is the image you'll need | |
228 to flash into your phone. Get in with fc-loadtool (using tfc139 if necessary | |
229 for locked-down Tracfones) and make a backup of the original flash content. | |
230 Then reflash the firmware as follows: | |
231 | |
232 flash erase-program-boot c139-unlocked-fw.bin 2000 | |
233 flash erase 10000 360000 | |
234 flash program-bin 2000 c139-unlocked-fw.bin 2000 | |
235 | |
236 The 3 commands given above will reflash the phone as follows: | |
237 | |
238 * The first 0x2000 bytes of the firmware image in c139-unlocked-fw.bin comprise | |
239 the boot code. This fw version features the "good" boot code *without* the | |
240 access locking malfeature. The erase-program-boot command will erase flash | |
241 sector 0 (the entire 64 KiB sector, as the physics of the flash chip dictates) | |
242 and then immediately reprogram its first 8 KiB with the "good" boot code from | |
243 the unlocked fw image file. The remaining 56 KiB of this sector will be blank | |
244 after this step. | |
245 | |
246 * The following "regular" flash erase command is to erase the following 54 | |
247 sectors (also of 64 KiB each) in preparation for programming the main fw | |
248 image in there. | |
249 | |
250 * The last command programs the bulk of the fw image into blank flash that has | |
251 been erased by the first two commands. | |
252 | |
253 I also recommend erasing the old FFS that was maintained by the old fw version, | |
254 so that the new fw will automatically format a "virgin" FFS the first time it | |
255 boots: | |
256 | |
257 flash erase 370000 50000 | |
258 | |
259 After this procedure the phone should retain its original IMEI and factory RF | |
260 calibration values, as these are stored in the 8 KiB sector at 0x3FC000 which | |
261 is not touched per the above procedure - not in the FFS. | |
262 | |
263 The same procedure should be followed for flashing all firmwares for C11x/123 | |
264 and C139/140 phones. In the case of C11x/123, adjust the length for the "main" | |
265 erase and program operations appropriately for the flash configuration in your | |
266 phone. | |
267 | |
268 C155/156 differences | |
269 ==================== | |
270 | |
271 C155/156 phones are nicer than the others in that they use a flash chip with a | |
272 "bottom boot" configuration. C11x/123 and C139/140 use "top boot" flash chips, | |
273 which is why the boot code and the first 56 KiB of the main fw image live in | |
274 the same erase block on those phones. The boot code and the control hand-off | |
275 interface between it and the main fw have also been revamped in C155/156 fw, | |
276 and the new structure is: | |
277 | |
278 8 KiB sector at 0: contains the boot code | |
279 7 more 8 KiB sectors starting at 0x2000: blank and unused | |
280 64 KiB sector at 0x10000: also blank and unused | |
281 64 KiB sector at 0x20000: beginning of main fw image | |
282 | |
283 With this new flash layout, it is now possible to erase and program the main fw | |
284 region starting at 0x20000 without ever erasing the boot code sector or doing | |
285 any writes to it, so there is no bricking vulnerability window at all. (The | |
286 phone can still be bricked though if one types the wrong command and erases the | |
287 boot sector inadvertently, so be careful.) | |
288 | |
289 So far the only phones in this family that I laid my hacking hands on have been | |
290 North American C156 units, all from the same seller and batch (hence identical), | |
291 so I don't know if there exist any maliciously-locked boot code versions in | |
292 this family - the boot code in my C156 is free of any malfeatures. But if "bad" | |
293 versions of C155/156 boot code do exist, and if you can break into the phone | |
294 somehow, you can use the flash erase-program-boot command to rewrite the boot | |
295 code with minimal risk of bricking just like on the other Compal families. |