i.crave.beer – The online home of Joshua Skorich

12th August 2016

Defcon 24 Badge

Another August, another week in the desert for security summer camp. This year my company was kind enough to sponsor my entire trip including four days of Black Hat training. Ossmann's Software Defined Radio (SDR) class was pretty darn fantastic and I also really enjoyed Joe Grand's Hardware Hacking course. Having a few years experience in product development, most of what Joe was saying wasn't new to me, but the tools and techniques he presented in reversing unknown hardware were well received. Which leads me to the entire point of this post. Defcon 24 featured an electronic badge for attendee's that allowed me to practice some of my new skills in reversing the circuit. I tried to document as much as possible, but feel free to hit me up if I am missing something obvious.

Full disclosure: I didn't bring any hardware hacking tools with me in Vegas. Most of what I ended up using I bought in the Defcon vendor bazaar, or bought online after I got back.

I started by reviewing the hardware that could be seen on the board. The only component really worth much attention was the Intel Quark D2000 microcontroller. The datasheet is publicly available on Intel's site which showed the full pinout including GPIO, UARTs, JTAG, etc..

Basic review of the board showed surface traces leading from the microcontroller to the top test points. The schematic in the datasheet identifies these as pins 13 and 14, corresponding to UART_B_TX and UART_B_RX. All I had at that point was a DP Bus Pirate, so I used the built in ADC to test for ground, and then hooked up for UART passthrough.

As you may have noticed, the top right test points aren't actually connected to anything. The surface lead goes to a pad, which is where the MCU is sending async serial, but that's where it stops. At least the pinout is confirmed as can be seen via the serial output to bus pirate:

And sadly, that's all I was able to do with the badge at Defcon. A few people told me about the Konami code, which in fact does light up the LEDs and spits out "Konami Code unlocked!" to the UART. Woooopie.

So I knew I wanted to go further. For starters, what are the 8 via's at the base of the baord there for? The datasheet again suggests these are for JTAG, which theoretically could be used to read/write firmware and was most likely used for initial programming. That was my goal. First up, JTAGulation! Well, not quite. The real first act is trying to get something connected to those tiny vias so we can connect anything to it. I relocated the battery connector to the backside, and then decided to hell with it and soldered some wires directly to the pads to hook up to an external power supply.

After looking high and low to find a wire small enough to feed through the vias, I ended up gutting a CAT5 cable, and using 2 strands of each 24 guage wire. Once these were soldered to the board, I threw some tape on there to keep everything in place and could finally start JTAGulation!!! Such a fun word. JTAGulate.

Connect all 8 of the unknown pins up to the JTAGulator, as well as a ground connection and start with an ID Scan. Joe Grand covers this pretty nicely in his videos, so reference those for more info.

It should only take a handful of seconds for the ID Scan to complete which gives us a partial pinout, and also confirms JTAG is present. Next, perform a Bypass scan to get the TDI, and also confirm the ID scan results.

Fantastic! JTAGulation complete! Love that word... Now for the black magic, dumping firmware.

I bought a Bus Blaster by Dangerous Prototypes from Seeed Studio to act as my low cost, high speed JTAG interface. It's $35 plus shipping so why not. After a bit of RTFM'ing OpenOCD's documentation, I was able to get everything wired up and communicating. Being on a Mac made it slightly more difficult, but in other ways it was rather simple. My apologies if you use a different OS, but I'm only documenting what worked for me. Installing OpenOCD (Open On Chip Debugger) is pretty simple, however the config's to work with Intel's Quark D2000 are not in the Homebrew repo yet. Brew can still be used to install everything, just be sure to include '--HEAD' to pull from git rather than the brew repo.

Install OpenOCD:
`brew install --HEAD openocd`

Once installed, `sudo updatedb` and `locate openocd` to find the location of the interface and target scripts. Using the pinout discovered via JTAGulation, wire up the Bus Blaster to the JTAG wires.

OpenOCD took a bit of trial and error, but first things first, if you are on a Mac, unload the FTDI drivers. Look hard enough at the OpenOCD documentation and you will find this yourself.
`sudo kextunload -b com.apple.driver.AppleUSBFTDI`

OpenOCD has a built-in config for the Bus Blaster, as well as the Quark D2000, but a couple of config options were needed to get everything playing nicely. You can add them to modular files like I did or just throw them all in one. Regardless, I needed all of the following:
$ cat speed.cfg
jtag_khz 2000

$ cat daemon.cfg
telnet_port 4444
gdb_port 3333

Everything should be ready. But it's not. I still haven't figured out why, but in order to pull firmware from the board you must first boot into "JTAG mode". I can't find anywhere in the D2000 datasheet that says this, but after a ton of trial and error, the Internet told me to jump the top left test points (1 and 3), then power on the board. Sure enough, it now works. More investigating is needed to figure out why.

Regardless, lets move on. Jump test points 1 and 3, then power on the badge, then plug in the Bus Blaster to USB. Launch OpenOCD similar to this, substituting your file locations:
`openocd -f /usr/local/Cellar/open-ocd/HEAD-cd9b9a6/share/openocd/scripts/interface/ftdi/dp_busblaster.cfg -f /usr/local/Cellar/open-ocd/HEAD-cd9b9a6/share/openocd/scripts/target/quark_d20xx.cfg -f speed.cfg -f daemon.cfg`

In a separate tab, window, etc., connect into OpenOCD via telnet, netcat, whatever:
`ncat localhost 4444`

Last up, follow the OpenOCD instructions. Ensure that the board is initialized, halt the core, then dump the image. The datasheet shows where the flash memory resides, so use these as your offset and length:

Sweet! Lets take a look at it in a hex editor:

Looks like we are getting somewhere. Finally, lets toss it in IDA and end this hardware hacking exercise:

Annnnd. Done! Some beautiful x86 ASM to play with. I haven't even began to modify and try to write back, but at least I got this far.

Files for download if you want to continue the adventure:
- Binary dump
- Disassembled