Demodulate and frame a Sub-GHz burst

Mechanism

Sub-GHz ISM devices are built for cost, not stealth: nearly all of them transmit narrowband OOK/ASK (the carrier blinks the bits on and off) or (G)FSK (the carrier shifts between two tones), with no spread-spectrum and no scrambling [rtl433primer]. That makes the physical layer a pure signal-processing problem — there is no key, no de-spreading, and no channel hopping to defeat before the bits appear. Demodulation recovers the symbol stream; framing then resolves the line coding — typically PWM, PPM, Manchester or raw NRZ at a few hundred to a few thousand baud — into bits [rtl433primer].

Two demodulation paths exist, and they are equivalent at this layer. A software path loads an I/Q recording from an SDR and slices it: rtl_433 runs a pulse demodulator and, with -A, reports the measured pulse width, gap width and period so you can read the coding by eye, while -X lets you write a flex decoder for an unrecognised device [rtl433primer]. A hardware path programs a CC1101/CC1111-class transceiver (driven by rfcat) to the recovered carrier, modulation and baud, letting the radio chip itself do the demodulation — the hybrid SDR-plus-dedicated-radio workflow Ossmann set out as “rapid radio reversing” [ossmann2015rrr]. Universal Radio Hacker sits in the middle: it visualises the burst, auto-detects the modulation and bit length directly from the I/Q, and extracts the bitstream [pohl2018urh][urhrepo]. That auto-detection — estimating all the demodulation parameters from the recording so an analyst can skip the physical layer — is the subject of Pohl and Noack’s follow-on work [pohl2019autopre].

The security relevance at PHY is exactly this absence of a barrier. Because the bits travel in the clear, framing the burst is a tooling exercise rather than a cryptographic one [ossmann2015rrr][rtl433primer]; the recovered bitstream is what every downstream control — capture/replay, rolling-vs-fixed determination, forgery — consumes. This control verifies only that the bits can be recovered cleanly; it does not yet replay or forge them.

The applicability list and the bit-rate range (“a few hundred to a few thousand baud”) are the representative envelope for the band — the modulation and line-coding families and the few-hundred-to-few-thousand-baud range are the general behaviour documented for ISM-band devices [rtl433primer], not a guarantee for any one target, which must be measured per device.

Procedure

All steps below are passive receive-and-demodulate. They involve no transmission and so need no special authorisation, but any later replay/forgery step does — perform those only on equipment you own or are explicitly authorised to test.

1. Capture the burst as I/Q, centred on the carrier found at the Spectrum step, at a sample rate that comfortably covers the burst bandwidth. With an RTL-SDR or HackRF:

   rtl_sdr -f 433920000 -s 1024000 -g 40 capture.iq

   Trigger the device a few times during the capture. A non-empty file with visible energy when you trigger the device confirms a usable recording; silence means re-check the frequency/gain.

2. Read the modulation and timing with rtl_433’s analyzer. Point it at the band and enable the analyzer/verbose pulse output:

   rtl_433 -f 433.92M -A

   Expected: for a recognised device, a JSON line naming it; for an unknown one, the analyzer prints measured pulse width, gap width and pulse period and a guess at the coding (OOK_PWM / OOK_PPM / OOK_MC / FSK). Read those numbers — they are the bit rate and line coding [rtl433primer].

3. Demodulate and frame in Universal Radio Hacker when rtl_433 has no decoder. Load the recording and let URH auto-detect:

   urh                       # GUI: Interpretation tab → "Autodetect parameters"

   Expected: URH labels the modulation (ASK/FSK), estimates the bit length / samples-per-symbol, and renders the burst as a bit string. Set the decoding (Manchester / PWM / NRZ) until the preamble and a stable structure appear [pohl2018urh][pohl2019autopre].

4. Confirm the framing is correct, not just plausible. The same physical press, captured twice, must demodulate to the same bits (for a fixed-code device) or differ only in the expected counter field (rolling). A demod whose bit count drifts between identical presses means the bit length or coding is still wrong — return to step 3.

