Your devices are screaming — The invisible fingerprints that every modern device leaves behind

Every wireless device you own constantly emits radio signals. Not only when you call or browse the Internet — all the time. These transmissions are not encrypted private communications between your device and a cell tower. They are public radio broadcasts, readable by anyone in range who has the right receiver.

And the receivers are cheap. A Nordic Semiconductor BLE sniffer. An RTL-SDR dongle. A Raspberry Pi with a consumer Wi-Fi adapter. All you need is to passively capture the invisible fingerprints your devices spew into the air every second of every day.

This is not theoretical. It is physics. Radio waves travel in all directions. Your phone does not whisper to a single access point — it calls into a room, a street, a building. And anyone listening can hear it.

WLAN Probe Requests: Your phone sends your network history

When WLAN is enabled on your phone, it does not wait passively for networks to appear. It actively searches for them by sending Probe Requests — small radio frames that essentially ask: “Is MyHomeNetwork here? What about CorporateWiFi? How about Hilton_Guest?”

Each Probe Request contains an SSID: the name of a network your device has connected to before. Your device runs through its list of preferred networks and sends each name in sequence. That means your phone constantly proclaims:

• The name of your home network
• Your work Wi‑Fi (reveals your employer)
• Hotel and airport networks (reveal your travel history)
• Café and restaurant networks (reveal your habits)
• The security type your device expects for each network

This is not a side channel or a clever attack. It is how WLAN is designed. The 802.11 specification defines Probe Requests as a standard discovery mechanism. Your phone sends them on multiple channels, unencrypted, for anyone to receive.

A passive receiver captures these probes and sees a device MAC address paired with every SSID it searches for. Over time, a travel diary emerges: This device was at the Marriott in Frankfurt, connected to “GoogleGuest” and had a home network named “Mueller_Family_5G”. These are not metadata — this is a profile.

BLE: A multifaceted fingerprint

Bluetooth Low Energy is even more informative than WLAN. Where a WLAN Probe Request reveals a network name, a single BLE Advertisement can reveal a dozen identifying features at once.

Every BLE device sends Advertisements on three dedicated channels (37, 38, and 39) to announce its presence. These Advertisements carry structured data fields that together form a rich, layered fingerprint:

Appearance Values — A 16-bit code declaring what the device is. A phone (Appearance 0xC0), a smartwatch (0x00C1), a pair of headphones (0x0941), a tracking tag. Bluetooth SIG assigns hundreds of these categories. Your device proclaims its type in every Advertisement.

Service UUIDs — Standardized identifiers that reveal exactly what a device can do. A heart rate monitor advertises UUID 0x180D. an audio sink advertises 0x110B. A blood pressure monitor advertises 0x1810. These are not optional — devices send them so other Bluetooth devices can recognize their capabilities. But everyone else can see them too.

Manufacturer-specific data — A payload that begins with a company identifier assigned by Bluetooth SIG. Apple is 0x004C. Samsung is 0x0078. Google is 0x00E0. After the company ID follow proprietary data that often encodes device model, firmware version, and status information. This data is sent in clear text.

Local device names — Many devices include a human-readable name in their Advertisements. “AirPods Pro.” “[TV] Samsung 65Q80.” “Fitbit Charge 5.” “OsmoPocket3-A7F2.” These names appear as plain text in the radio signal.

Google Fast Pair Model IDs — Android devices using Google’s Fast-Pair protocol broadcast a 3-byte model ID under Service-UUID 0xFE2C. This is not a category — it is a specific product identifier. Model ID 0xA1B2C3 points to exactly one product in Google’s database. In discoverable mode, this ID is transmitted in clear text, so anyone nearby can identify the exact make and model of your headphones, earbuds, or watch.

TX Power Level — The transmit power reported in the Advertisement, intended for distance estimation. Combined with the received signal strength (RSSI), this not only reveals what a device is, but roughly where it is located.

Advertising intervals and channel patterns — The timing between advertisements and the channel sequence (37 → 38 → 39) create a behavioral fingerprint. Different chipsets have different timing precision. Different firmware versions have different interval configurations. Even if everything else is randomized, these physical characteristics remain.

