BadUSB Engineering: Open-Source-HID-Stick unter 30 $

Wir haben gemeinsam mit der österreichischen Cybersecurity-Firma BYTEBOLT einen Open-Source-BadUSB-Stick entwickelt. BadUSB ist ein USB-HID-Tool für autorisierte Awareness-Tests und Penetrationstests. Das Ziel war nicht die maximale Feature-Liste, sondern maximal wirtschaftliche Einsetzbarkeit in echten Awareness-Programmen mit Stückzahlen von 50 bis 500 Einheiten. Die drei zentralen Engineering-Entscheidungen, ATmega32U4 statt STM32, UDP-Standardformat statt Custom-Mechanik und Arduino-Bootloader statt Bare-Metal, haben das Tool unter 30 $ Stückkosten ermöglicht. Bei Embedded Solutions heißt das Projekt BadUSB, BYTEBOLT vertreibt es als BYTEBOLT One.

Ausgangslage: Warum bisherige BadUSB-Tools für Awareness-Programme ungeeignet waren

Cybersecurity-Awareness ist in den letzten Jahren erwachsen geworden. Phishing-Simulationen sind in Mittelstand und Konzernen Standard, ISO 27001 und NIS2 verlangen kontinuierliche Mitarbeiterschulung. Eine Angriffsklasse blieb dabei fast immer außen vor: physische USB-basierte Angriffe.

Der wissenschaftliche Beleg dafür, wie ernst das Thema ist, liefert die viel zitierte UIUC-Studie von Tischer et al. (2016): Auf einem Universitätsgelände platzierte USB-Sticks wurden in 98 % der Fälle aufgehoben und in mindestens 45 % der Fälle tatsächlich an einen Rechner angeschlossen, der erste binnen unter sechs Minuten. Eine aktuellere Forschungsarbeit, Li et al. (2025) im Journal of King Saud University - Computer and Information Sciences, identifiziert die fehlende praktische Simulationsmöglichkeit von BadUSB-Angriffen als kritische Forschungs- und Praxislücke in Unternehmensumgebungen.

Die Lücke entsteht nicht nur aus mangelndem Bewusstsein, sondern aus einer wirtschaftlichen Konstellation am Werkzeugmarkt:

Genau diese Lücke zwischen „zu teuer für Bulk" und „zu unzuverlässig für Profi-Einsatz" hat BYTEBOLT mit uns gemeinsam geschlossen.

Anforderungsprofil aus der Pentest-Praxis

BYTEBOLT führt Penetrationstests, Awareness-Schulungen und Phishing-Simulationen für Mittelstand und Konzerne durch. Das Anforderungsprofil für ein eigenes BadUSB-Tool war von Anfang an klar formuliert:

• Vollständig offen, Schaltplan, Firmware und Dokumentation unter einer freien Lizenz (GPLv3)
• Programmierbar in einer Standard-Sprache, kein proprietäres Skript-Ökosystem. Programmierbar mit C und über die Arduino IDE leicht an das Zielgerät übertragbar. Kein Programmer oder komplizierte IDE nötig.
• Kompakt im UDP-Formfaktor, kompatibel mit Standard-USB-Stick-Gehäusen, also auch mit Custom-Branding-Optionen
• Bulk-fertigbar, Stückzahlen für Awareness-Workshops müssen wirtschaftlich darstellbar sein
• Eindeutig identifizierbar, jede Einheit mit unverwechselbarer Seriennummer für Engagement-Tracking
• Killswitch, nach definierter Anzahl Auslösungen oder nach Programm-Ende automatisch deaktivierbar

Designentscheidung 1: ATmega32U4 USB HID, nicht STM32 oder RP2040

Die wahrscheinlich wichtigste frühe Entscheidung war die Wahl des Mikrocontrollers. Auf dem Tisch lagen mehrere Optionen:

Für ein Tool mit dem Anspruch „möglichst viele Features" hätten wir vermutlich zu einem STM32 gegriffen. Die Anforderungen waren aber andere. Der wichtigste Faktor war Wartbarkeit für eine breite Community:

Jeder Embedded-Entwickler, jeder fortgeschrittene Maker und ein großer Teil der Pentest-Community kennt die Arduino-IDE und die Keyboard.h-Bibliothek. Wer einen Custom-Payload schreiben will, kann das in zehn Minuten, ohne IDE-Setup, ohne Toolchain-Konfiguration, ohne Cross-Compiler-Hürden.

Der ATmega32U4 hat 32 KB Flash und Full-Speed-USB hardware-nativ in der MCU. Für die meisten realen Payloads ist das mehr als genug, ein typischer Awareness-Payload (Tastatureingaben plus ein paar Mausbewegungen) kommt mit deutlich unter 8 KB aus. Die 4 KB Bootloader, die nominell vom Flash abgehen, sind der Preis für den Komfort, dass jeder Stick ohne externen Programmer geflasht werden kann.

