Locked C139 bootloader reverse-engineered

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Michael Spacefalcon msokolov at ivan.Harhan.ORG
Thu May 15 21:52:55 UTC 2014


Hello fellow hackers,

Following my successful reverse eng of Tracfone "unlocking" utility
mot931c.exe, I wrote a native Unix/Linux program (tfc139, based on
FreeCalypso rvinterf tools) that breaks into locked-down TF C139
phones in the same fashion, with an IRAM payload that enables and
jumps to the Calypso boot ROM.  Doing so allowed me to run fc-loadtool
against one of these Tracfones that still has its original locked-down
bootloader intact (*not* overwritten with mot931c), and make a dump of
the latter for examination.

So here is how the bootloader lock works: the bootloader which sits in
the first 0x2000 bytes of flash sector 0 is clearly built together
with the main fw image as a single whole (TI's reference firmware is
built the same way, so no surprise), and thus the bootloader version
changes in sync with the main fw version.  Most of the versions seen
in the wild are almost byte-identical, the only diffs being some
unused signature (?) words at 0x20 and the word at 0x964 giving the
initial value to be loaded into the stack pointer - variations in the
latter are a linker artifact resulting from how this bootloader is
built together with the main fw.

Despite the way in which they must have been compiled, the older
versions of the bootloader have one good quality: if you are going to
break into the bootloader serially (in our familiar way), then only
the first 0x2000 bytes of the flash (in fact, even less than that)
need to be good; the flash from 0x2000 onward can be blank or filled
with garbage or malware or whatever - as long as the boot process is
interrupted with a serial download, the jump to 0x20f8 doesn't happen
and nothing from 0x2000 onward affects anything.  So far, so good.

But the newer versions of the bootloader that are part of the newer
firmwares for both C11x/123 and C139/140 have an added malicious
feature.  Before sending what we call PROMPT1 out the serial port and
waiting for a possible serial download, the boot code now checks the
word in flash at 0x2060.  This word needs to equal 0xDDDDDDDD (was it
some developer's fascination with bras? - scnr); if this word contains
any other value, no serial download opportunity is offered, and the
code proceeds directly to the silly routine that emits that "ftmtool
error" nonsense, followed by the jump to 0x20f8.

All TF-branded C139 phones I've seen have fw version 8.8.17, which
features the new malware bootloader.  And the word at 0x2060 is zeroed
out, resulting in the observed behavior of no serial download
opportunity being given on boot.  I speculate that perhaps the newer
fw versions containing boot code with this malicious feature start out
with 0xDDDDDDDD in the word at 0x2060, so that their own developers
could do their job, but when shipping phones to end users, the bastards
issued some ETM or whatever command to zero that word out, disabling
the serial download access - remember that any NOR flash bit can be
changed from 1 to 0 at any time, but going the other way around
requires erasing and rewriting the whole sector.

So what do we do about it?  Well, at least the TF-branded C139s still
have that ETM memory write command that allows us to break in by
writing a little payload into IRAM and smashing the stack while the
main fw is running, and we now have a free, source-enabled, Unix/Linux-
based tool for performing this break-in.  Not too long ago there was
someone else on this list who had a newer C139 with Cingular branding
(not TF) that also featured the maliciously locked bootloader.  Not
surprisingly, mot931c wouldn't work on that phone, as this closed
source Weendoze binary does a fw version query and refuses to work
with any versions other than TF's 8.8.x.  But now that we have our own
free tool for the hack in question, it may be worth testing if one can
break into non-TF phones by the same method.  The addresses for the
IRAM payload download and the stack smashing may need to be tweaked
experimentally, but hey...

When the time comes to flash our own FreeCalypso firmware into these
phones, I'm thinking of adopting one of the old bootloader versions as
our "standard".  In fact, the only diff between C11x/123 and C139/140
versions of this boot code is that the latter adds the check for "1003"
at 0x803ce0, whereas the former has no such check.  Thus we can use
the more basic C11x/123 version of the boot code on all hw versions,
and make our chainloading more efficient by loading 32 bytes instead
of 15332. :)

All of the work described above has already been pushed into the
freecalypso-sw and freecalypso-reveng Hg repositories on Bitbucket.

VLR,
SF




More information about the baseband-devel mailing list