All of this information is continuously broadcast to everyone, with no authentication or encryption. A passive receiver in range — typically 10 to 100 meters — captures every field.

The devices that reveal everything

Nearly every wireless device you interact with contributes to your radio fingerprint. Here is what different device categories reveal:

Smartphones

The biggest culprits. A typical smartphone simultaneously sends WLAN probe-requests (exposes your network history), BLE advertisements (exposes manufacturer, device type, and service capabilities), and often Google Fast Pair or Apple Handoff data. With WLAN and Bluetooth enabled, a smartphone creates a rich, cross-layer fingerprint that is trivially trackable across locations.

Smartwatches and Fitness Trackers

These devices advertise health-related service UUIDs such as heart rate (0x180D), running speed (0x1814) and environment sensing (0x181A). Their Appearance Values identify them as wrist-worn devices. Some transmit sensor data directly in their advertisement payload — your current heart rate, step count, or activity status, in the clear, readable by anyone.

Headphones and Earbuds

Audio devices reveal their function through audio-sink and source service UUIDs. Many high-end earbuds from Sony, Bose, JBL, and Beyerdynamic share the same Airoha chipset, identifiable by a specific 128-bit service UUID (5052494D-2DAB-0341-6972-6F6861424C45). This means a passive receiver can not only identify “headphones” but also the exact chipset family, narrowing the product down to a handful of models.

Dashcams and Action Cameras

These create WLAN hotspots for the companion app pairing and broadcast SSIDs like “OsmoPocket3-A7F2″ or “GoProHERO12-1234″. Some also send BLE pairing beacons. A device that should be inconspicuous on a dashboard proclaims its exact product model to anyone in radio range.

Smart Home Devices

Environmental sensors from firms like Ruuvi, Minew, and Laird broadcast temperature, humidity, air pressure, and door/window status in their BLE advertisement payloads. A passive receiver passing by a building can inventory the smart-home sensors inside — and read their measurements.

Tracking Tags

AirTag, Samsung SmartTag and Tile trackers each have distinct protocol signatures. Apple Find My devices use vendor data type 0x12 with a rotating 22-byte public key. Samsung SmartTags use vendor ID 0x0078 with a characteristic 0x20-frame pattern. Tile uses its own service UUID. Each protocol is immediately recognizable to a passive observer.

The Bluetooth SIG: A public decoding key

All these hex codes and UUIDs may sound cryptic, but their interpretation requires no reverse engineering. The Bluetooth Special Interest Group (SIG) — the industry body that manages the Bluetooth standard — publishes comprehensive databases of all assigned numbers as open YAML files in a public repository. Anyone can download them.

Company Identifiers — The SIG maintains a register of nearly 4,000 company codes. Every manufacturer delivering a Bluetooth product registers a 16-bit identifier. Apple is 0x004C. Samsung is 0x0078. Airoha Technology is 0x00CC. Ericsson is 0x0000. When your device sends manufacturer-specific data, the first two bytes are a company code that directly points to a name in this public list. There is no ambiguity and no decryption needed — just a table lookup.

Service UUIDs — The SIG defines over 200 standardized 16-bit Service UUIDs. Heart Rate is 0x180D. Blood Pressure is 0x1810. Environmental Sensing is 0x181A. Fitness Machine is 0x1826. Insulin Delivery is 0x183A. Each UUID has a defined meaning, a defined data format, and a published specification. When a device advertises a Service UUID, it declares its exact function in a standard industry vocabulary that anyone can read.

Appearance Values — The SIG publishes a structured taxonomy of device categories and subcategories. The top 10 bits of the Appearance value identify the category — Phone, Computer, Watch, Tag, Keyring, Heart Rate Sensor, Audio Sink, Hearing Aid, Glucose Meter, Domestic Appliance, etc. The lower 6 bits further refine: not just “Computer”, but “Laptop” or “Server-class Computer”. Not just “Wearable Audio Device”, but “Earbud” or “Headset”. A single 16-bit number reveals exactly what kind of device is sending.

These are not leaked internal documents or reverse-engineered databases. It is the official, public specification that manufacturers must use. The Bluetooth SIG publishes it so devices interoperate. The side effect is that anyone with a passive receiver can look up what each device in range is, who made it, and what it can do — using the same public tables that the devices themselves rely on.

