Practical MC13224 Firmware Extraction

by Travis Goodspeed <travis at radiantmachines.com>
as presented at CONFidence Krakow, 2011.



Pictured above is a Freescale MC13224 chip, having been partially decapped with nitric acid in my lab. This is the chip used in the Defcon 18 Ninja Badge and the Redwire Econotag. This brief demonstrates two methods for extracting the firmware from an MC13224 or MC13226 which has been read-protected by placing "SECU" as the first four bytes of Flash memory.

Rather, pictured above are the three chips and a few discrete components that comprise the MC13224. The smallest chip is a radio balun, while the largest is a CPU+radio and the third chip is Flash memory. This brief article will present two methods for forcibly extracting firmware from a locked MC13224, the latter of which is non-invasive and requires only a bit of soldering skill.

For a more thorough discussion of the MC13224, read Akiba's MC13224 Review. In short, the strong point of this chip is its radio, which integrates analog components on chip. Literally everything except for the antenna is included, so a 50Ω trace antenna is the only external radio component. Most of these components aren't on-die, just in-package. You can see the 0402 components used in this in the photo below, which is slightly less etched than the one at the beginning of this article.



Unlike many competing microcontrollers, the MC13224 is unable to execute code directly from Flash. Rather, a ROM bootloader copies a working image from Flash into RAM. If the security word "OKOK" is seen, then JTAG access is enabled before the bootloader branches into RAM. If the security word is instead set to "SECU", then JTAG access is not enabled and the chip remains in its default, locked state.




The final chip shown above is the Flash memory. Its badge is in the corner near a bonding wire, clearly identifying the chip as an SST25WF010, a SPI flash chip that aside from its low voltage is easily interfaced with a GoodFET or Arduino.


The first method for recovery requires access to some rather--but not terribly--expensive equipment. First, use HNO3 or H2SO4 to remove the packaging and expose the SST25WF010 die. Then use a wedge wire-bonder to place the chip into a new package. The die has ten bonding pads while only eight pins are documented, but these can be guessed quickly enough if it is supposed that the sides of the chip are kept constant.

A second extraction technique takes advantage of the fact that, while the SPI bus is not bound out to external pins, the power and ground lines are exposed. Still better, the supply line to the SST25 has its own pin! Pin #133, NVM_REG, is the voltage regulator output for the flash memory, which is exposed in order to allow an external voltage regular to replace the internal one. In ZigBee applications, power could be saved by shutting down the SST25 after booting. This pin is highlighted below.



Given that a local attacker can control power to just the SST25 Flash chip, what would happen if he disabled the chip by cutting its power? MC1322xRM.pdf explains in Figure 3-22 on page 93 that the MC13224 will enable JTAG access then try to boot from UART1, as a SPI slave, as a SPI master, or as an I2C master. If none of these methods work, the chip will hang in an infinite loop.

So all that is needed to recover a copy of an MC13224's flash memory is a board that holds Pin 133 too low during a reset, then loads a new executable into RAM that--when Pin 133 is allowed to swing high--will read firmware out of the SST25WF010 and exfiltrate it through an I/O pin.

Toward that end, I've made a small batch of modified Econotag boards that expose this pin to a jumper. A pair of tweezers can then hold the line low during a reboot in order to unlock JTAG. Once the tweezers are removed, a client for the internal SST25 flash chip can be used through the board's built-in OpenOCD implementation to dump the firmware.



Please note that the MC13224 and MC13226 are the only Freescale 802.15.4 chips with an ARM and external flash die. Both older and more recent devices use an 8-bit HCS08 microcontroller with built-in flash memory.

Freescale could certainly patch the boot behavior, but this would bring its own complications. Mandating an erase and erase-check on failure would cause the chip to self-destruct when being supplied with noisy power. Not mandating that erase would make the chip difficult to recover if improperly flashed.

But even if they were to patch the ROM behavior, successfully, the first vulnerability would still remain. The SST25WF010 chip can still be rebonded into a new package. Further, MC1322x family appears to be an evolutionary dead-end. There have been no new releases since the initial pair of chips, and Freescale's more recent designs have abandoned the ARM7 for the less expensive HCS08 core they maintain in-house.