Bruce Firmware Volume 6 — Wi-Fi & Networking

6.1 About this Volume

Wi-Fi is Bruce’s deepest subsystem, and this volume surveys it the way the rest of this deep dive surveys every offensive capability: at category level only. It names each class of thing the Wi-Fi and networking menus can do, explains what that class is and what it is for defensively, and frames the authorization and regional-RF-law boundary that governs it. It deliberately does not reproduce the menu tree, and it does not give step-by-step procedures for running any specific attack. That is a standing rule across this hub’s offensive-firmware dives (it matches the treatment in the ESP32 Marauder Firmware deep dive and the WiFi Pineapple deep dive), and it is the rule here.

The reason for the category-level treatment is practical as well as ethical: the value of this material to an engineer is understanding what the tool is capable of and where the lines are, not a recipe. A defender needs to know “this firmware can mount an evil-portal credential harvest” to reason about the threat; they do not need the keystrokes. An operator with authorization already has the wiki. So this volume is a map, not a manual.

Authorization preface — read before anything else in this volume. Every capability described here is lawful to exercise only against networks and devices the operator owns or has explicit written authorization to test, and only within the operator’s regional radio regulations. Several categories transmit; transmission is regulated, and some of it (notably jamming-adjacent behaviour and unauthorized deauthentication) is outright illegal in many jurisdictions regardless of intent. The baseline discipline for this entire hub is ../_shared/legal_ethics.md; it applies in full to everything below. §12 returns to this in detail.

Voice note. Reference account of Bruce’s Wi-Fi/networking feature categories, assembled from the official wiki. No capability here has been exercised against any network in the writing of this volume.

6.2 The Wi-Fi subsystem at category level

Bruce groups its Wi-Fi and networking features into a single large menu. The categories below are the functional groupings; think of them as five bands running from passive to active to connective.

 PASSIVE / OBSERVE ACTIVE / EMIT CONNECT / TUNNEL
 ───────────────── ───────────── ────────────────
 • Scan / Connect / AP • Deauth (broadcast) • Telnet client
 • Wardriving (+GPS) • Station Deauth (targeted) • SSH client
 • Host / Port scan • Beacon / SSID spam • WireGuard tunnel
 • RAW Sniffer (.pcap) • Karma • TCP listen / client
 • Handshake capture • Evil Portal (captive page) • SOCKS4 proxy
 • Responder (LLMNR) • ESP-NOW (Connect menu)
 • ARP spoof / poison (MITM)
 • NetCut
 • Brucegotchi (autonomous)
 │ │ │
 lowest RF/legal highest RF/legal needs a joined
 exposure (mostly RX) exposure (TX, often network; mostly
 against third parties) standard protocols

Two structural facts set expectations. First, several of these are LITE-excluded (Vol 5 §7): Telnet, SSH, WireGuard, ScanHosts, RawSniffer, and Brucegotchi are compiled out of the LITE build. A CYD running the stock LITE image has the passive/active basics but not the connectivity stack, the host scanner, the raw sniffer, or the autonomous collector. Second, the connect-side features need a network to be on (they are clients or in-network tools), whereas most of the emit-side features operate on the air independent of any association.

Table 1 — 2. The Wi-Fi subsystem at category level

Band	Representative categories	RF/legal exposure	In LITE?
Observe (RX)	Scan, Wardriving, RAW Sniffer, Handshake capture	Low (mostly receive)	Sniffer/ScanHosts: no
Emit (TX)	Deauth, Beacon/SSID spam, Karma, Evil Portal	High (transmit; often third-party)	Mostly yes
In-network	Host/Port scan, Responder, ARP spoof, NetCut, SOCKS4	Depends on authorization	ScanHosts: no
Connect	Telnet, SSH, WireGuard, TCP	Standard protocol use	No (all LITE-excluded)
Mesh	ESP-NOW (Connect menu)	Low	Yes

6.3 Reconnaissance and discovery

The passive and discovery categories are the lowest-exposure part of the subsystem and the natural starting point for any authorized assessment.

