Make a low-cost Bluetooth LE packet sniffer with Wireshark

https://wiki.makerdiary.com/nrf52840-mdk-usb-dongle/guides/ble-sniffer/

by Zelin • 3 years ago

112 33 3 years ago

wiki.makerdiary.com

Zelin• 3 years ago

This is a useful tool for debugging and learning about Bluetooth Low Energy applications.

nixgeek• 3 years ago

All your comments on LinkedIn seem to be shilling for nRF52840?

vardump• 3 years ago

That SoC is pretty nice and relevant for this discussion.

Bouncingsoul12• 3 years ago

No it is not, IMO. These devices are only ever usefull if you have unencrypted connections, with peripherals with static addresses. Add either random addresses or encryption and you won't have any success while debugging. So this tools are not usefull for 99% of peripherals you see around. These cheap tools can only operate on 1 frequency at a time. BLE Advertisments are done one 3 channels (37,38,39), you have to listen to all of them to get the init of the connection. With this cheap devices you have 66% you miss some parts of this and thus fail to follow the connection and encryption on the remaining 36 channel (BLE does dynamic channel hopping, the channel list is exchanged within the connection). Plus with only 1 channel, it will sooner or later fail to follow the connection and this is usually just before you could repro the issue at hand.

Believe me if you want to do anything serious you have to invest some money. Up to BLE 4.2 i would suggest https://fte.com/products/bpalowenergy.aspx which comes around 1000€. There is so no follow up for 5.0 (which more and more devices have now) so I have no suggestion there (unless you want to invest 10.000+++)

kallistisoft2• 3 years ago

Very much depends on what you're trying to do... In my case I wanted to examine the raw traffic between two devices that I had written software for and had full control over. I found it worked just fine as the debug version of the code doesn't implement any of the ble security features. Also had no issues using the dongle to examine ble 5.x traffic.

12311123151232• 3 years ago

Great note, didn't think of this limitation when using the dongle previously.

One question though, doesn't the sender transmit advertisements sequentially on all of the broadcast channels? So at least for BLE advertisements, they should all appear on the advertisement channel you're listening on - even if that's just one of them?

_flux• 3 years ago

Wouldn't MitM attack work, though?

I found this one, doesn't seem to be maintained but the concept seems clear: https://github.com/PaulPauls/Bluetooth_LE_MITM

It doesn't seem to be concerned about encryption, but would that typically be a problem?

hamandcheese2• 3 years ago

I was looking in to BLE sniffing and was very surprised to learn this can't be done with a typical Intel wifi+Bluetooth chip (like an ax201 for example).

Is this a hardware limitation, or a limitation of the Linux Bluetooth stack? Or maybe I'm just wrong?

GuestHNUser• 3 years ago

I had this exact question a while ago. Closest answer I could find was this stackexchange post: https://superuser.com/questions/1708946/why-do-bluetooth-pac...

montecarl• 3 years ago

I an the sole developer of a product that uses bluetooth (classic not BLE) and have struggled so much with bluetooth (documentation and APIs just seem not that helpful or complete or are at such a low level that they aren't useful unless you already know everything), but I will try to give an answer and hopefully if I am wrong someone can educate us.

My understanding is that most bluetooth devices interface with the operating system over a standardized host controller interface (HCI) over a UART or SPI interface. Basically the OS sends some standardized commands to the HCI and receives some data back. This means that the OS doesn't have full control over the radio and are limited in what they can do to a set of standardized commands[1]. For example, even if you monitor everything that OS sends/receives over this HCI channel (using, e.g. btmon on Linux) you will not see everything that is going on.

For example, with bluetooth classic, during inquiry (discovering pairable devices) you don't really see all the details of what the device is doing. The hardware doesn't seem to signal anything about a host devices scanning you and the reply packets that are sent. I was trying to debug some issues with Windows 11 not discovering my device (despite it being in inquiry scan mode and that my phone could see it but not my desktop) and btmon was totally unhelpful in this case and I believe it to be a limitation of how the OS and the bluetooth device communicate at a fundamental level. It turns out the answer to my particular issue was the "class of device" that my device reported wasn't one that Windows 11 will show during pairing.

[1] https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_...

ajb• 3 years ago

Bluetooth is a frequency hopping protocol. Most hardware is provisioned to access one channel at a time. In BLE, even the initial setup can happen over once of three channels. My understanding is that it's difficult for a sniffer to work reliably (including the one in the OP) unless the hardware is provisioned to receive multiple channels. But I'm not an expert in it.

hamandcheese2• 3 years ago

You're probably right, you just reminded me of btlejack, a project for BLE sniffing which can use 3 distinct listeners to reliably sniff setup:

https://github.com/virtualabs/btlejack

dromtrund2• 3 years ago

I wrote some of the firmware for this sniffer. As others mention, Bluetooth Low Energy works on multiple channels, with connections jumping from channel to channel in a predefined pattern. Bluetooth stacks are implemented to act as one of the two parts of a connection, and there are no apis that would let you change this, as it's normally not relevant.

This sniffer is set up to follow the channel jumping, but instead of participating in the packet exchange, it just listens for both parts. As the channel jumps are predetermined, the sniffer can sleep between these events, then start the radio up to listen on the right channel at the right time.

The hardware does not support listening to multiple channels at the same time, so to follow a connection, the sniffer needs to listen to the connection establishment exchange to learn the timing and channel pattern for the connection.

Device discovery and connection establishment runs on three channels, but all beacon packets (advertisements) are sent on all three channels, so the sniffer only needs to listen to one of them.

The connection requests are sent as immediate responses to an advertisement. If we want to be sure we catch all connection requests for a specific device, we can choose to "follow" its advertisements, which are sent on each of the three channels in sequence.

The sniffer is implemented by interacting directly with the radio hardware peripheral, which acts just like a state machine with states RX, TX, idle, and a few warmup states.

kallistisoft2• 3 years ago

Recently setup this up using the same board (nrf52840 usb dongle), it was a fun and cheap ($10 on mouser.com) mini-project. Learned a bunch about the ble protocol in the process :)

