The GoodFET's MSP430 Stack Depth

by Travis Goodspeed <travis at radiantmachines.com>

Today I'm stranded in Munich and unable to walk, so I thought it neighborly to measure the stack depth of the GoodFET's firmware in order to determine the minimal microcontroller necessary, reducing the material cost of each unit. This article ought to help those who wish to do the same.

The MSP430F1612 ($15 to $11) that I presently use is rather expensive, and a smaller, cheaper chip will likely suffice. While I don't expect the code to fit in the MSP430F2013 ($3 to $1.50), it's not unreasonable to assume that something like the MSP430F2274 ($5 to $3) would be a good choice.

To determine whether the Flash is sufficient is easy, as I can measure that by the size of the output image. make install reveals this to be 7566 bytes as of r79, which will comfortably fit in the MSP430F2254 (16KB) and 2274 (32KB) and doesn't come close to filling the 1612's 55KB of Flash.

Determining RAM usage is much more difficult, and likely better to be done in actual use than in simulation or by static analysis. I'm implementing this by adding two new commands to the Monitor application. The first, RAM_PATTERN (0x90), fills all of RAM with 0xBEEF, suiciding and resetting at the end. The second, RAM_DEPTH (0x91), measures how large this block of memory is. By running the first, then running several test cases, then running the second, I can accurately measure RAM usage, estimating the minimum required chip for the GoodFET firmware. RAM_PATTERN cannot simple be run at start because the GoodFET restarts each time a client connects.

RAM_PATTERN must know the entry point of the application in order to reset, as well as the start and end addresses of RAM. No care need be taken to avoid damaging the stack or global variables, as a reboot will obliterate and repopulate them anyways.

Looking at the linker script (trunk/firmware/ldscripts/161x.x), it can be seen that the RAM region is defined by data (rwx): ORIGIN = 0x1100, LENGTH = 0x1400, so it extends from 0x1100 to 0x2500. RAM_PATTERN simply writes 0xBEEF over this region, then calls asm("br &0xfffe") to reboot. Don't forget your pointer arithmetic: ++ on a pointer increments by the word size (2), not the integer address (1).

In any case, once these functions are working, it's a simple matter to measure RAM usage. As we know that 0x1400 bytes are available, we can fill with the pattern, then restart, then run code, and compare the number of available bytes. By the following log, you can see that 0x12b2 bytes are unused by the GoodFET firmware even after running the Chipcon test cases, or that 0x1400-0x12b2=0x14E=334 bytes of RAM are necessary.

petite% goodfet.monitor ramfill
petite% goodfet.monitor ramdepth
0x12c4 RAM bytes free.
petite% goodfet.monitor test    
Performing monitor self-test.
Self-test complete.
petite% goodfet.cc test >>/dev/null
petite% goodfet.monitor ramdepth   
0x12b2 RAM bytes free.
petite%

Rounding that 334 byte measurement up a bit, it still ought to fit in the MSP430F2254's 512 bytes of RAM, with a pin-compatible upgrade available for the 2274 with 1 kilobyte of RAM. For comparison, the present hardware has 5K of RAM with the MSP430F1612 and 10K with the 1611.

Note that this lean behavior is only possible because the GoodFET's firmware is very flat and uses no dynamically allocated buffers. I will be running some more tests, and if they turn out to my liking, there's a good bet that the MSP430F2274 will be the basis of the GoodFET30.

Firmware compatibility between the two chips will require more creativity than the present scheme of a wacky linker script, as they are of different families. Seeing as how plenty of memory is left over, I could write firmware which identifies its host system and configures the I/O ports so as to run on either system from a single image. I don't think that I will do this, as incompatibilities in the I/O port choices would require complication of all I/O routines that could better be handled by preprocessor directives.

Half-Blind Attacks, Source Barcelona

by Travis Goodspeed <travis at radiantmachines.com>

