Other IoT Radios

• Other IoT Radios
  • Why this matters
  • The landscape
  • Sub-GHz remotes: fixed and rolling codes
    • Fixed code
    • Rolling code
  • TPMS: identifiers in the clear
  • nRF24 and the Logitech Unifying protocol
    • The radio layer
    • Logitech Unifying and MouseJack
    • Worked example: surveying for nRF24 devices
  • Shorter notes on the rest
  • Approaching an undocumented protocol
  • Key takeaways
  • References

Why this matters

WiFi, Bluetooth, Zigbee, Z-Wave, Thread and LoRa have standards bodies, published specifications, certification programmes and security researchers. They are the well-lit part of the spectrum.

Most of the radio traffic in an average building is not any of them.

It is a garage remote from 2003, a tyre-pressure sensor, a wireless doorbell, a weather station, a keyboard dongle, a gate opener, an energy-harvesting light switch and a utility meter. These run proprietary protocols with no specification, no certification, and frequently no security at all — and they are attached to things that matter, like doors.

The long tail is where the bugs are, for the obvious reason: nobody looked. This page covers the protocols you will actually meet, and — more usefully — how to approach one nobody has documented.

The landscape

Two entries deserve note as the good examples. Wi-SUN — the mesh used for utility metering — authenticates every node with EAP-TLS and X.509 certificates, which is stronger than anything else on this page or its siblings. NB-IoT and LTE-M inherit cellular authentication with a real SIM and a carrier-operated key infrastructure. When someone has an incentive to get it right, it gets done right.

Sub-GHz remotes: fixed and rolling codes

The 315 MHz (North America) and 433.92 MHz (Europe and elsewhere) ISM bands are full of on-off keyed remotes. Their security model splits cleanly in two.

Fixed code

The remote transmits the same bit pattern every time. Older units set that pattern with DIP switches — eight or ten of them, giving a few hundred possibilities, sometimes shared across a whole apartment block.

Capture once, replay forever. There is nothing else to it. Garage doors, gate openers, cheap doorbells, remote mains sockets, some alarm sensors, and a distressing number of them are still installed.

Rolling code

Each press advances a counter, encrypts it (KeeLoq on the classic Microchip HCS301, or vendor variants), and transmits the result. The receiver accepts counters ahead of its own within a window and resynchronises. A captured transmission is useless because its counter has already been consumed.

That is a real improvement, and it is defeated by exploiting the window rather than the cipher:

RollJam (Samy Kamkar, DEF CON 2015). Jam the receiver narrowly while capturing the remote’s transmission. The user’s press does not work, so they press again; capture that one too, and replay the first code — which the receiver has never seen. You now hold an unused, valid code, and the user noticed nothing beyond one button press that did not take.

Resynchronisation flaws. Some implementations accept a counter far ahead of current, or can be driven to resynchronise by a consecutive sequence — the issue class behind Rolling-PWN (2022) in certain vehicle systems. The cryptography is untouched; the state machine around it is the problem.

RollJam stopped being a research project. Kamkar’s 2015 demonstration used hardware he built himself, and for a few years afterwards the implicit defence was that nobody would go to that effort. That defence has expired.

The attack has one hardware requirement: transmitting and receiving at the same instant. A half-duplex SDR such as a HackRF cannot do that unaided, and for a while that was a meaningful barrier: the radios that can — a full-duplex 2×2 device like a bladeRF, LimeSDR or USRP B210 — cost between $600 and $2,000 and assume you can write the signal processing yourself. That barrier is gone. The Evil Crow RF v2 is an ESP32 carrying two independent CC1101 transceivers plus an nRF24L01, covering 300–348, 387–464 and 779–928 MHz, driven from a web page, for roughly the price of a textbook. The two CC1101s can receive and transmit simultaneously on different frequencies, which is the RollJam primitive expressed directly in hardware — the same capability a $2,000 SDR provides, minus the generality, at a thirtieth of the price.

Read that as a statement about threat models rather than a shopping recommendation. “An attacker would need custom equipment” was always a weak argument, and the general pattern — an attack requiring specialist hardware, then that hardware becoming a commodity board with a web interface — recurs across this whole field. The Proxmark3 followed the same curve for RFID, and the Flipper Zero did it for sub-GHz capture.