• Scan / Connect / AP. Enumerate nearby networks; join one as a station; or raise the board’s own soft access point (the BruceNet AP by default, Vol 4 §6) for up to a small number of clients. The AP mode is the substrate several other features build on.
• Wardriving. Log observed access points with location, pairing the Wi-Fi scan with a GPS module (Vol 4 §10) to produce a geo-tagged survey of the RF environment. The honest defensive framing: wardriving is a mapping activity, legal to do with received signals in most places, but the resulting dataset is a surveillance artifact and should be handled accordingly. Bruce can carry a WiGLE token (wigleBasicToken, Vol 4 §6) for the common wardriving-dataset workflow.
• Host / Port scan (ScanHosts). Once joined to a network, discover live hosts and probe common ports — standard network-inventory reconnaissance, scoped to the network you are authorized on. LITE-excluded.
• RAW Sniffer. Capture raw 802.11 frames to a .pcap on the SD card (Vol 4 §9) for later analysis in Wireshark or equivalent. This is the data-collection primitive behind handshake capture (§6). LITE-excluded.

These categories are where a defender’s own posture assessment should begin: running the scan and sniffer against one’s own estate shows exactly what an attacker in the car park sees.

6.3.1 Wardriving and GPS in a little more detail

Wardriving deserves expansion because it is the one reconnaissance category that produces a persistent, shareable dataset. Bruce pairs the Wi-Fi scan with a GPS module wired per the board’s diagram (Vol 4 §10) so each observed AP is stamped with a position and time. The output is a log on the SD card (Vol 4 §9) in the common wardriving format, and the wigleBasicToken config key (Vol 4 §6) exists so that dataset can feed the usual community mapping pipeline.

Three honest notes for an engineer. First, wardriving is receive-only at heart — it listens to beacons that APs broadcast anyway — which is why it sits in the lowest-exposure band and is generally lawful. Second, the dataset is nonetheless a surveillance product: a geo-tagged census of who runs what AP where, and it should be custodied like one. Third, the defender’s use is self-audit: driving one’s own site reveals rogue and shadow APs, mis-configured guest networks, and SSIDs that leak organizational structure. The capability is a mapping tool; the posture question is who holds the map.

6.3.2 DPWO-ESP32 — the default-credential category

Bruce also carries DPWO-ESP32, a category that searches for default router credentials — testing the well-known factory username/password combinations that ship on consumer gateways. At category level this is a default-credential audit: it finds the embarrassingly common case of a router or AP still on admin/admin (or the vendor’s documented default). The defensive framing writes itself — the countermeasure is simply changing default credentials, and running this category against one’s own gateways is a legitimate one-line audit. Against someone else’s gateway it is unauthorized-access territory (§12). The related Config sub-item manages the saved Evil WiFi SSID list (the evilWifiNames array, Vol 4 §6) — housekeeping for the Evil Portal category in §5, not an attack in itself.

6.4 The access-layer manipulation class

This class emits management frames to influence association state. It is the highest-legal-exposure part of the subsystem and the part most constrained by law.

• Deauth (broadcast). Sends 802.11 deauthentication/disassociation frames to knock clients off an AP. A denial-of-service primitive at the link layer.
• Station Deauth (targeted). The same, aimed at one specific client rather than broadcast. (Fixed in v1.16.1 — see §11.)
• Beacon / SSID spam. Floods the air with fabricated SSID beacons, populating victims’ network lists with fake entries.
• Karma. Answers clients’ probe requests by impersonating the networks those clients are looking for — exploiting the way devices actively hunt for remembered SSIDs.

The defensive value of knowing this class exists is concrete: management-frame attacks are exactly what 802.11w (Protected Management Frames) was standardized to blunt, and WPA3 mandates PMF. A network that enforces PMF is substantially harder to deauth; a network that does not is trivially disruptable by any device in this class. That is the single most useful takeaway for a defender reading this section — not how Bruce sends the frames, but that the countermeasure is PMF/WPA3.

