This guide shows how to install/setup Ubertooth one, a 2.4 GHz wireless development platform device, and its plugins. This tutorial will detail on how to sniff Bluetooth Low Energy packets and how to crack the encryption of a BLE connection.
Please note that all the information provided is only tested on Ubuntu 20.04 TLS. For other operating systems, you may need to make some changes. Ubertooth one documentation can be found here.
the Bluetooth baseband library (libbtbb) needs to be built for the Ubertooth tools to decode Bluetooth packets:
Ubertooth contains host code for sniffing Bluetooth packets, configuring the Ubertooth and updating firmware. All three are built and installed by default using the following method:
Plug the Ubertooth one using a USB port. Go to the directory that you have installed Ubertooth, and update the firmware by:
You should see something like:
The device will automatically enter DFU mode and flash the firmware. For troubleshooting and more information, visit here.
Make sure your Ubertooth One is plugged in and execute:
You should see a continuous output that looks like:
You should see various random LAPs detected. In the output ch represents the channel used by the device referenced in the LAP value. The channel hopping is clearly comprehensible. Clkn indicates the master’s clock, while s references the signal strength and n state the value of noise. Following that the snr value represents the signal-to-noise ratio.
Due to uncertainties in identifying Bluetooth packets without prior knowledge of an address, it is normal for this process to identify false positives. Error correction should mitigate this problem, but a small number of false positives may still be seen. When you see the same LAP detected more than once, that is very likely an actual Bluetooth transmission. Once you have seen a LAP multiple times, you can be confident that it is a genuine Bluetooth piconet. To find the next byte of the address, the UAP, we can use:
In this mode ubertooth-rx only detects packets from the given piconet and uses them to determine the next byte of the address and some of the internal clock value.
you can also see the ubertooth spectrum analysis with:
you should see something like this:
Once a BLE connection is established (on the advertising channel the device has been listening to), Ubertooth will follow the hops along the data channels capturing the transmissions between the devices. Per default, Ubertooth can be used to follow any connection it observes randomly. Naturally, the device can be restricted to observe a specific device by providing the BD_ADDR of the device in question. The general syntax of the corresponding command looks like:
for my Sumup device, the command looks like this:
This will produce a continuous output in the console:
Furthermore, it is possible to redirect the output into a file or a pipe. To achieve this, the syntax requires this generic command:
Which is as following for the Sumup device output in a pipe:
or .pcap file:
you can generate .pcap output as well.
Users of Wireshark version 2.2+ do not need to build any plugins at all and may skip this section. I did not need this section, but if you do, find the relevant steps here.
Make a pipe as follows:
Pipe is a buffer for inter-process communication. One process can send data to it, and another process can read it.
In the Wireshark, Open Capture Options => Manage Interface => Pipes => New Pipe => add “/tmp/pipe” => save => close => start
In a terminal, run ubertooth-btle:
You should see packets in the Wireshark. More details can be found here.
Kismet-Ubertooth identifies not only the LAP but also the 8 bit Upper Address Part (UAP) of detected devices as it is able. This is done by analysing the timing and other characteristics of multiple packets over time.
first uninstall any kismet version you have by:
I highly recommend to clone it from the git as the downloaded .tar.xf versions can not build (It is a common issue. It turns out that sometimes the website version is not updated and can make trouble).
You can accelerate the process by adding -j #, depending on how many CPUs you have. To automatically compile on all the available cores:
If you encounter errors about missing header files (foo.h not found for example), try removing all .d files and running make again:
Then continue by:
Finally, you need to add the pcapng log type to the configurations. The log config file is in a different place in the new version. In /usr/local/etc: you can see a kismet.conf file that contains all the configurations. If you open this file, you can see that the logging configuration is set to be in the kismet_logging.conf. if you nano it, you can add any logging file you want to the kismet logging system. The default one is .kismet that cannot be opened via Wireshark. So, we need to add a log type understood by Wireshark, pcapng:
In the log_prefix you can also set the path where you want your logs to be stored. You probably want to remove the kismet log type from the above since we do not use it.
To start the Kismet web server, run:
Then, open http://localhost:2501/ to set it up. You need to set a username and password for your login.
To add the Ubertooth device to the Kismet, run:
If you look into your terminal, you can see that a log file has been generated. If you open the Kismet web server on http://localhost:2501/, you should be able to select Ubertooth in the datasource in the devices.
Note: In the Ubertooth One tutorials, it was mentioned to install the kismet plugin for Ubertooth. But as I looked into the latest versions, it seems like it is supported by default. But for any reason if you think you should still do this step, either watch this video or follow these steps. I followed the video and still cannot $make && make install in the /ubertooth-2020-12-R1/host/kismet/plugin-ubertooth. But still, I get the .pcapng log file that can be used later.
Crackle is a tool that attempts to decrypt BLE Encryption. Crackle is the right tool if you have captured a connection based on BLE Legacy Pairing. It cannot decrypt LE Secure Connections based transmissions. The capture must include the pairing process otherwise it's not going to work. Capturing a pairing process is difficult, so you have to keep trying!
Now that you have your output log file either by BTLE or Kismet (.pcap or .pcapng), you can use the latest version of the tool by executing this command: