---

10.1 About this Volume

This final volume steps back from the feature subsystems of Vols 6–9 to place Bruce in its ecosystem: how it compares to the other ESP32 offensive-security firmwares an engineer might flash on the same hardware, how its PCB and hardware ecosystem is structured, how it relates to the other CYD-based firmwares tracked in this hub, who builds and maintains it, and — the question the whole deep dive has been building toward — how to decide whether Bruce is the right firmware for a given board and goal, and how to operate it lawfully. It closes with a laminate-ready legal/ethics cheatsheet and a glossary spanning the whole dive.

The comparison section is written to complement this hub’s ESP32 Marauder Firmware deep dive, not to duplicate it. The Marauder dive already contains a thorough fork-landscape treatment (mainline Marauder vs Ghost ESP vs Bruce vs Bad Pinguino); this volume covers the same landscape from Bruce’s vantage point, with the detail that is specific to understanding Bruce’s position, and defers to the Marauder dive for the Marauder-internal detail. Where the two dives touch the same facts, this one states Bruce’s side and points across.

10.2 Bruce vs Marauder vs Ghost ESP vs Bad Pinguino

The crucial framing fact, and the one most often gotten wrong in casual discussion, is that Bruce is not a Marauder fork. It is an independent multi-tool firmware that credits and borrows features from several upstream projects — ESP32Marauder (justcallmekoko), M5Stick-Nemo (n0xa), Launcher (bmorcelli), and Evil-M5Project (7h30th3r0n3) — but it is its own codebase with its own architecture (the HAL “new core” of Vol 4) and its own enormous feature surface. Treating Bruce as “Marauder with extras” misreads both projects.

The clearest way to hold the landscape is by layer and breadth:

Table 1 — The clearest way to hold the landscape is by layer and breadth

Firmware	Layer / base	Breadth	Best understood as
Bruce (pr3y / BruceDevices)	Arduino-layer “micro-OS”; HAL across many boards	Widest — Wi-Fi, BLE, sub-GHz (CC1101), IR, RFID/NFC, NRF24, FM, scripting, connectivity, WebUI	The broadest-hardware, most feature-dense multi-tool
ESP32 Marauder (justcallmekoko)	Arduino-layer	Focused — 802.11 Wi-Fi + BLE at L2	The Wi-Fi/BLE L2 specialist; depth over breadth
Ghost ESP	ESP-IDF-native (lower-level, leaner)	Moderate; research-grade capture/streaming	The IDF-native, lower-level capture/orchestration tool
Bad Pinguino	Marauder-family fork (Spanish-language)	Marauder-adjacent	Out of scope here; see the Marauder dive

Bruce vs Marauder. Both are Arduino-layer firmwares, and Bruce openly reuses Marauder’s work. The difference is scope. Marauder is a specialist: it does 802.11 Wi-Fi and BLE at the link layer with depth and polish, and it does little else — no CC1101 sub-GHz, no IR, no RFID/NFC, no scripting. Bruce is a generalist: it does the Wi-Fi/BLE work (crediting Marauder for parts of it) and adds sub-GHz, IR, RFID/NFC, NRF24, FM, a JavaScript interpreter, a connectivity stack, and a WebUI, across a far wider range of boards. The honest comparison is not “which is better” but “specialist vs generalist” — Marauder is the sharper instrument in its narrow domain, Bruce is the one device that touches every radio in the hub. For an engineer who wants the deepest, most battle-tested 802.11 tooling on an ESP32, the Marauder dive is the reference; for one who wants the broadest single firmware, this one is.

Bruce vs Ghost ESP. Ghost ESP is built on ESP-IDF (Espressif’s native SDK) rather than the Arduino layer, which makes it lower-level and leaner, and it leans toward research-grade capture — packet streaming suitable for Wireshark, multi-device orchestration. Bruce wins decisively on breadth and hardware support; Ghost ESP’s argument is architectural leanness and IDF-native capture fidelity. (This positioning comes from a Ghost-ESP-leaning source rather than a head-to-head benchmark, and should be read as orientation, not measurement.)