Legal callout — deauthentication is regulated. Transmitting deauth frames against networks or clients you do not own or are not authorized to test is unlawful in many jurisdictions and is treated as interference or unauthorized interruption of a communications service. In the United States the FCC has levied substantial penalties for intentional Wi-Fi blocking. This class is bench/own-estate/authorized-engagement only. See §12 and ../_shared/legal_ethics.md.

6.5 The credential-harvest class — Evil Portal

Evil Portal is the captive-portal credential-harvest category: the board raises an open access point and serves a fake login/captive page, collecting whatever a connecting user enters. Bruce persists the portal’s configuration in bruce.conf (evilWifiNames, evilWifiEndpoints, evilWifiPasswordMode, Vol 4 §6), which is why the feature has a “Config” sub-item for managing the saved SSID list rather than re-entering it each time.

At category level this is a social-engineering credential-capture tool: its effectiveness comes entirely from a human mistaking the portal for a legitimate one, not from any cryptographic weakness. That framing is the defensive lesson. The countermeasures are organizational and user-side — captive-portal awareness, not connecting corporate devices to open APs, certificate/HTTPS discipline, and EAP-based enterprise auth that does not present a web login at all. Technically detecting a rogue AP relies on the same scan/monitor categories in §3 run defensively.

Legal callout — Evil Portal collects other people’s credentials. Operating a credential-harvesting portal against anyone other than consenting test subjects in an authorized engagement is unambiguous unauthorized access / interception, and in most jurisdictions a serious criminal offence. There is no “just testing” exemption when real users and real credentials are involved. Authorized, scoped, consented engagements only.

6.6 Handshake capture and offline recovery

Bruce can capture WPA/EAPOL handshakes — the four-way-handshake frames exchanged when a client associates — saving them for offline analysis. The wiki notes the handshake can be collected via the RAW Sniffer, via Brucegotchi (§8), or via Karma. Separately, a Wi-Fi Password Recovery category tests a wordlist against a captured handshake offline (it needs no live network — it works on the saved file).

The defensive reading is the standard WPA2-PSK threat model, and it is worth stating because it is widely misunderstood: capturing a handshake does not recover the password; it enables an offline dictionary/brute-force guess against the pre-shared key. The security of a WPA2-PSK network against this entire category therefore reduces to passphrase entropy — a long, random, non-dictionary passphrase is not feasibly recoverable from a handshake, while a weak or dictionary passphrase is. WPA3-SAE changes this picture fundamentally by making offline guessing against a captured exchange impractical (the “Dragonfly” handshake is resistant to offline dictionary attack), which is one more reason the WPA3 detection added in v1.16.1 (§11) matters for assessment. Both the capture category and the recovery category are LITE-excluded in their heavier forms (RawSniffer, Brucegotchi).

6.7 The MITM class

These categories manipulate traffic on a network the board has joined — they are in-network, not over-the-air, and they presuppose the operator is legitimately on the network.

• Responder (LLMNR poisoning). Answers LLMNR/name-resolution queries to insert the device into name-resolution flows — the classic path to capturing authentication material on Windows-heavy LANs.
• ARP spoof / poison. Sends forged ARP replies so traffic between hosts and the gateway routes through the board — the textbook man-in-the-middle primitive.
• NetCut. Uses the same ARP mechanism to cut a target host off the network (a targeted in-network DoS). Multi-target handling was fixed in v1.16.1 (§11).
• SOCKS4 proxy. Routes other devices’ traffic through the ESP32 — the pivot/relay side of the same in-network position.

The defensive countermeasures for the whole class are well established and worth naming: dynamic ARP inspection and DHCP snooping on managed switches, disabling LLMNR/NetBIOS name resolution, and end-to-end encryption (TLS, SMB signing, IPsec) so that occupying the man-in-the-middle position yields ciphertext rather than credentials. A network with those controls is largely immune to this class even from an authorized-but-curious device on it.

6.8 Brucegotchi — the autonomous collector

