Shmoocon 2017: A Simple Tool For Reverse Engineering RF

Anyone can hack a radio, but that doesn’t mean it’s easy: there’s a lot of mechanics that go into formatting a signal before you can decode the ones and zeros.

At his Shmoocon talk, [Paul Clark] introduced a great new tool for RF Reverse Engineering. It’s called WaveConverter, and it is possibly the single most interesting tool we’ve seen in radio in a long time.

If you wanted to hack an RF system — read the data from a tire pressure monitor, a car’s key fob, a garage door opener, or a signal from a home security system’s sensor — you’ll be doing the same thing for each attack. The first is to capture the signal, probably with a software defined radio. Take this data into GNU Radio, and you’ll have to figure out the modulation, the framing, the encoding, extract the data, and finally figure out what the ones and zeros mean. Only that last part, figuring out what the ones and zeros actually do, is the real hack. Everything before that is just a highly advanced form of data entry and manipulation.

[Paul]’s WaveConverter is the tool built for this data manipulation. Take WaveConverter, input an IQ file of the relevant radio sample you’d like to reverse engineer, and you have all the tools to turn a radio signal into ones and zeros at your disposal. Everything from determining the preamble of a signal, figuring out the encoding, to determining CRC checksums is right there.

All of this is great for reverse engineering a single radio protocol, but it gets even better. Once you’re able to decode a signal in WaveConverter, it’s set up to decode every other signal from that device. You can save your settings, too, which means this might be the beginnings of an open source library of protocol analyzers. If someone on the Internet has already decoded the signals from the keyfob of a 1995 Ford Taurus, they could share those settings to allow you to decode the same keyfob. This is the very beginnings of something very, very cool.

The Github repo for WaveConverter includes a few sample IQ files, and you can try it out for yourself right now. [Paul] admits there are a few problems with the app, but most of those are UI changes he has in mind. If you know your way around programming GUIs, [Paul] would appreciate your input.

23 thoughts on “Shmoocon 2017: A Simple Tool For Reverse Engineering RF

      1. guess who’s setting up a VM tonight LOLz, I’ll see if I can get it working on my debian testing machine and post back here if it works, I just prefer debian over Ubuntu these days thanks for the heads up!!!

    1. Debian testing x86_64 here. No problems installing its dependencies or running the program. Still need to understand how to visualize the waveforms though as none of the examples provided show anything resembling a modulating signal. But having other things to do I’ve tried it just for a while. Might well be my fault.

  1. very interesting, but how is this better than GNU radio ?
    quickly going over the manual, it seems to be very limited. for instance only OOK and FSK demodulation schemes are available ..

  2. ” figuring out what the ones and zeros actually do, is the real hack. Everything before that is just a highly advanced form of data entry and manipulation”

    Spoken like a true software snob with ZERO hardware background. I find the comment insulting and denigrating to the RF engineers who design the magic that goes into transmitting and receiving those 1’s and 0’s.

      1. I don’t think B.B. meant it like that. RF design is an extremely challenging discipline, but we’re in an affordable SDR world now and these generic tools turn hacking most RF devices into a software problem.

    1. This is a reword of a comment from the presentation given at Shmoocon by the author of this tool [who has a mixed-signal hardware development background]. The comment was not to say that RF was easy, but that demodulating it was a pretty well known process. This is opposed to R.E. of the bits which does not currently have a well defined process.

  3. These SDR “Reverse-Engineering” stacks typically FAIL when you get down and dirty – beyond determining even basic modulation types and rates (e.g., Cyclo-Stationary Analysis). Then you are left to try and figure out what is happening to the data from interleaving through error-correction. That’s where it almost always fails. Even with a non-hopping simple TDMA signal (xPSK/xQAM), unless you are a DoD/NSA attacker with budgets running into the $Billions, you’re never going to get past figuring out chained interleave/FEC specifics! And this is assuming the data is NOT encrypted in the first place (security through obscurity works). Let’s say the system designer is Lazy (or driven by available silicon), simply adding rolling-randomized interleaving to avert burst errors to common-known Convolutional-Viterbi FEC (much less TPC/LPC) obfuscates your transmission enough to prevent even sophisticated reverse-engineering. The lesson is: Just having an SDR and what you think amounts to “Powerful Analytical Software Tools”, doesn’t mean a damn thing in the end – even without non-encrypted plain-text to work from.

  4. Pile of garbage too specific to do anything useful, but hey, it gets you a slot at Shmoocon. Kids always think that they can automate everything, and then keep automating for 2-3 examples they already solved and then they call it a win. Son, develop tools to help the human to process the data and analyze it, don’t expect to develop a working solution that demodulates anything useful. Furthermore, Jesus Christ, the GUI development stuff is not something for the engineers like you, it is full of bugs. Instead of thinking about “automating” the whole process, think about how to display the data, what can help to find the right modulation/timings. It is faster to demod a FSK/OOK by hand than relying on this crap, and by the way inspectrum is another crap that, as usually started over and over again doing his own thing. Instead of reusing gnuradio (sources, sinks, math and graphics widgets libs for example) they use liquid dsp and re-developed a lot of things just because they are stupid enough to not learn to use gnuradio. For “offline” processing, they could have developed a simple set of blocks to move the samples back and forth and then you could have had all the power of gnuradio.
    At some point kids, you should stop spending energy re-inventing the wheel, your wheels suck, get used to it. Grab what the big boys already developed and start from there, I beg you all kids to stop thinking you are Human Machine Interface (HMI) gurus, DSP engineers, cryptographers and whatnot. Furthermore, the conference organizers should start to think twice before they accept a talk because seriously, since a couple of years anyone can present any crap. They play with something during 2 weeks, following tutorials (what a challenge…) and they think they can present anything interesting about the subject. Keep the useless tools/presentation for yer mums. Love.

  5. Thanks so much for the tech support & encouragement for thousands of hacker criminals out there, such as the culprit(s) who hit me and all my neighbors last night, who are looking for new & easy ways to break into cars and steal whatever they want. I really hope my sarcasm isn’t too subtle here.

  6. I do like WaveConverter, it provides easy access to decoded data for well know coding schemes. I would very much like to see additional coding schemes coming available, like Differential Manchester (or called Biphase Mark Code). I use WaveConverter (and SDR in general) to build home automation systems into existing situations.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.