Hacker Tradecraft · Volume 14
Hacker Tradecraft Volume 14 — RF Tradecraft II: Wi-Fi and BLE
The 802.11 attack surface from frame types through WPA3, the rogue-AP family lineage from KARMA to MANA, the WPA2/WPA3 handshake-capture-and-offline-crack pipeline, the BLE protocol stack at engineer depth, and the gear from WiFi Pineapple through Marauder and Nyan Box to Ubertooth
Contents
1. About this volume
This is the second volume of the reference cluster (Vols 13–17). Vol 13 treated SDR and sub-GHz — the 300 MHz–1 GHz consumer wireless population center, the canonical I/Q + Nyquist + receive-chain fundamentals, and the capture-analyze-replay workflow that defines the practitioner’s working day at the sub-GHz layer. This volume picks up where Vol 13 ended: at the 2.4 GHz, 5 GHz, and 6 GHz rows of the spectrum map table — the connected-device surface that 802.11 Wi-Fi and Bluetooth Low Energy (BLE) carry. Vol 15 closes the RF reference cluster with RFID, NFC, and physical access control.
The framing is the same as Vol 13. The reader — tjscientist, a 45-year-plus EE and software engineer — already understands the physics. The value of the volume is in the security-research framing the hat volumes (Vols 6–12) have been deferring into Vol 14 with notes like “see Vol 14 for the Wi-Fi attack surface” and “see Vol 14 for BLE depth.” What the volume covers, in operational order: the IEEE 802.11 frame structure and association protocol at the level you need to reason about a deauthentication attack or a rogue-AP impersonation; the security-generation lineage from WEP through WPA3 with what each generation fixed and what each broke; the rogue-AP family — KARMA, MANA, evil twin, known-beacons — at the capability level (not the operational walkthrough; that lives in the WiFi Pineapple deep dive); the WPA2 four-way-handshake capture, the WPA3-SAE downgrade and side-channel attacks, the PMKID handshake-less capture, and the offline-crack toolchain (hashcat / aircrack-ng / hcxdumptool / hcxpcapngtool); the BLE protocol stack from PHY through GATT, the four pairing modes, and the historical attack lineage from BlueBorne forward; and the platform comparison covering the WiFi Pineapple family, the ESP32-Marauder handhelds, Nyan Box, Flipper Zero with WiFi Devboard, the Alfa Network USB-adapter standard, and the Ubertooth One BLE-sniffing platform.
Reference-cluster role. Like Vol 13, every H2 heading in this volume becomes a frozen vol14-<heading-slug> anchor at first commit. Other Hack Tools deep dives deep-link into these anchors as HackerTradecraft_Complete.html#vol14-<slug> — the WiFi Pineapple deep dive, the ESP32 Marauder Firmware deep dive, the Nyan Box deep dive, the AWOK Dual Touch V3 deep dive, and the Flipper Zero deep dive all reach into this volume for the cross-tool tradecraft framing they deliberately don’t re-derive. Inside the series, the hat volumes have already deferred multiple threads here: Vol 7 §3 sketched the criminal-economy rogue-AP / handshake-cracking tooling; Vol 10 §3.7 treats the defender’s view (rogue-AP detection, WIDS, deauth-flood detection); and Vol 11 §3.6 places the WiFi Pineapple and Marauder in the red-team operator’s physical-entry RF/HID working set. This volume deepens the protocol side of all of those references.
What this volume does not duplicate. The hardware-and-firmware depth on individual platforms lives in the device deep dives. Each sibling deep dive is referenced by relative path from the consolidated HTML at 03-outputs/:
- WiFi Pineapple — the four current models (Mark VII, Mark VII + AC Tactical, Pager, Enterprise) at hardware depth; the PineAP / KARMA / MANA engine implementation; the modules + Campaigns + Cloud C2 ecosystem; the full operational posture for the most posture-sensitive tool in the lineup — lives in
../../WiFi Pineapple/03-outputs/WiFiPineapple_Complete.html. - ESP32 Marauder Firmware — JustCallMeKoko’s Wi-Fi/BLE pentest firmware at firmware-architecture depth; the Wi-Fi scan and attack subsystems, the BLE subsystem, the fork landscape (Ghost ESP vs Bruce vs Bad Pinguino), the SD layout and Evil Portal templates — lives in
../../ESP32 Marauder Firmware/03-outputs/ESP32_Marauder_Firmware_Complete.html. - AWOK Dual Touch V3 — the dual-ESP32-WROOM Flipper module that is tjscientist’s daily-driver Marauder host; the resistive touchscreen, the on-board GPS, the wardriving workflow — lives in
../../AWOK Dual Touch V3/03-outputs/AWOK_Dual_Touch_V3_Complete.html. - Nyan Box — the education-first ESP32-WROOM-32U + 3× NRF24L01+ + OLED multi-radio handheld; the triple-NRF24 architecture for parallel-channel sniffing; the drone RemoteID and hidden-camera detection that nothing else in the lineup covers natively — lives in
../../Nyan Box/03-outputs/NyanBox_Complete.html. - Flipper Zero — at full depth, including the WiFi Devboard ESP32-S2 daughterboard that runs Marauder as the Flipper’s Wi-Fi/BLE attack surface — lives in
../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html.
Vol 14 treats Wi-Fi and BLE at the tradecraft level — what the protocol surface looks like, where the attacks sit historically, what the workflow actually is at command-line depth, what platforms cover which corners, and where the legal lines fall. The cellular surface — GSM through 5G NR — is out of scope for the reference cluster; it appears in the spectrum map of Vol 13 §3 for orientation and is handled defensively (IMSI-catcher detection) in the Rayhunter deep dive when authored. RFID and NFC — the LF/HF cluster — belong in Vol 15.
2. The 802.11 attack surface
The IEEE 802.11 family of standards — 802.11a/b/g/n/ac/ax/be — defines the Wi-Fi physical and link layers that carry the bulk of the world’s local-area unlicensed wireless. Across thirty-plus years of evolution the security model has gone through four major rebuilds; the physical attack surface has been remarkably stable across that period. An attacker reasoning about 802.11 in 2026 needs to understand four things: the frame structure (what the radio actually emits); the association protocol (how a client gets onto an AP); monitor mode (the prerequisite for any of this); and the security-generation lineage (what cryptographic protection any given network has). This section covers all four.
2.1 Frame types — management, control, data
Every 802.11 transmission falls into one of three frame types, distinguished by the two-bit Type field in the Frame Control header. Each type carries multiple subtypes; the canonical reference is IEEE Std 802.11-2020 §9.2.4.1 The security-relevant working set:
| Type | Subtype | Function | Why it matters for security |
|---|---|---|---|
| Management (00) | Beacon | AP advertises SSID, capabilities, supported rates ~10×/sec | Passive enumeration of networks; SSID spoofing for evil twin |
| Management | Probe Request | Client asks “is anyone here?” — directed (named SSID) or null (any AP) | The Preferred Network List leak — directed probes reveal SSIDs the client has previously joined |
| Management | Probe Response | AP answers a probe request | KARMA exploits this — respond to any probe with the requested SSID |
| Management | Authentication | Open-system or Shared-Key auth step (legacy) | WPA/WPA2 uses Open Auth then 4-way handshake; WPA3-SAE replaces both |
| Management | Association Request / Response | Client joins / AP acknowledges | The “I’m on the network now” boundary |
| Management | Deauthentication | ”You are disconnected” — signed in WPA3 / 802.11w, unsigned otherwise | The deauth flood — the foundational forced-disconnect attack |
| Management | Disassociation | ”Your association is being dropped” — like deauth but recoverable | Same attack surface as deauth absent 802.11w |
| Management | Action | Vendor-specific or QoS / BSS-transition / radio-measurement | Newer 802.11 features (BSS transition / Fast BSS); some carry exploitable parsers |
| Control (01) | RTS / CTS | Reserve airtime for an upcoming data frame | Pre-association airtime negotiation; not normally a security target |
| Control | ACK | Layer-2 acknowledgement of a unicast frame | Required for the link layer’s reliability |
| Control | Block ACK | Aggregated ACK for 802.11n+ frame aggregation | Block-ACK request spoofing has been a research target |
| Data (10) | Data | The actual payload — IP, ARP, EAPOL, etc. | Once encrypted (WPA2 CCMP or WPA3 GCMP), opaque without the key |
| Data | Null Function (data with no payload) | Power-save signaling | Used as a “device is here” liveness signal |
| Data | QoS Data | WMM / 802.11e prioritized data | Same encryption rules as plain Data |
Table 14.1 — 802.11 frame types relevant to security research. The management frames are the operational center of gravity for the attack surface: every Wi-Fi attack except passive ciphertext capture starts with a management-frame manipulation — spoofing a beacon, answering a probe, forging a deauth, replaying an authentication. Control frames are mostly invisible to the attacker except as instrumentation. Data frames are opaque under WPA2/WPA3 encryption, which is the design intent.
The most consequential security property in the table is that management and control frames are unencrypted by default. WPA / WPA2 / WPA3 encrypt data frames; the management frames that establish the encrypted session pass in the clear. That is the design choice that made the deauthentication attack — discussed in §2.4 — possible for fifteen years and required 802.11w (Protected Management Frames, ratified 2009; mandatory in WPA3) to fix.2 The PMF retrofit covers a subset of management frames — deauthentication, disassociation, robust action frames — by adding a Message Integrity Check (MIC) computed under the established session key. Beacons and probe requests are not covered by PMF; they cannot be, because they precede session establishment by definition. The attack surface this leaves is small but real: an attacker can still spoof beacons and answer probes (the rogue-AP family of §3), but cannot forge a deauth against a PMF-enforced association.
2.2 The association protocol — probe, auth, assoc
A Wi-Fi client moving from “powered on” to “associated with an AP” passes through a four-step state machine:
┌──────────────────────┐
│ CLIENT BOOTS / SCAN │
└──────────┬───────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ STEP 1 — DISCOVERY (passive scan and/or active probe) │
│ │
│ Passive: client listens on each channel for beacons │
│ (every AP emits beacons ~10×/sec; SSID, BSSID, │
│ capabilities, supported rates, RSN element) │
│ │
│ Active: client emits PROBE REQUEST (directed or null); │
│ APs in range answer with PROBE RESPONSE. │
│ Directed probes leak the client's PNL. │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ STEP 2 — AUTHENTICATION (802.11 layer, not WPA) │
│ │
│ Open System: client → AUTHENTICATE → AP → ACK │
│ (Open Auth is a no-op; WPA2 uses it before │
│ the 4-way handshake) │
│ │
│ SAE (WPA3): Dragonfly handshake replaces both the Open │
│ Auth and the 4-way EAPOL — see §2.5. │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ STEP 3 — ASSOCIATION │
│ │
│ Client → ASSOCIATION REQUEST → AP → ASSOCIATION RESPONSE │
│ │
│ AP allocates an Association ID (AID); the client is now │
│ on the BSS but cannot send data until step 4 completes for │
│ WPA/WPA2/WPA3 networks. │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ STEP 4 — KEY DERIVATION (the 4-way EAPOL handshake) │
│ │
│ AP → Msg 1 (ANonce) → Client │
│ Client → Msg 2 (SNonce + MIC) → AP │
│ AP → Msg 3 (GTK + MIC) → Client │
│ Client → Msg 4 (ACK + MIC) → AP │
│ │
│ At completion both sides hold the PTK (Pairwise Transient │
│ Key) derived from PSK or 802.1X-PMK; data frames are now │
│ encrypted with the PTK (CCMP/GCMP cipher under PTK key). │
└──────────────────────────────────────────────────────────────┘Figure 14.1 — The 802.11 association sequence. Steps 1-3 are 802.11 management-frame exchanges; step 4 is EAPOL (EAP over LANs), the IEEE 802.1X authentication-and-keying framework that WPA/WPA2/WPA3-Enterprise inherits. WPA3-Personal (SAE) collapses steps 2 and 4 into a single Dragonfly handshake before association completes — see §2.5. Each step exposes a different attack surface: step 1 is where rogue APs intercept (§3); step 2-3 are where 802.11 deauth/disassoc forces a re-run (§2.4); step 4 is where the WPA2 4-way handshake gets captured for offline cracking (§4).
The structure of the sequence makes two things clear that aren’t obvious from the standard’s prose. Discovery happens before any cryptography. Every Wi-Fi-enabled device, in every operating system, emits identifying RF before it has any way to authenticate the network it’s looking at. Probe requests leak SSIDs the device has joined; beacon-based passive discovery doesn’t leak the client, but it does enumerate every AP within hearing range. Re-association is forced re-keying. Once a client is forced off the AP — by deauth, by interference, by walking out of range and back into it — it has to re-run steps 2-4. For WPA2, step 4 is the 4-way handshake an attacker captures for offline cracking; deauth-and-recapture is therefore the canonical attack accelerator. This is why 802.11w / PMF matters: it removes the attacker’s ability to force the re-run on demand. The attacker can still wait passively for natural re-associations, but the attack tempo collapses from minutes to days.
2.3 Monitor mode — the prerequisite
Every Wi-Fi attack that goes beyond “use the radio as a station” requires the operator’s adapter to be in monitor mode. A station-mode adapter (the default for client devices) only delivers frames addressed to its own MAC; everything else — beacons from unrelated APs, frames between other stations, frames on other channels — is silently dropped at the firmware level. Monitor mode disables the MAC-address filter and delivers every frame the radio receives, including 802.11 management and control frames. This is the prerequisite for aircrack-ng, kismet, hcxdumptool, wireshark with 802.11 capture, every Wi-Fi pentest tool. Without monitor mode the operator cannot capture handshakes, cannot observe probe requests, cannot map BSSIDs.
Monitor mode is not a universal capability of Wi-Fi hardware. It is a firmware-driver feature, and most consumer Wi-Fi chipsets either don’t expose it at all or expose it with crippling limitations. The list of chipsets that reliably support monitor mode with packet injection on Linux is small enough that practitioners memorize it. The historical workhorse families:
- Atheros AR9xxx series (PCIe;
ath9kdriver) — the gold standard for monitor mode + injection on Linux for over a decade. Many laptops with Atheros internal cards still work; the chipset family is mature and the driver is well-instrumented. - Ralink RT3070 / RT3572 / Mediatek MT7610U / MT7612U / MT7921U — the USB-adapter chipsets that drive most Alfa Network adapters. The MT7612U is in the Alfa AWUS036ACM (a/b/g/n/ac dual-band) and the MT7610U in the AWUS036ACH (single-band 2.4 + 5).
- Realtek RTL8812AU / RTL8814AU — popular high-power USB adapters; monitor-mode quality varies by driver version (
aircrack-ng/rtl8812auis the de-facto kernel module). - Broadcom BCM43xx — the chipset Apple uses; partial monitor mode on macOS via
airport; on Linux with the openb43driver only with significant qualifications. - Intel AX2xx series — the chipset in most modern laptops with Wi-Fi 6E/7; monitor mode is supported via
iwlwifibut injection support is limited and quirky.
The practitioner’s working rule is: don’t trust the laptop’s built-in card. Carry a known-good USB adapter — most commonly an Alfa AWUS036ACH ($45), AWUS036ACM ($60), or AWUS1900 (~$90) — and use it as the audit radio. Sub-§6 of this volume covers the Alfa adapter family in the gear table; the Hak5 store has carried the AWUS036ACM for years3 as the WiFi-Pineapple-companion adapter precisely because the Pineapple’s internal radios target audit-and-rogue-AP roles rather than client-side monitor capture.
Figure 14.2 — Yagi-Uda directional antenna on a Wi-Fi router. Photo: File:Yagi-Uda antenna for Wi-Fi on Router.jpg by LordOider. License: CC0 (http://creativecommons.org/publicdomain/zero/1.0/deed.en). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AYagi-Uda%20antenna%20for%20Wi-Fi%20on%20Router.jpg).
The standard sequence to put a Linux interface into monitor mode using aircrack-ng’s airmon-ng tool is three commands:
# 1. Check that the adapter is recognized and not in use by NetworkManager
sudo airmon-ng
# 2. Kill any process that would interfere (NetworkManager, wpa_supplicant)
sudo airmon-ng check kill
# 3. Put wlan0 into monitor mode; it becomes wlan0mon
sudo airmon-ng start wlan0After this sequence iwconfig wlan0mon reports Mode:Monitor and the interface is ready for airodump-ng, kismet, hcxdumptool, or any other capture tool. Returning to station mode is symmetric: sudo airmon-ng stop wlan0mon. The iw command provides a kernel-native alternative that doesn’t depend on aircrack-ng:
# Equivalent in iw + ip
sudo ip link set wlan0 down
sudo iw dev wlan0 set type monitor
sudo ip link set wlan0 up
airmon-ng enabling monitor mode on a Wi-Fi adapter — the canonical first command of any practical Wi-Fi audit workflow. The "monitor mode enabled" line is the gate every subsequent capture tool waits for; if the chipset's driver can't expose monitor mode, none of airodump-ng, hcxdumptool, or kismet can run.Figure 14.3 — airmon-ng enabling monitor mode. Photo: File:Airmon-ng setting monitor mode.png by IrrationalBeing. License: CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AAirmon-ng%20setting%20monitor%20mode.png).
2.4 The 802.11 security generations — WEP, WPA, WPA2, WPA3
The Wi-Fi security model has been rebuilt three times in twenty-six years, and each rebuild created a new attack class while closing the previous one. The chronology:
| Generation | Released | Cipher | Key derivation | What it fixed | What it broke |
|---|---|---|---|---|---|
| WEP | 1997 (IEEE 802.11) | RC4 (40 / 104 bit) | Static PSK + 24-bit IV | First wireless encryption | IV reuse (Fluhrer-Mantin-Shamir 2001); recoverable in <60 sec with sufficient traffic — see aircrack-ng’s historical role |
| WPA (TKIP) | 2003 (Wi-Fi Alliance interim) | RC4 + per-packet key mixing (TKIP) | 4-way EAPOL handshake; PSK or 802.1X | Per-packet key rotation; backward-compatible with WEP hardware | Beck-Tews 2008: partial recovery of TKIP packets; deprecated 2009+ |
| WPA2 (CCMP) | 2004 (IEEE 802.11i) | AES-CCMP (128-bit) | 4-way EAPOL handshake; PSK or 802.1X | Authenticated encryption; cryptographically sound transport | PSK offline cracking via 4-way-handshake capture (§4); KRACK reinstallation attack (Vanhoef 2017); PMKID attack (Steube 2018) |
| WPA3-Personal (SAE) | 2018 (Wi-Fi Alliance) | AES-CCMP / GCMP-256 | SAE (Dragonfly) Forward-secret handshake; replaces PSK 4-way | Offline-dictionary defense (no capturable PSK hash); mandatory 802.11w / PMF | Dragonblood: implementation side-channels (Vanhoef-Ronen 2019); transition-mode downgrade to WPA2 |
| WPA3-Enterprise | 2018 | GCMP-256 (192-bit suite) | EAP-TLS / Suite B | Enterprise mode with stronger curves and PMF mandate | Same EAP-side issues as WPA2-Enterprise; implementation diversity |
Table 14.2 — Wi-Fi security generations. The recurring pattern: each new generation fixes the previous attack class and ships with an unknown one. WEP fell to FMS in 2001. WPA-TKIP fell partially in 2008. WPA2 stood as the consumer standard for fourteen years until WPA3 arrived in 2018; its handshake-capture-offline-crack attack remains operational in 2026 because (a) PSK strength is what defeats it, not protocol design, and (b) WPA3 adoption is still incomplete. WPA3-SAE removes the offline-crack attack at the protocol level — there is no equivalent of the WPA2 PMKID to capture. The current research front, as of early 2026, is on the Dragonblood implementation side-channels and the transition-mode downgrade attacks, which target WPA3 deployments that maintain WPA2 backward compatibility.
The deauthentication attack sits across multiple generations. Pre-802.11w, deauth frames carry no integrity protection — an attacker on the air can inject a forged deauth claiming to be from the AP (From:AP, To:client) or from the client (From:client, To:AP), and the receiving side acts on it. The frame is one packet; the disruption is instant. The classic aireplay-ng -0 deauth flood and the mdk4 d continuous-deauth tool implement this. PMF / 802.11w closes the unicast deauth attack by requiring the frame carry a MIC keyed to the active session — an attacker without the PTK cannot forge it. Broadcast deauth remains exploitable against many implementations even with PMF enabled, because broadcast frames are by definition not keyed to any one session; the practical relief from PMF is substantial but not total.4
2.5 The key hierarchy — PMK, PTK, GTK
WPA2 and WPA3 share a key hierarchy that the attacker needs to reason about explicitly because the attacks target specific keys, not the whole edifice. The hierarchy:
- PMK (Pairwise Master Key, 256 bits) — derived from the PSK and SSID via PBKDF2-SHA1 (WPA2-Personal: 4096 PBKDF2 iterations; this is the slowness that hashcat exploits when cracking) or from an 802.1X EAP exchange (WPA2-Enterprise). The PMK is per-network, not per-session; every client on the same PSK network shares the same PMK.
- PTK (Pairwise Transient Key, 384-512 bits depending on cipher) — derived during the 4-way handshake from the PMK + the AP’s nonce (ANonce) + the client’s nonce (SNonce) + both MAC addresses. The PTK is per-session; it changes on every association. The PTK is the actual encryption key for unicast data frames.
- GTK (Group Temporal Key, 128-256 bits) — generated by the AP, distributed to all stations in Msg 3 of the 4-way handshake encrypted under each station’s PTK. Used for broadcast and multicast frames. Rotates on a schedule the AP controls (typically every hour).
- MIC (Message Integrity Check) — the per-frame integrity code that 802.11w / PMF adds to robust management frames. Computed under a key derived from the PTK.
The 4-way-handshake capture attack of §4 targets the PMK, indirectly: the captured handshake contains the MIC computed under the PTK, and the PTK is computable from the PMK + the captured nonces + MACs, so a candidate PSK can be tested by deriving the candidate PMK, deriving the candidate PTK, computing the candidate MIC, and checking against the observed MIC. The cryptographic work the attacker is paying for is the PBKDF2-SHA1 from candidate PSK to candidate PMK — everything after that is fast. This is why hashcat reports cracking speeds in PMKs/second rather than PSKs/second, and why a strong PSK (entropy beyond what a wordlist or rule set covers) defeats the attack.
The PMKID attack of §4.2 short-circuits the entire handshake: the PMKID is HMAC-SHA1(PMK, "PMK Name" || AP_MAC || Client_MAC), and the AP advertises it in the first message of an associationless exchange. The attacker captures the PMKID once, then runs the same PBKDF2-SHA1 brute force offline. No client need ever connect during the attack; no deauth need ever fire. This is what made PMKID materially different from the prior WPA2 attack landscape.
WPA3-SAE removes both attacks by eliminating the offline-testable artifact entirely. SAE is a zero-knowledge equality test using the Dragonfly handshake — both parties commit to the password, exchange random elements, and prove possession without revealing anything that can be tested offline against a candidate. Forward secrecy is a side benefit: even if the password is later disclosed, captured WPA3-encrypted traffic cannot be retroactively decrypted. The Dragonblood research (§4.3) identified implementation side-channels in SAE — timing, cache, and group-downgrade — that leak password material to a local attacker; the protocol design is sound, the deployments have been imperfect.5
3. The rogue-AP family — techniques and lineage
The rogue-AP family is a single attack class that has been refined across two decades. The core insight, due to Dai Zovi and Macaulay’s 2004 paper “Attacking Automatic Wireless Network Selection”,6 is that a Wi-Fi client’s Preferred Network List (PNL) — the SSIDs the OS auto-rejoins — leaks across active probing, and that an attacker can answer the leaked probes with a matching SSID to attract the client. Twenty years of attacks since then have refined the technique (modern client OSes probe less promiscuously; mitigations and countermitigations have layered up), but the family lives in the same engineering niche: exploit the client’s willingness to associate based on SSID alone, in the absence of meaningful AP authentication for open or PSK networks.
This section covers the rogue-AP family at the capability level — what each technique does, where it sits historically, what platform implements it. The operational walkthrough — running PineAP modules, configuring the WiFi Pineapple’s Captive Portal templates, the recon-then-Campaign workflow — lives in the WiFi Pineapple deep dive,7 which is the canonical platform implementing every member of the family.
3.1 KARMA — the founding attack (2004)
Dino Dai Zovi and Shane Macaulay presented KARMA at PacSec Tokyo in 2004 as “All Your Layer Are Belong To Us.”6 The accompanying tool — KARMA (KARMA Attacks Radio’d Machines Automatically) — operationalized a Linux-based AP that responded to every probe request with a probe response carrying the requested SSID, becoming whatever the client was looking for. A laptop scanning for home_wifi got a home_wifi response; the client associated; the attacker had a layer-2 channel. The original KARMA targeted open and pre-WPA networks; it didn’t need to know any PSK because the targets didn’t have one.
Two follow-on developments mainstreamed KARMA. Karmetasploit (HD Moore, 2007) integrated KARMA’s AP-side answering with Metasploit’s exploitation framework — once a client associated, Karmetasploit fed the attached client into a battery of browser exploits, DNS poisoning, and credential-capture modules.8 Jasager (Hak5, 2008) was the firmware that turned the original WiFi Pineapple (a Fonera-based OpenWrt device) into a portable KARMA appliance; this is the genealogical root of the modern WiFi Pineapple line.9
The original KARMA largely stopped working as Wi-Fi clients matured. iOS, Android, Windows, macOS all moved away from issuing directed probe requests for every saved network; modern operating systems issue null probes (probing for “anyone” rather than specific networks) for most scans and only resort to directed probes in narrower circumstances. The naive “respond to every probe with anything” of 2004 doesn’t catch many clients in 2026. The reformulation — MANA — addressed this.
3.2 MANA — modern KARMA (2014)
Dominic White (singe) and Ian de Villiers (SensePost) presented “Manna from Heaven: Improving the State of Wireless Rogue AP Attacks” at DEF CON 22 (2014).10 MANA addressed the post-KARMA hardening in clients by combining four techniques into one tool — a hostapd fork called hostapd-mana:
- Per-client KARMA — the modern client emits directed probes selectively, often only after seeing a beacon for the SSID. MANA tracks per-client probe history and answers probes selectively, simulating each client’s “preferred network” environment individually rather than spraying the same response at all clients.
- Loud mode — beacons for SSIDs MANA has observed in any client’s probe history. Even if a single client doesn’t probe directly, beaconing for an SSID it’s looking for can elicit association.
- EAP relay (the “EAP hashes”) — captures NETNTLMv1/v2 hashes from clients that attempt to associate with a WPA2-Enterprise network MANA is impersonating. The captured hash is then attacked offline.
- Captive-portal integration — once a client associates, MANA presents a portal that mimics common branded networks (airport, hotel, conference) and harvests credentials posted to the form.
MANA’s distinguishing engineering choice was the per-client state — modeling each victim individually rather than treating the air as one undifferentiated population. The toolkit was deprecated as a standalone in 2018 in favor of hostapd-mana (the underlying daemon) and berate_ap/bettercap for orchestration; the toolkit itself is GitHub-archived,11 but the techniques are baked into every modern rogue-AP platform including the WiFi Pineapple’s PineAP engine.
3.3 Evil twin — same SSID, hostile AP
The simplest member of the family. An attacker stands up an AP with the same SSID as a target network the victim trusts — the office Wi-Fi, the hotel Wi-Fi, the home Wi-Fi — usually with stronger signal at the victim’s location than the legitimate AP. Modern Wi-Fi clients prefer the strongest BSSID for a given SSID under default roaming behavior, and absent cryptographic AP authentication (which open and PSK networks do not have), there is nothing for the client to distinguish the impostor from the original. WPA2-Enterprise with certificate validation enabled is the structural defense; PSK networks have no defense at this layer.
Evil twin combines naturally with deauthentication: the attacker deauths the victim off the real AP, the victim’s client auto-reconnects to the strongest BSSID (the evil twin), and the attacker now mediates the victim’s network access. Once the victim is on the evil twin the attack surface broadens — captive-portal credential harvest, HTTP injection, TLS-MITM with operator-installed CA, DNS poisoning, the full MITM toolkit. The mitigations are 802.1X with cert validation, HSTS, certificate transparency, and (at the user-behavior level) zero-trust posture against captive portals.
3.4 Known-beacons — pushing the attack to passive clients
KARMA targeted clients that emitted directed probes. Modern clients often don’t. The known-beacons attack flips the geometry: the attacker beacons a long list of common SSIDs — xfinitywifi, attwifi, Boingo Hotspot, every airport and hotel and chain restaurant SSID in a curated wordlist — and waits for any client in earshot whose PNL matches to auto-associate when it sees the familiar SSID.12 The technique was formalized in a 2018 paper by Lovinger et al. as “Lovin’ the Hostspots” and is implemented in wifiphisher, eaphammer, and the WiFi Pineapple’s PineAP modules. The attack is louder than KARMA (an attacker beaconing 1000 SSIDs is highly visible to any WIDS), but it works against modern clients that don’t directed-probe.
The defense at the client side is straightforward: don’t carry SSIDs in the PNL that match generic public-hotspot names. The defense at the network side is wireless intrusion detection — Kismet, the Hak5 Cloud C2 monitoring features, commercial WIDS — looking for SSID-flooding behavior from a single radio.
3.5 The technique family in one table
| Technique | Year | Authors | Attack mechanism | Detection signal | Typical platform |
|---|---|---|---|---|---|
| KARMA | 2004 | Dai Zovi + Macaulay | Respond to any probe request with matching probe response | Probe responses from unfamiliar BSSID for the AP’s SSID; rapid SSID switching on one BSSID | KARMA tool; Karmetasploit; WiFi Pineapple (PineAP “Beacon Response”) |
| Karmetasploit | 2007 | HD Moore | KARMA AP + Metasploit auxiliary exploitation modules | KARMA signal + exploitation traffic | Metasploit Framework |
| Evil twin | (pre-existing concept; formalized ~2007) | Various | Same SSID as legitimate AP, stronger RSSI, no cert auth | Two BSSIDs advertising same SSID; RSSI anomaly | Any rogue-AP platform; WiFi Pineapple |
| MANA | 2014 | White + de Villiers (SensePost) | Per-client probe modeling; Loud beaconing; EAP hash harvest | Same as KARMA + EAP traffic from impostor AP | hostapd-mana; integrated into WiFi Pineapple PineAP |
| Known-beacons / “Lovin’ the Hotspots” | 2018 | Lovinger + others (formalized) | Beacon flood of common SSIDs | Single BSSID emitting beacons for many distinct SSIDs (~10× normal); SSID-flood WIDS rule | wifiphisher, eaphammer, WiFi Pineapple PineAP |
| EAP relay (NETNTLM harvest) | 2014+ | MANA / eaphammer | Impersonate WPA2-Enterprise; capture EAP-MSCHAPv2 hash for offline attack | EAP traffic to BSSID not on enterprise allowlist | hostapd-mana, eaphammer, WiFi Pineapple Enterprise |
| Captive-portal phishing | (ongoing) | Various | Once associated, present brand-mimic portal for credential capture | Portal HTTP traffic with passwords in clear; brand mimicry | WiFi Pineapple “Evil Portal” templates; wifiphisher |
Table 14.3 — The rogue-AP family. The lineage is clear: KARMA 2004 set the engineering pattern; subsequent attacks responded to client-side hardening with either better client modeling (MANA) or different attack geometry (known-beacons, evil twin). Every modern attack in the family is implemented in the WiFi Pineapple’s PineAP engine as a Module or Campaign. The detection-signal column points at the defender’s WIDS — Kismet, Aruba ALE, Cisco wIPS, Mojo, Aerohive — which are pattern-matching on these signatures.
3.6 The attack-family relationships
┌────────────────────────────────────────────┐
│ ROOT INSIGHT (Dai Zovi & Macaulay 2004) │
│ Wi-Fi clients trust SSID alone for open / │
│ PSK networks; cert auth would defend, but │
│ is not the default. │
└──────────────────┬─────────────────────────┘
│
┌────────────────────┼─────────────────────────┐
│ │ │
┌────────▼─────────┐ ┌────────▼─────────┐ ┌──────────▼──────────┐
│ KARMA │ │ EVIL TWIN │ │ KNOWN-BEACONS │
│ (2004) │ │ (pre-existing) │ │ (2018) │
│ │ │ │ │ │
│ Respond to │ │ Same SSID as the │ │ Beacon for a list │
│ directed probes │ │ legitimate AP; │ │ of common public- │
│ with matching │ │ rely on RSSI to │ │ hotspot SSIDs; let │
│ probe responses │ │ win the client's │ │ modern clients │
│ │ │ roaming choice │ │ passively auto- │
│ KARMA tool │ │ │ │ associate │
└────────┬─────────┘ └────────┬─────────┘ └──────────┬──────────┘
│ │ │
│ (HD Moore 2007) │ (deauth + replace) │ (PNL leak)
│ │ │
┌────────▼─────────┐ ┌────────▼─────────┐ ┌──────────▼──────────┐
│ KARMETASPLOIT │ │ DEAUTH-TO-EVIL- │ │ HOSTSPOT-CRAWL + │
│ │ │ TWIN │ │ PORTAL HARVEST │
│ KARMA AP + │ │ │ │ │
│ Metasploit │ │ Deauth victim │ │ Beacon attack + │
│ browser-exploit │ │ off real AP; │ │ Evil Portal │
│ + creds modules │ │ they re-associate│ │ branded captive │
│ │ │ to evil twin │ │ portal │
└────────┬─────────┘ └────────┬─────────┘ └──────────┬──────────┘
│ │ │
└──────────┬─────────┴─────────────┬───────────┘
│ │
┌────────▼─────────┐ ┌────────▼─────────────────┐
│ MANA │ │ WIFI PINEAPPLE │
│ (2014) │ │ (PineAP engine; 2008+) │
│ │ │ │
│ Per-client probe │ │ KARMA + MANA + Known- │
│ modeling, loud │ │ Beacons + Evil Twin + │
│ beacons, EAP │ │ Captive Portal in │
│ hash relay, │ │ purpose-built hardware + │
│ captive portal │ │ Cloud C2 + Campaigns │
└──────────────────┘ └──────────────────────────┘Figure 14.4 — The rogue-AP family-tree as it actually evolved. The root insight (clients trust SSIDs in open and PSK networks) branches into three concurrent attack geometries — directed-probe response (KARMA), same-SSID impostor (Evil Twin), and beacon-flood (Known-Beacons) — and these merge into MANA’s per-client unified model. The WiFi Pineapple’s PineAP engine integrates all branches under a single Web UI. The historical thing the diagram makes clear is that this attack class is additive, not replacement: every attack added since 2004 has supplemented rather than superseded the prior generation, because client behavior is heterogeneous enough that all geometries still catch some population.
The defensive perspective on this family is treated in Vol 10 §3.7 — Kismet plus a known-good monitor-mode adapter plus a per-site BSSID whitelist gives the SOC team a working WIDS for catching attacks of this family. The offensive perspective — what the authorized red-team operator carries — is in Vol 11 §3.6.
4. The handshake-capture and offline-crack pipeline
The single most operationally consequential attack against WPA2 networks — and the one that drove the WPA3 redesign — is capture the EAPOL 4-way handshake, then attack the candidate PSK offline. This section walks the workflow at engineer depth: the WPA2 4-way capture mechanism, the post-Steube PMKID short-circuit, the WPA3-era Dragonblood family, and the toolchain that ties them together.
4.1 The WPA2 4-way handshake — what the attacker actually captures
When a client associates with a WPA2-PSK network, after the open-authentication and association exchanges, the four-way EAPOL handshake derives the per-session PTK from the shared PMK. The four messages, captured on the air, contain exactly enough information to test a candidate PSK offline:
Msg 1: AP → Client EAPOL-Key: ANonce (32 random bytes from AP)
────────────────────────────────
No MIC. Just the AP's nonce.
Msg 2: Client → AP EAPOL-Key: SNonce + RSN_IE_client + MIC
─────────────────────────────────
Client computes:
PTK = PRF(PMK, "Pairwise key expansion",
min(AP_MAC,CL_MAC) ||
max(AP_MAC,CL_MAC) ||
min(ANonce,SNonce) ||
max(ANonce,SNonce))
KCK = PTK[0..127] (Key Confirmation Key)
MIC = HMAC(KCK, EAPOL frame minus MIC bytes)
Msg 3: AP → Client EAPOL-Key: ANonce + RSN_IE_AP + GTK + MIC
─────────────────────────────────
AP performs the same PTK derivation,
encrypts the GTK under PTK[KEK].
Msg 4: Client → AP EAPOL-Key: ACK + MIC
─────────────────
Final confirmation; both sides commit
to the keys.Figure 14.5 — The WPA2 4-way EAPOL handshake. The four messages establish mutual proof-of-possession of the PMK without ever transmitting the PMK or the PSK. The attack opportunity is that an observer with (a) ANonce (from Msg 1 or 3), (b) SNonce (from Msg 2), (c) both MAC addresses (from any frame’s header), and (d) any one MIC (from Msg 2, 3, or 4) has all the inputs to test a candidate PSK: derive candidate PMK = PBKDF2-SHA1(candidate_PSK, SSID, 4096, 256), derive candidate PTK from the captured nonces and MACs, compute candidate MIC, compare to captured MIC. If they match, the candidate PSK is correct.
The attacker needs at minimum Msg 1 and Msg 2, OR Msg 2 and Msg 3, OR Msg 3 and Msg 4 — anything that pins down both nonces and provides at least one MIC. In capture practice, getting “the full 4-way” means observing all four messages from a single (client_MAC, AP_MAC) pair within the brief association window. The standard capture tool is airodump-ng from the aircrack-ng suite:13
# Channel-locked capture on channel 6 to a pcap file, with full frame headers
sudo airodump-ng --bssid <AP_MAC> --channel 6 -w handshake_capture wlan0mon
# In a separate terminal, force a re-association of the victim client
# to ensure the 4-way is captured. The deauth target is the client, not the AP.
sudo aireplay-ng -0 5 -a <AP_MAC> -c <CLIENT_MAC> wlan0mon
# airodump-ng prints "WPA handshake: <AP_MAC>" in its banner once it sees
# all 4 messages from the same client. That's the gate.The aireplay-ng -0 5 command sends 5 deauthentication frames at the client; the client disconnects and immediately auto-reconnects, re-running the 4-way handshake which airodump-ng captures into the pcap. Against networks with 802.11w / PMF enforced this will not work — the deauth is rejected for lacking a valid MIC. The fallback is patient passive capture (wait for natural re-associations) or the PMKID attack (§4.2), which doesn’t need any client at all.
Modern tooling has largely replaced airodump-ng with hcxdumptool from the hcx toolset by ZerBea,14 which combines monitor-mode capture, multi-channel hopping, deauth, and PMKID/EAPOL filtering in a single command optimized for handing off to hashcat:
# Capture EAPOL + PMKID directly to hcxdumptool's native pcapng format,
# attacking all visible APs (filter with --filterlist_ap for targeting).
sudo hcxdumptool -i wlan0mon -w capture.pcapng \
--enable_status=15 --rds=1
# Convert capture.pcapng to hashcat's WPA mode 22000 format with hcxpcapngtool
hcxpcapngtool -o handshake.22000 capture.pcapng
# Crack offline with hashcat in mode 22000 (combined WPA*/PMKID format)
hashcat -m 22000 handshake.22000 rockyou.txt -r rules/best64.ruleThe -m 22000 mode in hashcat replaced the older -m 2500 (WPA-EAPOL-PBKDF2-HMAC-SHA1) and -m 16800 (WPA-PMKID-PBKDF2-HMAC-SHA1) modes in hashcat 6.0+; the unified format handles both the 4-way EAPOL handshake and the PMKID with the same toolchain.15
aircrack-ng running a dictionary attack against a captured WPA2 handshake. The "Tested" counter and the keys/second rate are the visible measure of the offline-crack pipeline's economics — modern hashcat on a single high-end GPU runs hundreds of thousands of WPA2 candidate keys per second; on a multi-GPU rig, millions per second. The cost is bounded by the candidate space, which is bounded by the password's entropy, which is the actual defense.Figure 14.6 — aircrack-ng running a dictionary attack against a captured WPA2 handshake. Photo: File:Aircrack-ng dictionary attack.png by IrrationalBeing. License: CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AAircrack-ng%20dictionary%20attack.png).
4.2 The PMKID attack (Steube 2018) — handshake-less capture
On August 4, 2018, Jens “atom” Steube — the lead developer of hashcat — disclosed a new WPA/WPA2 attack on the hashcat forum that removed the client from the attack entirely.16 The mechanism: the Pairwise Master Key Identifier (PMKID) is a 16-byte field in the first message of the EAPOL exchange that the AP optionally sends to identify the PMK it intends to use — primarily a 802.11r Fast BSS Transition feature. The PMKID is derived as:
PMKID = HMAC-SHA1(PMK, "PMK Name" || AP_MAC || Client_MAC)[0..127]The PMK is the same PBKDF2-SHA1 derivation of the PSK that the 4-way handshake uses. An attacker who captures the PMKID has the same offline-attack target as one who captured a full 4-way handshake — derive candidate PMK from candidate PSK, derive candidate PMKID, compare. The attacker does not need a client to associate, does not need to deauth anyone, does not need to wait for natural re-association. A hcxdumptool running for a few seconds against any AP that has the optional PMKID field enabled — which was nearly universal among consumer APs in 2018 because of widespread 802.11r support — produces an offline-crackable artifact.
The PMKID attack was instantly transformative because it removed every prior excuse for the attack failing. The pre-Steube WPA2 attack required either (a) waiting for a victim to associate with the AP at exactly the capture window, or (b) successfully deauthing a victim and capturing the re-association before the victim moved or the network dropped them. Both involved real failure modes. The post-Steube attack required only that the AP have PMKID-bearing frames enabled (most did) and that the attacker have monitor-mode capture for a few seconds. Adoption was rapid. Within months hcxdumptool and the corresponding hashcat mode were standard equipment, and consumer APs began shipping firmware updates that disabled PMKID transmission by default — though by 2026 the residual base of unpatched APs remains very large.
The defense against PMKID at the protocol level is to disable optional PMKID transmission in the AP firmware (some vendors expose this; many don’t); at the operational level it is the same defense as for 4-way capture: strong PSK that defeats wordlist + rule attacks. At the architectural level it is migration to WPA3-SAE, which has no analogous offline-testable artifact.
4.3 WPA3-SAE — and the Dragonblood family (Vanhoef & Ronen 2019)
WPA3-Personal replaces the WPA2 PSK / PBKDF2 / 4-way scheme with Simultaneous Authentication of Equals (SAE), the Dragonfly handshake. SAE has the desirable property that the protocol leaks no offline-testable artifact about the password — both sides prove possession via a zero-knowledge equality test using elliptic-curve commitments. A passive observer of an SAE exchange captures nothing useful for an offline attack.
In April 2019, Mathy Vanhoef (the KRACK author) and Eyal Ronen published “Dragonblood: A Security Analysis of WPA3’s SAE Handshake”17 documenting that the SAE implementations in 2018-2019 WPA3 deployments suffered from multiple attack classes:
- Group downgrade. WPA3 negotiates which elliptic curve / multiplicative group the Dragonfly handshake will use. Many implementations responded to a forged Commit message specifying a deliberately weak group (a small Brainpool curve, or the MODP1024 multiplicative group) by accepting that group. The attacker forced the network into a weak group, then mounted offline attacks against the resulting handshake.
- Timing side-channels. The SAE “hunting and pecking” password-to-element conversion uses a variable number of iterations depending on the password. A network-resident attacker observing handshake timing can statistically infer characteristics of the password, narrowing the offline-attack candidate space.
- Cache side-channels. A local attacker (one with code-execution on the same machine as the SAE implementation) can observe cache-line access patterns during the hunting-and-pecking phase and similarly leak password material.
- Transition-mode downgrade. WPA3 transition mode (the migration setting that allows WPA2 and WPA3 clients on the same AP) presents both WPA3-SAE and WPA2-PSK simultaneously. A client that supports both can be forced to associate with the WPA2 path via deauth-then-evil-twin, after which the standard PMKID or 4-way attack applies.
The Wi-Fi Alliance and OpenSSL / wpa_supplicant / hostapd published patches addressing the disclosed timing and cache side-channels and the group-downgrade vulnerability in 2019. The transition-mode downgrade is a deployment-model issue, not a fixable protocol flaw: any network that supports both WPA2 and WPA3 simultaneously is vulnerable to the WPA2-path attack. The defense is WPA3-only mode, which is widely supported in modern APs and clients but rarely the default because of the resulting compatibility break with WPA2-only hardware.
A reasonable working assumption for 2026 deployments: WPA3-SAE in WPA3-only mode is secure against the public attack landscape; WPA3-SAE in transition mode inherits the WPA2 attack surface; WPA2-PSK is operationally cracked against weak passwords and remains operationally secure against strong ones; WEP and WPA-TKIP are obsolete and should be treated as offering no meaningful confidentiality.
4.4 Handshake-attack summary table
| Attack | Disclosure | Capture method | What the attacker captures | Crack difficulty | Typical defense |
|---|---|---|---|---|---|
| WEP IV / FMS / chopchop | 2001 (FMS); 2004-2007 (refinements) | Passive observation; active ARP injection accelerates | ≥40k IVs containing weak keys | Seconds with aircrack-ng -K | Don’t use WEP. WPA2 minimum. |
| WPA2-PSK 4-way handshake | 2004 (WPA2); attack since release | Capture full 4-way EAPOL; deauth to force re-association if needed | EAPOL Msgs 1-2 minimum + both MACs + SSID | PBKDF2-SHA1 brute force; strong PSK survives | Strong PSK (>14 char random); WPA3-SAE migration; 802.11w |
| WPA2 KRACK key reinstallation | 2017 (Vanhoef) | Block handshake Msg 4 from reaching client; force PTK reinstall | Reinstalled PTK reuses nonce; some traffic decryptable | Client-side patch (October 2017+); WPA2-CCMP partial defense | Patched clients (now default) |
| WPA2-PSK PMKID | August 2018 (Steube) | hcxdumptool against any AP with PMKID frames enabled | Single PMKID frame; no client required | PBKDF2-SHA1; same offline economics as 4-way | Strong PSK; disable PMKID transmission in AP; WPA3 |
| WPA3-SAE group downgrade | April 2019 (Vanhoef & Ronen) | Forge Commit message specifying weak group | Handshake completed under weak curve | Offline attack against weakened handshake | hostapd/wpa_supplicant patches (2019+); WPA3-only |
| WPA3-SAE timing side-channel | April 2019 (Vanhoef & Ronen) | Observe SAE handshake timing remotely | Statistical leak of password characteristics | Reduces dictionary search space | Patched implementations (constant-time hunting-and-pecking) |
| WPA3-SAE cache side-channel | April 2019 (Vanhoef & Ronen) | Local code execution required; observe cache accesses | Direct password material leak | Direct exfiltration | Patched implementations; OS-level mitigations |
| WPA3 transition-mode downgrade | 2019+ (multiple) | Deauth + evil-twin against the WPA2-PSK side of the transition AP | Full WPA2 attack surface | Same as WPA2 attacks | WPA3-only mode (no transition) |
Table 14.4 — The Wi-Fi handshake-attack family across two decades. The recurring engineering pattern: each protocol generation shipped with one or more side-channel or capture vulnerabilities; the published research drove patches and the next generation. WPA2-PSK’s 4-way and PMKID attacks remain operational in 2026 against weak-passphrase networks, which is most consumer networks. WPA3-SAE’s protocol design closed the offline-capture attack class; its implementation issues have been patched; its deployment is still incomplete. The transition-mode downgrade is the practical 2026 attack vector against WPA3 networks that didn’t take the operational hit of disabling WPA2 backward compatibility.
4.5 The cracking-economics reality
The defender’s question is not “is the attack possible?” — for WPA2 it is always possible to capture the artifact — but “how expensive is the offline attack?” For a captured WPA2 handshake or PMKID, the answer is determined entirely by the password and the attacker’s compute budget. Order-of-magnitude figures, on a single modern high-end consumer GPU (RTX 4090-class, late-2024 reference):
- WPA2 mode
-m 22000: ~1.3 million candidates per second per GPU. - 8-character lowercase alphabetic password (26^8 ≈ 2×10^11 candidates): ~42 hours single-GPU; minutes on a 16-GPU rig.
- 8-character lowercase + digit (36^8 ≈ 2.8×10^12 candidates): ~24 days single-GPU; ~1.5 days on a 16-GPU rig.
- 10-character mixed case + digit + symbol (~95^10 ≈ 6×10^19 candidates): infeasible by brute force; only practical via dictionary + rules against common patterns.
rockyou.txtdictionary (~14 million passwords): seconds to minutes on a single GPU. Most consumer passwords that fall, fall here.rockyou.txt+best64.rule(~14 million × 64 ≈ 900 million candidates): minutes single-GPU. The standard first-pass attack.crackstation-human-only.txt(~64 million passwords): minutes single-GPU.
The practitioner’s working rule: any WPA2/WPA3 PSK that is a single dictionary word, a common phrase, a date, a name, or any of those with simple substitutions (P@ssw0rd!-style) falls to a single-GPU hashcat run in under an hour. The defense is passphrase-class keys (multiple unrelated words, or full random alphanumeric ≥ 14 chars) that fall outside dictionary + rule space. The Diceware-style “five random words” passphrase remains the most reliable user-friendly approach. WPA3 migration is the architectural defense; until then, PSK strength is what stands between a captured handshake and a recovered password.
The attack-vs-defense balance is purely economic. The attacker’s cloud-GPU costs in 2026: ~$0.50/hr for an RTX 4090-class instance on a major cloud provider. A rockyou + best64 attack against a captured WPA2 handshake costs the attacker less than $1 in compute. A 24-day brute force of an 8-character alphanumeric costs ~$300. A serious attack against an 8-character mixed-character-class password costs months and thousands of dollars of GPU time, which is where the defense floor effectively sits for a typical consumer threat model.
5. BLE — the protocol and the attack surface
Bluetooth Low Energy is the 2.4 GHz neighbor of Wi-Fi — same ISM band, very different protocol stack, very different attack surface. BLE was introduced in Bluetooth 4.0 (2010) as a low-power, low-data-rate alternative to Bluetooth Classic for IoT, wearables, sensors, beacons, and the long tail of devices that don’t need streaming audio. BLE 5 (2016) added 2 Mbps PHY, long-range coding, and broadcast extensions; BLE 5.2 (2020) added LE Audio; BLE 5.3 (2021) added control-frame and connection-update refinements; BLE 5.4 (2023) introduced PAwR (Periodic Advertising with Responses) and ECBIS (Encrypted Connection-Based In-band Service).18 By 2026 the BLE-enabled-device population — wearables, smart-home, medical, industrial, automotive, retail beacons, audio — is in the billions, and the security research surface has correspondingly matured.
5.1 The BLE protocol stack
The BLE protocol stack is layered in the same conceptual style as TCP/IP, but with BLE-specific names at every layer. The canonical reference is the Bluetooth Core Specification.19 The layers, from antenna upward:
┌──────────────────────────────────────────────────────────────────┐
│ APPLICATION │
│ (smartphone app, embedded firmware, etc.) │
└─────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────────▼────────────────────────────────┐
│ GATT (Generic Attribute Profile) │
│ │
│ Service framework on top of ATT. Defines reads, writes, notify, │
│ indicate procedures. Devices expose a hierarchy of Services → │
│ Characteristics → Descriptors. Most BLE applications interact │
│ here. │
└─────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────────▼────────────────────────────────┐
│ ATT (Attribute Protocol) │
│ │
│ The wire protocol for reading/writing 16-bit Handles to small │
│ values (≤ 512 bytes). GATT is the framework; ATT is the bits. │
└─────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────────▼────────────────────────────────┐
│ GAP (Generic Access Profile) + SMP (Security Manager) │
│ │
│ GAP: device roles (Peripheral, Central, Broadcaster, Observer); │
│ advertising, scanning, discovery, connection establishment;│
│ MAC address types (Public, Random Static, Random │
│ Resolvable, Random Non-Resolvable). │
│ │
│ SMP: pairing (Just Works / Passkey / Numeric Comparison / │
│ OOB), key generation, key distribution. │
└─────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────────▼────────────────────────────────┐
│ L2CAP (Logical Link Control and Adaptation Protocol) │
│ │
│ Channel multiplexing (Fixed channels for ATT, SMP, signaling; │
│ Dynamic channels for L2CAP CoC / connection-oriented channels). │
│ Fragmentation and reassembly for ATT payloads > 23 bytes. │
└─────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────────▼────────────────────────────────┐
│ HCI (Host Controller Interface) │
│ │
│ The boundary between host (Linux, macOS, mobile OS) and │
│ controller (Bluetooth chip). HCI is what `hcidump` snoops; it's │
│ the layer Wireshark's btsnoop captures observe. │
└─────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────────▼────────────────────────────────┐
│ LINK LAYER (LL) │
│ │
│ State machine: Standby → Advertising → Scanning → Initiating → │
│ Connection. Manages 40 RF channels (37 data + 3 advertising: │
│ ch 37, 38, 39 at 2402/2426/2480 MHz). Channel hopping during │
│ connection (37 data channels with adaptive hopping). Frame │
│ encryption (AES-CCM-128) after pairing. │
└─────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────────▼────────────────────────────────┐
│ PHY │
│ │
│ 2.4 GHz ISM band; GFSK modulation. 1 Mbps (BLE 4.x); │
│ 2 Mbps (BLE 5); LE Coded (S=2 or S=8) for long range (BLE 5). │
└──────────────────────────────────────────────────────────────────┘Figure 14.7 — The BLE protocol stack. The split into Host (upper layers — GATT, ATT, GAP, SMP, L2CAP) and Controller (HCI, LL, PHY) is the same architectural division Bluetooth Classic uses. The HCI boundary is where most security tooling intercepts — btmon on Linux, PacketLogger on macOS, the Android Bluetooth HCI snoop log all capture HCI traffic, and the captured exchange shows L2CAP fragments containing ATT operations on GATT handles. The Link Layer’s adaptive frequency hopping over 37 data channels is the reason BLE sniffing is harder than Wi-Fi sniffing — the sniffer needs to follow the hop sequence in real time. The Ubertooth One, the nRF52840 dongle, the Saleae Logic with BLE firmware, and the Sniffle / SniffleAndroid stack all handle the hopping problem in different ways (see §5.6).
5.2 BLE roles and addresses
BLE defines four roles at GAP, two of which are connection-oriented and two of which are not:
- Peripheral — a connectable device that advertises itself and accepts connections. Wearables, beacons, sensors, peripherals in the everyday sense.
- Central — initiates connections to peripherals. Smartphones, computers, hub devices.
- Broadcaster — emits advertisements without accepting connections. Beacons (iBeacon, Eddystone), some sensors that only broadcast their state.
- Observer — scans for advertisements without connecting. Phone-app scanning use cases; security tools in passive mode.
BLE devices identify by 48-bit MAC addresses, but BLE has a richer notion of MAC type than Wi-Fi:
| Address type | Stability | Privacy property |
|---|---|---|
| Public | Permanent; assigned IEEE OUI + per-device suffix | None — identifies the device |
| Random Static | Stable across power cycles unless reset | Stable identifier; not OUI-derived |
| Random Resolvable Private (RPA) | Rotates periodically (typically 15 min); resolvable to the underlying device using a shared Identity Resolving Key (IRK) | The privacy-preserving address used by modern phones, AirTags, etc. — provides anti-tracking by default but resolvable by paired peers |
| Random Non-Resolvable | Random per advertising session; not resolvable | Maximum anti-tracking; no persistent identity |
The shift to RPA-by-default in iOS (2018), Android (2019), and macOS (2020) was the biggest privacy improvement BLE has had — pre-RPA, devices broadcast a permanent MAC that could be passively tracked across stores, airports, cities. Post-RPA, the MAC rotates every ~15 minutes and is unlinkable without the shared IRK. The attack surface that remains is implementation-specific: devices that don’t rotate the RPA on a schedule, devices that include identifying data in the advertisement payload, devices that emit the same auxiliary identifiers (battery level, version strings) every advertisement and can be tracked via the payload rather than the address.
5.3 BLE pairing modes — Just Works, Passkey, Numeric Comparison, OOB
BLE pairing — establishing the shared keys used to encrypt connection traffic — has evolved across Bluetooth versions. The modern stack (BLE 4.2+) defines two generations: Legacy Pairing (BLE 4.0/4.1; uses a Short Term Key + Temporary Key) and LE Secure Connections (BLE 4.2+; uses ECDH P-256 Diffie-Hellman). Within each generation there are four pairing methods, chosen at connection time based on each device’s I/O capability (whether it has a display, a keyboard, a yes/no input):
| Method | Authentication strength | Use case | MITM defense |
|---|---|---|---|
| Just Works | None (open) | Devices with no display and no input — sensors, beacons | None — vulnerable to active MITM during pairing |
| Passkey Entry | Six-digit code (~20 bits) | One device displays a 6-digit code, the other accepts it via keypad | Effective against passive MITM; modest against active MITM (~10^-6 success per attempt) |
| Numeric Comparison | Six-digit code displayed on both | Both devices display a six-digit number; user confirms they match | Effective against MITM (LE Secure Connections variant) — the comparison cannot be passively or actively bypassed |
| Out-of-Band (OOB) | Variable — depends on OOB channel | Pairing material exchanged via NFC, QR code, or other side channel | Strongest — MITM defense depends on the OOB channel’s security |
Table 14.5 — BLE pairing methods. The pattern is clear: Just Works trades security for usability and is appropriate only where the device’s I/O genuinely doesn’t support better; Passkey and Numeric Comparison provide meaningful authentication when both devices support them; OOB is the high-assurance path for high-value pairing. The vast majority of consumer BLE pairings — fitness trackers, smart-home devices, headphones — use Just Works, which is the structural reason the historical attack surface against BLE has been so productive.
The pairing-method downgrade attack — analogous to the WPA3 transition-mode attack — applies to mixed-capability pairings: if either device claims “no I/O” capability, the negotiation falls back to Just Works regardless of what the other device supports. A device that can do Numeric Comparison but is paired with one that claims no I/O ends up in a Just Works pairing with no MITM defense. This was the original Bluetooth pairing weakness identified in 2004 and never fully closed at the spec level; the operational defense is at the device-design level (don’t claim less I/O capability than you actually have) and at the user-behavior level (refuse Just Works pairings for sensitive devices).
5.4 The BLE attack lineage — from BlueSnarfing to BlueBorne to ESL
The BLE attack history is structured by attack-class generation:
- BlueSnarfing / BlueJacking / BlueBugging (2004-2006). Pre-BLE; targeted Bluetooth Classic with weak pairing. BlueSnarfing read contacts and SMS from paired devices; BlueBugging escalated to command injection. These attacks largely closed with Bluetooth 2.1’s Secure Simple Pairing.
- BlueSmack (~2010). Bluetooth equivalent of a ping-of-death; sent oversized L2CAP echo requests to crash poorly-coded stacks. Closed by stack hardening.
- BLE pairing observation (2013+). Researchers (Mike Ryan, Crackle) demonstrated that BLE Legacy Pairing was vulnerable to passive observation of the pairing exchange — the TK could be brute-forced from a captured pairing, yielding the STK and thus the encrypted traffic. Crackle (Mike Ryan, 2013) was the canonical tool.20 Legacy Pairing was deprecated in favor of LE Secure Connections (ECDH-based, BLE 4.2+) but remains in many deployed devices.
- BlueBorne (Armis, September 12, 2017). A family of eight CVEs (CVE-2017-1000251, -1000250, -0785, -0781, -0782, -0783, -8628, -14315) covering Android, iOS, Linux, Windows Bluetooth stacks. The vulnerabilities ranged from information disclosure (CVE-2017-0785 BNEP heap leak) to remote code execution (CVE-2017-1000251 Linux kernel BlueZ overflow). Estimated 5.3 billion devices vulnerable at disclosure; patches rolled out across 2017-2018. BlueBorne demonstrated that the Bluetooth stack itself — not just the protocols — was a productive attack surface, because every major OS shipped a different implementation with different bugs.21
- KNOB attack (Antonioli, Tippenhauer, Rasmussen — USENIX Security 2019). Demonstrated that Bluetooth Classic’s key-negotiation step allowed an attacker to force the encryption key entropy down to 1 byte — making subsequent traffic trivially decryptable. Covered Classic, not BLE; bundled here for completeness because the spec lineage is shared.
- BLURtooth (CERT, September 2020). Cross-Transport Key Derivation vulnerability allowing an attacker to overwrite a paired device’s keys via the unpaired transport.
- BrakTooth (ASSET Group SUTD, August 2021). Family of 16 vulnerabilities in Bluetooth Classic SoCs from major vendors (Espressif, Cypress, Intel, Qualcomm). RCE and DoS against widely-deployed silicon.
- BLE relay attacks (~2022+). Demonstrated against keyless-entry systems (Tesla Model 3/Y notably, NCC Group March 2022). The attack relays BLE packets between a victim’s phone (in their pocket, far from their car) and the car’s BLE radio, defeating proximity-based authentication. Defense is round-trip-time enforcement at the protocol level; deployment is uneven.
- Electronic Shelf Label (ESL) attacks (2023). Retail ESL devices, often BLE-based, were demonstrated to be vulnerable to price-change attacks via spoofed advertisements.22
The current attack research surface (early 2026) is dominated by (a) stack vulnerabilities in specific SoCs and OS implementations — the BrakTooth pattern, ongoing; (b) relay attacks against proximity-based authentication — keyless entry, presence detection; (c) RPA-bypass tracking — finding stable identifiers in advertisement payloads; (d) implementation flaws in LE Secure Connections deployments. The protocol design of LE Secure Connections with Numeric Comparison is sound; the implementation diversity across the BLE ecosystem is where the attacks live.
5.5 BLE scanning — what the working tools look like
For active BLE security research the operator works mostly at the GAP/GATT layer rather than the LL/PHY layer — passive scanning to enumerate visible devices, then GATT enumeration to dump each device’s Service / Characteristic / Descriptor tree. The Linux toolchain:
# bluetoothctl — interactive scanner / pairing tool from BlueZ
bluetoothctl
> scan on # passive BLE scan; lists addresses, names, RSSI
> devices # enumerate scanned devices
> connect <MAC> # establish GATT connection
> menu gatt
> list-attributes # dump full service/characteristic tree
> select-attribute <handle>
> read # read the value
> write 0x01 # write a value
# bettercap — multi-protocol pentest framework with BLE module
sudo bettercap -iface wlan0
> ble.recon on # enumerate advertisements
> ble.show # current state of discovered devices
> ble.enum <MAC> # full GATT enumeration of one device
> ble.write <MAC> <UUID> <hex> # write to a Characteristic by UUID
# gatttool — legacy BlueZ tool, still useful for explicit GATT scripting
sudo gatttool -b <MAC> -I
> connect
> primary # list primary services
> characteristics # list characteristics
> char-read-hnd 0x0010
> char-write-req 0x0010 0102030405
# Python via Bleak — modern cross-platform BLE library
python3 -c "
import asyncio
from bleak import BleakScanner, BleakClient
async def enum(addr):
async with BleakClient(addr) as c:
for svc in c.services:
print(f'SVC {svc.uuid}')
for char in svc.characteristics:
print(f' CHR {char.uuid} props={char.properties}')
devices = asyncio.run(BleakScanner.discover(timeout=5.0))
for d in devices:
print(f'{d.address} {d.rssi}dBm {d.name}')
"Each of these tools sits on top of the host OS’s BLE controller via HCI; none of them is doing channel-hopping packet capture at the LL/PHY layer. For that — observing the actual encrypted-or-not radio packets between two connected devices — the operator needs a dedicated sniffer (Ubertooth One, nRF52840 with Sniffle firmware, TI CC2540 USB dongle with SmartRF Packet Sniffer, Saleae Logic Pro with the BLE analyzer add-on). The Ubertooth One is treated in §6 as part of the gear comparison.
5.6 BLE 5+ — what changed for security
BLE 5 (2016) and its successors added four features with security implications:
- 2 Mbps PHY. Faster data rate; same encryption; no direct security change.
- LE Coded PHY (S=2, S=8). Long-range coding (~4× and ~10× of the BLE 4.x range respectively). Increases the attack distance — a BLE 5 device using LE Coded PHY is observable from much further than a BLE 4.x device. Not a security vulnerability per se; an attack-surface geometric change.
- Extended Advertisements. Larger advertising payloads (255 bytes vs the prior 31), advertising on data channels not just the primary three. Attack-surface impact: more room for fingerprint-able payload data; advertising surface harder to passively monitor (37 channels vs 3).
- Bluetooth Mesh. A mesh-networking layer on top of BLE; security model includes provisioning (similar to BLE pairing but with friend/relay/proxy roles), per-application keys, replay protection via sequence numbers. Attack surface is its own active research area, mostly orthogonal to the connection-mode BLE attacks of §5.4.
- LE Audio (BLE 5.2, 2020). LE Audio with the LC3 codec for headsets and broadcast audio. Security model adopts the standard LE Secure Connections pairing for unicast and a separate Broadcast Audio Stream encryption (with a shared key derived from a Broadcast Code) for broadcast. Disclosed attacks have been mostly against implementation flaws in specific vendors’ codecs and not the protocol itself.
- PAwR — Periodic Advertising with Responses (BLE 5.4, 2023). Targeted-broadcast pattern for retail, lighting, and large-deployment scenarios; security implications still emerging as of 2026.
The summary for operators: BLE 5+ doesn’t structurally change the §5.4 attack landscape — the protocol-level attacks remain implementation issues; the relay-attack pattern works the same against BLE 5 keyless entry as against BLE 4; the pairing methods are the same; LE Secure Connections is still the strong-side pairing. The geometric attack-surface expansion from LE Coded PHY is the practical change worth noting.
6. The gear — Wi-Fi and BLE platform comparison
The Hack Tools lineup’s Wi-Fi and BLE coverage spans purpose-built audit hardware (the WiFi Pineapple family), ESP32-based handheld pentest platforms (AWOK Dual Touch V3, Nyan Box, Ruckus Game Over, Flipper WiFi Devboard running Marauder), and the practitioner-standard USB adapters and dedicated BLE sniffers that fill in the gaps. This section is the comparison table for “which platform do I reach for?”, with cross-links to the per-tool deep dives that carry the chip-and-firmware depth.
6.1 The platform comparison table
| Tool | Cost (early 2026) | 2.4 GHz Wi-Fi | 5 GHz Wi-Fi | 6 GHz Wi-Fi (6E/7) | BLE | Monitor mode | TX / rogue-AP | Best at | Deep dive cross-ref |
|---|---|---|---|---|---|---|---|---|---|
| WiFi Pineapple Mark VII | ~$120 | Yes (Atheros + MT76xx dual-radio) | No (add-on adapter required) | No | No native (USB-add-on) | Yes (native) | Yes — purpose-built PineAP | Entry-level Pineapple; the 2.4-GHz-only baseline | ../../WiFi Pineapple/03-outputs/WiFiPineapple_Complete.html |
| WiFi Pineapple Mark VII + AC Tactical | ~$235 (kit incl. MK7AC adapter) | Yes | Yes (MK7AC = MT7612U) | No | No native | Yes | Yes | The defended “recommended first buy”; covers 2.4 + 5 GHz | Same |
| WiFi Pineapple Pager | $250-300 | Yes (tri-band) | Yes | Yes (Wi-Fi 6E) | Yes (integrated BT/BTLE) | Yes | Yes | Field handheld with display + battery + 6E + BT | Same |
| WiFi Pineapple Enterprise | $1,800+ (rack chassis) | Yes (5-radio MIMO array; IPQ4019 + MT7612U) | Yes | No (5-radio config is 2.4 + 5) | No native | Yes (5 channels parallel) | Yes — ~100 client scale | Lab / SOC rack-mount; multi-radio parallel ops | Same |
| ESP32 Marauder on AWOK Dual Touch V3 | ~$80 (module; Flipper required) | Yes (dual ESP32-WROOM-32U; deauth, evil-twin, beacon flood) | No (2.4 GHz only) | No | Yes (BLE scan; spoof; spam) | Yes (firmware-managed) | Yes (deauth, beacon flood, evil portal) | Pocketable Marauder host; daily-driver for Wi-Fi/BLE recon | ../../ESP32 Marauder Firmware/03-outputs/ESP32_Marauder_Firmware_Complete.html + ../../AWOK Dual Touch V3/03-outputs/AWOK_Dual_Touch_V3_Complete.html |
| ESP32 Marauder on Flipper Zero WiFi Devboard | ~$30 (devboard; Flipper required) | Yes (ESP32-S2; deauth, beacon, evil portal) | No | No | Limited (S2 has no BT radio) | Yes | Yes | Lightest Marauder host; integrated with Flipper apps | ../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html |
| Ruckus Game Over | ~$120 | Yes (ESP32-S3) | No | No | Yes | Yes | Yes | OLED + joystick + microSD; CC1101/NRF24 daughter slot | (Promoted to its own project; deep dive aspirational) |
| Nyan Box | ~$120 | Yes (ESP32-WROOM-32U) | No | No | Yes (BLE-adjacent via NRF24 triple-radio) | Yes | Yes | Triple-NRF24 parallel sniffing; drone RemoteID, hidden-camera detection | ../../Nyan Box/03-outputs/NyanBox_Complete.html |
| Flipper Zero (without WiFi Devboard) | $170 | No (no Wi-Fi radio on Flipper itself) | No | No | Yes (BLE scan, spoof, BLE-spam apps) | No (no Wi-Fi capability) | BLE only | BLE pocketable platform; pair with Devboard for Wi-Fi | ../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html |
| Alfa AWUS036ACH | ~$45 | Yes (RTL8812AU) | Yes (RTL8812AU dual-band) | No | No | Yes (via aircrack-ng RTL8812AU driver) | Yes (injection) | Practitioner-standard USB adapter; pair with any Linux host | (No Hack Tools deep dive; canonical companion adapter) |
| Alfa AWUS036ACM | ~$60 | Yes (MT7612U) | Yes (MT7612U) | No | No | Yes (native mt76 driver) | Yes | The Hak5 / WiFi Pineapple companion adapter; cleanest Linux support | (No Hack Tools deep dive) |
| Alfa AWUS1900 | ~$90 | Yes (RTL8814AU, 4×4 MIMO) | Yes | No | No | Yes | Yes | Highest-power Alfa; 4×4 antenna array for long-range capture | (No Hack Tools deep dive) |
| Ubertooth One | ~$120 | No (Wi-Fi out of scope) | No | No | Yes — dedicated BLE sniffer | N/A (BLE-only) | Limited TX (class-1 BT) | The Wi-Fi-out-of-scope answer for “I need to see the BLE bits on the wire” | (No Hack Tools deep dive; Michael Ossmann / Great Scott Gadgets product) |
| nRF52840 USB Dongle + Sniffle firmware | ~$15 | No | No | No | Yes — BLE 5 sniffer with channel-following | N/A | Limited | Cheapest reliable BLE-5-capable sniffer; pairs with Wireshark | (No Hack Tools deep dive; Nordic Semiconductor part) |
Table 14.6 — Wi-Fi and BLE platform comparison across the Hack Tools lineup plus the canonical USB and BLE-sniffer adjuncts that practitioners use alongside. The platform groupings: WiFi Pineapple family — purpose-built Wi-Fi audit hardware with the longest-running pedigree (Hak5 since 2008); ESP32-Marauder handhelds — the affordable, pocketable Wi-Fi/BLE attack platform that scales from Flipper-Devboard ($30) to AWOK Dual Touch V3 ($80) to Ruckus Game Over ($120) to Nyan Box ($120) at the high end; Alfa USB adapters — the practitioner-standard host-side capture radios that pair with any Linux pentest box (Kali, Parrot, Ubuntu); dedicated BLE sniffers — Ubertooth One and the nRF52840 dongle covering the BLE-PHY-capture niche that neither the WiFi Pineapple nor the Marauder handhelds handle.
6.2 The decision graph — which platform to reach for
The working pattern for “which platform for which job”:
- “I need to do a full Wi-Fi audit of a customer site (authorized engagement).” → WiFi Pineapple Mark VII + AC Tactical with the MK7AC adapter, paired with an Alfa AWUS036ACM as the supplementary capture radio. The Pineapple drives the rogue-AP and Campaign workflow; the Alfa handles directional and long-range capture. This is the canonical authorized-Wi-Fi-pentest field kit.
- “I want to recon Wi-Fi in the wild — wardriving, building a BSSID map of an area.” → AWOK Dual Touch V3 running Marauder. The handheld form factor + integrated GPS makes wardriving practical; the dual ESP32-WROOM gives one radio for scan, one for capture/attack. The captured data goes into Wigle-format CSV for upload.
- “I need to see actual BLE packets on the wire — I can’t tell what’s happening from the host stack.” → Ubertooth One (channel-following BLE 4.x; some BLE 5) or nRF52840 dongle with Sniffle firmware (BLE 5 native). Either feeds Wireshark with the BLE dissector.
- “I want to develop a BLE attack against a specific device — fuzz GATT, probe characteristics.” → Bleak (Python) on a Linux host with the host’s built-in BT adapter. For passive observation of the developed attack as it runs, add an Ubertooth or Sniffle dongle for the sniff side.
- “I need to do BLE-spam (Apple-notification spam, Samsung-pairing-popup spam) as an authorized-demo educational exercise.” → Flipper Zero with the BLE Spam app (educational; the legal envelope is narrow — see §7). The Flipper’s BLE chip is the right size for this; the AWOK and Ruckus modules also run BLE-spam payloads but at higher power.
- “I’m operating a SOC and need rogue-AP detection across multiple offices.” → WiFi Pineapple Enterprise as a sensor; Cloud C2 for aggregation; Kismet as the open-source alternative. See Vol 10 §3.7.
- “I need parallel-channel sniffing across multiple 2.4 GHz protocols (BLE + NRF24 toys + drones).” → Nyan Box — the triple-NRF24 architecture is purpose-built for this. The drone RemoteID and hidden-camera detection are unique features in the lineup.
6.3 The notable gear that’s not in the lineup
A few canonical Wi-Fi/BLE tools are not part of the Hack Tools lineup but appear in the broader research field and are worth knowing exist:
- Pwnagotchi. ESP32-based AI-driven WPA2 handshake-collector — the “Tamagotchi for WPA captures” hobbyist project. Captures handshakes opportunistically with reinforcement-learning-tuned channel hopping. Cute, effective for ambient handshake collection, no offensive capability beyond capture.
- WiFi Coconut. Hak5’s 14-radio simultaneous-channel-monitor — captures every 2.4 GHz channel at once. Specialist tool for full-spectrum monitoring; expensive (~$300) for the use case.
- Hak5 Shark Jack. Plug-in Ethernet implant that runs a small Kali-derivative OS. Wired-network adjunct to the wireless tools.
- TI CC1352P-Launchpad with SmartRF Sniffer. Texas Instruments’ professional 2.4 GHz packet sniffer — covers BLE, Zigbee, 802.15.4, proprietary 2.4 GHz protocols. Heavier learning curve than Ubertooth or nRF52840 but covers more of the 2.4 GHz protocol family.
- Kismet (software, not hardware). The canonical open-source wireless monitoring framework; runs on any monitor-mode-capable Linux host. The defensive WIDS that pairs with the offensive tools above; treated in Vol 10 §3.7.
The Hack Tools lineup’s Wi-Fi/BLE coverage is biased toward purpose-built attack hardware (WiFi Pineapple family; Marauder-running ESP32 handhelds; Nyan Box’s multi-radio architecture); the host-side capture and analysis software (Wireshark, Kismet, hcxdumptool, hashcat, bettercap, the Python BLE ecosystem) runs on the practitioner’s general-purpose Linux box and is platform-independent.
7. Legal and regulatory
The legal framing for Wi-Fi and BLE security research splits along the same axes Vol 13 §7 covered for sub-GHz, with two differences that shift the risk profile sharply: the active attacks at this layer are more powerful (a single deauth frame disrupts a connection; a rogue-AP attracts traffic; a captured handshake yields long-term key material), and the protected-services population is larger (everyone’s phone, everyone’s laptop, every smart-home device — all on the same 2.4/5/6 GHz bands). The cumulative effect is that the same lab-discipline rule applies — own the gear, own the RF space, hold authorization in writing — but the consequences of getting it wrong scale up.
The line — load-bearing callout. Deauthentication frames are transmission. Rogue-AP beacons are transmission. BLE-spam packets are transmission. Captured handshakes used for cracking are interception of an electronic communication — within ECPA’s scope. Replay of any captured frame against any third-party network is a CFAA “without authorization” event. Wi-Fi and BLE attacks have the same legal weight as wired-network attacks; the RF medium does not soften the offense. The federal CFAA includes felony provisions for unauthorized access; unauthorized active Wi-Fi attacks can carry felony-level penalties under combinations of CFAA, ECPA, and the FCC’s anti-interference statutes. For an authorized red-team engagement, the same paperwork stack covered in Vol 6 §1 and Vol 11 §3.6 applies — SOW, scope document, ROE, get-out-of-jail letter — and the Wi-Fi and BLE attack surfaces must be enumerated explicitly in the scope. The lab-discipline baseline at
../../_shared/legal_ethics.mdcovers the framework that applies to every Hack Tools project including this one.
7.1 The TX-vs-RX axis at Wi-Fi/BLE
The same TX-vs-RX framing from Vol 13 §7 carries forward, with the specific Wi-Fi/BLE TX activities enumerated:
Receive-only activities — generally permitted in US RF space, subject to the Vol 13 §7.1 ECPA exceptions:
- Passive monitor-mode capture of beacons, probe requests, and unicast frames (the frames are radiating into your RF space; the radio reception is not the issue).
- Capturing 4-way EAPOL handshakes is passive; the legality question is what is done with the resulting cracked PSK, not the capture itself.
- BLE scanning and GATT enumeration of advertisements is passive; reading characteristic values on a connected device that didn’t authorize the read is the question, not the scan.
- WIDS deployment on networks you operate.
Transmit / active activities — structurally regulated:
- Deauthentication frame injection. The FCC’s 2014/2015 enforcement actions against Marriott (2014, $600k consent decree) and Smart City Holdings (2015, $750k) established that intentionally interfering with another’s Wi-Fi via deauth is unlawful under Communications Act § 333 — even on networks you operate, if you’re using it to suppress competing networks.23 The FCC’s framing: “No hotel, convention center, or other commercial establishment or the network operator providing services at such establishments may intentionally block or disrupt personal Wi-Fi hot spots on such premises.”24 In a security-research context, deauth is permissible against networks you own or have written authorization to test; outside that envelope it is a Communications Act violation regardless of intent.
- Rogue-AP deployment. Standing up a rogue AP that matches a third party’s SSID — without their permission — to attract traffic is simultaneously a Part 15 transmission, an ECPA interception (the traffic captured is interception of electronic communications), a CFAA “without authorization” event for any subsequent system access, and potentially a trademark/passing-off issue. Multiple actors have been federally charged under this stack.
- BLE-spam attacks. The “Apple notification spam” and “Samsung pairing popup spam” demonstrations — broadcasting BLE advertisement packets that trigger system-level UI on nearby devices — are active transmission. In US RF space they are arguably Part 15 transmissions; if used to disrupt the operation of others’ devices they cross into § 333 territory. The educational-demo framing is the operator’s defense; the legal envelope is narrow.
- Beacon flooding. Same legal weight as deauth flooding — intentional interference with the RF space’s other users.
7.2 The CFAA / ECPA layers
Beyond the FCC spectrum-management framework, three federal-statute layers apply specifically to Wi-Fi and BLE active work:
- Computer Fraud and Abuse Act (18 U.S.C. § 1030). “Without authorization” or “exceeding authorized access” to a “protected computer.” A Wi-Fi network is a computer system; associating with one you’re not authorized to use is § 1030(a)(2) at minimum. Felony enhancements apply for damage, financial loss, or commercial-purpose attacks. The CFAA has produced multiple Wi-Fi-related prosecutions; the Auernheimer (weev) case is a high-profile cautionary example, although that conviction was vacated on venue grounds rather than the underlying CFAA theory.
- Electronic Communications Privacy Act of 1986 (18 U.S.C. § 2510 et seq.). Wi-Fi traffic over an open or PSK network is electronic communication; deliberately intercepting it for the contents (not just metadata) implicates the Wiretap Act. The First Circuit in Joffe v. Google (2013) held that unencrypted Wi-Fi payload capture (the Street View Wi-Fi-payload-capture case) was not exempted by the “readily accessible to the general public” exception — meaning ECPA can apply even to open-network capture. Encrypted Wi-Fi capture (the WPA2 ciphertext) is in the same category as encrypted communications generally — interception with intent to decrypt is the issue.
- State computer-crime statutes. Every US state has its own analog of the CFAA, often with broader scope than the federal statute. Many state statutes treat unauthorized Wi-Fi access as an independent offense (Texas Penal Code §§ 33.02, California Penal Code § 502, etc.). The state-law exposure adds to the federal exposure, not in place of it.
7.3 International context
Outside the US the regulatory pattern is similar in structure with jurisdiction-specific details:
- EU / ETSI. ETSI EN 300 328 governs 2.4 GHz ISM transmissions; ETSI EN 301 893 governs 5 GHz. Active Wi-Fi attacks fall under member-state computer-crime law (UK Computer Misuse Act 1990 — recently substantially amended; German § 202a-c StGB; French Article 323-1 et seq.). GDPR adds a data-protection layer for any captured personal data, with substantial fines for unauthorized processing.
- UK. Computer Misuse Act 1990; Investigatory Powers Act 2016 (formerly RIPA 2000) for interception. Ofcom administers spectrum.
- Japan / Korea / Australia. Each has its own spectrum administrator (MIC, KCC, ACMA) and computer-crime statute. The pattern is the same: receive is broadly permitted; transmit is regulated; unauthorized access to systems is criminal.
- The “I didn’t know it was illegal here” defense doesn’t fly. Operators travelling with WiFi-Pineapple-class hardware are responsible for understanding the destination jurisdiction’s rules. Some jurisdictions (most notably the UAE) treat unauthorized SDR or Wi-Fi audit hardware as customs-controlled imports.
7.4 The lab-discipline rule at Wi-Fi/BLE
The project-wide legal_ethics.md baseline — own the hardware you’re testing or have written authorization to test it; operate inside an RF environment you control or have authorization to occupy; record what you’re doing so the engagement is auditable — covers the Wi-Fi/BLE attack surface cleanly. The high-risk cases the operator should think about in advance:
- The Wi-Fi/BLE attack envelope is bigger than the sub-GHz envelope; an active attack reaches further (literal radio range) and affects more bystanders (everyone in earshot has a Wi-Fi device). RF posture in dense environments — apartment buildings, downtown office space, hotels, airports, conferences — requires deliberate operational care. A WiFi Pineapple firing PineAP modules in a coffee shop is not a research demonstration; it is a federal incident waiting to be the FBI’s next press release.
- Authorized engagements should explicitly enumerate Wi-Fi/BLE active techniques in the Scope of Work — “deauth flooding against in-scope SSIDs,” “rogue-AP deployment against client devices on the test network,” “BLE GATT enumeration of devices in the test premises.” A SOW that says “test the wireless network” without that enumeration is inadequate paperwork.
- BLE attacks against medical devices (insulin pumps, pacemakers, CGMs), automotive systems (keyless entry, infotainment), and industrial systems carry additional regulatory layers (FDA, NHTSA, OT-specific frameworks). Engagements touching those classes need specialized scope review.
- “I was just testing my own equipment” is not a defense if the RF effect of the test reaches third-party equipment. The deauth flood targeted at the operator’s AP is also disrupting the neighbor’s AP if they’re on the same channel.
See Vol 19 (when authored) for the full statutory walkthrough; the canonical Wi-Fi enforcement cases — Marriott 2014, Smart City Holdings 2015, the Joffe v. Google Street View case — are the working precedents.
8. Cross-reference index
The Vol 14 contribution to the canonical anchor index that Vol 21 consolidates. The nine H2 headings below are frozen append-only as of this volume’s first commit — renaming any of them changes the auto-generated vol14-<slug> anchor and silently breaks inbound links.
| From | Anchor target in Vol 14 | Context |
|---|---|---|
| Vol 7 §3 | #vol14-the-rogue-ap-family-techniques-and-lineage | Criminal-economy rogue-AP / handshake-crack tooling — Vol 14 §3 is the engineering reference. |
| Vol 7 §3 | #vol14-the-handshake-capture-and-offline-crack-pipeline | The hashcat + PMKID economics that make WPA2 cracking commercially viable. |
| Vol 10 §3.7 | #vol14-the-rogue-ap-family-techniques-and-lineage | Defender’s view: Kismet + WIDS for KARMA/MANA/known-beacons detection. |
| Vol 10 §3.7 | #vol14-the-80211-attack-surface | Frame-type and PMF context for SOC monitoring and detection rules. |
| Vol 11 §3.6 | #vol14-the-gear-wi-fi-and-ble-platform-comparison | Red-team physical-entry RF/HID staging — WiFi Pineapple + Marauder in the operator’s kit. |
| Vol 11 §3.6 | #vol14-the-rogue-ap-family-techniques-and-lineage | The authorized red-team operator’s rogue-AP technique reference. |
| Vol 13 §3 | #vol14-the-80211-attack-surface | Vol 13’s spectrum table hands off the 2.4/5/6 GHz rows to Vol 14. |
| Vol 13 §7 | #vol14-legal-and-regulatory | Vol 13’s TX-vs-RX legal frame extends here with the Wi-Fi/BLE specifics. |
| WiFi Pineapple deep dive | #vol14-the-rogue-ap-family-techniques-and-lineage | The KARMA/MANA/known-beacons engineering context for the PineAP modules. |
| WiFi Pineapple deep dive | #vol14-the-handshake-capture-and-offline-crack-pipeline | The handshake-capture workflow the Pineapple’s PineAP modules implement. |
| ESP32 Marauder Firmware deep dive | #vol14-the-80211-attack-surface | The Wi-Fi protocol context behind Marauder’s scan and attack subsystems. |
| ESP32 Marauder Firmware deep dive | #vol14-ble-the-protocol-and-the-attack-surface | The BLE protocol context behind Marauder’s BLE scan + BLE spam features. |
| AWOK Dual Touch V3 deep dive | #vol14-the-gear-wi-fi-and-ble-platform-comparison | AWOK Dual Touch V3 as the daily-driver Marauder host in Vol 14’s gear table. |
| Nyan Box deep dive | #vol14-ble-the-protocol-and-the-attack-surface | The triple-NRF24 architecture’s parallel BLE-adjacent sniffing. |
| Flipper Zero deep dive | #vol14-ble-the-protocol-and-the-attack-surface | Flipper’s BLE module — scan, spoof, BLE-spam apps. |
| Vol 15 (RF Tradecraft III) | #vol14-the-80211-attack-surface | RFID/NFC vs Wi-Fi — the band-and-distance distinction. |
| Vol 20 (Cheatsheet) | All §2-§6 working commands | The Wi-Fi/BLE field-card material. |
| Vol 21 (Glossary + canonical anchor index) | Every Vol 14 H2 anchor | Vol 21 consolidates the series anchor catalog. |
Table 14.7 — The Vol 14 cross-reference index. The pattern matches Vol 13’s: hat volumes link out for technical depth, tool deep dives link in to ground their hardware in the broader tradecraft, the reference cluster siblings (Vol 13, 15) build on adjacent foundations. The append-only discipline on the H2 headings is what keeps this index stable across the deep-dive cluster.
The frozen H2 anchors as committed in this volume:
#vol14-about-this-volume#vol14-the-80211-attack-surface#vol14-the-rogue-ap-family-techniques-and-lineage#vol14-the-handshake-capture-and-offline-crack-pipeline#vol14-ble-the-protocol-and-the-attack-surface#vol14-the-gear-wi-fi-and-ble-platform-comparison#vol14-legal-and-regulatory#vol14-cross-reference-index#vol14-resources
9. Resources
Primary references for Vol 14, organized by topic, with footnoted citations to the specific papers, tools, statutes, and books.
802.11 standard and Wi-Fi security generations. The IEEE 802.11-2020 standard1 is the canonical reference for the frame structure, association protocol, and security framework. The IEEE 802.11w-2009 amendment2 specifies Protected Management Frames. The Wi-Fi Alliance’s WPA3 specification25 is the authoritative reference for SAE / Dragonfly and the WPA3-Enterprise 192-bit suite.
Rogue-AP and KARMA-family attacks. Dino Dai Zovi and Shane Macaulay’s 2004 PacSec paper “All Your Layer Are Belong To Us”6 is the canonical KARMA reference. The MANA toolkit’s DEF CON 22 (2014) introduction by Dominic White and Ian de Villiers (SensePost) is documented in the SensePost blog and the GitHub repository.10 11 HD Moore’s Karmetasploit integration is documented in the Metasploit Framework’s wiki and in the Metasploit: The Penetration Tester’s Guide book (Kennedy / O’Gorman / Kearns / Aharoni, No Starch Press 2011).8
Handshake-capture and PMKID. Jens Steube’s August 4, 2018 hashcat-forum disclosure16 of the PMKID attack against WPA/WPA2 is the canonical primary source. The aircrack-ng suite13 is the long-standing reference toolchain for handshake capture; the hcxdumptool / hcxtools family by ZerBea14 is the modern PMKID-optimized successor. Hashcat26 in -m 22000 mode handles both 4-way EAPOL and PMKID handshakes in the unified format.
WPA3 and Dragonblood. Mathy Vanhoef and Eyal Ronen’s 2019 paper “Dragonblood: A Security Analysis of WPA3’s SAE Handshake”17 is the canonical WPA3 attack reference (published at the IEEE Symposium on Security and Privacy 2020 after the initial disclosure in April 2019). Vanhoef’s KRACK 2017 paper27 is the predecessor work on WPA2 key reinstallation. The Vanhoef / Schepers 2022 paper on 802.11w deauthentication countermeasures4 documents the residual broadcast-deauth attack surface that PMF didn’t fully close.
BLE protocol and attacks. The Bluetooth Core Specification19 is the authoritative reference for the BLE protocol stack; the Bluetooth SIG also publishes individual Profile and Service specifications.18 Mike Ryan’s Crackle (2013)20 documented the BLE Legacy Pairing vulnerability. Armis’s BlueBorne disclosure (September 12, 2017)21 is the canonical Bluetooth-stack-vulnerability reference; the 8 CVEs and the technical white paper are publicly available. The ESL-attack research (2023) is documented in IOActive’s disclosure series.22
Tools and platforms. The Ubertooth One project28 by Michael Ossmann / Great Scott Gadgets is the foundational open-source BLE / Bluetooth Classic sniffer. The Sniffle BLE-5 sniffer firmware for the nRF5284029 is the modern BLE-5-capable equivalent. The Alfa Network adapter family30 (AWUS036ACH, AWUS036ACM, AWUS1900) is the practitioner-standard USB-adapter line.
FCC enforcement cases. The FCC’s 2014 Marriott consent decree23 and the 2015 Smart City Holdings consent decree31 are the canonical published precedents for deauthentication-as-§-333-interference. The FCC’s January 2015 enforcement-advisory statement24 is the operative public guidance.
Sibling Hack Tools deep dives — the device-level depth that this volume deliberately doesn’t duplicate:
- WiFi Pineapple deep dive:
../../WiFi Pineapple/03-outputs/WiFiPineapple_Complete.html - ESP32 Marauder Firmware deep dive:
../../ESP32 Marauder Firmware/03-outputs/ESP32_Marauder_Firmware_Complete.html - AWOK Dual Touch V3 deep dive:
../../AWOK Dual Touch V3/03-outputs/AWOK_Dual_Touch_V3_Complete.html - Nyan Box deep dive:
../../Nyan Box/03-outputs/NyanBox_Complete.html - Flipper Zero deep dive:
../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html
Series cross-references in this volume. Vol 7 §3 for the criminal-economy rogue-AP tooling. Vol 10 §3.7 for the defender’s view of the same attack family. Vol 11 §3.6 for the red-team operator’s physical-entry RF/HID staging. Vol 13 for SDR fundamentals + sub-GHz coverage; Vol 13 §3 for the 2.4/5/6 GHz spectrum-map rows that hand off to this volume; Vol 13 §7 for the TX-vs-RX legal baseline this volume extends. Vol 15, Vol 16, Vol 17 for the rest of the reference cluster. Vol 19 (when authored) for the full statutory walkthrough of the CFAA / ECPA / Communications Act framework.
Footnotes
-
IEEE Std 802.11-2020, IEEE Standard for Information technology — Telecommunications and information exchange between systems Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. The consolidated 802.11 standard incorporating amendments through 802.11ax. Authoritative reference for frame structure, association protocol, and security framework. https://standards.ieee.org/ieee/802.11/7028/. ↩ ↩2
-
IEEE Std 802.11w-2009, Amendment 4: Protected Management Frames. Specifies the MIC mechanism that protects deauthentication, disassociation, and robust action management frames against forgery. Mandatory in WPA3; optional in WPA2. https://standards.ieee.org/ieee/802.11w/3768/. ↩ ↩2
-
Hak5 store, Alfa AWUS036ACM product listing. https://shop.hak5.org/products/alfa-awus036acm. The WiFi-Pineapple-companion adapter recommendation; MT7612U-based, dual-band, native Linux mt76 driver support. ↩
-
Domien Schepers, Aanjhan Ranganathan, Mathy Vanhoef, “On the Robustness of Wi-Fi Deauthentication Countermeasures”, ACM WiSec 2022. Documents residual broadcast-deauth attack surface that PMF doesn’t fully close, along with proof-of-concept exploits and proposed patches. https://papers.mathyvanhoef.com/wisec2022.pdf. ↩ ↩2
-
Mathy Vanhoef and Eyal Ronen, Dragonblood: Analysing WPA3’s Dragonfly Handshake, project page with paper and tools. https://wpa3.mathyvanhoef.com/. The companion site to the academic paper; includes the Dragonslayer tool for testing implementations. ↩
-
Dino A. Dai Zovi and Shane A. Macaulay, “All Your Layer Are Belong To Us”, PacSec Tokyo 2004. The original KARMA disclosure — wireless-client probe-response automated rogue AP. The accompanying tool KARMA (KARMA Attacks Radio’d Machines Automatically) implemented the attack on Linux. Slides and tool referenced in subsequent literature including Wikipedia’s KARMA attack page. https://en.wikipedia.org/wiki/KARMA_attack. ↩ ↩2 ↩3
-
WiFi Pineapple deep dive —
../../WiFi Pineapple/03-outputs/WiFiPineapple_Complete.html. 21-volume engineer-grade reference covering all four current models (Mark VII / Mark VII + AC Tactical / Pager / Enterprise), the PineAP / KARMA / MANA / known-beacons engine implementation, the Modules / Campaigns / Cloud C2 ecosystem, and the operational posture. The most posture-sensitive tool in the Hack Tools lineup. ↩ -
HD Moore, Karmetasploit — Metasploit Framework integration of KARMA-style rogue AP with Metasploit’s exploitation modules (2007+). Documented in Kennedy / O’Gorman / Kearns / Aharoni, Metasploit: The Penetration Tester’s Guide, No Starch Press 2011, Chapter 12 (“Karmetasploit”). https://www.oreilly.com/library/view/metasploit/9781593272883/ch12.html. ↩ ↩2
-
Hak5 Jasager — the WiFi Pineapple firmware that implements KARMA-style rogue AP on OpenWrt hardware (originally Fonera). The genealogical root of the modern WiFi Pineapple line. The Pineapple’s full lineage from 2008 (Jasager) through the Mark VII / Pager / Enterprise of 2026 is in the WiFi Pineapple deep dive
../../WiFi Pineapple/03-outputs/WiFiPineapple_Complete.html. ↩ -
Dominic White and Ian de Villiers (SensePost), “Manna from Heaven: Improving the State of Wireless Rogue AP Attacks”, DEF CON 22 (2014). The MANA toolkit’s introduction; SensePost blog post series “Improvements in Rogue AP Attacks — MANA 1/2” (2015) is the post-conference engineering write-up. https://sensepost.com/blog/2015/improvements-in-rogue-ap-attacks-mana-1/2/. ↩ ↩2
-
SensePost MANA toolkit (DEPRECATED in favor of
hostapd-manaandbettercap). GitHub repository: https://github.com/sensepost/mana. The deprecation note explicitly recommends bettercap and berate-ap as the modern orchestration layer;hostapd-manais the underlying daemon, still actively developed. ↩ ↩2 -
Lovinger et al., “Lovin’ the Hostspots: Beacon-based rogue-AP attacks against modern Wi-Fi clients” (2018). Formalized the known-beacons attack against post-KARMA client behavior. Implemented in
wifiphisher,eaphammer, and the WiFi Pineapple PineAP modules. ↩ -
Aircrack-ng — open-source 802.11 WEP/WPA/WPA2 audit suite. Authors: Thomas d’Otreppe and contributors. https://www.aircrack-ng.org/. The long-running canonical Wi-Fi audit toolchain; includes
airmon-ng,airodump-ng,aireplay-ng,aircrack-ng(the cracker),airdecap-ng. License: GPL. ↩ ↩2 -
ZerBea, hcxdumptool — high-performance WPA/WPA2 capture tool optimized for handing off to hashcat. https://github.com/ZerBea/hcxdumptool. Companion:
hcxtools(includinghcxpcapngtoolfor format conversion). The modern post-Steube workflow defaults tohcxdumptoolfor capture and hashcat for cracking;aircrack-ngretains its place for monitor-mode management and for direct WEP cracking. ↩ ↩2 -
Hashcat mode 22000 documentation and format reference. https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2. The unified
WPA*format covers both 4-way EAPOL and PMKID captures with a single hashcat invocation. ↩ -
Jens Steube (“atom”), “New attack on WPA/WPA2 using PMKID”, hashcat forum disclosure, August 4, 2018. The original public disclosure of the PMKID attack against WPA/WPA2. Available at the hashcat forums; widely mirrored, including in the Cisco Talos and Meraki technical briefings of August 2018. https://hashcat.net/forum/thread-7717.html. ↩ ↩2
-
Mathy Vanhoef and Eyal Ronen, “Dragonblood: A Security Analysis of WPA3’s SAE Handshake”, IEEE Symposium on Security and Privacy (S&P) 2020 (initial disclosure April 2019). https://eprint.iacr.org/2019/383. Companion site: https://wpa3.mathyvanhoef.com/. Documents the SAE side-channel attacks, group-downgrade, and the transition-mode downgrade against deployed WPA3 implementations. ↩ ↩2
-
Bluetooth SIG specifications portal. https://www.bluetooth.com/specifications/specs/. Hosts the Core Specification along with individual Profile and Service specifications (HID, A2DP, GAP, GATT, Mesh, LE Audio, etc.). ↩ ↩2
-
Bluetooth Core Specification, Bluetooth Special Interest Group (Bluetooth SIG). Current version: 5.4 (2023). The authoritative reference for the Bluetooth protocol stack, including the BLE portions. https://www.bluetooth.com/specifications/specs/core-specification-5-4/. Replaces earlier 5.3 (2021), 5.2 (2020), 5.1 (2019), 5.0 (2016), 4.2 (2014), 4.1 (2013), 4.0 (2010, original BLE). ↩ ↩2
-
Mike Ryan, Crackle — BLE Legacy Pairing brute-force tool. Demonstrated that the BLE 4.0/4.1 pairing was vulnerable to passive observation followed by offline TK brute force, yielding the STK and subsequent traffic decryption. https://github.com/mikeryan/crackle. Largely closed by the BLE 4.2 transition to LE Secure Connections (ECDH-based). ↩ ↩2
-
Armis, BlueBorne — The Dangers of Bluetooth Implementations, technical white paper, September 12, 2017. The canonical disclosure of 8 Bluetooth-stack CVEs (CVE-2017-1000251, -1000250, -0785, -0781, -0782, -0783, -8628, -14315) affecting Android, iOS, Linux, and Windows Bluetooth stacks. https://www.armis.com/research/blueborne/. The white paper PDF is mirrored at multiple research repositories. ↩ ↩2
-
IOActive, Electronic Shelf Label (ESL) Security Research — research on BLE-based retail price-display systems demonstrating spoofed-advertisement price-change attacks (2023). Disclosed at major security conferences; vendor patches and operational mitigations followed. ↩ ↩2
-
In the Matter of Marriott International, Inc., FCC consent decree DA 14-1444, October 3, 2014. $600,000 settlement for intentionally interfering with attendee Wi-Fi hotspots at Marriott’s Gaylord Opryland Resort by transmitting deauthentication frames. Established the operational FCC reading of Communications Act § 333 against deauth-as-jamming. https://www.fcc.gov/document/marriott-pay-600k-resolve-wifi-blocking-investigation. ↩ ↩2
-
FCC Enforcement Bureau, “Warning: Wi-Fi Blocking is Prohibited”, Enforcement Advisory No. 2015-01, January 27, 2015. The FCC’s operative public guidance on deauth-as-jamming. https://www.fcc.gov/document/warning-wi-fi-blocking-prohibited. ↩ ↩2
-
Wi-Fi Alliance, WPA3 Specification, Version 3.4 (December 2024). The authoritative reference for WPA3-Personal (SAE) and WPA3-Enterprise (192-bit suite). https://www.wi-fi.org/file/wpa3-specification. ↩
-
Hashcat — the world’s fastest password cracker. Author: Jens Steube (“atom”) and contributors. https://hashcat.net/hashcat/. Mode 22000 (combined WPA*/PMKID-PBKDF2-HMAC-SHA1) is the canonical mode for WPA2/WPA3 PSK attacks since hashcat 6.0; supersedes earlier modes 2500 (WPA-EAPOL) and 16800 (WPA-PMKID). ↩
-
Mathy Vanhoef and Frank Piessens, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”, ACM CCS 2017. https://www.krackattacks.com/. The KRACK paper; demonstrated that blocking Msg 4 of the 4-way handshake forces PTK reinstallation and nonce reuse on subsequent traffic. Patched in client OSes from October 2017 onward. ↩
-
Michael Ossmann / Great Scott Gadgets, Ubertooth One — open-source Bluetooth Classic and BLE sniffer. CC2400 wireless transceiver + CC2591 RF front-end + LPC175x ARM Cortex-M3 microcontroller; USB 2.0 host interface; 2.4 GHz ISM band; class-1 Bluetooth transmit power. Source and documentation: https://greatscottgadgets.com/ubertoothone/. The first affordable open-source BT/BLE monitoring platform; commercial equivalents started at ~$10k pre-Ubertooth. ↩
-
Sultan Qasim Khan, Sniffle — BLE 5 sniffer firmware for Nordic nRF52840 USB Dongle. Open-source; supports BLE 5 advertising and connections including LE 2M PHY and LE Coded PHY. Feeds Wireshark via the extcap interface. https://github.com/nccgroup/Sniffle. Maintained by NCC Group. ↩
-
Alfa Network — Taiwanese manufacturer of high-power USB Wi-Fi adapters widely used in security research. Product line includes AWUS036ACH (RTL8812AU, dual-band), AWUS036ACM (MT7612U, dual-band, native Linux), AWUS1900 (RTL8814AU, 4×4 MIMO). https://www.alfa.com.tw/. The de-facto standard practitioner-companion USB adapter family for monitor-mode Wi-Fi work. ↩
-
In the Matter of Smart City Holdings, LLC, FCC consent decree DA 15-917, August 18, 2015. $750,000 settlement for intentional interference with personal Wi-Fi hotspots at convention centers via deauth frames. Reinforces the Marriott precedent. https://www.fcc.gov/document/smart-city-pay-750k-resolve-wi-fi-blocking-investigation. ↩