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>
Wednesday, July 8, 2009
Friday, June 19, 2009
GoodFET MSP430 Tutorial
by Travis Goodspeed <travis at radiantmachines.com>
N.B., that this is quite outdated. See the GoodFET Tutorial for a more recent description.
This is a quick tutorial for using the GoodFET to program an MSP430. This should work for all classic MSP430 chips which support 4-wire JTAG, but it will not yet work with SpyBiWire or MSP430X2 chips, such as the MSP430F5xx and CC430. As these instructions will likely become dated very quickly, expect some surprises.
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.
Grab the entire project by running "svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet". Future updates may be grabbed by "svn update".
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.
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.
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.
The "erase" verb will mass erase all memory except for the DCO configuration. An erase is automatically performed prior to a flash.
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.
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.
Saturday, June 13, 2009
Cold, Labless HNO3 Decapping Procedure
by Travis Goodspeed <travis at radiantmachines.com>
with thanks to Brooke Hill
The following are instructions and matching photos for removing the packaging of microchips without a proper chemical laboratory. Neither a hot plate nor a fume hood is required, and the only chemicals necessary are fuming nitric acid and acetone. The result is a bare die, with bonding wires. The bonding wires may then be removed and the die photographed using microscope.
The same as any author of a lay chemistry article, I must caution you to be very careful with the procedure that I describe. If you've no prior experience with chemistry, purchase an introductory book and study the safety instructions thoroughly. Nitric acid in these concentrations is nasty stuff, even when cold.
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.
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.)
Once decapped, each die should be cleaned in acetone. For microscope photography, the bonding wires ought to also be plucked by tweezers.
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.
Friday, June 5, 2009
SPI Client Tutorial for the GoodFET
by Travis Goodspeed <travis at radiantmachines.com>
I've just confirmed that SPI support is functional on the GoodFET, but I've done so with my ugly-as-sin Python client. I'd much rather that neighborly souls write their own clients for this device. The following article describes the protocol by which this is done, as well as some snippets of the GoodFET firmware. The present code should be sufficient to write an AVR programmer, an interface for Chipcon radios, and all sorts of other neighborly things.
SPI is a synchronous, full-duplex serial protocol, which is an uptown way of saying that it has a clock and that bits are simultaneously transmitted and received. Whenever you transmit a byte, you are actually exchanging values of a register. Instead of start and stop bits, clocks are synchronized by the falling of the !SS (Slave Select) line, and then they remain synchronized by counting bits. Data is transmitted MSB-first, received LSB-first.
The GoodFET attaches by a USB serial port, one which is also used for programming. As the DTR, Data Terminal Ready, line is connected to the !RST pin of the GoodFET's microcontroller, you will find that the GoodFET turns off when you connect to it with Minicom or Hyperterminal, then turns back on when you disconnect! To remedy this, you must drop the DTR line low by using ioctl() in Posix C or your language's equivalent. This will boot the GoodFET, beginning a session.
The session itself will begin at9600 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.
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}
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.
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
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.
Friday, May 29, 2009
GoodFET11 Released
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>
Friday, May 22, 2009
Black Hat '09, Defcon 17
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>
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>
Tuesday, May 19, 2009
MSP430 Challenge of May 2009
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>
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>
Subscribe to:
Posts (Atom)
