A Keyboard With No Keys

For as capable as smartphone hardware is, the software running on them can be especially restrictive and cumbersome. Unlike a single-board computer with GPIO running a standard Linux operating system and some intuitive programming language like Python, smartphones are generally walled gardens where programming major overhead, and if a custom program can be run on them at all the user still has to figure out how to interface hardware with a USB-C port. To skip past all of this, [nicolas.ma] built an audio modem that can send keyboard input to a computer with nothing more than a browser.

The “keyboard” starts off in a browser running on a standard smartphone. A user can input text into the browser, which then gets converted into a series of audible audio pulses that can be sent to the keyboard. The keyboard itself listens to those pulses, decodes them, and then sends the text through to the computer as a standard USB device thanks to an Arduino Micro at the center. Arduino Micros are excellent choices for keyboard controllers because they have a built-in USB chip.

The protocol used here is designed and built by [nicolas.ma] as well. The words allow for variable length, with the device determining message length, and a word-ending scheme that automatically sends the message to memory when it’s detected that the message is finished. There’s also integrity checking and the ability to check on the link’s state. From hardware to software it’s an impressive build, and for anyone wondering what this might be used for [nicolas.ma] has already built a password manager from itContinue reading “A Keyboard With No Keys”

Regain Some Trust In Unknown USB Drives

For how useful USB thumb drives are for quickly toting around and copying files from one computer to another, they can be a bit of a security headache. Programs can be loaded on them with all kinds of malware; they can be obscured in some ways that are difficult to detect, and they can be set up to execute certain programs when they’re plugged in. The general wisdom is to simply avoid untrusted USB devices completely, but that sort of abstinence-only policy rarely works in the real world. If, for some reason, an untrusted USB device absolutely needs to be used, many of these security issues can be mitigated with this tool.

Built by [Novamostra], the device is simple on the surface: it’s a Raspberry Pi Pico mated to a 2-in-1 USB splitter cable. But with the USB Neutralizer software they have written loaded onto the Pico, it automatically destroys the ability of any connected USB thumb drive to load files. The program works by deleting the first and last 34 Logical Block Addressing (LBA) sectors on the drive immediately when it’s plugged in, without doing anything else. This effectively corrupts the drive bad enough to prevent malicious software in the partitions from doing anything, allowing the user to (relatively) safely put the USB drive into their computer and format it for re-use. The code for this tool is also open-source and reviewable on the project’s GitHub page.

Of course, this isn’t a perfect security solution for all USB attacks. It doesn’t erase or replace the firmware on the drive itself, and although firmware-level attacks are rare they’re not out of the question for all users, all the time. It also won’t prevent a malicious physical attack like this high-voltage one, and it may also not stop hidden or obscured partitions or devices programmed for storage and some other nefarious purpose simultaneously, like a USB HID. But still, this solves a great many of the problems associated with getting new drives from semi-untrustworthy sources, like retailers or friends whose computer skills we don’t fully trust.

Giving A Power Mac G4 A USB Upgrade, For Free!

At various times in the history of desktop computing, the market has stubbornly refused to follow the path dictated for it by a dominant manufacturer. IBM’s move to MCA in their PS/2 line is one of many examples. Another is Apple’s take on USB a couple of decades ago, when their view of the future lay with Firewire 800. [Pierre Dandumont] has revisited a Power Mac G4 from that era and unleashed what Apple never did back in the day: a USB 2.0 port. (French language, Google Translate).

The hack lies in Apple shipping the machine with an NEC USB 2.0 controller, but only using it for USB 1.1. A PowerPC Linux distro will happily use it for USB 2.0, but Mac OS refused. Replacing the BIOS ROM with an image designed for the same Mac without Firewire 800 cured the problem, but at the expense of being so we’re told irreversible.

An obscure set of Macs from the early 2000s with an odd combination of hardware and OS may not count for much in 2026, but back in the day having USB 2.0 was a big deal and this would really have mattered. We like it that he put this together, even if the chances of having a G4 on the Hackaday desktop probably isn’t too high.

This isn’t the first USB hack we’ve seen for a PowerMac G4.

Homebrew Webcam Support For The Original Xbox

These days, we take it for granted that a video game console will have multiple USB ports. There’s even an expectation that basic peripherals such as storage devices will “Just Work” when plugged into the system — a far cry from the days when each system had its own proprietary memory card.

The original Xbox from 2001 actually had USB ports as well, it’s just that they were used for the controllers and had non-standard connectors that kept you from plugging in other devices. But a simple adapter gets you a standard USB-A port, and after that it’s just a matter of software. Like this homebrew project to get generic USB webcams working on Microsoft’s first foray into console gaming.

