Reversing a 2.4GHz Remote Control | Hacker News Reader

Reversing a 2.4GHz Remote Control

xakcop.com

159 pointsggerganov28 comments

RTL SDRs are such a great way to get into this (less than $20 on Amazon).

I was shocked to see how easy the garage door opened once I'd captured a packet with the RTL SDR (on 433 Mhz) and then replayed it through the Rasperry Pi bit-banging FM hack with a tiny wire on a pin. I looked at the code and converted it to 0s and 1s, only to find out that it was always the same and also that the middle part matched the 8-bit hard-coded on/off switch every garage tends to have to adjust your coding (so your neighbour doesn't open yours).

I then realised it would only take about 256 attempts to open just about any garage door in my neighbourhood (most are bought from one or two vendors). All it takes is a Raspberry PI, a USB power-bank and a script that runs in a loop.

Amazing. Shocking also. But fascinating.

My garage door opener uses a “rolling code” to prevent these sorts of playback attacks. I would assume they’re pretty commonplace nowadays?

I remember reading a text file back in the early 90s downloaded from a bbs that had plans for a master garage door opener. Seemed like magic.

Vulnerabilities happened in rolling code systems too, see for example https://www.iacr.org/archive/crypto2008/51570204/51570204.pd... (they were able to read manufacturer key and then clone any transmitter just by eavesdropping) or https://www.usenix.org/system/files/conference/usenixsecurit...

> My garage door opener uses a “rolling code” to prevent these sorts of playback attacks. I would assume they’re pretty commonplace nowadays?

Samy Kamkar's Rolljam supposedly does well against those, though the owner's fob quits working, so it's not stealthy.

https://archive.ph/lHHnQ

While rolling code has now been the norm for some time, there are a lot of older garage door openers still in service. More concerning, commercial buildings like apartment complexes often remain vulnerable to these trivial replay attacks because of a "lowest common denominator" effect... they purchase gate controllers, door locks, tokens, etc from different vendors, and the only interoperable protocol may be a very poorly secured one. This is a major problem with door locks where very outdated ProxCard standard remains in wide use due to low price and interoperability.

Yeah, I think it's the fact that many of the garage doors I see around here are easily 15 to 20 years old or more. My brother approached me recently about his apartment complex garage door, as they only give out one remote unit (but they have two cars), so we duplicated the code hoping it's not a rolling code, and he tried it out and it works. So he duplicated the remote without trouble. It's an ESP32 with a battery.

Really enjoyed reading this.

When i first stumbled across https://github.com/jopohl/urh (universal radio hacker) i couldn’t believe my luck.

