---

7.1 About this Volume

This volume covers everything Bruce does inside the 2.4 GHz industrial-scientific-medical band, which in practice means two very different radio subsystems glued to the same firmware. The first is the Bluetooth Low Energy (BLE) radio that is integrated on-die into every ESP32 and ESP32-S3 the firmware runs on — this is native silicon, requires no add-on module, and is available on essentially every board in the device matrix (see Vol 2 for the full supported-hardware table). The second is the Nordic Semiconductor nRF24L01+ transceiver, an external SPI-attached module that only a subset of boards carry — Bruce’s own PCBs (RF REAPER, Bruce PCB V2, Pirata), and a few third-party devices wired for it. These are distinct radios doing distinct jobs, and conflating them is the most common error in understanding what a given Bruce board can and cannot do on 2.4 GHz.

The treatment here is deliberately category-level. This is offensive-security firmware, and in keeping with the posture established for the ESP32 Marauder Firmware deep dive and the WiFi Pineapple deep dive elsewhere in this hub, the volume describes what class of thing each subsystem does, the hardware and protocol constraints that bound it, and the legal and consent framing that governs its use. It does not reproduce the on-device menu tree, and it does not give step-by-step operating procedures for running a specific attack. An engineer reading this should come away understanding the mechanism and its limits; an operator wanting a procedure should read the on-device help and the official wiki under an authorization that covers the activity.

A note on honesty about feature maturity runs through this volume. Bruce’s menus list several 2.4 GHz features — Mousejack being the headline example — that are present as menu entries but are not yet functional or are incomplete in the firmware as shipped. This volume flags those explicitly rather than describing them as working capabilities, because a deep dive that reports a stub as a feature is worse than useless. Where the brief and the source disagree on maturity, maturity is reported as the brief states it.

7.2 The 2.4 GHz band on an ESP32, and what Bruce actually touches

The 2.4 GHz ISM band (nominally 2400–2483.5 MHz in most regions) is one of the most crowded pieces of spectrum in civilian use. Wi-Fi occupies it in 20/40/80 MHz channels, classic Bluetooth and BLE hop across 79 and 40 channels respectively, Zigbee and Thread sit in it, and a long tail of proprietary 2.4 GHz protocols — wireless mice and keyboards, RC toys, some medical telemetry — share the same air. An ESP32 can see and transmit in this band through three mechanisms, and Bruce uses two of them directly.

 2.4 GHz ISM band as Bruce sees it
 ┌───────────────────────────────────────────────┐
 │ 2400.............................. 2483.5 MHz │
 ├───────────────┬───────────────┬───────────────┤
 │ Wi-Fi (L2) │ BLE (native) │ nRF24 (ext.) │
 │ ────────── │ ─────────── │ ─────────── │
 │ 802.11 b/g/n │ 40 adv/data │ 126 1-MHz ch │
 │ on-die radio │ on-die radio │ SPI module │
 │ │ │ (not on all │
 │ → see Vol 6 │ → §3–§5 │ boards) │
 └───────────────┴───────────────┴───────────────┘
 same antenna real estate, different stacks

Wi-Fi (802.11) is handled by the ESP32’s native Wi-Fi MAC and is the subject of Vol 6 — it is not repeated here. BLE is handled by the ESP32’s native Bluetooth controller and the firmware’s BLE stack, and is the subject of §3 through §5. The nRF24 transceiver is a separate chip that Bruce drives over SPI, and it opens a window onto the band that the ESP32’s own radios cannot reach cleanly — the raw 1 MHz channel grid that proprietary 2.4 GHz devices use. That window is the subject of §6.

The practical consequence for an operator choosing a board is this: BLE features work everywhere; nRF24 features work only where an nRF24 module is present and wired. A bare M5Stick or a plain CYD can do every BLE feature in this volume. Only a board with an E01-2G4M27SX (or equivalent) nRF24 module — RF REAPER, Bruce PCB V2, Pirata — can do the nRF24 jammer and 2.4 GHz spectrum view. The capability matrix in Vol 2 has an explicit NRF24 column precisely because this distinction is load-bearing.

