When Clever Hardware Hacks Bite Back: A Password Keeper Device Autopsy

February 7, 2026 by Maya Posch 3 Comments

Sometimes you have this project idea in your mind that seems so simple and straightforward, and which feels just so right that you have to roll with it. Then, years later you stumble across the sad remnants of the tearful saga and the dismal failure that it portrays. Do you put it away again, like an unpleasant memory, or write it up in an article, as a tearful confession of past sins? After some coaxing by a friend, [Alessandro] worked up the courage to detail how he set about making a hardware-only password keeper, and why it failed.

The idea was so simple: the device would pretend to be a keyboard and type the passwords for you. This is not that unusual, as hardware devices like the Mooltipass do something similar. Even better, it’d be constructed only out of parts lying around, including an ATtiny85 and an HD44780 display, with bit-banged USB connectivity.

Prototyping the hardware on a breadboard.

Overcoming the challenge of driving the LC display with one pin on the MCU required adding a 74HC595 demultiplexer and careful timing, which sort of worked when the stars aligned just right. Good enough, but what about adding new passwords?

This is where things quickly skidded off the tracks in the most slapstick way possible, as [Alessandro] solved the problem of USB keyboard HID devices being technically ‘output-only’, by abusing the indicator statuses for Caps Lock, Num Lock, and Scroll Lock. By driving these from the host PC in just the right way you can use them as a sort of serial protocol. This incidentally turned out to be the most reliable part of the project.

Where the project finally tripped and fell down the proverbial flight of stairs was when it came to making the bit-banged USB work reliably. As it turns out, USB is very unforgiving with its timing unlike PS/2, making for an infuriating user experience. After tossing the prototype hardware into a box, this is where the project gathered dust for the past years.

If you want to give it a try yourself, maybe using an MCU that has more GPIO and perhaps even a USB hardware peripheral like the STM32F103, ESP32-S3 or something fruit-flavored, you can take a gander at the project files in the GitHub repository.

We’re always happy to see projects that (ab)use the Lock status indicators, it’s always been one of our favorite keyboard hacks.

A pair of printed circuit boards are shown against a pink background. The right circuit board is plugged into a USB cable, and has several LED indicators on. The left board is plugged into the other at 45-degree angle, and has no visible components.

Tamper Detection With Time-Domain Reflectometry

January 24, 2026 by Aaron Beckendorf 13 Comments

For certain high-security devices, such as card readers, ATMs, and hardware security modules, normal physical security isn’t enough – they need to wipe out their sensitive data if someone starts drilling through the case. Such devices, therefore, often integrate circuit meshes into their cases and regularly monitor them for changes that could indicate damage. To improve the sensitivity and accuracy of such countermeasures, [Jan Sebastian Götte] and [Björn Scheuermann] recently designed a time-domain reflectometer to monitor meshes (pre-print paper).

Many meshes are made from flexible circuit boards with winding traces built into the case, so cutting or drilling into the case breaks a trace. The problem is that most common ways to detect broken traces, such as by resistance or capacitance measurements, aren’t easy to implement with both high sensitivity and low error rates. Instead, this system uses time-domain reflectometry: it sends a sharp pulse into the mesh, then times the returning echoes to create a mesh fingerprint. When the circuit is damaged, it creates an additional echo, which is detected by classifier software. If enough subsequent measurements find a significant fingerprint change, it triggers a data wipe.

The most novel aspect of this design is its affordability. An STM32G4-series microcontroller manages the timing, pulse generation, and measurement, thanks to its two fast ADCs and a high-resolution timer with sub-200 picosecond resolution. For a pulse-shaping amplifier, [Jan] and [Björn] used the high-speed amplifiers in an HDMI redriver chip, which would normally compensate for cable and connector losses. Despite its inexpensive design, the circuit was sensitive enough to detect when oscilloscope probes contacted the trace, pick up temperature changes, and even discern the tiny variations between different copies of the same mesh.

It’s not absolutely impossible for an attacker to bypass this system, nor was it intended to be, but overcoming it would take a great deal of skill and some custom equipment, such as a non-conductive drill bit. If you’re interested in seeing such a system in the real world, check out this teardown of a payment terminal. One of the same authors also previously wrote a KiCad plugin to generate anti-tamper meshes.

Thanks to [mark999] for the tip!

Embedded TPM: Watch Out!

January 23, 2026 by Al Williams 63 Comments

Today’s PCs are locked up with Trusted Platform Module (TPM) devices so much so that modern Windows versions insist on having a recent TPM to even install. These have become so prevalent that even larger embedded boards now have TPM and, of course, if you are repurposing consumer hardware, you’ll have to deal with it, too. [Sigma Star] has just the primer for you. It explains what TPM does, how it applies to embedded devices, and where the pitfalls are.

The TPM is sometimes a chip or sometimes secure firmware that is difficult to tamper with. They provide secret storage and can store boot signatures to detect if something has changed how a computer starts up. The TPM can also “sign off” that the system configuration is the same to a remote entity. This allows, for example, a network to prevent a hacked or rogue computer from communicating with other computers.

Embedded systems, usually, aren’t like PCs. A weather station at a remote location may have strangers poking at it without anyone noticing. Also, that remote computer might be expected to be working for many more years than a typical laptop or desktop computer.

This leads to a variety of security concerns that TPM 2.0 attempts to mitigate. For example, it is unreasonable to think a typical attacker might connect a logic analyzer to your PC, but for an embedded system, it is easier to imagine. There is a session-based encryption to protect against someone simply snooping traffic off the communication bus. According to the post, not all implementations use this encryption, however.

Motherboard has a slot for TPM, but no board? We’ve seen people build their own TPM boards.

Title image by [Raimond Spekking] CC BY-SA-4.0

