Travis Goodspeed's Blog

Introduction to Bluetooth RFCOMM Reverse Engineering

2011-12-04T15:25:00.000-05:00

by Travis Goodspeed <travis at radiantmachines.com>
with thanks to Alexei Karpenko

Reverse engineering a Bluetooth device is rather straightforward, but quite a few good neighbors don't know where to begin. This article demonstrates exactly how an Android client was reverse engineered in order to produce open source clients in Python and QT Mobility. I'm writing with the assumption that you are trying to reverse engineering your own device, which is similar but not identical to mine. As this is an introductory guide, I'll stay clear of any code reverse engineering, sticking only to network traffic.

The subject of this article is the Spot Connect, which transmits one-way text messages and GPS coordinates by L-band to the GlobalStar satellite constellation. These messages are then forwarded by email or SMS. Except in its emergency mode, the device is operated through Bluetooth by a smart phone. Thanks to Android's use of the Bluez bluetooth stack, it is rather easy to get the necessary traffic dumps.

Kind thanks are due to Alexei Karpenko (Natrium42) for his article on SPOT Reverse Engineering, which covers the original SPOT unit in excellent and thorough detail. It was his article that got me looking at the Spot Connect, and his description of the GPS format saved me quite a bit of travel for sample collection.

Sniffing RFCOMM

The first step is to load the official client onto a rooted Android phone, in my case a Nexus S. I had to swap SIM cards as my Brazilian one put me in a region of the Android market that didn't have the application. Switching to a Swiss card fixed this, and a moment later the app was installing.

The Spot Connect uses RFCOMM, which is Bluetooth's alternative to a TCP socket or a UART. As it is easy to prototype and always delivers packets in order, RFCOMM has become the standard way of implementing custom protocols. To sniff the traffic before knowing the mode, we'll use hcidump running in a debugging shell of the phone. For this, run adb shell hcidump -X | tee spotlog.txt on your workstation, send a transmission, and watch the result in the log.

The message being sent stands out as ASCII, of course, so it's the first thing to look for. With no knowledge of the HCI protocol, you can still be sure that you have a cleartext recording.

35 00 40 00 0b ef 63 aa 31 26 01 00 01 00 01 4d  5.@...c.1&.....M
72 2e 20 57 61 74 73 6f 6e 2c 20 63 6f 6d 65 20  r. Watson, come 
68 65 72 65 2e 20 49 20 77 61 6e 74 20 74 6f 20  here. I want to 
73 65 65 20 79 6f 75 2e 9a                       see you..

From Alexei's article, you can expect that frames inside of RFCOMM will begin with 0xAA, followed by a length, followed by a verb and the objects. These bytes will be wrapped in padding on the outbound end, and they'll be fragmented on the inbound end. Sure enough, these are the bytes that come before the word ``Watson'':

aa Preamble
31 Length
26 Verb
01 00 01 00 01 Flags (OK, Check In)
4d 72 2e 20 57 ASCII Message (abbreviated)

Counting 0x31 bytes out, notice that the packet ends exactly on a byte of the ASCII message, without a checksum! By looking for bytes of AA and searching for length, with allowances for packet fragmentation and the RFCOMM wrapper, it becomes possible to decode every command and its matching response.

Be aware that responses will be fragmented more than transmissions. If you need to reverse engineer longer transactions or have a more complete log, it will be handy to have a script to reassembly from the HCI frames. In those cases, toss together a proper HCI decoder to get a more accurate interpretation of the records.

Looking through the entire log, it the protocol appears to be as follows. First, the client queries the Device ID with verb 0x01, using the exact same format as Alexei's article. Then it uses verb 0x25 to query the last known position of the device, which will be returned in the style that Alexei reverse engineered from the original unit. Use pen and paper to decode these transactions from my Python client.

First Implementation

With these recordings in hand, the complete language can now be described and implemented. Luckily, three verbs make for a quick implementation!

I use py-bluez for prototyping such implementations, as its rfcomm-client.py example is simple enough to get a working client in minutes. As py-bluez is specific to Linux, Mac users might prefer lightblue.

For simplicity, cut the UUID code or switch it to RFCOMM's UUID, which is 00001101-0000-1000-8000-00805F9B34FB. For a list of all services on a device, run 'sdptool records $adr'. This only lists those which are publicly announced by SDP, the Service Discovery Protocol. To scan for unadvertised services, try BT Audit from Collin Mulliner.

0x01 -- Get ID
A minimal test client will just test the serial number of the device. To do this, simply send "\xAA\x03\x01" and then catch the reply with verb 0x01. Bytes 3, 4, 5, and 6 of the reply will contain the serial number in Big Endian notation. For this first implementation, commands and their responses may be handled synchronously for simplicity.

Where self.tx() takes a frame as its input and returns the response, this is implemented in Python as the following. What could be simpler?

0x25 -- Get Last Position
Similar in calling convention, the 0x25 verb requests the last known GPS position of the device. The coordinate format is exactly the same as in Alexei Karpenko's Spot Hacking article, consisting of three bytes apiece to describe latitude and longitude. The following is my C++ code for parsing the position data, which has already been requested as "\xAA\x03\x25".

0x26 -- Transmit Text
Transmitting text is just as easy, with the Spot Connect handling all the work after a message has been loaded. The following is Python code to transmit a short text message with the OK message-code. This lacks length checks and doesn't support the changing of flags, but it will work perfectly well for a test.

After the device receives this command, it will reply with an acknowledgment and then begin to attempt transmissions at irregular intervals. Each transmission consists of a number of fragments, such that the packet can be reassembled so long as one copy of each fragment makes it through. If you have a clear view of the sky and have configured the first destination to be your email address, you should receive a notification within a few minutes. If you don't receive a notification by the time the mailbox icon has ceased blinking, then the transmission failed.

Other Verbs
These three verbse--0x01, 0x25, and x026--are sufficient to implement a minimal client for the Spot Connect. If you'd care to help out, it would be useful to have more documentation for the flags of the 0x26 verb, as well as documentation for 0x52, 0x40, and 0x38. By scanning and listening for error codes, it should be possible to get a complete list of those verbs that are unused by the Android application.

You can find my Python client at https://github.com/travisgoodspeed/pyspot . It ought to run as-is on Linux with py-bluez, including the Nokia N900.

A Graphical Client

Now that the protocol has been sufficiently well documented to have a Python implementation, it is worthwhile to rewrite it as a GUI. In my case, I wanted a QT Mobility client for my Nokia N9. You can find my work in progress at https://github.com/travisgoodspeed/goodspot.

Other Methods

If hcidump isn't available for your platform, you might try Sniffing with a USRP or reflashing a dongle to become a commercial sniffer. For a jailbroken iPhone, see the iPhone Wiki's documentation.

Another option would be to create a Bluetooth proxy, relying on the slim authentication performed in the protocol. In this case, the proxy would open all relevant port to the device being reverse engineered, ferrying commands back and forth as a way to record them. You might also need to experiment with changing the device class and, in the case of iOS devices, there is also a lockout sequence that must be implemented.

If none of that works for your device, you could sniff the UART lines that come from the bluetooth module, shown here on the left board. This particular module happens to be a BT23, and Page 8 of BT23_Datasheet.pdf shows that pins 14 and 13 should be tapped to get a communications log.

As a last resort, you could always ask for documentation. I didn't bother with this because of my own impatience, but for some devices, such as the Metawatch, documentation is freely available. More than once, a neighborly vendor has been so kind as to give me the source code or documentation just to be neighborly.

Future Work

This article will be followed with one on the physical layer protocol of the SPOT, which I've been able to sniff thanks to some kind help from Michael Ossmann. For a preview of that technique, you are welcome to stalk my SPOT Connect Set on Flickr. The most neighborly of these shows individual bits from a FunCube Dongle recording of the transmission. It's cleartext, of course.

Replacement firmware is also a possibility. The Spot Connect uses an MSP430F5xx microcontroller with the standard USB bootloader, using a Java client on Windows and an Objective C client on OS X. The firmware itself is downloaded by HTTPS, and a copy could be acquired either by a MITM attack on HTTPS or by asking the bootloader politely, using the password that is to be found within the firmware update. Be careful when doing this to test on a unit without a service contract, as service cannot be moved from one unit to another and bricking is a distinct possibility.

Conclusions

I hope that this article has given you a decent overview of the methods for reverse engineering Bluetooth RFCOMM devices. While my subject was the Spot Connect, these methods would apply equally well to something like a GPS, the Metawatch, Bluetooth chat applications, and multiplayer games. Other brands of Bluetooth satellite communicators are available, and open documentation for them would be quite handy. For a list of a few thousand potential targets, search the Bluetooth SIG's Gadget Guide.

A Bluetooth GoodFET for the N900

2011-09-06T09:09:00.002-04:00

by Travis Goodspeed <travis at radiantmachines.com>
continuing Promiscuity is the NRF24L01+'s Duty
with kind thanks to @fbz, @skytee, and their Hacker Hostel.

Since building my packet sniffer for the Microsoft 2.4GHz keyboards, I've frequently wanted to demo it without having to drag out a laptop. Laptops are heavy, they are inconvenient, and cables just make matters worse. While it is possible to port it to a standalone board or to add an LCD to the Next Hope Badge, I'd rather have the entire GoodFET client library available over bluetooth to my Nokia N900. Pictured above is my prototype build, which reliably sniffs keyboard traffic on battery power for a more than an hour. Rather than serving as a build tutorial, this article will chronicle the bugs that cropped up during the port, in the hope that they'll help other neighbors trying to port the GoodFET firmware to new devices.

This sniffer was assembled from a Next Hope Badge running the GoodFET firmware with hardwired DCO calibrations, a Roving Networks RN41 module, and three NiMH batteries. The client uses py-bluez at the moment, but I might port it to LightBlue for OS X support. Future models will use a GirlTech IMME or Telos B in place of the Next Hope Badge, to allow me to play with APCO P25 or ZigBee networks without a laptop.

Compiling the Firmware

Most of the GoodFET devices are built around an FT232RL and MSP430, with the FTDI taking care of USB to serial conversions. The client software just opens /dev/ttyUSB0 or its local equivalent through py-serial, then uses the DTR and RTS lines to reset the MSP430 into either the GoodFET application or a masked-ROM bootloader, the BSL. The client and the hardware do a little initialization dance in which the GoodFET is reset until the clock configuration register within the device matches 16MHz. So when you run 'goodfet.monitor info' and it replies with "Clocked at 0x8f9e", the devices has rebooted several times until it finds by chance that 0x8F9E is a stable clock configuration for 16MHz.

When replacing the FTDI with a Bluetooth module, the DTR and RTS lines are unavailable with the timing resolution that is necessary to enter the BSL. Rather than rely upon them, I left them disconnected and instead ran only the TX and RX lines from the RN41 to the NHBadge. The !RST signal is also disconnected, so the GoodFET will boot when power is applied and cannot be rebooted except by the appropriate software command.

This creates a number of complications in the client, which I'll get to later, but the important thing for firmware is that the clock configuration must be explicitly known by the firmware at compile or link time. To specify this at compile time, set CFLAGS="-DSTATICDCO=0x8F9E". To specify it at link time, just flash the image without erasing the INFO flash that resides from 0x1000 to 0x1100 in the MSP430X chips.

Additionally, the firmware must be told which pins to use and which microcontroller to target. These are specified by exporting platform="nhb12b" and mcu="msp430x2618". If an NHB12 were used instead of the NHB12B, then the platform would be redefined appropriately. Finally, the firmware size (and thus the flashing time) can be significantly reduced by exporting config="monitor nrf spi" to reduce the set of applications to only the Monitor, Nordic RF, and SPI applications.

To ease in reconfiguring my build environment, I left a script to create these settings in trunk/firmware/configs/examples/bluetooth-nhb12b.sh . Be sure to change the STATICDCO value to that of your own hardware when building it.

Finally, the firmware had to be flashed by JTAG, rather than BSL. This was done the same way the Next Hope Badges were originally programmed at the factory, by wedging the board into a GoodFET programmer and running 'goodfet.msp430 flash goodfet.hex', then verifying with 'goodfet.msp430 verify goodfet.hex'.

Patching the Client

Recalling that the client was initially designed to use py-serial, a few changes were required to make it function through py-bluez.

Before writing a proper client, I wrote a quick py-bluez script to connect to the GoodFET and print any string that is received. Briefly touching the !RST signal on the JTAG connector to its GND pin resets the device, causing it this client to print "http://goodfet.sf.net/". If the default GoodFET firmware is flashed, with no STATICDCO or Info Flash, the string will be printed as garbage most times, with one attempt in ten producing a legible string.

Having verified that the timing and baud rate were correct, I continued by writing a communications module, GoodFETbtser(), that emulates the read() and write() functions of serial.Serial() used by the rest of the application. Additionally, the GoodFETbtser.read() function is written so as to always return the exact number of bytes requested by the receiver, as Bluetooth buffering sometimes breaks apart packets that would otherwise reliably be received as contiguous chunks.

The following is a screenshot (with GoodFET.verbose=1) of a transmission being split in half because of a read() request returning too few bytes.

Additionally, the initialization routine was modified such that if the GOODFET environment variable is set to a six byte MAC address. Setting it to "bluetooth" causes the firmware to search for Bluetooth devices by name, then exit with instructions for setting the MAC. Later revisions might attempt to use the first observed RFCOMM adapter.

Conclusions

The final client is already mainstreamed into the GoodFET's subversion repository, and it looks a little like the following when packet sniffing encrypted OpenBeacon traffic. It can also sniff Turning Point Clickers, Microsoft Keyboards, and anything else that uses the 2.4GHz Nordic chips.

I've already ordered parts to build Bluetooth versions of the Girltech IMME and the Telos B for mobile sniffing of APCO P25 and ZigBee. My rebuilds will include integrated battery charging from USB and the option of running standalone with the bluetooth module disabled, in order to greatly increase battery life. The client ought to run unmodified on rooted Android devices by use of SL4A and py-bluez. Additionally, I'm planning a firmware port to the OpenBeacon USB 2 module from Bitmanufaktur GmbH.

As a final note, I would like to remind all good neighbors that there is no reason why offensive security can't be fun for the whole family.

Remotely Exploiting the PHY Layer

2011-09-01T01:57:00.001-04:00

or, Bobby Tables from 1938 to 2011

by Travis Goodspeed <travis at radiantmachines.com>
concerning research performed in collaboration with
Sergey Bratus, Ricky Melgares, Rebecca Shapiro, and Ryan Speers.

The following technique is a trick that some very good neighbors and I present in Packets in Packets: Orson Welles' In-Band Signaling Attacks for Modern Radios (pdf) at Usenix WOOT 2011. As the title suggests, Orson Welles authored and implemented the attack in 1938 as a form of social engineering, but our version acts to remotely inject raw frames into wireless networks by abuse of the PHY layer. As that paper is limited to a formal, academic style, I'd like to take the opportunity to describe the technique here in my people's native language, which has none of that formal mumbo-jumbo and high-faluttin' wordsmithin'. This being just a teaser, please read the paper for full technical details.

The idea is this: Layer 1 radio protocols are vulnerable injections similar to those that plague naively implemented SQL websites. You can place one packet inside of another packet and have the inner packet drop out to become a frame of its own. We call the technique Packet-in-Packet, or PIP for short.

As I've mentioned in my article on promiscuously sniffing nRF24L01+ traffic, every modern digital radio has a Layer 1 form that consists of a Preamble, followed by a Sync, followed by a Body. The Body here is Layer 2, and that is the lowest that a normal packet sniffer will give you. (Keykeriki, Ubertooth, and GoodFET/NRF give a bit more.)

In the specific case of IEEE 802.15.4, which underlies ZigBee, the Preamble consists of the 0 symbol repeated eight times, or 00000000. The Sync is A7. After that comes the Body, which begins with a byte for the length, a few bytes for flags, the addresses, and some sort of data. Suppose that an attacker, Mallory, controls some of that data, in the same way that she might control an HTTP GET parameter. To cause a PIP injection of a Layer 2 packet, she need only prepend that packet with 00000000A7 then retransmit a large--but not unmanageably large--number of times. I'm not joking, and I'm not exaggerating. It actually works like that.

Below is a photograph of the first packet capture in which we had this technique working. The upper packet capture shows those packets addressed to any address, while the lower capture only sniffs broadcast (0xFFFF) messages. The highlighted region is a PIP injection, a broadcast packet that the transmitter intended to only be data within the payload of an outer packet.

How it works.

When Alice transmits a packet containing Mallory's PIP to Bob, Bob's interpretation can go one of three ways, two of which are depicted in the diagram below. In the first case, as shown in the left column, Bob receives every symbol correctly and interprets the packet as Alice would like him to, with Mallory's payload sitting harmlessly in the Body. In the second case, which is not depicted, a symbol error within the Body causes the packet's checksum to fail, and Mallory's packet is dropped along with the rest of Alice's.

The third interpretation, shown above in the right column, is the interesting one. If a symbol error occurs before the Body, within the Preamble or the Sync, then there's no checksum to cause the packet to be dropped. Instead, the receiver does not know that it is within a packet, and Mallory's PIP is mistaken as a frame of its own. Mallory's Preamble and Sync will mark the start of the frame, and Mallory's Body will be returned to the receiver.

In this way, Mallory can remotely inject radio frames from anywhere on the network to which she can send her payload. That is, this is a PHY-Layer radio vulnerability that requires no physical access to the radio environment. Read the WOOT paper for complications that arise when applying this to IEEE 802.11, as well as the conditions under which a PIP injection can succeed on every attempt.

War of the Worlds

In 1938, Orson Welles implemented a similar exploit as a form of social engineering in order to cause panic with his War of the Worlds (mp3, transcript) performance.

Recall that PIP injection works by having the victim miss the real start of frame marker, then fraudulently including another start of frame marker inside of the broadcast. As per the FCC requirements of his time, Orson begins with a real start of broadcast marker:

ANNOUNCER: The Columbia Broadcasting System and its affiliated stations present Orson Welles and the Mercury Theatre on the Air in The War of the Worlds by H. G. Wells.

(MUSIC: MERCURY THEATRE MUSICAL THEME)

ANNOUNCER: Ladies and gentlemen: the director of the Mercury Theatre and star of these broadcasts, Orson Welles . . .

ORSON WELLES: We know now that in the early years of the twentieth century this world was being watched closely by intelligences greater than man's and yet as mortal as his own. We know now that as human beings busied themselves about their various concerns they were scrutinized and studied, perhaps almost as narrowly as a man with a microscope might scrutinize the transient creatures that swarm and multiply in a drop of water. With infinite complacence people went to and fro over the earth about their little affairs, serene in the assurance of their dominion over this small spinning fragment of solar driftwood which by chance or design man has inherited out of the dark mystery of Time and Space. Yet across an immense ethereal gulf, minds that to our minds as ours are to the beasts in the jungle, intellects vast, cool and unsympathetic, regarded this earth with envious eyes and slowly and surely drew their plans against us. In the thirty-ninth year of the twentieth century came the great disillusionment.
It was near the end of October. Business was better. The war scare was over. More men were back at work. Sales were picking up. On this particular evening, October 30, the Crosley service estimated that thirty-two million people were listening in on radios.

That introduction is two minutes and twenty seconds long, and it was scheduled to begin while a popular show on another station was still in progress. Many of the listeners tuned in late, causing them to miss the Sync and not know which show they were listening to, just as in a PIP injection! What follows is thirty-eight minutes of a first act, without a single word out of character or a single commercial message from a sponsor. The play begins in the middle of a weather report, followed by repeated false station and show announcements, a few of which follow.

We now take you to the Meridian Room in the Hotel Park Plaza in downtown New York, where you will be entertained by the music of Ramón Raquello and his orchestra.
From the Meridian Room in the Park Plaza in New York City, we bring you the music of Ramón Raquello and his orchestra.
Ladies and gentlemen, we interrupt our program of dance music to bring you a special bulletin from the Intercontinental Radio News.
We are now ready to take you to the Princeton Observatory at Princeton where Carl Phillips, or commentator, will interview Professor Richard Pierson, famous astronomer.
Good evening, ladies and gentlemen. This is Carl Phillips, speaking to you from the observatory at Princeton.
Just a moment, ladies and gentlemen, someone has just handed Professor Pierson a message. While he reads it, let me remind you that we are speaking to you from the observatory in Princeton, New Jersey, where we are interviewing the world- famous astronomer, Professor Pierson.

By repeatedly lying to the listeners about the station and the program, Welles was able to convince them that they were listening to legitimate news broadcasts of an alien invasion. Ensuring that the listener missed the starting broadcast announcement breaks the encapsulation that was intended to prevent such confusion, just as a PIP injection relies upon the start of frame to be missed in order to break OSI model encapsulation.

How the hell did this happen?

This class of vulnerability is a really, really big deal. An attacker can use it to inject raw frames into any wireless network that lacks cryptography, such as a satellite link or an open wifi hotspot. Not only that, but because the injection is remote, the attacker needs no radio to perform the injection! Not only that, but this vulnerability has sat unexploited in nearly every unencrypted digital radio protocol that allows for variable frame length since digital radio began! So why did no one notice before 2011?

Packet in Packet injection works because when Bob forwards a wrapped string to Alice over the air, he is trusting Mallory to control the radio symbols that are broadcast for that amount of time. The potential for abusing that trust wasn't considered, despite communications experts knowing full well that sometimes a false Sync was detected or a true Sync missed. This is because a symbol error in the Sync field causes the packet to be implicitly dropped, with the same behavioral effect that would be had if the error were later in the packet and it were explicitly dropped. Except when faced with a weaponized PIP injection, nothing seems strange or amiss. Sync errors were just a nuisance to communications engineers, as we security guys were staying a few layers higher, allowing those layers of abstraction to become boundaries of competence.

That same trust is given in wired networks and busses, with the lesser probability of missing a Sync being the only defense against PIP injection. Just as PIP has shown that unencrypted wireless networks are vulnerable even when the attacker is not physically present, I expect wired networks to be found vulnerable as soon as an appropriate source of packet errors is identified. Packet collisions provide this in unswitched Ethernet networks, and noisy or especially long links might provide it for more modern wired networks.

If I've not yet convinced you that this attack is worth studying, I probably won't be able to. For the rest of you, please print and read the paper and extend this research yourself. There's a hell of a lot left to be done at the PHY layer, and it might as well be you who does it.

Thank you kindly,
--Travis Goodspeed

Practical MC13224 Firmware Extraction

2011-05-24T08:00:00.003-04:00

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.

GoodFET on the TelosB, TMote Sky

2011-03-01T03:41:00.001-05:00

by Travis Goodspeed <travis at radiantmachines.com>
with kind thanks to Sergey Bratus, Ryan Speers, and Ricky Melgares,
for contributions of code, conversation, and general neighborliness.

As I was recently reminded that the Crossbow Telos B and Sentilla TMote Sky devices litter most universities, left over from wireless sensor network research, it seemed like a perfect target. As such, I'm happy to announce that the GoodFET firmware now fully supports the Telos B and TMote, and also that support for the Zolertia Z1 mote will be coming soon. KillerBee integration should come in the next few weeks, but there's plenty of fun to be had in the meantime.

This brief tutorial will walk you through cross-compiling the GoodFET firmware for the Telos B or TMote Sky, as well as simple packet sniffing and injection. As the GoodFET project is always being refactored in one way or another, you can expect a bit of this to change.

Compiling the Firmware

A port of the GoodFET firmware is defined by three things. First, the $platform environment variable defines the header file from which port definitions come. Most platforms just use platforms/goodfet.h, which is loaded when $platform is undefined or set to 'goodfet'. Some devices, such as the two varieties of the Next Hope Badge and the Telos B, use ports which are not the same as the standard GoodFET's layout. In particular, it's rather common for the Slave-Select (!SS) line to be unique to the hardware layout of a particular board. Setting $platform to 'telosb' takes care of this.

Additionally, the Telos B uses the MSP430F1611 chip, so $mcu must be set to 'msp430x1611'. (That's with an 'x', as the linker doesn't care whether the chip is in the F, G, or C variants.)

Finally, a normal GoodFET includes a lot of modules for things like JTAG and similar protocols that the Telos B does not include wiring for. Although leaving them in doesn't hurt, it does make the firmware larger, which is annoying when repeatedly recompiling and reflashing during firmware development. To restrict support to just the monitor, the SPI Flash chip, and the Chipcon SPI radio, it is handy to set $config to 'monitor spi ccspi'.