When fingerprinting becomes a weapon: The Airoha RACE vulnerability

All of the above described is passive observation — a receiver quietly cataloging what devices send. But what happens if the information in these transmissions opens the door to active attacks?

In December 2025, security researchers Dennis Heinze and Frieder Steinmetz presented at 39C3 a chain of vulnerabilities in Airoha Bluetooth audio chips, a MediaTek subsidiary. Airoha does not sell headphones under its own name — the company makes the chipsets used in headphones from Sony, Bose, JBL, Beyerdynamic, Marshall, Jabra and others. If you own wireless premium earbuds or headphones, the likelihood is high that an Airoha chip is inside.

The problem is a proprietary protocol named RACE (Really Advanced Chipset Extension). Airoha chips expose a RACE GATT service over BLE that enables deep control over the chipset — read/write access to flash memory and RAM, firmware manipulation, and device configuration. The service is advertised in every BLE advertisement of the headphones, identifiable by a specific 128-bit UUID (5052494D-2DAB-0341-6972-6F6861424C45). And crucially: no authentication is required for the connection.

The attack chain works like this:

1. Passive identification. An attacker within BLE range (~10-100m) sees the RACE GATT service UUID in the headphones’ Advertisement. This identifies the device unequivocally as an Airoha chipset. No interaction with the device is required — the Advertisement is broadcast continuously.
2. Flash memory extraction (CVE-2025-20700). The attacker connects to the RACE service and reads the chip’s flash memory. This is done without authentication — no pairing, no PIN, no user prompt on the headphones. The flash dump contains stored Bluetooth Link Keys: the shared secrets that authenticate the trusted connection between the headphones and the owner’s phone.
3. Phone impersonation (CVE-2025-20701). With the extracted Link Key, the attacker can impersonate the headphones to the owner’s phone over Bluetooth Classic. The phone believes it is connecting to its trusted headphones. From this position the attacker could potentially access phone functions exposed over Bluetooth — audio, call management, and, depending on the phone’s Bluetooth stack, possibly more.

Three CVEs have been assigned: CVE-2025-20700 (unauthenticated flash reading), CVE-2025-20701 (authentication bypass via link-key extraction) and CVE-2025-20702 (RACE protocol information disclosure). Affected products include Sony WF-1000XM5, WH-1000XM5 and WH-1000XM6, Marshall Major V and Minor IV, Beyerdynamic AMIRON 300, Jabra Elite 8 Active and likely many other products built on the same chipsets.

This is a concrete example of how the problem of “invisible fingerprints” escalates beyond privacy. The same BLE Advertisement that reveals “these are Sony headphones with an Airoha chipset” also reveals “this device is vulnerable to unauthenticated memory extraction and thus to access the owner’s phone.” The advertisement does not only reveal identity — it advertises an attack surface.

Why MAC Randomization doesn’t save you

Modern devices randomize their MAC addresses to reduce tracking. It’s a meaningful improvement — but far from sufficient. The MAC address is just one field in a rich advertisement. If everything else is equal, changing the MAC is like putting on a false mustache while wearing a name tag.

Static payloads outlive randomized MACs. Your device rotates its MAC address, but the Appearance value, the Service UUIDs, the manufacturer data, and the local name often remain constant. A receiver that sees Appearance 0x0941 + Service UUID 0x110B + Manufacturer ID 0x004C + local name “AirPods Pro” does not need the MAC to know it is the same device.

Timing fingerprints are hardware-based. Different chipsets have measurably different advertising interval precision. Nordic Semiconductor nRF chips, for example, keep interval standard deviations under 5% of the mean — a level of precision that serves as a chipset fingerprint, independent of any software randomness. Advert intervals of 1022.5ms ± 2% look different from intervals of 1285ms ± 8%, even if the MAC changes every 15 minutes.

Channel-hopping patterns are deterministic. BLE advertisements occur on channels 37, 38, and 39 in sequence. Some implementations traverse these channels in a strict, predictable pattern — 37 → 38 → 39 → 37 → 38 → 39 — with over 80% determinism. This pattern persists across MAC rotations and can be used to link “different” devices to the same physical radio.