Bad Pinguino. A Spanish-language Marauder-family fork named in this hub’s Marauder dive. There is no reliable comparison data specific to Bruce, and it is out of scope here; the Marauder dive is the place it belongs.

Callout — the one-line positioning. Marauder = the Wi-Fi/BLE specialist. Ghost ESP = the IDF-native, lower-level capture tool. Bruce = the broadest, most feature-dense generalist, touching every radio across the most boards. They are not competitors so much as different points on a specialist-to-generalist axis, and an engineer who owns compatible hardware can flash whichever fits the task of the day.

A small decision graph captures the choice without belabouring it:

 What is the primary goal on this ESP32 board?
 │
 ├─ Deepest, most proven 802.11 Wi-Fi / BLE L2 work ────► ESP32 Marauder
 │
 ├─ IDF-native capture, Wireshark streaming, low-level ─► Ghost ESP
 │
 ├─ One firmware touching Wi-Fi + BLE + sub-GHz + IR +
 │ RFID/NFC + NRF24 + FM + a scripting platform ──────► Bruce
 │
 ├─ Serious RFID *emulation* of captured credentials ───► Chameleon Ultra (device)
 │
 └─ Lab-grade RFID key recovery / protocol analysis ────► Proxmark3 (device)

The graph makes the generalist/specialist trade explicit: Bruce is the answer whenever breadth on one board is the goal, and something sharper is the answer whenever a single domain at maximum depth is the goal. Because flashing is reversible and the hardware overlaps, an operator is not locked in — the same CYD or M5 board can carry Marauder one week and Bruce the next, which is itself an argument for understanding all of them rather than committing to one.

10.3 The PCB and hardware ecosystem — Smoochiee and the CYD firmwares

Bruce is unusual among ESP32 firmwares in having a first-party hardware ecosystem, not merely a list of supported third-party boards. The project ships its own PCB designs — the RF REAPER devkit and the Bruce PCB V2, plus the M5Stick-targeted Ultramarines and the Pirata (all detailed in Vol 3) — and these are designed around the firmware rather than the firmware being ported to them. The PCB design work is credited to Smoochiee and TH3_KR4K3N, and the “Bruce PCB V2 Smoochiee” is sold through Elecrow, giving the project a retail hardware path alongside its software.

 BruceDevices ecosystem
 ┌───────────────────────────────────────────────────────┐
 │ FIRMWARE (AGPL-3.0) HARDWARE (CERN-OHL-P-2.0) │
 │ pr3y + contributors Smoochiee, TH3_KR4K3N │
 │ ─────────────────── ──────────────────────── │
 │ • runs on many 3rd-party • RF REAPER devkit │
 │ boards (M5/LILYGO/CYD/ • Bruce PCB V2 (Elecrow) │
 │ Elecrow — Vol 2) • Ultramarines (M5Stick) │
 │ • + the project's own PCBs • Pirata (M5StickC Plus) │
 │ • shop.bruce.computer │
 └───────────────────────────────────────────────────────┘

The licence split reflects this dual identity and is worth stating precisely because it is easy to get wrong: the firmware is AGPL-3.0, the hardware/PCB designs are CERN-OHL-P-2.0, and third-party components are enumerated in the repo’s THIRD_PARTY.md. This is not an MIT project and not vaguely “open source” — the AGPL on the firmware is a strong copyleft with a network-use provision, and an engineer building on Bruce’s code inherits those obligations. (By contrast, several of the CYD firmwares discussed in §4 use permissive MIT licensing, which is one of the ways to tell the projects apart at a glance.)

10.4 The CYD-firmware family — SquachWatch, HaleHound and the shared-flasher caveat