One further ESP32-specific constraint shapes what the native-BLE features can do: Wi-Fi and BLE share the same physical radio on a single-radio ESP32. The chip time-slices between the two stacks rather than running them truly concurrently, which is why a board doing heavy Wi-Fi work (a sustained capture, an Evil Portal under load — see Vol 6) and heavy BLE work at the same time will see both degrade, and why Bruce’s menu structure treats a Wi-Fi operation and a BLE operation as distinct activities rather than a single simultaneous assault across both. An engineer evaluating a claimed “do everything at once” capability on a single-radio ESP32 should discount it accordingly; the silicon enforces a time-division discipline the firmware cannot wish away. The ESP32-C5 boards (newly supported, stabilizing — the 1.16.1 notes include C5 BLE crash fixes) and the dual-radio designs in the wider ESP32 family relax this somewhat, but the single-radio M5 and CYD boards that most operators will reach for first do not.

7.3 Bluetooth Low Energy — the scan and enumerate class

The foundational BLE capability, and the one with the least legal weight, is passive observation: scanning for advertising packets and enumerating the devices that emit them. Every BLE peripheral that wants to be discoverable — fitness trackers, earbuds, beacons, smart-home sensors, item trackers, phones in discoverable mode — periodically broadcasts advertising packets on the three primary advertising channels (37, 38, 39). A BLE scanner simply listens on those channels and reports what it hears: the advertised device address, the advertised name if present, the received signal strength (RSSI), and the advertising payload, which may include service UUIDs, manufacturer-specific data, and transmit-power hints.

Bruce’s BLE scan is a straightforward implementation of this. It presents discovered devices in a list with their addresses, names, and signal strengths, and RSSI gives a crude proximity sense — stronger signal, closer device, all else equal. This is the same class of capability a phone’s Bluetooth settings screen exposes, and the same class the AirTags deep dive and the SquachWatch deep dive elsewhere in this hub use for tracker-detection work. It is, on its own, a benign observational tool: receiving a broadcast that a device is deliberately emitting into public space is not an attack, and BLE scanning underlies legitimate counter-surveillance (finding an unwanted tracker) as readily as it underlies reconnaissance.

The subtlety that an engineer should internalize is address randomization. Modern BLE devices — certainly all current iOS and Android devices, and most privacy-conscious peripherals — rotate their advertised Bluetooth address on a schedule (typically every 15 minutes) specifically to defeat long-term tracking by passive scanners. The address Bruce reports is therefore usually a resolvable private address, not a stable hardware identifier, and following a device across a venue by its advertised address will fail the moment it rotates. This is a deliberate privacy feature of the BLE specification, and it bounds what passive scanning can accomplish. Devices that do advertise a stable address — some cheap beacons, some older peripherals, and notably some item-trackers in certain states — are the exception, and that exception is exactly what makes tracker-detection work (the premise of the AirTags and SquachWatch dives) possible.

Callout — scanning is receive-only. BLE scanning transmits nothing (beyond the low-level link requests a connection would need, which a pure scan does not issue). It is passive reception of broadcasts intended for public consumption. The legal and consent questions in §8 attach to the active features below, not to scanning.

7.4 Bad BLE — Ducky-style HID over Bluetooth

The first active BLE capability of real consequence is Bad BLE, and understanding it requires understanding the attack class it belongs to rather than the specific keystrokes it sends. Bad BLE is keystroke injection over Bluetooth: the ESP32 presents itself to a target as a BLE Human Interface Device (a wireless keyboard), and once the target accepts the pairing it injects a scripted sequence of keystrokes at machine speed. This is the BLE analogue of the USB “BadUSB” / Rubber Ducky technique — the same payload language, the same threat model, a different transport.

