The Hardware
So, if I want to pull this off, I should first take a look at the hardware. They state there's an entire
ARM in there, but wouldn't that be overkill for just a keyboard and some LEDs? Only one way to find out.
First of all, a look at the gorgeous Cherry switches. I also found out the reason the keyboard is pretty
heavy: the white plate the switches are placed in is actually solid metal.
This is the back of the naked keyboard, showing the PCB that connects the keys and LEDs. Notice that every
key has a diode to protect against ghosting issues.
This is a close-up of the region with the controller chip in it. On the bottom left, there's the connector
leading to the micro-USB jack. Above it is a voltage regulator sitting next to the main processor. All
around the processor are transistors to drive all the LEDs. There's also an i2c EEPROM, presumably to
store lighting settings.
The controller is an HT32F1755, made by the Taiwanese company Holtek. It's a 72MHz ARM Cortex-M3 with a generous 127K of flash and 32K of RAM. It's actually somewhat weird that speedy microprocessors nowadays are cheap enough that it makes economical sense to put one in a keyboard that's quicker than some of the first USB devices you can plug it into.
The controller has a few nice extra features. First of all, there's the usual SWD/JTAG-port to debug whatever is running on the controller using just a few wires and a JTAG debugger. Secondly, if you only want to read or write the flash, the keyboard has a ROM-based bootloader. Just pull a GPIO down and reset the chip, and using a Windows-program you can read or write the flash over USB. This works even if the flash contents are corrupted.
The chip also has a security feature or two. The most relevant here is a 'security bit'. This is meant to thwart people trying to get the flash contents out and will shut down the flash as soon as it's accessed from anything else than the program running in flash itself. That includes the USB bootloader and JTAG reads.
Well, the thing the security bit was designed to thwart was the first thing I had to do: I needed the flash contents to figure out how the keyboard works and modify it into running Snake. If the security bit was set, I wouldn't be able to use the SWD port to get it out. So was the security bit set? Only one way to find out...
First, I needed to figure out an easy way to get to the JTAG or SWD port. Luckily, the PCB actually
has them available on a few non-populated headers. The GPIO which invokes the USB ROM bootloader is also
brought out in a similar way.
This is my setup. The red board is my FT2232 JTAG board. It can't natively speak SWD, but there's a
one-resistor hack to change that. I used OpenOCD to talk to this, and after
creating a working configuration for it, I tried to dump the flash.
Drat, seems like the security bit is actually set...