You are currently browsing the category archive for the ‘Linux’ category.

A few days ago I read about NCC Group’s Sniffle tool, a BLE sniffer for Bluetooth 4.X and 5. Given my interest and previous track record at looking into the security of BLE devices, I could not stop myself from testing it.

The tool is available on NCC Group’s Github, along with quite good documentation. It was not hard to install all the prerequisites and set up everything following their documentation. My environment is pretty well set up for this type of experimentation and devices, so from Python to PySerial, I did not have to do much. All the TI-specific tools should be installed in their default folders suggested upon install (when running the .run files) and one will not have any major issues.

So far, I have been able to run the sniffer on the TI CC26x2R Launchpad Board. The firmware loads without issue and the board is ready to use. Note that, as I will describe below, I have been having a bit of stability/buggyness issues with the sniffer. Whenever something acts up a bit, the best thing to do is to reload the firmware. That seems to get things fixed for me most of the times.


Once the firmware is loaded, it is easy to start running captures. Given the simplicity of the radio it’s running on, the sniffer can only scan one channel at a time, so you are either scanning ADV channels (37, 38 and 39) or following a connection. Therefore, unless you happen to catch an actual connection establishment, you should expect to only see ADV-related messages on your first captures.


Once you are all set up, it is highly recommended to dump the traffic being captured to a pcap file using sniffle’s -o option. Looking at one of the captures I took, I see the expected advertising traffic. A whole bunch of Apple devices (in my experience, always very “loud” at sending ADV-related traffic) from my neighbors, some smart TVs (including mine; it’s been the subject of my research before and I know like the back of my hand the characteristics of its ADV packets) and some interesting devices that I will explore when I have more time.


Now that I am all set up, I will start taking actual captures of devices connecting and will test how reliable Sniffle’s ability to follow connections is. By the way, once you capture a full initial pairing and connection establishment, you should be able to process the pcap with Crackle to bruteforce the LTK session key and decrypt traffic. This is possible unless the pairing is being done with the Out of Band method. In my experience, the only device that I have observed in the wild using OOB pairing is the Apple Watch, though.

While using Sniffle I have noticed some instability. Every now and then I get weird errors raised by sniffle when having trouble parsing certain packets. See example above for a crash when it parses a packet that, allegedly, has an incorrect length field. I have observed similar parsing errors happening from time to time. When this happens, sniffle seems to get stuck when you try running it again. The quickest fix is to reload the firmware.


Once I have some time I will continue playing with sniffle. With two kids now, time is a very scarce resource! 🙂

EDIT (10/04/2019): Correction to myself. Bluetooth 5 *should* be using Diffie-Hellman for the handshake to derive STK which encrypts the handshake to exchange LTK. If that is the case, even when sniffing a full initial pairing+connection, one could not be able to brute force anything. I have to find myself a Bluetooth 5 device and capture that traffic. I’ll update when I have some time.

I was setting up today my new Windows7 laptop. And, as every single Windows laptop I’ve had before, I set up a Linux VM on it. Although on my other laptop I run a paid VMWare Workstation Pro license, in this particular license I am running the free VMWare Workstation 14 Player.

I currently have two VMs set-up, a custom Ubuntu one that I use mostly for development and tests and a Kali-Linux one. If you are interested in radio security, you must install the kali-linux-sdr and kali-linux-wireless packages. Such a convenient way to get all your favorite tools nicely installed on your machine.

By the way, when setting up the Kali image, for some reason, the apt sources were not properly configured and I could not apt-get install kali-linux-sdr and kali-linux-wireless. A quick update of /etc/apt/sources.list fixed the issue. You can get the url to the various package repositories here (note: several of the ones listed do not actually work).

Anyhow, once all my sdr and radio tools are ready to run, I got to the main issue at hand. It is quite well known that running USB devices from within a VM is prone to errors and rather imperfect. Things seem to work fine when, upon plugging my USRP B210, it would be recognized by the driver and connected to the VM.

