USB HID And Run Exposes Yet Another BadUSB Surface

You might think you understand the concept of BadUSB attacks and know how to defend it, because all you’ve seen is opening a terminal window. Turns out there’s still more attack surface to cover, as [piraija] tells us in their USB-HID-and-run publication. If your system doesn’t do scrupulous HID device filtering, you might just be vulnerable to a kind of BadUSB attack you haven’t seen yet, rumoured to have been the pathway a few ATMs got hacked – simply closing the usual BadUSB routes won’t do.

The culprit is the Consumer Control specification – an obscure part of HID standard that defines media buttons, specifically, the “launch browser” and “open calculator” kinds of buttons you see on some keyboards, that operating systems, surprisingly, tend to support. If the underlying OS you’re using for kiosk purposes isn’t configured to ignore these buttons, they provide any attacker with unexpected pathways to bypass your kiosk environment, and it works astonishingly well.

[piraija] tells us that this attack provides us with plenty of opportunities, having tested it on a number of devices in the wild. For your own tests, the writeup has Arduino example code you can upload onto any USB-enabled microcontroller, and for better equipped hackers out there, we’re even getting a Flipper Zero application you can employ instead. While we’ve seen some doubts that USB devices can be a proper attack vector, modern operating systems are more complex and bloated than even meets the eye, often for hardly any reason – for example, if you’re on Windows 10 or 11, press Ctrl+Shift+Alt+Win+L and behold. And, of course, you can make a hostile USB implant small enough that you can build them into a charger or a USB-C dock.

USB image: Inductiveload, Public domain.

Human-Interfacing Devices: Packing For The Descriptor Heist

We started with figuring out HID descriptors a week ago, and I’ve shown you how to send raw HID packets using a MicroPython fork. We do still have the task in front of us – making a touchscreen device. For that, let’s give you the tools to capture an existing descriptor from a touchscreen, then show you how to tweak it and how it turns out in the end.

Packing For The Heist

When it comes to this kind of adventure, we can’t go without tools and weapons – it could be dangerous! Without them, you could even abandon your project halfway! Here’s enough high-precision tools and ammunition to last you through whatever obstacles you might encounter. Except for the web-based tools, these tools are for Linux, but please remember that you can always use a virtual machine or a Raspberry Pi. Nobody would use Windows for a heist anyway, what’s with all the telemetry and such.

The first tool is for reading descriptors – we need one to learn from, it’s just like a keycard you can flash to a security guard and scan at the vault entry. Of course, with RFID, you want to have enough examples, compare bits between a few cards and all. For now, HID descriptors don’t have authenticity checks, but it looks like that might just change in the future. Leave it to Apple and Microsoft to add them, as usual. On Linux, seeing descriptors is simple – as root, go into /sys/bus/usb/devices/, find your device by its lsusb device tree path, then follow the directory with the VID/PID in it. That directory will contain a report_descriptor file – hexdump it. The entire command could look like this:

sudo hexdump -v -e '/1 "%02X "' /sys/bus/usb/devices/3-6.2/3-6.2\:1.1/0003\:0C40\:8000.0022/report_descriptor`

Again, you might need root to even find this path, so use sudo -i if you must. The format string in the hexdump command gives you parser-friendly output. Specifically, for parsing, I use this webpage – it’s wonderful, even adding tabs that delineate different sections of the descriptor, making its output all that more readable! You can also save this webpage locally, it’s a very neat tool. Other than that, you can try other local tools like this one!

Continue reading “Human-Interfacing Devices: Packing For The Descriptor Heist”

Human-Interfacing Devices: The Descriptor Heist

Today, we’ll build our own input devices. And they will be easy to create and write firmware for, they will work perfectly, and they will be cross-platform. We can do that with help of the Human Interface Device (HID) standard, and by way of introduction, so that you never get confused by what a “descriptor” means, and we’ll build our own HID device — a Human Interface Device device. The way we build them won’t require reading specifications – instead, I’ll teach your how to steal HID descriptors from existing devices, tweak them for our purposes, and use them in our devices to harness the power of HID.

For decades now, it’s been possible to build a HID mouse or keyboard by using a library or two, and it’s been a godsend for hackers all around the world. However, these libraries are typically confined to a certain template and inflexible, and we hackers often go outside of what’s expected. HID allows for much more than a simple keyboard or a mouse. That’s why today we’re building a touchscreen – something not yet covered online or by libraries.

HID lets you build devices that are friendly. They don’t need drivers, they are plug and play, and they do what you expect them to do. At its core, the HID standard is as simple as is ubiquitous. You can tunnel HID over USB, Bluetooth, I2C, and modern-day operating systems support all three of these. Today, let’s go through the basics of HID, and then build a USB touchscreen out of a SPI-connected resistive touchscreen, with help of the usual RP2040+MicroPython combo. I will also give you a toolkit for how to debug a Human Interface Device device as thoroughly as possible – specifically on Linux, showing all the HID debug and introspection capabilities that Linux gives you. But it’ll work on Windows too through the beauty of standardization.

Continue reading “Human-Interfacing Devices: The Descriptor Heist”

Shot of CubeTouch, a six sided cube built out of PCBs with each of the top PCB allowing for diffusion of the LEDs on the inside to shine through

Keyboard Shortcuts At The Touch Of A Planetary Cube

[Noteolvides] creates the CubeTouch, a cube made of six PCBs soldered together that creates a functional and interactive piece of art through its inlaid LEDs and capacitive touch sensors.

The device itself is connected through a USB-C connector that powers the device and allows it to send custom keyboard shortcuts, depending on which face is touched.

Finger touching the top of a CubeTouch device

The CubeTouch is illuminated on the inside with six WS2812 LEDs that take advantage of the diffusion properties of the underlying FR4 material to shine through the PCBs. The central microprocessor is a CH552 that has native USB support and is Arduino compatible. Each “planet” on the the five outward facing sides acts as a capacitive touch sensor that can be programmed to produce a custom key combination.

Assembling the device involves soldering the connections at two joints for each edge connecting the faces.

We’re no strangers to building enclosures from FR4, nor are we strangers to merging art and functionality. The CubeTouch offers a further exploration of these ideas in a sweet package.

The CubeTouch is Open Source Hardware Certified with all documentation, source code and other relevant digital artifacts available under a libre/free license.

Continue reading “Keyboard Shortcuts At The Touch Of A Planetary Cube”

Breaking Down The USB Keyboard Interface With Old-Fashioned Pen And Paper

What is better for gaming, old PS/2 style keyboards, or modern USB devices? [Ben Eater] sets out to answer this question, but along the way he ends up breaking down the entire USB keyboard interface.

It turns out that PS/2 and USB are very, very different. A PS/2 keyboard sends your keystroke every time you press a key, as long as it has power. A USB keyboard is more polite, it won’t send your keystrokes to the PC until it asks for them.

To help us make sense of USB’s more complicated transactions, [Ben] prints out the oscilloscope trace of a USB exchange between a PC and keyboard and deciphers it using just a pen and the USB specification. We were surprised to see that USB D+ and D- lines are not just a differential pair but also have more complicated signaling behavior. To investigate how USB handles multi-key rollover, [Ben] even borrowed a fancy oscilloscope that automatically decodes the USB data packets.

It turns out that newer isn’t always better—the cheap low-speed USB keyboard [Ben] tested is much slower than his trusty PS/2 model, and even a much nicer keyboard that uses the faster full-speed USB protocol is still only just about as fast as PS/2.

If you’d like to delve deeper into keyboard protocols, check out [Ben]’s guide to the PS/2 keyboard interface, complete with a breadboarded hardware decoder. If these keyboards have too many keys for your taste, you might consider this USB Morse code keyboard. Thanks to Peter Martin for the Tip!

Finally, Someone Has Found The Any Key

 

keyboard and any key device

“Where’s the any key?” Well, it’s right here. After running into trouble with the STM platform, [lukasz.iwaszkiewicz] went with the Texas Instrument C Series Launchpad to construct his “Any Key” HID device. He was able to make use of the TI TM4C123G LaunchPad’s extensive USB library which is laid out into four tiers – the very top tier being Device Class API. This gives the programmer the ability to implement simple devices with just a few lines of code. [lukasz.iwaszkiewicz] points out that ST does not have this option available.

The Any Key uses a host PC program that allows the user to enter keystrokes into a virtual keyboard. This information is then passed to the Any Key device. When it is pressed, it will push the recorded keystrokes back to the host PC. Simple, but effective!

The project is completely open source, and all files and code are available. Be sure to check out the video after the break demonstrating the Any Key in action.

Continue reading “Finally, Someone Has Found The Any Key”

DIY ‘PS3 Sixaxis’ Controller


[max] lets us know about this DIY ‘PS3 SIXAXIS’ style programmable controller. It’s a USB device that uses an accelerometer to provide an interactive human interface. They put one inside a model airplane and use it with a flight-sim. (I’d like to see them add some gyros to add some realistic resistance to the plane interface.)