Was haben wir bewusst aufgegeben?

• Externe SPI-Flash-Anbindung und damit Mass-Storage-Mode für Drag-and-Drop-Payload-Management
• BLE/Funk-Trigger
• Hardwarebeschleunigte Krypto

Diese Features waren für die Hauptanwendungsfälle nicht kritisch. Wer sie braucht, baut ein anderes Tool, welches wir jederzeit entwickeln können. BadUSB zielt auf den Sweet Spot zwischen generischem Klon und Profi-Werkzeug.

Engineering Lesson Learned: Die Wahl des MCUs wird oft als rein technische Entscheidung diskutiert. Flash-Größe, Taktfrequenz, Peripherie. Tatsächlich ist sie genauso eine Community- und Toolchain-Entscheidung. Ein Chip, für den 90 % der Zielgruppe sofort eigenen Code schreiben kann, schlägt einen leistungsfähigeren Chip mit proprietärem Stack.

Designentscheidung 2: UDP-Formfaktor und seine Folgen

Die zweite zentrale Entscheidung betraf die Mechanik. Standard-USB-Sticks im Consumer-Bereich folgen dem UDP-Formfaktor (USB Disk in Plastic), einem De-facto-Standard mit Abmessungen von etwa 24 × 11 × 1,4 mm, der von praktisch allen chinesischen Gehäusefertigern unterstützt wird.

Die Alternative wäre ein eigenes, kundenspezifisches Gehäuse gewesen mit allen Vor- und Nachteilen, die das mit sich bringt: einzigartiges Branding, aber hohe Werkzeugkosten (mindestens 2.000–3.000 € Werkzeugkosten für Spritzguss), lange Lieferzeiten und keine Flexibilität bei Stückzahlen.

Wir haben uns für UDP entschieden, weil es BYTEBOLT eine wichtige Option erschließt: Custom-Branding ohne Custom-Tooling. Plastik-Slide-On-Gehäuse mit Firmenlogo, Aluminium-Shells, gravierte Ausführungen. All das ist über bestehende Lieferketten ab niedrigen dreistelligen Stückzahlen möglich. Für ein Awareness-Programm mit 50–200 personalisierten Sticks ist das genau das richtige Niveau.

Die mechanische Auslegung des PCBs musste entsprechend exakt eingehalten werden: 24 × 11 × 1,4 mm, definierte USB-A-Kontaktzunge, definierte Befestigungsausfräsungen. Das klingt simpel, hat aber in der Praxis zu mehreren Iterationen geführt um die perfekten Maße vom Fertiger zu bekommen.

Designentscheidung 3: Arduino-Bootloader statt Bare-Metal

Eine Frage, die in der Embedded-Community emotional diskutiert wird: Soll die Firmware „echtes" Embedded C sein, Bare-Metal mit direkten Register-Zugriffen, eigene HAL, möglicherweise FreeRTOS, oder darf man die Arduino-Abstraktion verwenden?

Wir haben uns bewusst für den Arduino-Bootloader und den darauf aufsetzenden Arduino-Stack entschieden. Die Gründe:

1. Die Zielgruppe schreibt Payloads, nicht Firmware. Der durchschnittliche Nutzer ist Pentester oder Awareness-Trainer, kein Embedded-Entwickler. Für ihn ist Keyboard.print("hello") lesbar, UDADDR = ... ist es nicht.
2. Die Performance reicht. Selbst die schnellsten Tastatur-Injection-Sequenzen sind im Bereich von wenigen Hundert Keystrokes pro Sekunde. Das ist für den Arduino-USB-Stack kein Engpass.
3. Die Bibliotheken sind kampferprobt. Keyboard.h und Mouse.h werden seit über zehn Jahren von Millionen Arduino-Boards genutzt. Edge-Cases bei Tastatur-Layouts, Modifier-Keys oder USB-Enumeration sind seit Jahren behoben.
4. Kein externer Programmer nötig. Jeder Stick lässt sich per USB neu flashen. Das macht Bulk-Provisioning und Field-Updates praktikabel.

Was wir auf der Firmware-Seite zusätzlich beigesteuert haben:

• Auslesen der 10-Byte-Fabrikations-ID aus der Signature Row des ATmega32U4 und ihre Bindung an den USB Device Descriptor, damit ist jede Einheit eindeutig identifizierbar, ohne zusätzlichen Chip auf der Stückliste.
• Custom-VID/PID-Spoofing-Funktionalität
• EEPROM-basierter Killswitch über den internen AVR-EEPROM
• Erweiterungen für Tastaturlayouts, die in der Standard-Arduino-Distribution nicht enthalten sind (z. B. Schweizer Layout de_CH)

