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. Nothing about the transmission changes from press to press, which is convenient to build and trivial to abuse.
Because the code is constant, anyone who records one transmission holds a perfect copy of the credential. There is no challenge, no counter, no timestamp, just a static code that the receiver accepts whenever it arrives. That design choice, made for simplicity and cost, is the entire vulnerability, and it is still common in deployed hardware.
How a Replay Attack Works
The attack has two steps: capture and replay. The attacker records the remote’s transmission once, while it is sent legitimately, then re-transmits the identical signal later to trigger the receiver. With cheap software-defined radio, both steps are straightforward and require no understanding of the code’s meaning.
# 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 captureTools like rtl_433 decode many common remotes directly, and a raw IQ capture with an SDR records the signal even when the encoding is unknown. The attacker does not need to know what the bits mean, only to record them faithfully, which is why a fixed-code system falls without any reverse engineering at all.
Replaying the Capture
Replay is just transmitting the recorded signal back. A raw IQ capture is re-sent with the same SDR, and a decoded code is re-encoded and transmitted. Either way the receiver hears what it considers a valid press and acts, opening the gate or disarming the alarm as if the real remote had been used.
# replay: transmit the captured signal back on the same frequency
hackrf_transfer -t capture.iq -f 433920000 -s 2000000 -x 40That 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 device for this is as simple as capturing a press and replaying it to see if it works.
Testing a Remote for Replay
To assess a remote, capture a press and replay it; if the device responds to the replay, 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 a different analysis.
This test is quick and definitive, and it is a standard step when assessing any RF-controlled product. A device that operates on a replayed capture has no meaningful protection against anyone who can record one transmission, and that finding usually drives a recommendation to move to a rolling-code or challenge-response scheme.
Rolling Codes
The fix for replay is to make every transmission different yet verifiable, which is what rolling codes do. The remote and receiver share a secret and a synchronized counter. Each press sends a code derived from the secret and the current counter value, so a captured code is valid only once, and a replay of an old code is rejected because its counter has already passed.
KeeLoq is the classic example, and similar schemes are widespread in automotive and garage-door remotes. The receiver accepts a code whose counter is ahead of what it last saw, within a window, and advances its own counter, so legitimate presses keep working while replayed old codes fail. Done right, rolling codes defeat the basic capture-and-replay attack entirely.
Where Rolling Codes Go Wrong
Rolling codes are only as good as their implementation, and several classic mistakes weaken them. A shared manufacturer key across all units means extracting it from one remote breaks the scheme for the whole product line. A counter window that is too wide, or that resyncs too easily, can be abused. And the underlying cipher must be sound.
There are also attacks specific to rolling codes, like jam-and-replay, where the attacker jams the receiver so it never hears a press, captures the unused valid code, and replays it later. These show that rolling codes raise the bar substantially but are not automatically immune, and that the implementation details, key management and counter handling, decide how strong the protection really is.
The Jam-and-Replay Variant
Jam-and-replay deserves its own note because it defeats naive rolling-code systems. The attacker jams the frequency while recording, so the user’s first press never reaches the receiver but is captured. The user presses again; the attacker captures the second code and lets it through by stopping the jam, while holding the first, still-unused code to replay later.
This works because the captured first code was never accepted by the receiver, so its counter value is still valid. Defenses include tight timing windows, detecting jamming, and challenge-response schemes where the receiver injects randomness the attacker cannot predict. The variant illustrates that moving from fixed to rolling codes closes the easy attack but opens a more sophisticated one that still needs designing against.
Beyond Rolling Codes
The strongest RF designs move past one-way rolling codes to bidirectional, authenticated, encrypted protocols, where the receiver issues a challenge and the remote proves knowledge of a secret without sending anything replayable. This eliminates both basic replay and jam-and-replay, at the cost of a two-way radio and more complexity in the remote.
For high-value targets, vehicles, access control, payments, that complexity is justified, and modern systems increasingly use it. For low-cost consumer gear it is often skipped, which is why fixed and weak rolling-code systems persist. The right choice follows from what operating the device without authorization actually costs, which is the threat-model question behind every RF design.
What This Means for a Product
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 the device, which for a gate, a lock, or an alarm is a serious physical-security failure, not just a digital one. Choosing the protection level deliberately, against the real consequence of unauthorized operation, is what separates a remote that resists attack from one that broadcasts a reusable key with every press.
Identifying the Frequency and Modulation
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, usually simple on-off keying on cheap remotes.
# 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 This Persists in Shipped Products
Fixed-code and weak rolling-code remotes keep shipping because the radio chips that implement them 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. A thirty-second replay test, run once during development, would catch a fixed-code system immediately, which is why testing RF control the way an attacker would belongs in the process for any product where unauthorized operation actually matters.
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.