Tracfone C139 break-in procedure

Michael Spacefalcon msokolov at ivan.Harhan.ORG
Wed May 14 07:27:15 UTC 2014

Hello fellow hackers,

As has been discussed on this list a little over a month ago, Mot C139
phones sold with Tracfone branding usually have firmware version
8.8.17, which contains a bootloader in which the serial break-in and
download capability has been disabled.  However, this locked-down
firmware version still has the **16379# keypad command that switches
the headset jack back to the UART and presents a variant of TI's
RVTMUX interface on this UART; and there exists a Weendoze program
called mot931c.exe that:

1. connects to this RVTMUX interface;
2. does some black magic to break into the otherwise locked-down phone;
3. erases and rewrites flash sector 0, replacing the "bad" bootloader
   version with a "good" one.

The elusive part has been step 2 above - just what does this closed
source Winblows binary send to the phone to make the initial break-in?
Whoever was responsible for producing the locked-down fw in these
Tracfones really did close all of the well-known holes: not only have
they tied the nIBOOT pin high directly underneath the BGA and disabled
the serial access in their own bootloader, but TI's standard ETM_CORE
commands which would normally be available over RVTMUX don't work

Well, I have finally reverse-engineered what this mot931c.exe tool
does (by running it under Wine, pointing the Wine-emulated COM port to
a Unix pseudo-tty instead of a real serial port, and listening and
talking back on the master side of the Unix pty), and here is the
secret: Compal's firmware features some non-standard commands of their
own invention in their version of TI's ETM, these non-standard commands
have *not* been disabled in the TF-branded fw, and one of them is a raw
memory write command.

(The following description assumes that the reader is familiar with
 TI's standard versions of RVTMUX and ETM; if you aren't familiar
 with these things, read my write-up thereof in the FreeCalypso

Compal's non-standard ETM memory write command has the following format:

0x14 octet: tells the RiViera Trace MUX that the packet is for ETM
0x40 octet: non-std opcode in the place where ETM component ID would
		normally go
4 octets: absolute address at which the bytes are to be written,
		in LE bytes order
remaining octets before ETM checksum: raw bytes to be written
1 octet: standard ETM command packet checksum at the end

(Wrapped in the RVTMUX STX/DLE byte stuffing as usual.)

The mot931c tool uses the above ETM memory write command to write 204
(0xCC) bytes at address 0x800000, at the low end of IRAM - this happens
with the regular fw still running!  So far, so good.  How is control
then transferred to this downloaded payload?  Answer: by smashing the

After downloading its payload (in two chunks: first 120 bytes, then
the remaining 84), the mot931c tool sends more ETM memory write
command packets in exactly the same format, but this time each write
is just 4 bytes long.  The address being written into starts at
0x837C54, and increments by 4 from there.  The data written with each
of these commands is 00 00 80 00, i.e., 32-bit word 0x800000 in LE.
It is obviously seeking to hit a return address location on the stack,
in order to transfer control to the payload it just downloaded.  If it
keeps getting "ETM command successful" responses from the target, it
keeps retrying with incrementing write addresses until it reaches
0x838BF0, at which point it gives up.

If this procedure succeeds in hitting the function return address on
the stack and thus transferring control to 0x800000, which will indeed
succeed when run against the TF firmware in question, the code that's
been downloaded into that IRAM location then provides its own very
simple serial download protocol whereby the next code stage is
downloaded and run.  I haven't pursued the process further, as the
initial break-in was/is all I'm interested in.  I strongly dislike
this mot931c.exe tool's Heisenbergian approach of altering the flash
content without saving the original first, and my plan is to use this
break-in procedure to make FreeCalypso's fc-loadtool work with these
TF C139s.  Once we are running fc-loadtool, all of this tool's
functions will be available just like it currently offers on Openmoko
and Pirelli targets: flash dump2bin, flash erase, flash program-bin
etc.  Put the user back in control, instead of a closed source Weendoze
binary that does all of the reflashing without asking the user if she
wants it or not.

Viva la Revolucion,

More information about the baseband-devel mailing list