The question to put to a vendor is therefore not “could someone build a RollJam?” but “does your receiver notice it has been jammed?” A receiver that sees a burst of noise on its channel and then a code one counter behind the one it expected has all the information it needs to refuse and alert. Almost none of them look.

⚠️ Jamming is illegal and is not a lab exercise. RollJam is described here so you understand the class of attack and can assess whether a design is susceptible. Deliberate interference violates FCC rules regardless of power level and regardless of intent, and the rule does not soften because the jammer came pre-built. Do not build one, and do not enable the jamming mode on one you have bought.

rtl_433 decodes several hundred of these protocols already. Always try it before concluding you have something novel:

$ rtl_433 -f 433.92M -F json
{"time":"2026-09-13 14:02:11","model":"Generic-Remote","id":24857,"cmd":14,
 "tristate":"00001ZZ0Z1","mic":"CHECKSUM"}
{"time":"2026-09-13 14:02:44","model":"Acurite-Tower","id":11227,
 "temperature_C":21.4,"humidity":46,"battery_ok":1}

TPMS: identifiers in the clear

Tyre-pressure monitoring sensors transmit a unique 32-bit sensor ID, in the clear, every time the wheel turns fast enough. There is no encryption and there is no need for any from the manufacturer’s point of view — it is telemetry.

The consequence is a vehicle tracking system installed on every car by law. A receiver at a chokepoint logs sensor IDs; four IDs identify a specific vehicle persistently, regardless of plate. It is also spoofable — injecting a low-pressure reading lights a dashboard warning, which is a plausible way to make someone pull over.

rtl_433 decodes most TPMS variants. It is a compact, self-contained demonstration that an identifier broadcast without encryption is a tracking beacon, which is the same point made by BLE address randomisation and LoRaWAN DevAddr.

nRF24 and the Logitech Unifying protocol

The Nordic nRF24L01+ family and its Enhanced ShockBurst (ESB) protocol are the default answer for “I need a cheap 2.4 GHz link and I do not want a stack.” Drones, toys, telemetry, industrial remotes — and, most consequentially, wireless keyboards and mice.

The radio layer

ESB has no security whatsoever at the protocol level. The 5-byte address functions as a filter, not a secret — and it is transmitted in every packet. Whatever confidentiality exists is whatever the vendor built on top, per device.

Capture is awkward for a beautifully stupid reason: the nRF24 will not tell you about packets whose address does not match. The research technique abuses an undocumented behaviour — setting an illegal 2-byte address of 0x00AA makes the chip match on preamble alone, turning it into a promiscuous sniffer. This is why nRF24 work uses a Crazyradio PA dongle reflashed with research firmware rather than an SDR: the hopping is fast and the SDR path is far more work for the same result.

The Crazyradio PA is the reference platform and the one all the tooling targets, but it is no longer the only option: the Evil Crow RF v2 carries an nRF24L01 next to its sub-GHz radios and ships mousejacking in its stock firmware. The Flipper Zero does not — its 2.4 GHz radio is the STM32WB55’s BLE core, so nRF24 work there needs an external module and a community application. None of this changes the underlying technique, because the promiscuous-address behaviour is a property of the Nordic silicon; every one of these tools is performing the same trick.

Logitech Unifying and MouseJack

Logitech’s Unifying protocol pairs many devices to one dongle over ESB. Keyboard traffic is encrypted with AES-128. Mouse traffic is not.

Bastille Networks’ MouseJack (Marc Newlin, 2016) found that this asymmetry was not carefully enforced across the industry — Logitech, Microsoft, Dell, HP, Lenovo, Amazon and Gigabyte devices were all affected, in three distinct ways:

1. Unencrypted keystroke injection. Dongles accepted keyboard packets that were not encrypted at all, because some vendor keyboards did not encrypt.
2. Injection via the mouse channel. A dongle paired to a mouse accepted keyboard packets from the same address. Mouse packets are unencrypted, so the attacker simply sends keystrokes on a channel with no crypto on it.
3. Forced pairing. Some dongles accepted a new device pairing with no user action, letting an attacker add their own “keyboard.”

The impact is not subtle: arbitrary keystroke injection into a logged-in workstation, from up to about 100 metres, against a target that displays no indication. That is a shell, delivered by radio, to a machine with no listening service.

