BLE Scanning: How to See What's Broadcasting Around You

The Radio Environment You Can't See

Right now, in whatever room you're in, there are almost certainly multiple devices broadcasting BLE advertisements. Fitness trackers, wireless earbuds, phone accessories, smart home sensors, possibly your own phone advertising for Find My or Google's exposure notification system. All of it is visible to any device performing a passive BLE scan - no connection required, no interaction with the target device.

This is by design. BLE is built around a broadcast model. Devices that want to be findable - or want to communicate their presence and state - do so continuously, at regular intervals, on the three BLE advertising channels. Scanning is just listening on those channels.

This article covers how BLE scanning works, what information advertisements actually contain, what you can infer from different field types, and how tools like the BLEShark Nano and nRF Connect make this visible.

How BLE Advertising Works

BLE uses 40 channels across the 2.4GHz band. Channels 37, 38, and 39 are the advertising channels - the three frequencies where devices broadcast their presence. The remaining 37 channels are used for data connections once devices have paired or connected.

An advertising device broadcasts a packet on one or more of the three advertising channels at regular intervals. The advertising interval can range from 20ms (very frequent, higher power consumption) to 10.24 seconds (infrequent, battery-efficient). Most consumer devices use something in the 100ms-1000ms range as a tradeoff.

The advertising packet itself is a standard BLE PDU (Protocol Data Unit). The maximum payload is 31 bytes for legacy advertising (BLE 4.x) or up to 254 bytes for extended advertising (BLE 5.0+). Most devices use legacy advertising even if they support BLE 5.0, for backwards compatibility.

Passive vs Active Scanning

There are two modes of BLE scanning: passive and active.

Passive scanning: The scanner listens on advertising channels and records every advertisement it hears. The scanning device sends nothing. The advertising device has no idea it's being scanned. The received advertisement is called the ADV (advertising) PDU.

Active scanning: When the scanner sees an advertisement from a device that supports scan responses (ADV_IND or ADV_SCAN_IND types), it can send a SCAN_REQ packet to ask for additional data. The advertising device responds with a SCAN_RSP (scan response) containing up to 31 more bytes of information. The device now knows something scanned it (it received a SCAN_REQ), though it doesn't know who.

For privacy-sensitive scanning, passive mode is preferable - you learn everything in the primary advertisement without revealing your presence. Active scanning doubles the data you get from devices that support scan responses, but at the cost of sending identifiable packets.

The BLEShark Nano's BLE scanning mode operates passively by default, collecting advertisement data without transmitting SCAN_REQ packets.

sequenceDiagram
    participant DEV as BLE Device
(Advertiser)
    participant CH as Advertising Channels
(37, 38, 39)
    participant NANO as BLEShark Nano
(Scanner)
    participant UI as OLED Display

    Note over DEV: Advertising interval:
20ms to 10.24s

    loop Every advertising interval
        DEV->>CH: ADV_IND on Ch 37
(31 bytes payload)
        DEV->>CH: ADV_IND on Ch 38
        DEV->>CH: ADV_IND on Ch 39
    end

    Note over NANO: Passive Scan Mode
    NANO->>CH: Listen on Ch 37
    CH->>NANO: Capture ADV_IND
(MAC, RSSI, flags, name, UUIDs)
    NANO->>CH: Hop to Ch 38
    CH->>NANO: Capture ADV_IND
    NANO->>CH: Hop to Ch 39
    CH->>NANO: Capture ADV_IND

    NANO->>NANO: Deduplicate by MAC
Update RSSI values
    NANO->>UI: Render device list
sorted by signal strength

    Note over NANO: Active Scan Mode (optional)
    NANO->>DEV: SCAN_REQ
    DEV->>NANO: SCAN_RSP
(additional 31 bytes)
    NANO->>NANO: Merge ADV + SCAN_RSP data
    NANO->>UI: Update with extended info

Passive vs active BLE scanning - passive mode silently captures advertisements across three channels, while active mode sends SCAN_REQ to get additional data at the cost of revealing the scanner's presence.

