ESP32 Marauder · Volume 11
ESP32 Marauder Firmware Volume 11 — Operational Posture: Detection, Regional/Legal, Power, Thermal
What a Wi-Fi IDS sees, regional channel/regulatory considerations, battery sizing, thermal under continuous TX, chain of custody, when NOT to use Marauder
Contents
1. About this volume
Vol 11 is the operational-posture synthesis — considerations that apply across every attack and scan in the preceding volumes. Detection, legal, power, thermal, RF discipline, evidence handling, and the cases where reaching for Marauder is wrong.
Treat this volume as a checklist before any non-trivial engagement. Many of the points are repeated from earlier volumes — that’s deliberate. Vol 11 is where the operational implications converge.
The single most important point in this volume: own the airspace. Only fire Marauder attacks on RF you own (your own lab, your own network) or have explicit written authorization for. Everything else in this volume is downstream of that.
2. Detection signatures — what a Wi-Fi IDS sees
2.1 Per-attack signature reference
Each Marauder-class attack has identifiable on-the-wire signatures. A competent Wi-Fi IDS (Cisco DNA Center, Aruba ClearPass, open-source like Kismet) catches these reliably.
| Attack | Signature | Detection ease |
|---|---|---|
| Deauth (Vol 5 § 2) | Burst of deauth frames sourced from one MAC (the spoofed AP), unusual reason-code patterns, frame rate ~50/sec | Trivial — every IDS has a “deauth flood” rule by default |
| Beacon spam (Vol 5 § 3) | Rapid unique-SSID beacons from many random MACs on one channel; sustained > 10 unique SSIDs / sec | Trivial — beacon-anomaly rules common |
| Probe spam (Vol 5 § 4.1) | High-rate probe requests from random MACs; SSID-list cyclical pattern | Moderate — less commonly tuned-for than deauth/beacon |
| Karma probe-response (Vol 5 § 4.2) | Probe-responses from non-AP MAC at non-AP frame rate; impossible-coverage SSIDs (matching every probe asked) | Moderate — requires correlation across probe-req and probe-resp |
| Evil Portal SoftAP (Vol 5 § 5) | New open SSID matching known Marauder defaults; unusual MAC OUI; HTTP Server: header reveals firmware | Trivial — appears as a new AP in any scan, IDS-flaggable |
| BLE-spam Sour Apple (Ghost ESP) | Rapid Apple-Continuity-subtype advertising at >10/sec rate; rotating BD_ADDRs but identical subtypes | Moderate — requires BLE-aware IDS |
| BLE-spam Swiftpair (Ghost ESP) | Rapid Microsoft-Continuity-subtype adv; same pattern as Sour Apple | Moderate — Windows IDS less common |
| EAPOL handshake capture (Vol 4 § 6) | Pure passive — no signature. Only the deauth that induced the rejoin is detectable | Undetectable in passive mode — but the inducing deauth is loud |
| PMKID capture (Vol 4 § 5) | Pure passive — no signature whatsoever | Undetectable |
PMKID and EAPOL capture are the only operations Marauder does that don’t ship a signature. Everything that attacks (deauth, spam, Evil Portal) is loud.
2.2 Frame-rate fingerprinting
Marauder’s default frame rates are characteristic:
- Deauth: ~50 frames/second to one target
- Beacon spam: ~10-50 beacons/second per channel
- Probe spam: ~20-50 probe requests/second
- BLE-spam (Ghost ESP): ~10-30 advertisements/second
These rates are higher than legitimate AP/client behavior — a real AP sends ~10 beacons/second on its assigned channel; Marauder’s synthetic beacons exceed that on a single MAC. An IDS comparing observed-rate-vs-expected-rate will trigger on Marauder attack traffic immediately.
Ghost ESP’s runtime-tunable rates (Vol 7 § 4.1) let the operator slow attacks to legitimate-AP rates, reducing the rate-fingerprint. But the content still gives them away — see § 2.3.
2.3 Source-MAC fingerprinting
Marauder uses random source MACs for attacks by default (RandomMAC setting in settings.txt, Vol 8 § 6). The randomization is intentionally crude — full 6-byte random, no OUI awareness. This makes attack traffic identifiable by:
- Non-allocated OUI prefix — half the time, the randomized OUI doesn’t match any registered manufacturer. Legitimate hardware has a registered OUI.
- Per-frame MAC rotation at high rate — beacon spam emits beacons from a different random MAC each frame. No real AP behaves this way.
- Locally-administered bit cleared incorrectly — proper MAC randomization sets the LA bit (bit 1 of byte 0). Marauder’s quick-random often doesn’t, producing MACs that should be in legitimate OUIs but aren’t.
Smarter randomization (use a registered OUI from a major manufacturer; set the LA bit appropriately) is possible via firmware modification (Vol 10 § 5) but mainline doesn’t do it.
2.4 Triangulation considerations
A Marauder attack is RF traffic from a fixed location (the device on the operator). Multiple IDS sensors with directional antennas can triangulate the source to within a few meters in ~30 seconds. In a corporate environment with WIDS (Wireless IDS) coverage:
- Sustained attack → triangulation → security team dispatched.
- One-shot brief attack → may go unnoticed if below the IDS rate-threshold but still recorded.
For tjscientist’s bench-only / authorized-engagement use, triangulation isn’t a threat — but knowing it exists informs how loud you can afford to be in shared-space environments.
2.5 Why stealth-Marauder is mostly an oxymoron
Combining the above:
- Frame anatomy is standard 802.11 (Vol 4 § 2.2) — every IDS knows it.
- Frame rates exceed legitimate device rates.
- Source MACs are crude-random — fingerprintable.
- Attack content (beacon-spam SSID list, deauth-to-AP-from-AP, Evil Portal SoftAP) is by definition anomalous.
- The single radio means the attacker must be physically close (< 50 m typical).
- BLE attacks are even more localized (< 10 m typical for reliable spam).
The reasonable posture: assume any Marauder attack will be detected by a competent IDS within 30 seconds. Plan accordingly — short attack durations, narrow targeting, and engagement authorization that covers detection. Stealth is not a defense; authorization is.
For pure-passive operations (PMKID + EAPOL capture without inducing handshakes via deauth), Marauder is genuinely covert — but the moment you turn on an attack, you’re loud.
3. Regional / legal posture
This volume is not legal advice. Consult a lawyer for jurisdiction-specific questions. The below is general orientation.
3.1 US (FCC + CFAA + ECPA)
In the United States:
- FCC 47 CFR Part 15 governs unlicensed 2.4 GHz operation. ESP32 hardware operating within Part 15 limits (which it does at +20 dBm) is legal to operate as RF hardware.
- CFAA (18 USC § 1030) prohibits unauthorized access to computer systems. Attacking a Wi-Fi network you don’t own without authorization is a CFAA violation even if you don’t successfully break in. Penalties up to 10 years for some violations.
- ECPA (18 USC §§ 2510-2522) prohibits interception of electronic communications. Capturing Wi-Fi traffic from a network you don’t own without authorization is an ECPA violation. Penalties similar to CFAA.
- State laws add additional restrictions in many states. California, New York, and Texas have particularly aggressive computer-crime statutes.
For US operators: never attack a network you don’t own without written authorization from the owner. Verbal permission is insufficient (and forgotten). Email confirmation is a minimum.
3.2 EU (GDPR + national)
In the EU:
- GDPR treats captured probe-request data, BLE advertising data, and Evil Portal credentials as personal data. Capturing and processing it without consent is a GDPR violation (penalties up to 4% of global annual revenue for businesses, smaller for individuals).
- National computer-crime laws in each EU member state generally mirror CFAA/ECPA-equivalent restrictions on unauthorized access and interception.
- Network code in some countries (Germany, France) treats unauthorized radio transmission with elevated penalties even for spectrum that’s otherwise unlicensed.
GDPR is the load-bearing concern for European operators — even passive capture in public spaces can be a GDPR violation if the captured data is processed or stored.
3.3 Other jurisdictions
Most jurisdictions have analogous laws. Notable variations:
- UK: Computer Misuse Act (1990) + Investigatory Powers Act (2016). Both apply.
- Australia: Cybercrime Act + Telecommunications (Interception and Access) Act. Penalties severe.
- Canada: Criminal Code § 342.1 (unauthorized computer use).
- Japan: Act on Prohibition of Unauthorized Computer Access (1999) + Radio Act. Both apply.
- China / Russia / restrictive regions: assume any unauthorized RF transmission has criminal exposure; carrying a Marauder device into the country may itself be a customs issue.
International travel with Marauder: think carefully about customs declarations. The hardware is benign on paper (ESP32 dev board with TFT) but the firmware is not. Wipe SD card content before crossing borders.
3.4 Authorized engagements
When operating under authorization (employer-sanctioned pentest, contracted red-team engagement, security research):
- Get the authorization in writing. Signed by an owner of the system being tested. Specify dates, IP ranges, RF coverage scope, attacks permitted.
- Document your activity in real-time. Timestamps, target BSSIDs, attacks fired, what was captured.
- Stay within scope. Authorization to test “the conference Wi-Fi” doesn’t authorize testing “any nearby Wi-Fi” — narrow targeting (Vol 5 § 6) keeps you in scope.
- Stop when stopped. If you’re observed and asked to stop, comply and produce authorization paperwork. Continue only if the authorizing party confirms.
The Hack Tools _shared/legal_ethics.md has the project-wide posture.
4. Power profile and battery sizing
4.1 Per-mode current draw
Approximate current draw for the major modes (ESP32-S3 N16R8 on a Marauder v6.1 / Mini reference; classic ESP32 similar order of magnitude):
| Mode | Current (mA) | Notes |
|---|---|---|
| Idle (menu, no scan) | ~60-80 mA | Display backlight is bulk of this |
| Wi-Fi scan (probe sniff, hopping) | ~120-150 mA | Radio in RX |
| Deauth attack | ~250-400 mA | Burst TX at +20 dBm |
| Beacon spam | ~250-400 mA | Same — sustained TX |
| Probe spam | ~250-400 mA | Same |
| Evil Portal idle (no clients) | ~150-200 mA | SoftAP beaconing |
| Evil Portal with active client | ~200-300 mA | + HTTP serving + DHCP |
| BLE scan | ~80-120 mA | BLE is lower-power than Wi-Fi |
| BLE-spam (Ghost ESP) | ~200-300 mA | Sustained BLE adv TX |
| Display off (deep sleep — not used by mainline) | ~10 µA | Theoretical low-power mode; mainline doesn’t go there |
Display backlight is the single biggest constant draw. Lowering brightness (settings.txt Brightness key, Vol 8 § 6) materially extends battery life.
4.2 Brownout mechanics on classic ESP32
Classic ESP32-WROOM-32 has an aggressive brownout detector that trips at ~2.7 V. During TX-spam (deauth, beacon-spam), the supply rail dips momentarily — if the dip exceeds ~2.7 V threshold + hysteresis, the SoC resets.
Symptoms: TX attack “stops working” — actually, the SoC reset, rebooted, and lost menu state. Often misdiagnosed as RF or attack issue.
Causes:
- Aged / weak LiPo battery — internal resistance has grown; can’t sustain peak TX current.
- Cheap USB cable — voltage drop under load.
- microSD writing simultaneously with TX — additive current draw.
- Aggressive low-DC-headroom buck converter — some cheap dev boards have ~3.4 V minimum supply with no headroom.
Mitigations:
- Use a fresh LiPo (>= 2000 mAh) of known provenance.
- Use a known-good charge cable (Anker, OEM-bundled).
- Increase the SoC’s brownout-threshold tolerance via
sdkconfig(advanced —CONFIG_ESP_BROWNOUT_DET_LVL_SEL_5for more permissive). Vol 10 § 3 covers the rebuild. - Avoid concurrent SD writes during TX-heavy attacks.
ESP32-S3 has improved brownout behavior — less aggressive threshold and better PMU. The S3-based Marauder v6.1 / Mini rarely shows brownout under attack.
4.3 Battery-sizing recommendations
Per-use-case battery sizing:
| Use case | Recommended capacity | Expected runtime |
|---|---|---|
| Quick site survey (< 30 min) | 500-1000 mAh | 4-8 hrs idle, 1-2 hrs scan |
| Standard engagement (1-2 hr) | 1500-2000 mAh | 8-12 hrs idle, 3-5 hrs scan, 1-2 hrs TX |
| Sustained deployment (4-8 hr) | 3000-4000 mAh | 16+ hrs idle, 6-10 hrs scan, 3-4 hrs TX |
| All-day passive observation | 5000+ mAh or USB power | All day; consider power bank pass-through |
For the AWOK Dual Touch V3: the standalone Dual Board Battery Backpack ($37, BYO-LiPo, see AWOK V3 deep dive § 8) accommodates 18650 cells from ~1500-3500 mAh. Sustained Marauder runs benefit from 3000+ mAh cells.
5. Thermal under continuous TX
ESP32 silicon thermal limits: junction temperature absolute max ~150 °C; throttles starting at ~125 °C; sustained operation rated to 85 °C.
Under continuous TX-spam, the SoC and the on-module PA warm noticeably. Symptoms after 10-15 minutes of sustained beacon-spam / deauth:
- Case warm to touch (palpable warm, not burning)
- TX power slightly decreased (PA derating under high temp)
- Eventually, throttling causes intermittent TX failures
Practical mitigation:
- Don’t enclose the device fully during sustained TX — ventilation helps. The AWOK V3’s vented enclosure and the Cardputer ADV’s open metal sides both help; some 3D-printed Marauder Mini cases are sealed-plastic and trap heat.
- Take breaks — 15 minutes TX, 5 minutes idle / scan, repeat. Restores PA performance.
- Lower TX power if available (
esp_wifi_set_max_tx_power()in firmware — mainline doesn’t expose at runtime). Trades range for thermal margin. - Cooler ambient — TX in a 35 °C room is much harder than in a 15 °C room.
For brief attacks (< 5 min) thermal is non-issue.
6. RF discipline and antenna considerations
6.1 Range and RF output
ESP32 reference design at +20 dBm (100 mW):
- PCB-trace antenna (Marauder Mini, most DIY): line-of-sight range 30-50 m
- U.FL + external whip (Marauder v6.1): line-of-sight range 100-150 m with 5 dBi antenna; 200+ m with directional
- Through walls: range halves through one wall, halves again through two
- Reflections / multipath in indoor environments: effective range typically 30-50% of free-space
Marauder’s RF output is fundamentally limited by ESP32 silicon — no external PA available. For longer range, use HackRF (Vol 1 § 2.3) or a Linux laptop with a high-gain Wi-Fi adapter.
6.2 Antenna choice and orientation
- Stock vendor antenna (typically 5 dBi rubber-duck) — good for most engagements.
- Higher-gain omni (8-12 dBi) — extends range in horizontal plane; reduces overhead coverage.
- Directional patch (Yagi-style) — extends range in one direction; narrow beamwidth.
- Orientation: keep antenna vertical for matching client devices’ antenna orientation (most consumer devices use vertical polarization).
For BLE: antenna orientation matters less; BLE adv channels are dispersed enough that polarization is forgiving.
6.3 Co-existence with other RF in the area
Marauder’s RF is loud on 2.4 GHz. In a congested environment:
- Neighbor Wi-Fi networks will see signal degradation during your attack. This is more than annoying — it can cause legitimate users to lose connectivity. Don’t operate in residential areas without authorization.
- Bluetooth headsets, mice, keyboards also share 2.4 GHz and will be affected. Same caveat.
- ZigBee / Thread / Matter devices likewise share 2.4 GHz.
The “own the airspace” rule (§ 1) covers this — only operate where the RF impact is yours to make.
7. Chain of custody for capture data
(See Vol 8 § 9 for the SD-card-level workflow; Vol 9 § 8 for the Evil Portal cred-log triage.)
For captures intended as engagement deliverables:
At capture-time:
-
Document target BSSIDs, dates, justification, authorization.
-
SD card extracted with timestamp and provenance documentation.
-
Hash on extraction:
sha256sum /mnt/sd/marauder/pcaps/*.pcap > /tmp/captures_<engagement>.sha256
At transfer:
- Encrypted archive only (tar + age, or gpg-encrypted zip).
- Out-of-band hash verification (text channel separate from the archive transfer).
At engagement close:
- Deliverable: encrypted archive + report + chain-of-custody documentation.
- Source SD card: secure-erase per Vol 8 § 9.
- Retain only what the engagement scope authorizes; purge bystander data with documentation.
For BLE/probe-request captures that include third-party data, even authorized engagements should minimize retention. The data has indefinite re-identification potential; the operational value decreases rapidly past 48 hours.
8. When NOT to use Marauder
The inverse of Vol 1 § 6 — scenarios where reaching for Marauder is the wrong call:
| Scenario | Why Marauder is wrong | Better alternative |
|---|---|---|
| Need 5 GHz Wi-Fi | Marauder hardware is 2.4-only | ESP32-C5 (when AWOK ships) / Wired Hatters Banshee / Linux laptop + monitor-mode adapter |
| Need stealth | Marauder is overt; loud on the air | Pure passive — laptop with monitor-mode adapter in deep RX-only mode |
| Need sustained engagements (8+ hr) | Battery sizing, thermal limits, frame-rate-fingerprinting | Wi-Fi Pineapple Mark VII or laptop-based bettercap |
| Need Wi-Fi 6 / 6E features | Marauder hardware doesn’t support them | Modern monitor-mode adapter (Intel AX series) + Linux |
| Need polished client-engagement workflow | Marauder is a hacker tool, not a product | Wi-Fi Pineapple’s web UI for the engagement-deliverable shine |
| Need cracking power | Marauder doesn’t crack | Host with GPU (Vol 9 § 4) |
| In a hostile jurisdiction | Legal exposure | Don’t carry the device into the jurisdiction |
| Educational demo with minors / students | The attack ethics matter more than the tool | Use packet-capture-only setup in a controlled lab; never demo attacks against external networks |
| Just learning what Wi-Fi looks like | Marauder’s UI obscures the underlying protocol | Wireshark + a monitor-mode adapter teaches more |
The recurring theme: Marauder is the right tool for a narrow band of use cases — pocketable, handheld, authorized 2.4 GHz Wi-Fi/BLE testing in environments where its limitations (range, thermal, detection) are acceptable. Outside that band, other tools are usually better.
9. The pre-engagement checklist
Before any non-trivial engagement, verify:
- Written authorization from the system/network owner, signed and dated, covering the planned attack scope.
- Date range specified in authorization includes today.
- RF coverage scope specified (target SSIDs, target BSSIDs, geographic area).
- Attacks permitted listed (deauth + handshake capture? Evil Portal? BLE-spam? Be specific).
- Stop condition defined (time limit, signal-of-completion).
- Hardware ready: charged battery, fresh SD card formatted FAT32, known-good firmware.
- Settings configured: target BSSID(s) loaded, region code matches venue, MAC randomization on, Evil Portal SSID configured if Evil Portal is in scope.
- Logging plan: where will captures end up? Who has access?
- Sanitization plan: how is SD content erased post-engagement?
- Bystander mitigation: targeted attacks only (Vol 5 § 6 narrow targeting), not broadcast.
- Discovery plan: what do you do if security observes you? (Stop, produce authorization, document.)
If any item isn’t checked, the engagement isn’t ready.
10. Resources
Legal references
- US CFAA: 18 USC § 1030 (Computer Fraud and Abuse Act)
- US ECPA: 18 USC §§ 2510-2522 (Electronic Communications Privacy Act)
- US FCC 47 CFR Part 15: https://www.fcc.gov/general/title-47-code-federal-regulations
- EU GDPR: https://gdpr.eu/
- UK Computer Misuse Act: https://www.legislation.gov.uk/ukpga/1990/18
Engagement-rules references
- OSSTMM (Open Source Security Testing Methodology Manual): https://www.isecom.org/OSSTMM.3.pdf
- NIST 800-115 (Technical Guide to Information Security Testing): https://csrc.nist.gov/publications/detail/sp/800-115/final
- PTES (Penetration Testing Execution Standard): http://www.pentest-standard.org/
Hack Tools shared policies
../../../_shared/legal_ethics.md— Hack Tools project-wide posture
Technical references for the operational topics
- ESP32 datasheet (current draw, thermal, brownout): Espressif’s official docs
- 802.11 management-frame anatomy: IEEE 802.11-2020 § 9
- WIDS detection-rules examples: Kismet documentation, Aruba/Cisco public docs
Forward / cross references
- Pre-attack scan/recon: Vol 4
- Attack-specific signatures by attack: Vol 5 (Wi-Fi), Vol 6 (BLE)
- SD-side capture handling: Vol 8
- Host-side capture analysis: Vol 9
- Custom firmware modifications for stealth (smarter MAC randomization, rate limiting): Vol 10 § 5
- Cheatsheet condensation: Vol 12
This is Volume 11 of a twelve-volume series. Next: Vol 12 is the laminate-ready cheatsheet — the printable-and-carry synthesis of menu maps, attack quick-refs, SD layouts, channel charts, hashcat commands, and troubleshooting flows from across the series.