Sniffing and Decoding NRF24L01+ and Bluetooth LE Packets For Under $30 article points to an interesting hack: able to decode NRF24L01+ and Bluetooth Low Energy protocols using RTL-SDR (=a cheap USB digital TV tuner based digital radio). So cheap practicality anyone can obtain the equipment quickly. Some special hacking was needed because there are no RTL-SDR that would tune up to 2.4 GHz where Bluetooth works.
Sniffing and decoding NRF24L01+ and Bluetooth LE packets for under $30 is a long blog post that describes the journey to sniff and decode popular digital wireless protocols off the air for very cheap.The developer sees that this is first time BTLE can be decoded using a very cheap generic device. The description of the project can be found at http://blog.cyberexplorer.me/2014/01/sniffing-and-decoding-nrf24l01-and.html main software repository for this project is at https://github.com/omriiluz/NRF24-BTLE-Decoder. This looks like a really interesting hack to receive Bluetooth signals.
One of the challenges was that you can’t use rtl-sdr directly to receive Bluetooth signal because it is impossible using any version of the rtl-sdr that works up to 2.4 GHz. The highest you can buy reach 2.2Ghz. just shy of the 2.4Ghz we need. The only way to go this up is to convert the signal down to a frequency usable by the rtl-sdr. It was possible with MMDS LNB can be found for a variety of frequencies and LO frequencies, and one suitable cheap was designed to take 2.2-2.4Ghz signal and down convert it to around 400Mhz (where rtl-sdr can receive them). SDR# was used with the new radio setup to see if signals could be found on the right frequencies. It’s a clever kluge for capturing and reading 2.4 GHz traffic with a sub-2.2 GHz receiver.
The developer is sure that this software can be adapted to output the right format as input to the existing Bluetooth decoders such as Wireshark (Bluetooth stack is partially implemented and Wireshark can dissect several of the layers and protocols of the stack). That would be interesting to see. This hack was designed for Bluetooth LE, not any other Bluetooth variation. Please note that Bluetooth LE is a new technology, introduced in the Bluetooth 4.0 spec. It has absolutely nothing to do with bluetooth besides the name. Now that we have that out of the way, why is it cool? Well, it was made for low power, and the design shows. If you are interested more in it check also “Bit-Banging” Bluetooth Low Energy article.
There are also other ways to receive Bluetooth LE. Promiscuity is the nRF24L01+’s Duty blog posting describes a hack to convert a nRF24L01 into a promiscuous listening device. This achieves a very similar goal, but much cheaper.
7 Comments
Tomi Engdahl says:
Are We Not Indestructible? We Are Quiz Buttons!
http://hackaday.com/2014/01/31/are-we-not-indestructible-we-are-quiz-buttons/
Each button has an Arduino Pro mini and an nRF24L01 wireless RF module. On the receiver side is an Arduino Pro micro and an another RF module.
Tomi Engdahl says:
Reading 2.4GHz Transmitters With An Arduino
http://hackaday.com/2014/05/10/reading-2-4ghz-transmitters-with-an-arduino/
Tomi Engdahl says:
Sniffing Proprietary 2.4GHz Signals
http://samy.pl/keysweeper/#sn
While I would normally pull out something like a HackRF or RTL-SDR with digital down converter (to get 2.4GHz into RTL-SDR range), it would be really nice if we could sniff with more inexpensive hardware, as ultimately I want to package everything up into a device that can be left in the field.
how to turn the nRF24L01+ into a 2.4GHz sniffer using his GoodFET device, and a host computer with the goodfet.nrf python application.
Travis found that sniffing with the device is traditionally difficult because not only must you specify the channel (frequency) to listen to, you must specify a MAC address to listen on. The nRF chip will only deliver packets sent to that specific MAC address.
However when specifying the length of the MAC, Travis found there is one option which is considered “illegal” in the datasheet
by setting the MAC to data that would typically be found in the preamble (0x00AA or 0×0055, in binary 0000000010101010 or 0000000001010101), we can fool the device into giving us the packet early, providing a full MAC address to us in the data portion!
Promiscuity is the nRF24L01+’s Duty
http://travisgoodspeed.blogspot.fi/2011/02/promiscuity-is-nrf24l01s-duty.html
http://goodfet.sourceforge.net/
Tomi Engdahl says:
Hacking 2.4GHz Radio Control
http://hackaday.com/2015/09/20/hacking-2-4ghz-radio-control/
Many modern radio control (RC) systems use frequency hopping to prevent interference. Unfortunately, hopping all over the 2.4GHz band can interfere with video or WiFi using the same frequency band. [Befinitiv] was trying to solve this problem when he realized that most of the systems used a TI CC2500 chip and a microcontroller. The microcontroller commands the chip via SPI and controls the frequency by writing into a frequency register.
Updating the microcontroller firmware was impractical. The firmware is encrypted, for one thing. In addition, the change would have to be reinserted on any future updates and repeated for every RC vendor. So [Befinitiv] took a different approach. He did a classic man in the middle attack by inserting an CPLD in between the controller and the CC2500.
Enable 2.4GHz RC systems to work with 2.4GHz video systems
https://befinitiv.wordpress.com/2015/08/26/enable-2-4ghz-rc-systems-to-work-with-2-4ghz-video-systems/
Tomi Engdahl says:
Bluefruit LE Sniffer – Bluetooth Low Energy (BLE 4.0) – nRF51822 – v1.0
Have a peek under the hood of Bluetooth Low Energy devices, sniffing and visualising traffic down to the packet level.
$29.97
http://store.hackaday.com/products/bluefruit-le-sniffer-bluetooth-low-energy-ble-4-0-nrf51822-v1-0
Tomi Engdahl says:
Sniffing Bluetooth Devices With A Raspberry Pi
http://hackaday.com/2016/08/01/sniffing-bluetooth-devices-with-a-raspberry-pi/
[Jeff] of reelyActive stopped by the booth and showed off what his team has been working on. It’s a software platform that turns all your wireless mice, Fitbits, and phones into a smart sensor platform using off the shelf hardware and a connection to the Internet.
[Jeff]’s demo unit (shown above) is simply a Raspberry Pi 3 with WiFi and Bluetooth, and an SD card loaded up with reelyActive’s software. Connect the Pi to the Internet, and you have a smart space that listens for local Bluetooth devices and relays the identity and MAC address of all Bluetooth devices in range up to the Internet.
The ability to set up a hub and detect Bluetooth devices solves the problem Bluetooth beacons solves — identifying when people enter a space, leave a space, and with a little bit of logic where people are located in a space — simply by using what they’re already wearing.
http://context.reelyactive.com/technology.html
http://reelyactive.github.io/make-a-pi-hub.html
http://smartspac.es/
Tomi Engdahl says:
Reverse Engineering A BLE Service To Control A Light Bulb
http://hackaday.com/2017/08/13/reverse-engineering-a-ble-service-to-control-a-light-bulb/
So, you buy an Internet of Things light bulb, it’s a fun toy that allows you to bathe your environment in pretty colours at the touch of an app, but eventually you want more. You start to wonder how you might do more with it, and begin to investigate its inner workings. Then to your horror you discover that far from having bought a device with a convenient API for you to use, it has an impenetrable closed protocol that defies easy access.
This was the problem facing [Ayan Pahwa] when he bought a Syska Smartlight Rainbow LED bulb, and discovered that its Bluetooth Low Energy interface used a closed protocol. But instead of giving up, he proceeded to reverse engineer the communication between bulb and app, and his write-up makes for an interesting read that provides a basic primer on some of BLE’s workings for the uninitiated.
Reverse Engineering IoT Devices
https://iayanpahwa.github.io/Reverse-Engineering-IoT-Devices/
I recently bought a smart LED RGB light bulb for my work desk from Amazon, A 7 watts Syska Smartlight Rainbow LED bulb which can be controlled using a mobile application compatible with Android and Bluetooth. It was fun playing with it, a perfect mood lamp for my study room, blinks to notify of any new whatsApp message on phone, can wake me up in the morning and I can interact with it in so many ways BUT only through it’s native application.
Unlike other famous smart light bulbs available in the market like Philips Hue, LIFX etc, this one works on Bluetooth Low Energy rather than WiFi and unlike them it has no API to interact with it your own custom made application
After playing with it for couple of weeks, I decided to look whats’s under the hood. I’ve been playing around Bluetooth and Bluetooth LOW energy protocol for quite sometimes now and know the nitty gritty functioning of it ( All thanks to Cypress Semiconductor for sending me a PSoC4 BLE evaluation kit last year ).
though the BLE protocol has some already defined profiles such as basic old UART, BLE Heart Rate monitor, Beacons etc, the vendor is free to use what’s called GATT or Generic Attribute and create their own custom profile of how they want communication to happen between master and slave.
The fact that this bulb is not using TCP/IP based protocol for communication makes it little hard to reverse engineer,
From some previous project on BLE I knew about an amazing application by Nordic Semiconductor which runs on Android and ios called nrf connect which can be used to explore GATT services and characteristics exposed by the device. I can use this app to connect to my light bulb, know it’s Unique Address(sort of MAC address), find which GATT services are exposed by the light bulb and their corresponding characteristics, a good starting point isn’t it? I quickly fire up the application on my android device, turn the bluetooth and light bulb on and scan for devices. The device was shown up swiftly with the name ‘Cnligh’
The two out of three GATT Services exposed by the light bulb are generic to most of BLE Devices, the 0×1800 for Generic access to device and 0×1801 for Generic stuffs
Other than these two, there is one more service exposed by the light bulb which is user-defined, I can tell by seeing it’s 128-bit UUID which are meant for vendor defined BLE GATT profiles
Provided I’ve found the service name, UUID I’d be able to try sending some packets and see the results but it was not the case, hence the next step left was only to sniff the packets sent by the BLE app to the bulb.
I heard about a device called Ubertooth One By Great Scott gadgets which makes possible sniffing of Bluetooth packets but seeing at the price tag and local availability, I decided to look for an alternative, there were some other hardwares too from Nordic and Cypress Semiconductor but spending more bucks than price of a light bulb wont make sense isn’t it.
Further Googling, I found on StackOverflow, that with Android KitKat update it is possible to log bluetooth packets in a file
If you’ve android phone with kitkat and above you can enable this feature by going to settings > Developer option > Enable Bluetooth HCI snoop log. This is basicaly a bluetooth debugging tool, after enabling it all the bluetooth transaction will be logged to the file ‘btsnoop_hci’. I enabled the feature, and run the app controlling my light bulb changing different colors as I normally would, and focusing more on basic colors this time like pure red, blue and green which would help me filter data stream while analyzing packets, close the app and wolla! the file was actually generated, a merely 20Kb log file which could open the gates to the bulb without opening the hood
.
Next step was to bring the file on my workstation and try to visualize it using Wireshark which is a great tool for stuff like this
I found it a BLE based chip by Texas Instruments the ‘CC2540’ which the bulb is probably using
Investigating further, there are few types of protocol involved in overall communication as can be seen in wireshark- HCI_E, HCI_C, ATT etc.
That’t the most exciting thing in reverse engineering, you never know ;). The best way to tell this is by controlling it without using the native Syska bulb app.
I decided to use Bluez software stack which is available on Linux and I used my KALI Linux VM machine, because why not? Ain’t we hacking?