Should you be able to brick a keyboard just by writing a driver to flash the lights on it? We don’t think so either. [TheNotary] got quite the shock when embarking on a seemingly straightforward project to learn C++ on the x86-64 architecture with Windows and sent it straight to Silicon Heaven with only a few seemingly innocent USB packets.

The project was a custom driver for the XVX S-K80 mechanical keyboard, aiming to flash LED patterns across the key LEDs and perhaps send custom images to the integrated LCD. When doing this sort of work, the first thing you need is the documentation of the communications protocols. Obviously, this was not an option with a closed-source project, so the next best thing is to spy on the existing Windows drivers and see how they worked. Using Wireshark to monitor the USB traffic whilst twiddling with the colour settings, it was clear that communications were purely over HID messages, simplifying subsequent analysis. Next, they used x32dbg (now x64dbg, but whatever) to attach to the existing driver process and trap a few interesting Windows system calls. After reading around the Windows API, a few candidate functions were identified and trapped. This gave them enough information to begin writing code to reproduce this behaviour. Then things got a bit odd.

There apparently was a lot of extra protocol baggage when performing simple tasks such as lighting an LED. They shortened the sequence to reduce the overhead and noticed an additional byte that they theorized must encode the number of packets to expect in case only a subset of the LEDs were being programmed. Setting this to 0x01 and sending LED code for single keys appeared to work and was much faster but seemed unreliable. After a short experiment with this mystery value, [TheNotary] reverted the code to send all the packets for the full LED set as before, forgetting to correct this mystery value from the 0xFF it was programmed to during the experiment. They were surprised that all the LEDs and LCD were switched off. They were then horrified when the keyboard never powered up again. This value appeared to have triggered an obscure firmware bug and bricked it—a sad end to what would have been a fun little learning project.

Keyboard hacks are so plentiful it’s hard to decide where to start. How about upgrading the keyboard of your trusty ZX81? Here’s a lovely, minimal mechanical keyboard powered by a Pi Pico, and finally while we’re thinking about drivers bricking your stuff, who can forget FTDI gate? We may never forgive that one.

Header image: Martin Vorel, CC BY-SA 4.0.