A Comprehensive Guide to Analyzing Bluetooth Low Energy Snoop Dumps on Android via Wireshark!

If you came to this blog, then definitely you must be working related to Bluetooth and trying to figure out why things didn’t work properly.

Have you ever wondered how those smart devices around you communicate wirelessly with such low energy consumption? It’s all thanks to Bluetooth Low Energy (BLE) technology, which is used widely in the Internet of Things (IoT) world. We’re going to take a look through the process of using Wireshark — a network detective tool — to find details in BLE communication dumps captured from an Android device.

Working with Bluetooth Low Energy sometimes can be a pain to understand what's going on inside the device, when one initiates pairing, how the pairing popup gets transmitted, or how we get information regarding gatt attributes.

So, After struggling a lot to dig deep about the work and how to analyze snoop dump I got some of the points which helped me diagnose the actual cause behind various issues.

What are Snoop logs?

Snoop logs are like a behind-the-scenes record of Bluetooth conversations. They capture the messages and signals exchanged between devices, helping us see how devices talk to each other without all the technical talk. It’s like eavesdropping on a friendly chat between Bluetooth buddies to understand how they work together.

What You Need:

First things first — you’ll need an Android device that can do BLE stuff, a computer with Wireshark on it, a USB cable to hook up your Android buddy to the computer, and a sprinkle of understanding about BLE and how things chat over networks. Plus, make sure your Android device is ready to party with developer options and USB debugging turned on.

Bluetooth Host Control Interface (HCI) contains all interactions between a host and a Bluetooth radio controller.

The host is the main CPU that runs a Bluetooth stack. The controller is a separate chip that controls the low-level Bluetooth radio. These two devices (inside the phone) talk with each other usually over UART using the HCI protocol. Yes, INSIDE THE PHONE, both host and controller reside!

Generating SnoopDump Logs from an Android Device

To generate SnoopDump logs from an Android device for Bluetooth communication analysis, follow these steps:

1. Enable USB Debugging: Access “Developer options” in settings, and turn on “USB debugging.”
2. Enable Bluetooth HCI Snoop Log: Activate “Bluetooth HCI snoop log” in “Developer options.”
3. Run Bluetooth Experiments: Conduct your desired Bluetooth interactions and experiments.
4. Capture Bug Report: Connect your device to a computer via a USB cable.
5. Use ADB to Capture Bug Report: Execute theadb bugreport zipFileName command in the ADB directory.
6. Extract and Locate Logs: Extract the generated zip file and navigate to “FS/data/misc/bluetooth/log” Find “bluetooth.cfa” — your SnoopDump log file.

Following these steps will enable you to efficiently capture and access SnoopDump logs from your Android device, aiding in Bluetooth communication analysis and troubleshooting.

Exploring the Dump File

Now, Let’s open these logs inside WireShark. It's a powerful network protocol analyzer that allows users to capture, dissect, and analyze network traffic, providing insights into communication patterns, data flows, and potential issues within various network protocols.

The provided image illustrates the utilization of WireShark to open a sample log file. Within the interface, you’ll observe a range of Protocols, such as HCI_CMD, HCI_EVT, and HCI_ATT, displayed in the upper section. This window showcases data transmissions originating from a source and directed toward a destination. On the lower-left part of the interface, additional information related to the selected signal is available.

Let’s segregate these:

• Source
• Destination
• Protocol: HCI_CMD, HCI_EVT, HCI_ATT, HCI_ACL, SMP, L2CAP
• Info Status: Sent/Received
• Info Message
• Frame Time
• Bluetooth HCI Response

1. Source and Destination: The “Source” refers to the device or module initiating the communication, and the “Destination” is the device or module receiving the communication. This helps you identify which devices are involved in the data exchange.
2. Protocol: This shows different Bluetooth protocols that are being used during data transmission. If we look carefully inside Bluetooth stack then we can correlate where HCI and L2CAP exist.

• HCI_CMD (Host Controller Interface Command): Commands sent from the host to the Bluetooth controller.
• HCI_EVT (Host Controller Interface Event): Events generated by the Bluetooth controller to inform the host about specific states.
• HCI_ATT (Attribute Protocol): Used for attribute-based communication, seen in GATT-based BLE applications.
• HCI_ACL (Asynchronous Connectionless Link): Handles data transmission between devices.
• SMP (Security Manager Protocol): Manages security-related aspects of Bluetooth connections.
• L2CAP (Logical Link Control and Adaptation Protocol): Responsible for creating logical channels for data transmission or simply it fetches packets between Host🔄Controller, There are more protocols but these are the most common ones.