12311123151232• 3 years ago

Just for people who got the non-makerdiary version of the nrf 52840 USB Dongle (note the "MDK" in the article's dongle name):

For the non-MDK dongle, the reset button is a side-oriented button next to the big white button (almost looks like an LED). Took me a while.

jvm___• 3 years ago

There was a missing runner in Iowa who was eventually found in a corn field. I always wondered if some sort of Bluetooth sniffer could have found her smart watch if they'd canvassed the roads she was supposed to be on. Her body was 50-60ft off the road.

minimalist• 3 years ago

Maybe someone can help me understand this. I've always shied away from smartwatches because the tracking potential. We have always known how the MAC address of wireless clients can be used to track a device and decades later, MAC randomization is being offered on major operating systems.

Why don't I hear about that as much with bluetooth devices? Surely they suffer from the same problem? If not, how do devices remember each other?

andoma• 3 years ago

Not an expert in the field, but I have some knowledge. Bluetooth specifies different address types [1] where one of the types are Resolvable Random Private Address. This is used to avoid tracking. TLDR: The address is periodically randomized (typically every 15 min). Part of the address is a hash that lets you identify the device if you previously have bonded with the device (so you have its Identity Resolving Key)

[1] https://novelbits.io/bluetooth-address-privacy-ble/

abwizz4• 3 years ago

bt is flaky enough as it is ;)

but yea, fwiw bt mac addresses are NOT randomized on google and apple platforms and serve as a constant identification provider for anyone that cares (e.g. retailers).

wifi macs are randomized for a few years now (settings toggle in hostapd.conf)

ChrisMarshallNY4• 3 years ago

Apple randomizes BT, as well[0].

[0] https://support.apple.com/guide/security/bluetooth-security-....

jmole• 3 years ago

BT addresses are not randomized because it would break all existing BT headphones and the pairing process.

Both Apple and Google, as far as I know, will randomize MAC for BLE on Android and iOS when possible. Ditto for Wifi MAC, but it’s usually only randomized on a per-AP basis.

But that doesn’t prevent tracking via BLE accessories (e.g. heart rate monitors, older smart watches, etc.) which may periodically broadcast with the same MAC address indefinitely.

smackeyacky• 3 years ago

You can also do this with the Ti cc2540, comes with bluetooth sniffing firmware. You need a command line program in Linux to get the output to wireshark, but i find grabbing traffic and analysing afterwards more useful tham real time analysis anyway.

ChrisMarshallNY4• 3 years ago

I’ve used the Hollong sniffer[0]. Works well.

But BLE is a fairly secure protocol. There’s only a limited set of data that can be determined, without connecting to devices.

I wrote a few apps that act as sniffers[1] for Apple devices (including the Watch). Source available [2-3]. I haven’t really done much with the apps in a couple of years.

[0] https://www.aliexpress.us/item/3256804238048102.html?gateway...

[1] https://itunes.apple.com/us/developer/rift-valley-software-i...

[2] https://github.com/RiftValleySoftware/BlueVanClef

[3] https://github.com/RiftValleySoftware/RVS_BlueThoth

tomsonj• 3 years ago

The ubertooth one is a great, low-cost, open tool as well

https://ubertooth.readthedocs.io/en/latest/ubertooth_one.htm...

heffer• 3 years ago

As an application developer I not always have a need to observe protocol traffic as it happens on the air.

So for reverse engineering BLE protocols (especially between IoT devices and their apps) I've usually found my Android phone with developer mode and Bluetooth HCI snoop logging enabled to be very convenient. Wireshark can read the files my phone spits out and because I see the unencrypted packets when captured directly off the HCI it's very easy to work with.

WirelessGigabit• 3 years ago

This is perfect. Just what I needed!

Make a low-cost Bluetooth LE packet sniffer with Wireshark

Related Stories