search

greatscottgadgets / ubertooth

Software, firmware, and hardware designs for Ubertooth
https://greatscottgadgets.com/ubertoothone/
GNU General Public License v2.0
1.92k stars 430 forks source link

BLE sniffing connection issue: Follow mode only follows a connection for a few seconds before tracking ends #435

Closed tjhasan closed 3 years ago

tjhasan commented 3 years ago

I am currently running some tests using ubertooth-one and fitness devices (Fitbit Inspire and Garmin Vivosmart) and it looks like the tracking via follow mode drops only after roughly 10 seconds. This is despite my connection between my fitness device and my phone still being actively used.

The devices I am using are as follows: Fitbit Inspire (not the HR version), Garmin Vivosmart 4, and Samsung Galaxy s8+. The devices are pre-paired to the phone and are NOT connected at the same time during the testing time.

Steps to reproduce

  1. Run command ubertooth-btle -f -c /tmp/pipe
  2. Connect BTLE device with a smartphone
  3. Confirm that Ubertooth-One is tracking the connection
  4. Wait for 5 - 10 seconds for the tracking to randomly stop.

Expected behavior

I expect that the connection between the BTLE device and the fitness device be tracked until my phone disconnects from the device.

Actual behavior

The tracking only lasts for roughly 5 to 10 seconds. On very rare occasions I've been able to hold the connection for upwards of 20 minutes but this does not seem to work consistently (I am not doing anything differently).

Version information

Operating system: MacOS Mojave 10.14.6

Ubertooth tools version (ubertooth-rx -V): libubertooth 1.1 (2018-12-R1

libbtbb version: libbtbb 1.0 (2018-06-R1)

Ubertooth firmware version (ubertooth-util -v): Firmware version: 2018-12-R1 (API:1.06)

Any advice or assistance would be greatly appreciated. Thank you very much.

mikeryan commented 3 years ago

Can you please try release 2020-12-R1 that was just released?

tjhasan commented 3 years ago

I updated the firmware to 2020-12-R1 and tested it again and was only able to follow the connection for 129 seconds before it was lost.

For reference, for this test, I used my Samsung Galaxy s8+ and my Garmin Vivosmart 4 with the hope of tracking the packets sent between them.

mikeryan commented 3 years ago

Can you please share a PCAP of the connection dropping? Does the Ubertooth return to displaying advertising packets or freeze up completely?

tjhasan commented 3 years ago

Absolutely, the pcap file is within the zip folder attached. Doesn't look like Github supports attaching .pcap files directly to messages. pcap.zip

The connection is caught and tracked starting with packet 1753 at roughly 89 seconds and the tracking lasts up to packet 2014 at roughly 216 seconds.

After that, the Ubertooth goes back to displaying advertising packets.

mikeryan commented 3 years ago

This connection uses encryption. I suspect what is happening is that sometime between 1-2 minutes after the connection is established, either the channel map or connection parameters are being updated by the phone or the device. Since the connection is encrypted, Ubertooth can't read those packets. Once the new channel map or connection parameters take effect, Ubertooth becomes unsynchronized from the connection and is no longer able to follow it.

Even if you know the LTK, Ubertooth does not support decrypting packets in real time. Thus there is no way around this if you're sniffing with Ubertooth.

Have you tried logging the data using macOS's Packet Logger tool? It can be installed by downloading "Additional Tools for Xcode" and will log Bluetooth in a Wireshark-like interface. It can also export pklg files that can be opened by Wireshark. These logs will show the data prior to encryption, and could be used to confirm my theory in addition to reverse engineering the fitness trackers.

tjhasan commented 3 years ago

Thank you very much for your help. I had a feeling the reason was something like that. Regardless I'll try using the macOS Packet Logger as you described. I've never used it before but I'll look into it and post an update hopefully by the end of today.

tjhasan commented 3 years ago

Sorry for being so late on this, but here is a folder with the logged files. I have both Android and iOS logs in regards to the same device. I do believe that your assumption of the connection parameters being updated is correct. If we look at packet # 445 of the Android log, you can see a Connection Parameter Update Request which is then accepted. Please let me know what you think!

I also had a question in terms of the "Handle"s of these packets. If we look at any given packet from the Android log, for example, number 355, the info on the right side states "Rcvd Write Response, Handle: 0x000d (Generic Attribute Profile: Unknown)". My question is, what exactly is this "Handle" value, and is there a list of Handles somewhere I can reference?

Oh also, as a quick note, you'll notice that the Android log file is a text file, but it still can be opened with Wireshark to show the log data. Logged Files.zip

mossmann commented 3 years ago

The Attribute Handles are server-specific and must be discovered by the client. They can even change dynamically, requiring rediscovery.

I'm closing this issue as the original concern appears to have been answered: Ubertooth lost the connection because connection parameters changed and the update message was encrypted.