The payload language is the Ducky Script lineage. Bruce reads Ducky-style scripts (the STRING, DELAY, GUI, ENTER, modifier-key vocabulary documented at length in this hub’s Ducky Script deep dive) and replays them as BLE HID reports. An engineer who has read the Ducky Script dive already understands the payload semantics completely; Bad BLE changes only the delivery layer — from a wired USB enumeration to a wireless BLE pairing. The firmware can present as a BLE keyboard on boards that support the BLE keyboard role (notably the Cardputer and T-Deck, which the source calls out explicitly for the BLE/USB keyboard roles), and the same mechanism underlies both the “BLE keyboard” convenience feature (use the board as a real wireless keyboard) and the Bad BLE offensive feature (use it as a hostile wireless keyboard).

 Bad BLE = Ducky Script payload ──over──► BLE HID transport
 ┌────────────────┐ pair as ┌──────────────────────────┐
 │ ESP32 running │ BLE keyboard │ target host (phone, │
 │ Bruce, holding │ ────────────► │ tablet, PC) that │
 │ a.txt payload │ inject HID │ accepts the pairing │
 │ from SD card │ reports │ and trusts the "kbd" │
 └────────────────┘ └──────────────────────────┘
 payload = same language as the USB Rubber Ducky

The critical constraint — and the reason Bad BLE is operationally harder than its USB cousin — is the pairing step. A USB BadUSB device enumerates the instant it is plugged in and begins typing with no user consent, because USB HID enumeration is automatic and trusted by design. BLE HID is not automatic: the target must accept the pairing, which on a modern phone or PC means a user action (tapping “pair,” sometimes confirming a passkey). That consent gate means Bad BLE cannot silently attack a locked, unattended device the way a plugged-in USB Ducky can; it needs either a cooperative/tricked user, an already-paired-and-trusted state, or a target with weak pairing policy. This makes Bad BLE a social-engineering-adjacent technique more than a drive-by one, and it is the single most important thing to understand about its real-world reach.

The authorization posture for Bad BLE is identical to any keystroke-injection technique: it drives a keyboard on someone else’s computer, and doing that without explicit written authorization is unauthorized access under the computer-misuse statutes surveyed in the Hacker Tradecraft deep dive and summarized in ../_shared/legal_ethics.md. It belongs in the same “authorized engagement or own hardware only” bucket as the USB HID devices in the Ducky Script dive.

7.5 BLE advertising spam — the nuisance/DoS class

The second active BLE capability is BLE advertising spam, and it is best understood as a denial-of-service / nuisance-flood class rather than an intrusion. The technique exploits a design decision in several vendors’ proximity-pairing user experiences: when a phone sees an advertising packet formatted as a particular vendor’s “nearby accessory” or “fast-pair” beacon, it pops a pairing or setup prompt automatically, to make legitimate accessory onboarding frictionless. If a transmitter floods the air with a rapid stream of forged such beacons, each with varied parameters, nearby phones display a continuous barrage of pop-ups — a usability denial of service that can make the target device difficult to use until the transmitter stops or the target moves out of range.

Bruce organizes this capability by target-platform class, and the brief and source enumerate the classes it covers:

Table 1 — Bruce organizes this capability by target-platform class, and the brief and source enumerate the classes it covers

Spam class	Target ecosystem	Observable effect on a nearby device
iOS	Apple proximity-pairing pop-ups	Rapid accessory/“setup” prompts
Windows	Windows Swift Pair prompts	Repeated “add a device” toasts
Samsung	Samsung accessory onboarding	Galaxy accessory pop-ups
Android	Android Fast Pair prompts	Nearby-device pairing cards
”Spam All”	All of the above interleaved	Mixed barrage across platforms

Version 1.16.1 specifically added more Samsung OUIs to the BLE Spam set, which is the kind of maintenance that keeps the Samsung class effective as the vendor’s beacon formats evolve — a detail worth noting because it shows the feature is actively maintained rather than a one-time curiosity.

