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.
Using HID as the base protocol is something most hw hackers should get familiar with. Really comfy.
agree, everyone should at least be able to write a descriptor. a good two thirds of my hacks are hid devices.
Oh yes I have done exactly the same thing reverse engineering a Flexray module. I changed one byte in the SCN config to 0xFF and it induced a buffer overflow. This stopped the config from loading at both startup and in provisioning so no module function and also no ability to update over UDS. That was fun.
SELF-DESTRUCT CODE makes it sound intentional. I’d guess this is just a buffer overflow that somehow resulted in firmware being corrupted.
I’ve heard of pagers like that
recent news on the pager front has been interesting. at least they answered the question who terrorizes the terrorists.
Interesting story, but the Stuxnet reference is all wrong. Siemens didn’t have a bug in their controllers that led to their destruction, that was a spectacularly well designed abuse of the enrichment process employing temperatures and pressures to precipitate solid UF6 onto the centrifuges’ rotors, causing them to physically destroy themselves.
Didn’t the Stuxnet attack include the Siemens devices stop reporting their actual data and instead return fake data to the industrial control system?
Like the speed of the centrifuges?
Referencing it here is still wrong. And the article’s title is clickbait BS – where is the self destruct code?
A downvote for this article, there is no evidence of a self destruct code found though reverse engineering, but most likely some obscure bug that got triggered.
But apparently the flash of this thing is writable, so you can take up the challenge to write new firmware.