In the previous blog, we laid the groundwork by understanding the basics of Bluetooth Low Energy (BLE) what it is, how it works, and the key components that make BLE communication possible. Now, it's time to move from theory to practice. In this blog, we'll dive into the real-world process of capturing BLE traffic between a mobile app and a target device. We'll start by enabling the HCI snoop log on an Android phone, extracting the resulting capture file, and then analyzing it in Wireshark to uncover meaningful data exchanges.

Meet our target device "The Mystery Watch"

For privacy and responsible disclosure reasons, we won’t be naming the exact smartwatch used in this analysis. Instead, we’ll refer to it as our Mystery device. It’s a typical BLE-enabled smartwatch that communicates with its companion Android app to sync time, notifications, and other data.

If you're following along, you don’t need this exact model. You can pick up any inexpensive BLE smartwatch available online, pair it with its official app, and perform the same analysis steps. The key is that the device uses BLE, which is common in most fitness trackers, health bands, and entry-level smartwatches. Once you’ve chosen your target, you’re ready to move on to capturing the BLE conversation between the app and the device.

Capturing the Conversation

Once The Mystery Watch is paired with its app, it’s time to dig into the Bluetooth communication. Start by heading into your Android phone’s Developer Options and enabling Bluetooth HCI snoop log. This feature records all the Bluetooth Low Energy interactions between your phone and the connected device.

With logging enabled, open the companion app and interact with the watch as much as possible use every available feature. This helps capture the full range of BLE activity for later analysis.

Extracting the Log & Prepping for Analysis

After you're done interacting with the app, it’s time to retrieve the Bluetooth HCI log. Go to your phone’s Settings > System > Developer Options, scroll down, and tap "Take bug report". Once the report is generated (this might take a few minutes), share it to your email or file manager.

Inside the bug report ZIP, look for a file named something like btsnoop_hci.log. This is the raw BLE communication data between your phone and The Mystery Watch.

Now install Wireshark, the go-to tool for protocol analysis. Open the btsnoop_hci.log file in Wireshark and just like that, you're looking at the complete conversation between the app and the watch.

Once the HCI log is open in Wireshark, you'll be greeted with a stream of packets showing the back-and-forth communication. Here’s where things get interesting you can now see the source and destination addresses for each interaction. In our case, the target device (The Mystery Watch) can usually be identified by its MAC address, while your phone might appear with its name or another recognizable identifier.

You'll also notice other crucial details like the timestamp, protocol used (typically ATT or GATT in BLE communication), operation type (read/write/notify), and more. This view gives you full transparency into how the app and watch communicate, laying the groundwork for identifying what’s being sent and when.

Digging Into BLE Operations with Filters

We won’t go too deep into Wireshark analysis in this blog, but just enough to get what we need the handles that the app uses to communicate with the device. One of the most useful filters here is for detecting write commands, which reveal what handle is being written to, and what data is being sent. You can use the following Wireshark display filter:

btatt.opcode == 0x52

This shows all Write Command packets. Each of these will contain a handle and the value being written exactly what we're after.

To go a bit further, you can also filter for Read Requests using:

btatt.opcode == 0x0A

This shows interactions where the app reads from a handle—often to pull status or configuration data.

Notifications from the device using:

btatt.opcode == 0x1B

This helps locate data being pushed by the device to the app, such as heart rate updates or step counts.

Knowing how to apply these filters lets you focus on just the relevant packets in a sea of BLE chatter. By identifying which handles are involved in each operation, you’re one step closer to replicating or controlling the interaction manually.

Finding What We Need

Now that we’ve applied the right filters, we’ve successfully found one of the most important pieces of dataa write operation to handle 0x003c. The value written in this case is:

Value: 0139c701ad5501ce790194b20100002901a80114

This is exactly the kind of data we were looking for. It shows the handle being written to, and the full payload being sent by the app to the device. These values represent some sort of instruction or configuration something the smartwatch understands and reacts to.

From here, your task is to inspect the entire HCI log file and gather more write, read, or notification packets like this one. Each of them can give clues about how different features of the app interact with the device. These will form the foundation for our next step, where we attempt to reproduce or manipulate these actions ourselves.

Next: Talking to Our Mystery Device Directly

In this blog, we took a hands-on look at how to capture and analyze BLE communication between a smartwatch (our Mystery Watch) and its companion app. From enabling HCI snoop logs on Android to diving into the captured packets using Wireshark, we identified crucial handles and payloads that the app uses to interact with the device.

Now that we’ve gathered this intel, our next step is to use tools like gatttool to directly communicate with the device ourselves send those same values, test different commands, and see how the watch responds.

So, stay tuned for the next part of our BLE adventure, where we’ll go from observers to active participants talking directly to the device and bending it to our will.