RF-301 Week 11b — RF Penetration Testing Cross-Cut

"The Jeep had a cellular modem. The cellular modem ran an IP stack. The IP stack reached the UConnect infotainment head unit. The head unit had a CAN bus bridge. Miller and Valasek drove the Jeep into a ditch -- over a cellular connection -- from a laptop in St. Louis. The entry point was radio frequency." -- describing the 2015 Miller/Valasek disclosure; Wired, "Hackers Remotely Kill a Jeep on the Highway"

Lecture (90 min)

10.1 RF as an Attack Surface

The Miller/Valasek Jeep attack used a cellular modem (LTE) as the initial RF entry point -- not the 433 MHz sensor band the SIGINT labs have focused on. But the structure is the same: RF provides a remote attack surface that a network-architecture-only threat model misses entirely. The attacker does not need physical access; they need radio frequency access.

RF penetration testing (RF PT) is the practice of systematically enumerating and exercising the RF attack surface of a target system under an authorized engagement. It is distinct from the passive SIGINT work in Weeks 7-9 in one crucial way: RF PT can include active transmission. That distinction changes everything about the rules of engagement, the tooling, the legal authorization required, and the responsible disclosure process.

10.2 RF PT Scope and Rules of Engagement

How RF PT differs from network PT:

FCC authorization framework for RF PT:

• Part 15 (unlicensed): 433 MHz ISM, 2.4 GHz WiFi/BLE/Zigbee bands. Active transmission permitted within power and duty cycle limits. Passive capture always permitted.
• Part 97 (amateur): licensed amateurs may transmit on amateur bands for authorized experimentation. RF PT in amateur spectrum requires amateur license; commercial purposes are excluded.
• Experimental license: STA (Special Temporary Authorization) from FCC for out-of-band work. Requires application; rarely needed for typical RF PT engagements.

Practical scope boundary: In most RF PT engagements, the authorization covers passive capture and analysis (always permitted) and active transmission in an RF-shielded enclosure or a controlled environment where third-party devices cannot receive the transmitted signals. Active over-the-air transmission against client systems requires explicit written authorization identifying the specific frequencies, power levels, and locations authorized.

10.3 RF Reconnaissance Methodology

Passive capture survey. Before any active work, perform a passive spectrum survey (Stage 1 from Week 7) against the target environment. Document every RF emission from the target system: frequencies, modulations, duty cycles, apparent protocol families.

def rf_recon_survey(iq_file: str, fs: float, fc: float, duration: float) -> dict:
    """
    Passive RF recon: enumerate all signals in the captured spectrum.
    Returns dict of signals found: frequency, bandwidth, modulation hypothesis, power.
    """
    iq = np.fromfile(iq_file, dtype=np.complex64)
    
    # Stage 1: spectrum survey
    f, psd = welch(iq, fs=fs, nperseg=4096, return_onesided=False)
    f_centered = np.fft.fftshift(f) + fc
    psd_centered = np.fft.fftshift(psd)
    
    # Find signal peaks
    from scipy.signal import find_peaks
    psd_db = 10 * np.log10(psd_centered + 1e-12)
    noise_floor = np.percentile(psd_db, 10)
    peaks, props = find_peaks(psd_db, height=noise_floor + 10, width=5)
    
    signals = []
    for peak in peaks:
        # Estimate bandwidth at -3 dB
        peak_power = psd_db[peak]
        bw_indices = np.where(psd_db > peak_power - 3)[0]
        bw = (f_centered[bw_indices[-1]] - f_centered[bw_indices[0]])
        
        signals.append({
            "center_freq_MHz": f_centered[peak] / 1e6,
            "bandwidth_kHz": bw / 1e3,
            "peak_power_dBm": peak_power,
        })
    
    return {"signals": signals, "noise_floor_dBm": noise_floor}

Signal attribution. After enumerating the RF emissions, attribute each emission to a device or function: is this the vehicle's TPMS? The key fob receiver? The Bluetooth headunit? Attribution uses a combination of timing correlation (the signal appears when a known event occurs), frequency match to known protocols (433.92 MHz is nearly universal for European/Asian TPMS), and physical orientation (directional antenna sweep identifies the transmitter location).

10.4 Protocol-Level Attacks vs Physical-Layer Attacks

The replay attack. The simplest active RF attack: record a message the target device emitted, then retransmit it. A garage door opener with no rolling code (fixed code OOK remote) is fully vulnerable to replay: record the button press once, retransmit at will. The attack requires:

1. A receive chain (Lab 7's capture pipeline)
2. A transmit chain (RTL-SDR cannot transmit; HackRF One or LimeSDR can)
3. The captured IQ file from the legitimate transmission

def replay_attack_demo(iq_file: str, hackrf_freq_mhz: float):
    """
    Replay attack demonstration using HackRF One (requires HackRF installed).
    AUTHORIZATION: Run only in RF-shielded lab against explicitly authorized devices.
    """
    # Load captured IQ
    iq = np.fromfile(iq_file, dtype=np.complex64)
    
    # Transmit via HackRF
    # hackrf_transfer -t <iq_file> -f <freq_hz> -s <sample_rate> -x <tx_gain>
    import subprocess
    cmd = [
        "hackrf_transfer",
        "-t", iq_file,
        "-f", str(int(hackrf_freq_mhz * 1e6)),
        "-s", "2000000",  # 2 MSPS
        "-x", "20",       # TX gain (dBm; adjust per lab rules)
    ]
    # NOTE: This command transmits RF. Only run in authorized lab environment.
    print(f"Would run: {' '.join(cmd)}")
    print("Requires: RF-shielded enclosure, explicit authorization, HackRF hardware.")

10.5 Rolling Code Analysis

Rolling codes (Keeloq is the most studied implementation) address the replay vulnerability: each button press produces a different transmitted code. The receiver maintains a window of valid next codes; a replayed code from outside the window is rejected.

Why rolling codes are not equivalent to cryptographic security:

• Keeloq break (2007-2008, Bono/Green/Ju/Rubin/Stubblefield/Courtois/Meier/Lafitte): the Keeloq algorithm uses a 64-bit key derived from the manufacturer's key and the device serial number. Several attacks were published:

  • Side-channel attack (DPA): measure power consumption during the ASIC's decryption; recover the key in 65 minutes
  • Algebraic attack: recover the manufacturer's key from 65,536 rolling codes in <1 day
  • Relay attack: not an attack on the algorithm but on the protocol; two attackers relay the signal from a legitimate keyfob at extended range, defeating the distance assumption

• The practical implication: rolling codes prevent naive replay (the 2015 Moshe Schwartz "RollJam" research); they do not provide cryptographic security in the presence of an attacker who can observe many transmissions or use a side channel.

What this means for an RF PT engagement: rolling code analysis belongs to the passive capture phase. Demonstrate that the algorithm is vulnerable in principle (cite the published breaks); do not retransmit during a passive engagement. An active test of a specific system's key would require:

1. Authorized target (the client's specific system)
2. RF-shielded environment
3. A break methodology appropriate to the specific algorithm variant

10.6 RF Defense Measures

10.7 Responsible Disclosure for RF Vulnerabilities

RF vulnerabilities differ from software vulnerabilities in several ways that affect the disclosure process:

• No CVE equivalent. The CVE (Common Vulnerabilities and Exposures) system covers software and firmware. A vulnerability in a proprietary RF protocol has no standard identifier.
• Physical-layer vulnerabilities persist across firmware updates. If the Keeloq algorithm is embedded in an ASIC, a firmware update cannot fix it.
• Vendor reach is harder. A manufacturer of 433 MHz OOK sensors may not have a security team, a bug bounty program, or a product security contact.

Disclosure procedure for RF findings:

1. Document the finding formally: protocol spec + attack methodology + proof of concept + impact assessment (what an attacker can do in practice, not just in the lab)
2. Identify the vendor's general contact (sales/support if no security team)
3. Allow 90 days from first contact before public disclosure (CERT/CC standard)
4. If the vendor is unresponsive after 90 days, consult with a security-focused attorney before disclosing publicly -- RF vulnerabilities may affect safety systems, and the disclosure analysis is more complex than a typical software CVE

10.8 Architecture Comparison Sidebar

The key observation for this course. The Miller/Valasek attack started at the most protected layer in this table (LTE) -- but exploited a software vulnerability in the head unit after gaining network access. RF was the entry medium; the vulnerability was in the IP stack above. RF PT must address both the RF access surface and what is reachable from it.

Lab Preview

Lab 10 applies the rules of engagement framework and the protocol attack-surface analysis methodology to the Lab 9 protocol spec. See labs/lab-10.md.

Toolchain Diary Prompt

New this week: hackrf_transfer (TX chain, theoretical only unless you have authorized lab access). Compare this week's RF PT framework to network PT methodology you may know from other courses. Where does the RF PT authorization process add constraints that network PT does not have? Where does it remove constraints (e.g., no "scan detection" equivalent at the RF layer)?