Replay and forge a sub-GHz burst

Mechanism

Going active on a sub-GHz device means transmitting on its frequency to take over its function, and the single fact that decides the attack — established at the IG step — is the code type: fixed vs. rolling [rollingcode].

A fixed-code device (a PT2262/EV1527/HT12-class OOK encoder, or a sensor) sends the same payload in the clear on every press, so there is no confidentiality to break and no counter to advance — a verbatim replay of any captured burst makes the receiver act on it [rollingcode]. Universal Radio Hacker re-transmits exactly what it captured (and can edit the bits, fix a checksum, or fuzz a field before sending) [urh]. Where the keyspace is small (8–12 DIP-switch bits) you need not even capture first: OpenSesame transmits a De Bruijn sequence that packs every possible code into a minimal overlapping bitstream — because a shift-register receiver also tests every shorter substring as the bits stream past — cutting a 12-bit brute force from minutes to about 8 seconds against fixed-code garages and gates [opensesame][opensesame-repo].

A rolling-code device (KeeLoq / HCS301 and similar) sends a fresh value each press from a counter, so a naive replay of an old code is rejected [rollingcode]. This is replay resistance, not an encrypted channel you decrypt from a capture — and it is defeated without breaking the cipher. RollJam jams the receiver while recording the victim’s first press (so the device never acts on it and the code stays unused), lets the user press again and captures that too, forwards the first code to operate the device now, and keeps the second, still-valid code to operate it later [rolljam-sdr][rolljam-rtlsdr]. RollBack removes the jamming entirely: replaying a short run of previously captured consecutive codes triggers a resynchronisation in many receivers, rolling the counter back to a prior state so already-used codes become valid again — captured once, reusable indefinitely [rollback]. The RollBack research reports roughly 70% of tested Asian-market RKE systems vulnerable, and NVD records it against certain Honda (through 2018, five consecutive signals) [cve-2022-37305] and certain Nissan, Kia and Hyundai (through 2017, two consecutive signals) [cve-2022-37418]; the authors additionally tested Mazda among the vulnerable makes and found Toyota not susceptible.

To truly forge the next valid rolling code offline you would need the manufacturer key programmed into the chip, which a passive RF capture never yields; recovering it requires physical side-channel access (differential power analysis), which is out of scope for this RF toolchain [keeloq-dpa].

RollJam is Samy Kamkar’s DEF CON 23 (2015) work; it is cited here via a peer-reviewed SDR re-implementation [rolljam-sdr] and a contemporaneous technical report [rolljam-rtlsdr], both of which independently describe the jam-record-replay primitive. The RollBack CVE ids above are the NVD-confirmed entries (an earlier web result that mapped RollBack to CVE-2022-37428 was wrong — that entry is an unrelated PowerDNS Recursor denial-of-service). Per-vehicle/per-device susceptibility figures are representative — check current advisories.

Procedure

Authorised testing only. Transmit solely on equipment you own or are explicitly authorised to test, in an RF-shielded or controlled environment. Even unlicensed ISM bands carry power and duty-cycle limits — do not jam or transmit on live third-party devices.

1. Confirm the layer-1 settings and code type carried over from capture (RFSAM-RES-15): exact carrier (315 / 433.92 / 868 / 915 MHz), OOK/ASK vs (G)FSK, baud, and fixed vs rolling. With a YARD Stick One:

   rfcat
   >>> d.setFreq(433920000)
   >>> d.setMdmModulation(MOD_ASK_OOK)
   >>> d.setMdmDRate(2400)          # baud recovered at the capture step
   >>> d.lowball()
   >>> print(d.RFrecv()[0].encode('hex'))

   You should see the same burst bytes each press for a fixed code, and a value that changes each press for a rolling code. The changing value is the go/no-go for steps 3–4.

2. Fixed code — verbatim replay. Re-send the captured burst and watch the device act. From URH’s GUI use the Generator → Send tab on the recorded signal; from rfcat:

   >>> d.setModeTX()
   >>> d.RFxmit("7eXXXX...".decode('hex'))   # the exact captured payload

   Expected: the gate opens / the receiver registers the command. A Flipper Zero replays a saved fixed-code signal standalone (it refuses to save or replay rolling codes by design).

