Learn Ethical Hacking Series):Exercise 1: Security pipeline setup (abbreviated).
Flask app with 3 deliberate vulnerabilities:
1. SQLi in /search (caught by Semgrep: python.sqlalchemy.security)
2. AWS key in config.py (caught by gitleaks pre-commit hook)
3. requests 2.25.0 / CVE-2023-32681 (caught by pip-audit)
All 3 caught. Pipeline blocked on secret (pre-commit) and
critical SAST finding. SCA finding generated alert only.
The pre-commit hook caught the AWS key before it ever entered git history -- which is the entire point of the shift-left approach we discussed in episode 67. Once a secret enters git history, it persists in every clone of the repository even after you remove it from the current branch (you would need git filter-branch or BFG Repo-Cleaner to actually purge it, and by then any fork or mirror already has a copy). The Semgrep finding on the SQLi is equally important because it identified the exact line of vulnerable code with a specific rule ID (python.sqlalchemy.security), giving the developer a precise fix location rather than a vague "your app has SQL injection somewhere." The pip-audit SCA finding generated an alert rather than blocking the build -- this matches the balanced gate policy from episode 67 where known-CVE dependencies are treated as "fix within SLA" rather than "stop everything," because upgrading a dependency can introduce breaking changes that need testing.
Exercise 2: SAST comparison on DVWA (abbreviated).
Semgrep: 23 findings, 4 FP, 3.2s scan
CodeQL: 31 findings, 2 FP, 4m20s scan (most thorough)
PHPStan: 18 findings, 7 FP, 12s scan
CodeQL uniquely found multi-function taint flows.
Semgrep best for CI (fast). CodeQL best for nightly deep scans.
The 80x speed difference between Semgrep (3.2 seconds) and CodeQL (4 minutes 20 seconds) explains why both tools exist and neither replaces the other. Semgrep runs on every pull request without anyone noticing -- 3 seconds is invisible in a CI pipeline. CodeQL at 4+ minutes is noticeable, and on a large codebase it can take 15-30 minutes, which is too slow for PR-level feedback but perfect for nightly scans or weekly deep analysis. The false positive rates tell the real story: PHPStan's 7 FP out of 18 findings (39% false positive rate) means developers would quickly learn to ignore its output. Semgrep at 17% and CodeQL at 6% are both within the range where developers trust the findings. CodeQL's uniquely found multi-function taint flows (where user input passes through 3+ functions before reaching the vulnerable sink) demonstrate the value of its semantic database approach -- Semgrep's pattern matching cannot trace data flow across function boundaries the same way.
Exercise 3: Security gate policy (abbreviated).
BLOCK: secrets in code, Critical SAST (RCE/SQLi), CISA KEV CVEs
ALERT: High/Medium SAST (14-day SLA), High SCA (30-day SLA)
IGNORE: Low/Informational findings
Exception: security team approval, 7-day max, tracked in Jira.
The CISA KEV (Known Exploited Vulnerabilities) list as a blocking criterion is a smart choice that most generic gate policies miss. CISA KEV only contains vulnerabilities that are confirmed to be actively exploited in the wild -- not theoretical risks, not "maybe someday" CVEs, but vulnerabilities that real attackers are using right now against real targets. Blocking deployment when your application depends on a KEV-listed library version is arguably more urgent than blocking on a Critical SAST finding (which might be a false positive), because the KEV listing means the exploit is already in active circulation. The 7-day exception limit with Jira tracking is also critical -- exceptions without expiration dates become permanent, and within six months nobody remembers why the exception was granted. A 7-day forced review cycle ensures that every exception is either resolved or consciously renewed, not silently forgotten.
Episode 67 covered DevSecOps and pipeline security -- integrating SAST, DAST, SCA, and secret scanning into CI/CD pipelines, designing security gates that developers respect instead of bypass, and building a security culture that treats vulnerability prevention as a development concern rather than a compliance afterthought. The closing argument was that DevSecOps handles the commodity vulnerabilities automatically, freeing pentesters to focus on the hard problems that require human creativity.
Today we go back to the physical world. Episode 30 covered Wi-Fi attacks -- WPA2 cracking, deauthentication, evil twins, rogue access points. But Wi-Fi is only one slice of the wireless spectrum. Bluetooth is on every phone, laptop, smartwatch, and an alarming number of medical devices. Zigbee and Z-Wave control millions of smart home devices. RFID badges grant physical access to buildings. Software Defined Radio can receive (and transmit) across the entire radio spectrum from the AM broadcast band to microwave frequencies. Each of these protocols has its own security model, its own weaknesses, and its own dedicated attack tools.
This episode goes deep on all of them.
Before attacking Bluetooth, you need to understand that "Bluetooth" is actually two fundamentally different protocol stacks sharing the same name:
Classic Bluetooth (BR/EDR):
Purpose: audio streaming, file transfer, serial communication
Speed: 1-3 Mbps
Range: 10-100 meters (class-dependent)
Pairing: PIN-based or Secure Simple Pairing (SSP)
Security: E0 stream cipher (BR), AES-CCM (EDR/SC)
Attack surface: pairing intercept, BlueBorne, KNOB, protocol fuzz
BLE (Bluetooth Low Energy, introduced in BT 4.0):
Purpose: fitness trackers, smart locks, beacons, medical sensors
Speed: 1-2 Mbps
Range: up to 100 meters (typically 30-50 in practice)
Pairing: Just Works, Passkey, Numeric Comparison, OOB
Security: AES-CCM -- but MANY devices use no encryption at all
Attack surface: sniffing, GATT enumeration, replay, MitM, firmware OTA
The security gap between these two stacks is enormous. Classic Bluetooth has had decades of security research and iterative hardening. BLE was designed for low power consumption first and security second, and the "Just Works" pairing mode (which is what most cheap IoT devices use) provides zero authentication -- the devices pair without any user confirmation and the encryption keys are exchanged in a way that anyone within radio range can intercept. I have tested smart locks, fitness trackers, and even a blood pressure monitor that transmitted all data over BLE with zero encryption. Just... in the clear. Wowzers.
Here we go -- the first step in any Bluetooth assessment is discovering what is in range and what services it exposes:
# Classic Bluetooth scan (requires BT adapter in Linux)
hcitool scan
# 00:1A:7D:DA:71:13 JBL_Speaker
# 4C:65:A8:12:34:56 Galaxy_Watch5
# BLE scan with bluetoothctl (modern replacement for hcitool)
bluetoothctl
[bluetooth]# scan on
# [NEW] Device AA:BB:CC:DD:EE:FF SmartLock_v2
# [NEW] Device 11:22:33:44:55:66 FitBand_Pro
# [NEW] Device 77:88:99:AA:BB:CC Unknown
[bluetooth]# scan off
# BLE GATT enumeration -- read device services and characteristics
gatttool -b AA:BB:CC:DD:EE:FF -I
[LE]> connect
[LE]> primary
# attr handle: 0x0001, end grp handle: 0x0005 uuid: 00001800 (Generic Access)
# attr handle: 0x0014, end grp handle: 0x001a uuid: 0000180d (Heart Rate)
# attr handle: 0x0028, end grp handle: 0x002f uuid: custom-service-uuid
[LE]> char-read-hnd 0x0029
# Characteristic value/descriptor: 4f 70 65 6e (= "Open" in ASCII)
# Readable WITHOUT authentication -- this is the unlock command!
That last line is not hypothetical. A quit some number of commercial BLE smart locks store the unlock command as a GATT characteristic that is readable (and writable) by any BLE device in range without any authentication whatsoever. You connect, you read the characteristic to learn the unlock value, you write that value back, and the lock opens. No pairing, no PIN, no key exchange. The lock responds to whoever speaks to it.
For more systematic BLE enumeration, Python's bleak library (which we could have used back in episode 59 on Python for pentesters) gives you programmatic access:
import asyncio
from bleak import BleakScanner, BleakClient
async def scan_and_enum():
# Discover BLE devices (10 second scan)
devices = await BleakScanner.discover(timeout=10)
for d in devices:
print(f"[*] {d.address} {d.name or 'Unknown'} RSSI: {d.rssi}")
# Connect and enumerate GATT services on target
target = "AA:BB:CC:DD:EE:FF"
async with BleakClient(target) as client:
for service in client.services:
print(f"\n[Service] {service.uuid}")
for char in service.characteristics:
props = ", ".join(char.properties)
print(f" [Char] {char.uuid} Properties: {props}")
if "read" in char.properties:
val = await client.read_gatt_char(char.uuid)
print(f" Value: {val.hex()} ({val})")
asyncio.run(scan_and_enum())
This script discovers every BLE device in range, then connects to the target and dumps every GATT service, every characteristic, and every readable value. On a properly secured device, most characteristics require authentication before reading. On a poorly secured device, you get the full internal state -- sensor readings, configuration values, firmware versions, and sometimes device credentials -- without any pairing at all.
BlueBorne (2017) is one of the most significant wireless vulnerability disclosures in history. Eight vulnerabilities across Android, iOS, Windows, and Linux that allow remote code execution over Bluetooth without any pairing, without any user interaction, without the victim even knowing their device is being attacked. Just be within Bluetooth radio range (typically 10-30 meters, but with a directional antenna you can extend that considerably).
BlueBorne (CVE-2017-0781 through CVE-2017-0785, and more):
Android (CVE-2017-0781): Heap overflow in BNEP (Bluetooth Network
Encapsulation Protocol). Attacker sends crafted BNEP control message.
Result: RCE as the Bluetooth daemon (system-level process).
Linux (CVE-2017-1000251): Stack overflow in L2CAP (Logical Link
Control and Adaptation Protocol) configuration response handling.
Result: kernel-level RCE. Full system compromise from radio range.
Windows (CVE-2017-8628): MitM via Bluetooth PAN profile.
Result: network traffic interception.
iOS (CVE-2017-14315): LEAP (Low Energy Audio Protocol) heap overflow.
Result: RCE on iOS devices (patched in iOS 10).
Impact: 8.2 billion Bluetooth-enabled devices at time of disclosure.
Attack requires: Bluetooth enabled. Nothing else. No pairing, no
discovery mode, no user interaction. The attacker initiates the
connection. The victim's device does not need to be "discoverable."
Patched devices: those that received OS updates in Sep-Oct 2017.
Unpatched: billions of IoT devices, old phones, embedded systems
that will NEVER receive firmware updates.
The Linux kernel vulnerability (CVE-2017-1000251) is particularly terrifying because it gives the attacker kernel-level code execution -- not user-level, not daemon-level, but full ring-0 kernel access. From Bluetooth radio range. With no user interaction. On every Linux device that had Bluetooth enabled and had not received the October 2017 kernel patch. This includes many embedded Linux systems (routers, industrial controllers, medical devices) that do not have automatic update mechanisms and in many cases cannot be updated at all without a physical firmware flash.
The KNOB attack (Key Negotiation of Bluetooth, CVE-2019-9506) is a different beast -- instead of exploiting a memory corruption bug, it exploits a design flaw in the Bluetooth specification itself:
KNOB Attack (CVE-2019-9506):
The flaw: during Bluetooth pairing, the two devices negotiate
the entropy (length) of the encryption key. The Bluetooth spec
allows this negotiation to be DOWNGRADED to 1 byte of entropy.
Attack:
1. Attacker positions between two pairing devices (MitM relay)
2. During key negotiation, attacker modifies the entropy request
to set key length = 1 byte (8 bits of entropy)
3. Both devices accept 1-byte key (spec allows it!)
4. Attacker brute-forces 256 possible keys in real-time
5. All subsequent Bluetooth traffic is decrypted
Affected: ALL Bluetooth BR/EDR devices (spec-level flaw)
Fix: Bluetooth SIG updated spec to require minimum 7 bytes
of key entropy. Vendors patched firmware to enforce minimum.
Practical impact: any Bluetooth Classic connection between
unpatched devices can be eavesdropped by a nearby attacker
with MitM relay hardware.
This connects directly to what we covered in episode 9 on cryptography -- the KNOB attack is a downgrade attack on key entropy, the same class of vulnerability as POODLE (forcing TLS downgrade to SSL 3.0) or FREAK (forcing RSA export-grade keys). The pattern is always the same: the protocol allows negotiation to weaker parameters, and an attacker in the middle forces that negotiation to the weakest allowed setting. The fix is also always the same: enforce minimum acceptable parameters and reject anything below that floor.
BLE attacks go beyond enumeration. The three most practical attack categories are replay attacks, MitM relay, and firmware exploitation:
BLE Smart Lock Replay Attack:
1. Victim unlocks smart lock via phone app (BLE communication)
2. Attacker sniffs BLE traffic with Ubertooth One or nRF52840 dongle
3. Capture the unlock command sequence
4. If lock uses a STATIC unlock command (no rolling code, no nonce):
the exact same bytes work every time
5. Attacker replays captured BLE packets using gatttool or custom script
6. Lock opens
A 2019 academic study tested 16 commercial smart locks:
12 of 16 vulnerable to BLE replay
Static passwords, no challenge-response, often no encryption
Average retail price of vulnerable locks: $45-120
The 4 that resisted replay used challenge-response with session
nonces -- the lock sends a random challenge, the phone signs it,
and the signed response is only valid for that single interaction.
Defense: challenge-response with per-session nonces. Any static
command is a replay vulnerability by definition.
The MitM relay attack (sometimes called a GATTacker attack after the tool that popularized it) takes this further. Instead of passively sniffing and replaying, the attacker places a device between the legitimate phone and the target BLE peripheral. The attacker's device advertises itself as the real peripheral (cloned MAC address and service UUIDs), the phone connects to the attacker's device thinking it is the real lock, and the attacker forwards traffic between the phone and the real lock while intercepting everything. This works even against devices that use encryption, because the attacker establishes separate encrypted sessions with each side.
# BLE MitM with bettercap (requires 2 Bluetooth adapters)
sudo bettercap
# Scan for BLE devices
ble.recon on
# Show discovered devices
ble.show
# Target a specific device for enumeration
ble.enum AA:BB:CC:DD:EE:FF
# Write to a GATT characteristic (potential unlock command)
# WARNING: only do this on devices you own or have authorization to test!
ble.write AA:BB:CC:DD:EE:FF 002a 4f70656e
# Writes "Open" (hex: 4f70656e) to handle 0x002a
Having said that, BLE MitM attacks require quit some specialized hardware. You need at minimum two Bluetooth adapters (one to impersonate the peripheral to the phone, one to connect to the real peripheral), and ideally an Ubertooth One ($130) or nRF52840 dongle ($10-20) for packet-level sniffing. The Ubertooth can capture raw Bluetooth packets at the link layer, which is necessary for analyzing the pairing process and extracting temporary keys. The standard Bluetooth adapter in your laptop operates at the HCI (Host Controller Interface) level, which is too high in the protocol stack to see the raw pairing exchanges.
Zigbee (2.4 GHz, used by Philips Hue, Samsung SmartThings, most Zigbee-based sensors) and Z-Wave (868/908 MHz, used by smart locks, garage door openers, alarm systems) are the two dominant smart home protocols a part from Wi-Fi and Bluetooth:
Zigbee Security:
Encryption: AES-128 CCM (strong on paper)
Fatal flaw: the network key is transmitted over-the-air during
device join. If an attacker is sniffing at the moment a new
device joins the network, they capture the key in plaintext.
Tool: KillerBee framework + ApiMote or RZUSBstick hardware
Attack:
1. Force a device rejoin (by jamming its connection briefly)
2. Sniff the rejoin process
3. Capture the network key exchange
4. Decrypt all Zigbee traffic on the network
5. Inject commands to any device (lights, locks, thermostats)
Zigbee 3.0 introduced "Install Code" provisioning where the key
is derived from a code printed on the device (like WPA-PSK).
But backward compatibility means many networks still accept
non-Install-Code joins.
Z-Wave Security:
S0 (legacy, still widespread):
Key exchange encrypted with a well-known default key
(all zeros). Attacker captures key exchange, decrypts with
the known key, obtains real network key, controls all devices.
Tool: EZ-Wave (open-source Z-Wave exploitation framework)
S2 (2017+, mandatory for Z-Wave Plus v2 certification):
Diffie-Hellman key agreement, device-specific DSK code.
Much stronger -- no practical attack against properly
implemented S2. BUT: backward compatibility means networks
with a mix of S0 and S2 devices may fall back to S0 for
communication with legacy devices.
The critical risk: S0 devices on a network with S2 devices
create a downgrade path. The S0 device cannot speak S2,
so the controller communicates with it using S0 (weak crypto),
and an attacker who compromises the S0 session may be able
to pivot to the S2 devices through the controller.
The Zigbee key-exchange vulnerability is a beautiful example of a protocol that has strong cryptography (AES-128 is excellent) but terrible key management. The encryption itself is unbreakable. The problem is that the key is transmitted in a way that an attacker can intercept -- and if you intercept the key, the strength of the cipher is irrelevant. This is the same lesson from episode 9: cryptographic algorithms are almost never the weak link. Key distribution, key storage, and key negotiation are where the real vulnerabilities live.
An SDR replaces dedicated radio hardware with software. Instead of a radio receiver that can only tune FM broadcast or a specific frequency band, an SDR can receive (and in some cases transmit) across a huge swath of the radio spectrum. For wireless security assessments, this means you can intercept and analyze signals from devices that use proprietary protocols, uncommon frequencies, or encoding schemes that no dedicated tool supports.
# RTL-SDR (~$25 USB dongle, receive-only, 24 MHz - 1.7 GHz)
# Legal everywhere for receive-only use
# Scan the spectrum around 433 MHz (common IoT frequency)
rtl_power -f 400M:500M:100k -g 40 -i 10 scan.csv
# Generates CSV of signal strength across the band
# Visualize with heatmap.py to find active frequencies
# Decode 433 MHz sensors (weather stations, tire pressure,
# car key fobs, garage door remotes, wireless doorbells)
rtl_433 -f 433.92M
# Outputs decoded data:
# time: 2026-06-26 14:32:01
# model: Acurite-Tower id: 2841 channel: A
# temperature: 22.3 C humidity: 58% battery: OK
# All plaintext. No encryption. No authentication.
# HackRF One (~$350, CAN transmit, 1 MHz - 6 GHz)
# WARNING: transmitting without a license is ILLEGAL in most
# jurisdictions. Receive is legal. Transmit requires authorization.
# Capture a 433 MHz signal (e.g. from a garage door remote)
hackrf_transfer -r capture.raw -f 433920000 -s 2000000 -n 2000000
# Replay the captured signal
hackrf_transfer -t capture.raw -f 433920000 -s 2000000
# If the device uses static codes: it responds to the replay
The rtl_433 output is eye-opening the first time you run it. Within minutes of starting the tool, you will see temperature readings from your neighbor's weather station, tire pressure data from passing cars, status updates from wireless doorbells and motion sensors, and sometimes even alarm system sensor data -- all broadcast in plaintext at 433 MHz with zero encryption and zero authentication. These devices were designed in an era when "nobody would bother intercepting my weather station" was considered adequate security ;-)
The HackRF One takes this from passive observation to active interaction. With a HackRF you can capture a garage door remote's signal, replay it, and open the garage. This works against devices that use static codes (the same signal means "open" every time). Modern garage door openers use rolling codes (each press generates a unique code from a synchronized counter), which defeats simple replay. But even rolling code systems have been attacked -- the RollJam attack (demonstrated by Samy Kamkar) captures two consecutive codes while jamming the legitimate receiver, uses the first code immediately, and holds the second code for future use. The receiver never saw either code (because it was jammed), so the rolling counter has not advanced, and the attacker's held code is still valid.
NB: I cannot stress this enough -- transmitting radio signals without proper authorization is a criminal offense in most countries. Receive-only monitoring with an RTL-SDR is legal almost everywhere. The moment you transmit (replay, jam, or broadcast), you need either a specific license, explicit written authorization as part of a security assessment, or a properly shielded lab environment that does not radiate beyond its walls. This is one area where "I was doing a security assessment" is not a sufficient defense unless you have written authorization that explicitly covers RF transmission.
Episode 47 covered RFID badge cloning as a physical security technique. Today we go deeper into the protocol-level attacks:
# Proxmark3 -- the Swiss Army knife of RFID/NFC security research
# Read a low-frequency RFID card (125 kHz, e.g. EM4100)
proxmark3> lf search
# [+] EM410x ID found: 0400A48F2D
# [+] Valid EM410x ID
# Clone to a writable T5577 card (takes ~2 seconds)
proxmark3> lf em 410x clone --id 0400A48F2D
# [+] Done
# Read a high-frequency MIFARE Classic card (13.56 MHz)
proxmark3> hf search
# [+] MIFARE Classic 1K detected
# [+] UID: A1B2C3D4
# Darkside attack -- recover sector keys from MIFARE Classic
proxmark3> hf mf darkside
# [+] Found key: FFFFFFFFFFFF (default)
# This works because MIFARE Classic uses the Crypto-1 cipher,
# which was completely broken in 2008. The "darkside" attack
# recovers a sector key from a SINGLE authentication attempt
# in 10-30 seconds.
# Dump entire card (all 16 sectors, 1KB of data)
proxmark3> hf mf dump
# [+] Saved 1024 bytes to hf-mf-A1B2C3D4-dump.bin
# This contains: access credentials, floor permissions,
# vending machine balance, whatever the card stores
The MIFARE Classic situation is a genuine security disaster that has been in slow motion since 2008. The Crypto-1 cipher used by MIFARE Classic was reverse-engineered by researchers at Radboud University (the Netherlands -- toevallig my backyard), and the darkside attack they published recovers sector keys in seconds. Despite this being public knowledge for 18 years now, MIFARE Classic remains the most widely deployed access control card in the world. Hotels, office buildings, public transit systems, university campuses -- billions of cards using broken cryptography. The replacement (MIFARE DESFire EV3) uses AES-128 with mutual authentication and has no known practical attacks, but migration is expensive and slow.
RFID/NFC protocol comparison from a security perspective:
EM4100 (125 kHz):
Security: NONE. Zero encryption, zero authentication.
Clone time: 2 seconds with a $20 RFID writer.
Still the most common building access card worldwide.
MIFARE Classic (13.56 MHz):
Security: Crypto-1 (BROKEN since 2008).
Clone time: 30 seconds (key recovery) + 2 seconds (clone).
Used by: transit systems, office buildings, universities.
MIFARE DESFire EV2/EV3 (13.56 MHz):
Security: AES-128, mutual authentication, diversified keys.
Clone time: not feasible (no practical crypto attack).
Weakness: implementation bugs, default keys left unchanged.
iCLASS / HID (13.56 MHz):
Security: depends on generation. Legacy iCLASS is broken
(similar Crypto-1 weaknesses). iCLASS SE / SEOS is strong.
Clone time: legacy = 30 seconds. SE/SEOS = not feasible.
NFC Payment (EMV Contactless):
Readable data: cardholder name, PAN, expiry, last 10 transactions.
NOT clonable: dynamic cryptograms prevent card duplication.
Risk: harvested PAN + expiry enables card-not-present fraud
(online purchases on sites that don't require CVV).
The NFC payment point deserves emphasis because it causes the most confusion. You CAN read quite some data from a contactless payment card without the cardholder knowing -- just hold an NFC reader near their wallet. The card will happily respond with the cardholder name, full card number (PAN), and expiry date. But you CANNOT clone the card, because every transaction generates a unique cryptographic signature that the card computes internally using a key that never leaves the chip. The risk is not card cloning -- it is harvesting the PAN and expiry for online fraud on websites that do not require the CVV (the 3-digit code on the back of the physical card, which is NOT transmitted via NFC).
During a wireless security assessment, you need to be aware that the target may have Wireless Intrusion Detection Systems (WIDS) monitoring for exactly the kinds of attacks we have been discussing:
What WIDS detects:
- Deauthentication floods (episode 30 -- Wi-Fi attacks)
- Rogue access points and evil twins
- Unusual BLE scanning patterns (rapid sequential connections)
- Zigbee/Z-Wave protocol anomalies
- RF jamming (detectable via signal strength anomalies)
- MAC address spoofing (vendor OUI mismatches)
Evasion techniques:
- Slow scanning: connect to one BLE device per minute instead of
blasting through every device in range in 10 seconds. Patience
is the number one evasion technique across ALL security domains.
- Frequency hopping: Bluetooth already does this natively (1,600
hops/second across 79 channels), which makes passive interception
difficult without dedicated hardware like Ubertooth.
- MAC randomization: use random source MAC addresses for each
connection attempt. Most BLE adapters support this.
- Directional antennas: concentrate your signal toward the target
and away from WIDS sensors.
- Time your assessment: building security monitoring is often less
staffed on weekends and evenings (episode 47 on physical security).
The irony is that Bluetooth's built-in frequency hopping (which was originally designed to avoid interference with other 2.4 GHz devices) is actually an effective anti-interception feature. Passively sniffing Bluetooth Classic without knowing the hopping sequence is extremely difficult -- you need hardware like the Ubertooth One that can follow the hopping pattern, or you need to capture the connection setup (which includes the hopping sequence negotiation) from the beginning. If you start sniffing after the connection is already established, you will see fragments of data on random channels with no way to reassemble them. BLE is somewhat easier to intercept because its advertising channels are fixed (channels 37, 38, 39) and the data channel hopping is simpler, but you still need specialized hardware to capture reliably.
Bluetooth:
- Disable Bluetooth when not actively using it
- Set devices to non-discoverable mode (reduces attack surface
but does NOT prevent attacks like BlueBorne)
- Keep OS and firmware updated (BlueBorne and KNOB patches)
- Remove paired devices you no longer use
- Use Bluetooth 5.2+ with LE Secure Connections where possible
BLE devices (for manufacturers and developers):
- Require authentication for ALL GATT characteristics
- Implement challenge-response with per-session nonces
- NEVER use static unlock commands
- Encrypt all BLE traffic (not optional, not "later")
- Implement secure OTA firmware updates with signature verification
- Mobile apps should validate BLE device identity (not just name)
Smart home (Zigbee / Z-Wave):
- Separate IoT VLAN (episode 53 -- network segmentation)
- Prefer Z-Wave S2 / Zigbee 3.0 with Install Code provisioning
- Disable pairing mode when not actively adding devices
- Monitor for unauthorized device joins
- Firmware updates for all smart home devices (many vendors
support OTA updates through their hub apps)
RFID:
- Migrate from 125 kHz (EM4100) to DESFire EV3
- Multi-factor: badge + PIN for sensitive areas
- RFID-shielding card holders for contactless payment cards
- Change default sector keys on MIFARE installations
- Implement access logging and anomaly detection
AI is accelerating both sides of the wireless security landscape. On the offensive side, AI-powered SDR tools can automatically identify and decode unknown wireless protocols -- feed raw IQ samples into a trained model and it classifies the modulation scheme, identifies the protocol, and suggests decoding parameters. What used to require a radio engineer with years of experience can now be approximated by someone with a HackRF and a good ML model. AI also analyzes BLE traffic patterns and identifies authentication weaknesses automatically -- scanning hundreds of BLE devices and flagging those with unprotected GATT characteristics.
On the defensive side, AI-powered wireless IDS systems detect anomalous Bluetooth and Zigbee traffic that rule-based systems miss, identify rogue devices by behavioral fingerprinting (a cloned MAC address behaves differently from the real device at the radio layer), and flag replay attacks in real time by recognizing duplicate command sequences. The fundamental problem is the same one we keep returning to across this series: AI makes existing attack techniques more accessible to less skilled attackers while simultaneously giving defenders better tools to detect those attacks. The arms race spans the entire radio spectrum.
And on the development side, AI-generated IoT firmware is particularly dangerous in this context. AI models trained on GitHub code generate BLE implementations with default pairing modes, static GATT characteristics, and missing encryption -- because that is what the majority of example code looks like. The forementioned smart lock that ships with a static unlock command readable by any BLE device? Increasingly, that is the result of a developer asking an AI to "implement BLE lock control" and deploying whatever comes back without understanding the security implications.
Exercise 1: Use bluetoothctl (or hcitool if you prefer the legacy interface) to scan for Bluetooth devices near you. Document: (a) how many devices are discoverable vs non-discoverable (count both Classic and BLE), (b) device names and apparent device types (phone, speaker, watch, etc.), (c) which are BLE vs Classic. If you own a BLE device (fitness tracker, smart bulb, anything), use gatttool or bleak (Python) to enumerate its GATT services and document which characteristics are readable without authentication. Save to ~/lab-notes/bluetooth-enumeration.md.
Exercise 2: Research the KNOB attack (CVE-2019-9506) in depth. Document: (a) the exact protocol step where the attacker forces entropy reduction (which L2CAP message, what field is modified), (b) affected Bluetooth versions and the minimum key entropy the spec originally allowed, (c) practical impact (brute-force time for 1-byte vs 7-byte key entropy), (d) the Bluetooth SIG fix and which firmware versions implement it, (e) how this compares to TLS downgrade attacks like POODLE (episode 9). Save to ~/lab-notes/knob-attack-analysis.md.
Exercise 3: If you have an RTL-SDR dongle: install rtl_433 and capture 433 MHz sensor data for 30 minutes. Document every device type detected, what data each device transmits, whether any data is encrypted, and assess the privacy implications of the unencrypted broadcasts. If you do not have an SDR: research 3 published SDR-based attacks -- (a) car key fob relay attack, (b) garage door rolling code bypass (RollJam), (c) pager/POCSAG interception -- and document each attack's methodology, required hardware, and countermeasures. Save to ~/lab-notes/sdr-analysis.md.
@scipio