Marcus Mengs’ 2019 follow-up (CVE-2019-13052 through CVE-2019-13055) went further — recovering link encryption keys by sniffing a pairing, extracting keys from the dongle over USB, and injecting into encrypted links. Logitech issued firmware updates for some issues and declined others.

⚠️ The affected hardware is still in service. These dongles have no automatic update mechanism; patching requires a user to run a Windows utility they have never heard of. Treat any unifying-style dongle in an assessment as unpatched until you have evidence otherwise — the firmware version is readable and is the finding.

Worked example: surveying for nRF24 devices

With a Crazyradio PA running the research firmware, scan for promiscuous-mode packets:

$ sudo nrf24-scanner.py -v
[2026-09-13 14:11:02]  22  76:E1:44:9C:2B  00:0F:0F:55:0A:1C:32:...
[2026-09-13 14:11:02]  22  76:E1:44:9C:2B  00:C2:00:00:00:00:00:...
[2026-09-13 14:11:05]  48  BB:0A:DC:A5:75  00:4F:00:12:00:00:00:...

The five-byte value is the device address; once you have it, follow that one device across its channel set:

$ sudo nrf24-sniffer.py -a 76:E1:44:9C:2B -v
[2026-09-13 14:12:19]  22  76:E1:44:9C:2B  00:C2:00:01:FF:00:00:...

jackit and LOGITacker automate classification and will report which injection variants a given dongle is susceptible to. In lab, on course hardware only — this attack is keystroke execution on somebody’s computer, and the legal and ethical line here is not blurry.

Shorter notes on the rest

ANT / ANT+ (2.4 GHz, Garmin/Dynastream) — fitness sensors, heart-rate straps, bike power meters. ANT+ uses a published network key, because interoperability is the point; security, where it exists, is per-application. Broadcast sensor data is generally readable, which is a privacy question for anything worn on a body.

EnOcean (868/902 MHz) — energy-harvesting switches and sensors with no battery, powered by the press of the button itself. That constraint caps how much cryptography is affordable. Early devices used a plaintext “teach-in” and were replayable; later versions add a rolling code and AES. Check which generation you have.

DECT ULE (1.88–1.9 GHz EU, 1.92–1.93 GHz US) — cordless-phone technology repurposed for home automation. DECT’s original DSAA authentication and DSC cipher were reverse-engineered and broken by the deDECTed.org project in 2009; DSAA2/DSC2 replaced them. Legacy DECT remains in service.

Wireless M-Bus (868 MHz) — European utility metering. AES-128 is specified, but several modes are defined, key management is left to the utility, and meters have been found transmitting with encryption disabled or with shared keys. Consumption data at fine granularity is a detailed occupancy record.

Sigfox — ultra-narrowband (~100 Hz channels), extremely long range, with a strict message budget (roughly 140 uplinks per day, 12-byte payloads). Messages are signed and sequence-numbered against replay; payload encryption is optional and off by default, on the theory that 12 bytes of sensor data is not sensitive. Frequently it is.

LF and HF RFID — 125 kHz EM4100 credentials have no security whatever and are cloned in seconds; 13.56 MHz MIFARE Classic’s Crypto1 cipher has been broken since 2008. Both are still the majority of deployed access control. Proxmark3 is the tool; this sits on the boundary of the course and is worth knowing exists.

Approaching an undocumented protocol

This is the transferable skill, and it is the reason this page exists. Given an unknown transmitter, work in this order:

1. Find it. Sweep the likely ISM bands and look for energy correlated with you pressing the button.

$ rtl_power -f 300M:450M:50k -i 10 -e 2m -g 40 sweep.csv

2. Try the existing decoders first. rtl_433 knows hundreds of protocols. Most “unknown” devices are already supported, and discovering that after two days of manual work is a bad afternoon.

3. Classify the modulation from the waterfall. One blinking line is OOK; two alternating lines are FSK; diagonal sweeps are LoRa. See Radio Protocols.

4. Recover the symbol timing. Capture in URH, let it estimate the bit length, and check the result against a manual measurement of the shortest pulse. Automatic detection is usually right and occasionally confidently wrong.

5. Diff, do not decode. This is the central technique. Capture the same button ten times, then a different button ten times, and compare:

