5.1 About this Volume

This is the volume that explains what Rayhunter actually does once it is installed — the software architecture, the pipeline that turns a modem’s diagnostic stream into a stored recording, the bank of analyzers that judge that recording, and the user-facing warning that results. It is the conceptual core of the series: Volumes 2–4 built the threat model, the hardware, and the reference device; this volume is where they meet.

The treatment of the analyzers here is category-level and complete: every analyzer in the current release is named and its purpose explained, so a reader understands the shape of Rayhunter’s judgment. Volume 8 then revisits the same analyzers one at a time for the person triaging a live alert. The volume closes on the framing that governs how any of this output should be read — the “detection, not prevention; signal, not proof” discipline that Volume 1 introduced and that this volume finally grounds in the mechanism.

5.2 The daemon: a Rust process that reads, records, and judges

Rayhunter is, at runtime, a single long-lived daemon written in Rust, installed onto the device so it starts automatically at boot and runs whenever the device is powered. It does three things continuously:

1. Reads the modem’s DIAG diagnostic stream (Volume 4).
2. Records that stream to the device’s storage as a QMDL capture.
3. Judges the stream by running a set of analyzers over it, raising alerts when one matches.

Alongside the daemon it serves a small web UI on port 8080. The UI is the control surface — start and stop recordings, list and download and delete captures, and view the heuristic analyses the analyzers produced. There is no cloud component and no phone-home: everything runs on the device, and the analysis is local. The choice of Rust is not incidental to the project’s goals — a memory-safe systems language is a reasonable fit for a security tool that parses untrusted, adversary-influenced input (the very signaling a CSS might craft) on a small embedded system.

Note. Because the daemon runs continuously and automatically, Rayhunter’s normal state is “already recording.” The user does not start a capture to begin watching; a capture is always in progress while the device is on. Starting a new recording (from the web UI, or by double-tapping the power button on releases where that is enabled) mainly serves to segment captures and reset the alert line — see §6.

5.3 The capture pipeline: DIAG → QMDL → PCAP

The data path from the air interface to a file a user can analyze is short and worth seeing whole.

   air interface          modem               daemon                 outputs
   ─────────────          ─────               ──────                 ───────
   control-plane   ──▶  MDM9207  ──DIAG──▶  Rayhunter  ──record──▶  QMDL file
   signaling            (produces            daemon                 (on-device
                         DIAG events)          │                     storage)
                                               │  analyze
                                               ▼
                                         analyzer bank ──▶  alerts + line state
                                               │
                                               └──export──▶  PCAP (for Wireshark
                                                             & standard tools)

• DIAG is the live tap — the modem’s diagnostic firehose (Volume 4).
• QMDL is the recorded form. Qualcomm’s diagnostic-log format is what Rayhunter writes to storage as the native capture; it is the lossless record of what the modem surfaced, and it is one of the two things a user can pull off the device.
• PCAP is the analysis-friendly export. Rayhunter can render captures into standard packet-capture form so they can be opened in Wireshark and the usual tooling, which is how deeper post-hoc analysis is done off-device.

The web UI is where a capture is reviewed and exported; the EFF’s own documentation notes that an exported file “may contain sensitive information such as your IMSI,” so a QMDL or PCAP export is itself sensitive data (Volume 7 treats the handling discipline). The important architectural point is that the recording is lossless and the analysis runs over it — so a capture that produced no live alert can still be re-examined later, and a capture that did alert carries the full underlying signaling for a human (or Wireshark) to inspect.

5.4 The analyzer model

Rayhunter’s judgment is a bank of independent analyzers (heuristics), each watching the recorded stream for one characteristic pattern and each raising its own alert when it matches. This modular design is deliberate and has three consequences worth understanding:

• Each analyzer is a narrow, named rule. One looks for a suspicious identity-request sequence, another for a 2G-downgrade redirect, another for a null cipher, and so on. They are individually simple and individually fallible.
• Some are informational, some are graded alerts, and some are off by default. Not every analyzer is a “something is wrong” signal — one is purely diagnostic, and a couple are disabled by default because they are experimental or deliberately noisy.
• Combinations matter more than components. The design explicitly treats certain co-occurrences as stronger than their parts — most notably, an incomplete-system-information condition that is weak on its own becomes a strong indicator when it appears alongside the suspicious identity-request pattern. This mirrors the threat model of Volume 2 §5: the strongest evidence is a choreography, not a single message.