Well, “generic” may be pushing it a bit, as the project by [Darkone83] currently lists only two compatible cameras. The first is the Xbox Live Vision Camera, which was never intended to be used on the original Xbox and was instead an accessory for Microsoft’s follow-up console, the Xbox 360. Interestingly, the other supported camera happens to be Sony’s PS2 EyeToy. Claiming that you plugged a PS2 camera into your Xbox would have been fighting words back on the playground circa 2003, but now it’s a reality thanks to the power of open source.

Now there technically was a camera for the original Xbox, but it was only released in Japan and is quite rare. Perhaps unsurprisingly it used the same OV519 chipset as the EyeToy and later Vision Camera, and reverse engineering how the console communicated with it was critical to the development of this project.

As of right now, there’s not much practical application for this webcam driver. It just shows the image from the camera on your TV in glorious 320×240 resolution. But now that the code to make it work is out in the wild, hopefully other Xbox homebrew projects will add support for it.

Although things aren’t quite as active these days as they once were, the hacking scene for the original Xbox is the stuff of legend. If you ever see one of this gargantuan consoles at a flea market for cheap, there’s still plenty of fun to be had pushing the system outside of its comfort zone.

If You Want To Hack Me, Come In Through The Speaker

Some security hacks require someone to have physical access to your computer. In many cases, that’s easy to mitigate. Other attack vectors can put you at risk from anywhere via the network. That’s what firewalls are for. But there is an in-between risk where an attacker just has to be “around” your computer. [Rasmus Moorats] found out that a Creative Sound Blaster sound bar could open up just such an attack.

[Rasmus] was poking around the firmware just to write custom software to control it. The possibility of an attack was just an accidental find.

The soundbar connects to USB, but it also has Bluetooth, which, for some reason, is always on. There’s an app that can communicate with the speaker using BLE, and Creative has a special protocol to control it. The same protocol works on USB or Bluetooth, but with an important difference.

Continue reading “If You Want To Hack Me, Come In Through The Speaker”

ChargeCap Helps Your Batteries Last Longer By Limiting Charge Level

If you want to maximize the life of your lithium-ion batteries, proper storage voltage is critical. That is, don’t store them empty, and don’t store them completely full either. “Almost fully charged” is a sweet spot for occasional-use devices. Sadly, this is easier said than done. While many devices use integrated rechargeable batteries these days, most provide no method of limiting charge level. That’s where [DaverDavid]’s ChargeCap comes in.

By sampling charge current and disconnecting when it drops to 50 percent of peak, charging is reliably stopped when the target device is 80 to 90 percent charged, regardless of cell count or capacity.

ChargeCap sits between a USB charger and target device, disconnecting when it detects that recharging is 80 to 90 percent complete. This is particularly useful for maximizing the cell life of devices that see only intermittent use.

The way ChargeCap does this is clever, and relies on the fact that all lithium-ion charging curves look the same regardless of cell capacity or cell count. Charge current remains at pretty much the same level for most of the charging process, but tapers off quickly (and in a linear fashion) as cells approach their maximum capacity. That’s because charging a battery is a lot like blowing up a balloon: the first breaths are easy, but once the balloon fills out, every breath needs to push harder than the last.

ChargeCap works by sampling the peak charge current at the beginning of the charge cycle, then detecting when it drops below 50 percent of peak, at which point charging is stopped. The result is a device that reliably charges to 80 to 90 percent of capacity, and no more. ChargeCap uses an ESP32-C3 and a small OLED display that, as a nice touch, inverts colors to signal charge completion. Design files and code are at the GitHub repository.

Lithium-ion cells are fantastic devices, so flesh out your knowledge by reading [Arya Voronova]’s primer on designing them into your own projects, or a more in-depth explanation of how they work.

USB, Abstracted

Modern technology builds on abstractions. Most application programmers today don’t know what a non-maskable interrupt is, nor should they have to. Even fewer understand register coloring or reservation stations for instruction scheduling, and fewer still can explain the physics behind the transistors in the CPU. Sometimes tech starts out where you need to know everything (programming a bare-metal microprocessor, for example) and then evolves to abstraction. That’s where [WerWolv] wants to get you for writing USB code using the recent post USB for Software Developers.

Many USB tutorials assume you want to know about the intricacies of protocol negotiation, information about the hardware layer, and that you are willing to write a Linux kernel module to provide a driver. But thanks to abstraction, none of this has been absolutely necessary for many use cases for a long time.

While the post focuses on Linux, there is libusb for Windows. We presume the same principles would apply, more or less.

Continue reading “USB, Abstracted”