Brucegotchi is Bruce’s Pwnagotchi-style autonomous handshake collector: an unattended mode that combines Pwngrid-style beacon spam, multi-channel deauthentication, and handshake collection into a single hands-off loop that roams channels and gathers EAPOL handshakes on its own. It is conceptually the same appliance covered at length in the hub’s PWNagotchi deep dive — an autonomous “wander and collect” Wi-Fi device — implemented here as a feature of Bruce rather than a dedicated firmware.

Two concrete notes: Brucegotchi is LITE-excluded (Vol 5 §7), so it is absent from the stock CYD LITE image; and its handshake-capture path received a fix in v1.16.1 (§11). Because it bundles active deauthentication, Brucegotchi inherits the full legal weight of §4 — it is an autonomous version of the same regulated behaviour, and “it ran unattended” is not a legal defence. Authorized-estate only.

6.9 The connectivity stack

Separate from the offensive categories, Bruce carries a genuine network client stack — the features that make the board a small networked endpoint rather than only an RF tool. These are the pieces the LITE build drops wholesale (Vol 5 §7), which tells you they are both code-heavy and connectivity-oriented.

Table 2 — 9. The connectivity stack

Category	What it is	Needs joined network	In LITE?
Telnet	Remote command-session client to a server	Yes	No
SSH	Encrypted remote command-session client	Yes	No
WireGuard	VPN tunnel, configured by a file on the SD card	Yes	No
TCP listen / client	Accept inbound, or dial out to, a TCP endpoint	Yes	No (listener)
SOCKS4 proxy	Relay other devices’ traffic (also §7)	Yes	—

The defensive/benign framing here is different from the offensive categories: these are ordinary network-client capabilities. SSH and WireGuard in particular are security-positive — an encrypted admin session and a VPN tunnel are the tools a defender uses, and their presence makes a Bruce board a plausible tiny jump host or out-of-band console over the SD-card-configured tunnel. The TCP client/listener turns the board into a scriptable network endpoint, which pairs naturally with the JS interpreter (Vol 9) for automation. None of this is inherently offensive; it is the connectivity half of a “micro-OS.”

Callout — WireGuard config is a file on the SD card. The tunnel is defined by a config file on the card (Vol 4 §9), which means the private key sits on removable media in plaintext-adjacent form. Treat the SD card as holding a VPN credential — the same custody concern as the cleartext bruce.conf secrets in Vol 4 §6.

6.9.1 Wired networking — Ethernet via W5500

Not all of Bruce’s networking is wireless. With a W5500 Ethernet module wired to the documented pins (Vol 4 §10, the wiki’s External Modules → W5500 Ethernet Module), a Bruce board gets a wired network interface. The practical consequence is that the same in-network and connectivity categories already described (§3, §7, §9) can run over a cable instead of over the air — useful where Wi-Fi is unavailable, where a wired drop is the authorized test surface, or simply for a stable management link to the board. The legal envelope is unchanged by the medium: a wired tap is as scoped-and-authorized-only as a wireless one, and the defensive countermeasures in §7 (DAI/DHCP-snooping, port security, encrypted transport) apply identically on copper. Ethernet support is LITE-excluded along with the rest of the connectivity stack.

6.10 ESP-NOW — the Connect menu

Bruce’s Connect menu is built on ESP-NOW, Espressif’s connectionless peer-to-peer link layer (no AP, no association — boards talk directly). It offers Send File / Receive File and Send Commands / Receive Commands between Bruce devices.

ESP-NOW is low-exposure and genuinely useful: it is how two Bruce units (or a Bruce unit and any ESP-NOW peer) exchange payloads and drive each other without any surrounding Wi-Fi infrastructure, at low power and low latency. The “Send Commands / Receive Commands” pairing in particular makes one board a remote for another — relevant to multi-device setups and to the kind of orchestration the Ghost ESP comparison in Vol 10 contrasts. It is retained in LITE, being small. The security note is simply that ESP-NOW’s own pairing/encryption should be enabled for anything sensitive, since the raw protocol is a local broadcast medium.

