Replay Attack
Capture a valid transmission and re-send it to trigger the same action, without ever decrypting it. The default weakness of any system that authenticates by static command.
A replay attack captures a legitimate signal or message and retransmits it later to make a system perform the same action again, without ever needing to understand, decrypt, or modify it. It is the lowest-effort attack in the book and the one an alarming number of RF, IoT, and OT products still fall to.
What it is
Replay is a capture-and-resend attack. You do not break the crypto, forge a packet, or reverse the protocol, you record a valid exchange over the air or on the wire and play it back verbatim. Because the bytes (or the raw RF waveform) are identical to a genuine transmission, a receiver that only checks "is this a well-formed, valid command" accepts it. The attack works precisely because the message carries no freshness: nothing in it distinguishes the tenth replay from the first legitimate send.
Why it matters
Many IoT, RF, and OT systems authenticate by static command rather than by fresh, signed, single-use messages. A fixed-code garage remote, a smart plug that toggles on a plain BLE write, an unauthenticated Modbus write single register, a CAN frame that unlocks the doors, if the captured packet still works when replayed, the device has no defence against an attacker who was simply listening. And listening is cheap: a 20 USD SDR or a Flipper Zero is enough.
How it works
The attacker records a valid exchange, then re-emits it:
1. Capture. Sniff the medium while the legitimate action happens, a 433 MHz remote press, a BLE write, a Modbus command on TCP, a CAN frame on the bus.
2. Store. Keep the raw waveform (for RF) or the exact frame bytes (for a digital bus).
3. Replay. Transmit the identical capture back at the target on demand.
Because the original message contained no nonce, timestamp, or rolling counter, and the receiver keeps no record of what it has already seen, the copy is indistinguishable from the original.
From an attacker's view
Pick the tool for the medium, capture, then retransmit:
# Sub-GHz RF: decode with rtl_433, or capture+replay raw with an SDR / CC1101 / Flipper.
rtl_433 -A # analyze an unknown 433/315 MHz remote
# CAN bus: record a frame, then blast it back.
candump can0 -l # log the bus while the action fires
canplayer -I candump.log # replay the captured frames
# IP-based OT / IoT: capture, then resend the exact bytes.
tcpdump -i eth0 -w capture.pcap
tcpreplay -i eth0 capture.pcap
Garage doors, gate remotes, smart plugs, TPMS sensors, and unauthenticated industrial writes are classic targets. The countermeasures are all about freshness: rolling codes (KeeLoq and successors), per-message nonces, timestamps with a validity window, monotonic counters, and message authentication (a MAC/signature over a counter). A rolling code defeats naive replay, though it opens its own weaknesses (rolljam, desync capture).
Pitfalls
- Rolling codes are not replay-proof by capture alone, but a captured future code (jammed so the receiver never saw it) still replays once, this is rolljam, and it means "it uses a rolling code" is not the end of the analysis.
- Raw RF replay needs the right modulation, frequency, and timing; a bit-identical digital frame is easy, an analog waveform recapture can drift and fail.
- Some systems accept a replay only within a time or sequence window; test promptly after capture, a stale packet may be rejected purely by timing.