5
Week 3 · The keystone

Raw signals & rolling codes

This is the module that makes sense of everything you found strange so far. You'll capture signals the Flipper refuses to name, and you'll finally understand why a copied gate remote works exactly once and then dies — and why that failure is the system doing its job perfectly.

⏱ 55 min Gear: your own remotes, one rolling Firmware: Momentum

Goal

Two things, and they're connected. First: use Sub-GHz → Read RAW to record a signal the Flipper can't decode into a tidy key — a waveform instead of a number — and replay it to your own device. Second: understand rolling codes deeply enough that "my replay does nothing" stops being a mystery and becomes a prediction you could have made in advance.

By the end you'll be able to look at any RF device you own and say, before you even capture it, whether a replay stands a chance — and if it doesn't, exactly why.

Read RAW: capturing the un-nameable

In Module 3, Read matched your remote to a known protocol and gave you a clean key. But sometimes Read comes up blank. The pulses arrive, the frequency is right, and still no protocol name appears. That doesn't mean there's no signal — it means the Flipper doesn't have a rule that fits it. Maybe it's an obscure encoding, maybe it's rolling, maybe it's just unusual.

That's what Read RAW is for. Instead of trying to understand the signal, it simply records the raw on-off timings — every pulse and gap, in microseconds — as a literal transcript of what came out of the radio. No interpretation, no key. Just the waveform.

A saved RAW capture is still a plain-text .sub file, but it looks very different from the decoded one you saved in Module 3:

Filetype: Flipper SubGhz RAW File
Version: 1
Frequency: 433920000
Preset: FuriHalSubGhzPresetOok650Async
Protocol: RAW
RAW_Data: 328 -456 320 -1348 980 -452 336 -444 972 -1360 340 -448

The magic is all in the RAW_Data line. It's a long list of durations in microseconds, alternating sign:

+ value
The transmitter was on for that many microseconds (a pulse).
− value
The transmitter was off for that many microseconds (a gap).
Protocol: RAW
A flag that says "there is no decoded key here — replay by playing these timings back verbatim."

Real captures have hundreds or thousands of these numbers. Replaying a RAW file doesn't regenerate anything from a protocol — it just re-radiates the recorded pattern exactly. That's powerful (it copies things Read can't name) and fragile (it copies the noise and gaps too, so a messy capture plays back messy).

i
Read vs. Read RAW — when to use which Reach for Read first: if the Flipper can name the protocol, you get a compact, robust, editable key. Fall back to Read RAW when Read stays blank but Frequency Analyzer (Module 1) confirms there's a real signal on that frequency. RAW captures anything; decoded captures understand something. Prefer understanding when you can get it.

Fixed vs rolling, side by side

You've met both by now. Here they are next to each other, because the entire module hinges on the difference:

fixed Fixed code

Sends the same message every press. Capture it once and a replay works forever, because the receiver can't tell a copy from the original — there's nothing to change.

Doorbells, LED remotes, fans, cheap outlets, older gates (CAME, Nice FLO, Princeton, Holtek).

rolling Rolling code

Sends a different message every press. A captured code becomes stale the moment it's used, so a replay of an old code is rejected. Copying it once buys you nothing.

Car fobs, modern gates and garage doors (KeeLoq, Security+ 2.0, Nice FloR-S).

Fixed codes trade security for simplicity; rolling codes spend a little complexity to close the "capture once, replay forever" hole. The rest of this module is about how they close it — and it's more elegant than you might expect.

How a rolling code actually works

A rolling-code remote adds two ingredients to the fixed-code recipe: a counter and encryption.

The counter is just a number that goes up by one every time you press the button. Press one: counter 41. Press two: counter 42. Press three: counter 43. The remote and its paired receiver both keep track of this number, and crucially, they were synchronised when the remote was first enrolled.

If the remote simply broadcast "I'm remote #12345, counter 42" in the clear, an eavesdropper could read the pattern and forge the next value. So the remote encrypts the counter (together with its identity and the button) into a scrambled block that changes completely with every increment. This is what the classic ciphers do:

SchemeWho uses itThe idea
KeeLoq rollingMicrochip's classic; countless car fobs, gates, garagesThe original mass-market rolling cipher. Encrypts a counter + serial into a hopping code.
Security+ 2.0 rollingChamberlain / LiftMaster garage systemsA newer rolling scheme; the reason many recent US garage doors won't replay.
Nice FloR-S rollingNice gates and barriers (the rolling sibling of fixed Nice FLO)The Flipper's Read screen shows a Cnt that climbs each press — the counter, in plain sight.

When a press arrives, the receiver decrypts the block, checks the identity, and reads out the counter. Then it applies one simple, decisive rule.

The acceptance window

The receiver remembers the highest counter it has already accepted. Call it "last seen." A new press is accepted only if its counter is ahead of last-seen — and within a forward window of the next so-many values. Anything at or behind last-seen is treated as an old, already-used code and thrown away.

last seen rejected (used) accepted (window) too far → resync counter →
The receiver only accepts codes ahead of "last seen" and inside the forward window. Old codes fall in the red zone; codes far ahead need a resync.

Here's the consequence, and it's the whole game: the instant the receiver accepts a code with counter 42, it moves "last seen" up to 42. Now counter 42 is behind last-seen — permanently in the red zone. Replay that exact captured press and the receiver shrugs: "already used." A rolling code isn't rejected because it's fake. It's rejected because it's old.

Two more pieces make it survive real life:

  • The window exists so you can miss. Press your fob in your pocket, out of range, and its counter climbs while the receiver's doesn't. Next time you're in range, your counter is ahead but still inside the window, so it's accepted and the receiver catches up. Without a window, one accidental press would lock you out.
  • Resync handles a big gap. If you press far out of range many times, your counter runs past the window and the receiver ignores you. Most systems then require a resync — often two valid presses in a row, or a re-enrolment — to safely realign the two counters.
✓
The tell you can read on the screen For rolling families like Nice FloR-S, the Flipper's Read screen shows a Cnt value, and it increments by one every time you press. That climbing number is the single clearest sign you're looking at a rolling code — and a promise that replay won't work. A fixed code, by contrast, shows the same key on every press with no counter at all.

Now play with it. The simulator below is a remote, a receiver, and a counter window. Capture a code, replay it, and watch the receiver reject it as used — then see how a resync realigns them.

Case: a replay appears to work once

This is a hypothetical diagnostic example, not a verified incident involving a particular gate. In a counter-based model, a previously unused valid message may be accepted if it falls within the receiver’s forward window. Once consumed, the same message is stale.

A forward window does not make an old counter fresh again. If an identical capture seems to work intermittently, investigate the actual protocol, whether a file contains multiple frames, whether receiver state changed, and whether you are observing the same operation. Do not claim a diagnosis from “works once” alone.

Rejected stale messages do not normally advance the receiver counter. Real products have implementation-specific synchronization and recovery behaviour, and operational fob experiments can cause loss of access. Use the simulator to explore the model; use the manufacturer’s documented process for genuine remote provisioning or repair.

Read the primary sources: Microchip HCS301: synchronization model (PDF) · Flipper: demodulated RAW recordings · Flipper: static and dynamic protocol support. Course review: 10 September 2026.

Lab: RAW is a representation

  1. Use your documented fixed-code training remote from Module 3, or inspect its saved file if you cannot perform a radio lab.
  2. Record a short press with Read RAW using the correct frequency and preset; stop promptly and save with a lab name. You do not need an unknown or security remote to learn the RAW format.
  3. Compare the RAW file with the decoded file. Identify frequency, preset, and pulse timings. RAW contains demodulated timing data, not raw I/Q samples.
  4. Do not infer rolling security from a failed replay. Use the simulator above to compare fresh and consumed counters. Predict each result before pressing its controls.
  5. Record what each representation retains and what it does not tell you.

For this lab, no physical RAW replay is required. The fixed-code replay skill is covered in Module 4.

Read the primary sources: Flipper: demodulated RAW recordings. Course review: 10 September 2026.

Which tool for the job

You now have three ways to approach a Sub-GHz device: decode it with Read, record it with Read RAW, or recognise that a replay can't help at all. Choosing well is most of the skill. Use the picker below to reason it through for a given device, then check the ethics note underneath — because the line between learning and harming is exactly here.

Check yourself

Verify the details

Read the primary sources: Flipper: demodulated RAW recordings · Microchip HCS301: synchronization model (PDF). Course review: 10 September 2026.