Replay Attacks on RF Remotes
Many RF remotes, for garage doors, gates, alarms, and cheap consumer gear, send the same code every time you press the button. Capture that transmission once and you can replay it forever, operating the device without the remote. Here is how replay attacks work, how to test for them, and how rolling codes are supposed to stop them.
The Fixed-Code Problem
The simplest RF remotes encode the button press as a fixed sequence of bits and transmit it on a set frequency, often in the 315 or 433 MHz bands; the receiver listens for that exact code and acts when it hears it. Because the code never changes from press to press, anyone who records one transmission holds a perfect copy of the credential, with no challenge, no counter, and no timestamp to stop them. That design choice, made for simplicity and cost, is the entire vulnerability, and it is still common in deployed hardware.
Capture and Replay
The attack has two steps, capture and replay, and neither requires understanding the code’s meaning. The attacker records the remote’s transmission once, while it is sent legitimately:
# capture: record the RF burst when the remote is pressed
rtl_433 -f 433.92M -A # analyze/decode common remotes
hackrf_transfer -r capture.iq -f 433920000 -s 2000000 # raw IQ capture Tools like rtl_433 decode many common remotes directly, and a raw IQ capture records the signal even when the encoding is unknown. Replay is then just transmitting the recording back on the same frequency:
# replay: transmit the captured signal back on the same frequency
hackrf_transfer -t capture.iq -f 433920000 -s 2000000 -x 40 That single command operates the target if it uses a fixed code. The barrier to entry is a sub-hundred-dollar radio and public tools, which is why fixed-code remotes are considered broken for anything that matters.
Testing a Remote for Replay
To assess a remote, capture a press and replay it; if the device responds, it is vulnerable. Then capture several presses and compare them: if every press sends identical bits, the code is fixed; if the transmissions differ in a structured way, the device may use a rolling code, which calls for deeper analysis. The test is quick and definitive, and a device that operates on a replayed capture has no meaningful protection against anyone who can record one transmission.
The Ladder of Protection
RF control sits on a short ladder of protection, and knowing which rung a device is on tells you both how it fails and what it needs:
| Scheme | Resists capture-and-replay? | Weakness to watch |
|---|---|---|
| Fixed code | No | Capture once, replay forever |
| Rolling code | Yes | Shared key, loose counter window, jam-and-replay |
| Bidirectional challenge-response | Yes, and jam-and-replay too | Needs a two-way radio and more complexity |
Each rung trades cost and complexity for resistance. Fixed codes are the cheapest and the most broken; rolling codes defeat the basic replay but depend on their implementation; a bidirectional authenticated scheme closes the remaining gaps at the price of a two-way radio.
Rolling Codes and the Jam-and-Replay Trick
Rolling codes make every transmission different yet verifiable: the remote and receiver share a secret and a synchronized counter, each press sends a code derived from both, and the receiver accepts a code whose counter is ahead of what it last saw, within a window, so a replayed old code fails. KeeLoq is the classic example. But they are only as good as their implementation, a shared manufacturer key across all units, a too-wide counter window, or a weak cipher each undoes the scheme.
There is also an attack specific to rolling codes, jam-and-replay: the attacker jams the receiver so the user’s press is captured but never accepted, then captures a second press, lets it through, and keeps the first still-valid code to replay later. It works because the first code’s counter was never consumed. The defenses are tight timing windows, jam detection, and challenge-response, which shows that moving from fixed to rolling codes closes the easy attack but opens a subtler one that still needs designing against.
Identifying the Frequency
Before capturing anything you need the frequency and how the data is modulated, and a spectrum view finds both quickly. Sweeping the common ISM bands while pressing the remote shows energy spike at the operating frequency, and the shape of the burst hints at the modulation.
# watch the 433 MHz band while pressing the remote to find the carrier rtl_power -f 430M:435M:1k -i 1 spectrum.csv # or a live waterfall in a GUI tool to see the burst and its timing
strong narrow peak at 433.92 MHz when the button is pressed short bursts, amplitude-keyed -> OOK/ASK, typical of low-cost remotes
Confirming OOK at 433.92 MHz tells you exactly how to record and replay it, and that the encoding is almost certainly a simple on-off pattern rather than anything cryptographic. That five-minute reconnaissance step is what makes the capture-and-replay that follows reliable.
Why It Persists, and What to Do
Fixed-code and weak rolling-code remotes keep shipping because the radio chips are cheap, the firmware is simple, and the systems work perfectly in the absence of an attacker. A product passes its functional tests, the gate opens every time the button is pressed, and nobody on the team presses the button with an SDR recording. That gap between functional testing and adversarial testing is exactly where these vulnerabilities live.
If your product uses RF control, the test is simple and the stakes are clear: capture a press, replay it, and see if it works. A fixed-code system fails immediately and should be considered unprotected; a rolling-code system needs deeper review of its key management and counter handling; and an attacker-valuable device deserves a bidirectional authenticated scheme. The cost of getting this wrong is that anyone with a cheap radio can operate a gate, a lock, or an alarm, which is a serious physical-security failure, not just a digital one.
Where This Fits
Testing RF remotes and wireless control for replay and related attacks, and advising on rolling-code or challenge-response designs, is part of the wireless assessment in a product security review. If you want your RF control tested the way an attacker with an SDR would, that is the kind of work we do at Berkner Tech.
