Build a Standalone BadUSB Device with a Raspberry Pi Pico (No Flipper Required)

Our extensive Flipper Zero BadUSB content covers using the Flipper's built-in BadUSB capability — this build is different: a standalone BadUSB device built from a $5 Raspberry Pi Pico, with no Flipper required. It's a genuinely good way to understand exactly how a HID injection attack works at the hardware/firmware level, and it's cheap enough to build several and never worry about losing one.

How BadUSB Attacks Actually Work

A BadUSB device isn't malware in the traditional sense — it's a microcontroller that identifies itself to a computer as a USB keyboard (a Human Interface Device, or HID) and then types pre-programmed keystrokes at high speed the instant it's plugged in. Since operating systems inherently trust keyboards (a keyboard typing commands looks identical to a person typing them), this bypasses most traditional malware defenses entirely — there's no file to scan, just keystrokes arriving faster than a human could type them.

This is exactly why physical USB port security matters as much as software security, and building one yourself is the clearest way to understand why "don't plug in random USB devices" is genuinely serious advice, not paranoia.

Why the Pi Pico

The Raspberry Pi Pico is a genuinely excellent BadUSB platform: real native USB HID support in its SDK, RP2040 chip has plenty of headroom for this simple a task, and at roughly $5, it's cheap enough that using one for security testing doesn't feel like a big commitment. It also runs CircuitPython, which makes writing and modifying payloads dramatically more approachable than raw C for anyone not already deep into embedded development.

Parts List

ComponentNotes Raspberry Pi Pico (not Pico W — the wireless version isn't needed here)The base board, roughly $5 Micro USB cableFor programming and for the final deployed device to plug into a target machine Small enclosure (optional)A 3D printed shell disguising it as a generic USB drive/dongle — purely cosmetic, doesn't affect function

Setting Up CircuitPython

1. Download the CircuitPython UF2 file for the Pico from circuitpython.org
2. Hold the BOOTSEL button on the Pico while plugging it into your computer — it'll mount as a USB mass storage device
3. Drag the UF2 file onto the mounted drive — the Pico reboots running CircuitPython
4. Install the adafruit_hid library (download from Adafruit's CircuitPython library bundle) by copying it into the lib folder that appears on the Pico's drive

Writing Your First Payload

CircuitPython payloads live in a code.py file that runs automatically the instant the Pico powers on — meaning the instant it's plugged into any USB port. A basic example that opens a text editor and types a message:

import time import usb_hid from adafruit_hid.keyboard import Keyboard from adafruit_hid.keyboard_layout_us import KeyboardLayoutUS from adafruit_hid.keycode import Keycode time.sleep(2) # wait for the OS to recognize the HID device before sending keystrokes kbd = Keyboard(usb_hid.devices) layout = KeyboardLayoutUS(kbd) # Example: Windows Run dialog -> open Notepad -> type a message kbd.press(Keycode.GUI, Keycode.R) kbd.release_all() time.sleep(0.5) layout.write("notepad\n") time.sleep(1) layout.write("This came from a $5 microcontroller that took less than a second to type this.")

Save this as code.py on the Pico's drive, and it executes automatically on every power-up — meaning every time it's plugged into a USB port.

The Two-Second Delay Matters

That initial time.sleep(2) isn't optional — most operating systems take a moment to actually recognize and initialize a newly-connected HID device. Send keystrokes before that initialization finishes and they simply get dropped, since there's no keyboard for the OS to route them to yet. Real-world payloads often need a slightly longer delay depending on the target machine's speed; tune it based on testing against your own hardware.

Building More Useful Test Payloads

For actual security testing purposes (against machines you own or have permission to test), useful payloads to build and understand include:

• Screen lock timing test: a payload that simply waits and then checks whether a machine has auto-locked appropriately after a period of inactivity — useful for auditing whether your own systems' lock policies are actually being enforced
• Exfiltration awareness demo: a payload that opens a command prompt and demonstrates how quickly basic system information could be gathered — useful for showing, concretely, why an unlocked unattended machine is a real risk, not a theoretical one
• USB port policy testing: simply testing whether your own organization's USB port lockdown policies (if any) actually prevent a HID device from executing at all — some endpoint security tools specifically block unrecognized HID devices, and testing against your own policy confirms whether it's actually working

Defending Against This Class of Attack

Building this device is as much about understanding the defense as the attack:

• Physical USB port control — many endpoint security suites can block unrecognized HID devices entirely, or require explicit approval before a new HID device is allowed to send input
• Never plug in unknown USB devices — found in a parking lot, received unsolicited, anything without a clear trusted origin, full stop
• Screen lock discipline — a locked screen (correctly configured) generally blocks a BadUSB payload from doing much of anything useful, since most payloads assume an active logged-in session
• USB data blockers ("USB condoms") for charging-only scenarios on unfamiliar ports, preventing any data pins from ever being active

Responsible Use

Build and test this only against your own devices, or with explicit written permission on systems you're authorized to test. Deploying a HID injection payload against a computer you don't own or don't have permission to test is unauthorized computer access in most jurisdictions — a serious crime, not a prank. The value of building one yourself is entirely educational: understanding exactly how trivial this attack is to build cheaply is the strongest possible argument for taking physical USB security seriously.