The analyzer set evolves release to release — analyzers are versioned (there are, for example, a “v2” and a “v3” iteration of specific heuristics as they are refined), and the defaults around which ones are on have changed. The catalogue in §5 is the current set as of 2026-10-17; the versioning is itself a signal of how actively the heuristics are being tuned against real-world false positives.

5.5 The analyzers, by category

The following is the full current analyzer bank. Each entry names the analyzer, states the control-plane behavior it flags (grounded in Volumes 2’s threat model), and notes its false-positive character where the project documents one.

Table 1 — 5. The analyzers, by category

Analyzer	What it flags	Notes / false-positive character
IMSI Requested (v3)	The suspicious choreography of connecting to a new tower, the tower requesting the IMSI/IMEI, no authentication, then a disconnect — plus identity requests that come after auth, without a prior connection, or without authentication shortly after	The flagship analyzer, directly targeting the classic identity-harvest. Known to false-positive when a plane is landing; the authors note this is still being researched. Emits diagnostic notices for identity sends under normal circumstances
Connection Release / Redirected Carrier 2G Downgrade	A base station that releases the connection and redirects the device to a 2G tower, where traffic can be intercepted	The direct “forced 2G downgrade” tell of Volume 2
LTE SIB6/7 Downgrade (v2)	LTE cells broadcasting SIB6 or SIB7 messages that give 2G/3G frequencies higher priority (steering the device to reselect down)	Malformed SIB7 is more common than SIB6; older versions false-positived, and it remains most useful where 2G is genuinely prevalent
Null Cipher	A cell suggesting the EEA0 null cipher at the RRC layer — no encryption between device and tower	Should almost never happen outside test labs or specific regulated emergency cases
NAS Null Cipher	A NAS security-mode command suggesting EEA0	”Could be indicative of an attack”; a false positive is possible if a provider intentionally uses null ciphers or is misconfigured — described as very rare
Incomplete SIB	A SIB1 that lacks timing information for at least two further SIBs (commonly SIB3/4/5)	Alone, may just be a misconfigured tower; combined with IMSI Requested it is a strong indicator of malicious activity
Diagnostic Information	Informational only — marks when the device connects to and disconnects from towers; aids PCAP analysis	Not an alert; its messages can be ignored unless a low/medium/high warning appears
No NAS Messages (disabled by default, experimental)	Warns once per recording if ≥5 minutes of diagnostic traffic show no NAS message — possibly a missing, deactivated, or misprovisioned SIM	Experimental; can false-positive when the device sees radio traffic but cannot reach a network that produces NAS traffic
Test Analyzer (disabled by default)	Alerts whenever a tower’s SIB1 is seen	Deliberately very noisy; exists only to confirm Rayhunter is working — turn it off after testing

Two structural observations tie the catalogue back to the threat model. First, the bank maps cleanly onto Volume 2 §5’s list of CSS behaviors: identity harvest (IMSI Requested), 2G downgrade (Connection Release redirect, SIB6/7 Downgrade), null cipher (Null Cipher, NAS Null Cipher), and incomplete system information (Incomplete SIB). Rayhunter detects the categories of behavior a cheap, common catcher relies on. Second, the combination logic is explicit in the catalogue — Incomplete SIB is honest about being weak alone and strong alongside IMSI Requested — which is the single most important thing to carry into triage (Volume 8).

5.6 The warning UX: the line, the severities, the web UI

Rayhunter’s output reaches the user two ways: a glanceable on-device indicator and a detailed web UI.

The line. A green line across the top of the device’s display means Rayhunter is running and recording. When an analyzer raises an alert, the line changes — to yellow dots, orange dashes, or solid red, escalating with the severity of the alert. The line stays in its alerted state until the device reboots or a new recording is started. On releases since v0.3.3 a double-tap of the power button starts a new recording (which also resets the line); that gesture is disabled by default since v0.4.0 and must be enabled in configuration. The line is intentionally the entire on-device UX — enough for a non-expert to know “not green means go look,” nothing more.

