1. The Attack Surface Started Before the Network Stack

The first meaningful weakness I exploited on a Wi-Fi device had nothing to do with WPA2, key exchange, or packet injection. The device never successfully associated with my access point. The failure was upstream of the network stack, in the RF and PHY behavior of the radio itself. The firmware assumed the RF environment was benign. It was not.

The device used a low-cost 2.4 GHz radio with aggressive power saving. Under interference, it oscillated between scan and connect states, leaking timing information and occasionally wedging its driver. The attack was not about breaking encryption. It was about manipulating the RF environment to force the firmware into error paths that were never tested.

To reproduce the device behavior, I built a minimal monitor pipeline:

iw dev wlan0 set type monitor
ip link set wlan0 up
tcpdump -i wlan0 -e -I -y IEEE802_11_RADIO

This gave me raw frames and radiotap headers, including RSSI and retry counts. The patterns were visible long before any IP traffic existed.

2. RF Recon Is a Different Kind of Enumeration

Traditional recon enumerates services and ports. RF recon enumerates channels, modulation behavior, retry patterns, and timing. The first thing I wanted was a channel occupancy map over time, not just a snapshot scan.

Using a cheap SDR:

import numpy as np
from rtlsdr import RtlSdr

sdr = RtlSdr()
sdr.sample_rate = 2.4e6
sdr.center_freq = 2.437e9  # channel 6
sdr.gain = 'auto'

samples = sdr.read_samples(256*1024)
power = 10 * np.log10(np.mean(np.abs(samples)**2))
print(power)

This was crude, but enough to correlate device failures with spikes in noise floor. The device firmware treated noise-induced frame loss as "network instability" and triggered aggressive reconnect logic. That logic was exploitable.

3. Forcing Failure Modes With Controlled Interference

Once I understood how the device behaved under interference, I stopped thinking in terms of jamming and started thinking in terms of shaping the error conditions. Full-band jamming is noisy and obvious. Targeted interference that degrades specific control frames is quieter and more useful.

Using a programmable radio to emit narrow bursts:

from scapy.all import *
from scapy.layers.dot11 import Dot11, Dot11Deauth

pkt = RadioTap() / Dot11(
    addr1="ff:ff:ff:ff:ff:ff",
    addr2="00:11:22:33:44:55",
    addr3="00:11:22:33:44:55"
) / Dot11Deauth(reason=7)

sendp(pkt, iface="wlan0mon", inter=0.05, loop=1)

The goal was not to deauth clients at scale. The goal was to induce enough control-plane instability that the device's connection state machine entered rarely used code paths. In those paths, error handling was weak. The firmware occasionally leaked internal state over a debug UART exposed on test pads.

4. PHY-Layer Behavior Leaks Device State

One of the most useful signals was not packet content, but retry and rate adaptation behavior. The device's rate control algorithm revealed when it was under memory pressure. As buffers filled, the radio dropped to lower modulation rates and increased retries.

You can see this in radiotap headers:

tcpdump -i wlan0mon -e -I -y IEEE802_11_RADIO subtype data

Fields like Rate and Retry correlate with firmware load. This creates a side channel. Without touching IP traffic, you can infer internal device state by watching PHY-layer behavior. That was enough to time further actions, such as inducing power-save transitions that exposed race conditions in the driver.

5. Power Management as an Attack Vector

The most reliable fault I found was in the power management state machine. The device aggressively entered sleep states to conserve battery. Under RF instability, it oscillated between awake and sleep, occasionally corrupting internal buffers.

I reproduced this by creating a pattern of short bursts of interference:

import time
import subprocess

def pulse():
    subprocess.run(["iw", "dev", "wlan0", "set", "txpower", "fixed", "0"])
    time.sleep(0.2)
    subprocess.run(["iw", "dev", "wlan0", "set", "txpower", "fixed", "1500"])

while True:
    pulse()

The exact mechanism varies by chipset, but the class of bug is consistent: power state transitions are tested under nominal RF conditions, not adversarial ones. The resulting faults were not remote code execution, but denial of service and state desynchronization. In embedded systems, persistent denial of service is often enough to create a real-world exploit path.

6. Why Network-Layer Defenses Did Not Matter

From the vendor's perspective, the device was "secure." WPA2 was correctly implemented. TLS was enforced at the application layer. None of that mattered when the radio driver could be forced into undefined states. The security boundary they assumed started at the network stack. The real boundary started at the antenna.

This is the pattern I have seen repeatedly in IoT and embedded Wi-Fi devices. The RF front end and PHY handling are treated as a reliability concern, not a security concern. Once you treat RF as attacker-controlled input, entire new classes of bugs become visible.

7. Instrumentation Beats Exploitation

The most valuable tooling was not exploit code. It was instrumentation. Being able to correlate RF conditions with firmware behavior required synchronized logging.

I used a simple time-correlation approach:

date +%s.%N >> rf_log.txt
tcpdump -i wlan0mon -e -I -y IEEE802_11_RADIO >> rf_log.txt

On the device side, UART logs were timestamped. Aligning these two streams showed exactly which RF conditions triggered which firmware paths. Without this correlation, the failures looked random. With it, they were reproducible.

8. Defensive Implications for Device Builders

The defensive takeaway is not to add more crypto. It is to treat the RF environment as hostile input. Rate adaptation, power management, and reconnection logic are part of the security boundary. Fuzzing should not stop at packet parsing. It should include RF conditions, timing perturbations, and loss patterns.

At a minimum, device firmware should:

void on_rf_error(struct rf_stats stats) {
    if (stats.retry_rate > MAX_RETRY_THRESHOLD) {
        throttle_reconnects();
        reset_radio_state_machine();
    }
}

This kind of defensive coding treats RF instability as a potential fault injection vector. Without it, the device will fail in ways that are exploitable even if higher-layer protocols are correct.

9. The Real Lesson About Wireless Security

The lasting lesson is that wireless security does not begin with authentication. It begins with how the radio and firmware behave under adversarial physical conditions. You can "break" a Wi-Fi device without ever joining its network by forcing it into states its designers never exercised. In practice, those states are where reliability bugs become security problems.