Bruce runs on the “Cheap Yellow Display” family of ESP32 boards — the JCZN CYD-2432S028 and its relatives (Vol 2) — and so do several other firmwares tracked in this hub: SquachWatch (Talking Sasquach / skizzophrenic) and HaleHound each have their own deep dives here, and all three are “CYD firmwares” in the sense that an operator can web-flash them onto the same ubiquitous ~$15 board. This shared hardware substrate, and a shared flashing mechanism, is the real and verifiable relationship — and it is also the thing most easily overstated into a false claim of shared code. The distinction must be drawn carefully.

What is shared and verifiable: all three projects are distributed through browser-based ESP Web Tools flashers (the esptool-js lineage — Bruce’s own flasher at bruce.computer/flasher is one instance, and the pattern is standard across the CYD-firmware world). A user flashes any of them the same way — open the vendor’s web flasher, connect the board over serial, click flash. This is a shared flashing lineage and ecosystem, and it is why the three dives sit as peers in the hub. It is a shared delivery mechanism, nothing more.

What is NOT established: that HaleHound is a code-descendant of Bruce. It is not, on the evidence. HaleHound is a documented fork of CiferTech’s ESP32-DIV (MIT-licensed), with its own lineage; what it shares with Bruce and SquachWatch is the ESP Web Tools flashing lineage and the CYD-firmware ecosystem, not a common codebase. Stating or implying that HaleHound “grew out of Bruce” would be an unverified and almost certainly incorrect claim.

Callout — shared flasher ≠ shared code. Bruce (AGPL-3.0, pr3y/BruceDevices), SquachWatch, and HaleHound (a fork of CiferTech’s ESP32-DIV, MIT) are peers in the same CYD-firmware ecosystem and share the ESP Web Tools web-flasher lineage — a common way of getting firmware onto the board. That is a shared mechanism, not a shared codebase. HaleHound forks ESP32-DIV, not Bruce. Keep the relationship stated as “same ecosystem / shared flashing lineage,” never as a code fork.

The practical value of this framing to an engineer is navigational: these three dives describe three different firmwares that happen to target overlapping cheap hardware and install the same friendly way. Choosing among them is a feature-and-purpose decision (Bruce = broadest offensive multi-tool; see the SquachWatch and HaleHound dives for their respective detection-and-scan focuses), not a “which fork of the same thing” decision, because they are not forks of the same thing.

Table 2 — 4. The CYD-firmware family — SquachWatch, HaleHound and the shared-flasher caveat

Firmware	Lineage	Licence	Flashing	Role in hub
Bruce	Independent (credits Marauder et al.)	AGPL-3.0	ESP Web Tools (bruce.computer/flasher)	Broadest offensive multi-tool
SquachWatch	Talking Sasquach / skizzophrenic	(see SquachWatch dive)	ESP Web Tools	Surveillance-device detector
HaleHound	Fork of CiferTech ESP32-DIV	MIT (ESP32-DIV)	ESP Web Tools	CYD offensive-firmware (own dive)

10.5 The community — contributors, licence and project health

Bruce is a large, active, community project, and its health metrics are part of what makes it a reasonable firmware to invest time in. At the time of writing it carries roughly 7.0k stars and 2.3k forks on GitHub with on the order of 3,250 commits, and it maintains a Discord community that has run since 22 July 2024 and a shop at shop.bruce.computer. The project is now hosted under the BruceDevices organization (BruceDevices/firmware), with the older pr3y/Bruce path redirecting there — the same official project under a new org home, not a mirror or fork. (Mirrors do exist and clutter search results, which is why this deep dive’s sourcing is restricted to the official repo, site, and wiki; an operator should flash only from bruce.computer/flasher or the official releases.)

The core authorship and contributor credits deserve to be recorded, both out of fairness and because knowing who maintains which subsystem is useful when reading the codebase:

Table 3 — The core authorship and contributor credits deserve to be recorded, both out of fairness and because knowing who maintains which subsystem is useful when reading the codebase

