Tuesday, May 24, 2011

Practical MC13224 Firmware Extraction

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

MC13224

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.

MC13224

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.

MC13224 CPU
MC13224 LittleMC13224 Flash (SST25WF010)

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.
SST25WF010 Badge

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.

MC13224 NVM_REG

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.

RedBee w/ SECU Bypass

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.

9 comments:

Michael Ossmann said...

Outstanding work! Oh, and I'm pretty sure those are 0201s, not 0402s. It's pretty handy to have them in the package.

Mar said...

Hey Travis,

Good work as always!

The next question is about the "boot" mode on the encryption engine.

The datasheet makes some mentions about an onboard secret key that can be used to encrypt the firmware image.

I've done some work on the engine but haven't played with its boot mode in general.

Travis Goodspeed said...

Howdy Mar,

Recalling that JTAG is enabled, not disabled, by the bootloader, you can use GDB to run the bootloader from ROM after enabling flash. As JTAG won't be disabled, the contents of Flash will be decrypted and placed in RAM. Additionally, the key should be found in ASM_KEY0 through ASM_KEY3 at some point. Just toss a breakpoint on a write to that SFR, then single step until the key is in the SFR.

It might be fun to write a tricky two-stage bootloader, where the initial Flash image decrypts another after looking to see if it is being debugged. Maybe a microcontroller crack-me contest?

--Travis

HandShake said...

Money well spent...

Google.

Leon G. Vandenberg said...

Great work Travis -it is non-trivial effort - only a little bit of kit required to validate your findings but your work truly proves need for more secure controllers and boot strap sequencing.

LVitya said...

Hello Travis. I sent you a mail, but you don't replied. Maybe you spam filter stop my message. How can I contact with you?

Travis Goodspeed said...

Howdy Vitya,

I'm terribly busy and not very good at replying to emails. It's far more likely that I read the email and lost it than that the spam filter caught it, or that I've written half a reply that never got sent.

Please just send me a new email with a mention that I didn't reply to the last one, or include an email address in your post here so that I can reply directly.

--Travis

gua hu said...

items. With vinegar and baking soda, and maybe a few other ingredients, you'll be able to thoroughly
mitchel ondemand clean your full home. It'll be much better to your family members simply because you didn't use hazardous goods to wash it.
Pleasure Alderson writes custom content for Supermaids, Inc. in north Texas. autodata 3.38 windows 7 They're a with all English speaking workers and an A+ score using the Dallas Better Company Bureau.

pc sharma said...

very nice product info and thanks for sharing these information with us.
Custom USB