The 3D-printed adapter shown assembled, with the USB cable's wires going into cable channels on the adapter and magnets slotted into the adapter's openings

Use Your Thinkpad X1 Tablet’s Keyboard Standalone

Some hacks are implemented well enough that they can imitate involved and bespoke parts with barely any tools. [CodeName X]’s Thinkpad X1 Tablet Keyboard to USB adapter is one such hack – it let’s one reuse, with nothing more than a 3D printed part and a spare USB cable, a keyboard intended for the Thinkpad X1 Tablet (2016 or 2017).

The issue is, this keyboard connects through pogo pins and holds onto the tablet by magnets, so naturally, you’d expect reusing it to involve a custom PCB. Do not fret – our hacker’s take on this only needs aluminum foil and two small circular magnets, pressing the foil into the pins with the help of the printed part, having the USB cable pins make contact with the foil pads thanks to nicely laid out wire channels in the adapter. If you want to learn more, just watch the video embedded below.

Of course, this kind of adapter will apply to other similar keyboards too — there’s no shortage of tablets from last decade that had snap-on magnetic keyboards. But watch out; some will need 3.3V, and quite a few of them will use I2C-HID, which would require a MCU-equipped adapter like this wonderful Wacom rebuild did. Not to worry, as we’ve shown you the ropes of I2C-HID hacking.

Continue reading “Use Your Thinkpad X1 Tablet’s Keyboard Standalone”

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”

Hobnobbing With The Knob

The scroll wheel might be the best thing that happened to the computer mouse since, well, the computer mouse. But sometimes you want something a little more tangible. For example, with a software-defined radio setup, it doesn’t feel right to scroll your mouse to change frequencies. That’s where [Wagiminator]’ USB knob would come in handy. Marrying a 3D printed case, some addressable LEDs, a rotary encoder, and a CH552E microcontroller, the knob appears to the host operating system as a normal USB keyboard. That means most programs can use it without any special drivers or software.

There’s honestly not much to the hardware. A custom PCB holds two WS2812’s, the tiny CPU, the encoder, and the USB plug. There are a few random discrete components, too, but not many. Everything you need is on the project page. The PCB layout, the software, the schematics, and the 3D print files. The code that does the main work is extremely simple. The USB code is a bit more complex (look in the include directory) but honestly, it isn’t as bad as most USB examples we’ve seen.

This project is ripe for hacking. The software is simple enough to modify easily. The 3D printed case wouldn’t be hard to spruce up or print in different colors. Following the example, this would make a reasonable core for a custom keyboard peripheral that used exotic keys instead of a rotary encoder.

Knobs can be simple or complex. If you want our take on the odd volume control, we used sonar.

A couple of joysticks wired up to a Teensy for prototyping.

Custom Joystick Build Guide Should Point You In The Right Direction

Over the last two years, [benkster] has been perfecting their ideal flight controller. Like many people, they started out with a keyboard and mouse and eventually moved on to a joystick. While a HOTAS (hands on throttle-and-stick — e.g. a yoke controller with inputs right there on the sides) might have been the next logical step, those things cost too much. Naturally, the answer is to build one, ideally for less money. Hey, it could happen.

The design went from just an idea to a cardboard prototype, and then to a wooden enclosure and later, a 3D-printed case. Since [benkster] learned a great deal along the way, they want to give back to the community with a comprehensive joystick design/build guide so that others don’t have to start from zero, overwhelmed with information.

[benkster] wanted three joysticks, a bunch of big buttons, a throttle, a display to show component status (as in, is joystick #3 a joystick right now or a WASD keyboard?), and immersive details everywhere — you know, a million buttons and switches to give it that cockpit feel. [benkster] is using a Teensy 4 to control two 3-axis joysticks and one 2-axis stick. Since this adds up to too many axes for Windows/DirectX to read in, the 2-axis stick is used as a WASD keyboard.

This guide is a great place to start, especially for folks who may be newer to electronics. There are nice introductions to many types of components and tidbits that are relevant outside the world of joysticks.

You want immersive flight simulation away from the PC? Here’s a printable flexure-based ‘stick that snaps right on your Xbox controller and pushes the buttons.

MIL-SPEC Keyboard Now Salutes USB

When [easyjo] picked up this late ’80s Marconi mil-spec keyboard for cheap, he knew it wouldn’t be easy to convert it to USB — just that it would be worth it. Spoiler alert: those LEDs aren’t a mod, they’re native. They get their interesting shape from the key traces, which are in the four corners.

Despite having way-cool buttons such as WPNS HOLD, and the fact that Control is on the home row where it belongs, this keyboard does not look fun to type on at all for any length of time. Of course, the point of this keyboard is not comfort, but a reliable input device that keeps out dust, sweat, liquids, and the enemy.

This is probably why the controller is embedded into the underside of the key switch PCB instead of living on its own board.  [easyjo] tried to analyze the signals from the existing 26-pin connector, but it didn’t work out.

So once he was able to decode the matrix, he removed the controller chip and wired the rows and columns directly to an Arduino Leonardo. Fortunately, the LEDs were just a matter of powering their columns from the front side of the board.

The availability of certain kinds of military surplus can make for really interesting modernization projects, like adding POTS to a field telephone.

Via r/duino