Contributor (GitHub handle)	Area credited
pr3y	Project author/maintainer
@bmorcelli	The “new core” / HAL and many device ports; also the Launcher project Bruce is launcher-compatible with
@IncursioHack	RF / RFID subsystems
@Luidiblu, @eadmaster, @rennancockles, @7h30th3r0n3, @Tawank, @pablonymous	Core contributors across features
Smoochiee, TH3_KR4K3N	PCB / hardware designs

A note on the author: pr3y is a GitHub handle. The deep dive does not assert a real name or nationality, because neither is confirmed by the official project — the handle is the citable identity. The latest release at the time of writing is v1.16.1 (“Latest,” released around 11 August — the page does not show the year; 2025 is the reasonable inference), whose highlights were WPA3-PSK support with WPA2/WPA3 detection, a Brucegotchi handshake-capture fix, a Station-Deauth fix, additional Samsung OUIs for BLE Spam, ESP32-C5 BLE crash fixes, a NetCut multi-target fix, a CoreS3 SD-conflict fix, and a T-LoRa Pager encoder fix. That release-note character — a mix of new capability and many targeted bug fixes across a huge board matrix — is a fair picture of the project’s cadence: broad, fast-moving, and maintained by a distributed team.

10.6 Operating posture — the decision this volume is really about

Stripped to its core, the question a reader of this deep dive is trying to answer is: should I flash Bruce, on what, and how do I run it without breaking the law? The posture guidance below answers that directly.

When Bruce is the right choice. Bruce is the correct firmware when breadth matters more than specialist depth — when one board needs to touch Wi-Fi, BLE, sub-GHz, IR, RFID/NFC, and a scripting platform, and the operator values having every radio in one menu over having the sharpest tool in any single domain. It is especially compelling as the “flash it on gear you already own” firmware: it runs with full breadth on the M5Stack Cardputer ADV (the broadest-feature board in the matrix), it is supported on the M5Stick S3 / StickS3, and it runs (in the LITE build) on any CYD-2432S028 — all of which are owned or readily-owned hub hardware, which makes trying Bruce a zero-additional-hardware proposition.

When something else is the right choice. For the deepest, most proven 802.11 Wi-Fi/BLE work, the ESP32 Marauder Firmware (its own hub dive) is the specialist. For IDF-native research-grade capture and Wireshark streaming, Ghost ESP is the lower-level tool. For serious RFID emulation, a Chameleon-family device (Chameleon Ultra dive) beats Bruce’s not-yet-implemented emulation. For lab-grade RFID key recovery, the Proxmark3 (its own dive) is the instrument. Bruce’s strength is breadth, and the corollary is that any single deep task has a sharper dedicated tool.

The LITE-build caveat. Remember (from Vol 5) that the CYD LITE build drops the JavaScript interpreter, Telnet/SSH/WireGuard connectivity, raw sniffing, Brucegotchi, and several BLE features to fit the M5Launcher size ceiling. An operator who flashes Bruce on a CYD and finds the scripting platform absent has not hit a bug — they have the LITE build, and the full feature set requires a board (and build) with the flash headroom for it.

The non-negotiable posture rule. Bruce is “Predatory ESP32 Firmware” by its own description, and a large fraction of its menu is offensive. The posture rule is the one that governs every tool in this hub: operate active capabilities only against hardware you own or are explicitly, in writing, authorized to test; never transmit a jammer or FM broadcast outside a shielded enclosure; treat BLE spam as a consented-group-or-bench-only demonstration; and know the regional RF law before you transmit anything. The feature breadth that makes Bruce attractive is also what makes this rule load-bearing — the firmware will happily do illegal things on command, and the only thing standing between a demonstration and an offence is the operator’s discipline. ../_shared/legal_ethics.md is the binding statement of that discipline.

