4 ms·

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 th

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 3y 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-packet-sniffing-tutorials-for-windows-require-an-adapter https://superuser.com/questions/1708946/why-do-bluetooth-pac...
montecarl 3y 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_sdk/1.60.00.29_new/exports/docs/ble5stack/vendor_specific_guide/BLE_Vendor_Specific_HCI_Guide/hci_interface.html https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_...
ajb 3y 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.
- hamandcheese 3y 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 https://github.com/virtualabs/btlejack
dromtrund 3y 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.

GuestHNUser 3y 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-packet-sniffing-tutorials-for-windows-require-an-adapter https://superuser.com/questions/1708946/why-do-bluetooth-pac...

montecarl 3y 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_sdk/1.60.00.29_new/exports/docs/ble5stack/vendor_specific_guide/BLE_Vendor_Specific_HCI_Guide/hci_interface.html https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_...

ajb 3y 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.

hamandcheese 3y 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 https://github.com/virtualabs/btlejack

dromtrund 3y 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.