Three things bound this capability and an engineer should hold all three. First, it is transmit — it actively radiates forged advertising packets, which is categorically different from the passive scanning of §3 and carries real regulatory and consent weight (see §8). Second, its effect is nuisance, not compromise: it does not pair, does not inject, does not exfiltrate, and does not persist; it degrades the usability of nearby devices for as long as it runs and no longer. Third, it is a moving target: vendors patch the underlying pop-up behaviour, restrict which beacon formats trigger a prompt, and rate-limit the prompts, so the real-world effect of any given spam class varies with the OS version of the devices in range — a current phone may show far less than an older one, or nothing at all. It is, in short, a demonstration of a specification weakness with a short and shrinking half-life, not a reliable weapon.

Callout — this is consent-sensitive by its nature. BLE spam affects every susceptible device in radio range, not a chosen target. You cannot scope it to “only the device I am authorized to test,” because the transmitter does not know or care which phones are nearby. That property alone places it firmly in the “bench, shielded, or explicitly-consented-group-only” category. Running it in a public space degrades bystanders’ devices without their consent, which is the definition of the nuisance it is named for.

There is a defensive and research value to understanding this class that is worth stating, because it is the reason a deep dive documents it at all rather than ignoring it. The pop-up-flood behaviour exists because the proximity-pairing user experience trusts unauthenticated advertising packets; demonstrating the flood (on a bench, to a consenting audience) is how one shows a vendor’s onboarding flow needs rate-limiting and authentication, and it is why vendors have progressively hardened these flows. The counter-surveillance dives in this hub (AirTags, SquachWatch) rely on the same advertising-packet visibility for benign ends. The capability is a demonstration of a specification weakness, and its legitimate home is the bench where that weakness is studied — not the coffee shop where it is merely inflicted.

7.6 The NRF24 subsystem — jammer and 2.4 GHz spectrum

The nRF24L01+ is a cheap, ubiquitous 2.4 GHz transceiver originally designed for simple proprietary wireless links — RC vehicles, wireless sensors, the first generation of wireless mice and keyboards. Its relevance to Bruce is that it can tune to any of 126 one-megahertz channels across the band and transmit or receive raw packets, giving the firmware a view of, and a transmitter in, the parts of 2.4 GHz that the ESP32’s Wi-Fi and BLE radios abstract away. On Bruce this subsystem is strictly an add-on: the nRF24 is an SPI-attached module present only on boards wired for it (RF REAPER’s E01-2G4M27SX, Bruce PCB V2, Pirata), and the firmware exposes two capabilities on it — a 2.4 GHz spectrum view and a jammer.

 nRF24L01+ on SPI ──► 126 selectable 1-MHz channels (2400–2525 nominal)
 ┌───────────────┐
 │ RF REAPER / │ RX mode → "carrier detect" per channel →
 │ PCB V2 / │ a crude spectrum/energy sweep
 │ Pirata board │
 │ (SPI module) │ TX mode → continuous/hopping carrier →
 └───────────────┘ a wideband jammer across the band

The 2.4 GHz spectrum view uses the nRF24’s received-power-detector / carrier-detect across its channel grid to build a live energy map of the band. Sweeping the chip through its channels and reading signal presence at each produces a coarse “what is busy right now” picture — a histogram or scrolling display showing which parts of 2.4 GHz carry energy. This is genuinely useful diagnostic information: it shows Wi-Fi channel congestion, identifies a hopping Bluetooth device as energy smeared across the band, and reveals an active proprietary transmitter as a persistent spike. It is receive-only and benign, and it is the one nRF24 feature an engineer can use freely on their own bench.

The jammer is the opposite in every respect. Driving the nRF24 to transmit a continuous or rapidly-hopping carrier across the band’s channels denies that spectrum to every legitimate user within range — Wi-Fi, Bluetooth, and any proprietary 2.4 GHz link all degrade or fail while the jammer runs. Bruce exposes both a saturating approach and a hopping approach (the firmware’s RF jammers come in full and intermittent flavours; the same philosophy carries to the 2.4 GHz jammer). This is a blunt, indiscriminate denial-of-service tool, and it is illegal to transmit in essentially every jurisdiction outside a licensed, shielded test environment. It is treated at length in §8 and in the sub-GHz jammer discussion of Vol 8, because the legal line is the single most important fact about it.