The severities. Alerts are graded low / medium / high, which is what drives the line’s escalation and what distinguishes a mild anomaly from a strong one in the UI. The purely-informational Diagnostic Information output sits below this scale — it is context, not a warning, and is only worth attention when a graded alert also appears.

The web UI. Reached at http://192.168.1.1:8080 (Orbic) or http://192.168.0.1:8080 (TP-Link) over the device’s own Wi-Fi, at http://<device-ip>:8080 in Wi-Fi client mode, or via a USB port-forward. It lists recordings, shows each capture’s analyzer results, and lets the user download (QMDL/PCAP) or delete captures. Because the device serves plain HTTP, browsers show a security warning and may block the “insecure” download — the documentation notes these warnings can be safely ignored for this local, on-device UI.

   LINE STATE          MEANING
   ──────────          ───────
   green  ─────────    running + recording, nothing flagged
   yellow · · ·        low-severity alert
   orange – – –        medium-severity alert
   red   ━━━━━━━━       high-severity alert
   (stays until reboot or a new recording is started)

5.7 Where false positives come from

A detector that never cried wolf would be ignoring real attacks; Rayhunter’s analyzers are tuned to catch the common tells, and that tuning necessarily produces false positives. Knowing the documented sources prevents overreaction:

• Legitimate-but-unusual network behavior. A misconfigured honest tower can emit an incomplete SIB1; a carrier can, rarely, run a null-cipher or an unusual configuration. The NAS Null Cipher analyzer explicitly allows that a provider intentionally using null ciphers, or a misconfiguration, can trip it.
• Environment. The SIB6/7 downgrade heuristic is more likely to fire — sometimes benignly — where 2G is genuinely prevalent, because legacy-frequency prioritization is more normal there.
• Specific physical situations. The IMSI Requested analyzer is documented to false-positive when a plane is landing — an artifact the authors are still researching.
• SIM / coverage conditions. The experimental No NAS Messages analyzer can fire when the device sees radio traffic but cannot reach a network that produces NAS traffic — a coverage artifact, not an attack.
• The test heuristic. The Test Analyzer alerts on every tower by design and is pure noise outside testing; leaving it on guarantees false alarms.

The right mental model is Volume 2’s: each analyzer is a smoke detector for one kind of smoke. A single detector going off is a prompt to look, not a conclusion. The combination logic (§4, §5) is what turns scattered smoke into a credible fire — an IMSI-request pattern and an incomplete SIB together is a materially different event from either alone.

5.8 Detection, not prevention; signal, not proof

Everything in this volume converges on the framing Volume 1 opened with, and it is worth stating once more now that the mechanism is on the table.

Rayhunter detects. The daemon reads a diagnostic stream, records it, and judges it against heuristics. At no point does it prevent anything — it cannot stop the modem from attaching to a hostile cell, cannot block an identity request, cannot refuse a downgrade. By the time the line turns red, whatever was going to happen has already happened; Rayhunter’s value is that the user now knows, and can change posture (Volume 10). It is a smoke alarm, not a sprinkler.

And its output is a signal, not proof. Every analyzer can fire on a legitimate cause — a misconfigured tower, a 2G-heavy region, a landing aircraft, an unusual-but-honest carrier configuration. The combination logic raises confidence but never reaches certainty; the DIAG stream shows behavior, never intent (Volume 2 §6). A red line means “the control plane here did something an honest network rarely does, in a pattern worth investigating.” It does not mean “you were surveilled,” and treating it as if it did is the single most common misuse of the tool. The project’s own candor about this — versioned heuristics, documented false positives, severity grading, informational-only analyzers — is exactly what makes a signal from it worth taking seriously.

The next volume turns from how it works to how to get it working — the installer binary, the per-device install commands, reaching the web UI for the first time, and confirming the running line — before Volumes 7 and 8 cover day-to-day operation and the discipline of reading the warnings.

Facts in this volume reflect the public Rayhunter documentation and source as of 2026-10-17. The analyzer catalogue is the current set and is versioned upstream; default-on/off behavior and heuristic versions change across releases and should be re-checked against the live docs before relying on any specific analyzer.