RSSI variance reveals movement patterns. A device carried by a person shows characteristic signal strength variations while walking. A stationary device (like a fixed tracker) shows little variance. This behavioral layer exists purely in the physics of radio propagation and cannot be randomized away.

Cross-layer correlation breaks anonymity. If a phone transmits WLAN probes and BLE advertisements at the same time, the two signals can be correlated by timing, location, and behavioral patterns — even if each layer randomizes its MAC address. An identity across two protocols is harder to hide than an identity in a single protocol.

Find-My Networks and “Macless Haystack”

Apple’s Find My network, Google’s “Find My Device” and open-source alternatives like OpenHaystack have improved the cryptographic layer of tracking devices. Keys rotate. Payload data is encrypted for the owner. Some implementations even eliminate persistent MAC addresses entirely.

But these improvements address the data layer, not the radio layer. The fundamental problem remains: the device must emit a radio signal to be useful as a tracker. And that radio signal is public.

Anyone within about 100 meters of a Find-My beacon can:

• Detect that a Find-My Beacon exists. Apple Find-My devices are identifiable by their vendor data frame type 0x12 under company ID 0x004C. Google Find My Device beacons use service data UUID 0xFEE0. The protocol identity is visible even when the key payload is encrypted.
• Differentiate real devices from DIY beacons. Commercial Apple AirTags behave differently from DIY-nRF Find-My clones. Clones often exhibit more precise timing (nRF chip properties), more deterministic channel hopping, and a discrepancy between static MACs and rotating payloads. A behavioral scoring model can classify them with high confidence.
• Track payload rotation patterns. Even with rotating keys, the pattern of rotation is observable. How often does the key change? Is the rotation interval constant? Does the MAC address rotate in sync with the payloads or independently? These meta-patterns are fingerprints.
• Count and classify nearby trackers. A passive receiver can inventory all Find-My Beacons in range, classify them by protocol (Apple, Google, Samsung, Tile), and follow their movements relative to the observer — all without breaking encryption.

The “Macless” approaches are a step forward, but they do not render devices invisible. They make it harder to identify devices on the data layer while remaining fully visible on the radio layer. And for surveillance detection, knowing a tracking device is following you, visibility on the radio layer is decisive.

What can you do?

Completely quiet radio silence would mean giving up wireless devices altogether, which for most people is not realistic. But understanding what your devices send is the first step to controlling your exposure.

Disable WLAN when you are not connected to a network. The biggest WLAN privacy leak — Probe Requests — only occur when your device searches for networks. If you don’t actively use WLAN, turning it off stops the broadcast of your network history. Most phones have a quick switch for this.

Check which devices actually need radio. Does your dashcam need WLAN on if you’re not transferring footage? Does your fitness tracker need Bluetooth if you’re not syncing? Every active radio module is a module that transmits.

Use Airplane Mode in sensitive places. If you need to minimize your radio footprint — in situations where you worry about surveillance — turning off all radio modules at once is the most effective single measure.

Be aware that “smart” devices also transmit in idle. A smart-home sensor does not stop transmitting when no one looks at the app. A tracker tag does not stop transmitting when it lies in your pocket. Wireless devices are designed to always be on and always transmitting.

Understand your own RF footprint. Surveillance and detection tools can show you exactly what your devices send and how they appear to a passive observer. Knowing your own fingerprint is the foundation to controlling it.

Conclusion

We invest enormous effort in digital privacy, encrypted messages, VPNs, privacy-respecting browsers, cookie-consent dialogs. But beneath all this software, the physical radio layer of every wireless device you carry continuously broadcasts identity information into the air.

This is not a bug. This is how radio protocols are designed. WLAN Probe Requests, BLE Advertisements, tracker beacons, they all work by broadcasting structured, identifying data on public radio frequencies. Anyone with commonly available hardware can receive and interpret these signals. No hacking needed. No laws broken. Just physics.

MAC randomization helps. Encrypted payloads help. But as long as a device transmits a radio signal, that signal contains information about what the device is, what it can do, who made it, and how it behaves. The fingerprint may change its shape, but it does not disappear.

Privacy is not only a software problem. It is a radio problem. And the first step to solving it is understanding that your devices are screaming.