Callout — nRF24 jamming is not targeted. Like BLE spam, the jammer radiates into shared public spectrum and affects every user of that spectrum in range, with no ability to scope to a single authorized target. Unlike BLE spam, its effect is total denial rather than nuisance, and it will knock out safety-relevant and third-party systems (someone else’s Wi-Fi, someone else’s Bluetooth medical device) indiscriminately. There is no “authorized target only” configuration of a broadband jammer. The only lawful venue is a shielded enclosure or a licensed anechoic/test facility.

7.7 What is not yet done — Mousejack and the honest menu

Bruce’s NRF24 menu lists Mousejack as an entry, and the on-device menu and the project README both show it. The brief for this deep dive — verified against the official project on 2026-10-16 — records Mousejack as not-yet-done: present as a menu entry but not a working, reliable capability in the firmware as it ships. This volume reports it that way, and the distinction matters enough to spend a paragraph on.Mousejack, as a technique, is the 2017 Bastille research class: many wireless mice and keyboards that use nRF24-family proprietary links either do not encrypt their link or implement it weakly, which allows an attacker with an nRF24 transceiver to inject keystrokes into the victim’s computer by impersonating the victim’s own mouse/keyboard dongle. It is, in effect, keystroke injection over a proprietary 2.4 GHz HID link — conceptually a cousin of Bad BLE (§4) and USB BadUSB, but against the gap in cheap wireless-peripheral security. A working Mousejack implementation is a potent capability. Bruce’s menu entry signals intent to support it; the firmware’s current maturity does not deliver a reliable implementation.

The engineering reason this is hard, and why a menu entry is easier to ship than a working feature, is worth stating. Reliable Mousejack requires fast channel-hopping to find and lock onto the target dongle’s channel, precise reconstruction of the vendor’s proprietary packet format (which varies by manufacturer and model), and correct timing to inject before the dongle’s keep-alive window closes. The nRF24L01+ is capable of the radio work, but the firmware-side state machine to do it reliably across the range of vendor dongles is substantial, and it is exactly the kind of feature that is easy to stub as a menu item and hard to finish. Reporting it as “present and working” would be an error; reporting it as “intended, not yet reliable” is the honest state.

The same honesty principle applies to two other menu entries that recur across this deep dive: FM spectrum / traffic-announcement hijack on FM-equipped boards (Vol 8) and RFID tag emulation (Vol 9) are likewise menu-present but incomplete, and each volume flags its own. The pattern — a feature-dense menu that runs ahead of feature-complete firmware — is characteristic of a fast-moving community project with a very broad surface, and an engineer evaluating Bruce should treat the menu as a map of ambition and the release notes as the map of reality. The v1.16.1 release notes (WPA3 detection, a Brucegotchi handshake fix, a Station-Deauth fix, more Samsung OUIs, ESP32-C5 BLE crash fixes) are the better guide to what actually works in a given build than the breadth of the top-level menu.

Table 2 — 7. What is not yet done — Mousejack and the honest menu

2.4 GHz feature	Class	Maturity (per brief, 2026-10-16)
BLE scan / enumerate	Passive recon	Working
Bad BLE (HID over BLE)	Keystroke injection	Working (gated by pairing)
BLE spam (iOS/Win/Samsung/Android/All)	Nuisance / DoS	Working; effect varies by target OS
nRF24 2.4 GHz spectrum	Passive diagnostic	Working (nRF24 boards only)
nRF24 jammer	Denial of service	Working (nRF24 boards only); TX illegal
Mousejack	HID injection over nRF24	Not yet done — menu entry, incomplete

7.8 Consent, region and the legal envelope for this band

