Seeking Guidance on Building a Custom BadUSB Protection Tool Inspired by Anti-BadUSB

[lxlnimalxl]

Hi,

Thank you for creating Anti-BadUSB! It’s a clean, cross-platform solution that effectively demonstrates how behavioral heuristics (like rapid keystrokes) can be used to detect and mitigate BadUSB-style attacks.

I’m a developer with experience in scripting and security tools, and I’d like to build my own lightweight BadUSB defense mechanism—either as a learning project or for small-scale deployment. Your implementation using pynput and timing thresholds is very helpful as a starting point.

To better understand the design choices, I’d appreciate your insight on a few points:

Detection Thresholds:
How did you arrive at the default values (e.g., 10 keypresses, 30ms window)? Were these tuned through testing against real Rubber Ducky payloads?
Evasion Considerations:
Have you observed or tested ways this detection could be bypassed (e.g., by slowing down the payload or using mouse-based injection)?
Extension Ideas:
If someone wanted to enhance this approach—say, by adding USB descriptor checks (VID/PID) or integrating with system logs—would you recommend keeping the logic in Python, or switching to a lower-level language/service?
I’m not asking for code, just high-level advice or lessons learned that could help someone build a robust, minimal detector from scratch.

Thanks again for open-sourcing this tool!

[1Developpeur]

Hi,

Thanks for your interest in Anti-BadUSB!

First, sorry for the delayed reply.

Detection thresholds:
I tuned the defaults by testing against a BadUSB / Rubber Ducky-style payload script. The thresholds were chosen so the detector reliably flags the rapid-typing patterns typical of BadUSB payloads while avoiding false positives from a real human user.

Evasion considerations:
Mouse-based injection: my program does not currently monitor or block mouse-based injection. In theory an attacker could try to use a mouse or combinations of mouse+virtual keyboard, but it’s not obvious to me how such an attack could silently and quickly download-and-execute a payload compared with raw keyboard injection. Using a visual keyboard or long mouse sequences would likely be slower and less stealthy for the attacker.

Slowing down keystrokes: yes, if an attacker slows down the payload to mimic human typing, they can bypass a purely timing-based detector. BadUSBs rely on speed and automation; forcing attackers to slow down reduces their advantage, and may make many payloads long to execute.

Extension ideas:
Language choice: moving to a lower-level language (C/C++, Rust, etc...) has advantages: access to USB APIs, more reliable device-level inspection, better performance, and easier integration into boot/OS services. Python is great for prototyping and cross-platform proof-of-concept tools, but a production agent benefits from lower-level access and better privilege control.

USB descriptor checks: verifying device descriptors (VID/PID) is a strong addition. Whitelisting known VIDs/PIDs or requiring explicit user approval for new HID devices reduces attack surface. Think of this like a small firewall for peripherals. Add a device whitelist/blacklist UI, persistent logs of plugged devices, and alerts. Show device descriptors, attach timestamps, and allow quick “allow/deny” actions. Audit logs make post-incident analysis far easier.
Fail-safe/user workflow: provide a user-approval prompt when a suspicious device is detected (with an option to temporarily allow), safe quarantine mode that blocks HID input until user approval.

Thanks again for the feedback and for contributing to the project, i appreciate it!