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.
