Reverse engineering RF signals


How “easy” it is

I was hesitating on how to name this, but let’s get to the end of it, shall we?

A couple of years ago I got really annoyed from the fact that once every 3-4 months I would have to replace the batteries from the remote control of my garage door, every now and then I would misplace the remote or simply forget it at home, or even clumsier – leave it inside my car and going to my wife asking her to temporally borrow her remote so that I can literally unlock mine.

But I always carry my mobile phone with me. Being an electrical engineer, I thought to myself: there has to be a way to “poke” those RF signals coming out of the remote (or the keyfob as they are called?) and reverse the damn thing so that I can use my phone to unlock the garage door. Or at least have a backup!

That’s how I got into Software Defined Radio or SDR for short, GNU Radio, SDR#, the HackRF board and the RTL-SDR USB dongle device. Initially, I found this article on the Internet:

H4ck33D – hacking a 433MHz Remote Control

The article originates from July 2014, but the page seems to be removed since!? You can still have a look at it though, using Google’s cached version.

Nevertheless, I bought the simplest recommended hardware – which to me at the time was the RTL-SDR USB dongle. And that was it! For 2+ years, it stayed tucked away. I haven’t even plugged it in!?

Fast forward 2+ years, and I read this article on Linkedin:

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

I realized I have probably started too many micro projects so that in reality none of them gets done completely. But that’s another topic altogether. To make the story short (read ‘shorter’), I plugged my RTL-SDR dongle into my Linux Mint box, and followed these instructions:

RTL-SDR for Linux Quick-Start Guide

Fired up gqrx and tuned to my favorite FM station just to dip my toes:


Then I somehow ended up on Youtube looking for more in-depth tutorials on the topic, and someone (can’t remember the channel though! Sorry.) suggested there’s a dedicated Linux distribution targeting ham radio enthusiasts and the SDR open-source community.

Welcome to Skywave Linux (the version I ended up installing was the last at the time i.e. 3.1.1).

It’s a live distro, also offering the possibility to install it locally – which I did – but on a virtual machine – which is something I seem to be doing lately. I tend to keep my Linux Mint box ‘clean’ and run dedicated virtual machines. Please check Skywave Linux if you are a beginner SDR enthusiast like me. Trust me – it will save you ‘some’ time.

Now, moving on…

Once inside Skywave, I used the terminal and checked if all is good with my SDR device:


Next, I installed every package it seemed to me was missing in the distro but was to my preference (e.g. Audacity being one), and I went on opening my keyfob to look for my device’s (FCC) ID and realizing there’s absolutely nothing of the sort inside – no indication of an ID or a serial number!?


OK, I was guessing the emitting frequency was around 433MHz (which seems to be the frequency most devices in the ‘keyfob’ category operate in?) so to confirm that, I fired up gqrx (this time from inside Skywave), and… Yes, it was somewhere in that range but the FFT spectrum analysis indicated something strange – different from all the tutorials I’ve looked at.

At this point, I opened the keyfob (again!) and looked at the small IC on the PCB. Using my mobile phone’s camera, I managed to identify it as a HCS301. Whoopsie Daisy! A KEELOQ code hopping encoder from Microchip! This definitely complicated things for me, wishing to do a ‘first-time’ attempt at RF reverse engineering (which in the mean time I found out was quite possible, but it would be the theme for a future article).


So I went on to plan B – I had a remote control that operated 3 AC outlets – and this was using a much ‘simpler protocol’:


GNU Radio is awesome! Inspectrum is brilliant on its own, but coupled with DSpectrumGUI (a wrapper around Inspectrum) – it’s simply amazing! I went on by installing DSpectrumGUI following DSpectrumGUI’s Linux installation wiki.

There are some caveats mind you:

In the section Installing RVM & Ruby 2.2.8, I had to replace the original ‘source’ command with the following:

source /home/vdjepovski/.rvm/bin/rvm-shell

I guess the guys have made some updates to the RVM build process. Also, putting it at the end of my .bashrc file seemed to be causing my terminal to go idle!? After executing the bundle command in the Installing DSpectrumGUI (this app) section, I really had to try installing the nokogiri gem first by executing:

gem install nokogiri -v ‘’ –source ‘’