Running uhd_usrp_probe appeared to work well, as it loaded the firmware onto the USRP, but then it just couldn’t locate the device anymore. For some reason the VM gets lost in translation as, once the firmware is loaded, the USB device essentially changes and the VM loses it. And it took me quite some time to get it to work. I was close to leaving it for another day until I found a solution that worked well on both the Kali and Ubuntu images. Instead of running uhd_usrp_probe or any other application that probes and uses the USRP, the trick is to run first the b2xx_fx3_utils tool. Its path might be different depending on how you installed UHD, but in the Kali image it is in /usr/lib/uhd/utils. After running this tool the firmware is updated on the USRP and, from that moment on, everything works just fine. You will need to do this trick each time that you unplug the USRP and plug it again, as the firmware will need to be updated again.

When I thought I was done, I am actually facing a new challenge. Installing OpenLTE on Kali doesn’t work as cmake cannot find the UHD libraries. Most likely a permissions or weird installation path on Kali for UHD. But this is one that I’ll procrastinate in fixing as I switched to doing all my development and experimentation for my LTE exploits security research with srsLTE.

Ever since becoming a father I’ve had very little time for research, but I have some new LTE protocol exploits in the kitchen being cooked. Once I have enough time to put together results and a talk, you’ll see me on the road to talk about it. I’m aiming for Spring time.

Happy new year everyone!

EDIT: A lot of people has been asking me about this. What this fixes is the USRP itself being used from within a VM. This does not fix the ancient issue of VMWare with USB3 drivers. If you need to run something with the USRP that requires USB3 (e.g. an LTE base station at full 10MHz and ~30Msps), that will be VERY hard to do from within a VM. You are much better off by creating a partition to run native Linux on your laptop for that.

If anyone ever manages to get the USRP over USB3 working from within a VM, please please please let me know!

I had in mind another post for today, but the circumstances made me change my mind.

This morning, my 4 months old Lenovo IdeaPad U350 crashed. It was not a hardware problem – Lenovo still makes some of the best laptops out there – but a software problem. A problem with Windows 7, to be precise.

I was very happy with Windows 7 lately and I was convinced they had finally done something that works very well for the first time since Windows 3.1 – with Windows XP they got something that worked decently well as well -. But I was just being fooled by a flawless functionality for the last 4 months and some fancy commercials on TV. I will still be a Windows user, but Windows will always be Windows. And that means unreliability and a constant likelihood of you computer crashing, no matter how new or old it is.

The problem was odd. I logged in my user and everything looked wrong and I couldn’t see any of my files. Rebooted and, from then on, every time I would try to log into my computer, it would pop up a message saying that it was unable to bring up my user data. And that’s it. It wouldn’t log in. The computer was useless. Eventually I got one of the feared blue screens.

I find simply stupid that, a Windows 7 system, when the only user can’t log in because of an OS problem, it does not give you the choice to log in to fix the problem or to create another user.

Anyhow, lucky me I am and will always be a geek. Each time I have had a computer crashing – yes, you guessed right, always happened with Windows platforms – I fixed it myself and recovered all my data – no matter how badly it crashed – thanks to Knoppix.

Knoppix is a simple Linux based OS that boots from the CD unit. It has a very simple to use graphic interface, very similar to Windows. If an external hard drive – or other USB devices – are plugged in, it mounts them and allows you to use them. Therefore, one can save all the data in the computer’s hard drive to an external unit and then safely reinstall Windows.

I always thought of reinstalling Windows like ordering animal style fries at In’n’Out. You get them and they mess up your stomach. But the next time you go to In’n’Out you order them again.

Download here an ISO for a Knoppix CD and make sure you always have it with you.

About me:

Born in Barcelona, moved to Los Angeles at age 24, ended in NYC, where I enjoy life, tweet about music and work as a geek in security for wireless networks.
All the opinions expressed in this blog are my own and are not related to my employer.
About me:

Blog Stats

  • 144,595 hits

Twitter feed

Enter your email address to follow this blog and receive notifications of new posts by email.