Engineering Lesson Learned: Bei jedem Hardware-Projekt gibt es den Reflex, „noch einen Chip dazu" zu nehmen, um eine Anforderung zu erfüllen. Manchmal lohnt es sich, einen halben Tag in das Datenblatt der vorhandenen MCU zu investieren, die Signature Row und der interne EEPROM haben uns je einen zusätzlichen Baustein erspart.

Diese Erweiterungen sind im GitHub-Repository dokumentiert und stehen unter GPLv3.

Zwei PCB-Revisionen in der Hardware-Entwicklung: Was sich erst im Test gezeigt hat

Wir haben für BadUSB zwei PCB-Revisionen durchlaufen. Dieser Iterationsweg ist für Hardware-Projekte typisch und einer der Gründe, warum die Aussage „wir bauen Dir mal eben einen Prototyp" mit Vorsicht zu betrachten ist.

Revision 1: Funktionsnachweis

Elektrisch und funktional war Rev 1 voll lauffähig. Zwei mechanische Schwächen sind erst im Realbetrieb sichtbar geworden:

• Die Leiterplatte war einen Hauch zu breit für viele UDP-Standardgehäuse, der Stick ließ sich nur mit Druck einschieben.
• Die USB-A-Kontaktzunge zeigte schnellen Verschleiß: Nach wenigen Hundert Steckzyklen begannen die galvanisch beschichteten Kontaktflächen sichtbar abzunutzen.

Revision 2: Produktionsreif

Rev 2 ist die Version, die in Serie geht. Elektrisch hat sich zur Rev 1 wenig geändert, wir haben in dieser Iteration im Wesentlichen ESD-Schutzdioden auf den USB-Datenleitungen ergänzt, um Robustheit gegen Steckvorgänge mit statisch geladenem Personal sicherzustellen. Mechanisch wurden die Außenmaße korrigiert und das Plattierungs-Stack der Kontaktzunge auf höhere Steckzyklen ausgelegt.

Für die Fertigung haben wir mit Eurocircuits gearbeitet. Die Wahl war ein Kompromiss zwischen Stückkosten, Lieferzeit und der Möglichkeit, bei Qualitätsfragen kurze Wege zu haben. Eurocircuits wird auch von vielen Hobbyisten und Maker-Projekten verwendet, was uns wichtig war: Wer das offene Design selber nachbauen möchte, kann unsere Fertigungsdaten ohne Anpassung beim selben Partner einreichen. Außerdem war es uns wichtig, einen Partner aus der EU zu haben.

Zwischen „läuft auf dem Tisch" und „läuft zuverlässig in 1.000 Einheiten" liegen in der Regel mindestens zwei bis drei PCB-Iterationen, jeweils mit Neubestückung, Validierung und Lasttests.

Open-Source-Strategie: Was offen ist und was nicht

BadUSB ist Open Source, aber das heißt nicht, dass es kein Geschäftsmodell hat. Was unter GPLv3 steht:

• Schaltplan (Altium Designer)
• Firmware-Source-Code
• Beispiel-Payloads
• Dokumentation

Was bei BYTEBOLT und Embedded Solutions bleibt:

• Die Fertigungs- und Lieferketten
• Die Bulk-Customization-Erfahrung (Branding, Custom-VID/PID, vorinstallierte Payloads)
• Die Cybersecurity-Beratung, in deren Rahmen die Sticks oft eingesetzt werden
• Der Service rund um Awareness-Programme

Ein Wettbewerber kann das Design morgen kopieren, aber das ist der Sinn von Open Source. Was er nicht kopieren kann, ist die Erfahrung aus den letzten Jahren Pentest-Engagements: welche Payloads in welcher Branche funktionieren, und dass ein Pentest praktisch immer aus mehr als nur dem BadUSB besteht. Das ist der eigentliche Wert.

→ Die ausführliche strategische Begründung haben wir in einem eigenen Artikel zu Open-Source-Hardware als Geschäftsmodell durchgespielt.

Lessons Learned aus dem BadUSB-Engineering

Drei Punkte zum Mitnehmen für vergleichbare Hardware-Projekte:

1. Kompromisse beim MCU früh treffen, nicht spät

Die Versuchung, „doch noch BLE einzubauen" oder „doch externes Flash zu erlauben", taucht in jedem Projekt auf. Wer ihr nachgibt, baut am Ende ein anderes Produkt, mit anderen Stückkosten, anderer Zielgruppe, anderer Komplexität. Lieber von Anfang an zu einer klaren Positionierung committen.

2. PCB-Revisionen einplanen, nicht als Versagen werten

Zwei Revisionen sind für ein Hardware-Produkt normal und eher unterdurchschnittlich. Wer einem Auftraggeber verspricht, dass die erste Revision sofort produktionsreif sein wird, baut Erwartungen auf, die nicht haltbar sind.

