Using Wireshark for Bluetooth Analysis

Wireshark is the standard tool for network protocol analysis, and it handles Bluetooth just as well as Ethernet. If you are working with BLE devices - testing them, debugging them, or auditing their security - Wireshark gives you packet-level visibility into everything happening on the Bluetooth link.

The challenge with Bluetooth analysis is not Wireshark itself but getting the capture data into it. Unlike WiFi or Ethernet where you can just sniff the air or tap a cable, Bluetooth requires specific capture methods. This guide covers those methods and walks through analyzing the resulting data.

Why Wireshark for Bluetooth

Wireshark dissects Bluetooth protocols at every layer. From the radio-level Link Layer through L2CAP and ATT up to GATT, Wireshark decodes and displays every field. It understands standard Bluetooth SIG profiles and characteristics, so it can tell you that characteristic 0x2A19 is "Battery Level" and that the value 0x4B means 75%.

For BLE security research, Wireshark shows you:

• What a device advertises and how often
• The complete GATT service discovery process
• Every read, write, and notification with decoded values
• Pairing and bonding exchanges
• Encryption setup and key exchange
• Protocol errors and malformed packets

Capture Methods

graph TD
    subgraph "Capture Methods for BLE"
        A["HCI Log\n(Android/Linux)"] --> E["btsnoop_hci.log"]
        B["PacketLogger\n(macOS/iOS)"] --> F[".pklg file"]
        C["nRF Sniffer\n(Hardware)"] --> G["Live Wireshark\ncapture"]
        D["Ubertooth\n(Hardware)"] --> H["PCAP file"]
    end
    subgraph "Import to Wireshark"
        E --> I["File > Open"]
        F --> I
        G --> J["Live capture\ninterface"]
        H --> I
    end
    subgraph "Analysis"
        I --> K["Apply BLE\ndisplay filters"]
        J --> K
        K --> L["Decode protocols"]
        L --> M["Extract data"]
    end

Different BLE capture methods and how they feed into Wireshark for analysis

There are several ways to capture Bluetooth data for Wireshark analysis:

HCI logs (most accessible): Every Bluetooth stack passes data through the Host Controller Interface (HCI). On Linux and Android, you can capture HCI traffic directly. This shows you everything your Bluetooth adapter sends and receives, including advertising, connections, and data transfer. The limitation is that you only see traffic involving your own adapter.

Dedicated sniffers (most complete): Hardware sniffers like the nRF52840 dongle with Nordic's nRF Sniffer firmware or the Ubertooth One can passively capture BLE traffic from any nearby device. These integrate directly with Wireshark as capture interfaces.

PacketLogger (macOS): Apple's PacketLogger tool captures Bluetooth traffic on macOS and iOS. The .pklg files can be opened directly in Wireshark.

Capturing HCI Logs

Linux:

# Start capture
sudo btmon -w capture.snoop

# Or use hcidump
sudo hcidump -w capture.snoop

# For live Wireshark capture
sudo modprobe btusb
sudo hcitool lescan &   # Start scanning in background

On Linux, the btmon tool is the most reliable way to capture HCI traffic. It captures all Bluetooth activity on the system, including BLE advertising, connection events, and data transfers.

For live capture directly in Wireshark, the bluetooth0 interface should appear in Wireshark's interface list if your kernel supports it:

sudo wireshark

Select the bluetooth interface (usually bluetooth0 or bluetooth-monitor) and start capturing.

Android:

Android has a built-in Bluetooth HCI snoop log. Enable it in Developer Options:

1. Go to Settings > Developer Options
2. Enable "Enable Bluetooth HCI snoop log"
3. Perform the Bluetooth activity you want to capture
4. Pull the log file: adb pull /sdcard/btsnoop_hci.log
5. Open the .log file in Wireshark

The log location varies by manufacturer and Android version. Some devices store it at /data/misc/bluetooth/logs/btsnoop_hci.log (requires root) or /sdcard/btsnoop_hci.log.

You can also use the bug report method:

adb bugreport bugreport.zip
# Extract and find btsnoop_hci.log inside the archive

macOS:

Use Apple's PacketLogger (available from Apple's developer downloads):

1. Open PacketLogger
2. Start capture
3. Perform Bluetooth operations
4. Save as .pklg file
5. Open in Wireshark

Importing Captures into Wireshark

Wireshark natively opens these Bluetooth capture formats:

• .snoop / .log - btsnoop format (Android HCI logs, btmon output)
• .pklg - Apple PacketLogger format
• .pcap / .pcapng - Standard capture format (from sniffers)

Just use File > Open and select the file. Wireshark auto-detects the format.

If Wireshark does not dissect the Bluetooth protocols correctly, check that the DLT (Data Link Type) is set correctly. For HCI captures, you may need to set the encapsulation type via Edit > Preferences > Protocols > HCI_H4.

BLE Protocol Stack in Wireshark

graph TD
    subgraph "BLE Protocol Stack in Wireshark"
        A["HCI\nHost Controller Interface"] --> B["L2CAP\nLogical Link Control"]
        B --> C["ATT\nAttribute Protocol"]
        C --> D["GATT\nGeneric Attribute Profile"]
        B --> E["SMP\nSecurity Manager Protocol"]
        A --> F["Link Layer\nAdvertising, Connection"]
    end
    subgraph "Wireshark Display Filters"
        D --> G["btatt"]
        C --> G
        E --> H["btsmp"]
        B --> I["btl2cap"]
        A --> J["bthci_acl, bthci_cmd, bthci_evt"]
        F --> K["btle"]
    end

