Resources

Select an SDR whose instantaneous bandwidth covers the target, tune to the centre frequency, set sample rate ≥ signal bandwidth, and record I/Q to disk. Log overflow/dropped-sample counters — a capture with overflows is silently incomplete. Reference radios: RTL-SDR V4 (narrow), HackRF One (~20 MHz), USRP B210 (~56 MHz, GPSDO), bladeRF 2.0 (~61 MHz).

When full-band capture is impossible, recover the hop sequence/parameters from connection setup and retune per hop, or channelise the whole band (RFSAM-RES-03). For BLE, the hop interval and channel map are negotiated at connection time and visible to a sniffer that catches the connection request.

Split a wide I/Q stream into many narrow channels using a polyphase filterbank + FFT offloaded to the GPU (OpenCL / VkFFT). This makes real-time multi-channel demodulation tractable where CPU channelisation throttles and drops samples. Reference: the ice9-bluetooth-sniffer approach for the BLE band.

Drive a Sniffle-class sniffer (e.g. CatSniffer / CC1352) to passively scan advertising channels, then connect and enumerate GATT to audit for unencrypted readable/writable characteristics. Audit-on-discovery sweeps every connectable advertiser as it is found, classifying address type and recording writable handles without authentication.

After connecting, discover all services and characteristics, attempt reads on readable handles, and identify writable handles reachable without encryption. A REPL workflow (read/write/subscribe/terminate) lets the auditor replay learned commands and observe device response.

Follow an established connection’s hop sequence, stabilise over several connection events, then transmit as master to evict the original central. The clean pattern is hijack → LL_TERMINATE_IND → reconnect. Implementation note: set the decoder’s current Access Address to the connection AA only after reaching CENTRAL (flush first); advertisements during INITIATING reset it to the advertising AA and break data-PDU decoding.

Capture the ISM sub-band to I/Q, de-chirp with a soft-decision LoRa demodulator (gr-lora_sdr class), then parse the LoRaWAN frame: MHDR, MType, DevAddr, and — for joins — AppEUI/DevEUI/DevNonce in clear; application payload remains AES-128 encrypted. Classify by MType to profile the network passively.

Scan bands with a capable modem to list operators/EARFCNs, run cell search to recover PCI from PSS/SSS, then capture the target EARFCN on a GPSDO-disciplined SDR. Decode MIB (PBCH) for bandwidth and frame number before higher-layer work.

Lock the SDR to a GPSDO; confirm clock rate and register loopback. Validate the host can sustain the sample rate (host I/O can cause MIB-decode failures even when the SDR is fine). Coherence is mandatory for OFDM grid recovery.

From a recovered resource grid, blind-decode PDCCH: enumerate the search space, run Viterbi on each candidate, and validate by CRC masked with the candidate RNTI. Open-source tooling (LTESniffer / FALCON class) performs this passively; pair with SIB/paging decode for configuration and identity exposure.

Put a monitor-mode-capable adapter (e.g. ALFA AWUS036ACH / RTL8812AU, or ESP32-C6 Minino) into monitor mode, channel-hop across 2.4/5/6 GHz, and capture all 802.11 frames. Confirm injection support with aireplay-ng —test before relying on active controls. Add GPS for wardriving/geolocation of APs.

Capture the WPA 4-way handshake (optionally forcing it with a deauth where authorised and PMF is absent) or extract the RSN PMKID clientlessly from the AP. Crack offline with hashcat (mode 22000). Check WPS and attempt Pixie Dust / PIN brute-force. A WiFi Pineapple automates evil-twin and capture workflows.

Use a Proxmark3 (hf/lf search) to identify frequency, standard, chip and MIFARE PRNG strength, then run default-key checks and the matching Crypto1 attack (darkside/nested/hardnested). Chameleon and BomberCat (PN7150) read and emulate HF cards; mfkey32 recovers keys from a captured reader exchange.

Clone recovered data to blank/magic cards, or emulate with Chameleon/Proxmark/BomberCat. For NFC relay, use BomberCat RelayNFC (host reads the genuine card, client presents it to the target reader over the network). MagSpoof/BomberCat emulate magnetic-stripe data to legacy readers. Test for reader-side timing/anti-relay defences.

Use a wideband SDR (HackRF) to discover and characterise the burst (frequency, OOK/FSK, bitrate) — Ossmann’s ‘Rapid Radio Reversing’ workflow. Demodulate and reverse the frame in Universal Radio Hacker or GNU Radio. Then drive a CC1101-class transceiver (YARD Stick One + rfcat) at the recovered layer-1 settings to receive, replay or forge. For brute force, generate a De Bruijn sequence (OpenSesame). For rolling codes, assess jam-and-capture (RollJam) and sequential replay (RollBack).

