Press a car key or a garage remote and a little radio burst goes out at 433 MHz. How that burst is built decides whether someone who recorded it can replay it and walk in. The story runs from fixed codes that fall to the simplest attack imaginable, through rolling codes that fixed it, to RollJam - an attack that beats rolling codes anyway without breaking a single line of their cryptography. It is a clean lesson in how a defence can be sound and still be defeated by attacking its assumptions instead of its maths.
//Fixed Codes: One Recording Is Forever
The oldest remotes send the same code on every press. The receiver stores one valid value and opens whenever it hears it. There is no counter, no freshness, no cryptography - and so anyone who records one transmission holds a key that works indefinitely. Replay it and it is indistinguishable from a real press.
This is not just old car fobs. Plenty of cheap gear still ships fixed codes today: wireless doorbells, ceiling-fan and outlet remotes, low-end alarm sensors, and a lot of basic garage openers built on encoder chips like the PT2262 or HT6P20 family, where the "code" is a handful of address bits often set by DIP switches. Those are the weakest case of all - the keyspace is so small it can be brute-forced, not just replayed, which is what Samy Kamkar's OpenSesame demonstrated against fixed-code garages.
//Rolling Codes: Why Replay Stops Working
Rolling codes fix the replay problem with a counter. The remote and receiver share a secret key and a counter; each press increments the counter, encrypts it, and sends a result that looks completely different every time. The receiver decrypts, reads the counter inside, and - this is the key part - only accepts a counter ahead of the last one it saw, within a forward window, then advances past it.
That forward-only window is what kills replay. Record a press, let the owner press once more, and your recording is now behind the receiver's counter - rejected. The demo shows it: capture code 42, the owner presses again (receiver advances to 43), replay 42, denied. The window exists because presses happen out of range - in a pocket, out of sight - so the receiver tolerates the counter jumping ahead by a bit (a typical KeeLoq decoder accepts roughly the next 16 counts immediately, with a much larger resync window for a fob that has drifted far). But it never accepts the past.
KeeLoq, and an honest word on "broken"
The classic implementation is Microchip's KeeLoq, in encoder chips like the HCS301. Its transmitted word is 66 bits: a 32-bit encrypted portion (a 16-bit counter plus discrimination and button bits, run through the KeeLoq cipher) and a 34-bit fixed portion carrying the remote's 28-bit serial number and status. The cipher itself is a non-linear feedback shift register - an NLFSR, worth stating precisely because it is often miswritten, and it is a different thing from the FSK/ASK radio modulation underneath.
KeeLoq has been cryptographically broken since 2007-2008, in a series of academic papers culminating in a power-analysis attack from Bochum that extracts the shared manufacturer key from a receiver. But be honest about what that means: the headline break depends on first obtaining that manufacturer key - by power analysis of a decoder, or an implementation leak - after which an attacker can clone a fob from a couple of intercepted messages. It is not casually cracking one key fob out of the air. The practical, no-crypto-required attack is the next one.
//RollJam: Beating the Window Without Breaking the Crypto
In 2015, at DEF CON 23, Samy Kamkar demonstrated RollJam, and it is the elegant part of this whole story. It defeats rolling codes while leaving the cryptography completely untouched, by attacking the one assumption the window rests on: that a code the receiver emits is a code the receiver received.
The mechanism, which the demo walks step by step: the attacker jams the receiver's band so it never hears the fob, while recording the fob on a separate receiver. The owner's press appears to fail, so they press again - and the attacker records that one too, still jamming. Now the attacker holds two unused codes. The attacker stops jamming and replays the first captured code; the door opens, the owner sees it work on the second try and thinks nothing of it. But the second code was never delivered to the receiver, so its counter is still the next value the receiver expects - a live key the attacker keeps. Repeat and you always hold one fresh code in reserve.
No cipher was broken. RollJam exploits that a valid rolling code the receiver never actually received stays valid. It is a withholding attack, and it works against a huge installed base of garage doors and older keyless-entry systems precisely because the rolling-code design is sound - the assumption underneath it was not.
//What Fixed It, and What Is Still Open
Modern car entry increasingly moves to challenge-response: the car sends a random nonce, the fob returns a cryptographic answer, and a captured answer is useless because the next challenge differs. That kills both replay and RollJam-style withholding.
But it opened a new hole - the relay attack. Passive keyless entry will answer a challenge automatically, so two attackers can relay the exchange in real time between the car and the fob sitting on a hall table. The crypto is perfect; the broken assumption this time is distance. The current countermeasure is ultra-wideband secure ranging (the IEEE 802.15.4z and Digital Key specs), which measures time-of-flight precisely enough to confirm the key is physically within tens of centimetres - a relay adds just enough delay to fail the check.
Old garage doors, meanwhile, remain wide open. They are long-lived appliances with no challenge-response, a generous forward window, and firmware nobody ever updates, so RollJam-style attacks still work on an enormous installed base. The pattern across the whole article is the same one the metadata piece and the GPS piece land on from other directions: the cryptography is rarely the weak point. The assumption around it is.
//Sourcing and Framing
The fixed/rolling mechanics, the HCS301 66-bit structure and window behaviour are from Microchip's datasheet and the KeeLoq literature; the cryptanalysis is the 2007-2008 academic work (Bogdanov; Courtois, Bard and Wagner; Indesteege et al. at Eurocrypt 2008; the Bochum power-analysis paper at CHES 2008). RollJam is Samy Kamkar's DEF CON 23 (2015) "Drive It Like You Hacked It." Reported operational figures (a ~$32 build, cloning ranges) are attributed as reported, not independently reproduced. UWB distance bounding is the IEEE 802.15.4z / Car Connectivity Consortium Digital Key work.
Framing: defensive and educational, no operational attack tooling, and nothing about attacking systems you do not own - the demo decodes and attacks nothing, it illustrates the mechanism. The interpretation is mine: that RollJam is worth teaching precisely because it is not a crypto break, and the most durable security lesson in radio is to ask what a sound-looking scheme is quietly assuming.