The 2.4 GHz band is unlicensed for compliant low-power use, and that single word — compliant — carries the entire legal envelope. Unlicensed does not mean unregulated. A device operating in the ISM band must respect power limits, must not cause harmful interference, and in most jurisdictions must be a type-certified device; deliberately generating interference (a jammer) or impersonating other radios to disrupt them falls outside every ISM allowance and into the categories regulators treat most severely.

The features in this volume fall into three distinct legal tiers, and collapsing them is the mistake to avoid:

• Passive reception (BLE scan, nRF24 spectrum view) receives broadcasts and ambient energy. It transmits nothing and is lawful essentially everywhere, which is why counter-surveillance use (the AirTags and SquachWatch dives) rests on it. This tier is unrestricted on your own bench and in the field alike.
• Targeted active use against authorized systems (Bad BLE) injects into a specific device. It is lawful only against hardware you own or are explicitly, in writing, authorized to test. It is unlawful unauthorized-access the instant it touches a system outside that authorization — the same line the Ducky Script and Hacker Tradecraft dives draw around all keystroke injection.
• Indiscriminate transmission (BLE spam, nRF24 jammer) radiates at whoever is in range. Jamming is flatly illegal to transmit in nearly every jurisdiction — in the United States under the Communications Act, with the FCC treating signal jammers as prohibited devices; comparable prohibitions exist across the EU, UK, Canada, and Australia. BLE spam is not “jamming” in the regulatory sense but it is a nuisance transmission that affects non-consenting bystanders and, run in public, invites the same harmful-interference analysis plus the obvious consent problem.

Callout — the one rule that covers all of it. Transmit only into spectrum you are authorized to occupy, against devices you own or are authorized to test, in a venue where no third party’s radios are affected without their consent. For the jammer, that venue is a shielded enclosure. For BLE spam, it is an isolated bench or a group that has explicitly consented to the demonstration. For Bad BLE, it is your own device or a signed engagement scope. When in doubt, the shielded bench is always defensible and the open air rarely is. The regional-RF-law and authorization rules in ../_shared/legal_ethics.md are binding on every feature in this volume.

Regional variation deserves one more sentence because it bites in practice: the exact band edges, the permitted power, and even which protocols are allowed differ between regulatory domains (FCC, ETSI, and the various national regimes), and a feature that is a lawful bench experiment in one country may be an offence to even transmit in another. An operator moving a Bruce board across borders carries the regulatory burden with it.

7.9 Summary and cross-references

Bruce’s 2.4 GHz story is two radios with very different reach. The native BLE stack — available on every board — delivers passive scanning (benign, the backbone of tracker-detection), Bad BLE keystroke injection (potent but gated by the BLE pairing-consent step, unlike its USB cousin), and advertising spam (a nuisance/DoS demonstration of vendor proximity-pairing weaknesses, with a short half-life and an unavoidable bystander-consent problem). The external nRF24 subsystem — only on boards that carry the module — delivers a genuinely useful passive spectrum view and a blunt, illegal-to-transmit jammer. And the menu’s Mousejack entry is a statement of intent rather than a working feature, the headline example of a feature-dense menu running ahead of feature-complete firmware.

For the Wi-Fi (802.11) half of the 2.4 GHz band, see Vol 6, which covers recon, Evil Portal, handshake capture, deauthentication, the MITM class, Brucegotchi, and the full connectivity stack. For the sub-GHz, IR, and FM radios — and the detailed treatment of the full-vs-intermittent jammer philosophy that the nRF24 jammer shares — see Vol 8. For the Ducky Script payload language that Bad BLE replays, see this hub’s Ducky Script deep dive; for the native-ESP32 Wi-Fi/BLE specialist that Bruce credits and reuses, see the ESP32 Marauder Firmware deep dive, whose BLE-spam and scanning coverage this volume complements rather than duplicates. The device matrix that tells you which board carries an nRF24 module is in Vol 2. And the binding legal framing for every transmit feature named here is ../_shared/legal_ethics.md.