ESP32 Marauder · Volume 6
ESP32 Marauder Firmware Volume 6 — Bluetooth Subsystems
BLE advertising scan, BLE-spam variants (Sour Apple / Swiftpair / Easysetup / Fast Pair), AirTag detection, BT-classic on classic-ESP32 only
Contents
1. About this volume
Vol 6 covers Marauder’s Bluetooth subsystem. The headline takeaways:
- Mainline does BLE scan, period. Mainline does not ship BLE-spam attacks. The BLE-spam variants (Sour Apple, Swiftpair, Easysetup, Fast Pair) all live in Ghost ESP and Bruce — see Vol 7 for the fork landscape.
- AirTag detection is in Ghost ESP and Bruce; not in mainline.
- BT-classic scan requires classic-ESP32 silicon (ESP32-WROOM-32). ESP32-S3 is BLE-only. ESP32-S2 has no Bluetooth at all.
For tjscientist’s lineup, the operational implication is: BLE scan works on every Marauder host he owns; BLE-spam requires switching to Ghost ESP on the AWOK V3 (or a similar fork choice on the Cardputer ADV when Bruce is the firmware). BT-classic scan works on the AWOK V3 (classic ESP32 silicon) but not the Flipper WiFi Devboard (S2, no BT at all).
2. BLE radio and advertising channels
Bluetooth Low Energy uses 40 channels in 2.4 GHz:
- Channels 0–36 (2402–2478 MHz, 2 MHz spacing): data channels used after connection.
- Channels 37, 38, 39 (2402, 2426, 2480 MHz): advertising channels. Spaced across the band specifically to dodge Wi-Fi channels (Wi-Fi ch 1 / 6 / 11 cover 2412 / 2437 / 2462 MHz — BLE adv channels are between them).
All advertising traffic is on channels 37/38/39 only. A BLE scanner cycles through the three advertising channels — typically ~10 ms per channel — listening for advertising packets.
ESP32’s BLE radio is shared with Wi-Fi (single radio, coexistence-arbitrated). When Wi-Fi sniff is active, BLE scan is time-sliced; when both are on, capture rate drops on both. Marauder’s UI doesn’t expose the coexistence tradeoff — it just runs one mode at a time.
3. Advertising-packet anatomy
3.1 PDU types
A BLE advertising packet (PDU = Protocol Data Unit) header carries a PDU type — six values in the 4-bit field:
| Value | Type | Meaning | Marauder uses it for |
|---|---|---|---|
| 0000 | ADV_IND | Connectable, undirected. Generic “anyone can connect to me.” | The most common scan target |
| 0001 | ADV_DIRECT_IND | Connectable, directed at a specific target. | Rare in scan context |
| 0010 | ADV_NONCONN_IND | Non-connectable, undirected. Beacons (iBeacon, Eddystone). | iBeacon scan |
| 0011 | SCAN_REQ | Scanner asking advertiser for more info | Generated by Marauder when doing active scan |
| 0100 | SCAN_RSP | Advertiser’s response to SCAN_REQ — additional bytes | Captures longer advertising data |
| 0110 | ADV_SCAN_IND | Scannable but non-connectable | iBeacon / Eddystone variant |
ADV_IND, ADV_NONCONN_IND, and SCAN_RSP are the three that carry the bulk of useful information.
3.2 Payload structure — AD types
The advertising payload is a sequence of AD structures (Advertising Data structures), each carrying:
- Length (1 byte): bytes that follow in this AD structure (excluding the length byte itself)
- AD Type (1 byte): what this AD structure carries
- AD Data (Length−1 bytes): payload
Common AD Types (Bluetooth Core Specification Supplement § 1):
| AD Type | Hex | Name | Carries |
|---|---|---|---|
| 0x01 | Flags | LE-only / LE+BR-EDR / Discoverable mode | |
| 0x02–0x03 | Service UUIDs (16-bit, incomplete/complete) | Advertised GATT services | |
| 0x06–0x07 | Service UUIDs (128-bit, incomplete/complete) | Same, longer UUIDs | |
| 0x08 | Shortened local name | Display name (short form) | |
| 0x09 | Complete local name | Full display name | |
| 0x0A | TX Power Level | Transmit power in dBm (RSSI-distance estimation) | |
| 0x16 | Service Data | Service-specific data — used by Eddystone, Google Fast Pair | |
| 0xFF | Manufacturer Specific Data | The interesting one for fingerprinting (see § 3.3) |
Each AD structure is independent — a single advertising packet may contain multiple AD structures back-to-back, up to the 31-byte (legacy) or 254-byte (extended) total payload limit.
3.3 Manufacturer-specific data — the company-ID table
AD type 0xFF (Manufacturer Specific Data) is the catch-all for vendor proprietary advertising. Format:
| 1B Length | 1B AD Type 0xFF | 2B Company ID (LE) | N B vendor payload |The Company ID is a 16-bit value assigned by the Bluetooth SIG. Marauder’s BLE scan parses Company ID and labels the advertisement accordingly. Important Company IDs for fingerprinting:
| Company ID (LE bytes) | Vendor | What you’ll typically see |
|---|---|---|
| 0x004C (4C 00) | Apple | AirPods Continuity, AirTag offline-finding, iCloud Handoff, iOS device proximity |
| 0x0006 (06 00) | Microsoft | Swiftpair (Surface, Xbox controller), Windows Continuity |
| 0x0075 (75 00) | Samsung | Galaxy Easysetup, Galaxy Buds, SmartThings |
| 0x00E0 (E0 00) | Fast Pair, Nearby, Chromecast | |
| 0x0059 (59 00) | Nordic Semi | Generic Nordic chips (dev boards) |
| 0x004E (4E 00) | Linear (LG) | LG appliances |
| 0x0087 (87 00) | Garmin | Fitness devices |
The Apple, Microsoft, Samsung, and Google entries are the ones the BLE-spam attacks target — each OS recognizes its own vendor’s manufacturer-data subtypes and responds with native pairing prompts.
4. BLE advertising scan
4.1 What gets captured
Marauder menu: Bluetooth → Sniffer → BLE Scan.
Per advertising packet observed, Marauder records:
- BD_ADDR (Bluetooth Device Address, 6 bytes — analog of MAC for BLE)
- Address Type (Public / Random Static / Random Resolvable / Random Non-Resolvable)
- RSSI (signal strength, dBm)
- PDU Type (ADV_IND, ADV_NONCONN_IND, etc.)
- Manufacturer Data when present (Company ID + vendor payload preview, hex-dumped)
- Local Name when present (AD type 0x08 or 0x09)
- Service UUIDs when present
- Timestamp
Output (per packet, csv format):
BD_ADDR,AddrType,RSSI,PDU,CompanyID,LocalName,ServiceUUIDs,Timestamp
A4:5E:60:11:22:33,Public,-72,ADV_IND,0x004C,,AirPods Pro,2026-05-13T14:32:17
C0:25:5C:DE:AD:BE,Random Resolvable,-58,ADV_NONCONN_IND,0x004C,,iCloud handoff,2026-05-13T14:32:18
DC:A6:32:00:11:22,Public,-65,ADV_IND,0x0006,,Surface Pen,2026-05-13T14:32:194.2 Common manufacturer-data parses
Mainline parses a handful of Company ID prefixes into human-readable labels:
| Company ID + subtype | Labeled as | Typically seen on |
|---|---|---|
| 0x004C / 0x07 | ”Apple AirPods” | AirPods Pro / AirPods Max in advertising mode |
| 0x004C / 0x09 | ”Apple AirPlay” | Apple TV / HomePod / iPhone with AirPlay active |
| 0x004C / 0x10 | ”Apple Continuity / Handoff” | iCloud-connected iOS devices |
| 0x004C / 0x12 | ”Apple Find My” | AirTags, iPhone 13+ in offline-finding mode |
| 0x0006 / 0x03 | ”Microsoft Swiftpair” | Surface Pen, Xbox controller advertising for pairing |
| 0x0075 / various | ”Samsung Easysetup” | Galaxy Buds, SmartThings devices |
| 0x00E0 / 0x2C | ”Google Fast Pair” | Pixel Buds, Google Home setup |
Ghost ESP and Bruce add more parses (richer Continuity subtypes, more granular Find My identification). Mainline’s parses are intentionally conservative.
4.3 MAC randomization and what survives
BLE BD_ADDR has four address types:
- Public — globally-unique IEEE-assigned (analogous to a Wi-Fi MAC). Trackable.
- Random Static — random but stable across the device’s lifetime (or until factory reset).
- Random Resolvable — rotates every 15 minutes. Resolvable to a stable identity by anyone holding the device’s Identity Resolving Key (IRK) — the iCloud / Find My / etc. backends do this.
- Random Non-Resolvable — rotates frequently; not resolvable by any external party.
Modern iOS and macOS devices use Random Resolvable addresses by default for most advertising. Android uses similar randomization (varies by manufacturer). The effect: BD_ADDR alone is not a stable identity for most modern devices.
What still works for fingerprinting (similar to Wi-Fi probe-request analysis in Vol 4 § 3.2):
- Manufacturer-data fingerprint — the subtype + payload pattern is often device-specific (an AirPods Pro emits a different Continuity subtype than an iPhone). Cluster by manufacturer-data shape.
- TX power + RSSI distance proxy — same physical device emits at the same power; distance estimates correlate over time.
- Service UUID set — devices typically advertise a stable set of GATT service UUIDs.
- Timing patterns — advertising interval is often device-specific (AirPods Pro ~33 ms, iCloud handoff ~150 ms, etc.).
Vol 9 § 5 covers the post-capture analysis (the host-side clustering pipeline).
5. BLE-spam variants
5.1 The general primitive
The BLE-spam attack pattern, abstracted:
- Craft a synthetic advertising packet whose Company ID + subtype + payload the target OS recognizes as a pairing-prompt trigger.
- Broadcast that packet on BLE advertising channels (37/38/39) at high rate (typically every 100 ms or faster).
- Target devices within RF range receive the packet and react — typically by popping a native UI prompt offering to pair with the (non-existent) advertising device.
- Sustained spam = sustained prompts = denial-of-Bluetooth-UI on target devices.
Each OS has its own recognition pattern; § 5.2–§ 5.5 cover the four major variants. None of these are in mainline Marauder — all live in Ghost ESP and Bruce (see § 5.6 for why).
5.2 Sour Apple (iOS pairing-prompt flood)
The most-discussed BLE-spam variant. Targets iOS / iPadOS / watchOS.
Mechanism: synthesize Apple Continuity advertising packets (Company ID 0x004C) with subtypes that trigger iOS’s native “Connect to AirPods Pro?” / “Connect to Apple TV?” / “Set up iCloud Handoff” pairing prompts. iOS’s CoreBluetooth daemon processes the incoming Continuity packets and surfaces a pairing-modal in the OS.
When fired at high rate (10+ packets/sec) with rotating subtypes, the prompts arrive faster than the user can dismiss them. The Bluetooth UI becomes effectively unusable — every dismiss is followed by another prompt within ~100 ms.
Worst-case behavior: Sour Apple has been documented to cause iOS devices to lock up or reboot under sustained spam. The Notification subsystem appears to be the failure point — the rapid pairing-prompt surfacing exhausts internal queues. iOS 17.2+ added partial mitigation (rate-limiting the surfacing). iOS 18+ further hardened, but the attack still produces UI denial in current versions.
Why it matters operationally: brief Sour Apple bursts cause significant UI disruption to nearby iOS users with their Bluetooth on; sustained spam in a crowded area is a denial-of-iOS-UI to dozens of devices simultaneously.
Important caveat: the device-lockup edge case is real and has been documented (multiple reports of iPhones requiring force-reboot, a few claims of iPhones bricked into recovery mode requiring restore from backup — though never independently verified). The single largest reason Sour Apple isn’t in mainline Marauder (§ 5.6).
5.3 Swiftpair (Windows pairing-prompt flood)
Mechanism: synthesize Microsoft Swiftpair advertising packets (Company ID 0x0006, subtype 0x03) that match the pattern Windows 10+ recognizes for “new peripheral discovered, pair now?”
Windows displays a toast notification at the bottom-right with the synthetic device name. At high spam rate, toasts arrive faster than they auto-dismiss, eventually filling the notification queue.
Effects: less severe than Sour Apple — Windows handles the flood without UI lockup but the toast queue becomes congested for the spam duration. Annoyance attack, not a critical impact.
5.4 Easysetup / Samsung Galaxy
Mechanism: synthesize Samsung Easysetup advertising packets (Company ID 0x0075) matching the pattern Galaxy phones recognize for SmartThings / Galaxy Buds / Galaxy Watch pairing.
Effects: triggers the “Connect to [device]?” pairing prompt on Galaxy devices. Effectiveness varies wildly by Galaxy model and Android version — works reliably on Galaxy S22+ with One UI 5+ in lab tests; sporadic on older models.
The Easysetup payload format is less documented than Apple/Microsoft — Samsung hasn’t published the spec, and the Ghost ESP / Bruce implementations are based on packet captures from genuine Galaxy device pairings. Subtype identification is heuristic.
5.5 Google Fast Pair
Mechanism: synthesize Google Fast Pair advertising packets (Company ID 0x00E0, subtype 0x2C, or alternatively the Fast Pair service UUID 0xFE2C) matching the pattern Pixel / Android-with-GoogleServices recognizes.
Effects: triggers “Pair with [device]?” half-sheet on Pixel and Google-Services-enabled Android. Affects fewer devices than Easysetup because Fast Pair is opt-in per OEM.
5.6 Why BLE-spam isn’t in mainline
Koko has explicitly kept BLE-spam attacks out of mainline Marauder since they emerged in 2023. Two stated reasons:
- The iOS device-lockup edge case. Causing a stranger’s iPhone to reboot — or worse, brick into recovery mode — crosses a line the project doesn’t want to be on the wrong side of, both legally and reputationally. Even with caveats, shipping the attack in the canonical firmware would invite operators to fire it indiscriminately.
- Legal/RF posture. BLE-spam at high power for sustained durations is loud, easy to triangulate, and illegal in essentially every jurisdiction when fired without authorization. Mainline aims to stay within the “useful-with-discipline” envelope; the BLE-spam variants tempt indiscipline.
Ghost ESP and Bruce ship the variants because their maintainers made different calls. The operational implication for tjscientist: if BLE-spam is needed for an authorized engagement, switch the AWOK V3 to Ghost ESP. The migration is a flash-the-binary operation (Vol 7 § 8); SD-card content is mostly compatible.
6. AirTag detection (Bruce / Ghost ESP)
6.1 Apple Find My / offline-finding protocol overview
Apple AirTags (and iPhone 13+ in offline-finding mode) advertise on BLE using the Apple Continuity Find My subtype. The advertising packet carries a rotating public key — to anyone but Apple’s backend with the matching private key (the AirTag’s owner), the rotating key looks like random bytes.
The detection signature, however, is not random:
- Company ID 0x004C (Apple)
- Subtype byte 0x12 (Find My)
- Status byte (specific bit pattern indicating offline-finding mode)
- Public key bytes (rotating; cannot identify the specific AirTag but the presence of the format is identifiable)
- Advertising interval typically 2 seconds (consistent with Apple’s offline-finding spec)
The advertising-interval consistency is the strongest detection signal — the format alone is ambiguous (other Apple Continuity subtypes also use 0x12 in some contexts) but the every-2-seconds cadence is distinctive.
6.2 Detection signature
Bruce and Ghost ESP run a continuous BLE scan, filter for Apple Continuity Find My subtypes, and track BD_ADDRs that emit the pattern at the expected cadence over a minimum observation window (typically 30 seconds — enough to catch the advertising-interval consistency without false positives).
Output:
TIMESTAMP BD_ADDR RSSI INTERVAL LIKELY_DEVICE
2026-05-13T14:32:17 A4:5E:60:11:22:33 -68 ~2.0 sec AirTag (or iPhone Find My offline)
2026-05-13T14:32:19 C0:25:5C:DE:AD:BE -45 ~2.0 sec AirTag (or iPhone Find My offline)The detector cannot distinguish between an AirTag and an iPhone in offline-finding mode — both advertise the same format. Apple’s AirTag Anti-Stalking notification mechanism (the “AirTag detected traveling with you” notification on iPhones) uses additional context (specifically a separated AirTag — one not near its owner’s iPhone) that this detector doesn’t replicate.
6.3 Use cases — defense and offense
Defense (anti-stalking):
- Carry an AirTag detector (Bruce on the Cardputer ADV, or Ghost ESP on the AWOK V3) when entering an unfamiliar environment. Detect AirTags traveling along the route — if the same BD_ADDR appears at multiple stops, it’s plausibly attached to the operator’s vehicle / luggage / clothing.
- Detection-then-search workflow: detector identifies BD_ADDRs near you; iPhone’s Find My (if you have one) can do the precision-location ping for tags not bound to your Apple ID.
Offense:
- Knowing what’s tracking nearby has counter-intelligence value. Before a sensitive engagement, sweep for AirTags / unfamiliar Find My emitters in the area. Anomalous tags suggest surveillance.
- Awareness during travel — knowing the tag landscape in an environment informs where to plant or look for tracking.
The defensive case is the more common use. Apple’s “AirTag detected traveling with you” notification works only on iPhones that have been near the same separated AirTag for hours; the Marauder-derived detector works in real-time over seconds.
7. BT-classic scan (ESP32-classic only)
ESP32-classic (ESP32-WROOM-32) has BT classic + BLE 4.2; ESP32-S3 has BLE 5.0 only; ESP32-S2 has no Bluetooth at all. BT-classic scan only runs on classic-ESP32 hosts.
For tjscientist’s lineup: the AWOK Dual Touch V3 (classic ESP32 × 2) supports BT-classic scan; the Flipper WiFi Devboard (S2) does not; the Cardputer ADV / hypothetical Marauder v6.1 / Mini (all S3) do not.
BT-classic scan mechanics:
- Inquiry procedure — the scanner broadcasts on the inquiry channels; nearby BT-classic devices in discoverable mode respond with their BD_ADDR + Class of Device (CoD) + Extended Inquiry Response (EIR).
- EIR — analogous to BLE’s AD structures; carries the device name and supported services.
- Class of Device (CoD) — a 24-bit field that broadly identifies the device class (phone, headset, computer, etc.).
Output (per discovered device):
BD_ADDR,Name,CoD,Class,RSSI,Timestamp
84:DD:20:11:22:33,JBL Flip 5,0x240414,Audio/Speaker,-58,2026-05-13T14:32:17
C8:69:CD:44:55:66,Bose QC35,0x240404,Audio/Headset,-62,2026-05-13T14:32:19BT-classic is increasingly rare in real-world targets — most consumer devices (phones, peripherals) ship BT 5.0 / 5.1 / 5.2 silicon that defaults to BLE for discoverability. BT-classic discoverable devices are typically older Bluetooth speakers, vintage headsets, some industrial equipment.
The use case is mostly nostalgic / completeness — BT-classic scan is a Marauder feature because the firmware supports it on classic-ESP32 hardware, not because it’s a high-value attack surface in 2026.
8. BT output formats
| Mode | Output file | Format | Notes |
|---|---|---|---|
| BLE Scan | ble_<timestamp>.csv | csv | One line per packet observed; columns per § 4.1 |
| BLE Scan | ble_<timestamp>.pcap | pcap with link-type LINKTYPE_BLUETOOTH_LE_LL | Raw advertising packets; less common |
| AirTag Detect (Bruce/Ghost ESP) | airtags_<timestamp>.csv | csv | One line per detected AirTag candidate |
| BT-classic Inquiry | btclassic_<timestamp>.csv | csv | One line per discovered BT-classic device |
For host-side analysis, csv is the standard output. pcap is occasionally useful for replay with bluetoothctl or BLE protocol analyzers like Frontline.
9. Workflow recipes
Recipe A — BLE site survey
Goal: catalog BLE devices in an area.
- Marauder menu: Bluetooth → Sniffer → BLE Scan.
- Run for 10-30 minutes, walking the site at moderate pace.
- Stop. SD output:
ble_<ts>.csv. - Host: load csv into Python / Excel. Cluster by Company ID, count unique BD_ADDRs per vendor. Visualize manufacturer-data subtype distribution.
Typical yield: 50-150 unique BD_ADDRs in a 20-minute walk at a moderate-traffic site (mall, coffee shop, conference). Apple devices typically dominate (40-60%); Microsoft / Samsung / Google fill most of the rest.
Recipe B — AirTag sweep (Ghost ESP / Bruce)
Goal: detect AirTags traveling along the operator’s route.
- Switch Marauder host to Ghost ESP or Bruce (Vol 7 § 8 migration).
- Menu: Bluetooth → AirTag Detect (Ghost ESP) or BLE → AirTag Scanner (Bruce).
- Start at trip origin. Periodically check the screen — new entries indicate AirTags appearing in your environment.
- Cross-reference at multiple stops — BD_ADDRs that appear at multiple stops along your route are plausibly traveling with you.
- Stop. SD output:
airtags_<ts>.csv.
This is a continuous-background workflow — leave the AirTag detector running during travel; review the csv when stopped.
Recipe C — BLE-spam authorized red-team test (Ghost ESP)
Goal: test target organization’s BLE pairing-prompt response in a controlled engagement.
- Switch host to Ghost ESP.
- Menu: Bluetooth → Attack → Sour Apple (or Swiftpair / Easysetup / Fast Pair per target OS).
- Time-box the test — 30-60 seconds is plenty to demonstrate the effect. Longer is uncalled-for.
- Document timestamps + RF location + target affected.
- Stop. Long-form BLE-spam outside an authorized window is a discipline failure.
The legal/ethical posture (Vol 11 § 2) applies in full — BLE-spam against the public is illegal in essentially every jurisdiction.
10. Resources
Standards
- Bluetooth Core Specification 5.3: https://www.bluetooth.com/specifications/specs/core-specification-5-3/
- Bluetooth Core Specification Supplement: https://www.bluetooth.com/specifications/specs/core-specification-supplement-10/
- Company Identifiers (the canonical list): https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers/
Apple Continuity reverse-engineering
- furiousMAC continuity research (community): https://github.com/furiousMAC/continuity
- Apple’s published BLE manufacturer-data partial: https://developer.apple.com/library/archive/documentation/Bluetooth/Conceptual/BluetoothBestPractices/
Find My / AirTag research
- Who Tracks the Trackers? (academic paper, 2022): https://www.usenix.org/conference/usenixsecurity22/presentation/heinrich
- Apple’s own AirTag Anti-Stalking documentation: https://www.apple.com/airtag/
- OpenHaystack (open-source Find My implementation): https://github.com/seemoo-lab/openhaystack
Forks for BLE-spam and AirTag detection
- Ghost ESP repo: https://github.com/Spooks4576/Ghost_ESP
- Bruce repo: https://github.com/pr3y/Bruce
Forward references in this series
- Fork comparison + migration mechanics (mainline → Ghost ESP for BLE-spam): Vol 7 § 4 + § 8
- Host-side BLE analysis (clustering, manufacturer-data fingerprinting): Vol 9 § 5
- Operational posture / legal posture for BLE-spam: Vol 11
This is Volume 6 of a twelve-volume series. Next: Vol 7 is the fork landscape deep dive — mainline vs Ghost ESP vs Bruce vs Bad Pinguino, feature-by-feature, with the migration mechanics for switching between them.