Lab 10: RF Protocol Attack Surface Analysis

Week: 11b -- Penetration Testing Cross-Cut
Points: 15
Time estimate: 90 min lab + 1 hr independent
Prerequisite: Lab 9 protocol specification (use your lab9/PROTOCOL-SPEC.md)
Deliverable: lab-10-report.md

Objectives

1. Apply an RF threat model to the protocol you reverse-engineered in Lab 9.
2. Analyze the feasibility and impact of three attack classes against a real protocol.
3. Propose protocol-level defenses with explicit cost/complexity tradeoffs.
4. Write a rules of engagement document for a hypothetical authorized RF PT engagement.

Overview

Lab 10 does not require any signal transmission. The analysis target is the ISM433-MYSTERY protocol you documented in Lab 9. You are the analyst on an authorized RF security engagement against a client's sensor network that uses this protocol. Your job is to characterize the attack surface, evaluate the defenses, and write the ROE document.

If your Lab 9 protocol spec is incomplete, use the following reference spec:

Physical layer: OOK, 433.92 MHz, 4800 Baud, NRZ
Preamble: 8 × 0xAA
Sync word: 0xD3 0x91
Payload: Device ID (12 bits) | Channel (2 bits) | Temperature (10 bits)
Checksum: CRC-8/MAXIM (1 byte)
Auth: None
Replay protection: None

Part A: Threat Model (6 points)

A.1 Attack Surface Overview

For the ISM433-MYSTERY protocol, enumerate the attack surfaces available to an adversary with passive capture capability (RTL-SDR) and active transmission capability (HackRF One or equivalent).

Use this table template:

## ISM433-MYSTERY: RF Threat Model

**Attacker capability assumptions:**
- Passive capture: RTL-SDR at 433 MHz, 2.4 MSPS, within 100m of target device
- Active transmission: HackRF One or LimeSDR, ≤20 dBm TX power, at 433.92 MHz
- Protocol knowledge: full protocol spec from passive RE (this lab)

---

| Attack | Description | Receiver impact | Spec sufficient to mount? | Notes |
|---|---|---|---|---|
| Replay | Record a legitimate OOK frame; retransmit | Receiver accepts as legitimate; sensor reading injected | Yes | IQ file + `hackrf_transfer` |
| Bit-flip injection | Modify field bits in captured IQ and retransmit | Receiver receives false data (e.g., false temperature) | Yes, with care | Requires IQ-level bit manipulation |
| Denial of service (jamming) | Transmit wideband noise on 433.92 MHz | Receiver cannot decode any frames | No spec needed | Illegal without FCC authorization; excluded from most PT scopes |

A.2 Replay Attack Feasibility

Analyze the replay attack in detail:

#!/usr/bin/env python3
"""Lab 10 Part A.2: Replay attack feasibility analysis."""
import numpy as np

def analyze_replay_feasibility(protocol_spec: dict) -> dict:
    """
    Analyze whether a replay attack is feasible given a protocol specification.
    
    Returns a dict of feasibility assessments.
    """
    results = {}
    
    # Check 1: Rolling code present?
    results['rolling_code'] = protocol_spec.get('rolling_code', False)
    results['replay_prevented'] = results['rolling_code']
    
    # Check 2: Sequence number with small window?
    has_sequence = protocol_spec.get('sequence_number', False)
    seq_window = protocol_spec.get('sequence_window', 0)
    results['sequence_replay_limited'] = has_sequence and seq_window < 100
    
    # Check 3: Timestamp present?
    results['timestamp'] = protocol_spec.get('timestamp', False)
    
    # Check 4: Challenge-response?
    results['challenge_response'] = protocol_spec.get('challenge_response', False)
    
    # Assessment
    vulnerable = (
        not results['rolling_code'] and
        not results['challenge_response'] and
        not results['timestamp']
    )
    results['replay_vulnerable'] = vulnerable
    
    return results

# ISM433-MYSTERY protocol spec
ism_spec = {
    'auth': None,
    'rolling_code': False,
    'sequence_number': False,
    'sequence_window': 0,
    'timestamp': False,
    'challenge_response': False,
    'encryption': False,
}

analysis = analyze_replay_feasibility(ism_spec)
print("Replay Attack Feasibility Analysis:")
print(f"  Rolling code present: {analysis['rolling_code']}")
print(f"  Challenge-response: {analysis['challenge_response']}")
print(f"  Timestamp present: {analysis['timestamp']}")
print(f"  Replay vulnerable: {analysis['replay_vulnerable']}")
print()
if analysis['replay_vulnerable']:
    print("VERDICT: VULNERABLE to replay attack.")
    print("Required: HackRF One + captured IQ file + authorized engagement.")
else:
    print("VERDICT: Replay protection present. Further analysis required.")

A.3 Bit-Flip Injection Feasibility

A bit-flip injection modifies bits in the payload while keeping the preamble and sync word intact. The critical question is whether the CRC will reject the modified frame:

