diff 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
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/Compal-unlock	Thu Jun 19 20:17:28 2014 +0000
@@ -0,0 +1,295 @@
+Using FreeCalypso tools to unlock Motorola C1xx phones
+======================================================
+
+The ultimate goal of the FreeCalypso project is to produce our own complete GSM
+dumbphone firmware which We the People fully own, control and compile from
+source ourselves, running at first on some selected pre-existing hardware
+targets, and then ultimately on our own Free Dumb Phone hardware.  While that
+goal is still far past the visible horizon, what can we do in the meantime to
+make our current forced use of existing proprietary dumbphone firmwares a
+little more tolerable?  This article presents one such hack: using FreeCalypso
+loadtools to dump the flash content of Compal phones for analysis, including
+TIFFS, and to replace one existing proprietary fw version with another, e.g.,
+to remove carrier branding and the associated SIM restriction.
+
+Serial access
+
+Mot C1xx (Compal) phones have a 2.5 mm headset jack that dual-functions as a
+debug/programming serial port.  In hardware terms, there is an electrically
+controlled switch (MUX) inside that switches the external jack between the
+analog headset signals and the digital serial ones; this switch is controlled
+by a GPIO signal from the Calypso.  The hardware power-up state of this switch
+is serial; Mot/Compal's standard fw switches it to headset upon boot, but the
+serial setting persists long enough to use it to break into the bootloader.
+
+Bootloader
+
+The Calypso DBB (digital baseband) chip used in these phones has an on-chip
+boot ROM, but it also has a hardware pin that enables or disables this boot
+ROM, and unfortunately these phones have it disabled.  If the boot ROM were
+enabled in hardware, it would provide an unstoppable and unbrickable way to
+take control of the device through the externally-accessible serial port like
+we have on Openmoko and Pirelli phones, but unfortunately the hardware we have
+available is not wired that way.
+
+However, Mot/Compal's standard firmware on these phones includes a bootloader,
+a part that executes before any of the rest of the fw image is allowed to
+execute or made use of in any way, and this Compal-specific bootloader has a
+provision for interrupting the boot process and diverting it to an externally-
+supplied piece of code loaded over the serial line.  Older fw versions have
+this feature enabled unconditionally, but some of the newer versions have a
+malfeature whereby the serial boot interrupt and code download possibility may
+be disabled.  Some C1xx phones out in the wild, particularly all North American
+C139s with TracFone branding, have such maliciously-locked firmware in them.
+
+Fortunately though, these maliciously-locked firmwares (or at least the most
+common TFC139 one) have been found to have another hole through which we can
+break in, as described here:
+
+http://lists.osmocom.org/pipermail/baseband-devel/2014-May/004451.html
+http://lists.osmocom.org/pipermail/baseband-devel/2014-May/004455.html
+
+We can exploit this hole in the TFC139 firmware to gain code execution access
+to the Calypso, and then use the latter to reprogram the flash, replacing the
+ultra-malicious firmware with some other version that, although still
+proprietary, is a little less evil.
+
+Making first contact
+====================
+
+If you have a C1xx phone which you are seeking to free, your first step should
+be to try breaking in with fc-loadtool, using the Compal bootloader method.
+With the phone powered off, but containing a charged battery (SIM present or
+absent, doesn't matter), proceed as follows:
+
+1. Connect the serial or USB-serial cable between your PC or other host and the
+   target phone's headset jack.
+
+2. On the host end, run fc-loadtool like this:
+
+C11x/123: fc-loadtool -h compal /dev/ttyXXX
+C139/140: fc-loadtool -h compal -c 1003 /dev/ttyXXX
+C155/156: fc-loadtool -h c155 /dev/ttyXXX
+
+3. Press the power button on the phone.  A momentary press is sufficient and
+   recommended: the hardware powers up and causes the boot code to run exactly
+   the same whether the power button is pressed momentarily or held down.
+
+   Normal phone power-up requires the button to be held down because the
+   standard firmware does a check fairly late in the boot process to see if the
+   power button is still held down, and commands the hardware (the ABB) to
+   power off if it is not - it is a standard feature to prevent phones from
+   turning themselves on inadvertently from accidental momentary presses of
+   that button.  But if the goal is to cause the boot code to run, but not to
+   boot the regular fw all the way, a momentary press is ideal.
+
+If your phone has a bootloader without the malicious lock in it, the above
+procedure should result in fc-loadtool gaining full access to the target and
+landing you at a loadtool> prompt.  You can dump the flash content and analyse
+it, etc.  If you would like to change to a different fw version (to remove the
+SIM lock / carrier branding or for any other reason), see the corresponding
+later section of this article.
+
+Alternative method
+==================
+
+If the above procedure fails to gain access to the Calypso because the boot
+code in the phone never offers a serial download opportunity, the alternate
+break-in method should be tried, going through the full running firmware
+instead of just the bootloader part thereof.  Proceed as follows:
+
+1. Remove the SIM (if there was one to begin with) and put the charged battery
+   back in.  Charge the battery if necessary, using the standard charging
+   function of the existing fw.
+
+2. Power the phone up for normal boot: hold the power button down like a
+   regular user would, without fc-loadtool or other serial break-in tools.
+   The fw will boot up, notice the lack of a SIM, and the display will read
+   "SIM card absent" or something to that effect, depending on the fw version.
+
+3. Key in this magic sequence: **16379#.  A hidden "Trace Switch" menu should
+   appear, with the choices being "Trace On" and "Earphone".  Select "Trace On".
+   The electrically controlled hardware switch mentioned earlier in this article
+   should now be set back to the UART, bringing the latter out to the headset
+   jack.  Because Mot/Compal's firmware is based on TI's reference architecture,
+   the interface presented by the running fw on this serial port is TI's RVTMUX,
+   albeit at 57600 baud instead of TI's default of 115200.
+
+4. Connect the headset jack serial cable if it wasn't already connected, and
+   run this FreeCalypso hack-utility:
+
+   tfc139 /dev/ttyXXX
+
+Compal's firmware has some non-standard commands of their own invention added
+to TI's RVT/ETM interface, and one of these commands is a raw memory write.
+Our tfc139 hack-utility will try to break into the phone (gain code execution
+access) by using this Compal ETM command to write a little payload into a
+particular RAM location (beginning of IRAM), and then doing more memory writes
+by the same method, seeking to smash the stack and cause control to be
+transferred to the sent payload by overwriting a function return address on the
+stack.
+
+If the stack smashing hack succeeds, the code injected by tfc139 will send a
+message out the serial port indicating this success, and then re-enable the
+Calypso boot ROM and jump to it.  Once the boot ROM code gains control, it will
+wait forever for a serial code download following its standard protocol.  If
+tfc139 gets the success indication from the target, it will announce this
+success and direct you to run:
+
+fc-loadtool -h compal -c none /dev/ttyXXX
+
+Do as it says.  The -c none option tells fc-loadtool to skip compalstage and
+proceed directly to feeding loadagent to the Calypso boot ROM.  You should now
+be in full control of the phone via fc-loadtool.
+
+Dumping and reloading flash
+===========================
+
+Once you break in with fc-loadtool (either through the bootloader or through
+tfc139), the first step you should do is make a dump (backup) of the flash:
+
+loadtool> flash dump2bin flashdump.bin
+
+Before you do any flash write (erase or program) operations, please realise
+that these phones are brickable.  Because the Calypso boot ROM is disabled at
+the board level (Calypso DBB's nIBOOT configuration input is tied high directly
+underneath the BGA package!), when the phone powers up, the ARM7 core starts
+executing instructions directly out of the flash, from address 0.  Therefore,
+flash sector 0 must contain good working boot code (one that allows serial code
+download access for recovery) at all times.  If you erase this sector or fill
+it with some garbage (anything other than good working boot code) and then power
+the phone off or otherwise lose control of it, the phone will be unrecoverably
+bricked!
+
+On most C1xx models there seems to be no way to access the Calypso's JTAG
+signals, hence no possibility of using JTAG to unbrick a bricked phone.  And
+because the flash chip is a micro-BGA, it is quite unlikely that one could
+successfully desolder it, program it in a standalone flash chip programmer,
+and then put it back on the board.  Thus if you brick your C1xx phone, then
+most likely it is truly toast.  You've been warned!
+
+That being said, if your phone came with a maliciously locked bootloader, such
+that you had to use tfc139 to break in, then replacing that bootloader with a
+non-malware version is pretty much a necessity, and taking the chance of
+bricking the phone becomes a necessary risk.  Even if the bootloader version in
+your C1xx is free of the locking malfeature, if you need to reflash the main fw
+to a different version, one still needs to erase and reprogram the dangerous
+sector: on C11x/123 and C139/140 the main fw image starts at 0x2000, but the
+erase block boundary doesn't come until 0x10000.
+
+The good news, however, is that fc-loadtool has special support for rewriting
+the boot sector on Compal phones with minimal risk of bricking.  The command is:
+
+flash erase-program-boot binfile [length]
+
+The first argument is the name of the file (in straight binary format)
+containing the new boot code; the second argument (always interpreted as hex)
+is the number of bytes to program, always starting at 0.  If only one argument
+is given, the length of the file is used instead, which must not exceed the
+length of flash sector 0: 64 KiB on C11x/123 and C139/140, or 8 KiB on C155/156.
+
+This special command minimizes the bricking vulnerability window by loading the
+entirety of the new boot code to be programmed into a scratchpad RAM buffer on
+the target first (no problem because it's 64 KiB max), then commanding loadagent
+(the code that actually runs on the Calypso when you use fc-loadtool) to perform
+the "atomic" operation of erasing flash sector 0, then immediately reprogramming
+it with the bits that are already in scratchpad RAM on the phone.
+
+With this approach the phone will only be bricked if the battery dies or is
+physically yanked out of the phone in the time window between the beginning of
+the erase operation and the last critical bit of the new boot code being
+programmed - on the order of a second or two, or if the flash operations fail
+for some reason.  However, the phone will *not* be bricked with this approach
+if the serial connection between fc-loadtool or the target gets broken during
+the window in question, or if the host machine running fc-loadtool crashes: no
+flash operations start until loadtool gives the go-ahead command to loadagent,
+and once loadagent receives the latter command, it will proceed till completion
+without caring if loadtool is still there or not.
+
+Of course the conventional flash erase and flash program-bin commands will be
+happy to operate on flash sector 0 just like any other sector, but doing so is
+NOT recommended, as the window of vulnerability for bricking would then be
+considerably greater.
+
+Unlocked firmware for C139
+==========================
+
+If your phone is a North American (1900+850 MHz) C139, and you are reading this
+article because it came with Cingular or TracFone branding, whereas you would
+like to use it with SIMs and networks of your own choosing instead, you've come
+to the right place.  We have an unlocked and non-carrier-branded (Mot branding
+only) version of the fw that runs on these phones, and you can use FreeCalypso
+loadtools to flash this version into your C139 whether it came with Cingular or
+TF branding originally.  Download this file:
+
+ftp.ifctf.org:/pub/GSM/Compal/c139-unlocked-fw.zip
+
+Unzip it, and you'll get c139-unlocked-fw.bin - that is the image you'll need
+to flash into your phone.  Get in with fc-loadtool (using tfc139 if necessary
+for locked-down Tracfones) and make a backup of the original flash content.
+Then reflash the firmware as follows:
+
+flash erase-program-boot c139-unlocked-fw.bin 2000
+flash erase 10000 360000
+flash program-bin 2000 c139-unlocked-fw.bin 2000
+
+The 3 commands given above will reflash the phone as follows:
+
+* The first 0x2000 bytes of the firmware image in c139-unlocked-fw.bin comprise
+  the boot code.  This fw version features the "good" boot code *without* the
+  access locking malfeature.  The erase-program-boot command will erase flash
+  sector 0 (the entire 64 KiB sector, as the physics of the flash chip dictates)
+  and then immediately reprogram its first 8 KiB with the "good" boot code from
+  the unlocked fw image file.  The remaining 56 KiB of this sector will be blank
+  after this step.
+
+* The following "regular" flash erase command is to erase the following 54
+  sectors (also of 64 KiB each) in preparation for programming the main fw
+  image in there.
+
+* The last command programs the bulk of the fw image into blank flash that has
+  been erased by the first two commands.
+
+I also recommend erasing the old FFS that was maintained by the old fw version,
+so that the new fw will automatically format a "virgin" FFS the first time it
+boots:
+
+flash erase 370000 50000
+
+After this procedure the phone should retain its original IMEI and factory RF
+calibration values, as these are stored in the 8 KiB sector at 0x3FC000 which
+is not touched per the above procedure - not in the FFS.
+
+The same procedure should be followed for flashing all firmwares for C11x/123
+and C139/140 phones.  In the case of C11x/123, adjust the length for the "main"
+erase and program operations appropriately for the flash configuration in your
+phone.
+
+C155/156 differences
+====================
+
+C155/156 phones are nicer than the others in that they use a flash chip with a
+"bottom boot" configuration.  C11x/123 and C139/140 use "top boot" flash chips,
+which is why the boot code and the first 56 KiB of the main fw image live in
+the same erase block on those phones.  The boot code and the control hand-off
+interface between it and the main fw have also been revamped in C155/156 fw,
+and the new structure is:
+
+8 KiB sector at 0: contains the boot code
+7 more 8 KiB sectors starting at 0x2000: blank and unused
+64 KiB sector at 0x10000: also blank and unused
+64 KiB sector at 0x20000: beginning of main fw image
+
+With this new flash layout, it is now possible to erase and program the main fw
+region starting at 0x20000 without ever erasing the boot code sector or doing
+any writes to it, so there is no bricking vulnerability window at all.  (The
+phone can still be bricked though if one types the wrong command and erases the
+boot sector inadvertently, so be careful.)
+
+So far the only phones in this family that I laid my hacking hands on have been
+North American C156 units, all from the same seller and batch (hence identical),
+so I don't know if there exist any maliciously-locked boot code versions in
+this family - the boot code in my C156 is free of any malfeatures.  But if "bad"
+versions of C155/156 boot code do exist, and if you can break into the phone
+somehow, you can use the flash erase-program-boot command to rewrite the boot
+code with minimal risk of bricking just like on the other Compal families.