Find the channel first with an energy / cativity scan (Zigbee/Thread pin one of the 16 channels 11–26 at 2.4 GHz), then park a real 802.15.4 radio on it — an nRF52840 (nRF Sniffer), a CatSniffer (catnip), a CC2531 (whsniff) or a KillerBee radio — and stream the raw frames into Wireshark over its extcap, where the 802.15.4 + Zigbee/6LoWPAN/Thread dissector decodes MAC, NWK and (with the network key) the upper layers. Crucially, capture a device joining — that is where the key is transported and where the network opens up.

To read an encrypted 802.15.4 mesh you need the network key, and the weakness is how that key reaches a joining device. Capture a device joining (the APS Transport-Key on Zigbee; the commissioning exchange on Thread), then recover the key: zbdsniff extracts a Zigbee network key transported under the well-known default Trust Center link key ZigBeeAlliance09, while a Thread network key comes from weak / default / exposed commissioning credentials (PSKc, Joiner PSKd) — not from breaking AES. Load the recovered key into Wireshark’s protocol preferences to decrypt the capture in place. Modern S2-style ECDH key exchange resists capture-the-join.

Z-Wave is a sub-GHz (G)FSK protocol on a regional frequency (908.42 MHz in the US, 868.42 MHz in the EU, with other regional bands). Tune an RTL-SDR or HackRF to the region’s frequency and demodulate the ITU-T G.9959 frames with an SDR decoder (rtl-zwave or waving-z) to recover the Home ID, Node IDs and command classes; a Silicon Labs Zniffer on a UZB stick is the vendor path. Capture a device inclusion to assess S0 key transport (the network key is sent under a fixed all-zero temporary key during inclusion); S2 (Curve25519 ECDH) resists capture-the-join.

GNSS is a very weak spread-spectrum signal below the thermal-noise floor (GPS L1 C/A at 1575.42 MHz, around -130 dBm at the antenna). Use an active GNSS antenna and an RTL-SDR / HackRF to record L1 I/Q, then a software receiver (e.g. GNSS-SDR) to acquire satellites, read each one’s carrier-to-noise (C/N0) and the navigation solution. A raised noise floor with no acquisition points to jamming; implausibly strong or uniform C/N0, a position/time jump, or many satellites at identical power are signatures of spoofing.

AUTHORISED, RF-shielded / conducted testing only — never radiate GNSS over the air. Generate a synthetic GNSS scenario (e.g. with gps-sdr-sim) and transmit it on a TX-capable SDR (HackRF / bladeRF / USRP) into a shielded enclosure or a cabled setup, then observe whether the receiver under test locks onto the false position, follows a slow position / time pull-off from the genuine fix, or detects and rejects the attack. Test jamming resilience separately with a controlled in-band noise source. Assess any anti-spoofing the receiver claims (RAIM, signal-authentication, multi-constellation cross-checks).

ADS-B is broadcast and unencrypted. Receive 1090 MHz Mode S Extended Squitter (1090ES, PPM) on an RTL-SDR and decode with dump1090 or readsb to recover the ICAO 24-bit address, callsign, altitude and position from the DF17/DF18 messages; in the US, decode the 978 MHz UAT link with dump978. There is no crypto to break — the security property of interest is the absence of authentication or integrity, which is what makes injection/spoofing possible (and is assessed, authorised and RF-contained, at the Attack step).

Find the 5G NR carrier and its SS/PBCH block (SSB) on a waterfall — FR1 sub-6 GHz is reachable with a USRP-class SDR, while FR2 mmWave (~24–40 GHz) is out of reach of the common kit. There is no drop-in passive SA receiver: the practical routes are to stand up your own gNB (srsRAN Project or OpenAirInterface) with a 5G core and read the SSB / MIB / SIB1 from a controlled cell, to use a research PDCCH/MAC sniffer (5GSniffer / Sni5Gect) on a USRP, or to pull signalling off a Qualcomm 5G modem’s DIAG interface with QCSuper into Wireshark. Note the SUCI conceals the SUPI, so the LTE-style cleartext-IMSI harvest is closed.

Scan a GSM band (850 / 900 / 1800 / 1900) for live base-station carriers with kalibrate, which locks onto each BTS’s FCCH/SCH bursts and reports the ARFCN, its power and the radio’s ppm clock offset. Tune the target ARFCN on an SDR and demodulate with gr-gsm (grgsm_livemon): it decodes the BCCH/CCCH/SDCCH bursts and streams GSMTAP over UDP into Wireshark, where you read the System Information, paging and the Cipher Mode Command — confirming the A5/x cipher in force and whether the cell exposes the IMSI. Easiest on a non-hopping downlink.

UWB cannot be blind-scanned and no SDR in the common kit reaches its >500 MHz-wide channels at 6.5 GHz (ch 5) / 8 GHz (ch 9). Capture 802.15.4z frames with a real UWB transceiver that already knows the link’s channel, preamble code, data rate and STS mode/length: a Qorvo DWM3000EVB running the SEEMOO uwb-sniffer firmware forwards frames to Wireshark with picosecond timestamps, and a controllable DW3000 peer (Makerfabs board / foldedtoad driver) logs the ranging exchanges it participates in. Capturing the frames does not defeat the STS — the research surface is physical-layer distance manipulation, not key recovery.

