Decoding Unknown 433 MHz IoT Protocols with rtl_433

I was tuning around 433 MHz looking for LoRa packets from my own sensors when I stumbled on what turned out to be a neighbor's weather station transmitting temperature data in the clear. Ten minutes of work gave me a live feed of their backyard temperature and humidity. This is why IoT radio security matters.

The 433 MHz ISM Band

The 433.05-434.79 MHz band (in ITU Region 1) is an Industrial, Scientific and Medical (ISM) band. No license is required for low-power devices. As a result, it is packed with consumer devices: weather stations, tire pressure monitors, wireless doorbells, car key fobs, garage door openers, soil moisture sensors, and dozens of other things.

Most of these devices use simple OOK (on-off keying) or FSK (frequency-shift keying) modulation with proprietary protocols. There is no encryption, no authentication, and no replay protection.

rtl_433: The Universal Decoder

The rtl_433 project is an impressive piece of software. It supports over 200 device protocols and can automatically detect and decode signals from devices it recognizes.

# Install
sudo apt-get install rtl-433

# Or build from source for the latest protocols
git clone https://github.com/merbanan/rtl_433.git
cd rtl_433 && mkdir build && cd build
cmake .. && make -j4
sudo make install

# Run with automatic protocol detection
rtl_433 -f 433920000

Leave it running and within a few minutes you will start seeing decoded packets from nearby devices.

Identifying Unknown Signals

When rtl_433 does not recognize a signal, you can capture the raw data for analysis:

# Record raw I/Q samples
rtl_433 -f 433920000 -S unknown

# Or use rtl_sdr directly for a broader capture
rtl_sdr -f 433920000 -s 250000 capture.bin

Then analyze in GNU Radio or inspectrum:

inspectrum capture.bin

Inspectrum gives you a spectrogram view where you can see individual transmissions, measure timing, and identify the modulation type visually.

Case Study: Oregon Scientific Weather Station

The signal I found was transmitting every 30 seconds on 433.92 MHz. In inspectrum it showed classic OOK modulation with a clear preamble pattern.

rtl_433 identified it immediately:

time      : 2016-06-08 14:32:15
model     : Oregon-THR228N
House Code: 172
Channel   : 1
Battery   : OK
Temperature: 23.4 C
Humidity  : 67 %

No encryption. No authentication. Anyone within radio range (typically 30-100 meters for these devices) can read the data.

Security Implications

The lack of security on 433 MHz IoT devices has real consequences:

Replay attacks on garage doors. Many older garage door openers use fixed codes. Record the signal once, replay it later. Newer models use rolling codes, but the implementation quality varies.

Car key fob cloning. Some vehicles, particularly older models, use fixed-code key fobs on 315/433 MHz. The RollJam attack demonstrated by Samy Kamkar showed that even rolling codes can be captured and replayed under certain conditions.

Home sensor data leakage. Weather stations, motion sensors, and door/window sensors broadcast in the clear. An attacker can build a profile of a home's occupancy patterns just by monitoring 433 MHz from outside.

Tire pressure monitors (TPMS). Every car made after 2007 (in the US) transmits TPMS data on 315 MHz. This includes a unique sensor ID that can be used to track individual vehicles.

Mitigations

If you are designing IoT devices that use ISM bands:

  1. Use AES-128 encryption at minimum for all transmitted data
  2. Implement rolling codes or challenge-response authentication
  3. Include a message counter to prevent replay attacks
  4. Minimize the transmission power to reduce range
  5. Consider using protocols with built-in security like Zigbee 3.0 or Thread

For consumers: there is not much you can do about existing devices. Be aware that your wireless devices are broadcasting and act accordingly.

sc
strcpy
SDR & Radio Security Researcher
Radio tinkerer and SDR enthusiast. Explores wireless protocols at the physical layer using BladeRF, HackRF, and RTL-SDR hardware. All work is receive-only or conducted in authorized test environments.