and then re-execute the bundle command. I should also probably mention, that I did this exercise on my Mint box prior, and in doing so, I ran into a problem while attempting to launch DSpectrumGUI, the error being: missing a valid JavaScript runtime!? I found somewhere on the Internet, that often installing nodejs helps – and on my Mint box that is what I did!

Anyhow, going further…

I had to record some raw data for each of the buttons. You have plenty of options here: you may use GNU Radio Companion here, draw your flowchart, compile it, run it (probably the most powerful method of all – if you know exactly what you are doing. I didn’t!) but I went with the osmocom_fft tool with a centering frequency of 433.92MHz. The tool is basically made with GNU Radio, it’s perfect for novices and it records raw data in the ‘cfile’ format – supported by Inspectrum.


So I made 6 recordings – one for each of the buttons.

On with DSpectrumGUI/Inspectrum.


A ‘device’ inside DSpectrumGUI is essentially a category – a collection of devices sharing the same (more or less) electrical characteristics, whereas units are devices with distinctive physical and/or functional properties (e.g. one remote for the lights in the bedroom, another – possibly of different color – for the lights in the living room). I have only one such device/unit for which I needed to add each of the captures and extract the symbols from the RF stream using Inspectrum.

Loading up the captures individually, revealed that for each button press there’s a stream of ‘bits’ that is being transmitted (such as the one on the picture bellow) – exactly 5 times (!?). Also, the width of each individual pulse was around 250μs, and the pause between the pulses slightly varying or inconsistent (?) – making it extremely difficult to position the cursors exactly around each individual pulse!



At this point I was a bit confused. It’s a form of OOK (On Off Keying) but which one? Hence, I decided to pause for a while and figure things out before continuing onto the next five remaining captures.

OK. Mean while, I resorted to a different method of capturing the pulses. I resorted to GNU Radio Companion and following some explanations I found on the Internet, I composed the following flow diagram:


Pretty simple right? The RTL-SDR USB dongle is my source, tuned at a center frequency of 433.92MHz with a bandwidth of 2MHz and a sample rate of around 250ksps (kilo samples per second). My output or my sink (three of them actually), was a GUI representation of my capture, a raw file (I could later use with Inspectrum) and a wav file (hopefully representing the pulse train).

The contents of the wav file edited in Audacity:


Great! I was hoping to get something close to what I got with DSpectrumGUI/Inspectrum and I believe I did. I also confirmed it’s a repeating pulse train and at this point I was content – because I could just capture each bit sequence for each of the buttons on the remote and just do a replay attack – but this time based on the contents of the wav file as it proved to be more straightforward. Plus, at that stage I placed more trust into GNU Radio Companion than in my own analytical skills using DSpectrumGUI/Inspectrum!

But I wanted to know more.

Kudos to the Hak5 team (Hacking Keyless Entry Remotes – Hak5 1911). I cloned the latest snapshot of rtl_433 from Github and installed it using the provided instructions. I wasn’t hoping for much but I was going to try it anyhow.

And what do you know!? I got exactly what I needed:


Pulse Position Modulation is the name! Some references to check out: Pulse-position modulation, Difference Between PAM, PWM and PPM and Pulse Position Modulation and Differential PPM.

Proove/Nexa was the RF protocol in use (Home Automation – RF Protocols – A Tech Blog)! Now go back to the Audacity screenshot I dare you 🙂 and apply the suggested bit format. Makes sense right!? And yeah – (according to the article at least) the bit pulse width (one period!) should be 250μs! But maybe I’ll revisit this with an oscilloscope with a memory function.

At this point I was truly content! In a future article I will spit out the steps I am eventually going to take (or took!) to build the HW and replay what I captured using everything I have learned so far.

What did I accomplish? I got my feet wet in RF and everything GNU Radio has to offer and I am now ready to revisit my garage keyfob.

Was it easy? I wouldn’t say ‘easy’ but ‘easy enough’ for those who actually know what they are doing (and I don’t consider myself falling under that category. Not yet! :)). But lets be fair and conclude it gets complicated – fast – when moving forward into more complex projects.

Did I really reverse-engineer anything? No, I don’t dare say that. That triumph goes to all the people involved in building all of the SDR hardware and supporting software. And for that guys and gals… You rock and I humbly salute you!