3. Mechanik und Elektronik gemeinsam denken

Die Hälfte unserer Rev-1-Themen war an der Schnittstelle Mechanik/Elektronik, Steckzyklen, Gehäusepassung. Wer das Mechanik-Thema bis nach Rev 1 schiebt, verbrennt Zeit und Iterationen.

Fazit: Engineering ist Trade-off-Management

BadUSB ist ein vergleichsweise kleines Hardwareprojekt, ein USB-Stick mit einem 8-bit-Controller. Aber er zeigt gut, was eine professionelle Embedded-Auftragsentwicklung leistet: Aus einer fachlichen Anforderung wird ein durchdachtes, kompromissfähig spezifiziertes, fertigbares und wartbares Produkt. Die Engineering-Arbeit liegt dabei nicht in der maximalen Feature-Liste, sondern in den Trade-offs, die zur Anwendung passen.

Wenn Du selbst über ein Hardwareprojekt nachdenkst, sei es für interne Anwendungen oder als Produkt für Deine Kunden, sprich mit uns. Ein Erstgespräch von 30 Minuten ist unverbindlich und führt häufig schon zu einer klareren Sicht.

FAQ: häufig gestellte Fragen

Was ist ein BadUSB?

Ein BadUSB ist ein USB-Gerät, das sich am Host-Computer als Tastatur (HID-Keyboard) anmeldet und vorbereitete Tastatureingaben automatisch ausführt. Der Computer erkennt das Gerät als legitime Eingabequelle, wodurch sich Awareness-Tests, Penetrationstests und automatisierte Setup-Routinen realisieren lassen.

Warum verwendet das Projekt einen ATmega32U4 statt eines moderneren STM32?

Der ATmega32U4 hat USB-HID nativ, eine ausgereifte Arduino-Toolchain und eine sehr breite Community. Für die Anwendung HID-Emulation mit niedrigen Datenraten reicht der 8-bit-Controller vollständig aus. Ein STM32 würde mehr Performance bieten, aber die Eintrittshürde für Anwender, die eigene Payloads schreiben wollen, deutlich erhöhen.

Ist das BadUSB-Projekt legal?

Das Tool selbst ist legal. Sein Einsatz ist nur dann legal, wenn das Zielsystem dem Tester gehört oder eine ausdrückliche schriftliche Genehmigung vorliegt (typisch im Rahmen eines Pentest-Auftrags oder eines Awareness-Programms). BYTEBOLT führt diesen vertraglichen Rahmen als Teil seines Service.

Wie unterscheidet sich der Stick von den Konkurrenten?

Vergleichbare professionelle BadUSBs kosten etwa 120 $ pro Stück, nutzen eine proprietäre Skriptsprache und sind eine geschlossene Black Box. BadUSB liegt unter 30 $ Stückkosten, ist vollständig Open Source (GPLv3), nutzt Arduino-C als Skriptsprache und ist im UDP-Standardformat customizable.

Was bedeutet UDP-Formfaktor?

UDP (USB Disk in Plastic) bezeichnet das Standardformat für Consumer-USB-Sticks mit Abmessungen von etwa 24 × 11 × 1,4 mm. Praktisch alle chinesischen Gehäusefertiger unterstützen dieses Format, sodass Custom-Branding ohne eigene Werkzeugkosten möglich ist.

Kann ich das Tool für mein eigenes Awareness-Programm bestellen?

Den kommerziellen Vertrieb mit Customization, Bulk-Branding und Awareness-Service übernimmt BYTEBOLT unter dem Produktnamen BYTEBOLT One. Das Open-Source-Design steht unter github.com/LA-GL-Embedded-Solutions/BadUSB zum Selbstbau bereit.

Habt Ihr selbst die Fertigung übernommen?

Embedded Solutions hat die Engineering-Leistung erbracht. Hierzu zählen Bauteilauswahl, Schaltungsdesign, PCB-Layout, Firmware-Entwicklung, zwei Revisionen, Inbetriebnahme, Fertigungsbegleitung. Die Serienfertigung läuft über etablierte Fertigungspartner (PCBs über Eurocircuits). Bei eigenen Embedded-Projekten begleiten wir Auftraggeber von der Konzeptphase bis zur Serienfertigung und in der Serie.

Quellen und weiterführende Literatur

• Tischer, M. et al. (2016). Users Really Do Plug in USB Drives They Find. IEEE Symposium on Security and Privacy.
• Li, W. et al. (2025). ByteBait USB: a robust simulation toolkit for badUSB phishing campaign. Journal of King Saud University - Computer and Information Sciences, 37(5):91. DOI: 10.1007/s44443-025-00067-6