LoRa

LoRa (Long Range) is a sub-GHz chirp spread-spectrum radio modulation for long-distance, low-power links, and LoRaWAN is the network and security layer most deployments run on top of it. Note the split: LoRa is the physical layer (the chirp), LoRaWAN is the MAC and crypto. Attacking one is not the same as attacking the other.

What it is

LoRa uses chirp spread spectrum (CSS): each symbol is an up-chirp that sweeps across the channel bandwidth, which trades data rate for range and lets a receiver pull signals out from below the noise floor. Three parameters set the physical link and must all match to decode a frame:

LoRaWAN then classifies devices as Class A (uplink then two short receive windows, lowest power), Class B (scheduled beacon slots), or Class C (always listening). Security uses two AES-128 keys: a network session key (NwkSKey) for the frame MIC and an application session key (AppSKey) for payload encryption.

Why it matters

LoRaWAN carries OT telemetry, utility metering, and asset trackers over kilometres, so the radius of exposure is large and the endpoints are physically unreachable. Two keying modes exist. ABP (Activation By Personalization) burns static session keys into the device; if those leak or are reused, an attacker can decrypt and forge indefinitely. OTAA (Over The Air Activation) derives fresh session keys from a join, but if the server does not track the DevNonce, a captured join-request can be replayed to force re-keying or denial of service. Raw, non-LoRaWAN LoRa links are frequently unauthenticated and unencrypted entirely.

How to attack it

Match the physical parameters first, then work up the stack:

# 1. Find energy in the sub-GHz band with an SDR.
gqrx                              # or rtl_power sweep around 868/915 MHz

# 2. Decode LoRa frames once frequency, SF, and BW match.
#    gr-lora / gr-lora_sdr flowgraph in GNU Radio, or a LoStik/Heltec node.

# 3. Inspect and replay. For LoRaWAN, load keys into a decoder.
#    lorawan-parser / a NwkSKey+AppSKey in Wireshark's LoRaWAN dissector.

# 4. Replay a captured uplink or a join-request; jam by transmitting
#    continuously on the target channel.

For cheap sub-GHz replay of simple (non-LoRaWAN) OOK/FSK remotes, a CC1101 or a Flipper Zero is often enough; for real LoRa chirp decode you want an SDR (RTL-SDR receive, HackRF for transmit) plus gr-lora, or a dedicated LoRa concentrator.

Pitfalls

• LoRa is not LoRaWAN. A Flipper or CC1101 can replay a dumb sub-GHz remote, but it does not demodulate LoRa CSS; that needs an SDR flowgraph or a LoRa transceiver.
• All three of frequency, SF, and BW must match, plus sync word and coding rate. A near miss decodes nothing, which reads like "no signal".
• OTAA replay only works when the server accepts a repeated DevNonce; compliant LoRaWAN 1.0.4 / 1.1 servers track it and reject the replay.
• Regional duty-cycle limits (notably 1% in EU868) constrain how often you can legally transmit; jamming and flooding cross legal lines fast.

Further reading

• Wiki: replay-attack
• Wiki: zigbee
• Wiki: iot-attack-surface