Why Rolling-Code Remotes Resist Simple Copying

“Can this remote be copied?” is a common question in RF projects. To answer it properly, separate three things: what changes in the transmission, how the receiver validates it, and whether a previously accepted message can still operate the equipment.

Fixed-code and rolling-code remotes can look identical. The difference is in the message and the receiver’s decision. Recording a signal, replaying a command and providing a dependable replacement remote are different jobs.

Fixed Code Repeats; Learning Enrolls

A fixed code is like a key whose shape stays the same. For a given command, the relevant code remains static. In a system that accepts that code without additional protection, a compatible recording can potentially be replayed. Simplicity and cost may suit some applications, but neither proves resistance to unauthorized use.

Learning describes how a receiver adds a transmitter to its accepted list. It does not define whether the transmitted code is static or changing. A learning receiver can enroll either kind, depending on its design. More identity combinations may reduce accidental overlap, but they do not make a captured static message fresh.

Microchip’s TB003 explains the distinction between guessing a code and capturing one. Increasing the number of possible codes addresses guessing; preventing reuse requires another mechanism. These are separate questions when comparing products.

A receiver needs to know both that the command is authorized and that it is still valid to use.

A Counter Adds Freshness, Not Identity by Itself

In a counter-based rolling-code design, the transmitter advances stored synchronization state for a new activation. Secret-key processing protects changing data; the receiver checks the message against its own credentials and state. A visible counter that simply increments would be predictable. Changing a number is not enough to authenticate a command.

Think of the decision as two checks. Authentication asks whether the message is valid for an enrolled transmitter. Freshness asks whether its synchronization state is acceptable now. Both must pass before the intended control action is allowed. This is a conceptual model, not a universal packet format.

The HCS301 data sheet gives a concrete example: its message combines a hopping portion with a fixed portion, including a serial number. The receiver uses learned information, validates the decrypted data and evaluates synchronization. Not every field changes on every press.

A new button activation should not be confused with each RF frame. An activation can send repeated code words for reception reliability. Seeing repetition within a burst is therefore not, by itself, proof of fixed-code operation.

“Rolling code” is a family of approaches, not a single compatibility standard. Algorithm, provisioning, message format, receiver firmware and synchronization policy can differ. A chip name or a matching frequency does not establish that two products will work together.

Why Receivers Allow Some Forward Movement

A remote can be pressed out of range. Its state advances, while the receiver hears nothing. Requiring the next message to be exactly one step ahead would make this ordinary event unnecessarily disruptive.

A forward acceptance window gives the receiver some tolerance. The figure below uses a fictional last-accepted value of 100 and a four-step window. Values 101 through 104 are candidates for acceptance only if authentication also passes. After accepting 103, the receiver moves its stored state to 103; the acceptance range moves with it.

The HCS301 documentation illustrates a short forward window and a separate resynchronization region requiring an additional sequential transmission. It explicitly describes this as a typical firmware implementation. Follow the actual receiver’s instructions rather than assume the same thresholds or recovery steps for every product.

A wider window does not turn arbitrary transmissions into valid credentials. It does change how much authenticated forward movement the receiver tolerates. Evaluate that tolerance together with resynchronization, state storage and rejection rules. The useful question is how the complete acceptance policy handles both normal missed presses and abnormal input.

Counters also have finite ranges. Overflow, resets and replacement of stored state need defined handling. “Always moves forward” is a useful picture of normal operation, not a claim that a hardware counter can increase forever.

Why a Previously Accepted Code Normally Fails

Consider the same simplified example. The receiver is at 100, accepts an authenticated command at 101 and stores 101. A later replay of that command is no longer ahead of the stored state. With correct rejection and state retention, it does not authorize another operation.

That protection depends on the receiver having accepted the command. A captured message that never reached the receiver has not necessarily been consumed. A one-way counter system may still accept it if it remains inside the allowed range. “Recorded” and “already used” are not interchangeable.

Nor does a counter automatically impose a time limit. Whether an unused message expires after a period depends on additional protocol rules. Rolling-code freshness is usually about sequence state; it should not be advertised as a clock-based expiry without evidence.

A recording also does not give an ordinary copier the credentials and state needed to keep generating valid future commands. A supported replacement may nevertheless be available through the system’s documented provisioning and enrollment process. Resistance to simple copying is not the same as a ban on adding another remote.

The important boundary is not whether someone can observe the radio signal. It is what the receiver will still accept afterward.

Rolling Code Is a Mechanism, Not a Security Certificate

Changing code is an improvement over unrestricted reuse of a static command, but the label alone does not establish the security of an installed system. Review key protection, enrollment permissions, authentication checks, synchronization recovery and retention of the receiver’s last accepted state.

Samy Kamkar’s DEF CON 23 presentation introduced RollJam. At a high level, it combines interference with capture to retain a valid command that the receiver has not yet consumed. That challenges an unused-code boundary; it is not ordinary reuse of a command already accepted by a correctly advancing receiver.

Csikor and colleagues’ RollBack research, presented at Black Hat USA 2022, examined automotive remote keyless entry systems whose recovery behavior could make old captured commands acceptable again. Its findings concern the tested implementations. They do not demonstrate that every rolling-code garage-door or gate receiver has the same defect.

The practical lesson is to examine acceptance and recovery behavior, rather than assume that a changing waveform proves security. These research examples also do not mean a door-unlock command necessarily bypasses a vehicle’s separate start authorization.

Interference can prevent a valid command from arriving. Authentication and availability are different properties: rolling code does not, on its own, make the radio link immune to jamming. Likewise, features such as logging, abnormal-attempt detection or firmware updates must be confirmed for the actual product.

How WindChord Remote Approaches the Choice

For Dongguan Fengxian Electronics Technology Co., Ltd., the useful starting point is the customer’s installed system and required outcome. Cost, replacement compatibility, radio performance and security need to be considered together. No single frequency, encoder marking or product label answers all four.

For an access-control project, establish the receiver and controller model, the supported transmitter family and the authorized enrollment method. Then ask how the system handles a lost remote, missed presses and recovery after loss of power. Choose the documented mechanism that meets the application’s requirements, and verify operation on the actual receiver.

• Identify the installed receiver, firmware or hardware revision, and supported remote references.
• Confirm who may enroll a remote and whether a lost remote can be revoked individually.
• Request the documented synchronization and recovery behavior; avoid applying generic programming instructions.
• Ask what security evidence supports the system’s claims and whether it covers the configuration being purchased.
• Verify replacement compatibility and normal operation in the intended installation before a volume order.

The right answer to “Can it be copied?” is therefore more specific: can a captured static message be reused, can a captured but unaccepted command still work, and can a supported replacement be enrolled? Separating those questions makes the recommendation clearer and reduces avoidable pairing failures.

A good control system opens the intended door for an authorized command and rejects a command that is no longer valid.

Further reading: the manufacturer documents describe particular implementations; the research publications examine particular attack conditions. Neither is a universal programming guide or a security assessment of WindChord Remote products.

Microchip TB003 — An Introduction to KEELOQ Code Hopping.

Microchip HCS301 — encoder operation, message fields and typical receiver synchronization.

RollBack white paper — Csikor and colleagues, Black Hat USA 2022.

Drive It Like You Hacked It — Samy Kamkar, DEF CON 23, 2015.