BLE protocol layers and their corresponding Wireshark display filter prefixes

Understanding the BLE stack helps you navigate captures. From bottom to top:

Link Layer (btle): Advertising packets, connection requests, and raw link-layer data. You see this with hardware sniffers.

HCI (bthci_cmd, bthci_evt, bthci_acl): Commands sent to the Bluetooth controller, events received from it, and ACL data packets. This is what HCI logs capture.

L2CAP (btl2cap): Logical link layer that multiplexes data channels. BLE uses fixed channels for ATT (CID 0x0004) and SMP (CID 0x0006).

ATT (btatt): Attribute Protocol that handles read, write, and notification operations on attributes.

SMP (btsmp): Security Manager Protocol for pairing, bonding, and key exchange.

Analyzing Advertising Packets

BLE advertising is the first thing you see when analyzing a device. Advertising packets contain:

• Device address (potentially randomized)
• Device name (if included)
• Service UUIDs (what the device offers)
• Manufacturer-specific data
• TX power level
• Flags (connectable, discoverable, etc.)

Filter for advertising in Wireshark:

btle.advertising_header
btle.advertising_header.pdu_type == 0x00   # ADV_IND (connectable undirected)
btle.advertising_header.pdu_type == 0x02   # ADV_NONCONN_IND (non-connectable)
btle.advertising_header.pdu_type == 0x04   # SCAN_RSP (scan response)

From HCI captures, advertising appears as HCI LE Advertising Report events:

bthci_evt.le_meta_subevent == 0x02   # LE Advertising Report

Click on an advertising packet and expand the Bluetooth tree to see all AD structures decoded. Wireshark interprets standard AD types (flags, service UUIDs, local name, TX power) automatically.

Analyzing Connections

A BLE connection starts with a connection request and proceeds through service discovery before application data flows.

Key events in a connection:

# Connection established
bthci_evt.le_meta_subevent == 0x01   # LE Connection Complete

# Connection parameters update
bthci_evt.le_meta_subevent == 0x03   # LE Connection Update Complete

# Disconnection
bthci_evt.code == 0x05               # Disconnection Complete

After connection, the central typically performs GATT service discovery. You will see a series of ATT requests (Read By Group Type, Read By Type, Find Information) that enumerate all services and characteristics.

Decoding GATT Operations

GATT operations are the most interesting part of BLE analysis. Filter for ATT protocol:

btatt

Read operations:

btatt.opcode == 0x0a   # Read Request
btatt.opcode == 0x0b   # Read Response

Write operations:

btatt.opcode == 0x12   # Write Request
btatt.opcode == 0x13   # Write Response
btatt.opcode == 0x52   # Write Command (no response)

Notifications and indications:

btatt.opcode == 0x1b   # Handle Value Notification
btatt.opcode == 0x1d   # Handle Value Indication

Wireshark decodes standard Bluetooth SIG characteristics automatically. For example, a read response on handle 0x0019 for characteristic UUID 0x2A19 (Battery Level) will show the decoded value as a percentage.

For vendor-specific characteristics (non-standard UUIDs), the data appears as raw hex. You need to know the vendor's protocol to interpret it. This is where capturing multiple operations and correlating them with app behavior helps you reverse-engineer the protocol.

Essential Display Filters

Quick reference for the most useful Bluetooth display filters:

Combine filters with logical operators:

btatt && btatt.opcode in {0x12 0x52}   # All write operations
btatt.handle == 0x0025 && btatt.opcode == 0x1b   # Notifications on specific handle

Practical Analysis Workflows

Reverse engineering a BLE device protocol:

1. Enable HCI snoop log on your phone
2. Open the device's companion app
3. Connect to the device and perform various operations (read sensor, send command, change settings)
4. For each operation, note the time and what you did
5. Pull the HCI log and open in Wireshark
6. Use time correlation and ATT filters to identify which GATT writes correspond to which app actions
7. Look for patterns: fixed headers, incrementing counters, recognizable data

Analyzing pairing security:

btsmp

Filter for SMP to see the complete pairing exchange. Check for:

• Pairing method (Just Works, Passkey, Numeric Comparison, OOB)
• IO capabilities exchanged
• Whether Secure Connections is used (SC flag in pairing request)
• Key distribution (which keys are exchanged)

"Just Works" pairing with no Secure Connections flag is the weakest configuration and vulnerable to MITM.

Debugging BLE communication issues:

When a BLE device is not working properly, Wireshark shows you exactly where the communication fails:

btatt.error_code   # Show all ATT errors

Common errors include:

• 0x05 - Insufficient Authentication (need pairing)
• 0x06 - Request Not Supported
• 0x07 - Invalid Offset
• 0x0e - Insufficient Encryption (need encrypted link)

Comparing captures:

When you have captures from both the BLEShark Nano (raw 802.11/BLE) and an HCI log from the connected phone, you can cross-reference them to build a complete picture. The BLEShark Nano captures the air interface while the HCI log shows the host-side processing.

Wireshark's Bluetooth conversation tracking (Statistics > Conversations > Bluetooth) gives you an overview of all Bluetooth connections in a capture, along with packet counts and data volumes per connection.

This article is for educational and authorized security testing purposes only. Only capture and analyze Bluetooth traffic from your own devices or with explicit written permission.