3. Fixed code, small keyspace — De Bruijn brute force. Where capture is impractical and the code is short, run OpenSesame’s De Bruijn approach on a CC1111/CC1101 radio:

   # build/flash per samyk/opensesame; transmits every 8–12-bit code as one
   # overlapping sequence on the target ISM frequency

   Expected: the receiver opens within seconds rather than exhausting every code one by one [opensesame]. Authorised targets only.

4. Rolling code — jam-and-capture (RollJam). With one radio jamming the receiver’s channel and a second recording the fob:

   • Jam the receiver and capture the victim’s first press (the device does not act).
   • Keep jamming, let the user press again, capture the second code.
   • Stop jamming and transmit the first captured code — the receiver, never having advanced its counter, accepts it and operates.
   • The second code remains unused and valid for a later replay [rolljam-sdr][rolljam-rtlsdr]. Expected: the device operates on your replay of the first code, and the held second code still operates it afterwards.

5. Rolling code — resynchronisation (RollBack). Capture a run of consecutive presses, then replay them in order and observe whether the receiver rolls its counter back so already-used codes work again [rollback]. Record how many consecutive codes the target needs (the paper reports model-dependent counts).

6. Record the finding and impact. State the code type, which technique succeeded, what the receiver did (operated / rejected / resynchronised), and the security consequence (door/gate access, alarm sensor spoof, telemetry forgery).

Field case

A public sample-capture set shipped with rtl_433’s test corpus grounds the fixed-code half of this walkthrough. The merbanan/rtl_433_tests repository (tests/EV1527-Universal-Remote/) records a real EV1527 4-button 433.92 MHz key-fob remote captured at 250 kS/s (cu8), and its readme documents rtl_433 decoding each press to a stable Raw Code: button A → 81898a, B → 41898a, C → 21898a, D → 11898a, and A+C → a1898a (rtl_433 labels the decoder output “Smoke detector GS 558”, id 3148, unit 10) [rtl433-ev1527]. Every press of a given button decodes byte-for-byte identically — that invariance is precisely the fixed-code signature this control looks for, and it is what makes a verbatim replay of any one captured burst sufficient to drive the receiver. A companion capture in the same corpus (tests/EV1527-PIR-SGOOWAY/) shows the SGOOWAY PR2 EV1527 PIR sensor on the same 433.92 MHz band decoding to a single fixed Raw Code 357193 (id 11148, unit 19) [rtl433-ev1527] — the same fixed-code weakness applied to an alarm sensor whose reading the panel trusts.

On an authorised bench the workflow mirrors that documented data: a single press demodulated in URH yields the short, stable EV1527 payload; re-transmitting the recorded burst through a YARD Stick One at the recovered baud operates the gate (or spoofs the sensor reading), confirming verbatim replay.

Switching to a KeeLoq rolling-code fob, two consecutive presses demodulate to two different payloads, and a naive replay of the older one is rejected — exactly the replay resistance a rolling code provides. The jam-and-capture path is then exercised in a shielded enclosure to validate the RollJam primitive on owned equipment.

Remediation

Developer (device / chip). Do not ship fixed-code or short-keyspace OOK remotes for anything security-relevant — they are replayable and brute-forceable [rollingcode][opensesame]. Use authenticated, rolling-code or challenge-response schemes, and harden the counter resynchronisation logic so a short run of consecutive replayed codes cannot roll the window back to a used state — the RollBack class lives precisely in over-permissive resync windows [rollback]. Treat the manufacturer key as a side-channel target and apply DPA countermeasures to the key-handling silicon [keeloq-dpa].

Integrator (system / installer). Prefer frequency-agile or spread-spectrum links over single-frequency OOK so a jammer cannot trivially hold the receiver’s channel for the jam-and-capture window [rolljam-sdr]. For safety-critical sensors, use supervised links that alarm on loss of periodic check-in and on detected jamming, so a withheld or suppressed code is itself an alert. Bind the actuation to a second factor where the consequence warrants it (a gate that also requires a presence beacon, an alarm that cross-checks a wired zone).

Operator (deployment / user). Treat any one-way fixed-code remote or unauthenticated ISM sensor as forgeable, and any rolling-code fob as defeatable by jam-and-capture or resynchronisation; scope it out of trust for high-value access [rolljam-rtlsdr][rollback]. If a key press appears to fail once and works on the second try, consider jam-and-capture and rotate/re-pair where the device supports it. Conduct all replay/jam testing only on owned or explicitly authorised equipment in a controlled RF environment.