DEV Community: Krish Gulati

[Boost]

Krish Gulati — Sat, 25 Jul 2026 23:25:29 +0000

Krish Gulati

Jul 23

Building hid_guard, Part 1 — The Problem and the False Start

#security #linux #kernel #cybersecurity

6 min read

Building hid_guard, Part 1 — The Problem and the False Start

Krish Gulati — Thu, 23 Jul 2026 11:06:07 +0000

If you're just joining, the index post has the full origin story:

A wireless Rubber Ducky I built out of an ESP32-S2 to prank my roommate, ~60 recruits at a cybersecurity club demo, and the question that showed up a few days late like it always does:

If a ₹500 chip can convince a computer it's a keyboard, what's actually stopping it?

Short answer: nothing. Long answer: this post, and the extremely humbling three months that produced it.

`while(naive) { believe(); }`

Here's the thing your computer trusts, no questions asked: when something plugs into a USB port and announces "I'm a keyboard, and here's a keypress," the OS just believes it. No handshake, no proof, no captcha. It's the security equivalent of a bouncer who lets anyone in as long as they're wearing a shirt that says STAFF.

A Rubber Ducky is that shirt. It's a tiny chip that shows up, claims keyboard-hood, and immediately starts firing a pre-written script of keystrokes at whatever's foolish enough to trust it — which, per the paragraph above, is everything.

But a script isn't a person, and for anyone trying to catch this, that's good news: it leaks into the numbers. Measure the exact gaps between keystrokes and a real human has noise in there — tiny, involuntary jitter in how long a key is held and how long the pause is before the next one, because fingers are just imprecise machinery. A microcontroller replaying a script has none of that. It fires keys with a mechanical evenness no human has ever produced outside of a Black Mirror episode. The gap is small in absolute terms — single-digit milliseconds versus tens of milliseconds — but it's there.

I didn't have to take my own word for it: USBlock: Blocking USB-Based Keypress Injection Attacks (Neuner et al., DBSec 2018) shows you can catch injected keystrokes purely by watching timing patterns. So the core idea wasn't mine — it had actual peer review behind it. What I got wrong was where, physically, in the system, to go do the catching.

What I actually built

You don't need to know a single thing about the Linux kernel to see why this was doomed. You just need one picture: my code was two separate programs talking to each other through a shared queue called a BPF ring buffer.

Think of it as a mailbox with one strict rule: one side only ever drops letters in, the other side only ever picks them up, and neither has to stand there waiting on the other.

The kernel-space half was a tiny piece of code living right up against the hardware, close enough to see every keystroke the instant it happened. Its entire job was to grab the keystroke, timestamp it, drop it in the mailbox, and refuse to elaborate further.

The userspace half was a completely ordinary program — Python, Rust, C, whatever. It handled figuring out which device had appeared, reading keystrokes back out, running timing analysis, deciding whether something looked malicious, and disconnecting suspicious devices.

Even device discovery turned into more machinery than any sane person should need. On startup it snapshotted every already-connected input device — a known-good guest list — and then polled every 200 ms looking for newcomers, one loop for USB and one loop for Bluetooth. Once it found a new device, it attached its tiny keystroke watcher and started reading events.

Very proud of myself at the time. Should not have been.

`if (byte_count == 9) { yolo(); }`

Here's the actual logic:

// "9 bytes? Must be THIS layout."
// future me: it was not.

if (packet_length == 9) {
    modifier_byte = packet[1];
    key_byte      = packet[3];
} else {
    modifier_byte = packet[0];
    key_byte      = packet[2];
}

// two keys closer together than 5ms?
// get suspicious.

if (gap_since_last_key_ms < ATTACK_THRESHOLD_MS) {
    suspicion++;

    if (suspicion >= ALERT_THRESHOLD)
        block_this_device();
}

Two crimes committed here. I'll take the stand for both.

Crime #1: Magic numbers everywhere

ATTACK_THRESHOLD_MS and the alert threshold were just fixed numbers — 5 ms and 30 ms — reverse engineered from exactly two data points: one Rubber Ducky, and my own hands. There was no per-device baseline, no statistical model, no adaptation, no acknowledgement that humans type differently. A fast typist and a scripted attack could easily land on the same side of a hardcoded threshold. I wasn't modeling a distribution. I was drawing a line in the sand and hoping the tide agreed.