ESP-NOW is also the mechanism that makes a multi-board Bruce setup coherent: one unit can carry a screen and keyboard while another sits headless (Vol 4 §8) near the RF target, with the Connect menu’s command send/receive linking them. That pattern — a controller and one or more remote sensors/emitters over ESP-NOW — is the lightweight analogue of the multi-device orchestration the Ghost ESP comparison in Vol 10 highlights, achieved here without any surrounding Wi-Fi infrastructure and at low power. Because ESP-NOW is connectionless and operates on the Wi-Fi channels directly, it coexists with the board’s other 2.4 GHz activity rather than requiring a separate association.

6.11 WPA3 and the 1.16.1 Wi-Fi changes

The current release at the time of writing is v1.16.1 (the “Latest” tag; released around 11 August — year not shown on the page, inferred 2025). Its Wi-Fi-relevant changes are a useful snapshot of where the subsystem is maturing:

• WPA3-PSK support and WPA2/WPA3 detection. The scan/assessment side can now distinguish WPA2 from WPA3 networks — directly relevant to §4 (PMF/WPA3 resists deauth) and §6 (WPA3-SAE resists offline handshake cracking). For a defender using Bruce to audit their own estate, this is the feature that answers “are my networks actually on WPA3.”
• Brucegotchi handshake-capture fix (§8).
• Station-Deauth fix (§4).
• NetCut multi-target fix (§7).

These are incremental but they map cleanly onto the categories above, and the WPA3 work is the substantive one: it reflects the real-world shift that is steadily closing the two highest-impact category of attacks (management-frame disruption and offline PSK recovery) on networks that adopt WPA3.

6.12 Defensive reading and the legal envelope

This is the load-bearing section. Everything above is framed defensively on purpose; here is the discipline that must accompany any use of the subsystem.

Authorization is the gate, not an afterthought. Lawful use of the emit-side and in-network categories requires that the operator owns the target or holds explicit, written, scoped authorization to test it. Ownership of the tool confers nothing about the targets. An engagement scope that names specific SSIDs/hosts/time-windows is the norm for authorized work; “the coffee shop Wi-Fi” is never in scope.

Transmission is regulated by region. Bruce runs on ESP32 radios that transmit, and transmission is governed by the operator’s national radio authority (FCC in the US, Ofcom in the UK, and so on). Three bright lines recur across this hub’s dives and apply here:

Table 3 — Transmission is regulated by region. Bruce runs on ESP32 radios that transmit, and transmission is governed by the operator's national radio authority (FCC in the US, Ofcom in the UK, and so on). Three bright lines recur across this hub's dives and apply here

Category	The hard line
Deauth / Station Deauth / NetCut	Unauthorized disruption of a communications service — unlawful in many jurisdictions; the FCC has fined Wi-Fi blocking heavily.
Evil Portal / Karma / Responder	Capturing third-party credentials or inserting into name resolution is unauthorized access/interception — a criminal offence absent consent.
Beacon / SSID spam	Nuisance/DoS-adjacent emission; consent- and region-sensitive.

The defender’s use is the legitimate use. Run the scan, sniffer, and WPA3-detection categories against one’s own estate to see what is exposed; use the SSH/WireGuard connectivity stack as the ordinary admin tools they are; and use the knowledge of the emit-side categories to justify the countermeasures — PMF/WPA3 (defeats deauth), high-entropy passphrases or WPA3-SAE (defeats handshake recovery), DAI/DHCP-snooping and disabled LLMNR (defeats the MITM class), and captive-portal user awareness (defeats Evil Portal). That mapping — capability to countermeasure — is the entire reason to understand this subsystem.

6.12.1 The capability-to-countermeasure map

The most useful thing a defender can take from this whole volume is the mapping from each category to the control that blunts it. Read top to bottom, this table is a hardening checklist: if every right-hand control is in place on a network, the left-hand categories are largely neutralized even against an authorized-but-curious device sitting on it.

Table 4 — 12.1 The capability-to-countermeasure map

