RF reverse engineering has become trivial — thanks to the ‘Opensource SDR’ movement

Nihal Pasham
7 min readOct 10, 2018

--

Reversing RF

Thought I’d test this as it’s been on my mind for very long. How easy is ‘Radio frequency’ reverse engineering? To answer this question — I picked a new project and here’s an almost comical observation.

‘Emission Security’ is (surprisingly) easier when you move from ‘theory of operation’ to ‘hands-on tinkering’.

My goal — Pick a random wireless device and see if you can go from ‘wireless signals to meaningful bits’. I’ve always assumed that this was going to require some amount of time and effort, if you don’t know your way around hardware. But honestly, I went from — don’t know where to start to complete signal capture, recording , analysis, demodulation, decode and finally meaningful packets of information in under 2 hours.

I believe this is totally attributable to the Opensource SDR movement that’s given us a bunch of different tools to simplify signals analysis. Over the last couple of years, there has been a ton of activity in this space.

  • From cheap wireless dongles, originally intended to be used as USB-TV (820T2) tuner cards being re-purposed as low cost SDR solutions
  • To fully software controlled radios/transceivers (yardstick one) that you can interact with via a language like python.

Not to mention, pretty much most opensource signals analysis platforms like GnuRadio, rfcat come with built-in drivers to support these low cost SDR/SCR devices.

In my case, I took a slightly different direction, leveraged a tool called ‘Inspectrum’ to analyze my random wireless device — ‘a car keyfob’. It’s worth noting that of the 2hours, I spent an hour trying to set-up inspectrum on windows 10 via the WSL subsystem. (used Mobaxterm as my XServer and Ubuntu from the windows store)

If you’re thinking why windows?? … signals analysis in a VM just didn’t seem to perform well for me and dual or live booting Linux on MS Surface product is not a smart idea!

So with that out of our way, here’s my flow

Reconnaissance: First up — pry open your keyfob to get its FCC ID. Every radio transmitter/receiver usually has one (yes even devices made for the India market). Mine’s KR5V2X. Here’s a picture of what that looks like.

The transmitter’s FCC ID printed on the keyfob

Looked up the ID at fccid.io. The documentation among other things (there’s a wealth of information here) tells me that my keyfob uses 2 distinct channels 433.66Mhz & 434.18Mhz as its frequency of operation. That’s good, it means my keyfob is more reliable, as it transmits on multiple channels. So we have the frequency of operation. Next up — capture and record.

Capture & Record: Fired up GNU radio and captured multiple clicks from my keyfob for each button on the remote — trunk, lock, unlock.

GnuRadio capture flowgraph (also includes playback and demodulate flowgraphs)

Hardware used was the cheap 820T2 TV tuner dongle.

USB 820T2 DVB-T + FM dongle with an cheap antenna

Here’s a snapshot of one of the recordings

Fosphor FFT view of a recording — Single press of a lock button

Analyze: Pulled my recording into inspectrum. Inspectrum allows you to analyze recorded raw IQ signals and offers a really good visual interface. This is perhaps the most intuitive tool I’ve come across in my analysis.

Not to say that GnuRadio isn’t a great option but there are some things that could take you down a rabbit hole in GR. If you’re a noob and you TRY to do some clock recovery (i.e. extracting bits/symbols from a signal) in GR, you’d quickly realize that you’re looking at rainbows and unicorns. Although documentation exists, it assumes the reader already has a ‘working knowledge’ of what clock recovery is and how it’s usually implemented in software. Having spent a few mins attempting to make sense of it, I honestly think what’s missing is a simple yet authoritative introduction to the basics of clock recovery and its 2 types (closed or open loop) for radio dummies.

Coming back to the task at hand. Looking at our GnuRadio snapshot, we could say that the modulation used is FSK (you see 2 peaks in the FFT). However, just to be sure we can leverage inspectrum which offers a much more intuitive method to confirm this. First, we’ll need to clean-up the signal.

Raw signal as seen in inspectrum (2 pulses at 433.66mhz and 2 at 434.18mhz)

To do this — you can play with the power and zoom sliders till you get a nice red square wave. The top and bottom segments are the 2 frequencies in our 2-FSK modulated square wave. Great next up — demodulation

Cleaned up signal

Demodulate: Having figured out the type of modulation, we can simply select the waveform, right click and add a frequency plot which gives you the demodulated signal. This is so much more easier as you can clearly see the bits in the waveform.

FSK demodulated signal

What’s better — you could right click your frequency plot and add a threshold plot to get the traditional bitview.

Traditional bitview

And it doesn’t stop there, you can output the sequence of bits to a standard bash terminal or just copy them for further processing.

Extracted symbols or bits

We now have our bits but none of it seems to make any sense i.e. the raw bits don’t contain an ID for say each of the different button clicks and we cant tell where the transmitted code to unlock/lock begins/ends.

Decode: When you’re faced with such a problem, it makes sense to check whether the data is encoded. There are many forms of encoding but in our case, its likely that it is Manchester encoded. Again this is where inspectrum shines. We could just look at the square wave to determine whether ME is in use. And sure enough as required for manchester encoding, we see each segment includes either a high-to-low transition or a low-to-high transition, but never high-to-high or low-to-low. The actual decoding is done with this tool I found online — http://eleif.net/manchester.html

Manchester encoding applied

Informational packets: Upon decoding your data, the next step is to look for information. Converting each transmission into its hex form, we see a picture start to emerge. A few fields (bytes) change depending on either the channel in use or the button being pressed or the type of remote in use and some don’t change no matter what. I’ve color coded the fields based on these changes. And you can see that my keyfob uses 4 byte rolling codes (instead of static codes that can be intercepted and replayed) along with a counter that’s incremented for every button-click.

Hex encoded representation of our bits

That’s it, we went from a random wireless signal that we had no knowledge of to informational bits. So, gone are the days where you needed expensive radio HW/SW and especially with a tool like inspectrum, the process has become trivial. Also, we’ve established that when designing any kind of radio equipment, just assume all RF emissions are already known. The security of a device should depend on real protections/controls like robust authentication, standardized crypto and NOT obscure packet formats i.e. no security through obscurity please!

Some caveats:

  • Inspectrum analyses recorded/captured signals and doesn’t do real time signals analysis.
  • Although this example shows us how trivial the process is, it could get a bit laborious when working with more complex signals like Wi-Fi, Bluetooth, SigFox, Lora but that’s just signal complexity.

**Oh and If you’re wondering — my preliminary assessment leads me to believe that the cipher in use (for the rolling codes) maybe HiTag2 (a proprietary cipher developed by NXP for this purpose — which is no longer secure). I’ll need to do some testing to confirm this.

--

--

Nihal Pasham
Nihal Pasham

Written by Nihal Pasham

Product Security | IoT Edge & Cloud Security | Security Strategist | Adversarial Resilience & Neural Networks

Responses (4)