本帖最后由 我说要有光 于 2014-3-7 03:43 编辑

[color=rgb(51, 51, 51)][backcolor=rgb(254, 253, 250)][font=Arial, Tahoma, Helvetica, FreeSans, sans-serif]In this long post I am going to describe my journey to sniff and decode popular digital wireless protocols off the air for very cheap. So cheap practicality anyone can obtain the equipment quickly.

I was able to decode NRF24L01+ and Bluetooth Low Energy protocols using RTL-SDR.
As far as I can see, this is the first time the NRF24L01+ is being decoded, especially considering the low entry price for the hardware. Given the extreme popularity of this transceiver, we are likely to see a wave of hackers attacking the security of many wireless gadgets, and they are likely to succeed as security is usually the last priority for hardware designers of such cheap gadgets.

A lot of work have been done to decode bluetooth using dedicated hardware and I am sure this software can be adapted to output the right format as input to the existing Bluetooth decoders such as Wireshark.
As far as I can see, this is also the first time BTLE can be decoded using a very cheap generic device.

The main software repository for this project is at XXXXXXXXXXXXXXXXXX/omriiluz/NRF24-BTLE-Decoder

Developing a wireless mesh network challengesRecently I've been working on a project to create a super cheap (<$5) sensor node that can be flexible and power efficient so I can just leave sensors everywhere and need absolutely no maintenance.
I decided to use the extremely popular NRF24L01+ transceiver from Nordics Semiconductor due to a balance of performance, power and price - and you'll be surprised how many hardware designers have taken the exact same decision once you start sniffing the air for packets. In my home alone I can see 15 addresses - wireless keyboards and mouse, remote controls, toys and appliances all use this tiny transceiver for wireless communication.

The sensor node with NRF24L01+

While working on the mesh network code, my progress slowed to nearly a halt. The code is extremely complex and depends on external conditions like signal strength, noise, etc. But worst of all? I was completely blind on what really happens once packets leave the safety of my micro controller using SPI to the transceiver. For normal (i.e. non-wireless) projects I'm used to being able to connect my scope or logic analyzer and "see" what happens on the wire. This makes debugging a breeze. Unfortunately this is not the case for wireless projects and I had absolutely no idea what happens between the transceivers. To make things worse, these transceivers work in the ISM band of 2.4Ghz. this is fast. much faster than any equipment I have available.



Enter Software Defined Radio (SDR) [float=right][/float]I assume you all know about the magic of SDR and specifically the cheap RTL-SDR. If not, take a break and head to XXXXXXXXXXXXXXXXXXXXXX/trac/wiki/rtl-sdr to read about it. For $13-18 (Amazon 1,Amazon 2) you open a world of possibilities that stretches far beyond analog radio into the 2.4Ghz digital space, as you'll read on this post.

Back to the problem of debugging - having experience with rtl-sdr, I immediately started thinking how can I use it to sniff packets off the air. This is impossible using any version of the rtl-sdr as the highest you can buy reach 2.2Ghz. just shy of the 2.4Ghz we need.

I started looking for a way to convert the signal down to a frequency usable by the rtl-sdr. Building one was a possibility, but I had no idea how and all the commercial/DIY products costs hundreds of dollars.

China to the rescueAnother option was to try and find an existing, mass produced and cheap product with my required specification. A quick search on XXXXXXXXXXXXXX found exactly that  - MMDSLNB.
MMDS is a digital broadcast system used in some countries for digital TV, and the LNB is part of the antenna. The MMDS LNB can be found for a variety of frequencies and LO frequencies.

Complete setup

The base frequency defines the filters on the device and the LO frequency defines by how much will it reduce the input frequency.

Based on the specification, it would do EXACTLY what we need - take 2.2-2.4Ghz signal and down convert it to around 400Mhz. Then we can use the rtl-sdr and some code to decode packets off the air.

As it was very cheap ($12+shipping at Aliexpress) I took the chances and ordered one. About 10 days later it popped in my mail. I quickly hooked everything up and to my extreme surprise, after minutes -

Success!I used SDR# with the new radio setup to see if I can find signals where I expect them to. The easiest one to find was my Logitech wireless mouse (which uses nrf of course). Tuning to 2,405Mhz (or 407Mhz after down conversion using LO of 1998Mhz) clearly show a strong signal when I move my mouse.




Developing the software to decode the packets was a bit of a headache, but once it started shaping up it was very easy to use it to capture and decode the packets.

So what do you need to make it work?