I’ve done stuff like this manually before (as in just collecting all the bits and then trying to ascribe meaning, e.g. https://github.com/cleanflight/cleanflight/issues/1125#issue... ) but i used URH to reverse my bbq temperature sensors.

I have an alexa skill that shows the last 20 readings for both probes on a graph. It is stupidly over-the-top (a Pi with a cheap sdr dongle listens for packets from the bbq down the garden, it parses out the measurements and fires them into a dynamodb which is absurd but it was quick to do, then the Alexa skill just pulls from there and sends to a chart api that draws my line graphs to show on alex’s screen - totally absurd) but great fun to do.

Decades ago, I did something similar but far cheaper. I hooked up a toy tank's remote to RS232 and started bit-banging through RS232. The bits correspond to the voltage of the RS232 pins, which in turn activates the toy tank's remote's buttons. The toy tank is now completely programmable through the PC.

The OP's toy does not have any state so it is quite easy to reverse engineer. All you need is a simple map from a desired action to electromagnetic signal. I am thinking of reverse engineering the protocol between my customizeable mechanical keyboard and its PC software. As the mechanical keyboard has an internal state, it is much more difficult to reverse engineer.

This is very very cool.

The only problem I have is that the author knows his stuff so well that he falls short of explaining in enough detail.

But maybe that’s an excercise left to the reader.

Maybe they expected a different audience. There is no need to be overly verbose if your audience is knowledgable enough to deal with concise descriptions.

This blog seems to start after the hard part.

A friend of mine was trying something like this recently and couldn't figure out how to isolate the signal from all the noise around him. I was hoping this would explain even a little bit, but unfortunately not.

Really surprising that the communication is two-way, and sends signals with such a high bit rate. I wonder why this would be so? It's not like there's any closed-loop control going on, other than the loop formed by the user's eyes and fingers ;)

I wonder if the comms ICs used in the car and controller were originally designed for some far more complex use case involving bi-directional signalling, or status feedback?

I always wanted to try and reverse engineer the wireless communication of my wife's insulin pump (it can communicate with a glucose meter to show the current glucose level and receive a bolus).

But between me not having the know-how and any hacking being potentially threatening her health, I never got around to do it. But it would be nice to send a bolus, because the newer smartphone app can't do that via bluetooth.

I'm sure you know this, but giving someone a large and unexpected bolus of insulin is a good way to kill them, particularly if they are asleep.

If I were designing an artificial electronic pancreas like that, I would be super, super paranoid. It's probably one of the few medical devices that I really think should be a strong user of asymmetric cryptography with a challenge-response-challenge-response protocol and multiple independent sanity-checking validation steps at every opportunity. If it can't deliver the bolus it thinks you need, it should alarm loudly and tell you to manually check. If it has a bit flip in the night and slowly drives 255 units of insulin into your bloodstream at 3 am, you won't wake up.

I would expect that any modern insulin pump is required to be protected very thoroughly against random malfunctions. Some certification authorities seem to require IEC 61508 (functional safety) as a prerequisite for IEC 60601 (safety of medical equipment). IEC 61508 kind of requires self-monitoring against malfunctions in a reliable way. This includes mechanisms for detecting random bit flips if these can cause potential harm.

You're right that an artificial pancreas needs to be super careful.

The diabetes community got started on this before the official manufacturers did. Probably in part because the manufacturers were concerned about being 100% bulletproof whereas (some) people living with diabetes were willing to take a bit more risk. And there's a balance around alarms. Some glucose monitoring tech can be frustrating and lead to "alarm fatigue".

Most of the artificial pancreases I'm aware of mitigate some of the risk by rarely sending large boluses at all. They tend to adjust the background basal rate and only send a bolus when you explicitly tell them you've eaten.

I suspect you're aware, but there is a significant community effort on communicating with various insulin pumps.

The old Medtronic pumps were hacked years ago and Medtronic responded by making it impossible with newer pumps.

By now there are at least 3 different apps on different platforms and they support a variety of pumps.

I am aware, but my wife has the current model which is sadly incompatible with all community efforts I know of

I also have an unhackable pump, unfortunately. I know there were attempts on the later Medtronic pumps by some pretty smart people so it looks unlikely that they'll ever be able to be controller openly.

My next pump will definitely be one that allows remote control and some sort of looping. Whether that's officially from the manufacturer or not.

No idea of the costs, so forgive me if it's not reasonable, but couldn't you get a second device to experiment with? Perhaps secondhand?

These are generally not available to just buy. You need a prescription, and even if I could buy it myself, the price is in the upper four figures, probably more like five figures if I'd buy all necessary equipment

Really interesting. What sort of hardware would be needed to use this?

I know little about this but I think the device is called HackRF and costs about $350. It can act as a receiver and sender.

If you want to tinker with radio stuff for less money, you could start with a receiver only and try RTL-SDR. RTL-SDR is software-defined radio (=SDR) based on a particular RealTek (=RTL) chip. Suitable devices are as cheap as the right DVB-T USB receiver (check the list in the reddit-wiki for what might work and what might not) but there are more optimized devices for approximately $40 (un)available (because supply chain) - have a look at the rtl-sdr shop for those.

https://www.rtl-sdr.com/

https://www.reddit.com/r/RTLSDR/

Thanks, that's really useful. I had always wondered about the possibility of doing something like this with my children's various RF-controlled toys.