def test_bitflip_injection(original_bytes: bytes, flip_position: int) -> dict:
    """
    Test whether a bit-flip injection passes the CRC check.
    
    Args:
        original_bytes: original frame bytes (payload + checksum)
        flip_position: which bit to flip (0 = MSB of byte 0)
    
    Returns:
        dict with original checksum, modified checksum, and detection verdict.
    """
    import crcmod
    
    # Separate payload and checksum
    payload = original_bytes[:-1]
    original_checksum = original_bytes[-1]
    
    # Create modified payload with flipped bit
    modified_payload = bytearray(payload)
    byte_idx = flip_position // 8
    bit_idx = 7 - (flip_position % 8)
    if byte_idx < len(modified_payload):
        modified_payload[byte_idx] ^= (1 << bit_idx)
    
    # Compute checksum of modified payload
    crc_fn = crcmod.mkCrcFun(0x131, initCrc=0x00, rev=True, xorOut=0x00)
    modified_checksum = crc_fn(bytes(modified_payload))
    
    detected = (modified_checksum != original_checksum)
    
    return {
        'original_payload': payload.hex(),
        'modified_payload': bytes(modified_payload).hex(),
        'original_checksum': hex(original_checksum),
        'modified_checksum': hex(modified_checksum),
        'crc_detects_flip': detected,
    }

# Example: test flipping the temperature MSB (bit 14 in the 24-bit payload)
example_frame = bytes([0x3A, 0x01, 0xB2, 0xC7])  # placeholder: 3 payload bytes + CRC
result = test_bitflip_injection(example_frame, flip_position=14)
print("Bit-flip injection test (bit 14, temperature MSB):")
for k, v in result.items():
    print(f"  {k}: {v}")
print()
print("IMPLICATION: CRC-8 detects single-bit flips with probability 255/256 ≈ 99.6%.")
print("An attacker who can compute the correct CRC for a modified payload CAN inject undetected.")
print("The protocol's checksum is NOT authentication -- it is error detection only.")

Part A deliverable: The completed threat model table for all 3 attacks, the replay feasibility output, and the bit-flip injection analysis with a paragraph explaining the difference between error-detection checksum and authentication.

Part B: Defense Analysis (5 points)

For each attack in Part A, propose a protocol-level defense. Use this framework:

## Defense Analysis: ISM433-MYSTERY

---

### Defense Against Replay Attack

**Proposed defense:** [e.g., rolling code (Keeloq variant), timestamp + window, sequence number]

**Implementation cost:**
- Transmitter-side: [code changes, memory, power impact]
- Receiver-side: [window tracking, synchronized state]
- Manufacturing cost: [BOM impact, software update feasibility]

**Residual weakness:** [What the defense does NOT prevent]

**Tradeoff rating:** Low / Medium / High complexity; Low / Medium / High power cost

---

### Defense Against Bit-Flip Injection

**Proposed defense:** [e.g., authenticated encryption (AES-128-CCM), HMAC, challenge-response]

**Implementation cost:**
[same framework]

**Residual weakness:**
[same framework]

---

### Defense Against Jamming

**Note:** Jamming is not a protocol-level attack -- the fix is at the physical layer (FHSS, DSSS) or operational security (frequency agility, diversity). A protocol-level change cannot address jamming.

**Proposed physical-layer defense:** [e.g., frequency hopping, direct sequence spreading]

**Cost:** [estimate of BOM and firmware impact]

Part B deliverable: Complete the defense analysis template above. Your recommendations should be grounded in the protocol spec and realistic for a battery-powered ISM-band sensor. A defense that requires a 50 MHz ARM processor and WPA3 is not a useful recommendation for this class of device.

Part C: Rules of Engagement Document (4 points)

Write a 200-250 word ROE document for a hypothetical authorized RF PT engagement against a client's sensor network using the ISM433-MYSTERY protocol. The client is a logistics company that uses 200 of these sensors in their warehouse.

Your ROE document must cover:

1. Authorization scope: what actions are authorized and by whom
2. Recording requirements: what must be logged during the engagement
3. Active vs. passive boundary: what requires the shielded lab; what can be done in-situ
4. Collateral risk statement: what neighboring devices might be affected and how to mitigate
5. Disclosure obligation: what you commit to report and when

Template structure (do NOT use this verbatim -- write your own):

## Rules of Engagement: [Client Name] Sensor Network RF PT

**Engagement date:** [date range]  
**Authorized by:** [client representative + title]  
**Scope document reference:** [document number]

### Authorized Actions

[List specific authorized activities: passive capture, ...]

### Prohibited Actions

[List specifically excluded actions: jamming, ...]

### Recording Requirements

[What must be logged: timestamps, IQ file hashes, ...]

### Active Transmission Boundary

[Under what conditions active TX is authorized: shielded enclosure only, specific frequencies, max power level, ...]

### Collateral Risk Acknowledgment

[Neighboring 433 MHz devices, potential interference range, mitigation, ...]

### Responsible Disclosure

[Timeline, what gets reported, who receives the report, ...]

Part C deliverable: Your original 200-250 word ROE document. It will be graded on completeness of coverage (all 5 elements present), specificity (not generic -- tailored to the ISM433-MYSTERY protocol and the warehouse scenario), and realism (would a professional sign this?).

Lab Report

Create lab-10-report.md with:

1. Completed threat model table (Part A)
2. Replay feasibility output with explanatory paragraph
3. Bit-flip injection analysis and CRC-vs-authentication distinction
4. Defense analysis (Part B) -- all three defenses covered
5. ROE document (Part C)

Grading