Crime #2: This isn't parsing. It's vibing.

if (packet_length == 9) is not HID parsing.

Every HID device ships with something called a report descriptor — think of it as a tiny instruction manual handed to the kernel that says "here's exactly how every packet I send will be formatted." The kernel is supposed to read this manual. My code did not. It simply counted bytes.

It worked because my ESP32-S2 always emitted exactly the packet shape I'd hardcoded. Anything else; a different keyboard, a different layout, a different report ID arrangement, silently broke it.

My ESP32-S2's actual HID report descriptor. Every device draws this differently.

None of this crashed. None of it errored. It simply worked on exactly one device forever...which is arguably the most dangerous kind of bug: the kind that looks like success.

If you want the actual instruction manual instead of my fake success, read the kernel docs on HID before writing HID code. I did not. You're reading the consequences.

`O(too_slow)`: The latency problem

Suppose the parsing had been perfect. Suppose the thresholds were mathematically divine. There was still a deeper problem baked into the design: detection requires waiting to see a pattern, which means some keystrokes always land before the verdict comes in.

The pipeline looked like this:

Keystroke
     ↓
Kernel program timestamps event
     ↓
Ring buffer
     ↓
Userspace wakes up
     ↓
Timing analysis
     ↓
Threshold check
     ↓
Device disconnect

That's not unique to my setup, even USBlock, the paper this whole idea is built on, makes the same trade explicitly. Their own detection rule needs three suspicious keystrokes in a row before it acts, precisely because reacting on the first one alone would flag too many fast human typists. They measured their actual decision loop at under a millisecond, which is fast. But "fast" and "before the first few keystrokes land" are different guarantees, and their own paper is upfront that some earliest keystrokes get through by design.

Where my prototype actually lost, badly, wasn't kernel-vs-userspace speed; it was everything upstream of the decision. Broken packet parsing, no per-device baseline, and a discovery loop polling every 200ms meant my "three suspicious keystrokes" test could take way longer than a millisecond to even trigger, on top of an already-generous three-keystroke head start for the attacker.

A Rubber Ducky payload often completes in under a second. My detector needed multiple suspicious keystrokes just to get nervous, then more time on top of that to actually react while carrying all the extra latency my own bad architecture added along the way.

If the attack runs in O(instant), my defense was running in roughly O(please wait, buffering).

Why I finally let it go

The more I understood HID report descriptors, composite devices, and Linux input plumbing, the less my architecture made sense. The real solution wasn't "make userspace smarter" — it was "run detection where the events first appear." I just didn't know what that place was called.

A few months later I found hid-omg-detect, a kernel module attempting similar timing analysis, and then a review of it by Benjamin Tissoires (the person who maintains large parts of Linux HID subsystem). The teardown was brutal: wrong assumptions about report layout, races with other HID drivers, HID_ANY_ID matching problems, ownership issues. And then the actual verdict — this kind of logic belongs in HID-BPF, not as a standalone module, not fighting every other driver, but running before any driver even sees the raw events.

He wasn't talking to me. He didn't know I existed. Yet he'd independently arrived at exactly the same conclusion I had spent three months stumbling toward.

Three months of work, and the honest epitaph is this:

The prototype proved the signal was real, and then spent every remaining day of its life teaching me everything wrong with it.

A perfectly respectable way for a bad prototype to die.

Up next

Part 3 is the rebuild: running detection inside the kernel's own HID path, reading each device's actual report descriptor, reimplementing human-vs-script timing analysis from scratch, and learning how to do statistics in an environment that has never once heard of a decimal point.

The archived prototype, magic numbers and all, is available on GitHub if you want to see exactly how bad it was.

Anyone else built something clever that turned out to be solving the problem in exactly the wrong place? Curious how you found out.

[Boost]

Krish Gulati — Tue, 07 Jul 2026 10:51:28 +0000

Krish Gulati

Jul 7

The Duck Stops Here: Building hid_guard — Catching Keystroke Injection at the Kernel Level

#security #c #linux #opensource

5 min read

