Home

Privacy Preserving Wi-Fi Probe Requests

Final year project

June 2026 – July 2026
completed

A research prototype showing that Wi-Fi discovery can run on an obfuscated per-device alias rather than a plaintext SSID.

Source
What
A modified hostapd and wpa_supplicant that let a device rediscover an access point using a per-device token.
Why
Plaintext SSIDs in Probe Requests can be collected passively and cross-referenced with geolocation databases to infer where a device has been.
Result
Working prototype: reconnect scans used a wildcard SSID with the token in a vendor-specific IE, with no directed plaintext probe

The problem

When devices discover a network it already knows, it broadcasts the network's name in plaintext inside a Probe Request. Anyone nearby can collect those broadcasts, and cross-reference them with public geolocation databases to reveal where a device has been - home, work, or anywhere else it has connected before.

My final year project asked whether discovery could work on an obfuscated alias instead, without changing the shape of the 802.11 protocol.

The approach

Each access point derives a 16-byte token per station. Only MAC addresses are needed, so the token is available before association. It's unique for each device but identical across reconnects.

batch
token = SHA256(BSSID || STA_MAC)[0..15]

On first connection, the station associates using the real SSID and the access point derives a token which is sent back in the Association Response inside a vendor-specific Information Element. On every connection after that, the station scans with a wildcard SSID and attaches the stored token to its Probe Request instead. The access point matches the token and continues with the normal association flow.

Element ID 221 is an existing extension point in the standard, so nothing about the over-the-air structuure change.

Implementation

The prototype modifies both daemons, running on SoftMAC adapters. FullMAC hardware won't work, since management frames are generated in firmware there rather than in software.

On the access point side, hostapd gained token derivation during station state creation, storage in the per-station WPA state machine, a lookup table, an IE builder for the Association Response, and Probe Request parsing to match incoming tokens. On the station side, wpa_supplicant gained token extraction from the Association Response, persistence into the network config so it survives restarts, wildcard scanning when a token exists, and IE insertion into outgoing Probe Requests.

Results

Second-pass reconnects behaved as intended: wildcard SSID probing, the token IE present in the Probe Request, and the same token value the access point had provisioned earlier.

Verification came from hostapd and wpa_supplicant runtime logs, inspection of the persisted config, and packet captures analysed with tcpdump, tshark and Wireshark.

text
DEMO TOKEN (derived: SHA256(BSSID||STA_MAC)) - hexdump(len=16): 4b a6 51 73 ...
DEMO: token registered for 90:de:80:88:ce:60
DEMO: using wildcard SSID for token-based scan
DEMO: adding token IE to Probe Request

Scope

The token is sent in plaintext deliberately. It obfuscates rather than encrypts, and the design makes no claim to cryptographic confidentiality or strong anti-tracking guarantees. A passive listener still sees a stable per-device value; what they no longer see is the network name.

Token rotation, production hardening and a fuller privacy analysis were out of scope. This is an academic research prototype, not something to run on a real network.