At the Third Usenix Workshop on Offensive Technologies, I presented Half-Blind Attacks: Mask ROM Bootloaders Are Dangerous with Aurélien Francillon. This paper describes the use of a stack overflow exploit to return into a random piece of flash memory, which often enough will elevate privileges before returning into the bootloader.

I'll be presenting the security-conference equivalent of this paper as a lecture at Source Barcelona on September 21 or 22, along with something new. I will bring both the demonstration hardware and plenty of GoodFET boards.

--Travis

Extracting Keys from SoC Zigbee Chips

by Travis Goodspeed <travis at radiantmachines.com>

Last week, at Black Hat Briefings, I presented a short paper entitled Extracting Keys from Second Generation Zigbee Chips. Though brief, the paper is vitally important reading for anyone shipping a product with chips from Chipcon and Ember. The paper includes a method by which keys may be extracted from these chips, as well as a software method for defending Chipcon devices against the attack. All EM2xx chips are vulnerable, as are all of the 8051-based Chipcon radios, such as the CC2530. This is not the same as my attack against first generation, discrete radios.

GoodFET HHV, Neighborcon Vegas, Taipei

Howdy neighbors,

I'll be bringing plenty of spare GoodFET boards to vegas, perhaps something new as well. If you'd like to build one in the Hardware Hacking Village, please bring the parts from the GoodFET11 BOM, with perhaps some extras to share. I've given away all of my assembled GoodFET boards, save the one I use for development, so don't expect to have any fun without soldering.

The Neighborcon Vegas CFP will come out soon. Neighborliness will be abounding during Black Hat Briefings for all those that need a break from the crowd or cannot afford the ticket. A shuttle should run regularly from Caesar's, and we'll have all sorts of neighborly workshops and competitions. The official announcement is being delayed to keep the crowd manageable, but it will definitely be happening.

I am in Taipei, R.O.C. for the next two weeks. Email me if you'd like to meet up for drinks, especially if you speak Chinese and can help me navigate the local electronics market.

New technical articles are coming soon, covering the debugging protocols of the MSP430 and Chipcon 8051 chips. MSP430X, MSP430X2, and others will follow as GoodFET support solidifies. Also some fixes for security vulnerabilities that I will be announcing at my Black Hat talk.

Cheers,
Travis Goodspeed
<travis at radiantmachines.com>

GoodFET MSP430 Tutorial

by Travis Goodspeed <travis at radiantmachines.com>

N.B., that this is quite outdated. See the GoodFET Tutorial for a more recent description.



This is a quick tutorial for using the GoodFET to program an MSP430. This should work for all classic MSP430 chips which support 4-wire JTAG, but it will not yet work with SpyBiWire or MSP430X2 chips, such as the MSP430F5xx and CC430. As these instructions will likely become dated very quickly, expect some surprises.

Prerequisites

You will need a GoodFET board, complete with the clock crystal. Your workstation should have Python, Subversion, MSPGCC, and msp430-bsl installed. I assume below that you are using some form of Unix, but the software ought to be compatible with Cygwin. Those who are unfamiliar with Cygwin should wait for a GUI client that I'll release later this year.

If you are familiar with SMD soldering, email or catch me at a conference for a gratis board of the most recent revision.

Subversion Checkout

Grab the entire project by running "svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet". Future updates may be grabbed by "svn update".

Clients

CD to "goodfet/trunk/client" and run "sudo make link". This will link the client scripts to /usr/local/bin/, keeping the originals in the subversion directory to be easily updated. At this point, you can call up the "goodfet.msp430" command's usage by running it without parameters.

Firmware

Change your directory to "goodfet/trunk/firmware", then run "make" to compile a firmware image. If there are errors, check your MSPGCC installation. Once compilation succeeds, run "make install" to load the firmware into the GoodFET device.

Dumping an Image

The "goodfet.msp430" script is a stand-in until I get around to writing a proper client. To dump a target's firmware, the usage is "/usr/local/bin/goodfet.msp430 dump $foo.hex [0x$start 0x$stop]". To dump the BSL, which resides in the region [0xC00,0xFFF],