5. (Optional) Validate against a hardware demodulator. Program a YARD Stick One to the recovered settings and receive the same burst, cross-checking the bitstream:

   # rfcat (interactive)
   d.setFreq(433920000)
   d.setMdmModulation(MOD_ASK_OOK)
   d.setMdmDRate(2400)            # baud recovered above
   print(d.RFrecv())

   Matching bits from an independent CC1111 radio confirm the PHY parameters are right and not an SDR artefact.

Field case

Documented public walkthrough — substitute the values you capture. This is a worked example for the most common class on the band, an EV1527/PT2262-class OOK fixed-code remote (doorbell or socket remote), anchored to rtl_433’s published decoder and shipped sample corpus for this exact device class rather than to a live capture of our own [rtl433ev1527]. The modulation family (OOK/ASK), the fixed-code outcome and the per-press repetition are the general, citable behaviour of this device class [rtl433primer][rtl433repo]; the concrete timings below are the ones rtl_433 documents for it, but for any specific unit they must still be re-measured.

• The carrier sits at 433.92 MHz; the waterfall shows short OOK bursts (blinking blocks, not two stacked FSK lines) each time the button is pressed.
• rtl_433’s decoder for this exact class — Generic Remote SC226x EV1527 (src/devices/generic_remote.c) — characterises the burst as OOK_PWM with a short pulse of 464 µs and a long pulse of 1404 µs (tolerance 200 µs), i.e. a PWM bit period of roughly 1868 µs (~535 baud) [rtl433ev1527]. The sibling in-repo EV1527 flex spec (conf/EV1527-4Button-Universal-Remote.conf, m=OOK_PWM s=369 l=1072 g=1400 r=12840 bits>=24 repeats>=3) records the same OOK_PWM family with comparable timings for a 4-button variant [rtl433ev1527].
• Loaded into URH, autodetect labels the signal ASK, bit length [FILL: samples-per-symbol], and resolves the frame to 25 bits per burst — 24 data bits plus a trailing always-1 stop bit, per the decoder’s bits != 25 / “Last bit (MSB here) is always 1” framing check [rtl433ev1527]. The 24-bit data word repeats several times per press: rtl_433’s EV1527 family confirms a row by requiring it to recur ≥ 3 times per transmission (bitbuffer_find_repeated_row(bitbuffer, 3, 24)) [rtl433ev1527].
• Two captures of the same button press demodulate to an identical bitstream — establishing this as a fixed code (the fixed-vs-rolling determination this PHY framing hands to the link/attack layers), so a plain capture-and-replay is the relevant downstream test rather than a RollJam-class technique. The rtl_433_tests corpus (tests/generic_remote/01/, with gfile001.cu8 and its expected gfile001.json) ships exactly such a repeated fixed-code burst for this decoder [rtl433ev1527].

Remediation

Demodulation is auditor-side — there is no “fix” for the ability to recover bits from a clear waveform. The defensive value of this control is what the clean bitstream proves: that the PHY layer authenticates nothing. Layered guidance for the parties who can act on it:

• Developer (device firmware/silicon). Do not treat a stable, recoverable ID broadcast in the clear as a security property — identification is not authentication. If confidentiality or integrity matters, add it above the PHY (an authenticated/encrypted payload, a true rolling code with an adequate window, a freshness/nonce field), because the waveform itself will always demodulate [ossmann2015rrr][rtl433primer]. Avoid trivially short keyspaces (e.g. 8–12 DIP-switch bits) that a recovered frame format makes brute-forceable.
• Integrator (product builder). Choose modules whose security does not rest on obscurity of the modulation or line coding; assume an auditor (and an attacker) can frame the burst with rtl_433 or URH within minutes [pohl2018urh]. Where a clear-text fixed code is unavoidable for a function, ensure that function is not safety- or access-critical, or gate it behind a second, authenticated channel.
• Operator (deployment). Recognise that a captured remote, sensor or contact-closure signal can be reproduced from a passive recording; for access-control or safety roles, prefer devices documented to use authenticated rolling codes, and monitor for the replay/jamming the demodulated frame enables downstream. Frame any vendor protocol list as representative — check current advisories and rtl_433’s supported-device set, which change often [rtl433repo].