Make a low-cost Bluetooth LE packet sniffer with Wireshark | Hacker News Reader

Make a low-cost Bluetooth LE packet sniffer with Wireshark

wiki.makerdiary.com

112 pointsZelin33 comments

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.

This is perfect. Just what I needed!

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.

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?

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_...

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.

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.

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

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...

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

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.

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

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+++)

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.

Yes thats true, but even if I have access to the device firmware, which I usually do, so I can build an unecrpyted version and this usually leads to the problem not being reproducible or showing differently... Anyway I want to reproduce the problem as close to production fw as possible. So via our time/effort calculation, spending some money on a multichannel sniffer was surely worth it.

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?

This is true, but the connection request only comes on one channel. The sniffer can be set up to follow an advertiser though, which makes it jump to the next channel in the sequence as soon as the time window for sending a connection request after the advertisment is gone. It picks up connection requests virtually every time in this mode.

Both this and encrypted communication interpretation works a lot better than the commenter above you claims. They've either not tried this sniffer, and are only making claims based on assumptions, or they haven't learned how to use it properly.

It's definitely not as good as commercial sniffer hardware, but it's perfectly fine 90% of the time, and the price is two to three orders of magnitude lower.

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?

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

That SoC is pretty nice and relevant for this discussion.

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 :)

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.

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?

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/

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)

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.

blood sugar monitors are rather popular as well

Apple randomizes BT, as well[0].

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

my take from this document is that it is enabled for the low-energy variant but not the normal bt (with more reach).

care to verify?

my 1st-gen se with ios 15.whatever does NOT randomize the mac address in normal bt probes

That is correct.

But all my [modern] Apple devices randomize (except my old SE, which is my low-end test). It can be a pain to track, with my software.

BLE is probably where all of Bluetooth is going, eventually.

The main issue, now, is data speed, but even classic is pretty slow, compared to other standards. I believe they are incorporating high data-rate stuff into BLE, so you can have things like pure BLE headphones.

so, there are cases where btle does randomize the mac address, but not when using 'normal' bluetooth things

BLE is "ad hoc," with ephemeral, one-time connections, while Classic establishes long-lasting, "commitments."

BLE is like a Gig.

Classic is more like a Career.

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

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

Reply on news.ycombinator.com