As I collect BSL images, it would be neighborly of you to send the bsl.hex file my way. Dump with no range will dump all memory above 0x200, which is to say all memory that may be safely read without side effects.

Erasing a Chip

The "erase" verb will mass erase all memory except for the DCO configuration. An erase is automatically performed prior to a flash.

Flashing an Image

The "flash" verb of this client will flash an image to the target board. Every address evenly divisible by 0x100 is printed as a sort of progress meter,


Each word is validated as it is written, making it easy to identify when writes go bad. In the photo below, words were miswritten from 0x2500 to 0x2508, but later words were written properly.


That's all, folks. Expect a slew of firmware updates for the GoodFET over the next few weeks, and perhaps a GUI client of some sort.

Cold, Labless HNO3 Decapping Procedure

by Travis Goodspeed <travis at radiantmachines.com>
with thanks to Brooke Hill

The following are instructions and matching photos for removing the packaging of microchips without a proper chemical laboratory. Neither a hot plate nor a fume hood is required, and the only chemicals necessary are fuming nitric acid and acetone. The result is a bare die, with bonding wires. The bonding wires may then be removed and the die photographed using microscope.

The same as any author of a lay chemistry article, I must caution you to be very careful with the procedure that I describe. If you've no prior experience with chemistry, purchase an introductory book and study the safety instructions thoroughly. Nitric acid in these concentrations is nasty stuff, even when cold.

Materials

You will need two small vials with wax-paper seals, high-purity HNO3, acetone, tweezers, and a few pipettes. A fume hood is not required, as the reaction will be performed at room temperature. Safety glasses are recommended.

Surface mount chips are preferred for this method, as they have considerably less packaging to dissolve. I chose the CC2430, CC2431, and EM250 chips because they were handy, but also because I don't yet have die photographs of them.

Procedure

Begin by dropping the chips to be decapped into a vial.


Then add nitric acid to cover the chips, plus a bit more. This will react slowly, rather than violently, but for safety's sake be damned sure never to look down any sort of glassware when mixing in a new reactant. You will see the reaction as small bubbles that come from the chip casing as it dissolves.


This will slowly turn the nitric acid from yellow to a dark green. Agitate it occasionally to ensure that all of the plastic gets a chance to break away.


Leave the mixture overnight, allowing the plastic sludge to settle to the bottom of the vial. The liquid above it is still-potent nitric acid, which may be skimmed off with a pipette. Save this in a second bottle for future use, but do not reintroduce it to your bottle of clean acid.


At this point, you've got a vial which contains a lot of plastic gunk and very little liquid. Flush it with water to remove the soluble gunk, then dump the remainder into a shot glass for sorting with tweezers. (Pick the chips up by their bonding wires, as you might scratch the surface.)

Result

Once decapped, each die should be cleaned in acetone. For microscope photography, the bonding wires ought to also be plucked by tweezers.

SPI Client Tutorial for the GoodFET

by Travis Goodspeed <travis at radiantmachines.com>



I've just confirmed that SPI support is functional on the GoodFET, but I've done so with my ugly-as-sin Python client. I'd much rather that neighborly souls write their own clients for this device. The following article describes the protocol by which this is done, as well as some snippets of the GoodFET firmware. The present code should be sufficient to write an AVR programmer, an interface for Chipcon radios, and all sorts of other neighborly things.

SPI is a synchronous, full-duplex serial protocol, which is an uptown way of saying that it has a clock and that bits are simultaneously transmitted and received. Whenever you transmit a byte, you are actually exchanging values of a register. Instead of start and stop bits, clocks are synchronized by the falling of the !SS (Slave Select) line, and then they remain synchronized by counting bits. Data is transmitted MSB-first, received LSB-first.

The GoodFET attaches by a USB serial port, one which is also used for programming. As the DTR, Data Terminal Ready, line is connected to the !RST pin of the GoodFET's microcontroller, you will find that the GoodFET turns off when you connect to it with Minicom or Hyperterminal, then turns back on when you disconnect! To remedy this, you must drop the DTR line low by using ioctl() in Posix C or your language's equivalent. This will boot the GoodFET, beginning a session.

