c5-wardriver¶
C5 Wardriver v1.1 — justcallmekoko's ESP32 survey board, runs Marauder-family firmware
Vendor: justcallmekoko (community hardware) · class: badgelife
Status: supported — the identifiers and setup recipe are believed correct.
Maintainer-verified 2026-08-26 on Pop!_OS 22.04: Flashed, attached and enumerated; identifier, product string and serial captured with scripts/identify-device.sh. Firmware output was confirmed over UART, so the board is running. Its screen did not display correctly, which is recorded as a known problem rather than a USB finding.
What it is¶
A firmware for ESP32 boards that turns them into a handheld 2.4 GHz survey tool, sold and built by several people as a self-contained device with a screen and battery. The hardware is ordinary ESP32; the Marauder identity is the firmware.
What you can do with it¶
Scan for Wi-Fi access points and stations and for Bluetooth Low Energy advertisements, capture probe requests, and log what is present on the band around you. The firmware also includes active features — deauthentication frames, beacon spam, and captive-portal impersonation — which transmit rather than listen. Stating that plainly is deliberate: nobody should discover it by surprise, and operating those features against networks you do not own or are not authorised to test is a separate matter from installing a flasher.
Setup¶
Install the badgelife class packages, join dialout and plugdev, then log out and back in — group membership does not apply to an existing session. Plug the board in and run esptool chip_id, which reports what the chip actually is and is the quickest way to resolve an ambiguous silkscreen. tio /dev/ttyACM0 opens a console at 115200 8N1 (this board supplies no distinguishing descriptor, so it gets no /dev/badge-* symlink — see the NO SYMLINK note above). Firmware images come from upstream and are flashed with esptool; nothing here flashes anything on its own.
Known problems¶
Observed 2026-08-26 on the maintainer's v1.1 board: firmware runs and reports over UART, but the screen did not display correctly. That is a board or firmware matter rather than anything Linux does, and it is recorded here because the symptom -- a device that looks dead but is not -- is exactly what someone will search for. Check UART output before assuming the board is faulty. Several hardware builds share the name and differ in USB bridge, screen and button layout, so instructions written for one board may not match another. A board whose USB is provided by its own firmware disappears from /dev while being reflashed, which is expected rather than a fault. ModemManager holds a newly attached serial device for around twenty seconds on many desktops, which looks exactly like a dead board; the fix is a udev rule tagging the device so ModemManager ignores it, which Hammunition's hardware role will emit once the udev generator is written (it is not yet).
How it identifies itself¶
| USB id | What | Confirmed | Node |
|---|---|---|---|
1a86:55d3 |
WCH CH343 USB-serial bridge, as used on this board | yes | serial |
⚠ 1a86:55d3 is not unique to this device (kernel_generic_driver; also used by: any board using a WCH CH343 bridge). Debian 13 modules.alias binds 1a86:55d3 to cdc_acm, and it is on the generated ambiguity list. usb.ids calls it "USB Single Serial", which is a function rather than a product, and the board supplies no manufacturer string and no product string of its own -- so there is nothing beyond the per-unit serial to match on.
Access and permissions¶
Group membership required: dialout, plugdev — added at install, applies at next login.