I got a new keyboard this week with 80s-era clickiness: a Cooler Master QFR XTi.
This thing has LED-backlit keys, which is kind of fun but also a bit of a gimmick. More interesting to me is that driving everything is an ARM Cortex M3 MCU (Holtek HT32F165x) which is flashable over USB. That is more powerful than my first computer.
It would be nice to expand the features of this thing a bit, e.g. there’s an RTC on board the MCU, wouldn’t it be useful to have TOTP built directly into the keyboard? Or, perhaps it would be useful to audit the vendor firmware to make certain it is not recording your keystrokes. Of course, getting to the point of unraveling the vendor FW and flashing one’s own will entail a fair amount of work.
It seems there is support for SWD programming and pads for that on the motherboard, but given my clunkiness with a soldering iron that is kind of a last-resort thing to revisit once I brick my keyboard.
Anyway, I captured the firmware upload via USBPcap in Windows. Turns out it’s a fairly simple protocol. I saw the following two messages cross the wire:
MSG 1: 01 01 53 b6 38 2d 00 00 6b 2d 00 00 73 2d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 73 2d 00 00 07 48 80 47 07 48 80 47 07 48 00 47 fe e7 fe e7 fe e7 fe e7 fe e7 fe e7 MSG 2: 01 01 84 0d 6c 2d 00 00 9f 2d 00 00 fe e7 fe e7 fe e7 fe e7 ad 7b 00 00 4d 71 00 00 81 2d 00 00 df f8 0c d0 00 f0 3e f8 00 48 00 47 e5 84 00 00 60 47 00 20 06 49 07 4a 08 68 50 43 43 f2 39 02
It is reasonable to assume that the “fe e7” chain repeats without a break across the two messages, which in turn tells us that the header for the message is twelve bytes:
msg 1: 01 01 53 b6 38 2d 00 00 6b 2d 00 00
msg 2: 01 01 84 0d 6c 2d 00 00 9f 2d 00 00
Bytes 4-8 and 8-12 look like addresses in little endian format. As it happens, if you subtract these two addresses and add one, you get the value 52, which is exactly how many post-header bytes are in the message. Also note that the “address 1” in message two is just one more than the “address 2” in message one. So we have something that looks like this:
struct hdr {
u8 cmd; /* ??? */
u8 subcmd; /* ??? */
__le16 something; /* ??? -- crc? */
__le32 start_dest_address; /* first byte of xfer */
__le32 end_dest_address; /* last byte (inclusive) */
u8 data[0];
};
The device presumably copies the payload from “data” into the physical (flash) addresses specified in the header.
So I dumped the firmware from the pcap file. There’s nothing like an ELF header on it, but I guess that’s probably normal for bare-metal programs running on an MCU. Various bits do look like ARM thumb code.
Until now I didn’t really know squat about ARM MCUs, but a little bit of googling indicates that E7 FE is an infinite loop and the typical way you would write a handler for something like NMI that you just want to go into loop mode. So that explains the 0xfee7 sequence, and everything before looks like a lot of little-endian 32 bit addresses, which lines up with what would go in the Vector Table, an ARM concept which contains the values for program counter load address, stack pointer, IRQ handlers, and so on.
A bit more googling found some github projects with functional flashing utilities for similar products with similar or the same flashing protocol. There is yet hope, hopefully more to come.