The Duck Stops Here: Building hid_guard — Catching Keystroke Injection at the Kernel Level

Krish Gulati — Tue, 07 Jul 2026 10:50:55 +0000

This is the index post for a series on building hid_guard, a HID-BPF security monitor for the Linux kernel — from the first embarrassingly bad prototype to an RFC on the linux-input mailing list. I'll update the links below as each part goes live, assuming I don't get distracted rewriting Part 2 for the fourth time.

How this actually started

Every "I built a security tool" post claims to start with a researcher noticing a subtle gap in the threat model. Mine starts with me pranking my roommate.

Our cybersecurity club runs an intro session every fall to reel in new members, and in August–September 2025 it was my turn to make the pitch. The club is only three years old and still fighting the older, flashier clubs for attention, so standing on stage clicking through bullet points was not going to cut it. I had an ESP32-S2 sitting in a drawer doing nothing useful with its life, and I knew it could be flashed to act as a USB HID device; so I built a wireless Rubber Ducky: a 500–600Rs ($5–6) chip that shows up to any computer as "just a keyboard" and fires off whatever script you gave it the second it's connected.

It landed better than I hoped, roughly 60 sign-ups, the highest in the club's short history. I'd like to think the little wireless duck gets some of the credit.

Then, because a good prank is a wasted prank if you only use it once, I ran it on my roommate too. It worked on him exactly as well as it worked on a room full of strangers.

That's when the actual question showed up, a few days later than it probably should have: if this is this easy, what's supposed to stop it?

I went looking for an answer and found a handful of userspace tools trying:

Device-attribute whitelisting — trivially beaten by spoofing a trusted VID/PID
Watching for new keyboard insertions and locking the workstation in response
Flagging a mismatch between the USB class a device advertises and what it's actually registered for

All clever, all userspace, and none of them fast enough to matter: by the time a daemon reacts to a device event, a Rubber Ducky payload has usually already finished its PowerShell one-liner and is halfway through exfiltrating your browser cookies.

So I stopped asking "how do I stop this" and started asking "how does the kernel even get fooled in the first place." How does a HID device advertise itself, how is a keystroke report actually structured on the wire, what is the kernel trusting the moment it decides something is a "keyboard." That thread led me, inevitably, to eBPF.

I was fairly new to C at the time, and the eBPF tutorials humbled me a bit more than I'd like to admit: verifier errors that read like riddles written by someone who resents you personally, and a mental model I did not yet have for programs that aren't allowed to loop unbounded or touch a pointer without first proving to a paranoid static analyzer that it's safe. (C is my favorite language now, so something clearly stuck, possibly out of trauma bonding.) Eventually I had a genuinely ugly v0.01 and showed it off at my college's project showcase. We didn't win. I don't think the judges had heard of HID-BPF either, which stung less once I realized it meant the gap I'd stumbled into was real and not just badly explained by me.

After the showcase I sat down and rebuilt it properly — new architecture, a standalone eBPF prototype meant to do the entire job by itself. That phase is archived here: [eBPF-hid_guard]

fusion1110 / eBPF-hid_guard

eBPF-hid_guard

See Why This Was Archived below.

A Linux kernel-space security monitor for detecting and blocking HID injection attacks (Rubber Ducky, O.MG Cable, ESP32-based keyboard emulators) using eBPF HID-BPF struct_ops.

What This Does

Malicious HID devices emulate keyboards and inject keystrokes far faster than any human typist. This tool detects that timing anomaly and unbinds the offending device from the kernel HID driver before the attack completes.

On startup, the tool snapshots all currently connected HID devices and ignores them — only newly connected devices are monitored. It supports both USB and Bluetooth HID devices.

Branch Structure

`main` — Working Proof of Concept

Functional end-to-end pipeline, tested against an ESP32-based keyboard emulator:

Snapshots pre-existing devices at startup; ignores them
Parallel USB and BLE discovery threads — first to detect a new device wins
Attaches a HID-BPF struct_ops program to the discovered device
BPF side captures raw HID report bytes, timestamp…

View on GitHub