• RTL-SDR dongle - ~$15. Easiest to buy on Amazon - (Amazon 1, Amazon 2), but you can find it everywhere. I have both an E4000 and R820T dongles and they both work perfectly.
  
• MMDS down converter - $12+shipping at Aliexpress. Buy one for 2.2-2.4Ghz with L.O. of 1998Mhz. If you buy from the link here, the hideer will ask you for these details after you purchase.
  
• (optional) Cables - Different rtl-sdr sticks have different input plug, you need to find a way to connect it to your down converter. This is really optional as I simply hacked some wire and it worked fine.
  
• (optional) Power Injector - the down converter is an active component and requires 14-24V. I started by simply connecting my power supply to the wire and it worked fine. later I purchased a commercial power injector for less than $10. you can find one at Amazonor from the same Aliexpress hideer.
  

Back to the comfort of softwareFrom now one, all we need in order to get the packets is some clever software and the comfort of our computer (whether it's windows, linux, mac or RPi).

The NRF24L01+ (nrf from now on) uses GFSKmodulation for the data. FSK (and it's derivatives like GFSK) is the digital cousin of FM. the modulator takes a bit stream, and emits one frequency to represent "1" and another frequency to represent "0".
Luckily for us, there is already a great library that does the basic rtl-sdr work and includes a software FM demodulator, rtl_fm.

Using the rtl_fm code on the incoming stream, I exported to excel a raw demodulated feed and filtered to find interesting results -




This is without a doubt an nrf packet. You can see:

• Noise before (<80) and after (>395) the packet
  
• Radio turn on time (85 to 125)
  
• Preamble sequence of alternating bits (01010101 here) for the demodulator to detect a packet start and sync clocks (125 to 160)
  
• Packet data (160 to 395)
  

In my code, I detect the preamble and calculate a Threshold number - anything above that number is considered a binary "1" and anything below is a "0". This provides a bit stream which represent the packet.
My code takes this bit stream, and manipulate it to recover the packet.
The last step is to take the packet, apply CRC and compare to the CRC in the last two bytes to verify that this is a valid packet. if the CRC match, we print a decoded packet.

For a detailed description of how I turn this bitstream into a decoded packet, I suggest you open my code over at XXXXXXXXXXXXXXXXXX/omriiluz/NRF24-BTLE-Decoder, it is documented and should be relatively simple to understand.

Getting rtl_fm to output the right signalOnce you install the librtlsdr and have it working with your dongle, the basic command line for rtl_fm to product the bitstream we need as input is:
rtl_fm -f 402m -s 2000k -g 0 -p 239

The parameters are:

• -f - frequency. remember to take the nrf channel frequency and reduce your down converter LO frequency. in the case here it's 2400-1998=402.
  
• -s 2000k - mandatory. my code expects a 2M samples per seconds stream
  
• -g 0 - to avoid noise, it's important to disable the auto gain control and reduce the gain as much as possible. I use 0 when everything is on my table and 10-15 when it's in my house.
  
• -p defines the rtl-sdr permanent frequency drift. As a cheap device, the rtl-sdr is not calibrated. it's easy to calibrate it out of cellular signals using kalibrate-sdr
  

Sniffing NRF24L01+ packetsOnce rtl_fm works, simply pipe the output into my software to see packets decoded -
rtl_fm -f 402m -s 2000k -g 0 -p 239 | nrf24-btle-decoder -d 1

2 simple parameters:

• -t nrf | btle - should we decode nrf or bluetooth LE packets (more on this later)
  
• -d 1 | 2 | 8 - select packet speed - the nrf can do 2mbps, 1mbps or 256kbps. you need to pick the right one.
  

Having my sensor node send one byte of data (an increment counter) with an acknowledgment from another node, the output would look like:

Sniffing 2Mbps NRF24L01+ traffic on channel 0 (2,400Mhz)

And now I'm not blind anymore when debugging!

Taking it further
As one smart blogger explained, the physical radio of the NRF24L01+ and Bluetooth Low Energy (btle from now one) are quite similar. This allowed me to quickly adapt my code to sniff btle packets as well.

Sniffing Bluetooth Low Energy advertisement channel 38 (2,426Mhz)

The code for sniffing btle is complete for the advertisement channels, but not for the data channels, it would be my next step to add it. The main issue is frequency hopping as required by btle, which I'm not sure our lowly rtl-sdr can do fast enough.






[/size][/font][/color]
[color=rgb(51, 51, 51)][backcolor=rgb(254, 253, 250)][font=Arial, Tahoma, Helvetica, FreeSans, sans-serif]Posted by Cyber Explorerat 2:04 AM
[/size][/font][/color]