Bluetooth Forensics

Every Bluetooth pairing produces a persistent record on both devices. The record is written at pairing time and survives device restarts. It is updated when the device reconnects. The evidential value is significant: a pairing record places two specific devices in physical proximity, typically within 10 metres for classic Bluetooth and within 100 metres for BLE outdoor connections, at the time the record was created.

On Android, the Bluetooth stack stores pairing data in /data/misc/bluedroid/bt_config.conf (Android 6.0 and later) or the legacy bt_config.xml. Each paired device entry contains the Address field (BD_ADDR or BLE address), the Name field (the remote device's friendly name as it was set at pairing time), the Timestamp field (Unix epoch of the last connection), the DevClass or Appearance field, and the LinkKey or LE_KEY_PENC field containing the link key or BLE Long-Term Key. The file is a plain-text INI-style format and can be parsed without specialist tools, though dedicated mobile forensic tools such as Cellebrite UFED and Oxygen Forensic Detective extract and display it automatically.

On iOS, paired Bluetooth device data is stored in /private/var/mobile/Library/Preferences/com.apple.MobileBluetooth.devices.plist. This binary plist contains a dictionary keyed by device address, with sub-keys for the device name, the last-connect date, the device type, and pairing keys. The path is not accessible from a standard iTunes or Finder backup; it requires either a full-filesystem acquisition via checkra1n or similar bootrom-level method, or extraction via an agent-based tool that runs on a jailbroken device. An iCloud backup does not include this path.

Windows stores Bluetooth pairing data in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices\. Each paired device has a subkey named by its BD_ADDR. Within the subkey, the Name value holds the friendly name and the LTK or LinkKey value holds the pairing key. The registry also records service records that show which Bluetooth profiles the device supported, which is useful for establishing how the two devices were used together.

Classic Bluetooth supports a set of standardised profiles that define how devices use the protocol for specific purposes. Each profile leaves different artifacts. An examiner who knows which profile was in use can focus on the right artifact locations and interpret the data in context.

The Object Exchange protocol (OBEX), used by the Object Push Profile (OPP) and File Transfer Profile (FTP), is the mechanism for sending files between phones, from phone to PC, or from phone to printer. When a file is sent via OBEX, many devices record the transfer in an application-level log or in the phone's media database. On Android, received files land in /sdcard/bluetooth/ and are indexed by the MediaStore content provider. The transfer record includes filename, size, direction (sent or received), and timestamp. On iOS, AirDrop uses a proprietary protocol rather than OBEX, but Bluetooth-based OBEX transfers to non-Apple devices still leave records in the Bluetooth preferences plist.

The Hands-Free Profile (HFP) and Headset Profile (HSP) pair a phone with a vehicle infotainment system or wireless headset. The most forensically significant artifact from these pairings is the vehicle connection record, which logs each connection event with a timestamp. Many modern vehicle head units retain a pairing history independently of the phone. In criminal investigations, the vehicle's infotainment database has been extracted to place a specific phone, and by extension its owner, in a vehicle at a specific time. This evidence has been used in cases in the United States, the United Kingdom, and Australia.

The Phone Book Access Profile (PBAP) allows a vehicle or headset to download the phone's contact list and call log. This creates a copy of the contact database inside the vehicle. If the phone is wiped or destroyed before examination, the vehicle's copy may be the only surviving record of the contact list and recent calls. PBAP transfers are one-way: the vehicle requests and receives; the phone does not record that the transfer happened in a dedicated log, though the Bluetooth connection event is recorded.

BLE devices communicate primarily through the Generic Attribute Profile (GATT). A peripheral device, such as a fitness tracker, acts as a GATT server and exposes data organised as Services, each containing one or more Characteristics. A central device, such as a phone, acts as a GATT client and reads or subscribes to those Characteristics. The data exchanged includes heart rate measurements, step counts, blood glucose readings, location coordinates from GPS accessories, and proprietary application data.

BLE packet captures reveal the content of GATT operations: which Service was accessed, which Characteristic was read or written, and what value was exchanged. For a fitness tracker, this means the forensic record can include step-by-step movement data, sleep records, and heart rate timelines. In a 2019 case in the United States (State v. Bates, Connecticut), a Fitbit's activity data was used to challenge a witness account of events. Similar cases have proceeded in Australia and Germany using activity data extracted from wearable devices paired via BLE.

Address randomisation is the main complication in BLE device identification. The BLE specification defines three address types for peripheral devices. A public address is the fixed BD_ADDR assigned by the manufacturer. A static random address is generated at device power-on and stays fixed for that power cycle, but changes on reset. A resolvable private address (RPA) rotates periodically, typically every 15 minutes, using a rotation algorithm keyed to the device's Identity Resolving Key. An examiner who captures only advertising packets without also capturing the pairing exchange cannot determine whether two different observed addresses belong to one device or two separate devices.

The BLE bonding database on Android is stored at /data/misc/bluedroid/bt_config.conf in the same file as classic pairing records. BLE entries include LE_KEY_PENC (encrypted link key), LE_KEY_PID (containing the IRK and the device's true Identity Address), and LE_KEY_LENC (local encryption key). The LE_KEY_PID entry is what makes RPA resolution possible in post-hoc analysis of a capture file. Examiners should extract and preserve this value before the device is returned, powered off for an extended period, or wiped.

On-device logs record events from the perspective of one device. A packet sniffer records raw radio frames from all devices communicating on the observed channels, independent of any pairing relationship with those devices. This distinction matters when the device of interest cannot be examined directly, when activity from an unknown third device must be documented, or when the sequence of frames needs to be established at a precision finer than application-layer log timestamps permit.

The Ubertooth One is the most widely used open-source Bluetooth sniffer in forensic practice. It is a USB device that operates on the 2.4 GHz ISM band. For classic Bluetooth, the Ubertooth follows an active piconet by hopping channels synchronised to the master's clock, capturing all frames on that piconet. For BLE, it can capture advertising packets on the three advertising channels (37, 38, 39) and follow connections after observing the connection initiation exchange. Output is written to a PCAP file, the same format used by Wireshark, making it directly analysable with standard network forensic tools. The Ubertooth One has hardware limitations: it cannot decrypt encrypted classic Bluetooth traffic unless the pairing exchange was also captured (to derive the session key), and it cannot follow a BLE connection if it misses the connection request packet.

Commercial alternatives include the Ellisys Bluetooth Analyser, Frontline ComProbe, and ASUS USB-BT500 with vendor sniffer firmware. These tools offer wider frequency coverage, higher reliability for following connections, and often include protocol decode displays integrated into their own software. They are more expensive than the Ubertooth One and are common in laboratory settings. In field deployments where portability matters, the Ubertooth One is preferred.

Android devices include a built-in HCI (Host Controller Interface) snoop log that records all Bluetooth HCI commands and events passing between the Bluetooth host stack and the controller. On Android, this is enabled in Developer Options under the Bluetooth HCI snoop log setting. The log is saved to /data/misc/bluetooth/logs/btsnoop_hci.log (path varies by manufacturer). When enabled before the events of interest, the HCI snoop log captures all Bluetooth activity on that device including both classic and BLE traffic, in a PCAP-compatible btsnoop format. This is the most reliable way to document Bluetooth activity on an Android device without external hardware, but it requires the logging to have been enabled before the activity occurred.

Bluetooth pairing records require deeper acquisition than many other mobile artifacts. A standard logical extraction or a cloud backup typically does not include the Bluetooth stack database. The examiner must match the acquisition method to the artifact depth required.

For Android devices, a physical acquisition (full NAND image) or a file-system extraction via Android Debug Bridge (ADB) with root access reaches /data/misc/bluedroid/. Without root, ADB backup extracts only application data for apps that permit it, and the Bluetooth stack database is excluded. Some Android versions support extraction via the MediaProvider content resolver for external storage, but internal Bluetooth data requires elevated access. For devices that cannot be rooted, JTAG or chip-off acquisition reaches the raw NAND and includes the Bluetooth database within the filesystem image. See Physical Acquisition Techniques for the hardware-level methods.

For iOS devices, a full-filesystem acquisition is required. This is achievable via bootrom exploits (checkra1n on devices with A11 or earlier chips), agent-based extraction on jailbroken devices, or by using GrayKey or similar law-enforcement tools on supported iOS versions. A standard iTunes or Finder encrypted backup does not include the Bluetooth plist path. An iCloud backup does not include it. Examiners who can only perform a logical acquisition of an iOS device will not have access to Bluetooth pairing records and should document this limitation in their report.

Preservation steps for Bluetooth evidence are the same as for other mobile artifacts: isolate the device from radio signals (Faraday bag or airplane mode) to prevent remote wipe, calculate hash values of all extracted files before analysis, document the tool version and acquisition method, and retain the original extracted files as the master copy. For sniffer captures, the PCAP file should be hashed immediately after capture, and the hash value and collection metadata recorded in the examination log. Chains of custody for PCAP files are as important as for device images, because a sniffer capture file is the only record of what was transmitted in a wireless communication.

Bluetooth evidence rarely stands alone. Its value comes from corroborating or contradicting other evidence about the physical location and activity of a person or device. An examiner who understands the practical range limitations, the timestamp sources, and the conditions for false positives will present Bluetooth evidence with appropriate confidence levels.

Range is the most commonly misunderstood parameter. Classic Bluetooth Class 1 devices (typically USB dongles and access points) have a nominal range of 100 metres in open space. Class 2 devices (typical mobile phones) have a nominal range of 10 metres. In practice, walls, bodies, and interference reduce both figures. A pairing record establishes proximity at the time of the initial pairing, but a connection event logged after the initial pairing is also possible at the maximum device range. The examiner cannot infer from a connection event alone that two people were standing next to each other; they can infer that the devices were within radio range.

Timestamps in Bluetooth records are subject to the same clock accuracy issues as other mobile timestamps. The device clock may be ahead of or behind real time, and it may have drifted if the device was without network time synchronisation for an extended period. Timestamps from bt_config.conf on Android are Unix epoch seconds from the device's local clock. Where the device clock accuracy is in question, the examiner should cross-reference the Bluetooth timestamp with network event logs, call records, or other timestamped artifacts from the same device to establish a clock-offset value.

A Bluetooth pairing record does not prove that the registered owner of the device was present: it proves that the device was present. In cases where device-to-person attribution is contested, Bluetooth evidence must be combined with other evidence such as call logs, location data, biometric unlock records, or witness testimony. The combination of a Bluetooth connection event between a phone and a vehicle, GPS coordinates from the same phone, and a call log entry from the same time window provides much stronger placement evidence than any single artifact. See Location History and Geolocation Artifacts for how Bluetooth artifacts interact with GPS and cell-tower positioning.