export platform=telosb
export mcu=msp430x1611
export config='monitor ccspi spi'
make clean install

Accessing the SPI Flash

The Telos B is reset in a manner very different from the GoodFET, courtesy of a bit-banged I2C controller. Someday we'll figure out how to auto-detect this, but until then you will need to have $platform set to 'telosb' just as you did when compiling.

The Telos B contains a Numonyx M25P80 SPI Flash chip, which is compatible with the goodfet.spiflash client. Unfortunately, most units use a variety of this chip that does not respond to a request for its model number. (According to the datasheet, this feature is only available in the 110nm version. Datasheets have a way of phrasing bugs as if they were just optional features.) On those lucky units with a properly behaving chip, run 'goodfet.spiflash info' to get its capacity and model number. Upgrading to a larger chip or replacing the SMD unit with a socketed one will cause no problems, as the client will automatically adapt.

You may also use the standard peek, erase, dump, and flash verbs to access the contents of the chip. When the chip refuses to identify itself, the GoodFET will default to a size of 8Mb, so explicit ranges needed be given for things like 'goodfet.spiflash dump telosb_m25p80.bin'.

As the M25P80 chip is not access-controlled in any way, it's a handy way to grab old data from a node. On some academically-sourced devices, you might find leftover data or code from LogStorage or Deluge. On commercial devices, these chips sometimes keep hold more interesting things.

Sniffing ZigBee, 802.15.4

While the Flash chip is a neat little toy and handy for forensics, most users of the Telos B port will be interested in the CC2420 radio. As a final collaboration between Ember and Chipcon, the '2420 was one of the first popular 802.15.4 chips, and it is still quite handy for reversing and exploit ZigBee devices. Just as before, you must set $platform to be 'telosb' or the client will not connect.

To sniff raw 802.15.4 packets on channel 11, just call 'goodfet.ccspi sniff 11'. This enables promiscuous mode, so you will see traffic from all PANs and to all MACs in the region. If you are only interested in broadcast traffic, use 'goodfet.ccspi bsniff 11' instead.

As much fun as it is to sit with the 802.15.4 and ZigBee protocol documentation to figure out what a packet means the first time, white-washing this particular fence quickly becomes boring. For that reason, Ryan Speers and Ricky Melgares at Dartmouth tossed together a Scapy module for dissecting these sorts of packets. It's in the scappy-com Mercurial repository, so check it out with "hg clone http://hg.secdev.org/scapy-com" then run "sudo python setup.py install" after the prerequisite packages have been installed.

Once the community build of Scapy has been installed, you can run 'goodfet.ccspi sniffdissect 11' to print the Scapy dissections of various packets. As this code is less than a week old, there are a few kinks to work out, so ignore the warning messages that pop up at the beginning of the log. (Scapy likes to initialize the operating system's networking stack even though we're using a GoodFET instead. This is infuriating on OpenBSD, but merely an annoyance on OS X and Linux.)

If you have no other 15.4 equipment to play with, you can do a transmission test with 'goodfet.ccspi txtest 11'. In the following section, I'll show you to how to send and receive packets in a Python script, which is useful for talking to the myriad of wireless sensors that have less than serious security.

Scripting the CC2420

The GoodFET project is built as a number of client scripts which are written in spaghetti code, features from which are slowly moved out of spaghetti and into classes. That is to say, the heavy lifting should be in GoodFETCCSPI.py, while short and sweet client scripts will be found in goodfet.ccspi. As an example, this section will cover the functioning of 'goodfet.ccspi txtoscount' which implements the radio protocol spoken by the TinyOS RadioCountToLeds application.

Rather than go into too much detail, I'll just point out the lines that are most instructive. Just like sing-along cartoons, this only works if you read the code, so please open up your favorite editor and follow along. While you're at it, use 'svn blame' to figure out which new GoodFET developer wrote that routine. If too much time has passed, you'll also need to back up to the revision that was current when I wrote this review. Then jump back a few more revisions to figure out which bugs of mine had to be fixed before his code worked. Isn't revision control nifty?

By default, the CC2420 only receives packets addressed to the local PAN and MAC as well as those sent to the broadcast address. In order to receive promiscuously, allowing the client to automatically identify any devices on the channel, it is necessary to enable promiscuous mode with 'client.RF_promiscuity(1)'. You might also want to tune away from the default channel with 'client.RF_setchan()'.

