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

Capturing Bluetooth Classic #433

Closed tccl9438 closed 3 years ago

tccl9438 commented 3 years ago

Steps to reproduce

I followed the steps according to the guide to update the firmware. https://github.com/greatscottgadgets/ubertooth/wiki/Firmware I tried to start the sniffing with the ubertooth-rx command that aims to capture Bluetooth Classic. The command used to do so is _ubertooth-rx -z -r test_sendfile_phone_tolaptop.pcapng

Expected behaviour

I thought that it will decrypted when I open the .pcapng file in Wireshark.

Actual behaviour

I can capture the packets but they appear in Wireshark as type NULL. x-special/nautilus-clipboard copy file:///home/eec/test_sendfile_phone_to_laptop.pcapng I attached the .pcapng file that I got.

Version information

Operating system: Kali Linux GNU Linux Rolling Version 2020.1

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

**libbtbb version: libbtbb 1.0 (2018-12-R1).

**Ubertooth firmware version (ubertooth-util -v): ubertooth 2018-12-R1

If you are reporting a problem that involves third party software (Wireshark/Kismet/etc), please report the version here. Wireshark 3.2.8

I am looking to capture Bluetooth Classic packets. The best case scenario is to be able to use Wireshark directly. If not, the above mentioned ubertooth-rx would be an alternative.

mikeryan commented 3 years ago

This is is the expected behavior when running ubertooth-rx -z. This tool only logs very short inquiry packets that it can observe on the general inquiry channels. Currently Ubertooth only has very limited support for capturing classic Bluetooth.

You can look into the new btbr host code and firmware. I have never used it, but it looks like it might do what you're trying to do.

tccl9438 commented 3 years ago

Hi mikeryan,

So do you mean that the Ubertooth One is more for BLE sniffing?

I have some additional queries also. It is regarding the sniffed packets. So far the commands that I got is ADV_IND, CONNECT_REQ, Empty PDU, Pairing Request and Response, Pairing Confirm, Pairing Random, LL_ENC_REQ and RSP, LL_START_ENC_REQ and RSP, Encryption Information and LL_TERMINATE_IND. These are all under the LE LL Protocol.

May I know am I missing any other commands that should be present? These packets are captured between an Android smartphone and a Laptop. I was also trying to capture the transfer of a .txt file but it somehow does not get included in the packet.

Thanks in advance.

Regards, Terence

mikeryan commented 3 years ago

Ubertooth is most capable as a BLE sniffer, yes. With regards to whether those packets are complete, I would check with https://github.com/mikeryan/crackle.

If you just want to log Bluetooth data from your Android phone, you might not even need to use an Ubertooth. See crackle's FAQ on logging Bluetooth: https://github.com/mikeryan/crackle/blob/master/FAQ.md#can-i-log-data-without-having-to-sniff

tccl9438 commented 3 years ago

Hi mikeryan,

Thanks for the prompt reply.

I am trying to look for tools to perform the sniffing of Bluetooth protocol and Ubertooth is one of them in the wishlist.

I tried using the crackle but it produced the above mentioned errors when I use ubertooth-rx, so I suppose that I should be using the ubertooth-btle?

In addition, may I know what is the meaning of a LL_TERMINATION_IND with an error code of Remote User Terminated Connection? Is it because of me switching the Bluetooth of the device off?

Regards, Terence

mikeryan commented 3 years ago

Truly wireless sniffing of Bluetooth classic is more or less limited to the realm of $20,000+ tools like those from Ellisys and Frontline. ubertooth-btle is reasonably capable for BLE (and yes is required for using crackle), and btbr firmware is similarly capable for BR, but both have significant limitations. I suggest evaluating whether it's really necessary for you to actually sniff Bluetooth for your application.

LL_TERMINATE_IND with remote user terminated means the device that sent that wants to end the connection. It's likely that it was sent when you turned off Bluetooth.

Yamakaky commented 3 years ago

Hijacking this thread since my question is linked

@tccl9438 did you find a solution to this problem?

@mikeryan is this the same if I have access to the secret pairing key LTK? I'm working on Nintendo Switch/Joycon communication which uses bluetooth. I only need to read the data exchanged, no modification. https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/blob/master/spi_flash_notes.md#x2000-pairing-info

mikeryan commented 3 years ago

@Yamakaky it may be possible to capture and decrypt the data with the LTK, but as far as I know no tools exist to do that. If you are able to capture a connection with the btbr firmware and share the PCAP and LTK, I'd be willing to take a look but I can't promise any results on any sort of timeline.