A note on the “maturity map” as part of posture. Three times across this deep dive — Mousejack (Vol 7), FM spectrum / TA-hijack (Vol 8), and RFID tag emulation (Vol 9) — a menu entry turned out to be a not-yet-functional stub rather than a working capability. This is not a criticism of the project so much as a characteristic of a fast-moving, very broad community firmware, and it carries a posture lesson: plan an engagement around the release notes, not the menu. The menu is the project’s ambition; the changelog (v1.16.1’s WPA3 detection, handshake and deauth fixes, OUI additions, C5 crash fixes) is its reality. An operator who assumes a capability works because it has a menu entry will, sooner or later, be embarrassed in the field by a stub — and an engineer evaluating Bruce for a specific task should verify the specific feature against the current build before relying on it. Flashing is cheap and reversible; assuming is not.

Updating and staying current. Because the project moves quickly, the operationally-correct habit is to keep a board on a known-good release rather than chasing every nightly, and to re-flash deliberately via the official web flasher (bruce.computer/flasher) or M5Launcher OTA when a release note names a fix that matters. The firmware’s own update path (Vol 5) makes this low-friction. The one discipline that does not change with versions is the legal one; features come and go across releases, but the authorization-and-shielding rules in the cheatsheet below are invariant.

10.7 Legal & ethics cheatsheet

This cheatsheet condenses the legal envelope established across Vols 6–9. It is guidance, not legal advice; the controlling authority is ../_shared/legal_ethics.md and the law of the jurisdiction the operator is standing in.

The one rule, if you remember nothing else: Own the hardware or hold written authorization; transmit only into spectrum and against systems you are allowed to; never let a transmission reach a third party without consent; know the local RF law first.

By capability tier — what is lawful where:

Table 4 — By capability tier — what is lawful where:

Capability	Tier	Lawful venue
BLE scan, RF/2.4 GHz spectrum view, IR learn, RFID/LF read	Passive / benign	Anywhere; receive-only
NDEF-write to your own tag, IR TV-B-Gone/replay (courtesy aside)	Low-risk active	Your own equipment; room-scale
Bad BLE, BadUSB (incl. via interpreter), handshake capture, deauth, Evil Portal, ARP/MITM, RFID clone/emulate	Authorized-only	Own hardware OR signed written engagement scope
BLE advertising spam	Nuisance / consent-sensitive	Isolated bench or explicitly-consented group only
CC1101 jammer, NRF24 jammer, FM broadcast	Illegal to transmit in open air	Shielded enclosure / licensed test facility ONLY

Red lines (never, regardless of authorization scope):

• Never transmit a jammer (sub-GHz or 2.4 GHz) or an FM broadcast where the signal can reach a third party — jamming is a prohibited transmission in essentially every jurisdiction (in the US, under the Communications Act, with the FCC treating jammers as prohibited devices), and FM broadcast is unlicensed transmission into a licensed band.
• Never run BLE spam in a public space — it degrades non-consenting bystanders’ devices.
• Never clone, possess, or emulate an access credential you are not authorized to use — possession alone is an offence in many jurisdictions.
• Never replay a captured sub-GHz code to operate someone else’s gate, door, car, or device.
• Never drive BadUSB/Bad BLE keystroke injection against a computer outside your authorization.

Before any transmit: confirm the regional band plan and power limits (FCC / ETSI / national regime), confirm the engagement scope covers the specific activity in writing, and prefer the shielded bench over the open air whenever the capability radiates to anyone but the authorized target. When in doubt, the shielded bench is defensible and the open air rarely is.

Consent and documentation: for any authorized engagement, keep the written authorization on hand, scope the activity to what it permits, and log what was done. The authorization is what separates a professional’s demonstration from an offence; it is the single most important artifact in the operator’s bag, worth more than any board in it.

Glossary

AGPL-3.0 — GNU Affero General Public License v3.0; the strong-copyleft licence Bruce’s firmware uses, with a network-use provision. (Not MIT; not merely “open source.”)