3. Info Status: Sent/Received: This indicates whether the specific communication message was “Sent” from the source device or “Received” by the destination device. It helps track the direction of data flow.

4. Info Message: This is where you would find the detailed content of the communication message. It could include information about the data being exchanged, commands, events, or any other relevant details.

5. Frame Time: We can check the frame time epoch and verify the transmission happened at what time.

6. Bluetooth HCI Response: This will help us to know what response one received in this segment. This is sometimes helpful to find out the error reason in the response section.

Exploring basic BLE pairing Logs and Interpreting via Protocols

Here’s a breakdown of the logs showcasing various protocols and their corresponding actions:

HCI_CMD:

• Scan Sent LE Extended Scan Enable-> Start Scanning: Initiating the scanning process, the device readies itself to explore its surroundings. The device starts looking around for other BLE devices. It’s like saying “Hey, anyone out there?”
• Received Sent LE Meta Advertising -> Listing All Advertising Devices: As the scan starts, the device receives a list of advertising devices within its range.
• Connection Update -> Filtered MAC Address: After the scan results, the filtered MAC address emerges as the chosen partner. A connection update prepares for a secure connection.

HCI_EVT:

• Received Disconnect Complete -> Disconnection Happened -> Bluetooth HCI EVT -> Reason: In the process, a disconnection signal may occur. The reason behind this occurrence can be found by checking Reason in the lower left section of the Bluetooth HCI Event.

HCI_CMD:

• Send 0x015FCommand -> Scan: An encoded command (0x015F) triggers a renewed scan, ensuring a proper scanning of the environment.
• Sent LE Create Connection Command -> Start Connection: With the knowledge of potential companions, the device attempts to establish a connection with the chosen advertiser.
• Sent Write Link Policy Settings -> Fetch Compatibility Info: It refers to configuring rules that govern how devices interact over the connection. These settings influence aspects like power efficiency, data flow, and reliability, ensuring an optimized and smooth communication experience between devices.

HCI_EVT:

• Received 0x015F Command -> Scan Acknowledged -> Start Scanning: When the other device says “Got it!” after scanning, our device happily continues scanning.
• Sent LE Enhanced Connection Complete: MAC Address of Connected Devices: Then there's a successful connection. The MAC address of the chosen companion will now signify the bond.

SMP:

• Now Comes the Real Deal — SMP: Till now all these are happening inside the device only, in SMP we incorporate the actual device and the BLE server.
• Received Security Req -> Long Term Key (LTK) Attributes: The device asks for a secure chat, and if agreed, secret keys are revealed for secure talk. These cryptographic elements form the foundation of secure communication.
• Sent Pairing Key: The key to a secure connection is shared, bridging the gap between devices and establishing a confidential channel.
• Pairing DHKey Check (Deffie Hellman Key Exchange): Employing the Deffie Hellman Key Exchange method. They share secret numbers like a secret handshake, making sure they can trust each other.
• Received Identity Information: At this moment identity information is exchanged, stating the authenticity of each device.
• Received Address Information: They also share addresses, showing where they live.

HCI_ACL:

• Following the grand connection event, an asynchronous connection link (ACL) event takes the stage. This event facilitates the transmission of GATT data, where the devices exchange information about attributes and characteristics. The host generates and dispatches a random signal, ensuring a symphony of communication between the devices.

In this exploration, we’ve covered snoop logs, which act as a backstage pass to understanding Bluetooth conversations. We learned how to create these logs and take a peek inside using WireShark, where we decoded various sections like protocols, sources, destinations, and messages. Through simple examples, we followed the flow of disconnection and pairing in BLE, even pinpointing the arrival of GATT characteristics. This newfound knowledge motivated me to share, as such insights can be hard to come by. These insights have proven invaluable for diagnosing IoT and Bluetooth-related issues, shedding light on the intricate workings of these technologies.

Thank you for taking the time to read my article! I hope you found it insightful and informative. As I continue on my learning journey, I’ve done my best to share the insights I’ve gained. If you come across any mistakes, please feel free to point them out. Your engagement and feedback mean a lot as I strive to contribute and learn in this space.

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.