Great Trains, Not So Great AI Chatbot Security

January 13, 2026 by Jenny List 12 Comments

A joy of covering the world of the European hackerspace community is that it offers the chance for train travel across the continent using the ever-good-value Interrail pass. For a British traveler such a journey inevitably starts with a Eurostar train that whisks you in comfort through the Channel Tunnel, so a report of an AI vulnerability on the Eurostar website from [Ross Donald] particularly caught our eye. What it reveals goes beyond the train company, and tells us some interesting tidbits about how safeguards in AI chatbots can be circumvented.

The bot sits on the Eurostar website, and is a simple HTML and JavaScript client that talks to the LLM back-end itself through an API. The API queries contain the whole conversation, because as AI toy manufacturers whose products have been persuaded to spout adult context will tell you, large language models (LLM)s as commonly implemented do not have a context memory for the conversation in hand.

The Eurostar developers had not made a bot without guardrails, but the vulnerability lay in those guardrails only being applied to the most recent message. Thus an innocuous or empty message could be sent, with a payload concealed in a previous message in the conversation. He demonstrates the bot returning system information about itself, and embedding injected HTML and JavaScript in its responses.

He notes that the target of the resulting output could only be himself and that he was unable to access any data from other customers, so perhaps in this case the train operator was fortunately spared the risk of a breach. From his description though, we agree they could have responded to the disclosure in a better manner.

Header image: Eriksw, CC BY-SA 4.0.

The ‘Hidden’ Microphone Inside The Sipeed NanoKVM

December 20, 2025 by Maya Posch 44 Comments

Recently, [Jeff Geerling] dropped into the bad press feeding frenzy around Sipeed’s NanoKVM, most notably because of a ‘hidden’ microphone that should have no business on a remote KVM solution. The problem with that reporting is, as [Jeff] points out in the video below, that the NanoKVM – technically the NanoKVM-Cube – is merely a software solution that got put on an existing development board, the LicheeRV Nano, along with an HDMI-in board. The microphone exists on that board and didn’t get removed for the new project, and it is likely that much of the Linux image is also reused.

Of course, the security report that caused so much fuss was published back in February of 2025, and some of the issues pertaining to poor remote security have been addressed since then on the public GitHub repository. While these were valid concerns that should be addressed, the microphone should not be a concern, as it’d require someone to be logged into the device to even use it, at which point you probably have bigger problems.

Security considerations aside, having a microphone in place on a remote KVM solution could also be very useful, as dutifully pointed out in the comments by [bjoern.photography], who notes that being able to listen to beeps on boot could be very useful while troubleshooting a stricken system. We imagine the same is true for other system sounds, such as fan or cooling pump noises. Maybe all remote KVM solutions should have microphone arrays?

Of course, if you don’t like the NanoKVM, you could always roll your own.

Top image: the NanoKVM bundle from [Jeff]’s original review. (Credit: [Jeff Geerling])

Continue reading “The ‘Hidden’ Microphone Inside The Sipeed NanoKVM” →

This Week In Security: PostHog, Project Zero Refresh, And Thanks For All The Fish

December 19, 2025 by Jonathan Bennett 18 Comments

There’s something immensely satisfying about taking a series of low impact CVEs, and stringing them together into a full exploit. That’s the story we have from [Mehmet Ince] of Prodraft, who found a handful of issues in the default PostHog install instructions, and managed to turn it into a full RCE, though only accessible as a user with some configuration permissions.

As one might expect, it all starts with a Server Side Request Forgery (SSRF). That’s a flaw where sending traffic to a server can manipulate something on the server side to send a request somewhere else. The trick here is that a webhook worker can be primed to point at localhost by sending a request directly to a system API.

One of the systems that powers a PostHog install is the Clickhouse database server. This project had a problem in how it sanitized SQL requests, namely attempting to escape a single quote via a backslash symbol. In many SQL servers, a backslash would properly escape a single quote, but Clickhouse and other Postgresql servers don’t support that, and treat a backslash as a regular character. And with this, a read-only SQL API is vulnerable to SQL injection.

These vulnerabilities together just allow for injecting an SQL string to create and run a shell command from within the database, giving an RCE and remote shell. The vulnerabilities were reported through ZDI, and things were fixed earlier this year. Continue reading “This Week In Security: PostHog, Project Zero Refresh, And Thanks For All The Fish” →

This Week In Security: Hornet, Gogs, And Blinkenlights

December 12, 2025 by Jonathan Bennett 12 Comments

Microsoft has published a patch-set for the Linux kernel, proposing the Hornet Linux Security Module (LSM). If you haven’t been keeping up with the kernel contributor scoreboard, Microsoft is #11 at time of writing and that might surprise you. The reality is that Microsoft’s biggest source of revenue is their cloud offering, and Azure is over half Linux, so Microsoft really is incentivized to make Linux better.

The Hornet LSM is all about more secure eBPF programs, which requires another aside: What is eBPF? First implemented in the Berkeley Packet Filter, it’s a virtual machine in the kernel, that allows executing programs in kernel space. It was quickly realized that this ability to run a script in kernel space was useful for far more than just filtering packets, and the extended Berkeley Packet Filter was born. eBPF is now used for load balancing, system auditing, security and intrusion detection, and lots more.

This unique ability to load scripts from user space into kernel space has made eBPF useful for malware and spyware applications, too. There is already a signature scheme to restrict eBPF programs, but Hornet allows for stricter checks and auditing. The patch is considered a Request For Comments (RFC), and points out that this existing protection may be subject to Time Of Check / Time Of Use (TOCTOU) attacks. It remains to be seen whether Hornet passes muster and lands in the upstream kernel. Continue reading “This Week In Security: Hornet, Gogs, And Blinkenlights” →