An SDR cannot follow Bluetooth Classic’s adaptive frequency hopping (~1600 hops/s across 79 channels), so the accessible BR/EDR capture path borrows a device that already owns a real Bluetooth controller. Matheus-Garbelini’s esp32_bluetooth_classic_sniffer patches the ESP32’s Bluetooth ROM stack so the chip dumps the baseband packets it already demodulates — BT header, channel, role, FHS, ACL and LMP — over USB serial to a Python host tool (BTSnifferBREDR.py) that emits Scapy objects and a live Wireshark feed, all on a ~$5–10 board (the original ESP32, not an S3/C-series, which lack the Classic radio). The catch is that it is an active sniffer: it joins the piconet and connects to the target to follow the hop rather than capturing purely passively, so it is for authorised testing on devices you own or are contracted to assess. It is the most practical commodity-hardware alternative to expensive BR/EDR test gear, though coverage and stability vary by target chip and it is no substitute for a calibrated protocol analyser. Pair it with Wireshark for dissection of the exported frames.

The BR/EDR analogue of a BLE advertising scan is an inquiry scan, and an ESP32 can run a real one using its own Bluetooth Classic controller through the Bluedroid GAP API — no SDR required. AntorFr’s ClassicBTScan and esp32beans’s ESP32-BT-exp (a dual-mode Classic + BLE scanner) both bring up the stack and enumerate each discoverable device’s 48-bit BD_ADDR, friendly name, RSSI and Class of Device, which together hint at the device type before any deeper RF work. This only sees devices currently in discoverable / inquiry-scan mode; a non-discoverable device will not answer and must already be addressed by a known BD_ADDR. It also requires the original ESP32 with the BR/EDR radio — the ESP32-S3 and C-series are LE-only and cannot run Classic inquiry. Treat it as the cheap “is anything Classic here, and what is it?” enumeration step that feeds the rest of the descent.

BrakTooth (Garbelini et al., ASSET Research Group, SUTD, 2021) is a directed-fuzzing campaign against the Bluetooth Classic Link Manager Protocol and baseband that found a family of implementation flaws — 16 vulnerabilities plus several anomalous behaviours, spanning 20+ exploit variants — across BR/EDR controllers from many SoC vendors (Espressif, Intel, Qualcomm, Texas Instruments and others). Effects range from crashes and deadlocks to, on at least one chip, arbitrary code execution, and most variants need neither pairing nor authentication to the target. The public proof-of-concept, Matheus-Garbelini’s braktooth_esp32_bluetooth_classic_attacks, fires these malformed LMP/baseband sequences at a target from a cheap ESP32, reusing the same patched-firmware approach as the BR/EDR sniffer. Because these crash or deadlock live devices it is strictly for authorised testing on equipment you own or are contracted to assess. The CVE list and affected-SoC table are representative and date quickly — confirm current vendor patch status rather than trusting the original disclosure.

KNOB (Key Negotiation Of Bluetooth; Antonioli, Tippenhauer and Rasmussen, USENIX Security 2019; CVE-2019-9506) exploits the fact that the BR/EDR encryption key-length negotiation runs before encryption and is itself unauthenticated, letting an attacker in the middle force two victims to agree on an encryption key with as little as 1 byte (8 bits) of entropy. That key is then trivially brute-forced offline, after which the attacker can decrypt eavesdropped traffic and inject valid encrypted frames. It is a protocol-level downgrade against the specification — not a cryptographic break of E0 or AES-CCM — so it affected essentially every spec-compliant BR/EDR device of its era regardless of chip vendor. The mitigation is a host/controller-enforced minimum encryption key length (the Bluetooth SIG recommends rejecting keys below 7 octets), which closes the downgrade without touching the cipher. Performing it requires active man-in-the-middle injection during key negotiation, so it belongs only in authorised testing against devices you own or are contracted to assess.

The supported way to map the BR/EDR application surface is a normal Linux host running the BlueZ stack over any standard USB Bluetooth adapter — the same host path the BSAM Bluetooth controls assume. Start with sdptool browse <BD_ADDR> to walk the device’s SDP service directory and list its exposed profiles and RFCOMM channels, use l2ping <BD_ADDR> to confirm reachability, and drive bluetoothctl to pair and connect. From there, profile-specific tools exercise what the device trusts above the link: obexftp for OBEX object push/pull, and HID/HFP utilities to probe keystroke-injection or hands-free/AT-command surfaces over RFCOMM. This is a legitimate host stack, not a covert injector, so most of it requires the target to be reachable and usually pairable — discoverability, pairing mode and service access control all gate what you can enumerate. It needs no special radio beyond a working BlueZ-supported dongle, which makes it the cheapest and most reproducible entry point into the Classic application layer.