graph TD
    subgraph PKT["BLE Advertisement Packet (max 31 bytes payload)"]
        direction LR
        HDR["Preamble +
Access Address +
Header"]
        PDU["Advertising PDU"]
        CRC["CRC"]
    end

    subgraph PAYLOAD["ADV_IND PDU Structure"]
        ADDR["AdvA: Advertiser
MAC Address (6 bytes)
Public or Random"]
        AD_DATA["AD Structures
(up to 31 bytes)"]
    end

    subgraph AD["AD Structure Format (TLV)"]
        LEN["Length
(1 byte)"]
        TYPE["Type
(1 byte)"]
        DATA["Data
(Length-1 bytes)"]
    end

    subgraph TYPES["Common AD Types"]
        T1["0x01: Flags
Discoverability mode"]
        T2["0x09: Complete Local Name
e.g. 'Galaxy Buds Pro'"]
        T3["0x03: Complete 16-bit UUIDs
Service identifiers"]
        T4["0xFF: Manufacturer Data
Apple iBeacon, Google"]
        T5["0x0A: TX Power Level
For distance estimation"]
        T6["0x19: Appearance
Device category icon"]
    end

    PDU --> PAYLOAD
    AD_DATA --> AD
    AD --> TYPES

    subgraph INFER["What You Can Infer"]
        I1["Device type from
appearance + UUIDs"]
        I2["Approximate distance
from RSSI + TX Power"]
        I3["Manufacturer from
company ID in 0xFF"]
        I4["MAC randomization
from address type bit"]
    end

    TYPES --> INFER

BLE advertisement packet anatomy - each advertisement carries structured Type-Length-Value data fields that reveal device identity, capabilities, and manufacturer information.

Inside the Advertisement Payload

Advertisement payloads are structured as a sequence of AD (Advertising Data) structures. Each structure is a TLV record: one length byte, one type byte, then the data. Multiple AD structures are packed sequentially in the 31-byte payload.

Common AD types you'll encounter:

The combination of fields in a given advertisement tells you a lot about what kind of device you're looking at and what it's doing.

What Each Field Reveals

Device Name (0x08/0x09): This is the most immediately human-readable field. "Bose QC45," "Galaxy Watch5," "Tile_A3F2," "John's AirPods Pro." Many devices include their full name in every advertisement. Some include only a shortened name. Some include no name at all in the advertisement and reserve it for the scan response or GATT read after connection.

Device names are set by the manufacturer and sometimes by the user. They often contain model information, user-set labels, and occasionally the owner's name if the device uses the default Bluetooth name derived from the phone ("Lisa's iPhone" as a name leaked via an accessory).

Service UUIDs (0x02/0x03/0x06/0x07): These advertised UUIDs tell you what GATT services the device exposes. Standard UUIDs are assigned by the Bluetooth SIG and identify specific profiles - 0x180D is Heart Rate Service, 0x1812 is Human Interface Device (keyboard/mouse), 0x180F is Battery Service, 0x1800 is Generic Access. 128-bit UUIDs are vendor-specific and often proprietary.

A device advertising UUID 0x1812 (HID) is presenting itself as a keyboard or input device. That's immediately interesting from a security standpoint - it's telling the world it will accept being treated as a keyboard input source. A device advertising 0x180D is a heart rate monitor. Service UUIDs give you a functional fingerprint of the device without any connection.

Manufacturer Specific Data (0xFF): This is where the interesting vendor-specific data lives. The first two bytes are always a Bluetooth SIG-assigned company identifier. After that, the payload is entirely up to the manufacturer. Apple puts Continuity Protocol data here. Samsung puts Galaxy device state here. Many fitness trackers put encrypted activity data here.

Even if you can't decode the proprietary payload, the company ID tells you the manufacturer. A scan populated with advertisements containing company ID 0x004C is Apple-heavy. Lots of 0x0075 means Samsung devices. This lets you quickly profile the device ecosystem in a space without identifying individuals.

TX Power Level (0x0A): Combined with the received signal strength (RSSI reported by your scanner), TX power lets you estimate the distance to the advertising device using the log-distance path loss model. The formula is approximate - multipath reflections, obstacles, and varying antenna efficiency introduce noise - but it's accurate enough for room-level location estimates.

This is how BLE asset tracking systems work. They don't need GPS; they use TX power + RSSI across multiple receivers to triangulate position. A single scanner can use this for rough distance estimation. Multiple scanners (like a Shiver mesh of BLEShark Nanos) can triangulate more accurately.

Flags (0x01): The flags byte tells you about the device's discoverability and connectivity state. Whether it's in general discoverable mode, limited discoverable mode, or non-discoverable. Whether it supports BR/EDR (Classic Bluetooth) in addition to BLE. This is useful for understanding what the device is trying to do - a device in limited discoverable mode is actively seeking pairing, while a non-connectable beacon is just broadcasting information.

MAC Addresses and Privacy

Every BLE advertisement includes the advertiser's MAC address - a 6-byte hardware identifier. Historically, MAC addresses were static and unique per device, making it trivial to track a device (and by inference, its owner) across time and location.

The Bluetooth specification added random address types to address this. Devices can advertise with a randomly generated MAC instead of their real hardware MAC. Two subtypes exist:

Static random addresses: Random but stable per power cycle or longer period. Changes on reboot but not continuously. You can track a device within a session but not across boots.

Resolvable private addresses (RPA): Generated periodically (typically every 15 minutes) using a key shared with bonded devices. Paired devices can "resolve" the address back to the real identity; unpaired scanners see a fresh-looking address every rotation period. This is the most privacy-preserving option.

iOS and Android both use RPAs for their own Bluetooth advertisements by default. iPhones advertising for AirDrop, Find My, or other Continuity features rotate their MAC frequently. However, many IoT devices, fitness trackers, and low-cost accessories still use static real MACs - either because their firmware predates the privacy extensions or because the manufacturer didn't bother implementing them.

When scanning, the BLEShark shows MAC addresses for all observed devices. Devices with static MACs can be tracked over time. Devices with RPAs will appear to change identity regularly - nRF Connect and similar tools will show new entries as the address rotates.

Fingerprinting Devices Without a Name

Some devices advertise with no device name and a randomized MAC. Does that make them anonymous? Not entirely.

The combination of advertised service UUIDs, manufacturer data company ID, advertisement interval, payload structure, and TX power creates a reasonably distinctive fingerprint for a device model even without an explicit name. Two devices of the same model will have nearly identical advertisement structures; two different model devices rarely match across all fields.

More concretely: a device advertising with company ID 0x004C, a 25-byte manufacturer payload starting with 0x07 0x19, and specific service UUIDs is almost certainly AirPods. A device with company ID 0x0006 (Microsoft), service UUID 0xFE2C, and a 3-byte model ID payload is almost certainly a Fast Pair headset. You don't need the device name; the protocol tells you.

This is fingerprinting at the protocol level, and it works well enough to identify device categories and often specific models in the wild.

Using nRF Connect for BLE Scanning

nRF Connect (Nordic Semiconductor, available for Android and iOS) is the most widely used BLE scanner app. It shows all nearby advertisements in real time, lets you select individual devices to view decoded AD structures, displays RSSI and TX power, supports active scanning for scan responses, and can filter by service UUID or name.

For raw advertisement data analysis, nRF Connect is the best free option. Wireshark with a BLE-capable sniffer (TI CC2540 dongle, or a computer running the nRF Sniffer firmware) lets you capture and analyze at the packet level with full protocol decode.

The BLEShark Nano's BLE scanning mode gives you a field-portable scanner with OUI lookup built in. When you see a manufacturer data entry, the Nano cross-references the company ID against its OUI database to show the manufacturer name rather than raw hex. For quick environmental scans without pulling out a laptop, this is faster than nRF Connect.

Privacy Implications in Practice

A passive BLE scan of a public space reveals a detailed picture of the devices - and therefore the people - present. Fitness trackers with static MACs are particularly exposed: a device that stays in the same RSSI range across multiple scan sessions can be correlated to a specific individual if the scanner is in a fixed location (a shop entrance, a conference room doorway).

This isn't theoretical. Academic research has demonstrated the ability to build occupancy maps, track individuals through retail spaces, and identify which employees are in which meeting rooms using BLE advertisement data alone. None of this required pairing with or connecting to any device. All passive.

For security assessments, a BLE scan is legitimate recon. You learn what devices are present, what protocols they speak, what services they expose, and how they handle privacy. This data feeds directly into the BLE section of a wireless assessment report.

For individuals, the practical takeaway is: turn Bluetooth off when you're not using it, prefer devices from manufacturers who implement RPA properly, and understand that "Bluetooth is on" means "I am broadcasting".

What BLEShark Nano Shows You

The BLEShark Nano's BLE scanner displays nearby devices with signal strength, manufacturer identification via OUI lookup, and decoded advertisement data. It's designed for field use - walking through a space with the Nano and seeing what's broadcasting in real time, without needing a phone app or laptop.

For a full site survey, deploying multiple Nanos as a Shiver mesh (up to 16 nodes, ESP-NOW at 250 kbps Long Range, 20-50m range) lets you aggregate BLE scan results across a physical space simultaneously. Each node scans independently; results propagate to the master node for a unified view. This is particularly useful for finding devices that are only intermittently within range of any single scanner position.

Understanding what BLE scanning reveals is the first step toward either securing the devices that are broadcasting on your network - or finding the ones that shouldn't be there.