HW 4: RF Capture and Radio Protocol Analysis
Covers: Weeks 7–8 Due: Friday of Week 8 — 20 November 2026, 23:59:59 Points: 100
Introduction
HW #3 extracted firmware over a wire you could touch. This assignment removes the wire. Everything here happens over the air, at a distance, against a target that has no idea you exist.
You will characterize the spectrum, identify a modulation by its signature, capture and decode LoRa traffic between your board and a partner’s, and then demonstrate the consequence of a physical layer with no MAC-layer protections: a working replay.
The replay is the point of the assignment. It is not a clever trick — it is what happens by default when a link layer provides no freshness guarantee, and seeing it work on hardware you built yourself makes the LoRa/LoRaWAN distinction permanent in a way a lecture slide does not.
⚠️ Transmit only on 915 MHz ISM, only with course hardware, only in lab. Receiving is broadly legal; transmitting is not. The 915 MHz ISM band permits unlicensed operation under FCC Part 15 within power and duty-cycle limits, and the course radios are compliant as configured. Do not modify transmit power, do not transmit on other bands, and do not replay traffic from any device that is not yours or your partner’s. Violations are a federal matter, not a grading matter. See the scope and authorization note.
Part A — Spectrum and modulation
Task 1 — Characterize your capture chain
15 points.
Before capturing anything meaningful, establish that you understand your instrument.
- Using your SDR, record the three defining parameters of a capture — center frequency, sample rate, and gain — and explain what each controls.
- Capture the 915 MHz ISM band with your gain set deliberately low, then deliberately too high. Include waterfall screenshots of both.
- Identify at least one artifact in the high-gain capture that is not a real transmitter, and explain what produced it.
- State the minimum sample rate required to observe a 125 kHz LoRa channel, show the reasoning, and state what rate you will actually use and why.
Task 1.3 exists because front-end saturation produces signals that look completely real. Students who skip this step spend Task 3 chasing ghosts.
Task 2 — Modulation identification
15 points.
You will be given three recorded IQ captures of unidentified signals, plus you will capture a fourth yourself from your own board.
For each of the four signals:
- Include a waterfall screenshot and a time-domain amplitude plot.
- Classify the modulation using the signature table from Week 7.
- Justify the classification from what is visible, not from what you know the answer to be. “Two alternating parallel lines separated by ~50 kHz, constant amplitude” is a justification; “it is 2-FSK” is not.
- Estimate the occupied bandwidth and, where the modulation makes it visible, the symbol rate.
At least one of the provided captures is deliberately ambiguous. Say so if you cannot classify it confidently, and describe what additional information would resolve it.
Part B — LoRa
Task 3 — Capture LoRa over the air
20 points.
- Working with a partner, configure one board as a transmitter sending a distinctive payload including your OdinID, and the other as a receiver. Build on the code from Lab 2 and Lab 3.
- With your SDR, capture the transmission independently of the receiving board. Include the waterfall showing the chirps.
- Identify from the capture: the center frequency, the bandwidth, and the spreading factor. Explain how you determined the spreading factor from the chirp rate.
- Demodulate the capture to bits using URH, a GNU Radio flowgraph, or another documented tool, and show that the recovered payload matches what was transmitted.
- Report the RSSI at the receiving board and compare it against the signal strength visible in your SDR capture. Explain any difference.
Task 4 — Replay
25 points.
This is the core of the assignment.
- Capture a transmission from your partner’s board.
- Retransmit the captured payload from your own board, without your partner changing anything on the receiver.
- Demonstrate that the receiver accepted the replayed message as genuine. Include the receiver’s output — the OLED display, the serial console, or both — showing it processed your replay.
- Explain precisely why this works. Your explanation must identify what security property is missing, not merely restate that the replay succeeded.
- Now design a defence. Specify a scheme that would defeat your own replay
while running on the same hardware. Address:
- What state each side must maintain.
- What happens when the receiver reboots and loses that state.
- What happens when a legitimate message is lost in transit.
- Why flash write endurance constrains your design.
- Implement your defence and demonstrate that the same replay now fails. Include the code and the failed-replay evidence.
Item 5.4 is where most designs fall over, and it is the reason real devices get this wrong. A counter that must survive power loss lives in flash; flash wears out; implementers cut corners; the corner they cut is the one protecting you.
Task 5 — LoRaWAN analysis
25 points.
Written analysis. No implementation required.
- Explain the difference between LoRa and LoRaWAN as precisely as you can, identifying where the security boundary sits.
- Describe LoRaWAN’s key hierarchy: which keys exist, what each protects, and how they are derived or provisioned.
- Compare OTAA and ABP activation. Which is more vulnerable to the attack you performed in Task 4, and why?
- Describe the role of frame counters, and identify two documented real-world failure modes in deployed LoRaWAN systems. Cite your sources.
- Would your Task 4 replay succeed against a correctly implemented LoRaWAN network? Justify your answer from the specification, not from intuition.
- Graduate students (CS 510) only: LoRaWAN 1.1 changed the key hierarchy and join procedure relative to 1.0.x specifically to address weaknesses. Describe one such change, the weakness it addresses, and any backward compatibility concern it introduces.
Submission
Commit hw4/hw4.md, your code, and your captures to your repository.
IQ captures are large. Commit short representative captures only — a few seconds each — and note the parameters of anything larger you keep locally. If a capture exceeds 50 MB, do not commit it; report its SHA-256 instead.
Grading
| Item | Points | Required for |
|---|---|---|
| Task 1 — Characterize your capture chain | 15 | CS 410 and CS 510 |
| Task 2 — Modulation identification | 15 | CS 410 and CS 510 |
| Task 3 — Capture LoRa over the air | 20 | CS 410 and CS 510 |
| Task 4 — Replay and defence | 25 | CS 410 and CS 510 |
| Task 5 — LoRaWAN analysis, items 1–5 | 25 | CS 410 and CS 510 |
| Task 5 item 6 — LoRaWAN 1.1 key hierarchy | see note below | CS 510 required; CS 410 extra credit |
| Total | 100 |
CS 510 students who omit Task 5.6 lose 10 points from Task 5. CS 410 students who complete it earn up to 5 points of extra credit.
References
- LoRa Alliance, LoRaWAN specifications — https://lora-alliance.org/resource-hub/
- LoRa Alliance, LoRaWAN Security whitepaper — https://lora-alliance.org/resource_hub/lorawan-security-whitepaper/
- Semtech, LoRa Modulation Basics (AN1200.22) — https://www.semtech.com/products/wireless-rf/lora-connect
- Universal Radio Hacker — https://github.com/jopohl/urh
- Universal Radio Hacker, USENIX WOOT ‘18 — https://www.usenix.org/system/files/conference/woot18/woot18-paper-pohl.pdf
- GNU Radio — https://www.gnuradio.org/
- rtl-sdr — https://www.rtl-sdr.com/
- FCC Part 15 rules (47 CFR Part 15) — https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15
- Adafruit RFM9x LoRa documentation — https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts
Related course pages: Schedule · Lab 2 · Lab 3 · HW #3 · Final Project
🛠️ Maintenance note: the three provided IQ captures are course artifacts — keep them archived alongside the assignment rather than regenerating them each term, so grading stays consistent. Verify FCC Part 15 citations remain current and that the course radios’ configured transmit power is still within limits after any firmware update to the RFM95 driver stack.