The session itself will begin at 9600 115200 8/N/1, although faster speeds will be supported in the near future. When you drop the line low, you will receive the three bytes {0x00, 0x7F, 0x00}. This is a GoodFET packet, and like all packets it follows the same, simple form. The first byte indicates the application, 0x00 being the Monitor. The other application that we will use is 0x01, SPI. The second byte is a verb, with all bytes less than 0x80 being generic verbs and all bytes higher being application-specific verbs. 0x7F means "OK" in every application. Other verbs include READ (0x00), WRITE (0x01), SETUP (0x10), and NOK (0x7E). A complete list of generic verbs is available in the Manual. The third byte, 0x00, indicates the number of data bytes that follow.

The GoodFET's protocol is transaction based, with every transaction after the first being begun by the host. It is recommended that your transmit function also automatically receive this reply. Further, any verb may have data attached. While the OK verb of the Monitor might never include data, your client had better accept whatever data it chooses to send your way.

Inside of the GoodFET, an application is merely a handler. All application present in the firmware are active simultaneously, and where it doesn't cause problems you may mix and match them. For example, you might wish to use the Monitor to manage the Test pin manually in order to implement an AVR programmer.

In any case, you can implement an SPI library through the GoodFET with only a few verbs. A sample session with commentary follows.

Transaction

First, the host adjusts to 9600 8/N/1, then the device announces its presence.
D: {0x00 (Monitor), 0x7F (OK), 0x00 (0 bytes)}

The host calls the SETUP verb of the SPI application to configure the I/O pins.
H: {0x01 (SPI), 0x10 (SETUP), 0x00 (0 bytes)}
D: {0x01 (SPI), 0x10 (SETUP), 0x00 (0 bytes)}

At this point, the I/O pins are now properly configured. Pins 1, 2, 5, and 7 are now MISO, MOSI, !SS, and SCK. As the READ and WRITE verbs are interchangeable for SPI, the host may use either. If nothing is connected, the MISO pin's pullup resistor will ensure that the reply is always 0xFF.
H: {0x01 (SPI), 0x00 (READ), 0x01 (1 byte), 0xDE}
D: {0x01 (SPI), 0x00 (READ), 0x01 (1 byte), 0xFF}
H: {0x01 (SPI), 0x01 (WRITE), 0x01 (1 byte), 0xAD}
D: {0x01 (SPI), 0x01 (WRITE), 0x01 (1 byte), 0xFF}

If pins 1 (MISO) and 3 (MOSI) are bridged, the output (MOSI) will feed right back into the input (MISO), causing the output value to be returned.
H: {0x01 (SPI), 0x01 (WRITE), 0x01 (1 byte), 0x80}
D: {0x01 (SPI), 0x01 (WRITE), 0x01 (1 byte), 0x80}

If multiple SPI devices are chained together, such as in a gang programmer, data may be shifted through one into the other. To do this, make a ring with each MISO line connected to the next's MOSI, then perform a transaction of as many bytes as you have devices. This will cause !SS (Slave Select) to drop low, then all bytes will be shifted, then !SS will rise high to indicate the end of the transaction. The same is appropriate for registers in multiples of 8 bits, such as a 16 bit device. The first byte in the reply is the first byte to be received, so when ganging devices the bytes of the reply will need to have their order swapped.
H: {0x01 (SPI), 0x01 (WRITE), 0x02 (2 bytes), 0xDE, 0xAD}
D: {0x01 (SPI), 0x01 (WRITE), 0x02 (2 bytes), 0xBE, 0xEF}

Ideas

A programmer/dumper for SPI EEPROMs could be written in short order, as could a command console for various Zigbee radio modules. The present application only supports SPI's master mode, but slave and sniffing support will be added at a later date.

A separate tutorial on extending the firmware will be available soon. If you'd like to get a head start, fork spi.c to make an I2C adapter. Email or catch me at a conference for a free board.