Category (band)	What it does	The control that defeats it
Deauth / Station Deauth / NetCut	Management-frame disruption	802.11w PMF / WPA3 (mandatory PMF)
Beacon / SSID spam / Karma	Fake-network flooding / probe impersonation	Client-side: disable auto-join to open/known SSIDs; MDM profiles
Evil Portal	Captive-page credential harvest	User awareness; no corporate device on open APs; EAP-TLS (no web login)
Handshake capture + offline recovery	Capture, then offline PSK guessing	High-entropy passphrase, or WPA3-SAE (offline-guess-resistant)
Responder (LLMNR)	Name-resolution poisoning	Disable LLMNR/NetBIOS; enforce DNS
ARP spoof / SOCKS pivot	In-network MITM / relay	Dynamic ARP Inspection, DHCP snooping; encrypt end-to-end (TLS/SMB-signing/IPsec)
Host / Port scan (ScanHosts)	Network inventory recon	Segmentation; IDS alerting on sweeps; least-exposed services
RAW Sniffer / Wardriving	Passive capture / AP census	Assume RF is observed; PMF + strong crypto make captures low-value
DPWO-ESP32	Default-credential discovery	Change default credentials on every gateway/AP
Brucegotchi	Autonomous deauth + handshake loop	Same as deauth + handshake rows (PMF/WPA3 + strong passphrase)

Two patterns fall out of the table and are worth stating because they compress the whole defensive story. WPA3 is the single highest-leverage control — it mandates PMF (killing the deauth/Brucegotchi rows) and uses SAE (killing the offline-handshake row), so adopting WPA3 closes the two highest-impact category of attacks at once. And the in-network classes all presuppose the attacker is already on the network, so the perimeter controls (strong auth, segmentation, not handing out network access) are what keep that position out of reach in the first place.

6.12.2 Why a tool like this is studied, not just feared

Bruce’s Wi-Fi subsystem is, in effect, a pocket-sized rehearsal of the common wireless attack surface. For a blue-team or an engineer responsible for an estate, understanding it concretely — which categories exist, what each produces, which control stops each — is how a threat model stops being abstract. The legitimate uses recur throughout this volume: auditing one’s own WPA3 adoption (§11), finding rogue/shadow APs by wardriving one’s own site (§3.1), proving a passphrase is strong enough to survive capture (§6), verifying PMF actually resists deauth (§4), and confirming no gateway is still on defaults (§3.2). None of that requires, or is served by, a procedure walkthrough — it requires knowing the shape of the threat, which is exactly what category-level treatment gives.

The canonical rules for this hub are in ../_shared/legal_ethics.md; it governs this volume in full, and the WiFi Pineapple and ESP32 Marauder Firmware deep dives carry the same framing for the same reasons.

6.13 Reference

• Wiki: https://wiki.bruce.computer — Features → WiFi; Features → Ethernet; Features → GPS; Features → Connect (ESP-NOW); External Modules → W5500 Ethernet Module / GPS.
• Release notes: v1.16.1 (WPA3-PSK + WPA2/WPA3 detection; Brucegotchi handshake fix; Station-Deauth fix; NetCut multi-target fix) — https://github.com/pr3y/Bruce releases.
• LITE exclusions touching this volume: Telnet, SSH, WireGuard, ScanHosts, RawSniffer, Brucegotchi (Vol 5 §7).
• Config keys: wifiAp, wifi, evilWifiNames, evilWifiEndpoints, evilWifiPasswordMode, wifiMAC, wigleBasicToken (Vol 4 §6).
• Related volumes: Vol 4 (control surfaces + bruce.conf + external modules), Vol 5 (the LITE build that drops much of this), Vol 7 (BLE/NRF24 — the other 2.4 GHz categories), the hub’s PWNagotchi deep dive (autonomous collectors), the WiFi Pineapple deep dive and ESP32 Marauder Firmware deep dive (same category-level + legal treatment).
• Legal/ethics baseline: ../_shared/legal_ethics.md — authoritative, applies in full.