You can map an entire protocol’s field structure this way without ever understanding its encoding, because structure reveals itself under controlled variation. It is the same reasoning used to identify an unknown bus from a logic capture in Hardware Communications Protocols.

6. Check for the obvious encodings. Manchester and PWM cover most cheap sub-GHz devices; if the bits look like a repeating pattern with no information density, you are probably reading a line code rather than data. CC1101-based devices may also apply data whitening, which URH can undo.

7. Only then consider transmitting — and only against hardware you own.

Key takeaways

• Most radio traffic in a building belongs to undocumented proprietary protocols, and that is where the unexamined bugs are.
• Fixed-code remotes are capture-and-replay, permanently. They are still widely installed on doors.
• Rolling codes are defeated through the resynchronisation window, not the cipher — RollJam captures a code the receiver has never seen by jamming and letting the user press twice.
• “An attacker would need custom hardware” has expired as a defence: RollJam’s two-radio requirement now ships as a commodity board. Ask instead whether the receiver notices it has been jammed.
• TPMS broadcasts a unique plaintext ID: a tracking beacon mandated on every vehicle.
• nRF24 ESB has no security at all; the 5-byte address is a filter, not a secret, and it is in every packet.
• MouseJack turns an unencrypted mouse channel into arbitrary keystroke injection at 100 m, and the dongles have no automatic update path.
• Wi-SUN (EAP-TLS) and NB-IoT/LTE-M (SIM-based) show what these protocols look like when someone has a real incentive to secure them.
• To analyse an unknown protocol, diff captures under controlled variation — structure emerges without understanding the encoding.
• Try rtl_433 before writing anything.

References

• Newlin, MouseJack: Injecting Keystrokes into Wireless Mice (Bastille, 2016) — https://github.com/BastilleResearch/mousejack
• Bastille, MouseJack technical advisories — https://github.com/BastilleResearch/mousejack/tree/master/doc/advisories
• Mengs, Logitech wireless input device vulnerability disclosure (CVE-2019-13052…13055) — https://github.com/mame82/UnifyingVulnsDisclosureRepo
• LOGITacker — https://github.com/mame82/LOGITacker
• Nordic Semiconductor nRF24L01+ product specification — https://www.nordicsemi.com/Products/nRF24-series
• Kamkar, Drive It Like You Hacked It (DEF CON 23, 2015) — https://samy.pl/defcon2015/
• Indesteege et al., A Practical Attack on KeeLoq (EUROCRYPT 2008) — https://www.esat.kuleuven.be/cosic/publications/article-1045.pdf
• Rouf et al., Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study (USENIX Security 2010) — https://www.usenix.org/legacy/event/sec10/tech/full_papers/Rouf.pdf
• rtl_433 and its supported protocol list — https://github.com/merbanan/rtl_433
• Universal Radio Hacker — https://github.com/jopohl/urh
• Crazyradio PA — https://www.bitcraze.io/products/crazyradio-2-0/
• Evil Crow RF v2 — https://github.com/joelsernamoreno/EvilCrowRF-V2
• Texas Instruments CC1101 low-power sub-1 GHz RF transceiver — https://www.ti.com/product/CC1101
• deDECTed.org, DECT security analysis — site offline; archived at https://web.archive.org/web/2018/https://dedected.org/, and the original 25C3 presentation is at https://media.ccc.de/v/25c3-2937-en-dect
• Wi-SUN Alliance, FAN specification overview — https://wi-sun.org/
• Proxmark3 — https://github.com/RfidResearchGroup/proxmark3
• FCC Part 15 rules (47 CFR Part 15) — https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15

Related course pages: Radio Protocols · LoRa and LoRaWAN · Bluetooth · Z-Wave · Hardware Communications Protocols · Attacks · Tools of the Trade

🛠️ Maintenance note: the tooling on this page is the least maintained in the course — mousejack, jackit and the nRF24 research firmware all date from 2016 and the Crazyradio hardware has since been revised, so the nrf24-scanner.py pipeline must be tested end to end before any lab that depends on it. rtl_433’s protocol list grows every release, which is good news: re-check whether a device the course treats as “undocumented” has since been added. Regional band assignments (315 vs 433 MHz especially) differ by country and should be verified for the devices actually on the bench.