Arduino layer — the Arduino-core abstraction over the ESP32, as opposed to Espressif’s lower-level ESP-IDF. Bruce and Marauder are Arduino-layer; Ghost ESP is ESP-IDF-native.

Bad BLE — keystroke injection (Ducky-style HID) delivered over a Bluetooth Low Energy keyboard pairing rather than USB. Gated by the target accepting the BLE pairing. (Vol 7.)

BadUSB — USB-HID keystroke injection: a device enumerates as a keyboard and types a payload at machine speed. Available on Bruce as a menu feature and via the scripting interpreter’s BadUSB module. (Vol 9; see the Ducky Script deep dive.)

BLE spam — flooding forged proximity-pairing advertising packets (iOS/Windows/Samsung/Android) to trigger a barrage of pairing pop-ups on nearby devices; a nuisance/DoS class, not a compromise. (Vol 7.)

Brucegotchi — Bruce’s Pwnagotchi-style autonomous Wi-Fi handshake collector; dropped in the CYD LITE build. (Vol 6; see the PWNagotchi deep dive.)

bruce.conf — the runtime configuration file on SD/LittleFS holding per-board settings (pin maps, module selection, UI). (Vol 4.)

CC1101 — Texas Instruments sub-GHz transceiver (~300–928 MHz, OOK/ASK/FSK) that Bruce drives for 433/315/868/915 MHz work; on-board on the T-Embed CC1101 and RF REAPER, external elsewhere. (Vol 8.)

CERN-OHL-P-2.0 — the permissive CERN Open Hardware Licence used for Bruce’s PCB/hardware designs (distinct from the firmware’s AGPL).

CYD (“Cheap Yellow Display”) — the JCZN ESP32-2432S028R board and relatives; a ~$15 ESP32 with a display, a common substrate for Bruce (LITE build), SquachWatch, and HaleHound. (Vol 2.)

Doolittle — justinknight93’s project from which Bruce’s JavaScript interpreter is derived. (Vol 9.)

ESP Web Tools — the browser-based esptool-js flashing framework behind Bruce’s web flasher and the other CYD firmwares; the shared flashing lineage (not a shared codebase) across the CYD-firmware ecosystem. (Vols 5, 10.)

Evil Portal — a captive-portal credential-harvest capability class. (Vol 6; authorized-only.)

Ghost ESP — an ESP-IDF-native, lower-level ESP32 firmware focused on research-grade capture; leaner than Bruce, narrower in breadth. (§2.)

HAL / “new core” — Bruce’s hardware-abstraction layer (credited to @bmorcelli): each board is a PlatformIO env plus a board/pin config, with features gated at compile time by capability flags. Porting = adding a board config, not forking the app. (Vol 4.)

HaleHound — a hub-tracked CYD offensive firmware that is a documented fork of CiferTech’s ESP32-DIV (MIT); shares only the ESP Web Tools flashing lineage with Bruce, not a codebase. (§4; its own deep dive.)

Jammer (full / intermittent) — a transmitter that denies a frequency by continuous carrier (full) or pulsed bursts (intermittent); indiscriminate, illegal to transmit outside a shielded enclosure. (Vols 7, 8.)

LITE build / LITE_VERSION — a reduced Bruce build (e.g. for the CYD) that drops the JS interpreter, Telnet/SSH/WireGuard, raw sniffer, Brucegotchi, and several BLE features to fit the M5Launcher size ceiling. (Vol 5.)

Launcher — @bmorcelli’s app launcher; Bruce is built to run under it and be OTA-managed by it, which is why the LITE build exists (a size ceiling). (Vol 4.)

Marauder (ESP32 Marauder) — justcallmekoko’s focused 802.11 Wi-Fi/BLE L2 firmware; a specialist Bruce credits and borrows from, not Bruce’s parent. (§2; its own deep dive.)

Mousejack — keystroke injection against weakly-secured nRF24 wireless mice/keyboards; present as a Bruce menu entry but not yet functional. (Vol 7.)