I got most of the userspace side working, and then, sometime in April, I ran into hid-omg-detect: a kernel module doing almost exactly what I'd been reaching for, scoring HID devices on keystroke timing entropy and plug-and-type latency. Buried in the maintainer discussion was a suggestion from Benjamin Tissoires (the HID subsystem maintainer and the person behind udev-hid-bpf) to build this kind of detection on top of HID-BPF rather than as a standalone kernel module. Watching someone arrive at that conclusion independently, from the inside, while I'd been circling the same idea from the outside with zero credentials and a lot of stubbornness, was about as close to validation as I was going to get.

That sent me down the udev-hid-bpf rabbit hole for real. I'll get into the framework itself (struct_ops, device matching, the attach pipeline) in Part 2. Recently I submitted an RFC patch to the linux-input mailing list and got back an automated report cheerfully pointing out everything wrong with it. Which is, in its own way, a milestone: the project is now real enough to have a bot mad at it.

A prank, a rabbit hole, a bad prototype, a good rebuild, a maintainer confirming from the outside that I hadn't been chasing nothing. This series is the long version.

The problem

Plug a BadUSB or Rubber Ducky device into a machine and, to the operating system, it's just a keyboard. HID has no concept of "this input device is actually a microcontroller replaying a script."

It types exactly like a person — except it doesn't, not really.

A script fires keystrokes on a schedule; a human's timing has noise in it that's genuinely hard to fake convincingly down at the millisecond level. That gap is small. But it's real, and it's measurable, if you're watching at the right layer instead of trusting the device's word for it.

hid_guard watches at that layer. It's a HID-BPF program, built on the udev-hid-bpf framework, that models keystroke timing per device and flags input that looks automated rather than typed. This series is the story of building it — including the parts that didn't work the first time, because those are usually the parts worth reading about.

Why a series instead of one post

A single "I built a kernel security tool" post would flatten months of dead ends into a highlight reel — a nice narrative, a nearly useless technical reference. The actual engineering lives in the parts that get thrown away and rebuilt: the framework I abandoned, the bug that only showed up on one specific keyboard, the review that caught five things I'd completely missed before submission. Cram all of that into one post and it's either exhausting to read or quietly dishonest by omission. Splitting it up lets each part get the space it actually needs.

What's in the series

Part 1 — The problem and the false start.
Why keystroke-timing detection is viable at all, and the standalone eBPF prototype I built first and then abandoned once its limits became embarrassingly clear. (coming soon)

Part 2 — Pivoting to udev-hid-bpf and designing the detection model.
The framework switch — struct_ops, hwdb device matching, the probe/attach pipeline, how HID descriptors encode a keyboard's layout and the detection model built on top of it: Welford's online variance algorithm reimplemented in fixed-point arithmetic because BPF has never heard of a float, and why Post-Enumeration Delay turned out to matter almost as much as keystroke timing itself. (coming soon)

Part 3 — Where it breaks: 6KRO vs. NKRO.
The off-by-one bug that only surfaced on N-key-rollover hardware, and what it taught me about trusting a length value I hadn't actually bothered to define properly. (coming soon)

Part 4 — From review to RFC.
A pre-submission review that caught issues I'd missed, a spinlock clobber risk on device re-enumeration, and what actually went out to the linux-input mailing list — plus what came back. (coming soon)

DEV Community: Krish Gulati

[Boost]

Building hid_guard, Part 1 — The Problem and the False Start

Building hid_guard, Part 1 — The Problem and the False Start

while(naive) { believe(); }

What I actually built

if (byte_count == 9) { yolo(); }

Crime #1: Magic numbers everywhere

Crime #2: This isn't parsing. It's vibing.

O(too_slow): The latency problem

Why I finally let it go

Up next

[Boost]

The Duck Stops Here: Building hid_guard — Catching Keystroke Injection at the Kernel Level

The Duck Stops Here: Building hid_guard — Catching Keystroke Injection at the Kernel Level

How this actually started

fusion1110 / eBPF-hid_guard

eBPF-hid_guard

What This Does

Branch Structure

main — Working Proof of Concept

The problem

Why a series instead of one post

What's in the series

`while(naive) { believe(); }`

`if (byte_count == 9) { yolo(); }`

`O(too_slow)`: The latency problem

`main` — Working Proof of Concept