Also, as checksums must be correct in any outbound traffic, it is necessary to enable the AUTOCRC mode with 'client.RF_autocrc(1)'. This appends a checksum to every outbound packet, and it also rejects any inbound packets with invalid checksums, which is helpful to reduce noise but would sometimes accidentally rejects packets from non-compliant devices during sniffing. (TinyOS always uses the AUTOCRC feature, so it isn't an issue in this particular application.)

Packet reception, as is standard among the radio modules, is performed by 'client.RF_rxpacket()'. This method returns None if no packet has been received, so a synchronous application ought to spin in a loop until something else is returned.

Finally, the routine needs to broadcast its own reply, either from a stock template or from the sniffed packet. This is accomplished by passing an array of bytes to 'client.RF_txpacket(packet)'.

That's really all there is to it.

Conclusions

The GoodFET is primarily a tool for reverse engineering, and integration with other tools is a priority. KillerBee and Kismet plugins are already in development, and clients for all sorts of 802.15.4 devices will be written as hardware becomes available. Support for the CC2420's AES engine will also be added, so that encrypted packets can be sniffed once keys are sniffed from the air or by syringe with a bus analyzer.

That's all folks. Grab a Telos B or TMote and start poking at devices. Good targets might include Z-Wave door locks and ZigBee thermostats.

Promiscuity is the nRF24L01+'s Duty

2011-02-07T01:09:00.001-05:00

by Travis Goodspeed <travis at radiantmachines.com>
extending the work of Thorsten Schröder and Max Moser
of the KeyKeriki v2.0 project.

Similar to Bluetooth, the protocols of the Nordic VLSI nRF24L01+ chip are designed such that the MAC address of a network participant doubles as a SYNC field, making promiscuous sniffing difficult both by configuration and by hardware. In this short article, I present a nifty technique for promiscuously sniffing such radios by (1) limiting the MAC address to 2 bytes, (2) disabling checksums, (3) setting the MAC to be the same as the preamble, and (4) sorting received noise for valid MAC addresses which may later be sniffed explicitly. This method results in a rather high false-positive rate for packet reception as well as a terribly high drop rate, but once a few packets of the same address have been captured, that address can be sniffed directly with normal error rates.

As proof of concept, I present a promiscuous sniffer for the Microsoft Comfort Desktop 5000 and similar 2.4GHz wireless keyboards. This vulnerability was previously documented at CanSecWest by Thorsten Schröder and Max Moser, and an exploit has been available since then as part of the KeyKeriki v2.0 project. My implementation differs in that it runs with a single radio and a low-end microcontroller, rather than requiring two radios and a high-end microcontroller. My target hardware is the conference badge that I designed for the Next Hope, running the GoodFET Firmware.

Part 1: or, Why sniffing is hard.

Radio packets usually begin with a preamble, followed by a SYNC field. In the SimpliciTI protocol, the SYNC is 0xD391, so the radio packets will begin with {0xAA,0xD3,0xD91} or {0x55,0xD3,0x91}. The AA or 55 in the beginning is a preamble, which is almost universally a byte of alternating 1's and 0's to note that a packet is beginning, followed by the SYNC field which makes sure that the remainder of the packet is byte-aligned.

In the case of the Nordic radios, there is no SYNC pattern unique to the radio. Instead, the MAC address itself serves this purpose. So an OpenBeacon packet will begin with {0x55, 0x01, 0x02, 0x03, 0x02, 0x01} while a Turning Point Clicker's packets will begin with {0x55, 0x12, 0x34, 0x56}. The preamble in this case will be 0x55 if the first bit of the SYNC/MAC is a 0 and 0xAA if the first bit is a 1. To make matters worse, the chip does not allow a MAC shorter than three bytes, so previously it was believed that at least so many bytes of the destination address must be known in order to receive a packet with this chip.

Moser and Schröder solved this problem by using an AMICCOM A7125 chip, which is a low-level 2FSK transceiver, to dump raw bits out to an ARM microcontroller. The ARM has just enough time to sample the radio at 2Mbps, looking for a preamble pattern. If it finds the pattern, it fills the rest of register memory with the remaining bits and then dumps them to the host by USB. In this manner, every prospective MAC address can be found. Once the address is known, KeyKeriki places that address in its second radio, an nRF24L01+, which is used to sniff and inject packets.

A similar solution is used in Michael Ossmann's Project Ubertooth sniffer for Bluetooth. See that project's documentation and Ossmann's Shmoocon 2011 video for a more eloquent explanation of why sniffing without a known SYNC is so hard.

Part 2: or, Sniffing on the cheap.
My trick for sniffing promiscuously involves a few illegal register settings and the expectations of background noise. You can find code for this in the AutoTuner() class of the goodfet.nrf client.

First, the length of the address to sniff must be reduced to its absolute minimum. The datasheet claims that the lowest two bits of register 0x03 are responsible for address width, and that the only valid lengths at 3 bytes (01b), 4 bytes (10b), or 5 bytes (11b). Setting this value to 00b gives a 2 byte match, but when checksums are disabled, this results in a deluge of false-positive packets that appear out of background noise.

Second, it is necessary to begin receiving before the SYNC field appears, as the Nordic chips drop the address of incoming packets, leaving only the payload. By looking at the noise returned when the address is at its shortest length, it is clear that background noise includes a lot of 0x00 and 0xFF packets as well as 0xAA and 0x55 packets, which are likely feedback from an internal clock. What then would happen if the address were to be 0x00AA or 0x0055?

What happens is that noise activates the radio a bit early, which then syncs to the real preamble, leaving the SYNC field as the beginning of the packet payload! This is because the preamble and SYNC do not need to be immediately adjacent; rather, the SYNC can be delayed for a few bytes from the preamble in order to allow for longer preambles in noisy environments.

As a concrete example, an OpenBeacon packet looks something like the following. The SYNC field is 0x0102030201, so the packet will be cropped from that point backward. 0xBEEF is all that will be returned to the application, with everything prior to that cropped.

By making the address be 0x0055 and disabling checksums, that same packet will sometimes be interpreted as shown on the bottom. The preamble will be mistaken for a SYNC, causing the real SYNC value to be returned as the beginning of the payload. In that way, I am able to determine the SYNC/MAC field without any prior knowledge or brute force exploration.

This does depend upon the preamble being preceded by 0x00, which occurs often in background noise but is not broadcast by the attacker. So the odds of receiving a packet, while significantly worse than we'd like, are much better than the 1/2^16 you might assume. In experiments, one in twenty or so real packets arrive while a significant number of false positives also sneak in.

Recalling that the MAC addresses are three to five bytes long, and that radio noise is rather distinct, it stands to reason that noise can easily by separated from real packets by either manually checksumming to determine packet correctness or simply counting the occurrences of each address and taking the most popular. You will find an example log of OpenBeacon packets and false positives at http://pastebin.com/8CbxHzJ9. Sorting the list reveals that the MAC address 0x0102030201 is the most popular, which is in fact the address used by OpenBeacon tags.

Rather than rely on packet dumps and sorts, there is an autotune script that identifies network participants and prints their MAC addresses. Simply run 'goodfet.nrf autotune | tee autotune.txt' and go out for a coffee break while your device is transmitting. When you come back, you'll find logs like the following, which has identified a nearby OpenBeacon transmitter.

As low data-rate devices require significantly more time than high-rate devices to identify, such devices will either require undue amounts of patience or a real KeyKeriki. In the case of a Nike+ foot pod, I'm resorting to using loud hip hop music to trigger the sensor, which is left inside a pair of headphones. My labmates are not amused, but it is a great way to reveal the radio settings when syringe probes aren't convenient.

Part 3: or, Sniffing a keyboard effectively.

Having a class to identify channels and MAC addresses is most of the problem, but there are remaining issues. First, the packets themselves are encrypted, and that cryptography must be broken.

Fear not! We won't need to do any fancy math to break this cryptography, as the key is included at least once in every packet. Moser and Schröder's slides explain that the packet's header is cleartext, while the payload is XOR encrypted with the MAC address.

Applying an XOR to the proper region yields decrypted packets such as the following. Because these contain USB HID events, key-up HID events quite often include long strings of 0x00 bytes. When XOR'ed with the key, those zeroes produce the key, so some packets contain the XOR key not just once, but twice!

Finally, the USB HID events need to be deciphered to get key positions. Mapping a few of these yields meaningful text, with bytes duplicated in the case of retransmissions and omitted in the case of lost packets. Disabling checksums will allow the dropped packets to be converted to a smaller number of byte errors, while tracking sequence numbers will prevent retransmitted keys from being displayed twice. Regardless, the results are quite neighborly, as you can make out the sentence typed below in its packet capture.

Part 4; or, Reproducing these results.

All of the code for this article is available in the GoodFET Project's repository, as part of GoodFETNRF.py and its goodfet.nrf client script. The hardware used was an NHBadge12, although an NHBadge12B or a GoodFET with the SparkFun nRF24L01+ Transceiver Module will work just as well.

To identify a nearby Nordic transmitter, run 'goodfet.nrf autotune'. Keyboards can be identified and sniffed with 'goodfet.nrf sniffmskb', while a known keyboard can be sniffed and decoded by providing its address as an argument, 'goodfet.nrf sniffmskb aa,c10ac074cd,17,09'. The channel--0x17 in this case--will change for collision avoidance, but channel hopping is slow and resets to the same starting channel. Identification of the broadcast channel is faster when the receiver is not plugged in, as that causes the keyboard to continuously rebroadcast a keypress for a few seconds.

All code presently in the repository will be refactored and rewritten, so revert to revision 885 or check the documentation for any changes.

Conclusions

Contrary to prior belief, the nRF24L01+ can be used to promiscuously sniff compatible radios, allowing for keyboard sniffing without special hardware. It's also handy for figuring out the lower levels of the otherwise-documented ANT+ protocol, and for reverse engineering vendor-proprietary protocols such as Nike+.

Additionally, it should be emphasized that the security of the Microsoft keyboards in this family is irreparably broken, and has been since Moser and Schröder published the vulnerability at CanSecWest. (It's a shame, because the keyboards are quite nicer than most Bluetooth ones, both in pairing delay and in battery life.) Do not purchase these things unless you want to broadcast every keystroke.

While I have not yet written code for injecting new keystrokes, such code does exist in the KeyKeriki repository and would not be difficult to port. Perhaps it would be fun to build stand-alone firmware for the Next Hope badge that sniffs for keyboards, broadcasting Rick Astley lyrics into any that it finds?

Please, for the love of the gods, use proper cryptography and double-check the security your designs. Then triple-check them. There is no excuse for such vulnerable garbage as these keyboards to be sold with neither decent security nor a word of warning.

Generic CC1110 Sniffing, Shellcode, and iClickers

2011-01-24T09:34:00.001-05:00

Howdy y'all,

I haven't the time to write individual posts on these subjects, but I do have plenty of new features for the CC1110 that are worth sharing. Rather than explain how they were written in too much detail, I invite you to read the source code, which is mostly Python and C shellcode.

In order to follow along with these examples, you will need to have SmartRF Studio installed to /opt/smatrf7. While this requirement will go away in a few weeks, the GoodFET client temporarily needs SmartRF Studio for machine documentation about the CC1110. You can find more details on SmartRF requirements in the goodfet.cc client page.

(1) Packet sniffing, and other neighborly scripts.

GoodFETCC now has packet sniffing support for the SimpliciTI protocol used by the Chronos watch. Not only that, but it implements the protocol well enough to act as an access point for the watch, collecting accelerometer data and deciphering it for the host.

Run an access point with 'goodfet.cc simpliciti [band]'. (This command will likely change names soon, as it is a rather ugly hack which only supports the Chronos accelerometer feature.) The optional parameter should be us, eu, or lf for the American, European, and Low Frequency versions of the watch.

Not only protocols intended for the GoodFET, but also others which are coincidentally compatible, are supported. Thanks to some register settings contributed by Mike Ossman, you can sniff and decipher i<clicker traffic with 'goodfet.cc iclicker'.

The i<clicker uses a Xemics XE1203F (PDF) radio chip, shown below. The XE1203F is nearly as configurable as the CC11xx parts, except that it is limited to 2FSK encoding. Previously, this protocol could be sniffed with the GR-Clicker project and a USRP, but the highly-versatile CC1110 chip allows this to be done with neither a software defined radio nor a chip identical to that used by the transmitter.

If you find it handy to see when a device is broadcasting, you can produce an ASCII-art plot of signal strength with 'goodfet.cc rssi [freq]':

Care to jam another transmitter? Just like with the Next Hope Badge's GoodFET mode, it takes a single command to hold a carrier wave.
'goodfet.cc carrier [freq]'

(2) Shellcode, now for quiche-eaters!

At the risk of appearing to facilitate quiche-eating, I'd like to quickly explain the new shellcode interface for placing code fragments on a Chipcon 8051 target, such as the CC1110.

The Chipcon radios have certain functions which are timing sensitive, chief among these being the rewriting of flash memory and the use of the digital radio core. If flash memory is not pulsed with the correct timing, mis-writes will occur. If the radio is read too slowly, bytes will be missed and a buffer underflow will ruin the transaction. Similarly, a transmission might fail if the single-byte transmission buffer isn't refilled quickly enough. I've also had trouble, for reasons that I can poorly explain, configuring the crystal oscillator through the debugging interface without shellcode.

As I described in my CC2430 Debugging Notes, the recommended method of flashing memory is to write a small block of code into XDATA RAM which does the actual write, then to branch to this code, waiting for a HALT (0xA5) opcode to return control to the debugger. This routine is provided in SWRA124 as machine code with assembly comments, beginning with the fragment shown below.

While this is fine and dandy for code that works, it's a bit infuriating to debug code in machine language. (Is that opcode supposed to be 0xA5 or 0xA6? Is the length of this instruction correct? Similar frustration abounds.) To correct for this, the GoodFET project now has a trunk/shellcode directory in addition to trunk/firmware and trunk/client. Shellcode is compiled for target microcontrollers, in this case just the CC1110 by SDCC, the Small Device C Compiler.

For example, this is the code that used to configure the crystal oscillator on the CC1110, a prerequisite for any radio operations:

That ugly mess becomes the following little fragment of C. It is compiled by 'sdcc --code-loc 0xF000 crystal.c' in order to place the code squarely within RAM, which is executable in this 8051 clone's unified memory architecture. (It's a Harvard chip that acts Von Neumann, or the other way around.)

For inputs to these functions, and also for their return values, I find it more convenient to declare arrays at known locations than to read the symbol files to find them. The syntax for placing an array in XDATA memory at 0xFE00 is 'char __xdata at 0xfe00 packet[256];'. You can find examples of this in txpacket.c and rxpacket.c in the GoodFET repository.

(3) Care to join the fun?

There are a number of features remaining to be implemented in shellcode. Among them in a completed port of Ossmann's $15 Spectrum Analyzer, which I began in CC1110 Instrumentation in Python and you can find in the contrib/ directory of the GoodFET repository. By dropping the GUI interface and replacing it with timing delays, full spectrum scans can be made in decent time without requiring that anything in flash memory be changed.

Another handy tool would be an OOK sniffer that over-samples, using the infinite-packet-length trick described in the CC1110 datasheet to fill ram with a recording. Triggering on RSSI allows the beginning of the packet to be reliably timed, with oversampling allowing for correction on all later bits. I've begun to implement this as 'goodfet.cc sniffook [freq]', but an enterprising neighbor should be able to start sniffing garage door remotes in short order.

A Morse-code library in combination with an external amplifier would also be neighborly for the licensed amateur bands. The ability of the microcontroller to quickly return and channel hop might be able to account for, among other things, the Doppler shift experienced in EME moon-bounce experiments, without losing backward compatibility with 19th century radio technology.

As a prize, I offer one ale apiece for GoodFET patches implementing these features.

Stay neighborly,
--Travis Goodspeed
<travis at radiantmachines.com>

Hacking a Knitting Machine's Keypad

2010-12-06T02:16:00.006-05:00

by Travis Goodspeed <travis at radiantmachines.com>
in collaboration with Fabienne Serriere and Arjan Scherpenisse,
at Mediamatic's RFID Devcamp 2010, Amsterdam,
for Multithreaded Banjo Dinosaur Knitting Adventure 2D Extreme,
with kind thanks to David Carne.

Thanks to some extra-neighborly blackmail by Fabienne, I spent last week hacking up a storm in Amsterdam. By extending the work of Steven Conklin, Limor Fried, and Becky Stern, we were able to hack a Brother KH930 knitting machine to print high score panes from a custom video game in yarn. This game was then displayed at Mediamatic for SensorFest, leading all sorts of neighbors to learn that RFID, socializing, and beer can lead to a neighborly time. Never in my life did I expect to get such an adrenaline rush from knitting, much less from from this newfangled social networking nonsense.

Conklin's technique for loading new patterns into the machine involves using an FTDI chip to simulate a Tandy PDD1 floppy disk drive, then typing "CE 5 5 1 STEP 1 STEP CE STEP STEP CE 9 0 3 STEP STEP" to load a new pattern set from disk and print pattern 3 of the set. (551 is the command to read from disk, and patterns held in RAM begin at 900.) For our exhibit, this sequence was far too complicated to type for every half meter of output, so we hacked the device's keypad for scripting.

This article describes how a matrix keypad works, how we reverse engineered the specific keypad of the Brother KH930, and how to use an Arduino with a handful of transistors to automate the typing of commands necessary for loading a new pattern from an emulated floppy disk. It should be applicable to all sorts of keyboards, but for those with serial protocols there might be a simpler method.

Unfortunately, there won't be room here to describe the first emergency knitting machine purchase in history, our A-Team trip to the far side of Holland in a borrowed van, or the case of Club Mate that we begged from a squatter bar in order to finish the project in the five days allotted.

A keypad matrix is most often built with switches that connect a row wire to a column wire. By keeping every column in a high-impedance state with pull-up resistors, then dropping each row low in sequence, the column inputs can be sensed to determine when a button is pressed. Dave's Hacks' first article on IM ME Hacking describes in detail how the keypad of the GirlTech IMME works, and all other implementations seem to function similarly.

The connections between rows and columns are just switches.

While in a perfect world, rows and columns would be arranged exactly as they appear visually, this is rarely efficient to route in copper for more than twelve buttons. We produced the diagram below by scanning the keyboard membrane, then pushing a button while using the continuity tester to see which row and column wire were connected. The table at the bottom converts from wire signal names to the Arduino signal names used within the client library.

In order to connect rows and columns to a center rail, I used BC547 NPN transistors prototyped on an Arduino shield. Each has a 1K resistor on the base. Row transistors have the collector coming from the row signal and the emitter going to the common rail; column transistors are the same, except that the collector and emitter are swapped in order to fit the direction of current.

As each transistor conducts when only when its base is high, the Arduino can press a key by first dropping all outputs low, then raising a row control line (RCx) and a column control line (CCx) high. Because of debouncing and a limited scan rate, this must be held for a short amount of time before releasing the key.

Such a design fits perfectly well on a prototyping shield, although the transistors are a tight fit. I recommend first prototyping a single row and column to ensure that the transistors are properly aligned, as current direction might be different on your keypad.

For those who prefer to have a board fabbed, here's a proper schematic and layout. Gerbers and Eagle CAD source files are available in the project's subversion repository.

A more sophisticated software implementation would involve using the Arduino's serial port to communicate with the host, accepting strings in ASCII and translating them to keypresses. We decided against such a complication because we feared relying on a second long USB cable. Further, we thought it handy when necessary to be able to run the device stand-alone with a single (reset) button press from the operator signaling that the next pattern should be loaded.

Full keyboard emulator code is available either by pastebin or from SVN. You'll find it in banjo/code/arduino.
svn checkout svn://svn.mediamatic.nl/devcamps/camp10/banjo

The code works by using simple methods to press a row and column by raising those pin voltages. Higher level methods allow for such functions as loading a pattern from disk or printing a pattern, each by performing multiple key presses and occasionally inserting a delay. By placing this within the Arduino code's setup() function, the pattern is loaded whenever the device is reset.

New patterns are loaded from the Banjo Dinosaur Knitting Adventure 2D Extreme game by first starting a floppy disk emulator--as per Steve Conklin's technique--then pulsing the DTR line of the arduino in order to cause a reset. The Perl for that is just a single line,
Device::SerialPort->new("/dev/ttyACM0")->pulse_dtr_on(100)

The end result, with a machine typing by itself, looks a little like this,

That's all there is to it. With fourteen transistors and just as many resistors, you can script your knitting machine--or any other keypad device--from a microcontroller without modifying the underlying firmware.

As a final note, I will give a cookie to the first neighbor who uses this technique to dump all of the power codes from a universal infrared remote control, or to program something long and sophisticated into a graphing calculator that lacks a link port.

Bitmapped Sprites on the GirlTech IMME

2010-11-01T08:00:00.001-04:00

by Travis Goodspeed <travis at radiantmachines.com>
with sprites by Eli Skipp,
extending Dave's LCD reversing,
and with thanks to Mike Ossmann.

The GirlTech IMME is a fine platform for radio hacking and embedded programming, but the LCD of the device is by no means designed for lightning fast graphics. In this brief article, I demonstrate the method by which a sprite library can be constructed which abstracts away the less neighborly minutia of the LCD in favor of a row-wise framebuffer that gets flushed to the LCD as appropriate. This isn't fast enough for a port of Sonic the Hedgehog, but it's certainly sufficient for ZombieGotcha, a network disease simulation game that Eli Skipp and I are prototyping.

To quickly recap, the GirlTech IMME is a children's toy powered by the CC1110F32, which combines an 8051 microcontroller with a versatile sub-GHz radio. The toy also includes a text LCD controller and keyboard, making it a delightful platform for embedded systems hacking and prototyping. Thanks to Dave's article on attaching a debugger and reversing the LCD, it is possible to wire a GoodFET into the IMME, allowing for debugging and reprogramming of the device.

Since the days of the first raster displays, computers have been drawing images as rows, because that's the way that a television's electron stream is traced along the display. The IMME draws rows internally, but because it is intended to draw fonts, its rows are eight pixels tall. For example, the bytes {0x7f, 0x08, 0x08, 0x08, 0x7f, 0x00} are pushed to the LCD in order to draw an uppercase letter H in Dave's LCD Demo for the IMME. Drawing this on graph paper or rendering it by Python, it becomes clear that 0x7F represents a side of the letter, 0x08 represents the bar, and 0x00 is the space following the letter.

Rather than attempting to natively store a framebuffer in the LCD's format, I chose to internally index by row, then to translate during the export of the framebuffer to the LCD. My primary reason for doing this is to maintain portability of the ZombieGotcha code to custom hardware. It also simplifies the transcription of sprites from original bitmaps to C structures.

Having an internal framebuffer is not without cost, however. The buffer is 132 pixels wide and 64 pixels tall. Even with bit-packing, this is more than a kilobyte in size, consuming more than a quarter of the CC1110's 4kB of XDATA RAM. (Programs and sprites are stored in CODE Flash memory, of which there is 32kB, so this limit is not quite so severe as it sounds.)

My sprite toolchain is begun with bitmap images submitted by the artist. I cannot stress enough how important it is that your pixel artist understand pixels. Every sprite must be drawn at native resolution, with proper offsets of each frame and an understanding that the LCD is what it is, regardless of what Photoshop might render.

From the original bitmap sprites, PNM files are produced that are more easily parsed by Perl. This format consists of whitespace-delimited words for the format, width, and height of the sprite. In this case, the sprite consists of three frames, each of them being 24 pixels width and 32 pixels tall. Other sizes are possible, of course, but it is convenient for bit packing that the width is an even multiple of 8, so that the old pixels needn't be read back in.

It is then necessary to use an ugly Perl script to convert the sprite from a PNM to a C array of bytes. Pretty Perl won't work, of course, because such a thing doesn't exist. My script, sprite2c.pl, takes a 24-bit color PNM file and converts it to a 1-bit map that is byte-packed. Each of these is included by the preprocessor as a __code unsigned char[], with the __code keyword implying that the object should be stored in Flash rather than RAM.

Sprite animations are performed by storing the frame count along with the width and height in the C structure. Considering the resource constraints of this system, frame counts change very rarely and are stored within the C code.

Dumping the frame-buffer to the LCD is as simple as writing every stripe of data to the screen. Potentially, as an optimization, you could keep track of which stripes have been invalidated across what horizontal range, updating only where necessary.

Keeping in mind that the LCD is updated as stripes of 8 pixels in height, code such as the following will refresh the entire LCD from the frame-buffer. Be sure not to erase the LCD between writes, as that would cause unnecessary flickering.

The framebuffer elements themselves are grabbed by selecting the pixel index divided by 8, then masking off the selected bit. The following functions work admirably for this purpose.

If greater performance is required, a game should certainly be designed with a custom graphics library that optimizes the few things it does most. Performances can be gained by storing sprites and the frame-buffer natively in the row/stripe format that the LCD expects, simplifying conversion. Mike Ossmann used the technique of basing most graphics around vertical lines in his spectrum analyzer firmware, allowing for channels to be redrawned as they are scanned rather than flushed from a frame-buffer.

As the ZombieGotcha game is largely turn-based and the frame-rate is not a dire concern, I don't expect to optimize the sprite library much beyond what is presented here.

One major addition will be that of screenshots, as I'd like to produce animated GIFs of game action for the website. Screenshots can be produced by the method that I outline in CC1110 Instrumentation with Python, dumping the frame-buffer from XDATA with a GoodFET and writing that to disk. Alternatively, full-speed screenshots could be dumped by sniffing the LCD's SPI bus using a Total Phase Beagle or other SPI protocol analyzer.

For those of you with an IMME, Eli and I will be releasing the ZombieGotcha game at the Twenty-Seventh Chaos Communications Congress in Berlin this winter. We'll bring a bed of nails for reflashing IMME units on the spot, as well as GoodFET kits for modifying your IMME to be a development kit. (The ZombieGotcha will also run on full-custom hardware, but we are maintaining IMME support in parallel.)

As a final note, a teaser of the ZombieGotcha opening screen can be found here in the Intel-Hex format. I'll give a GoodFET40 kit to the first neighbor who sends me an animated GIF of it and a script to generate the same, either by a debugger or an emulator.

CC1110 Instrumentation with Python

2010-10-05T00:10:00.015-04:00

by Travis Goodspeed <travis at radiantmachines.com>
concerning the GirlTech IMME,
utilizing the GoodFET's Chipcon Debugger
to instrument Michael Ossmann's $16 Pocket Spectrum Analyzer.

Often a neighbor, such as myself, finds himself with a damned useful tool that's missing logging. Further, when this is a black-box application, it is undeniably inconvenient to patch in logging where no communications method exists. In this brief article, I will demonstrate how to instrument a Chipcon CC1110 application using Python and a GoodFET with zero bytes of modification to the original firmware image. My target's source code is available, but the technique applies just as well to black-box firmware.

Specifically, I want to dump the raw data from Michael Ossmann's $16 Pocket Spectrum Analyzer in order to demo it on stage at our Toorcon 12 talk, Real Men Carry Pink Pagers. I'll assume the reader to be familiar with Mike's article, as well as my article on wiring an IMME for debugging with a GoodFET. Readers wishing to play along can order a GoodFET31 for little or no money by following these instructions.

From the datasheet or Mike's Makefile it can be seen that the external RAM (XDATA, which is called external for historic reasons) section begins at 0xF000. The only structure at this location is xdata channel_info chan_table[NUM_CHANNELS], where NUM_CHANNELS is defined to be 132 and the channel_info struct is eight bytes, defined as

typedef struct {
 /* frequency setting */
 u8 freq2;
 u8 freq1;
 u8 freq0;
 
 /* frequency calibration */
 u8 fscal3;
 u8 fscal2;
 u8 fscal1;

 /* signal strength */
 u8 ss;
 u8 max;
} channel_info;

The first several entries in this struct might be as follows. The first of these lines defines the frequency to be 0x22af4b, the frequency calibration to be 0xef2c27, and the signal strength to be 0x41. The final byte defines the maximum strength, which is zero unless max-highlighting mode is turned on.

 22 af 4b ef 2c 27 41 00
 22 b1 43 ef 2c 27 3e 00
 22 b3 3b ef 2c 27 46 00
 22 b5 33 ef 2c 27 3c 00
 22 b7 2b ef 2c 27 44 00
 22 b9 23 ef 2c 28 3c 00
 22 bb 1b ef 2c 28 42 00
 22 bd 13 ef 2c 28 3f 00
 22 bf 0b ef 2c 28 3d 00
 22 c1 03 ef 2c 28 40 00
 22 c2 fb ef 2c 28 3d 00
 22 c4 f3 ef 2c 28 3e 00
 ...

This information can be extracted by halting and resuming the CPU, just as I did in my article on the PRNG Vulnerability of Z-Stack's ZigBee SEP ECC implementation. That is, GoodFETCC.CCpeekdatabyte() is used to grab these bytes from the CC1110's RAM. The following code dumped the fragment shown above.

#!/usr/bin/env python 

import sys;

sys.path.append('/Users/travis/svn/goodfet/trunk/client/')

from GoodFETCC import GoodFETCC;
from intelhex import IntelHex16bit, IntelHex;
import time;

client=GoodFETCC();
client.serInit();

client.setup();
client.start();

bytescount=8*132;
bytestart=0xf000;

while 1:
    time.sleep(1);
    client.CChaltcpu();
    
    dump="";
    for foo in range(0,bytescount):
        dump=("%s %02x" % (dump,client.CCpeekdatabyte(bytestart+foo)));
        if foo%8==7: dump=dump+"\n";
    print dump;
    sys.stdout.flush();
    client.CCreleasecpu();

To get proper data, it is necessary to add a wake-up delay of a few seconds, so that the table is populated by the first sampling. Additionally, it is handy to convert the frequency to MHz from its native unit (Hz/396.728515625). Finally, successive pages should be separated by a time column in order to facilitate graphing. The result is this script, which can be found in the GoodFET project as "contrib/ccspecantap/specantap.py".

An example recording can be seen below, as a spectrum recording of a friend's Kenwood FreeTalk UBZ-AL14 FM Transceiver unit. This is compatible with other family FM radios, and I wanted to know which center frequencies were in use. In the first image, I've highlighted the noise floor as blue and the peaks as green. In the second image, the time domain is used to show broadcasts on several channels in sequence, all of which fall into one of the two center frequencies: 925MHz and 935MHz. The raw data is here, best viewed with NASA's excellent Viewpoints tool.

Future additions to this project will include integration into the GoodFET radio framework, as well as a 2.4GHz version built around the CC2430 and CC2530. The performance of the tap can be greatly improved by using block transactions rather than peeking individual bytes, and the view can be re-tuned by poking the configuration IDATA variables, positions of which are described in specan.rst as produced by the SDCC compiler.

It's also handy to know that a Chipcon radio will halt if the 0xA5 opcode is executed. In this manner, patching a single byte of a while() loop can allow the state at every iteration to be dumped.

This technique of scripted debugging through a programmer can be handy for more than instrumentation. Unit tests can be run on an assembly line without additional wiring, and--by single-stepping--execution traces of unknown firmware can be generated for assisting in reverse engineering. Those with enough patience can use this to fuzz test embedded systems for security vulnerabilities.

For help instrumenting your own Chipcon or MSP430 project, join us in #goodfet on irc.freenode.net or send me an email. The project has advanced to the point where interesting things can be done from Python alone, and I'd quite like to see what could be done with it.

Reversing an RF Clicker

2010-07-04T17:00:00.000-04:00

by Travis Goodspeed <travis at radiantmachines.com>
concerning the Turning Point ResponseCard RF,
having FCC ID R4WRCRF01,
patented as USA 7,330,716.

In this article, I describe in detail the methods by which I have reverse engineered the TurningPoint ResponseCard RF, casually known among students as a "Clicker". This 2.4GHz radio transceiver is used in undergraduate university classrooms for automated roll-call and in-class quizzing or voting. By dumping and analyzing its firmware, one can determine the radio protocol necessary to intercept and forge packets, as well as to build a custom base station. The radio hardware that I have used is a reprogrammed Next HOPE Badge running the GoodFET firmware.

A follow-up article will likely describe the writing of replacement firmware, but that can be easily enough discovered by an enterprising reader. My purpose instead is to provide the information necessary to build compatible products, as well as to teach the technique of reverse engineering these products to find such information when none is available.

Disassembly

The Clicker's keypad is attached only with adhesive, and it can be pulled off after lifting an edge with a knife blade. Beneath the keypad, there are four screws holding the board in place, plus a fifth from the rear of the device. If you are lucky, these will be small Phillips screws, but the unlucky will find tri-wing "Nintendo" screws. I was lucky to have one of each type, but those with neither a Phillips-screwed Clicker nor a tri-wing screwdriver can buy one or try one of these tricks.

In either case, it isn't strictly necessary to open your clicker, as test-points for dumping and replacing its firmware are accessible from the battery compartment. Further, the radio communications are accessible with no hardware access whatsoever.

Hardware

The Clicker is built upon a Nordic nRF24E1 chip, which combines an 8051 microcontroller with an nRF2401 radio transceiver. Although the two cores have been combined into a single package, the 8051 core speaks to the radio through a few bit-field registers and an internal SPI bus, which is shared with the external SPI bus.

As the nRF24E1 lacks internal non-volatile storage, a CAT25C32 (pdf) SPI EEPROM is used for program and configuration storage. Within the microcontroller, there is a masked ROM bootloader from 8000h to 81FFh that loads executable code from the EEPROM into executable RAM from 0000h to 0FFFh.

Dumping Firmware

At the base of the circuit board's primary side, there are test points for the SPI EEPROM. As the default firmware only uses the SPI bus when buttons are pressed, this EEPROM may be dumped at any point after the device has booted. The test points are as follows, which should be matched to those of equivalent names in the GoodFET SPI Table. They were determined by use of a continuity tester.

T4	MISO
T5	SCK
T6	MOSI
T3	!CS
T1	VCC
GND	GND

In order to dump the firmware, I quickly wrote a GoodFET client for the 25C32 using its datasheet. A read is performed by sending {0x02, AL, AH, 0} as a SPI transaction, with the result coming back as the fourth byte. Doing it this way with the GoodFET's SPI driver is slower than having C code within the GoodFET dump the whole ROM, but it's fast enough for a dump and takes very little code.

From this point, I dumped the firmware with 'goodfet.spi25c dump image.hex', converted the Intel Hex file to binary, and popped it open in Emacs/hexl. The result looks something like the following, whose format is described in the nRF24E1 datasheet. The opening passage is {u8 config, u8 entry offset, u8 blockcount}. Here {0x0B, 0x07, 0x0B} means that executable code begins at byte 0x07, and that the total image length is 0x0B*256==2,816 bytes. (Additional space within the SPI ROM is unused and left as 0xFF.)

To produce an image suitable for a disassembler, I cut the bytes before 0x07 to make an image beginning with {0x02, 0x0A, 0xB7, ...}. The extra bytes in this region are the serial number and default frequency, but we'll get back to that later.

Firmware Analysis

As the firmware is only three kilobytes, it doesn't take terribly long to reverse engineer. First, the Special Function Registers (SFR) which are defined on pages 79 and 81 of the nRF24E1 datasheet are fed to the disassembler.

(I'm using IDA Pro here, but any 8051 disassembler with a decent text editor could suffice. All of the following function labels are from my imagination, while Special Function Registers (SFRs) come from the nRF24E1 datasheet.)

For example, "MOV 0xA0, #0x80" is rather opaque, but "MOV RADIO, #0x80" makes it clear that the immediate value 0x80 is being placed into the RADIO register. Page 89 of the datasheet will then explain that the high bit of the radio register is power control, so this instruction is powering up the radio for use. Similarly, "SETB RADIO.3" is setting the fourth bit of the RADIO register, which the datasheet describes as raising the CS signal.

Once the SFR addresses are known, it becomes useful to search for them in order to identify the I/O routines. In the nRF24E1, the radio is accessed across a SPI bus, so a good first step is to identify the SPI routine. The function containing this code will always include a MOV involving the SPI_DATA register.

Having this, a list of cross-references quickly shows that while few functions call the SPIRXTX function, each calls it many times. This is because the author has chosen to repeatedly call that function with immediate values, rather than to dump an array of bytes with a for(){} loop.

While the disassembler can automatically identify the function entry points in the table above, it is not capable of giving them English names or descriptions. To understand how this is done, it is necessary to read the datasheets of the SPI devices.

The SPI EEPROM chip, a CAT25C32, is used by dropping the !CS line then writing an opcode byte followed by its parameters or results. Opcodes include WREN/WRDI for write protection, RDSR/WRSR for accessing a status register, and READ/WRITE for reading and writing bytes. A WRITE may only be performed when the external !WP pin is low and the software write protect has been disabled by opcode. A transaction begins when !CS drops low and ends when it drops high.

To identify the function which reads a byte from the 25C32, a few things can be safely assumed: (1) The function will begin by dropping some I/O pin (!CS). (2) The function will then broadcast the READ opcode, 0x03. (3) It will then broadcast a sixteen bit parameter; that is, DPL followed by DPH. (4) Finally, it will return the result of a fourth SPIRXTX call. In pseudocode, that would be something like

SPIROMPEEK(u16 ADR){
  SPIRXTX(0x03);
  SPIRXTX(ADRL);
  SPIRXTX(ADRH);
  return SPIRXTX();
}

Sure enough, one of the few functions calling SPIRXTX does exactly this. The constant pushing and popping of the parameters is a quirk of the compiler, which might possibly allow it to be identified. From the code below, it is clear that P0.0 is the !CS line of the CAT25C32.

The SPIROMPOKE function looks similar, except that two transactions are performed. First the WREN (0x06) opcode is sent to enable writing, then WRITE (0x02) is used to perform the actual write.

The other SPI operations concern the nRF2401 radio core, which behaves differently from the EEPROM. Rather than transactions being an opcode followed by parameters, there is only a single SPI register that must be completely written during a transaction. A second register, selected by the CE line, contains the packets.

The configuration is set by one big register, sent MSBit first. If fewer than the needed bytes are sent, the value is right-aligned into the lower bytes of the register. That is, the last byte sent is always (CHAN<<1)|RXMODE and the second to last always describes the radio configuration.

Searching around a bit yields the RADIOWRCONFIG function, the tail of which is below. It can be seen from the code that the 0x1A IRAM byte holds the channel number. That is, if 0x20 is stored at 0x1A, the radio will be configured to 2,432 MHz. The other configuration bytes reveal that the MAC addresses are 24 bits, the checksum is 16 bits, and the device broadcasts at maximum power sourced from a 16MHz crystal. (That the configured crystal is identical to the one on the board is very important. Some enterprising coders will lie to a chip about its crystal in order to access an unsupported radio frequency.)

At this point, it still remains to sniff traffic is to find the target address to which packets are broadcast as well as the frequency. We'll start with the address, because that's a bit easier.

The TXPACKET function involves a lot of PUSH and POP instructions, but it otherwise looks very similar to the RADIOWRCONFIG function, in that a series of bytes are written in order with repeated function calls to SPIRXTX. In pseudocode, this function becomes the following. From the radio documentation and configuration, it is clear that the first three bytes will be the target MAC address. From the RADIOWRCONFIG() function, it is equally clear that the three bytes at 0x1B are the receiving MAC address of the unit. (The parameter of the function happens to be the button press, as can be determined by tracking the keyboard I/O routines or viewing a few packets.)

void TXPACKET(u8 button){
  RADIOHOP(); //set channel
  
  //Target MAC address
  SPIRXTX(&0x1E);
  SPIRXTX(&0x1F);
  SPIRXTX(&0x20);
  
  //Source MAC address
  SPIRXTX(&0x1B);
  SPIRXTX(&0x1C);
  SPIRXTX(&0x1D);
  
  //Data value
  SPIRXTX(button);
}

The radio itself will append a 16-bit CRC; therefore, the full packet then becomes {u24 tmac, u24 smac, u8 button}.

To determine the value of the target MAC address, just grep the disassembly for "mov" and one of 0x1E, 0x1F, 0x20. The relevant instructions are as follows, setting the target MAC address to 0x123456. (In 8051 notation, the first instruction moves the immediate constant #0x12 into byte 0x1E of IRAM.)

mov 0x1E, #0x12
mov 0x1F, #0x34
mov 0x20, #0x56

As this point, it would be possible to scan each channel for a few seconds, listening for packets sent to that address, but it's classier to find the value by static analysis. Acting on the hunch that the configuration is held in EEPROM and looking for references to the SPIROMPEEK() function, the READIDFREQ() function can be found. As can be seen in the fragment below, EEPROM[6] holds the channel number while the MAC address is at EEPROM[3,4,5].

As the EEPROM begins with "0b 07 0b 15 79 1b 29", it's clear that the MAC address of the unit from which it came is 0x15791B and that it is broadcasting on 2400+0x29=2441MHz. This can be double-checked by the serial number "15791B" being printed on the label.

Implementation

Knowing the modulation scheme, target address, and packet contents, it becomes possible to sniff traffic from a Clicker. This is performed by use of the GoodFET firmware on a Next Hope badge, my prior tutorial for which describes the process of packet sniffing.

The NHBadge board contains an nRF24L01+ radio, which differs dramatically from the nRF2401 in terms of how it is configured. Still, the radios are sufficiently compatible. The following hack of the goodfet.nrf client allows packets to be sniffed from the air with proper checksumming.

Sure enough, here are some packets of the 5 button being pressed on unit 1F8760. The keypress is the final byte in ASCII.

Response Codes

Now that it is clear how to receive and recognize button presses, it becomes necessary to reverse engineer the response codes which might be sent from the access point. Without hearing a reply of at least an ACK, the Clicker will continue to broadcast each message more than three hundred times. This takes more than ten seconds, during which all other key presses are ignored.

The broadcast loop within the MAIN() function would look a little like this in C.

for(count=0;count< MAXCOUNT && !reply;count++){
  TXPACKET(button);
  reply=RADIORX();
}
switch(reply){...}

This region is easy enough to find, but there's another command mode. An easier target is the channel hopping routine, which constantly broadcasts 0x3F while incrementing the channel, sticking with the last one on which a reply of 0x18 was received. Channels 1 through 83 are attempted; that is, 2,401 MHz to 2,483MHz at 1MHz steps.

Checking this code within the MAIN() function reveals that its effect is to blink the green LED (P1.1) six times, exiting the broadcast loop. Other commands include 0x04 (LED Off), 0x06 (LED Green), 0x15 (LED Red), 0x11 (Blink Green), 0x14 (Blink Red), and 0x18 (Blink Green, Channel Lock). All undefined opcodes set the red LED.

Conclusions

By sniffing traffic within a classroom, it is possible to watch votes as they are being cast by students. Similarly, packets could be broadcast by a reprogrammed Clicker or NHBadge to make a student in virtual attendance, automatically voting with the majority so as to gain perfect attendance and a solid C quiz average. Where instant feedback is available, this might even allow for a solid A quiz average. Without taking advantage of the masked-ROM option of the nRF24E1, the code cannot be even slightly protected from extraction and reverse engineering.

Less adventurous users can jam the network by running 'goodfet.nrf carrier 2441000000' to hold a carrier wave on the channel. The only attempt at a frequency change is made when pressing the GO button, at which point the new channel can be discovered and similarly jammed.

Since performing this work, it has come to my attention that a USRP plugin for doing this to the competing 900MHz iClicker product is available as http://gr-clicker.sourceforge.net/. Additionally, the infrared Clicker units were broken with a little tool called Survey Says. I have ordered more sophisticated Clicker models from CPS and Turning Point, and proper descriptions of them will soon follow.

Hacking the Next Hope Badge

2010-06-10T23:12:00.035-04:00

by Travis Goodspeed <travis at radiantmachines.com>

In just less than a month, the Next Hope conference will bring a few thousand neighbors to Manhattan's Hotel Pennsylvania to share all sorts of neighborly ideas. The following are some notes that will help enterprising neighbors to hack these badges, which will be running an MSP430 port of the OpenBeacon firmware. These badges are active RFID tags which beacon the position of each attendee a few times a second, so that the god damned devil army of lies--by which I mean the Next Hope badge committee--can track each attendee around the Hotel Pennsylvania. A second part will continue just before the conference begins, but I hope that this will provide sufficient food for thought.

See http://amd.hope.net/ for a nice little video explaining the purpose of the project as a whole. Those who do not wish to broadcast their positions can remove batteries or reprogram them, but to be thorough, they should turn off their cellular phones as well.

A public HTTP API for querying the badge database is defined in the OpenAMD API Manual, and a server should be available for beta testing before the conference begins. For example, to find the location of user 31337, the client will fetch /api/location?user=31337 then look at the X, Y, and Location fields to determine the users position. As for this article, I will stick the badge hardware, its design, and all sorts of neighborly and malicious things that may be done with it or to it. Little mention will be made of the higher levels of the stack, as those are not my specialty.

Also, in order to keep things fun, I reserve the right to lie about any and all technical details of the badge, its operation, or its security mechanisms. This document by no means complete, and there are still plenty of secrets to find.

Badge Hardware, Usage

The badges themselves are built from an MSP430F2618 or MSP430F2418 microcontroller, as well as an NRF24L01+ 2.4GHz radio. The MSP430 chips were kindly donated by Texas Instruments, and replace the energy guzzling PIC chips of yesteryear. Further, they've got a great C compiler and bootloader, so you cannot brick them no matter how bone-headed your replacement firmware might become.

The back of the badge consists of just a battery clip, but it can optionally be populated with an SSOP28 FT232RL USB to Serial adapter an a mini-USB plug. This USB port then allows for replacement firmware to be loaded, as well as a high-speed serial link to that firmware. Kits will be available containing the parts necessary for this, though you should expect them to sell out quickly.

For the schematic, grab the full-res version of this image.

The layout, for the moment, is private, but you can expect it to be similar to the following cropped image of the prototype. Badges will come in Blue for attendees, Green for speakers, and Red for goons, with prototypes having a white silkscreen.

GoodFET Firmware

When the badges have been flashed with the GoodFET firmware, a prebuilt radio client is available in the form of goodfet.nrf. For example, running 'goodfet.nrf sniffob' will sniff the OpenBeacon protocol, while 'goodfet.nrf carrier 2479000000' will place a carrier wave at 2.479 GHz, jamming any carrier-sensing radios on that frequency.

The full Python scripting environment of the GoodFET is available to the NRF port, so it is easy to script this usage. If you'd like to broadcast Morse code by turning the carrier on and off, you can do so without ever touching a C compiler. The same goes for frequency hopping or packet sniffing, although some architectural limitations of the NRF24L01+ make sniffing difficult without knowing the first three bytes of the destination MAC address to be sniffed.

This code is already committed to the mainstream GoodFET repository. Here it is running on Windows XP, sniffing encrypted traffic from a Last Hope badge.

Radio Configuration Extraction

The exact radio channel and addresses will be a surprise for the conference, but there's little harm in my showing you how to extract them from a running firmware image.

Start with a virgin badge; that is, one which has not been reflashed. Solder on a USB chip and connector, then perform the following without disconnecting it from power. The idea here is to replace the existing MSP430 firmware, then extract the contents of the radio's RAM which is not damaged by a reflashing of the MSP430. It might help to have already tested an installation of the GoodFET client, as you rebooting the host PC might cause the radio to lose its settings.

First, reflash the badge with the goodfet firmware by running 'goodfet.bsl --fromweb' in Unix or 'gfbsl.exe -e -p goodfet.hex' in Windows. Once this is complete, you can dump the radio settings by 'goodfet.nrf info'. For a Last Hope badge which was dumped in a similar manner, the results were as follows.

air-2% goodfet.nrf info
Encoding GFSK
Freq          2481 MHz
Rate          2000 kbps
PacketLen 16 bytes
MacLen     5 bytes
SMAC  0x424541434f
TMAC  0x0102030201
air-2%

You can get more detail by dumping all registers,

air-2% goodfet.nrf regs
r[0x00]=0x000000000a //          CONFIG
r[0x01]=0x0000000000 //           EN_AA
r[0x02]=0x0000000001 //       EN_RXADDR
r[0x03]=0x0000000003 //        SETUP_AW
r[0x04]=0x0000000003 //       SETUP_RET
r[0x05]=0x0000000051 //           RF_CH
r[0x06]=0x000000000f //        RF_SETUP
r[0x07]=0x000000002e //          STATUS
r[0x08]=0x0000000000 //      OBSERVE_TX
r[0x09]=0x0000000000 //             RPD
r[0x0a]=0x424541434f //      RX_ADDR_P0
r[0x0b]=0xc2c2c2c2c2 //      RX_ADDR_P1
r[0x0c]=0x00000000c3 //      RX_ADDR_P2
r[0x0d]=0x00000000c4 //      RX_ADDR_P3
r[0x0e]=0x00000000c5 //      RX_ADDR_P4
r[0x0f]=0x00000000c6 //      RX_ADDR_P5
r[0x10]=0x0102030201 //         TX_ADDR
r[0x11]=0x0000000010 //        RX_PW_P0
r[0x12]=0x0000000000 //        RX_PW_P1
r[0x13]=0x0000000000 //        RX_PW_P2
r[0x14]=0x0000000000 //        RX_PW_P3
r[0x15]=0x0000000000 //        RX_PW_P4
r[0x16]=0x0000000000 //        RX_PW_P5
r[0x17]=0x0000000011 //     FIFO_STATUS
r[0x18]=0x0000000000 //               ?
r[0x19]=0x0000000000 //               ?
r[0x1a]=0x0000000000 //               ?
r[0x1b]=0x0000000000 //           DYNPD
r[0x1c]=0x0000000000 //               ?
r[0x1d]=0x0000000000 //               ?
r[0x1e]=0x0000000000 //               ?
r[0x1f]=0x0000000000 //               ?
air-2%

Sniffing traffic with the GoodFET firmware requires only that these same registers be loaded back into the NRF chip, and also that the MAC addresses be swapped. That is, to sniff Last Hope badge traffic, you will want RX_ADDR_P0 to be 0x0102030201 rather than 0x424541434f.

To perform this on a badge as prepared above, simply run the following.

air-2% goodfet.nrf poke 0x0a 0x0102030201
Poking 0a to become 0102030201.
Poked to 102030201
air-2% goodfet.nrf sniff
Listening as 0102030201 on 2481 MHz
 dd 8f 4a 5b ff 7c bb 76 09 42 a6 ec 61 6f 9a db
 90 bb 2f cd 06 81 e9 36 20 9c 4c 23 b3 10 6c c7
 37 7a 37 c5 93 57 2b 24 6a 9d 9a 8b 3c 52 1c 23
 56 a8 04 f5 a7 ed 26 0b 24 ec 39 9d 10 fb da 76
 ba b5 d0 5c 89 4d 1c 63 19 28 a1 9d 35 e6 7f a5
 ec 63 5f 60 b8 0f 1c bf 4c e6 af 93 c2 fe 93 ee
 ad fc a1 25 42 81 7a a1 28 a8 f5 21 4a 7a 55 af
 79 42 5c 6d 38 ca 46 ab 1b 8c ab 90 ad 47 90 d1
 f6 9a 22 0d e4 37 19 b7 75 34 8d 4f f9 9c fd 2a
^C
air-2%

Key Extraction

Concerning cryptography, the badges will have it, but that oughtn't stop you from having some fun. Badges are XXTEA encrypted, with keys being published after each conference. A list of old encryption keys can be found at http://wiki.openbeacon.org/wiki/EncryptionKeys, with the key for the above packets being {0x9c43725e,0xad8ec2ab,0x6ebad8db,0xf29c3638}. Example decryption routines are plentiful within the OpenBeacon source repository.

If the badges used more sophisticated radio chips, such as the SPI 802.15.4 chips, an AES128 key would be present within the radio to be read out. Since this isn't the case, the key stays within Flash or RAM of the MSP430 microcontroller.

Flash extraction requires that an attacker gain access to memory through the serial bootstrap loader (BSL) or through JTAG. The BSL is protected by a password, one which might or might not be vulnerable to my timing attack. The timing attack is impossible to perform through the FTDI chip, so a second microcontroller must be wired up to the 0.1" serial port header.

Additionally, it might be possible to extract the contents of Flash through the JTAG port through which these chips are initially programmed. Unlike the bootloader, there is no password protection, but rather a security fuse which is blown to disable future access.

RAM is not protected by the serial bootstrap loader, and you can extract it by first erasing the chip by 'goodfet.bsl -e', then dumping the contents of RAM to disk for later perusal. Somewhere in this mess will be a copy of the XXTEA key, unless I took the time to ensure that is not copied into RAM at startup.

Packet Format

Once decrypted, packets look like the following.

 SZ PR FL ST SEQUENCENUM SOURCEIDXXX RESVD CRC16                                
 10 17 00 ff 00 0a 6f a7 ff ff ff ff 00 00 e7 53                                
 10 17 00 ff 00 0a 6f ab ff ff ff ff 00 00 b5 38                                
 10 17 00 aa 00 0a 6f ae ff ff ff ff 00 00 54 79                                
 10 17 00 ff 00 0a 6f b3 ff ff ff ff 00 00 11 ee                                
 10 17 00 ff 00 0a 6f b7 ff ff ff ff 00 00 d0 28                                
 10 17 00 aa 00 0a 6f ba ff ff ff ff 00 00 a2 c4

Fields in order are Size, Protocol, Flags, Strength, Sequence, Serial Number, Reserved, and a CRC16 checksum. The 8-bit Flags field indicates the bits of a capacitive multi-touch sensor, while the Reserved field has been co-opted for a secret project of mine. The Source ID is the badge's serial number, which can be found on a sticker that is present on the badge.

The sequence number is incremented for each packet while the last few bits of it determine the broadcast strength. In this example, the badge is rather far from the reader, so all 00 and 55 strength packets are lost, while some AA and FF packets get through. FF being stronger, more of its packets go through. Comparing packet loss rates allows the aggregation server to determine badge positions.

The received signal strength, RSSI, of each packet is not used in this calculation because it is rather primitive in the NRF24L01+, being only a single bit wide. Competing chips, such as the CC2420, would allow this but only at a significant increase in unit cost.

Breakouts

To facilitate badge hacking, there are four breakout headers, all of which have standard 0.1" spacing.

The first is a 14-pin MSP430 JTAG connector, the same used by the MSP430 FET UIF and the GoodFET.

The second is a 6-pin BSL header, in the style of FTDI breakout boards from Sparkfun. This has not been tested, and you had damned well better only use it at 3.3 volts.

The third is a 7-pin breakout connector for the NRF24L01+ radio and SPI bus. You might use it to add an additional SPI chip, such as a second radio or an LCD. The pins are (1) GND, (2) CE, (3) !CS, (4) SCK, (5) MOSI, (6) MISO, and (7) !IRQ. The !IRQ signal is only asserted by the NRF when configured to do so, so it might be coopted to act as a !CS pin for a second SPI device.

The fourth and final header is an 8-pin breakout of Port 3 of the MSP430 microcontroller. By default, it is used as a capacitive touch sensor, but it might also be used for any sort of I/O expansion. In addition to GPIO, some hardware accelerated ports are available on this pins. I'll leave you to the datasheet to figure them out.

Compatible Hardware

The ANT wireless protocol can be implemented with the NRF24L01+ of this badge, though technical details on exactly how to do it are rather difficult to find. I'd be much obliged if some neighbors brought ANT equipment to the conference for the rest of us to play with.

Sparkfun offers a number of NRF24L01 modules, my favorite of which is a Key Fob Remote.

Stay Tuned

These details should help you to spend more time hacking, and less time researching, during the conference. A special prize will be given for the most original badge modification, with heavy credit going toward those of high technical caliber. There are also some secrets to be found within the badges, so best to bring b

I will be presenting this and a several more tricks as a lecture during the conference, entitled "Building and Breaking the Next Hope Badge" at 22h00 on Saturday, July 17th in the Tesla room. There will also be a panel presentation entitled "The OpenAMD Project" at 18h00 on Friday, July 16th in the Lovelace room. Both rooms are on the 18th floor.

CUDA PTX Extraction

2010-04-26T15:13:00.010-04:00

by Travis Goodspeed <travis at radiantmachines.com>
concerning CUDA 3.x on Darwin
as the first of several CUDA articles.

The following are some brief introductory notes on dumping PTX kernels from modern CUDA applications, as well as techniques for embedding them within new applications. One or two copies of every shader are stored as ASCII strings within each CUDA executable by default. With a little ingenuity, the contents of this article and a decent machine with a G80 card should provide a decent start in reverse engineering general-purpose GPU applications.

Nvidia's CUDA framework for GPU computing uses a portable meta-assembly language, PTX (ptx_isa_2.0.pdf), to facilitate translation between multiple GPU devices. In this manner, they can escape the backward compatibility issues that hold most modern CPU architectures to a single instruction set. PTX vaguely resembled the underlying machine code, but it lacks features which would tie it to any particular GPU. In this brief article, I present a trivial method for extracting PTX assembly from CUDA applications, as well as some pointers for merging that code into new applications.

Dumping

The screenshot below shows a fragment of libcublas.dylib from CUDA 3.0 in Snow Leopard being edited in Emacs. Following the dozens of assembler directives are individual VM opcodes. (This contains Basic Linear Algebra Subprograms. As this comes from Fortran, not C, the code is a bit weird.) By default, CUDA will compile inline code in a language similar to C into PTX assembly, then include the PTX assembly string verbatim into the resulting executable or library. User comments are not preserved, but compiler comments are introduced and names are unaltered. Except where hand-written, the compiler will always be nvopencc.

The nvopencc compiler has a number of quirks when writing PTX:

Every line that is not a label is tabbed in at least once.
The first directive is .version, the second is .target.
Registers are declared in groups.
Names are preserved, with C++ mangling.

Further,

Every PTX script ends with a null (0x00) byte.
While they can be big, no PTX script is larger than two megabytes.
PTX scripts come in pairs, one for sm_20 and another for sm_10.

To dump the PTX code from a binary, Mach-O executable, just scan the input for long strings, printing everything starting with "\t.version". In my own setup, I have an ugly C program that prints these, passing them off to the unix split command for separation into multiple PTX files.

The 312 PTX scripts from CUBLAS are mostly small, with only nine of them having source in excess of a megabyte but none being larger than two megabytes. Thus, you'll need a rather long string buffer. Additionally, it is handy to purge the buffer when no fragment of a PTX executable is found and whenever a null byte is encountered. You can find the PTX from the vectorAdd example at http://pastebin.com/nqKqKhNc.

Applications can be compiled without PTX inclusion, using machine-language CUBIN files instead. This has the disadvantage of not being forward-compatible, and thanks to Wladimir J. van der Laan's Decuda project, it isn't much more difficult to read.

To try this out yourself, first build a dumping script based upon the CUDA examples and libraries. Once you have that, try downloading a few of the more advanced demos. The Nvidia Graphics Plus demos might be a good target, as would any game advertising CUDA support.

PTX JIT

Having dumped a PTX script, it is handy to link it back into an existing project. For this, you will want to use the matrixMulDynlinkJIT or ptxjit examples that come with the CUDA development kit. These projects use the cuModuleLoadDataEx() method to link a PTX script from a string, then cuModuleGetFunction() to grab a CUfunction pointer to any function.

Conveniently, the PTX scripts include symbol names, but as with any complex compiler, these have been somewhat mangled. In the addVector example, the entry point hask been mangled to _Z6VecAddPKfS0_Pfi for both sm_10 and sm_20. It is this function name, and not the simpler VecAdd, that must be passed to cuModuleGetFunction().

This is the code that the ptxjit example uses to load a kernel named _Z8myKernelPi kernel contained within the myPtx[] character array. Looking at the string itself, which is defined within ptxjit.h, it can be seen that the code was rather hastily dumped by a method similar to the one I describe above.

Caveats

GPU programming is sufficiently confusing when source code is available that the lifting of code oughtn't be a concern. Generally only small fragments are executed within the GPU, with the majority of development time being spent debugging those fragments and twisting them for different physical optimizations.

Daniel Reynaud's talk on GPU Powered Malware at Ruxcon 2008 proposed that GPU programs might be useful for malware URL generation. It goes without saying that sophisticated malware will do better than to include an unencoded ASCII string. Pre-assembled bytecode can be provided directly to the card, avoiding the inclusion of a PTX string. While some of Reynaud's points are less relevant now that CUDA has debugging and bytecode emulation, the core of his argument that GPU packers will become important is still valid. For starters, it is possible use a pegged memory segment to have GPU code rewrite host X86 code on the fly without a context switch!

Expect some follow-up articles on the neighborly things that can be done once your hands are inside the beast that is CUDA.

Smartgrid Skunkworks

2010-03-24T06:39:00.002-04:00

Dearest engineers and hackers, and also their management,

Recent vulnerabilities found in smart meters and HAN devices have shown a number of weaknesses in the engineering practices used to build these devices and their constituent components. A vulnerability in a chip or library is fixed slowly, and it is a very rare event that the meter and thermostat vendors affected by the vulnerability are notified by their suppliers. Because of this, vulnerabilities are spreading downward through the supply chain, and the engineers of smart grid devices are left uninformed.

While those utilities that actively investigate security have a considerable amount of bargaining power with their immediate suppliers, the rest of the supply chain has no similar leverage to compel security notifications. Chip and library vendors are failing to notify the meter vendors that depend upon their components. Even when the meter vendors are notified directly of vulnerabilities, thermostat and other HAN vendors can have no realistic expectation of such a privilege.

Despite having found many vulnerabilities in microcontrollers and LPAN radio chips, I have never seen one single security issue mentioned in the errata sheets of these devices. It has been a year since I first reported to Texas Instruments that the RAM of their Chipcon 8051 core is exposed to an attacker, but there's not one scrap of documentation from the firm to its customers suggesting that they make the simple patch of moving the key variables to Flash memory. The example ZigBee stack for the chip is still vulnerable to this attack, even after recent patches! A year later, exactly two debugger commands are all that are required to extract keys from nearly every ZigBee SEP device with a Chipcon radio, and no one knows to patch their code! (Do not be smug if you are an Ember customer. The EM2xx chips are unpatchably vulnerable to debugger key extraction, and there is no mention of this in the chip's errata sheet either.)

As chip and library vendors have failed to document the publicly known vulnerabilities in their products, and as they have often been unable or unwilling to repair them, the most expedient remedy to this problem is a separate line of communication. At least one point of reference must exist for the engineers trying to build these products.

For these reasons, I have created a skunkworks mailing list for the announcement and discussion of smart grid vulnerabilities, particularly but not exclusively those in AMI equipment. This is to be a list for engineering discussion, by engineers and security researchers. Anonymous posts and lurking are welcome, but politics and committee items are not.

For this reason, I especially request that those firms which care about security ask--or perhaps even require--their engineering staff to subscribe. This list is the appropriate place to post questions concerning the secure use of a particular radio chip, fragment of code, or anything else which is too low level or vendor-specific to be mentioned in standards.

If your firm is unwilling to allow its engineers to post, please at least compel them to follow the posts of others. In saying nothing, they will still learn how to make more secure products along with all sorts of fascinating gossip about your competitors. Your firm has every right to keep its mouth shut, but keeping its ears shut is a betrayal of each and every one of your customers.

To kickstart this mailing list, I will make it my first site of public disclosure for smart grid vulnerabilities over the coming months. The subscription link is below, and I invite you to join me in preventing smart grid vulnerabilities before they are created.

http://groups.google.com/group/smartgrid-skunkworks

Thank you kindly,
--Travis Goodspeed
Belt Buckle Engineer
Security Hobbyist

IM ME GoodFET Wiring Tutorial

2010-03-09T21:11:00.002-05:00

by Travis Goodspeed <travis at radiantmachines.com>
concerning the Girltech IM ME,
with a million thanks to Dave.

WARNING: Reflashing the CC1110 while batteries are low will permanently lock the chip. Either be damned sure to use fresh batteries or leave the batteries out and power the IMME from your GoodFET.

Howdy y'all,

This brief tutorial describes the process of reflashing the Girltech IM ME with custom firmware, so that it may be used as a development platform for the Chipcon CC1110 sub-GHz ISM System-on-Chip. I assume the reader to have an assembled GoodFET with recent firmware, but other programmers may of course be substituted.

You should also read Dave's first article on IM ME hacking, as it describes his method for reprogramming the device. All the pinouts below were taken from his articles, as well as the keyboard and LCD information that he was so neighborly as to publish.

Wiring

First, you'll need to purchase an IM ME, which can be had for $20 USD on a few toy sites while it remains in stock. You'll also need an assembled GoodFET and basic electronics tools.

The testpoints used for programming the IM ME are located behind the batteries in the rear compartment of the device. Ideally, a bed of nails should be used to clip into it, but failing that, just solder on to the Debug Data (DD), Debug Clock (DC), Reset (!RST), and GND pins. Run these to the GoodFET's 14-pin header as shown below.

From left to right on the IM ME, the pins are !RST, DD, DC, +2.5V, and Ground. Because the GoodFET is a low-voltage device, there's no need for the resistor dividers in Dave's article. Use EITHER the GoodFET OR the batteries for VCC, but not both.

Name	Pin		Name
DD	1	2	Vcc
	3	4	Vcc
RST	5	6
DC	7	8
GND	9	10
	11	12
	13	14

Flashing

Once you have the IM ME wired up, you can check its model number and status by running `goodfet.cc status'. This will tell you that the chip is locked, so making a backup of its firmware is non-trivial. If you continue from here, the IM ME will no longer function as an instant messenger.

Erase the chip by 'goodfet.cc erase' then dump an image of RAM as 'goodfet.cc dumpdata immeram.hex' to see if anything neighborly can be found inside.

You now have a blank IM ME, with the LCD most likely showing the last gasping breaths of its firmware. To flash a new firmware image, just grab its ihex file and run 'goodfet.cc flash foo.hex'.

I've placed a few example binaries in the repository of an operating system that I've started for the IM ME called GoodME. To flash Dave's LCD Test, run the following commands.
svn co https://goodfet.svn.sourceforge.net/svnroot/goodme
goodfet.cc flash goodme/bins/dave-lcdtest.hex

For a more functional demo, try bins/term-morse824mhz.hex, an ugly hack of an operating system for the IM ME with a Morse code transmitter and random number generator demo. In the Radio demo, holding any of the letter buttons broadcasts on 824MHz. The PRNG demo, shown below, demonstrates the repetition of strings withing the psuedo-random number generator and counts the number of bytes between them. This is sometimes used for key material.

Custom Development

The SDCC compiler is in the package repositories of most civilized operating systems. You might need a more recent version for the cc1110.h header, though building this compiler is a thousand times simpler than GCC. Compiling an example is as simple as sdcc foo.c; packihx <foo.ihx >foo.hex, which will produce a suitable Intel Hex file for flashing. The 8051 memory model makes specifying a chip model unnecessary, a handy deviation from those of us with a thousand MSP430 linking scripts.

Within the GoodME repository, you'll find my bastard child of an operating system at /branches/rough/. It was used to make the term-morse824mhz.hex, and its keyboard, font, and LCD drivers are ripe for organ transplants. /trunk/ ought to someday contain a proper operating system for the device, but for now, I haven't the time to complete it.

Have fun, and build something neighborly,
--Travis

XML of SmartRF Studio 7

2010-02-21T19:12:00.022-05:00

by Travis Goodspeed <travis at radiantmachines.com>
concerning TI SmartRF Studio 7.

For those who have not personally suffered the experience, choosing radio register values is an absolute pain. In this brief article, I will demonstrate a method for extracting settings in bulk from SmartRF 7 Studio for use in other projects.

Suppose that a program should configure a CC1110 to operate on a particular frequency, in a particular encoding, etc. The code will like the following, which is from the CC1110 examples. This will generate a carrier wave near 823 MHz, as the 2.433GHz FREQ[] value is outside of the allowed range.

To choose a different center frequency, the engineer is expected to either find the register's definition within the datasheet or use SmartRF Studio, a screenshot of which is below. The software is a Windows application for communicating with a radio through a serial port. It also allows an engineer to load preconfigured profiles for certain types of modulation, such as IEEE 802.15.4 or SimpliciTI. Once loaded, the settings may be tweaked and loaded into a packet-sniffer firmware for debugging projects.

The screenshot above, from SmartRF 6, can provide a decent idea of how infuriating the software might become. For product development, the register settings are to be copied and pasted into opaque source files. It can instill the same sort of anger as an uncooperative web form, even after the old Visual Studio 6 libraries have been located to make it work under Wine.

SmartRF 7--at Beta 0.9.1 as of this writing--is a new client under active development, one which seems to have been rewritten from scratch or at least significantly refactored. The old Win32 GUI has been replaced with QT4, making a future Linux or Mac port possible. Most importantly of all, however, is that the default configurations, as well as register explanations, are stored as XML.

The screenshot above shows how default configurations are chosen for the target radio. Users can select an example, then change any of the settings they like. These configurations are further abstracted into an "Easy Mode" which hides all the messy minutia of radio, abstracting use to standards and channel numbers.

These configuration settings are to be found as XML in the config/xml/ directory, organized by chip and presentation. The following is an example of one such configuration file for the CC1110.

Patching these configurations allows for the easy addition of new standards. For example, I added support for my Tennessee Belt Buckle radio by adding a new stanza to easymode_settings.xml.

The register definitions and their bitfields are also defined in XML. The following from register_definition.xml for the CC1110 described the FREQ2 register's meaning.

Printing SDCC special-function register definitions, such as those found in cc1110.h, is as easy as a bit of Python magic,


#!/usr/bin/python

# Simple script for dumping Chipcon register definitions to SDCC header.
# Only intended as a rough example.
# by Travis Goodspeed, Engineer of Superior Belt Buckles

import xml.dom.minidom
def get_dom(chip="cc1110",doc="register_definition.xml"):
    fn="/opt/smartrf7/config/xml/%s/%s" % (chip,doc);
    return xml.dom.minidom.parse(fn)

dom=get_dom();

for e in dom.getElementsByTagName("registerdefinition"):
    for f in e.childNodes:
        if f.localName=="DeviceName":
            print "// %s=%s" % (f.localName,f.childNodes[0].nodeValue);
        elif f.localName=="Register":
            name="unknownreg";
            address="0xdead";
            description="";
            for g in f.childNodes:
                if g.localName=="Name":
                    name=g.childNodes[0].nodeValue;
                elif g.localName=="Address":
                    address=g.childNodes[0].nodeValue;
                elif g.localName=="Description":
                    if g.childNodes:
                        description=g.childNodes[0].nodeValue;
            print "SFRX(%10s, %s); /* %50s */" % (name,address, description);

These configuration files should allow for new Chipcon radio applications and development tools to be written in short order. Please contact me if you would be so kind as to write a complete Python class for querying this data.

Call for Info Flash

2010-02-05T05:35:00.004-05:00

by Travis Goodspeed <travis at radiantmachines.com>
continuing a discussion of MSP430 Info Flash

Neighborly MSP430 developers, please do me a favor and email me the contents of memory from 0x1000 to 0x1100 of every MSP430F2xx device that you can. I'm trying to reverse engineer the exact distributions of the CALBC1_16MHZ and CALDCO_16MHZ values in order to build a UART library that operates without Info Flash. The GoodFET does this well enough, but I still get the occasional bug report when a device is slightly out of range. I can reduce the default to baud rate or try similar tricks to get around this, but I want to know exactly which values are safe.

If your GoodFET can be programmed by goodfet.bsl but does not respond after programming, try the info flash images available in /contrib/infos/ to see if any of them work.

air% goodfet.bsl -e -p 2618-002.txt;\
goodfet.bsl -p ../../trunk/firmware/goodfet.hex   
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Program ...
256 bytes programmed.
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Program ...
10596 bytes programmed.
air% goodfet.monitor peek 1000 100A
1000 55aa
1002 3fff
1004 abcd
1006 55aa
1008 1234
air%

Previously programmed GoodFETs have info flash wiped during programming, but if yours has never been programmed, you can dump the info with

goodfet.bsl --dumpinfo >info.txt

ZStack PRNG Fixed

2010-01-25T14:00:00.001-05:00

by Travis Goodspeed <travis at radiantmachines.com>
concerning versions 2.2.2 and 2.3.0 of TI Z-Stack
and a fix of the ZigBee Smart Energy Profile ECC vulnerability.

Texas Instruments has released version 2.3.0 of Z-Stack, their ZigBee stack for the TI/Chipcon CC2530, MSP430, and CC430 chips. The new version adds a variety of new features, but chief among them is a fix to the random number generator which used to be utterly insufficient for cryptographic use. Technical details on the vulnerability were first revealed publicly in my last article. (Nate Lawson's translation is here.)

Source code for the new generator is not included, but rather references as a Security Service Provider (SSP). Since 2.2.3, they have extended the SSP API to include SSP_GetTrueRandAES() for generating random numbers by an AES key.

This is then called in zclGeneral_KeyEstablishment_GetRandom(), which in previous versions used the 16-bit LFSR.

Authors of firmware for ZigBee Smart Energy devices that have used this code should patch their source code and issue firmware upgrades as quickly as possible. Those with independent crypto implementations should check to ensure that they have not made similar mistakes. Programmers should also note that

Electric utilities with equipment using the MSP430 or Chipcon CC2530 should contact their vendors for such updates. Unlike Windows and Linux, there's no easy way to perform an upgrade of a fragment of microcontroller firmware to which you haven't got the source.

This fix only applies to the remote recovery of keys by PRNG attacks; local key extraction is still possible by the methods that I outlined in Extracting Keys from Second Generation ZigBee Chips.

PRNG Vulnerability of Z-Stack ZigBee SEP ECC

2010-01-09T10:32:00.001-05:00

by Travis Goodspeed <travis at radiantmachines.com>
with neighborly thanks to Nick DePetrillo,
concerning version 2.2.2-1.30 of TI Z-Stack
and a ZigBee Smart Energy Profile ECC vulnerability.

In past articles, I've presented a variety of local attacks against microcontrollers and ZigBee radios. While I maintain that local vulnerabilities are still very relevant to ZigBee devices, this article presents a remotely exploitable vulnerability in the way that random keys are generated by TI's Z-Stack ZCL implementation of the ZigBee Cluster Library. Randomly generated numbers--those fed into the Certicom ECC crypto library--are predictable, repeated in one of two 32kB cycles. Details follow, with links to source code and a complete list of random numbers.

Dumping Random Bytes

I dumped byte sequences from the CC2430 using the GoodFET to debug a live chip. The chip runs a program which populates IRAM with PRNG bytes, then halts with a soft breakpoint (Opcode 0xA5) for the debugger to grab all sampled values. The main loop looks something like this:

The firmware was compiled with the Small Device C Compiler, flashed by the GoodFET. A quick Python script then used the GoodFET library to debug the target, dumping random values through the same interface that programmed the chip.

Short PRNG Period

Page 18 of the CC2530 Datasheet describes the random number generator peripheral, which is shared by all other 8051-based ZigBee SoC devices in the series.
The random-number generator uses a 16-bit LFSR to generate pseudorandom numbers, which can be read by the CPU or used directly by the command strobe processor. The random numbers can, e.g., be used to generate random keys used for security.

The state of this RNG is initialized in the hardware abstraction library by feeding 32 bytes from the ADCTSTH special function register into RNDH register. Bytes read from ADCTSTH are physically random, but poorly distributed. RNDH and RNDL are the High and Low bytes of a 16-bit CRC Linear Feedback Shift Register, the state of which can be advanced by writing to RNDH or overwritten by writing to RNDL. In between reading or writing from RND, the state is advanced by setting the fourth bit of ADCCON1. Detailed descriptions of these registers can also be found within the datasheet.

CC2430 examples randomize the seed by mixing 32 values into the RNG,

for(i=0;i<32;i++){
    RNDH=ADCTSTH;
    ADCCON1|=0x04;
}

Because these numbers are not evenly distributed, Z-Stack prefers to sample just the least significant bit of the RF random number generator sixteen times, then write them in directly as the state without mixing them. Further, it checks to ensure that the state is not a dead-end, substituting another if it is. This method is also advocated within the CC2530 programming guides.

for(i=0; i<16; i++)
      rndSeed = (rndSeed << 1) | (RFRND & 0x01);
if (rndSeed == 0x0000 || rndSeed == 0x0380)
      rndSeed = 0xBABE;
RNDL = rndSeed & 0xFF;
RNDL = rndSeed >> 8;

Once the RNG has been seeded, it has an initially random 16-bit state. From then on, however, it produces random bytes in a predictable sequence. Only the starting point is random, as ADCTSTH is never used for future reseeding. As shown in the screenshot above, if the sequence "7c e1 e8 4e f4 87" is observed, the probability of the next bytes being "62 49 56 fe 80 00 60" is 100 percent. Further, because the domain is so small, it can be exhaustively searched for keys in little time.

Code for dumping these values through the GoodFET debugger can be found by svn, along with a complete dump of the PRNG sequence.
svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet/contrib/ccrandtest

Seed Values

The plot above shows the histogram of radio ADCTSTL values used to seed the PRNG. These are far from random, but when sampled slowly enough, their least significant bit is probably good enough for key generation. There are, however, two things of interest with this.

First, if the crypto library is used infrequently, it would make sense to use this source of entropy instead of the inadequately random PRNG output. There would be a cost in power consumption, as ADCTSTL is only random while the radio is operating, but the resulting increase to security is necessary.

Second, if the peaks on the histogram come from a measurement of the radio, it might be possible to generate a radio signal that forces even the least significant bit to be a predictable value. Steps such as AES whitening should be taken to avoid such an attack.

ZigBee SEP, ECC

A less than perfect random number generator is not much of an issue when symmetric keys are pre-shared, but because pre-shared keys are vulnerable to local attacks, the ZigBee Smart Energy profile recommends the use of session keys signed by elliptic curve cryptography. See the USAF paper Cryptanalysis of an elliptic curve cryptosystem for wireless sensor networks for a prior break of ECC with a poor RNG.

As will be shown in the next section, Chipcon's ZStack makes use of poorly random PRNG data as key material, allowing for a key domain of only 16 bits. This is small enough to be exhaustively searched, either by a PC or by a "Chinese Lottery" of previously compromised wireless sensors.

ZStack Usage

ZStack 2.2.2-1.30 for the CC2530 makes use of the PRNG to implement the Smart Energy Profile's asymmetric cryptography. The Windows installer works perfectly under Wine, leaving ZStack installed to an awkward directory. I symlink it to /opt/zstack for convenience.

Once installed, the following Functions are of interest.

mac_mcu.c contains macMcuRandomByte() and macMcuRandomWord(). As the two are largely the same, take the former for an example. First the PRNG is clocked, then the high byte is sampled.

zcl_key_establish.c is used to generate keys by the ZigBee Cluster Library specification, available for free by form from ZigBee.org. The code fragment below takes the low bytes of macMcuRandomWord(), redefined as osal_rand(), to populate a session key before signature.

The ultimate function for ECC key generation is ZSE_ECCGenerateKey(), which is defined in eccapi.h but whose source is missing. Reading ecc.r51 yields a few filenames as part of stored compiler warnings. The developer's filename was "C:\SVN-ZStack-2.2.0\Components\stack\sec\eccapi.c", but it is only a stand-in for the Certicom Security Builder MCE library that is not shipped with the development kit. In any case, the vulnerability here lies in ZStack and not in Security Builder.

Conclusions

This article has shown that the Chipcon ZStack library, as of version 2.2.2-1.30 for CC2530, uses an insufficiently random PRNG for cryptographic signatures and session keys. PRNG data repeat every 32,767 samples, and there are at most 16 bits of entropy in any key. Searching the entire key space ought to be possible in very little time. Contrary to the CC2530's documentation, these random numbers must not be used to generate random keys used for security.

All users of this library, particularly those using it for Smart Grid devices and other industrial applications, are recommended to re-implement macMcuRandomWord() and to ensure that nothing requiring cryptographic security operates from the PRNG alone. Users of other libraries for the Chipcon devices should ensure that those libraries are not using the PRNG data.

Competing devices and libraries should also be checked for similar vulnerabilities, as well as commercial products such as Smart Meters that might have forked the ZStack code or followed the datasheet's recommendation of using the PRNG for key generation.

S4 Paper

2009-11-02T08:00:00.000-05:00

Howdy Y'all,

A paper of mine from S4/Miami, Low-Level Design Vulnerabilties in Wireless Control Systems Hardware, has recently been made publicly available by Digital Bond. Coauthored with Brad Singletary and Darren Highfill, it provides a detailed survey of vulnerabilities that might be found in the hardware and firmware of AMI Smart Meters and similar equipment.

Please note that the paper, written late last year, is now outdated in two respects. First, the self-propagating worm presented hypothetically in Section 3.1 is no longer hypothetical. Mike Davis has written one. Second, the System-on-Chip Zigbee devices advocated in the conclusion of Section 4.1 are not secure, as I have since demonstrated in Extracting Keys from Second Generation Zigbee Chips.

--Travis Goodspeed
<travis at radiantmachines.com>

MSP430 Info Flash

2009-10-28T21:37:00.004-04:00

by Travis Goodspeed <travis at radiantmachines.com>

The following is a description of the MSP430F2xx Info Flash, as well as my ugly--yet reliable--hack for initializing the DCO of MSP430F2xx chips after my use of the Serial Bootstrap Loader (BSL) has destroyed the contents of that flash on the GoodFET. This ought to be of use to anyone who wishes to make an MSP430 design without a crystal, as well as for anyone who has accidentally erased info flash.

The mask-ROM bootstrap loader, BSL, of the MSP430 chips is damned handy, despite some security concerns. It allows you to very quickly program a chip by the same USB/serial converter that you use to interface it with a computer, without any of the hassles of having to flash a bootloader onto the chip. In this article, I describe the way in which the MSP430F2xx flash can be accidentally corrupted by the bootloader, as well as a method for repairing that damage by backing up the info flash while the password is left as the default.

The MSP430F2xx family has another dandy feature, that clock configuration values need not be calibrated to an external clock, such as the 32KHz crystal of the older GoodFET models. Instead, configuration data is calculated at the factory and placed into info1 flash, a region of 256 bytes at 0x1000. Using this, code that would be rather complicated can become trivially simple.

The code that configures the clock is configured on the GoodFET with MSP430F1xx chips is too complicated for me to include here. By contrast, on the MSP430F2xx chips, it becomes just

void msp430_init_dco() {
  BCSCTL1 = CALBC1_16MHZ;
  DCOCTL = CALDCO_16MHZ;
}

The security model of the BSL is a bit confusing. Upon connecting, you are required to present a password before reading, writing, or doing anything else that might affect the security of the device. You are, however, allowed to erase all of flash memory--including the info flash--to 0xFFFF. As this is traditionally the first command that you send upon connecting to a device, you will wipe all of the configuration data of a chip in programming it. Finding this problem is hellish, because the exact same code will work if programmed by JTAG and you quite often have not got JTAG handly if you intend to program everything by the BSL.

As part of the GoodFET project, I've forked TinyOS's tos-bsl client to add support for the MSP430F2xx. I've also implemented a "--dumpinfo" command for dumping info flash to a TI Text file. This file can be reflashed after the chip has been erased to restore its factory settings.

petite%  goodfet.bsl --dumpinfo          
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Use -h for help
Transmit default password ...
@1000
aa 55 ff 3f cd ab aa 55 34 12 ff ff aa 55
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff b4 85 fe 16
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff 08 10 00 80 01 00
62 7f b2 0b e8 0d 98 7f 01 07 56 08 fe 08
ff ff ff ff ff ff ff ff 01 08 7f 8f 85 8e
74 8d c2 86 
q

petite%

This output is in the TI Text format, which is easily converted to Intel-hex, but is a hell of a lot easier to write. Piping it into a file allows me to restore the contents of flash after erasure, and also to extract the configuration values which are used on this chip. Because the chips are similar physically, it turns out that the calibration values for one are often sufficient to program another. So by observing the model number (in big endian at 0x0FF0), I can guess in the absence of calibration values.


//! Initialize the MSP430 clock.
void msp430_init_dco() {
  if(CALBC1_16MHZ!=0xFF){
    //Clear DCL for BCL12
    DCOCTL = 0x00;
    //Info is intact, use it.
    BCSCTL1 = CALBC1_16MHZ;
    DCOCTL = CALDCO_16MHZ;
  }else{
    //Info is missing, guess at a good value.
    BCSCTL1 = 0x8f;   //CALBC1_16MHZ at 0x10f9
    DCOCTL = 0x7f;    //CALDCO_16MHZ at 0x10f8
  }
}

When I find the time, I intend to test a large quantity MSP430 chips to determine the exact tolerances of manufacturing, the variances of CALBC1_16MHZ and CALDCO_16MHZ, and the probability that a given unit will so drastically differ from these values that serial communications become impossible. For now, I've found that the hardwired values above seem to work for all recently acquired MSP430F2274, MSP430F2254, and MSP430F2618 microcontrollers when using the hardware UART at 115,200 bits per second. Further, the GoodFET firmware does not require a crystal when running on these chips.

CC2430 Debug Protocol, First Notes

2009-10-17T08:00:00.000-04:00

by Travis Goodspeed <travis at radiantmachines.com>
with thanks to Peter Kuhar

The following are my notes on the debugging mechanism of the CC2430 and other chips (such as the CC2530) from Chipcon using an 8051 core. These notes do not apply to the upcoming CC430. As most of this was written before I implemented the protocol, plenty of errata are likely to exist.

These notes are intended for those who wish to understand how the device is programmed, not for those who merely want a device programmer. See CCFlasher or the GoodFET for that.

Be sure to have a copy of SWRA124, which is the official documentation for this protocol.

Concerning pins, there are three related to debugging. Debug Data (DATA) is a synchronous, bidirectional data line. Debug Clock (DCLK) is its clock, but its edges also control when commands are interpreted, and it is crucial to initializing the chip's debugging unit. The third pin, !RST, puts the chip into a reset state when pulled low, but is also used to start the chip with the debugger enabled. The clock idles low, while !RST idles high. Data is posted during the rising edge, sampled during the falling edge. As there is no equivalent of the SPI !SS pin, it is necessary to dead-reckon commands; a command of incorrect length will cause unneighborly consequences.

To initialize the debugger, pull !RST low while sending two clock pulses on DCLK. It will look something like this,

The command byte 0x34 looks something like this,

Concerning commands, once the debugger has been initialized, the chip will accept a command byte, optionally followed by up to three additional parameter bytes. It will then reply with at least one byte, which might be discarded. Some commands reply with two bytes rather than one.

A command byte is composed of 8 bits. Bits 1 and 0--the least significant--contain the number of data bytes following the command. Bit 2 is labeled "return input byte to host", but it doesn't appear to be observed regularly by the documented examples. The remaining five bits specify the command itself.

Only twelve commands are described in the documentation, but either 16 or 32 commands are possible, depending upon whether the MSBit is variable or fixed to 0 as a sort of start bit.

These commands were chosen to be easy to implement in hardware. They include CHIP_ERASE, RD_CONFIG, WR_CONFIG, HALT, RESUME, GET_PC, and DEBUG_INSTR. There are no primitive commands for peeking or poking memory, nor for managing flash. Instead, macro commands are built up by using DEBUG_INSTR.

Concerning command execution, it is clear from the documentation that a command with no parameters begins to execute at the instant of the eighth falling debug clock edge. Multi-byte commands likely execute on multiple clock edges, each being the last falling edge of an instruction.

In any case, to debug a command, you simply send DEBUG_INSTR (0x54) summed with the length of the instruction, up to 3 bytes, then read a single byte reply. So to execute "NOP", send {0x55, 0x00}. Except for a jump, this will not affect the program counter.

Concerning memory access, there are no debugging commands to read or write memory. Instead, DEBUG_INSTR (0x54) is used to do the same. For example, to fetch from Data memory, first debug {0x90, AH, AL} to move the address into the data pointer. Then debug {0xE0, 0, 0} to MOVX from the data pointer into A. The 0's aren't part of the instruction, but they are necessary to give the device time to fetch the target of the pointer.

The is the code that fetches a byte from Data memory,

Concerning the writing of Flash, it is necessary to load a RAM buffer, then to copy that buffer into Flash by use of a short assembly script. Flash may only be erased in 2kB pages, and it may only be written as 32-bit words. The code that performs this is found on page 11 of SWRA124, and you'll find it in Data memory if you look hard enough after a programmer that doesn't cover its tracks.

You will find this code in the GoodFET source.

You will find the same code in RAM after programming.

Concerning the protection of Code memory, there is a lock bit in a hidden page of Flash memory. By setting the lowest configuration bit (by WR_CONFIG), the lowest 2kB of flash memory will be mapped to a special information region. Clearing the least significant bit of the first byte will lock the chip, causing it to refuse debugging after a full-power reset. Access to debugging instructions can only be regained after executing a CHIP_ERASE, which erases all of Flash memory.

At Black Hat USA in August of 2009, I presented a paper entitled Extracting Keys from Second Generation Zigbee Chips. The vulnerability, demonstrated in the image below, is that Data memory is not cleared along with Flash memory during a CHIP_ERASE. By booting a wireless sensor, then erasing it, then dumping RAM, the attacker can find any keys which are stored within the unit. This works even for constant keys, as 8051 compilers will copy them into RAM in order to make C pointers consistent.

In implementing a debugger, it's also necessary to watch out for a minor bug. Upon connecting, be sure to DEBUG_INSTR a NOP so as to have the lock bit checked. Failure to do so might cause the lock bit to be misrepresented when checking the device's status.

In conclusion, the protocol is blessedly simple and the 16 pages of documentation are quite complete when supplemented with the CC2430 datasheet. I hope that these notes might allow you to implement the protocol with less of a headache than I have.

GoodFET30 Boards by Mail

2009-10-03T18:54:00.007-04:00

Howdy y'all,

As anyone who has taken up my offer of a free GoodFET board can tell you, I've been terribly slow at shipping the things. Not only did I only send them while I was in stock, but I also had to have ample quantities of stamps and envelopes. Further, the envelopes were often lost in the mail do to my miscalculating postage (42¢≠44¢) or failing to properly pad each board. Add my travel schedule to the mix, and it was not uncommon for a neighbor to wait more than a month for his board to arrive.

To remedy this situation, I've arranged for blank boards to be shipped from Tennessee. Presently, the new GoodFET30 boards are in stock, and I'll order more panels as soon as these run out. To order one, just send a few bucks by Paypal to <sixtysixav at hotmail.com> along with a mailing address and a note that you'd like a GoodFET30. If you're broke or religiously opposed to Paypal, just send a neighborly request to my address below and I'll see that a free board goes your way.

Assembled units are coming, but don't expect them to be available before the new year.

N.B., do not forget to include your mailing address when ordering.

Thank you kindly,
--Travis Goodspeed
<travis at radiantmachines.com>

GoodFET Firmware Distribution

2009-09-13T11:11:00.005-04:00

by Travis Goodspeed <travis at radiantmachines.com>

Until recently, the GoodFET firmware was available only by source code through subversion. While I still expect all GoodFET users to be familiar with C, Unix, Subversion, and other such things, it is a bit much to ask each user to build the MSP430 cross compiler just to use the device. To that end, I'm implementing an automated testing server and firmware distribution system. The latest firmware images are now available by HTTP, free for any client to download and test. This article describes an early incarnation of this system.

To test each target, I've begun to fill a server in Philadelphia with GoodFET boards. Ideally, I'd like one of each GoodFET model matched to one of each target, but that collection has not yet been completed. In this screenshot below, the Chipcon and SPI Flash targets are being tested.

If the output contains anything different, the diff will show this and require manual intervention before an update may be published. These differences might be caused by a failed test, or they might be caused by a minor change, such as the amount of reported RAM consumption in the following screenshot.

To distribute these files, the Makefile in /packaging/ checks out a fresh copy of the code from subversion, builds and installs it to all attached boards, runs every available test case, and compares the results. If--any only if--all test cases match, the resulting intel hex files will be uploaded to http://goodfet.sourceforge.net/dist/. Clients may fetch these to update the targets, and I've added the "goodfet.bsl" client--a fork of tos-bsl-- to facilitate this upgrades.

Loadable modules will come next, along with some substantial changes to the GoodFET packet format that will allow for much larger blocks. I also hope to soon revamp MSP430 JTAG support, with support for quickly flashing 1xx and 5xx devices, as well as support for MSP430X (1xx and 4xx) devices.

As a final note, be sure to update your clients as well as your firmware. The packet format changes and other alterations might break compatibility of the new firmware with the old clients.

State of the GoodFET

2009-09-04T16:20:00.003-04:00

by Travis Goodspeed <travis at radiantmachines.com>

I shipped the last of the American GoodFET20 requests today. Please contact me if yours hasn't arrived. Orders to Europe will be sent next week, while I'm in Paris, Besançon, and Stockholm.

I'm now using the MSP430F2618 for GoodFET development, as it will run at 16MHz without a crystal. There are some bit errors on a few of these boards, owing to the accidental erasure of Info Flash by the bootloader. Until rebroadcasts are implemented, continue to construct your boards with the 1612 or 1611. The upcoming GoodFET30 will migrate the project entirely to the 2xx series, breaking compatibility with TI's firmware.

The Python clients are presently being refactored at the same time as the command structure is combined. Please contact me if you are interested in building a client for C# or Cocoa that will be easier to distribute.

Thanks to a generous EVK donation, MSP430X2 support is underway, which will allow such chips as the MSP430F5438 and the CC430 Zigbee SoC devices to be programmed. I've got the basics working, and full support for writing Flash memory ought to be ready rather soon.

I'm considering a plugin architecture that loads new modules into RAM, a GoodFET iPhone attachment, and all sorts of other crazy things. Comment with any feature requests below.

The GoodFET's MSP430 Stack Depth

2009-08-20T07:31:00.018-04:00

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

2009-08-19T05:08:00.003-04:00

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

2009-08-06T18:56:00.007-04:00

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

2009-07-08T09:12:00.004-04:00

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

2009-06-19T21:11:00.017-04:00

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

2009-06-13T16:10:00.000-04:00

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

2009-06-05T09:36:00.022-04:00

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.

GoodFET11 Released

2009-05-29T06:11:00.004-04:00

The GoodFET11 boards have arrived for HardHack in Berlin, where they were assembled earlier today. It was quite neighborly to see that intelligent people with steady hands, but no prior practice, had little trouble assembling the GoodFET's surface mount components.

GoodFET firmware ought to be functional in the next week or two, with I2C and the Chipcon debugging protocol as the first targets. Please contact me if you are interested in writing a client application in Python or another unix scripting language.

--Travis Goodspeed
<travis at radiantmachines.com>

Black Hat '09, Defcon 17

2009-05-22T12:21:00.004-04:00

Howdy y'all,

I'll be taking a trip to Vegas this summer for Black Hat and Defcon. Abstracts below are as submitted to the conferences, and there will be a tool released, of the extra-neighborly sort, at Black Hat. I also expect to do some hands-on stuff at Defcon's hardware hacking village.

For Defcon,
Locally Exploiting Wireless Sensors
Wireless sensors are often built with a microcontroller and a radio chip, connected only by a SPI bus. The radio, not the MCU, is responsible for symmetrical cryptography of each packet. When the key is loaded, it is sent as cleartext over the SPI bus, and an attacker with local access can steal the key using a few syringe probes and readily available hardware. This attack and other local attacks against wireless sensor networks will be presented in detail, including a live demo of an AES128 key being extracted from an operational network. Following the conclusion of the lecture, audience members will be brought onstage to perform the attack themselves on various pieces of example hardware.

For Black Hat,
A 16 bit Rootkit and Second Generation Zigbee Chips
This lecture in two parts presents first a self-replicating rootkit for wireless sensors, then continues with recent research into the security of second generation Zigbee radio chips such as the CC2430/2431 and the EM250.

--Travis Goodspeed
<travis at radiantmachines.com>

MSP430 Challenge of May 2009

2009-05-19T10:51:00.004-04:00

Howdy neighbors,

The following image is a piece of disassembled code that was compiled for the MSP430F1611. The code is found in many programs, but in this one it is accidentally vestigial as a result of a compiler bug. Please comment as to (1) which compiler generated the code, (2) what the code was intended to do, and (3) why the code is vestigial in the example, but might not be in another program. Translations to C or psuedocode and commented write-ups are also nice. The MSP430F1xx Family Guide might be handy if you're unfamiliar with the architecture.

I'll send a GoodFET board to the most insightful commentator, but as I send those boards out to anyone who asks, you're really only commenting for the neighborliness of it all. If I get enough replies, I'll post one of these each month.

Also, I saw a lot of good work on last month's Masked ROM Challenge while I was a Cleveland, but next to nothing has been sent my way. If you made significant progress, such as semi-automated extraction of the bits, please email me.

--Travis Goodspeed
<travis at radiantmachines.com>

HardHack and PH Neutral, Berlin

2009-05-19T00:08:00.006-04:00

On April Fool's day, I jumped into my car and left Knoxville to wander the world in search of neighborliness. Now I find myself in Berlin, finishing up some projects and living on döner.

At the end of this month, I'll be giving a workshop at HardHack on Friday 29 May on the GoodFET project. No slideshow, no projector, just a good old fashioned, informal sermon on the design as we build a few USB JTAG adapters then program them. Sign-ups for the workshop are here.

The GoodFET is self-programmable by USB, so upgrading firmware requires no additional hardware. As this is surface-mount, you'll need to have a steady hand and good eyesight. I've ordered parts and boards for the GoodFET11, with the GoodFET10 as a backup if the boards don't arrive in time.

On Saturday 30 May at 15h00, I'll be presenting at PH Neutral. Everything about the talk is a surprise, except that it involves embedded systems.

--Travis Goodspeed
<travis at radiantmachines.com>

Microchip Zena Reversed

2009-05-15T08:22:00.005-04:00

Howdy y'all,

Neighbor Joshua Wright has reverse engineered the Microchip Zena Zigbee sniffer's USB protocol, allowing packets to be dumped and channels to be hopped from Linux. Kismet support is the next step.

The EZ430RF2500 uses similar tricks in Windows with its HID driver, making Linux support quite difficult. If you have a Windows machine and are interested in doing the same to the RF2500 kit, please send an email my way, with a carbon copy to Josh.

--Travis
<travis at radiantmachines.com>

FET Firmware from MSP430.DLL

2009-05-13T11:07:00.000-04:00

by Travis Goodspeed <travis at radiantmachines.com>

The firmware of the MSP430 FET is distributed for purposes of upgrades within MSP430.dll. In this brief article, I'll describe its location and a method for extraction.

Firmware as Regions

All of these examples will use MSP430.dll with the following checksum. My previous FET articles have used a firmware image from the last revision of libMSP430.so, so addresses and code fragments will differ slightly.
f0685a0eca0545dfc542530afff8159f

A bit of quick searching reveals that the firmware of the MSP430 FET is contained within MSP430.dll as little-endian words at these addresses.
Bootloader code at offset of 0x1BFE8, region [0xF800,0xFFE0).
Application code at offset of 0x1EB38, region [0x2500,0xF7E0).
IVT at offset of 0x1BDBC, region [0xFFE0,0xFFFF].

That is, to recover the bootloader, copy 32 bytes (0x10000-0xFFE0=0x20) from the DLL at (0x1BDBC+0xFFE0=0x2BD9C) offset to the target MSP430 image at 0xFFE0.

Below are memory maps of my first attempt at extraction and an old EZ430 FET. It's clear that a lot of junk has been included by accident, which is why tabular entries, rather than regions should be used.

In addition to the large segments, there are also a few scattered bytes that form the lower IVT. (See Repurposing the TI EZ430U, Part 3 for an explanation of why there are two Interrupt Vector Tables.) Because the lower IVT is sparse, only those words which are not 0xFFFF are included. For example, the lower RESET vector--which, incidentally, is never read by the bootloader, in which the lower RESET is hard-coded--resides at 0xF7FE and points to 0x2502.

Searching MSP430.DLL for the interrupt vector, "02 25", yields a few results, one of which is "fe f7 d9 02 02 25". That's quite clearly an entry in a table of some sort. Searching around it yields a few more entries.

Firmware as a Table

By this point is should be clear that while it might be possible to extract the different fragments of the firmware manually, it would by much nicer to dump the whole damned thing as a table. This can be done.

Each entry is of the form {adr, len, data} where adr is the 16-bit address of the fragment within the firmware image, len is the length of the data in 16-bit words, and data is a collection of 16-bit words as little-endian. Following one entry is another, ending with an invalid address. (Anything less than 0x200 is I/O, anything less than 0x2500 is not flash.) Adding 4+(len<<1) to an entry's pointer gives the next entry.

Using this technique and finding an initial entry point of 0x21036, I generated a dump that produces the following image (left) as compared to the previous attempt (right).

The new attempt contains everything important, including a few bytes which were missed in the first attempt. It also lacks all of the vestigial bytes that got roped in by the previous method. Further, as each binary is defined by a single entry point, it shouldn't be terribly difficult to search for the entry point in order to generically dump any version of the library.

This cleanliness is confirmed by the callgraph below, which properly shows no function calls between the bootloader (right) and the application (left). (Branches are not graphed.)

The Code

The MSP430 Flash Emulation Tool's firmware is available for free download in MSP430.DLL, and anyone wishing to experiment with it need only download the library and extract the code.

A hastily written extraction utility can be found by subversion. A screenshot follows.
svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet/contrib/fetextract

UART Sniffing Notes

2009-05-09T15:53:00.002-04:00

by Travis Goodspeed <travis at radiantmachines.com>
concerning a collaboration with Reilly Grant.

The following are some brief notes on asynchronous serial traffic, how to decipher it, and how to identify a baud rate when a scope is unavailable.

RS232, TTL UART Waveforms

Of the two waveforms above, the first is RS232 and the second is TTL-level serial. They are on opposite sides of a MAX232 level-converter, and the images have been scaled to show the same point in the transmission, which is inverted and amplified by the MAX232. Here, the TTL line is +5V for a 1 and 0V for a 0. The RS232 line is -10V for a 0 and +10V for a 1.

In decoding serial traffic, it is important to recognize that the least significant bit is transmitted first, and that it is preceded by a start bit of 0. Following the most significant bit will be an optional parity bit and stop bit of 1. Thus, 0xEE would be
111111110011101111111111
where the bold portion is the data byte and the surrounding ones are the idle state. For practice, draw arbitrary bytes on paper, both as RS232 and as TTL-level. Further, note that the exact end of the byte is not immediately clear, and can only be found by matching timing from the starting 0 bit.

Here is a photograph of a few bytes.

Double Timing

When decoding serial traffic, it is crucially important to do so at the proper rate. It is for this reason that the standard baud rates have been decided upon. The traffic above was received at roughly, but not quite exactly, twice its baud rate. Note--by clicking the image for a better view--how common bytes of 0xFF and 0x00 are, as well as how rare a byte containing just a single 1 or 0 in isolation is.

Close Timing

Once sniffing traffic on the proper order of magnitude, it is often the case that a smart card reader will not be using exactly the same timing. As timing is synchronized not to a clock, but to a start bit, the less significant bits will be correct with errors being found in the more significant bits. For example, "0x3B 0x02" might be mistakenly read as "0x9B 0x82" if the transmission is being sniffed at a slower rate than the actual. This is because the stop bits are being misinterpreted as most-significant bits. (10,400 baud being sniffed at 9600 baud, in this case.)

To determine the next guess from an incorrect read without a scope, draw the misinterpreted byte and the correct byte of graph paper, comparing them. Shown below are 0x3B and 0x9B, click on the image for annotations.

Unfortunately, Unix was not designed with odd baud rates in mind, and the Linux solution isn't terribly elegant either. In short, you must configure the port to run at 38,400 baud and override that baud rate with a manually chosen clock divider. For details, see the setserial documentation, looking at the spd_cust option. Further complicated matters, spd_cust doesn't seem to work with the FTDI usb/serial chip. If you can get the chip to work at an odd rate, please post a comment with details.

Automation

Automatically identifying the baud rate isn't terribly hard for a microcontroller, which can watch traffic to measure the bit width and adjust its reception appropriately. At some point, I'll write firmware for the MSP430 to do just that.

Improving the MSP430 FET

2009-04-30T19:00:00.000-04:00

by Travis Goodspeed <travis at radiantmachines.com>

To celebrate 4/30 day, I am happy to announce my own variant of the MSP430 FET debugger. My variant is compatible with a patched version of the original firmware, but my goal is to eventually have open firmware as well.

For an overview of the internal functioning of the original FET, see my three part series on Repurposing the EZ430, or torrent my 25C3 lecture on the same topic.

For the purposes of this discussion, a FET is any Flash Emulation Tool containing an MSP430F1612, including the FET UIF and EZ430 debuggers. The parallel-port FET operates differently and is outside the bounds of this discussion.

To follow along with this discussion, be sure to print the FET schematics from the relevant TI application notes. The FET UIF's schematic can be found on page 64 of SLAU138K. Version 1.0 of the EZ430U can found on page 12 of SLAU176B, while Version 2.0 can be found on page 13 of SLAU227B. As I've likely made a few mistakes in the write-up, please kindly inform me of them.

FT232 for TUSB3410

All present FETs use the TUSB3410 usb to serial converter. Support for this chip is a pain in Linux, with kernel module requirements varying often. It's so bad that I keep a script in my private svn repository for fixing support as quickly as possible, and despite the recent appearance of open FET clients, using them on an obscure operating system is impossible without kernel support.

Internally, the '3410 is an 8051 microcontroller with a USB 2.0 Full Speed (12Mb/s) peripheral and a single UART. The traditional FET and most other devices use this chip with its default usb/serial firmware, but the second-generation EZ430 firmware uses various tricks to make a second, bit-banged, asynchronous serial port to the debugging target. On Windows, this leads to reliability issues, and on Linux, this leads to utter incompatibility. The '3410 also requires several external components, complicated the design and making hand soldering less feasible.

The FT232R from FTDI is a perfect replacement. It is available in an SSOP28 package for easy soldering, every operating system on Earth supports it, and its only external components are decoupling capacitors.

Bootstrap Loader

The MSP430 Bootstrap Loader (BSL) and I have had some good times together. While I still consider it to be a security risk for locked devices, it's damned handy for an unlocked board such as the FET. Likely for historical reasons, the BSL runs on P1.1 and P2.2, rather than the hardware UART pins. It also requires a special reset sequence, in which the RTS and DTS serial lines are connected to the RST and TCK pins.

Early revisions of the FET did not connect the BSL I/O pins, making the software bootloader that I describe in my articles on the EZ430 necessary. (The FET and first-generation EZ430 share a flash bootloader, while the second-generation EZ430 has a different, larger bootloader.) While later hardware revisions of the UIF connect the BSL pins, I've not seen the masked-ROM BSL used in practice. My design supports the BSL, preventing bricking and allowing for TI's firmware and open firmware to be exchanged at a whim.

To program the board by BSL, use tos-bsl with the --invert-reset and --invert-test switches.

MSP430F1612/1611

The MSP430F1612 was chosen for compatibility with the original FET. It has 55K of flash and 5K of RAM. Alternately, the MSP430F1611 with an identical footprint might be used for applications which require additional RAM but are willing to use less flash, at the expense of compatibility with the original chip. (MSP430 firmware grows upward from the bottom of flash memory, making it easy to port code from a device with less flash to a device with more, but difficult to port in the opposite direction.)

All custom firmware should be compiled to run in the intersection of memory of the two chips. In that way, most applications will run on either chip, with only those that need more stack depth requiring the 1611 and only those requiring more flash memory requiring the 1612.

Crystals

The MSP430 supports both high-speed and low-speed crystals, with the low-speed crystal's frequency being multiplied. Stable timing is not necessary for synchronous protocols such as JTAG or Spy-Bi-Wire, but only for asynchronous serial communication. While the EZ430 and FET firmwares both demand high-frequency crystals for absurdly high serial baud rates, I expect to reduce the data rate and source an external low-frequency crystal to reduce the parts count.

It is also possible to use bit-banged serial, or to call bit-banging serial routines from the bootloader (BSL) ROM. The BSL's code is particularly elegant because it resyncs the timing with the 0x80 SYN byte. This byte in 8/E/1 (8 bits, Event parity, 1 stop bit) appears as 8 marks surrounded by spaces, so rather than being read it is measured. The measured width is right shifted three times to get a bit's width, then once more for a half-bit. This measurement is used to bit-bang one transaction, then a new measurement is made for the next transaction. In this manner, even without a crystal, the BSL is able to perform fast, reliable serial communication in spite of clock drift. By calling this code--which is already resident in each chip--crystal-free operation is possible.

A high-frequency crystal is required to run unpatched variants of TI's firmware, but I've decided against including one in the design at this stage. Perhaps this will change in the future.

I/O Pins

The first four pins of P5 are used as JTAG and SBW I/O. Starting with P5.0 and continuing to P5.3, they are TMS, TDI, TDO, and TCK. I've chosen to omit the FET UIF's optical isolation in favor of the EZ430's simpler protection, which consists of 47K pull up resistors and 100R current-limiting resistors. Unlike the EZ430, which only support spy-bi-wire, my design has a full 14-pin JTAG connector.

Firmware, Old

The above image is the firmware of an EZ430U FET, generated by msp430static. 0x0000 is the bottom left corner, 0xFF00 the top left, and 0xFFFF the top right. Blue represents the target of an immediate pointer, black is empty flash memory, red is potentially executable code, and grey is information which is certainly not executable.

The image is composed of two parts. The upper red region is a bootloader which is used to reflash the chip, while the lower region does the actual work. As compilers ship with firmware upgrades, it is not necessary to distribute any copyrighted code. A replacement bootloader could accept a firmware upgrade, then patch it, while retaining software compatibility. More information on the bootloader can be found in Part 3 of my series on repurposing the TI EZ430U.

Firmware, New

Ideally, replacement firmware will be written for various applications, beyond MSP430 debugging. The same hardware could program competing microcontrollers, serial eeproms, FPGAs, and all sort of other things in the same way that the Hackaday Bus Pirate does.

So far as replacement firmware for debugging MSP430 chips goes, documentation is slim. Enough of the JTAG protocol has been documented to implement programming, but the setting of hardware breakpoints and other advanced features are not described by any public documentation. Custom firmware is not yet functional, but that ought to change in the near future.

Second Serial

The red board variants of the EZ430, those shipping with the RF kits, use drastically different firmware to facilitate a second serial port that connects to the target board. This breaks Linux compatibility, requiring firmware of both the MSP430 and the CAT24 EEPROM of the board to be downgraded.

To support low voltage serial communications, I brought out the second UART of the board's MSP430 to test points. This might also be used for timing attacks or similar things. Series and pull-up resistors would be nice on these lines, but they were omitted in the first design.

Availability

I've ordered a panel of the first revision, GOODFET10, and I'll send a board to anyone who is willing to assemble the device and help construct its firmware. Schematics, gerbers, and construction details have been posted to http://goodfet.sourceforge.net/, and "hello world" firmware has already been committed to the subversion repository.

Notacon Masked ROM Challenge

2009-04-17T14:21:00.003-04:00

Here at Notacon 6 in Cleveland, I'm having a competition involving the decoding of the MSP430F22x4's masked BSL ROM. The ROM, pictured below, begins with "0c06; 0c1e; 3fff; 40b2; a540; 012c; 90b2; ffde;" and ends with (in reverse order) "62b1; 0401; 0102; 0000; 0000; 0000; 4040; 27f2; ffff; ffff; ffff; ffff;".

Begin by downloading the high resolution version of the image, then marking it like so.

The first person to bring me a method for converting addresses to physical locations and back will win a Hack-A-Day Bus Pirate kit. A second kit will be given to the first person to bring me a script for generating correct bits from a binary (or Intel Hex) dump of the ROM.

Hints will be given during my lecture, "Fun with the MSP430", Saturday at noon.

--Travis Goodspeed
<travis at radiantmachines.com>

An Open GDBProxy!

2009-03-27T16:04:00.004-04:00

Howdy everybody,

Rob Spanton and Tom Bennellick have recently released fetproxy, an open-source replacement for gdbproxy. They reverse engineered the protocol the week before I did, and their implementation--unlike mine--acts as a replacement for gdbproxy. They also managed to get approval from Texas Instruments, which is quite neighborly indeed.

I'll be closing up my msp430fet project, which was only intended as a stop-gap until Rob and Tom were able to make their release. The final state will be a standalone C client for programming; I won't be adding support for debugging.

--Travis

Breaking 802.15.4 AES128 by Syringe

2009-03-15T00:29:00.003-04:00

by Travis Goodspeed <travis at radiantmachines.com>

I'm working on a pair of hands-on Zigbee hacking workshops. The first, which I've submitted with Aurélien Francillon to ToorCamp involves the writing of advanced stack overflow attacks for the MSP430 and AVR microcontrollers. The second, which I've submitted to Defcon 17, involves a number of hands-on hardware attacks against Zigbee nodes. Both include the sniffing of AES128 keys from a CC2420 Zigbee radio, a procedure that I demonstrated informally at Source Boston and describe below.

The CC2420 is a popular Zigbee/802.15.4 radio, and it is found in many wireless sensor development kits. We'll be attacking its hardware-accelerated AES128 implementation, by taking advantage of the fact that keys must be loaded over the SPI bus.

In the photograph above, I've tapped one of three SPI pins of the CC2420 radio chip on a Telos B using a hypodermic syringe. SPI consists of four pins: SCL, MOSI, MISO, and !SS. SCL, the Serial Clock, is output from the master to synchronize communication with the slave. MOSI and MISO are data lins, Master Out Slave In and Master In Slave Out. !SS or Slave Select is an inverted line that indicates the selection of a particular slave chip. Here, we'll only be tapping SCLK and one of the data lines, as two syringes are much easier to hold that four. Ground is shared by USB, so it isn't critical that we tap it.

As seen on my portable scope below, the tapped pin is the SCL, the data clock. The clock stands out because it idles low, and because all pulses in a batch are of regular width. Unlike a system clock, the clock only cycles when data is being transported.

The remaining two pins, in the group of three, are data. As shown on the scope image below, SPI data lines idle high, and bits are measures on edges of the clock.

Now that the clock and data lines have been found, it is necessary to sniff the traffic using a bus adapter. Until SPI-sniffing firmware for the Hackaday Bus Pirate becomes available, I will continue to use the Total Phase Beagle I2C/SPI Protocol Analyzer. A screenshot of the Total Phase client follows.

All that remains to identify the key in use, or anything else sent over the bus, is to read the log. I will likely release scripts for doing so at Defcon.

NeighborCon

2009-03-04T13:31:00.002-05:00

Howdy y'all,

The NeighborCon announcement is up, for Knoxville's most neighborly hacker conference. There's also talk of a trip to Dollywood after the conference has concluded.

--Travis Goodspeed
<travis at radiantmachines.com>

New Business Card

2009-03-03T05:29:00.004-05:00

Howdy Neighbors,

I've just received a few prototypes of my new business card, which also happens to be a 1.8V/3.3V smart card emulator. (Most readers default to 5V, just to make life difficult.) The final revision will be compatible with all three voltages, and I expect to order boards in quantity by the end of next month.

--Travis Goodspeed
<travis at radiantmachines.com>

Postscript:
Just to be perfectly clear, these are not intended for TV piracy and they are not for sale.

SOURCE Boston and Notacon

2009-02-23T11:20:00.006-05:00

Howdy Y'all,

The next stops of my tour will be SOURCE Boston in March and Notacon in April. In between, I might swing by Carolinacon, though I won't be speaking.

My SOURCE Boston lecture, Wireless Sensors as an Asset and a Liability, is my first attempt at a business lecture, albeit one that repeatedly leans on technical depth for credibility. First, I will explain exactly why this technology is too valuable to ignore. Entire industries will be revolutionized by it, and any firm refusing to use the technology will find itself at a significant competitive disadvantage. That being done, I'll continue by demonstrating just how easy it is to subvert this technology, using a few items from my bag of tricks that haven't made it into other conferences.

My Notacon lecture, Building Things with the MSP430, is also a departure from my previous topics, in that I won't mention security. Instead, I'll provide some helpful tips on how to build belt buckles, toys, and other other neighborly things. Attend if you're new to electronic design or the MSP430 microcontroller, or if you're sick of security and want to be a belt buckle engineer.

As always, email me if you'd like to meet at either conference.

--Travis Goodspeed
<travis at radiantmachines.com>

Shmoocon and Black Hat, DC

2009-01-14T08:00:00.000-05:00

Howdy y'all,

I'll be presenting two new lectures in DC next month. The first, at Shmoocon, is on the construction of wireless sensors. Beginning with a product idea, Josh Gourneau and I will step you through the design of a modern sensor node's hardware and software. Then we walk you through the design of a brand new node: hardware design, fabrication, porting an operating system, writing an application, maintaining power efficiency, and proper use of the radio. Who knows, we might even make radio version of our neighborly Party Mode Belt Buckle?

At Shmoocon, be sure to catch Off the Shelf Security - Meeting Crime with an Open Source Mind, which immediately follows my talk in the same room.

My second lecture, at Black Hat DC, will describe the reverse engineering and exploitation of wireless sensors. You will learn how to take a wireless sensor apart, reverse engineer its firmware, sniff the various buses it contains, craft an embedded stack overflow, and some interesting techniques with radio jamming.

--Travis Goodspeed
<travis at radiantmachines.com>

Implementing the MSP430 FET Protocol

2009-01-03T17:11:00.010-05:00

by Travis Goodspeed <travis at radiantmachines.com>
continuing initial observations.

Following a comment posted to the prior article, I discovered that, as suggested, the PPP FCS-16 checksum is the one used for communicated with the FET. Searching MSP430.dll for the initial bytes of the checksumming table which is presented on Section C.2 of RFC1662, yields the following table,

The 16-bit entries from the table appear as little endian, so {0x1189, 0x2312} becomes {0x89, 0x11, 0x12, 0x23}. Running a quick test with the RFC's FCS-16 code yields a proper checksum, with which messages can be signed.

The result of this is an open source too, MSP430FET, for programming chips with the MSP430 FET tools. The present version can read and write memory, but it is limited to spy-bi-wire and is unable to erase memory. Expect those features, and a website, in a later revision.

svn co https://msp430fet.svn.sourceforge.net/svnroot/msp430fet/trunk msp430fet

Sniffing the MSP430 FET Protocol

2008-12-30T21:09:00.024-05:00

by Travis Goodspeed <travis at radiantmachines.com>
regarding his independent recreation of ~~anonymous,~~ ~~unpublished~~ by other neighborly fellows. update: see here for the original implementation.

As the MSP430's gdbproxy relies upon closed-source libraries, which are not available for platforms other that Windows and i386 Linux, it would be valuable to generate an open-source alternative. Further, these closed libraries do not allow the debugging of all MSP430's. As reverse engineering the protocol by code review would be prohibitively complicated, grabbing serial traffic is an effective alternative. The following method allows for the dumping of serial frames for later analysis.

It is also a worthy goal to reverse engineer the proprietary aspects of TI's JTAG standard, but that is not the subject of this article. Here I will only investigate the protocol between a workstation and the MSP430 JTAG tool.

The simplest means of doing so is by using LD_PRELOAD to proxy--and print--calls to the write() and read() methods. To do so, I authored serspy.

Serspy works by proxying each call to the read() and write() system calls. For example, to trap the write() command,

//trap the write command
static ssize_t (*_write)(int fd, const void *buf, size_t count)=0;
int write(int fd, const void *buf, size_t count){
  int num;
  
  //This grabs a pointer to the original function.
  if(!_write)
    _write=(ssize_t (*) (int fd, const void *buf, size_t count)) dlsym(RTLD_NEXT,"write");
  
  //Now really write.
  num=_write(fd,buf,count);
  
  //And log it.
  logdataw(fd,buf,count);
  return num;
}

The code above is a replacement for the write() function which uses dlsym() to request a pointer to the original write() function, to which it forwards the call before logging it. As msp430-gdbproxy doesn't link against libdl and it is a 32-bit application, LD_PRELOAD must be set to ``./serspy.so:/usr/lib32/libdl.so''. Further, serspy.so itself must be compiled with the -m32 switch on 64-bit workstations.

Consider an example transaction, such as

W  7e 01 01 16 07 7e
R  0c 00
R  01 02 00 00 01 00 50 9e 98 00 67 4b

Writes (W) from the workstation begin and end with 0x7e, which never appears within the request. An encoding method of some sort is used to remove them. Reads (R) from the FET device begin with a 16-bit, little endian length. Following this length are the bytes themselves.

Consider also the following Writes, all of which are fetches for memory.

x/h 0x0200
7e 0d 02 02 00 00 02 00 00 02 00 00 00 b0 17 7e
x/h 0xfc00
7e 0d 02 02 00 00 fc 00 00 02 00 00 00 c0 06 7e
x/h 0xfc02
7e 0d 02 02 00 02 fc 00 00 02 00 00 00 af 0d 7e

All addresses are found intact as little endian: "00 02" for 0x200, "00 fc" for 0xfc00, and "02 fc" for 0xfc02. That won't be true for bytes which contain illicit characters, as I'll demonstrate later. Also note that the final two bytes of each message vary drastically; these are most likely a checksum of some sort.

Regarding the checksum, there are two common possibilities. The first is a CRC16 checksum, while the latter is the XOR of all transmitted bytes. The MSP430's serial bootstrap loader uses the latter method, but it is easy to rule out here. As the examples above for fetching 0xfc00 and 0xfc02 differ by only one bit apart from the checksum, yet the checksums show no resemblance, this checksumming function must be more complicated. A solution to the checksumming problem will be presented in a later article.

Illicit characters are dealt with by escaping. Consider the following queries,

x/h 0xeeee
7e 0d 02 02 00 ee ee 00 00 02 00 00 00 5c ac 7e
x/h 0xee7e
7e 0d 02 02 00 7d 5e ee 00 00 02 00 00 00 c6 3c 7e
x/h 0xee7d
7e 0d 02 02 00 7d 5d ee 00 00 02 00 00 00 16 b6 7e
x/h 0xee7f
7e 0d 02 02 00 7f ee 00 00 02 00 00 00 79 bd 7e
x/h 0xee7c
7e 0d 02 02 00 7c ee 00 00 02 00 00 00 a9 37 7e

From this it can be seen that 0x7d is the escape character, and that 0x7d and 0x7e are the characters to be escaped. Each is escaped by following 0x7d with either 0x5e or 0x5d, taking the lesser nybble.

Performing a few more queries exposes the length field of the memory read, as queries for 2, 1, and 4 bytes yield

x/h 0xeeee
7e 0d 02 02 00 ee ee 00 00 02 00 00 00 5c ac 7e
x/b 0xeeee
7e 0d 02 02 00 ee ee 00 00 01 00 00 00 91 89 7e
x/w 0xeeee
7e 0d 02 02 00 ee ee 00 00 04 00 00 00 c6 e7 7e

The first byte after the frame-start is 0xd, which is also the first byte of the response. Taking this further, a command/response code can be discovered, which is the first byte of both the encapsulated request and the response. In the follwoing case, an examine query has the code 0x0d while the set query has a code of 0x0e.

set *0xffd0=0xdead
W  7e 0e 04 01 00 d0 ff 00 00 02 00 00 00 ad de 49 6e 7e
R  06 00
R  0e 00 00 00 9c 52
x/h 0xffd0
W  7e 0d 02 02 00 e0 ff 00 00 02 00 00 00 4d b6 7e
R  0c 00
R  0d 03 00 00 02 00 00 00 ff ff 03 b8

~~This series will be continued once the checksumming routine has been reimplemented, at which point a custom client may be written.~~

See this post for details on my implementation.

25C3 Workshop

2008-11-25T15:22:00.002-05:00

I'll be giving a workshop on Repurposing the TI EZ430U at the 25th Chaos Communications Congress, Berlin. It will be on Day 3 (2008-12-29 Mon) from 16h00 to 18h00.

There's no charge for the workshop beyond conference admission, but please attend the lecture and bring an EZ430 with you if at all possible.

Cheers,
--Travis
<travis at radiantmachines.com>

Radiant Machines

2008-11-19T17:41:00.002-05:00

I've started a site, http://radiantmachines.com/ to showcase my collaborations with Josh Gourneau. The first is a belt buckle.

--Travis
<travis at radiantmachines.com>

Speaking at 25C3

2008-11-14T17:19:00.009-05:00

At the 25th Chaos Communications Congress in Berlin this December, I'll be presenting some new research in the security of the MSP430's serial bootstrap loader (BSL) as well as a nice little lecture/workshop combo on reverse-engineering the TI EZ430 development tool.

I intend to travel through France and England, returning in late January for S4, Miami. Please email me if you'd like to meet.

Cracking the MSP430 BSL
Day 1 (2008-12-27), 20h30 (8:30 pm) in Saal 3.

The Texas Instruments MSP430 low-power microcontroller is used in many medical, industrial, and consumer devices. When its JTAG fuse is blown, the device's firmware is kept private only a serial bootstrap loader (BSL), certain revisions of which are vulnerable to a side-channel timing analysis attack. This talk continues that from Black Hat USA by describing the speaker's adventures in creating a hardware device for exploiting this vulnerability.

While the previous part focused on the discovery of the timing vulnerability and its origin, this lecture will focus on the exploitation. Topics include a brief review of the vulnerability itself, PCB design and fabrication, the malicious stretching of timing in a bit-banged serial port, observation of timing differences on the order of a microsecond, and the hell of debugging such a device.

Repurposing the TI EZ430U
Lecture: Day 3 (2008-12-29), 12h45 (pm) in Saal 3
Workshop: Not yet scheduled.

USB devices are sometimes composed of little more than a microcontroller and a USB device controller. This lecture describes how to reprogram one such device, greatly expanding its potential.

At only twenty dollars, the Texas Instruments EZ430U is a bargain of an in-circuit debugger for the MSP430 microcontroller. The board itself is composed of little more than an MSP430 and a USB to Serial controller. The board's JTAG fuse is unblown, and full schematics are included in public documentation. This lecture will discuss the use of the EZ430U, not as a debugging tool, but as a development platform in and of itself. Topics will include the writing of replacement firmware, analysis of the default firmware, reprogramming the USB to Serial controller, and potential target applications.

--
Travis Goodspeed
<travis at radiantmachines.com>

MicaZ Code Injection

2008-11-04T12:05:00.007-05:00

by Travis Goodspeed <travis at utk.edu>

Aurélien Francillon and Claude Castelluccia of France's INRIA recently demonstrated at CCS2008 a code-injection attack that reflashes Mica wireless sensors. This is more difficult than my TelosB attack because the MicaZ uses a Harvard-architecture CPU, one that is incapable of directly executing RAM. The authors use meta-gadgets, collections of executable code found already within the device, to copy the payload into executable flash memory. It's about damned time that someone authored a practical implementation for those things, and the paper is well worth reading.

If you quickly glance over the paper, you might miss the best part, which is not that the authors used meta-gadgets but exactly how they found the meta-gadgets. See the seventh page of their paper, the section entitled `Automating the meta-gadget implementation', for details of a modified CPU simulator that constructs meta-gadgets automatically from a given firmware image.

Speaking at S4 in Miami

2008-11-02T03:17:00.001-05:00

On Thursday, January 22nd, I'll be presenting at Digital Bond’s SCADA Security Scientific Symposium (S4) a paper authored with Brad Singletary and Darren Highfill of Enernex on the topic of Low-Level Design Vulnerabilities in Wireless Control Systems Hardware. As 802.15.4 sensors and similar hardware are subject to theft by an attacker, we demonstrate several practical attacks that we've been cooking up for the past year. We include plenty of schematic diagrams, logic analyzer recordings, oscilloscope photographs, and code fragments to keep things interesting. Attendance is strictly limited to fifty-five, and registration is expected to sell-out this year.

Please email me if you'd like to meet up while I'm in town. As always, I'll bring some of my equipment for a show and tell.

Cheers,
--Travis Goodspeed
<travis at utk.edu>

The MSP430F2254 is a 2274.

2008-10-28T00:03:00.007-04:00

A few weeks back, I ran out of MSP430F2274 chips and used the pin-compatible 2254 for a few of my BSLCracker boards. After connecting a FET to program the first of them, I found that GDB mistook it for a 2274. The chip ID of a 2254, beginning at 0xFF0 and continuing as big-endian quartets, is "F2274". The photograph above, taken by Brooke Hill, confirms that the die of the MSP430F2254 is that of a 2274.

What method is used by TI to downgrade a '74 to a '54, and is it reversible? Please email me if you can shed any light on the matter.

Cheers,
--Travis Goodspeed
<travis at utk.edu>

Speaking at PumpCon 2008 in Philly

2008-09-29T18:51:00.003-04:00

Howdy Y'all,

I'll be driving to Philadelphia on Friday, October 24th to speak at this year's PumpCon. This lecture continues that of Black Hat USA, focusing on the exploitation--rather than the origin--of timing vulnerabilities that I've found in certain revisions of the MSP430's serial bootstrap loader.

--Travis Goodspeed
<travis at utk.edu>

Repurposing the TI EZ430U, Part 3

2008-09-15T07:26:00.000-04:00

by Travis Goodspeed <travis at utk.edu>
of Southern Appalachia

The first installment of this series described a method of accessing the EZ430's MSP430 firmware by way of JTAG, while the second installment took a detour to discuss the TUSB3410 usb controller of the board. This third installment is concerned with the analysis of the green EZ430U firmware; that is to say, it is concerned with the firmware of the six-pin EZ430f2013 kit, which might differ from the four-pin EZ430f2013 kit and drastically differs from the red EZ430rf2500 kit.

Section 1, wherein we make general, even visual observations regarding the organization of firmware, as well as the locations of important objects.

Observe the following memory map, which was generated by the .memmap.gd.xview macro of msp430static.

In an m4s memory map, the X axis represent the less-significant byte while the Y axis represents the more significant byte. 0xFF00 would be the top left, and 0xFFFF would be the top right. As the interrupt vector table (IVT) of the MSP430f1612 ranges from 0xFFE0 to 0xFFFF, it appears as a green band in the upper right of the image. Entries within it all point to the upper red band, with addresses varying from 0xfb78 to 0xfdb0, in regular increments of 4. The only exception to this rule is the RESET vector at 0xfffe, which points to 0xfdaa.

Why such an arrangement? Each of these regularly-spaced interrupt handlers is a branch to a lower interrupt handler. The blue line that you see at the top of the black expanse is a second IVT, entries of which are called from above. 0xffe0, the DMA vector, point to a branch to &0xf7e0, which is to say that address which is contained within 0xf7e0. Similarly, 0xffe2 points to a branch to 0xf7e2. In fact, every interrupt except for RESET points to nothing but a branch to its equivalent in the table that begins 0xf7e0.

It should be clear, then, that not one but two programs reside in this image. The first-stage firmware, which rests at the top of memory, performs its own initialization when the chip is reset, but differs all interrupt handling to the lower firmware, which grows from the beginning of flash to 0xf7e0. It shouldn't be hard to instruct a compiler to build a second-stage firmware compatible with the first-stage, but it would be imprudent to spring into such a task without at least a casual analysis of the first stage.

Section 2, wherein we examine the first-stage firmware in depth.

The first-stage firmware is a bootloader which resides from 0xf800 to 0xffff in flash memory of an MSP430F1612. A quick search with MSP430static--which I'll refer to as 'm4s' for the sake of brevity--reveals that 30 functions have been found in this area. Fifteen of these, those in the range [0xfb78,0xfbb0], are merely branches to interrupt handlers in lower memory. The interrupt handler is a function which I'll call init() that resides at 0xfdaa, calling a config() function at 0xf828 to set registers to their proper values. The only call made by config() is to delay() at 0xf812 that uses nested loops to implement a timing delay.

I/O is performed by putbyte() and getbyte() functions at 0xfbc6 and 0xfbd2 respectively. These use USART0 in UART mode. This port is configured, as are many other peripherals, in the previously mentioned config() function.

As the purpose of this series of articles is to describe the process for writing a complete replacement firmware, I should mention that such information is to be found within this stage. Port 3 is especially important, as it is tied into both UARTS and I2C. As you'll recall from the early articles of this series, the TUSB3410 refuses to load with ports in the default configuration. By matching the configuration of the original firmware, we ought to be able to get something going.

To that end, Port 3 is configured as follows within the config() function.


f88e: bis.b #48, &P3SEL
f894: bis.b #16, &P3OUT
f89a: bis.b #16, &P3DIR

Clocks and such must also be reconfigured, but I come bearing good news! There's an easier way, in that by relocating the IVT or reconfiguring your compiler, you can generate a custom second stage firmware without rewriting the first stage.

Section 3, wherein we examine the second-stage firmware in brief.

By comparison to the simple, neighborly firmware of the preceding section, the second stage firmware is gigantic and multi-tasking, with a rats-nest of function calls to a few key functions. Although it serves little immediate value, I'll cover second stage as an example of a few analysis techniques.

Which function calls are most popular, and what do they do? The .calls.top10 macro results in the following:

163     4c3e    4c3e
151     4f54    4f54
142     4b6a    4b6a
29      4eca    4eca
28      6100    6100
27      2ba2    2ba2
24      8d0e    8d0e
24      a784    a784
20      5f4c    5f4c
17      756e    756e

Note the sharp dropoff after the third. In a multi-tasking application, such as a TinyOS wireless sensor node, it would be logical to assume these to be mutex locks. In a JTAG adapter, however, it is much more likely that these serve an I/O purpose. Sure enough, all three are I/O related with 0x4f54 performing I/O through function calls and the other two doing it directly.

As I am not concerned with reverse-engineering the TI's proprietary debugging protocol, but rather only with making software capable of running on the EZ430 programmer, I'll delve no further into the second-stage firmware. Remember only the following: (1) That the IVT of the second-stage code resides at 0xf7e0, (2) that all else remains unchanged.

The question then becomes one of relocating the IVT, which may be accomplished either by altering linker scripts or by rewriting the firmware image before flashing it to the device. We shall begin with the prior method.

Section 4, wherein we rewrite the linker scripts of two popular compilers so as to generate our own second-stage code for this fine platform.

Moving the IVT is accomplished in GCC by forking msp430x1612.x to ez430u.x, then changing line 8 to the following:

vectors (rw) : ORIGIN = 0xf7e0, LENGTH = 0x20

Call GCC with the -T switch followed by your forked linker script, and the output will direct to the proper address. Use msp430-objdump to verify the address in your output. For further details, consult my article on Retargetting the MSPGCC Linker. In the case of the IAR compiler, the IVT range is defined near the end of lnk430F1612.xcl.

Please note that, for no reason that I can fathom, the RESET vector of the second-stage IVT has been hard-coded to be 0x2502 in some places. You must set the .text section to begin at 0x2502, or the reset will land in the middle of a two-word instruction.

Section 5, wherein your author makes a shameless plug his upcoming appearance at the tenth annual Toorcon San Diego but provides little else of substance.

A fourth installment of this series will wrap up the replacement MSP430 code, concluding with a complete and commented `hello world' example for GCC.

Errata from Black Hat USA 2008

2008-09-08T23:46:00.026-04:00

There exist two errata, one trivial and one substantial, in my Black Hat presentation.

First, Vcc of the 2013 chip in the schematic diagram should be connected to Vcc of the JTAG/SBW connector, not Vext as is shown in the schematic. I had to score and solder those in my prototype, but I forgot to update the slides. (The new unit uses the MSP430F2274, regardless.)

Second, and much more substantially, memory is erased by default on reception of an incorrect password unless BSLKEY is set to 0x0000 on BSL version 2.0+. See page 11 of SLAA089D for details. You will find the code responsible at 0xD66 within the password comparison routine of the MSP430FG4618 Rev. G BSL, version 2.12, wherein BSLKEY is located at 0xFFBE. This makes these devices invulnerable by default, unless protection is explicitly disabled by the programmer.

The MSP430F1101A and other chips using BSL versions beneath 1.60 are vulnerable by default.

The next revision of my board will incorporate power glitching attacks, which might potentially prevent the 4618 from erasing its memory on a bad password or allow entry into a disabled BSL.

--Travis Goodspeed

Retargetting the MSPGCC Linker

2008-09-06T18:27:00.035-04:00

by Travis Goodspeed <travis at utk.edu>

In this article, I describe the use and modification of GCC linker scripts. In particular, I emphasize their use within MSPGCC to add support for an additional target chip, the MSP430F2274. This technique allows the generation of executables for chips which are presently unsupported by MSPGCC, as well as the creation of executables that are intended to work with a custom bootloader.

Until recently, I had been using IAR's compiler for development of the BSL Password Cracker, which was the subject of my Black Hat USA talk. IAR makes a great compiler, but the proprietary UBROF object format prevented me from exporting debugging symbols to GDB. My requests to the company for a copy of the specification have thus-far yielded nothing.

In switching to MSPGCC, I found myself unable to compile executables for the MSP430F2274 around which I had already based the second major revision of my board. In this article, I will describe a simple method for extending the MSPGCC linker to support a new chip by modifying the definition of one that's presently supported. The same technique is also handy for building an image to be compatible with a custom bootloader, as I'll describe in the next installment of my series on reprogramming the TI EZ430U with custom firmware.

Under the hood, a compiler is built of many separate applications. The first stage is a preprocessor which evaluates macros such as the #include directive. After that, the compiler stage translates preprocessed C into assembly language. A third stage, the assembler, converts assembly language into object files, which are complete except for labels that have been left empty for later insertion. A fourth stage, the linker, combines one or more object files into an executable firmware image. In the case of the MSP430, this image is a complete kernel, which does not rely upon a surrounding kernel or dynamic libraries.

As objects enter the linker, they are not quite complete machine code. This is because, prior to linking, it is impossible to know the entry address of any function. They are quite likely to be re-arranged, with unused functions stripped out entirely.

Also unknown prior to linking is the location of various system boundaries, such as the range of memory which is mapped to Flash ROM, that range which is mapped to RAM, and various ranges of lesser importance. Embedded compilers use linking scripts to specify these regions.

IAR's linker, xlink, scripts in the config/ subdirectory of each target, /opt/iar430/config on my machine but more likely C:/Program Files/IAR Systems/Embedded Workbench 5.0/430/config in Windows. Observe the code memory region of lnk430F2274.xcl as an example:

// -------------------
// Code
// -------------------

-Z(CODE)CSTART,ISR_CODE=8000-FFDD
-P(CODE)CODE=8000-FFDD

The regions themselves are helpfully described in English comments at the top of the file, giving those too lazy to read the datasheets a helping hand. It's also rather nice that these are standard command-line arguments to xlink.

GCC's linker, ld, uses a different format. Regions are described not as beginning and ending absolute addresses, but rather as an absolute beginning address and a length. The corresponding line in my 2274 script is
text (rx) : ORIGIN = 0x8000, LENGTH = 0x7fe0

The first step in retargetting the linker is to adjust the rest of the lines in the MEMORY stanza to values that work. That is nearly all the work that you must do, but converting memory regions is not quite all that you'll have to contend with. In using an MSP430F1612 script as a starting point, I initially overlooked the following line.
PROVIDE (__stack = 0x2500) ;

That line initializes the stack pointer (r1) to be 0x2500. Nothing is mapped to this address, and the entire region reads each byte as 0x5321. As GCC places globals at the bottom of memory, setting this value to the top of memory, which is to say 0x5fe, results in a functional stack.

You can find my first attempt at an MSP430F2274 linker script here. It works for me, but it comes with the usual warranty, by which I mean none. Place it in the working directory and add -T foo.x to your linking gcc line.

In the near future, I intend to add a linker-script importer for msp430static to give context to different regions of memory. Support will exist for GCC and IAR formats, and a standalone mode will allow translation between formats.

Speaking at Toorcon 10 in San Diego

2008-09-02T12:41:00.005-04:00

I'll be giving a 75-minute Deep Knowledge Seminar at Toorcon X in San Diego on Friday, September 26th regarding my efforts to repurpose the TI EZ430U in-circuit debugger. This seminar will cover both of the presently published articles, as well as details on writing custom replacement firmware that will be published as a third (and perhaps fourth) installment. More generally, it will provide a thorough introduction to the reverse engineering of microcontroller-based USB peripheral boards.

Note that the seminars are not included with general conference admission. Seminar registration is $750 until September 12th, $950 at the door.

Please email me if you'd like to meet up.

--Travis Goodspeed
<travis at utk.edu>

Temporarily Paralyzing the MSP430 Memory Bus

2008-09-01T19:08:00.009-04:00

I've been playing lately with the use of light to induce temporary faults within a decapped MSP430F1101A. The chip, pictured above, was decapped by Chris of Flylogic Engineering. Lacking a convenient source of UV with which to begin erasing flash memory, I tried the flash from my digital camera. What luck!

Although it appears that flash memory has been reset, that is not in fact the case. The memory bus is paralyzed, with all reads returning 0xFFFF. This includes Flash, RAM, and ROM regions. After a while, this effect dissipates and memory returns to normal.

I'll soon begin to experiment with different wavelengths, durations, and polarizations of light. Please email me if you've any advice to offer.

Cheers,
--Travis

Post-Vegas

2008-08-16T17:44:00.003-04:00

Black Hat and Defcon were both a blast. My Black Hat slides and paper are available. See here for the book of which I spoke at Defcon.

Chris Tarnovsky of Flylogic Engineering let me photograph a run-through of the workshop that he later gave at Defcon. I've been locked out of my Flickr account, but you'll find most of those photos tagged with flylogic. I'll post the others if and when I recall my password.

It'll take me a while to send all the emails that I've promised. Please email me first if you have the time.

Cheers,
--Travis
<travis at utk.edu>

Vegas or Bust! Three talks in three days.

2008-08-04T23:05:00.004-04:00

Howdy y'all,

I'm leaving Knoxville for Las Vegas in eight hours. I'll be speaking Thursday, Friday, and Saturday. Three talks, on three different topics.

Thursday/13h30 at Palace 1 in the Hardware track of Black Hat, I'll be speaking at Black Hat USA regarding a timing vulnerability of the MSP430FG4618's serial bootstrap loader. This is just after the lunch break. Come early to get a good seat, then keep it for talks by Karsten Nohl and Chris Tarnovsky.

Friday/16h00, I'll be speaking at Defcon 16 in the Breakout room regarding not my own work, but the historic work of Paul Courbis and Sébastien Lalande. In 1990, they published «Voyage au centre de la HP28C/S» detailing the initial reverse engineering of the Hewlett Packard 28 graphing calculator. For the past year, I've been translating it as a hobby.

Saturday/18h00, I'll be giving a Defcon Skytalk on the topic of reverse-engineering an 802.15.4/Zigbee wireless sensor node using msp430static. This is a revision of my talk from Last Hope, with new content to reflect my Black Hat talk. I was added to the line-up at the last minute, so you won't find this in the conference booklet or the poster.

Please email me at the address below if you'd like to meet up.

Cheers,
--Travis Goodspeed
<travis at utk.edu>

Last Hope recap, slides

2008-07-28T15:21:00.002-04:00

by Travis Goodspeed <travis at utk.edu>
at the Extreme Measurement Communications Center
of the Oak Ridge National Laboratory

Despite sleep deprivation and the longest drive of my life, I had a blast at the Last HOPE conference this past weekend.

You'll find the slides for my scheduled (Friday) talk at lasthope_goodspeed.pdf. Saturday's talk was a rerun from TIDC 08; thanks to Marco and Kevin Figueroa for getting me a projector on such short notice. Sunday's workshop was unrehearsed, and I apologize for not taking screenshots.

You'll find me next week at Black Hat 2008 and Defcon 16 in Vegas. In addition to my scheduled talks, I expect to give at least one unscheduled lecture or workshop during Defcon. Email me for details.

--Travis

Repurposing the TI EZ430U, Part 2

2008-07-04T12:09:00.003-04:00

by Travis Goodspeed <travis at utk.edu>
at the Extreme Measurement Communications Center
of the Oak Ridge National Laboratory

Section 1, wherein topics of discussion are enumerated and datasheets cited.

The first installment of this series described a method of accessing the EZ430's MSP430 firmware by way of JTAG. That's dandy, but the MSP430 isn't the only microprocessor on the board! This installment will focus on the firmware and reprogramming of the TUSB3410 USB to serial chip, which contains an 8052 microprocessor core.

Section 11 of SLLS519 describes the boot sequence of the TUSB3410. In brief, an I2C EEPROM is used if such a chip is present and it contains an image with the proper signatures. Firmware may also be loaded over USB, in which case the EEPROM is either absent or provides only such minutia as the device ID.

The EEPROM on the Revision 2.0 boards--those with six pins for the target device--is the CAT24C32 by Catalyst Semiconductor. Revision 1.1 used the smaller CAT24C16 chip, presumably because that revision had no need for such complicated software. (See Part 1 for details.)

Section 2, wherein firmware is forcefully extracted by use of hypodermic syringe and our heroes contemplate an intriguing fragment of a schematic diagram.

The 24C32 chip, like all I2C devices, uses two lines for communication. These are SDA and SCL. Addressing lines, allowing for multiple units of the same chip to reside on a board, are unused and tied to ground. Thus, the chip looks something like the following schematic.

To read the chip, it is necessary to have an I2C host adapter, such as the Total Phase Aardvark. So as to avoid soldering headers to the chip, I attached two of my syringe logic probes to the Aardvark's SDA and SCL lines. Power was shared through USB, negating the need to tie it into the target board. I tapped an unlabeled via near R23 for SDA and tapped SCL directly on a leg of the EEPROM. I2C's multi-master feature allows this to be done without disabled anything in the board.

Section 3, wherein our heroes--having extracted the firmware of the 24C32 of the EZ430U--conspire to similarly free the firmware of an I2C EEPROM of a much finer vintage.

Dumping firmware from similar chips on the green EZ430U and a USB-FET gave samples for comparison. The contents of the green board and the FET were nearly identical, differing only by a few bytes. They are also significantly smaller than the red firmware, even though the FET contains a larger EEPROM. Unused bytes are padded as 0xFF.

The most common complaint regarding the EZ430-RF series is that, unlike the original EZ430, there exist no Linux drivers for the board. By reflashing the firmware of both the MSP430 and the 24C32 chips, a red EZ430 can be reverted to the green firmware, making it compatible with Linux.

For those without access to an I2C programmer, it is worth noting that the MSP430 of this board is tied to the 24C32 EEPROM. It is possible to write an MSP430 firmware image that, upon booting, does nothing but reprogram the TUSB3410's ROM.

Section 4, wherein your esteemed author prematurely concludes this article of the series.

The third installment contains instructions for compiling new firmware for the EZ430 by retargetting GCC and manually linking in the USB bootloader.

Speaking at Last Hope

2008-06-19T13:53:00.000-04:00

I'll be speaking at Last Hope in Manhattan next month. My abstract follows.

Introduction to MCU Firmware Analysis and Modification with MSP430static
The Texas Instruments MSP430 is a low-power, 16-bit microcontroller which is rapidly gaining in popularity in the embedded world. MSP430static is a tool for reverse engineering the MSP430's firmware. Following a quick tour under the hood of this tool, this lecture will demonstrate how to analyze, modify, and reflash a black-box firmware image.

MSP430 BSL Passwords: Brute Force Estimates and Defenses

2008-06-16T13:43:00.001-04:00

by Travis Goodspeed <travis at utk.edu>
at the Extreme Measurement Communications Center
of the Oak Ridge National Laboratory
regarding the work of
Alexander Becher, Zinaida Benenson, and Maximillian Dornseif
with minor additions and comments.

The MSP430 microcontroller uses its 256-bit interrupt vector table (IVT) as a password for its serial bootstrap loader (BSL), which can remain activated despite a blown JTAG fuse. As code confidentiality then depends upon the BSL password, this article will make some preliminary observations as to the difficulty of guessing the password. It doesn't attempt to be terribly thorough, precise, or academic. Rather, consider this to be a few `back of the napkin' notes on breaking the password. Further, the scope of this article is limited to the brute forcing of passwords. Alternatives to brute forcing will not be discussed here.

A good starting point would be [1] Tampering with Motes: Real World Physical Attacks on Wireless Sensor Networks. It's an excellent paper, but be sure to get the 15-page version; the 4-page variant is no substitute. This article will begin by recapping their estimate of the BSL password strength, and it will conclude with the source code of a Perl script mentioned--but not included--in that paper.

The issue at hand is that the MSP430 reuses its interrupt vector table (IVT) as a password. Thus, while the password is technically 256 bits in length, many of those bits are either fixed or predictable. Further, as the BSL allows for direct memory access to the device, it might be used to compromise keys where the firmware is known.

Becher et all attempted to determine the minimum keyspace, which is to say the number of bits out of 256 which are truly unpredictable in a rather small program. Beginning with 256 bits in an array of sixteen 16-bit interrupt handler function pointers, their reasoning follows: (1) As all MSP430 instructions must be even-aligned, every valid interrupt handler must have a least-significant bit of 0. Therefore, the space is reduced to 16*15=240 bits. (2) As the reset vector always points to the beginning of flash memory, the space is further reduced to 15*15=225 bits. (3) All unused interrupts point to the same address. As a worst case would have at least four distinct handlers, the keyspace will be reduced to no less than 4*15=60 bits by this observation. (4) As code is placed in a contiguous region of memory, a smaller program would have less are in which to place interrupt handlers. Supposing the program uses only 2^11=2kb of flash memory, the key domain is reduced to only 4*10=40 bits.

Note that as the intent is to come up with a reasonable minimum, claims (3) and (4) above refer only to a reasonable minimum of program security. An average, complicated ZigBee application might well have many more bits of randomness. They then measured that the speed of a brute forcing algorithm is 12 passwords/second at 9600 baud, 31p/s at 38,400 baud, and 83p/s at 38,400 baud with a modified client. They state a theoretical limit at 38,400 baud of 150p/s. Rounding off to 2^7=128 passwords per second, they conclude that brute forcing would be limited to 2^(40-7-1)=2^32 seconds, which is roughly equal to 128 years.

I'd like to briefly consider how brute forcing might be sped up beyond their estimates, even if such a speed-up is not of sufficient magnitude to make unassisted brute-forcing of the BSL feasible.

While the most recent revisions of the BSL require a password for changing the baud rate, V1.60 and V1.61 have no such requirement[2]. When using this command, the BSL client sends three bytes: D1, D2, and D3. D3 is what we would expect: 0x00 for 9600 baud, 0x01 for 19200 baud, and 0x02 for 38400 baud. D1 and D2, however, are much more interesting. They are written directly to the clock module control registers! (DCOCTL and BCSCTL1 on F1xx/F2xx; SCFI0/SCFI1 on F4xx.) These two registers control the frequency of the device, and they may be set to anything the device supports, which is in excess of the 4.2Mhz required for 38400 baud. Further, bytes are read by bit-banging, which is calibrated by the 0x80 synchronization character. By sending 0x80 too quickly and setting the microcontroller to 8 or 16mhz, it should be possible to brute force at a much faster rate. 2^9 passwords is a reasonable rough estimate; a bit more might be possible. 32 years is still too slow to be practical, but perhaps with possession of another revision of the target firmware image this speed-up might be valuable.

Suppose that you wish to maximize the security of the BSL password on your MSP430-based device, and you don't want to disable the BSL entirely. Becher's solution from [1] is a Perl script which replaces each interrupt pointer in the IVT with a pointer to another address, which contains a branch to the original address. At the cost of a few extra cycles on each interrupt, it can considerably increase the difficulty of brute-forcing a password. Most importantly, by separately randomizing the vectors of every device you ship, it is possible to defend against an attacker who has a copy of the firmware but does not have internally held keys of a device from reading those keys through the BSL.

In August at Black Hat USA 2008, I'll be presenting a timing attack which makes it possible to break some revisions of the BSL in short order.

[1] Tampering with Motes: Real World Physical Attacks on Wireless Sensor Networks
[2] SLAA089: Features of the MSP430 BSL


#!/usr/pkg/bin/perl
use warnings;
use strict;

# Use with Intel Hex files for Texas Instruments MSP430 microcontrollers.
# Replace ALL interrupt vectors with addresses generated randomly.
# Store jump instructions to the original interrupt handlers there.

# Written by Alexander Becher <alex@cyathus.de>, 2005.
# Use freely.

# $start and $end define the address range into which new vectors will point.

# The start address will be updated by the Ihex reading code below.
# It must be correctly aligned.
my $start = 0x4000;

# This is where the interrupt table starts. Addresses >= $end will not be used!
my $end         = 0xffe0;

my $align       = 2;            # code addresses on MSP430 must be even

my %used;   # will contain used memory regions

my @interrupts;   # stores the original interrupt vector table

# Read an Intel hex file. With much help from BFD.
while (<>) {
    my ($len, $addr, $data, $checksum)
      = (/^:([[:xdigit:]]{2})([[:xdigit:]]{4})00([[:xdigit:]]*)([[:xdigit:]]{2})\cM?$/);

## Does not work? What did I do wrong??
#     if (m/^:   # colon
#           ([[:xdigit:]]{2}) # data length
#           ([[:xdigit:]]{4}) # address
#           00   # record type
#           ([[:xdigit:]]*) # data
#           ([[:xdigit:]]{2}) # checksum
#           \cM?$/x  # CRLF
#        ) {

    if (!defined $addr || ($addr ne "FFE0" && $addr ne "FFF0")) {
 # update start of unused address region
 # assume ascending order of addresses
 # (i.e. it is not the case that there is a line in the hex file
 #  which contains code for address 0x4242 which is followed by a
 #  line which contains code for address 0x2323)

 # assume all data first, then interrupts, then trailing stuff
 if (defined $addr && defined $len) {
     $start = align(hex($addr) + $len);
 }

 print;
 next;
    }

    # If we reach this point, we are reading the first or the second
    # line of the interrupt vector table.

    # Attention: MSP430 is little endian!
    while ($data =~ /([[:xdigit:]]{2})([[:xdigit:]]{2})/g) {
     push @interrupts, hex "$2$1";
    }

    # If this is the second line, do The Real Work[tm].
    if (@interrupts && $addr eq "FFF0") {
 replace_interrupts(@interrupts);
    }
}

#
# Why this program exists ;->
#
sub replace_interrupts {
    my (@interrupts) = @_;

    foreach my $addr (@interrupts) {
 # Create a branch instruction to the original address of the handler
 my $instr = br($addr);

 # Get a new, unused address, using key material
 my $new_addr = new_addr(length $instr);

 # write a branch instruction there, mark appropriate addresses as used.
 code($new_addr, $instr);

 # point interrupt vector to new address (use Perl's loop aliasing)
 $addr = $new_addr;
    }

    print ihex(0xFFE0, map { rep_16bit_le($_) } @interrupts);
}

#
# Returns a new random unused address suitable for putting code of
# $length bytes there. Return value will be aligned.
#
sub new_addr {
    my ($length) = @_;

    my ($addr, $diff);

    $diff = ($end - $start) / $align;

    # create a new random address until an unused region of the desired
    # length is found
    do {
        my $n = int rand $diff;
 $addr = $start + $n * $align;
    } while (grep { $_ } map { isused($addr+$_) } (0..$length-1));
    # Woohoo, Perl's list processing rocks. ;-> The above was a crude
    # form of "Is any address in the region [$addr, $addr+$length) used?".

    return $addr;
}

sub isused { $used{shift()} }

sub mark_used {
    my ($addr, $len) = @_;

    foreach ($addr .. $addr + $len) {
 $used{$_} = 1;
    }
}

#
# Place $code at $addr (which must be aligned). Outputs an ihex line
# which says just that, and marks the memory area as used.
#
sub code {
    my ($addr, $code) = @_;

    my $l = length $code;
    mark_used($addr, $l);

    print ihex($addr, $code);
}

# MSP 430 branch instruction
sub br {  "\x30\x40" . rep_16bit_le(@_) }

# 16 bit little endian representation
sub rep_16bit_le { pack("v", @_) }

# ihex($addr, @data)
# write an ihex line, saying that $addr contains bytes @data
# @data should contain "\xXX" binary data
sub ihex {
    my ($addr, @data) = @_;

    @data = split //, join("", @data);

    my $type = 0;  # data

    my $ret = "";

    while (@data) {
 my @bytes = @data >= 16 ? (splice @data, 0, 16) : (splice @data);

 my $c = @bytes;

 # XXX pack?
 my $data = join("", map { sprintf "%02X", ord $_ } @bytes);

 # checksum computation from GNU binutils bfd/ihex.c
 my $checksum = $c + $addr + ($addr >> 8) + $type;
 foreach (@bytes) {
     $checksum += ord;
 }
 $checksum = (- $checksum) & 0xff;

 $ret .= sprintf(":%02X%04X%02X%s%02X\cM\cJ",
   $c, $addr, $type, $data, $checksum);

 $addr += 16;  # wrong for last iteration, but irrelevant then
    }

    return $ret;
}

# round up to the nearest multiple of $align
sub align {
    my ($n) = @_;
    if ($n % $align != 0) {
 $n += $align - ($n % $align);
    }
    return $n;
}

Syringe Logic Probe, Revision 2

2008-06-15T14:17:00.001-04:00

While my original probe is damned useful, it was a bit of a rushed job. Since then, I've found uncoated silver jewelry wire whose diameter is just a hair smaller than the inner diameter of the needle, allowing me to force it in for an electrical connection. More importantly, as I no longer solder to the outside of the needle, I can restore the safety cap and save my fingers from getting nicked.

--Travis Goodspeed
<travis at utk.edu>

Spring Cleaning

2008-06-13T14:27:00.000-04:00

I just received Nick Chernyy's Microbox as part of The Great Internet Migratory Box of Electronic Junk project.

I took the 8051 board, the 2x16 LCD, and a MAX232 level-converter chip. I then removed a healthy number of packing peanuts, swapped one of the microcontroller cases for a smaller one, and added the following:

Two PICs.
Three MSP430F2012 DIPs.
A 4G iPod, sans hard disk
Two TI CC1100 radio boards.
A board of ZIF sockets for PIC programming.

As is tradition, I'll be sending the box to someone on the Box Requests page within the next week or so.

--Travis

CopyWench, a File Format for Publicly Discussing Undistributable Material

2008-06-02T18:45:00.000-04:00

by Travis Goodspeed <travis at utk.edu>
at the Extreme Measurement Communications Center
of the Oak Ridge National Laboratory

Suppose that an author has written a document describing the reverse engineering of ROM image, and he wishes to publish his work. Further, let us suppose that the author is an honest and law-abiding citizen of a nation with intellectual property laws that prevent him from distributing software copyrighted by another. He cannot distribute his work in its entirety, as his work will cite numerous lines of the original. In this short article, I will discuss a format for a utility which--much like diff--allows an author to distribute only his changes to a document. Unlike diff, my format will not include so much as a single line of the original.

First, suppose this to be our secret file. It is from Wikipedia's BASIC article. We'll call it secret.txt:

10 INPUT "What is your name: ", U$
20 PRINT "Hello "; U$
30 INPUT "How many stars do you want: ", N
40 S$ = ""
50 FOR I = 1 TO N
60 S$ = S$ + "*"
70 NEXT I
80 PRINT S$
90 INPUT "Do you want more stars? ", A$
100 IF LEN(A$) = 0 THEN 90
110 A$ = LEFT$(A$, 1)
120 IF A$ = "Y" OR A$ = "y" THEN 30
130 PRINT "Goodbye ";U$
140 END

Each line of secret.txt has a one-way MD5 hash, which is what will be published in lieu of the line itself. To someone who does not have the secret file, 12b9bdf57db1a1c9e4fb2fb1b35e9c41 means nothing. But to someone who does have the file, it's rather easy to find that the hash belongs to line 10 above.

Suppose this to be our private commentary:

Commentary of a BASIC program.
by John Doe.

10 INPUT "What is your name: ", U$
My name is John!
20 PRINT "Hello "; U$
Hello to you, too!
30 INPUT "How many stars do you want: ", N
Tons of stars!
40 S$ = ""
50 FOR I = 1 TO N
60 S$ = S$ + "*"
70 NEXT I
80 PRINT S$
90 INPUT "Do you want more stars? ", A$
Always.
100 IF LEN(A$) = 0 THEN 90
110 A$ = LEFT$(A$, 1)
120 IF A$ = "Y" OR A$ = "y" THEN 30
130 PRINT "Goodbye ";U$
Adieu.
140 END

By replacing every secret line--that is to say every line which is found in secret.txt--with a one-way hash of the original, we will arrive with something like the following, which is free of copyrighted material.

Commentary of a BASIC program.
by John Doe.

COPYWENCH 12b9bdf57db1a1c9e4fb2fb1b35e9c41
My name is John!
COPYWENCH 8a80ddc83dc0592951d29151d62487a4
Hello to you, too!
COPYWENCH cbbf650ae187427f3cd74a58a7b0edf4
Tons of stars!
COPYWENCH f842a481f76099503c63c611dc84784e
COPYWENCH 9376ab1f0bed02260134dc9d6b723433
COPYWENCH 5cbb0ef3dbb1b75c047b278b3480fa46
COPYWENCH 95cfeba9a3004c3e6b2db6ce3222341b
COPYWENCH 402c331f990b99054568e72315e5e01b
COPYWENCH f8ee49bfcd41e6a43266105e65964247
Always.
COPYWENCH 24407c853d6df83fecd3074dc44e5ef5
COPYWENCH cc67be8c43810e63859ae75abaf7b1c2
COPYWENCH 36c25fd5bf40b1a5a0ef8d68af1580c7
COPYWENCH 80a1d74d3d5b1321fe3805a6d6f6011c
Adieu.
COPYWENCH 811061ce8478b3e56543e103ccd52c67

The following algorithm will translate between public and private files:

For each line of secret.txt:
1. Place a hash of the line in an associative array.
Then for each line of the input file,
1. If the line begins with COPYWENCH, print the line matching the checksum of the second word.
2. Else if the line exists in the associative array, print "COPYWENCH" followed by a space and the line's hash.
3. Else print the input line.

I recommend this file format, which I've named the CopyWench format, because it is terribly easy to implement. A few minutes in any scripting language will result in a working implementation.

A sample implementation follows. As all implementations ought to be licensed so as to be distributable with the documents with which they are intended to be used, this one is in the public domain. Do with it as you will.


#!/usr/bin/perl

#CopyWench 0.1
#Authored for the Public Domain
#by Travis Goodspeed <travis at utk.edu>

#Either Digest::MD5 or Digest::Perl::MD5 is needed.
BEGIN {
    eval {
 require Digest::MD5;
 import Digest::MD5 'md5_hex'
    };
    if ($@) { # no Digest::MD5
 require Digest::Perl::MD5;
 import Digest::Perl::MD5 'md5_hex'
    }             
}

if($#ARGV!=0){
    print "Usage: $0 secret.txt <input.txt >output.txt
Where secret.txt is the secret being written about.\n";
    exit;
}

my $secret=$ARGV[0];
my %lines;
my ($line,$hash);
open SECRET, "<$secret";

#Build an associative array of secret lines.
while(<SECRET>){
    chomp($_);
    $line=$_;
    $hash=md5_hex($line);
    #print "$hash $line\n";
    $lines{$hash}=$line;
}
close SECRET;

while(<STDIN>){
    chomp($_);
    $line=$_;
    $hash=md5_hex($line);
    if($lines{$hash}){
 print "COPYWENCH $hash\n";
    }elsif($line=~m/\bCOPYWENCH ([0-9a-f]+)/){
 print "$lines{$1}\n";
    }else{
 print "$line\n";
    }
}

Speaking at Defcon 16

2008-05-29T17:08:00.000-04:00

After Black Hat, I'll be speaking at Defcon 16 regarding an entirely different subject. The abstract follows.

In 1990, a wire-bound book was published in Paris by the title of «Voyage au centre de la HP28 c/s». It presents a very thorough account of the inner workings of the Hewlett Packard 28 series of graphing calculators. Designed before the days of prepackaged microprocessors, the series uses the Saturn architecture, which HP designed in-house. This architecture is very different from today's homogeneous RISC chips, with registers of 1, 4, 12, 16, 20, and 64 bits in width. The fundamental unit of addressing is the nibble, rather than the byte. Floats are represented as binary-coded decimal, and a fundamental object in the operating system is an algebraic expression.

This architecture is still used, albeit in emulation, in the modern HP50g. With this talk, I intend to call attention to a fascinating, professional, and well-documented feat of reverse engineering. Using little more than their ingenuity and an Apple ][e, Paul Courbis and Sebastien Lalande reverse engineered a black box calculator into a real computer, one which became user-programmable in machine language as a result. More than that, they documented the hack in such exquisite detail that their book is not just a fascinating read, but also veritable holy scripture for anyone trying to write custom software for this machine.

Expect a thorough review, in English, of the contents of the book. This is not a sales pitch; electronic copies of both the translation and the original are free to all interested readers. Topics include the datatypes of the computer algebra system, hacking an upgrade into the memory bus, bootstrapping an assembler, writing in machine language by tables, and adding an I/O port for software backups.

If you'd like a copy of the book in advance, grab the original French from the site of Paul Courbis or email me for a rough draft of the English translation.

--Travis Goodspeed
<travis at utk.edu>