NDEF — NFC Data Exchange Format; the structured-record format Bruce can write to NFC-Forum tags (URLs, text, Wi-Fi join records). (Vol 9.)

nRF24L01+ / NRF24 — Nordic 2.4 GHz transceiver (126 × 1 MHz channels); an external SPI module on some Bruce boards, used for a 2.4 GHz spectrum view and a jammer. (Vol 7.)

OOK / ASK — on-off keying / amplitude-shift keying; the simple modulation schemes most cheap sub-GHz remotes use and that CC1101 capture/replay targets. (Vol 8.)

PN532 / PN532Killer — NXP HF (13.56 MHz) reader IC and an enhanced variant; Bruce’s selectable NFC front-ends. (Vol 9.)

pr3y — the GitHub handle of Bruce’s author; no real name/nationality is asserted here because none is confirmed officially.

RF REAPER — Bruce’s own ESP32-S3 (N16R8) devkit PCB with CC1101, nRF24, ST25R3916 NFC, IR, GPS, iButton, microSD, and a Flipper-compatible header — the strongest single-board Bruce RF/RFID platform. (Vol 3.)

Rolling code — a sub-GHz scheme (KeeLoq and successors) that defeats naive replay by using a synchronized counter + crypto hop; contrast fixed code. (Vol 8.)

ST25R3916 — STMicroelectronics HF reader front-end integrated on the RF REAPER. (Vol 9.)

Scripting interpreter — Bruce’s on-device JavaScript engine (derived from Doolittle), exposing Core and Hardware modules; scripts run from SD. Dropped in the LITE build. (Vol 9.)

SquachWatch — a hub-tracked CYD surveillance-device detector firmware (Talking Sasquach / skizzophrenic); a CYD-ecosystem peer of Bruce. (§4; its own deep dive.)

TV-B-Gone — the stored-power-off-code IR sweep that turns off most TVs in line of sight; the benign IR demonstration. (Vol 8.)

WebUI — Bruce’s browser-based control surface served over the board’s AP, one of several control surfaces alongside the on-device UI, Serial, and Headless mode. (Vol 4.)

10.8 Summary and cross-references

Bruce sits at the generalist end of the ESP32-firmware spectrum: not a Marauder fork but an independent multi-tool that credits Marauder, M5Stick-Nemo, Launcher, and Evil-M5Project, and that out-breadths every peer — Marauder the Wi-Fi/BLE specialist, Ghost ESP the IDF-native capture tool — while deferring to dedicated instruments (Chameleon Ultra, Proxmark3) for single-domain depth. It is backed by a real first-party hardware ecosystem (Smoochiee and TH3_KR4K3N’s PCBs, AGPL firmware over CERN-OHL hardware) and a large active community (~7k stars, v1.16.1), and it shares the CYD substrate and ESP Web Tools flashing lineage with SquachWatch and HaleHound — a shared mechanism, emphatically not a shared codebase, with HaleHound forking CiferTech’s ESP32-DIV rather than Bruce. The operating posture is the one that governs the whole hub: breadth is Bruce’s gift and its hazard, and the written-authorization-and-shielded-bench discipline of the cheatsheet above is what keeps its predatory menu lawful.

For the firmware comparison from the other side, see this hub’s ESP32 Marauder Firmware deep dive; for the CYD-ecosystem peers, the SquachWatch and HaleHound deep dives; for the dedicated depth tools Bruce complements, the Chameleon Ultra, Proxmark3, Flipper Zero, and iCopy-X deep dives; and for the owned hardware Bruce runs on with the least friction, the M5Stack Cardputer ADV and M5Stick S3 deep dives. The device matrix is Vol 2, the hardware is Vol 3, the architecture Vol 4, the build/flash story Vol 5, and the capability subsystems Vols 6–9. The binding legal framing throughout is ../_shared/legal_ethics.md.