The benign legal footing of passively recording your own connection, the ethics of carrying and reporting, OPSEC of the detector itself, a laminate-ready field card, and an A–Z glossary

10.1 About this Volume

This volume closes the dive with the non-technical half of operating a detector responsibly: the legal footing (which is benign, and worth understanding why it is benign), the ethics of carrying one and of what to do with a warning, and the operational security of the instrument itself — which, being a cellular device that travels and records, carries its own small risks. It ends with the two reference artifacts the dive has been building toward: a laminate-ready field card and an A–Z glossary of the terms used across all ten volumes.

Nothing here is legal advice. Laws differ by country and change over time; EFF’s own documentation carries a disclaimer to that effect and recommends that people outside the United States consult a local attorney. The aim of this volume is to give an operator an accurate mental model and the right habits — not a ruling.

10.2 The legal footing: passive observation of your own connection

Rayhunter’s legal posture is clean for a simple structural reason: it only observes the network traffic its own device is already a party to, and it transmits nothing beyond what any hotspot transmits to register on the network. It does not intercept anyone else’s communications, does not transmit on licensed spectrum beyond ordinary network registration, and does not emulate a base station. It is a passive log of the operator’s own modem’s control plane.

The three facts that keep it benign:

Receive-only in substance. The only radio transmission is the normal registration/attachment a hotspot performs to use the network — the same thing a phone does. There is no attack transmitter, no fake-base-station emission, no jamming. (Volumes 6–8 describe only observing and reading; no transmit behaviour exists to describe.)
Your own traffic. The recorded control plane is the signalling between the operator’s device and the network it chose to join. Recording the signalling your own device exchanges is categorically different from intercepting a third party’s communications.
Control plane, not content. It records signalling, not calls, texts, or data payloads (Vol 8 §2) — so there is no user-communication content being captured at all.

Caveat, honestly stated. “Benign in substance” is not the same as “identical everywhere in law.” Radio, privacy, and surveillance law vary by jurisdiction. EFF’s docs explicitly tell non-US users to consult a local attorney, and that advice is repeated here. The structural argument above is why the tool is designed to be lawful to use; it is not a guarantee for every jurisdiction.

10.3 Ethics of carrying and reporting

The tool is defensive, and using it ethically is mostly about keeping expectations and claims honest.

It is for noticing, not accusing. A warning is signal, not proof (Vol 7 §6). Publicly declaring “there is a Stingray here” on the strength of a single heuristic warning is both factually unjustified and potentially harmful — it can spread alarm, misdirect attention, and discredit the tool when the warning turns out to be a false positive. State only what the recording actually supports — that the detector flagged behaviour associated with a cell-site simulator at a specific time and place — and let experts weigh in on ambiguous data.
Report responsibly. A genuinely suspicious recording is worth sharing — with EFF, with the project community, or with a cellular-security expert who can assess it (Vol 8 §9). Responsible reporting improves the analyzers and builds the kind of dataset that makes everyone’s warnings more interpretable. Sensational reporting does the opposite.
Respect others’ privacy. A recording is a log of where the operator’s device was. If it is ever shared, share the control-plane artifact relevant to the question, not an unnecessary trail of the operator’s (or anyone else’s) movements.
Don’t oversell it to people who rely on you. Telling an at-risk colleague that a Rayhunter “keeps you safe” is a disservice; it tells you when something is suspicious (Vol 9 §9). Frame it accurately so their decisions rest on what it actually does.

10.4 OPSEC of the detector itself

The detector is an instrument, and treating it as one is the core OPSEC rule. It travels, it records, and it is a cellular device — each of which creates a small exposure worth managing.

Table 1 — 4. OPSEC of the detector itself

Concern	Practice
Don’t route real sensitive traffic through it	The Rayhunter hotspot is a sensor, not a secure gateway. Keep sensitive comms on a separate, trusted path (e.g. a GL-iNet travel router for data); treat the Rayhunter device as instrumentation only
The recordings are sensitive	Each recording logs where the device was and the control plane it saw. Export what you need, archive it securely off-device, then clear the device (Vol 7 §8). The less history on a device that could be lost or inspected, the better
Firmware drift via the carrier	Keep the flashed device off the carrier’s OTA path where practical — a carrier update can close the rootable firmware the install relied on (Vol 6 §2)
The device advertises itself	A loud UI Level (High-visibility / Demo) is for demos, not discretion. In a setting where carrying a detector is itself sensitive, use Invisible/Subtle and lean on ntfy notifications (Vol 6 §8)
Physical loss / seizure	A cleared device with no stored recordings exposes far less than one holding weeks of trips. Clear between trips; keep the archive elsewhere
It looks unusual	A flashed hotspot with a coloured status line can draw questions (§5). Be ready to explain it plainly

The one-line OPSEC summary. Rayhunter is the smoke detector, not the fire door. It tells you something may be wrong; it does not protect the traffic you care about. Protect that traffic separately, and treat the detector — and its recordings — as the sensitive instrument it is.

10.5 Crossing borders and explaining the device

A flashed hotspot is, physically, an ordinary cheap mobile hotspot — but one running custom firmware with a visible coloured status line, which can invite questions at security checkpoints or borders. Two sensible preparations:

Be able to explain it plainly. It is an open-source tool from the Electronic Frontier Foundation that passively checks whether the cellular network is behaving normally; it does not transmit attacks and does not intercept anyone else’s communications (§2). A calm, accurate one-sentence explanation defuses most confusion.
Mind the recordings crossing a border. Border inspection regimes vary and can include device searches. A device cleared of recordings before a crossing (Vol 7 §8) carries less to inspect. This is a judgement call tied to the operator’s own threat model and jurisdiction, and — like §2 — it is a place where local legal advice beats a generic rule.

Discretion setting matters here. If a border or checkpoint is part of the trip, the UI Level chosen in Vol 6 §8 is a real decision: a full-screen coloured status is conspicuous. Set it before you travel, not at the checkpoint.

10.6 The field cheatsheet (laminate-ready)

RAYHUNTER — FIELD CARD

WHAT IT IS — Passive IMSI-catcher detector. Records your own modem’s control plane. No attack, no transmit beyond normal registration. A warning is SIGNAL, not PROOF.

POWER-ON ORDER

Turn on in a known-clean place → green line (blue if Colorblind Mode).

Confirm web UI loads: http://<device>:8080 (Orbic 192.168.1.1, TP-Link 192.168.0.1).

Clear old recordings; start a fresh recording. Then travel.

THE STATUS LINE green/blue running, clean · yellow dots low · orange dashes higher · solid red high. Alert persists until reboot / new recording / power double-tap (if enabled).

ON A WARNING (signal, not proof → shift posture) • Open web UI → which analyzer, what severity. • Pause sensitive cellular calls/messages. • Note where / when / which analyzer. Keep the recording (don’t delete). • Leave the area if warranted. • Do not declare “a Stingray is here” — say what the data supports.

DEVICE QUIRKS • TMOHS1 / CT2MHS01: Wi-Fi AP sleeps ~10 min idle — detector still records; wake device to reach UI. • Keep device off carrier OTA after flashing (firmware drift can close root).

AFTER A TRIP — Download keepers (QMDL + PCAP) → review (Wireshark) → delete from device.

OPSEC — Don’t route sensitive traffic through it. It’s a sensor, not a secure gateway. Clear recordings between trips.

HELP — efforg.github.io/rayhunter · github.com/EFForg/rayhunter

10.7 A–Z glossary

Terms used across Volumes 1–10, defined at the plain, category level this dive maintains.

Table 2 — 7. A–Z glossary

Term	Meaning
2G downgrade	A base station pushing a device from LTE down to 2G, where communications are easier to intercept; one behaviour a cell-site simulator can induce, watched by a Rayhunter analyzer
ADB (Android Debug Bridge)	A host tool used to reach an Orbic over USB — port-forwarding `8080` exposes the web UI and download endpoint locally
Analyzer	A Rayhunter heuristic that inspects the recorded control plane and raises a warning when it matches a pattern associated with a cell-site simulator (Vol 5)
Attachment	A device joining and registering with a cell; Rayhunter observes what its modem experiences after attachment (a structural limit — Vol 9 §9)
Baseband / modem	The cellular radio subsystem of a device; its diagnostic stream is what Rayhunter records
Baseline	The known-clean reference the operator establishes before relying on the detector (Vol 7 §3)
Cell ID / eNB	Identifier of a specific cell / LTE base station; used to cross-check a serving cell against a tower database (Vol 8 §5)
Cell-site simulator (CSS)	A fake base station that induces nearby devices to connect to it; also called an IMSI catcher or Stingray. Rayhunter detects; it never emulates one
Cell reselection	A device moving between cells per the network’s broadcast priorities; manipulated priorities (e.g. ranking 2G above LTE) are a downgrade signal
Control plane	The signalling between a device and the network (identity, security, system information, connection setup/release) — Rayhunter’s subject. Not call/text/data content
DIAG	Qualcomm’s modem diagnostic interface; the source of the stream Rayhunter records
Downgrade	Forcing a device onto an older, weaker radio technology (see 2G downgrade)
EEA0 / null cipher	The “no encryption” cipher option at the RRC or NAS layer; should almost never appear outside test labs. A null-cipher suggestion is a Rayhunter warning
Heuristic	A rule that flags a likely-but-not-certain condition; Rayhunter’s analyzers are heuristic, so warnings are signal, not proof
Hotspot	A small device that provides a cellular data connection; Rayhunter runs on cheap Qualcomm-modem hotspots
IMEI	A device’s hardware identity; requested alongside IMSI in some suspicious patterns
IMSI	The subscriber’s permanent SIM identity; an unauthenticated request for it is a classic cell-site-simulator tell (the IMSI Requested analyzer)
IMSI catcher	See cell-site simulator
NAS (Non-Access Stratum)	The signalling layer carrying identity, authentication, and the security-mode command; where the IMSI-request and NAS-null-cipher patterns appear
ntfy	A notification service Rayhunter can push to on detection (Vol 6 §8)
OpenCelliD	A free, crowdsourced tower database; used to sanity-check a serving cell’s identifiers against a location (Vol 8 §5) — corroboration, not proof
PCAP	Standard packet-capture format; Rayhunter exports the recorded control plane as PCAP for Wireshark (Vol 8 §2)
QMDL	Qualcomm MoDem Log — the native, lossless recording of the DIAG stream; the original to archive and to re-analyze (Vol 8 §2, §8)
RRC (Radio Resource Control)	The LTE layer carrying SIBs, connection setup, and release/redirect; where downgrade and RRC-null-cipher patterns appear
Rooting	Gaining the privileged shell the installer needs; device- and firmware-specific, documented per-device by EFF (Vol 6 §2)
SIB (System Information Block)	Broadcast messages a tower sends; an incomplete SIB schedule, or SIB6/7 ranking 2G/3G above LTE, are downgrade/anomaly signals
Serving cell	The cell a device is currently attached to; its identifiers (MCC/MNC/TAC/Cell ID) are what a tower-database lookup checks
Severity ladder	Rayhunter’s status escalation: green/blue → yellow dots → orange dashes → solid red (Vol 7 §5)
Stingray	A common brand-name-turned-genericism for a cell-site simulator
TAC / LAC	Tracking / location area code — a serving-cell identifier used in tower cross-checks
tshark	Wireshark’s command-line companion; used in the host-side summary workflow (Vol 8 §7)
TMSI	A temporary subscriber identity the network assigns to avoid broadcasting the permanent IMSI; a network repeatedly forcing use of the permanent IMSI instead is part of what makes an IMSI request suspicious
Warning	A fired analyzer surfaced on the status line and in the web UI — signal, not proof; the correct response is a posture shift (Vol 7 §6)
WebDAV	An optional upload target Rayhunter can push recordings to on a schedule (Vol 6 §8)
Wi-Fi-client mode	A mode where the hotspot joins an existing network instead of only serving its own, easing web-UI access (Vol 6 §9) — Orbic/Moxee/UZ801/TMOHS1/Wingtech
Wireshark	The standard packet analyzer used to review the exported PCAP’s control plane (Vol 8 §4)

10.8 Further reading — the canonical sources

The authoritative references for everything in this dive. For anything version-sensitive — supported devices, install steps, analyzer behaviour — these are the sources of truth, not this dive.

EFF Rayhunter documentation — efforg.github.io/rayhunter — installation, supported devices, usage, heuristics, and configuration.
Rayhunter source and releases — github.com/EFForg/rayhunter — the code, the default config.toml, the per-device install guides, and the issue/community links.
EFF Rayhunter announcement — eff.org/rayhunter — project background, goals, and the broader context on IMSI catchers.
EFF Surveillance Self-Defense — cell-site simulators / IMSI catchers — plain-language background on the threat Rayhunter addresses.
Project community — the Mattermost channel linked from the EFF docs — for support, feedback, and contributing.

Re-verify before relying. Rayhunter is actively developed; supported-device lists, analyzer sets, and install details change between releases. Treat every specific claim in this dive as dated to its writing and confirm against the canonical sources above before acting on it in the field.

End of the Rayhunter dive. Volumes 1–5 (sibling-authored) cover what Rayhunter is, the threat it addresses, the supported hardware, the daemon architecture, and how the analyzers work; Volumes 6–10 cover installing, field use, reading the recordings, the ecosystem, and the legal/ethics/OPSEC posture with the field card and glossary.

Rayhunter Volume 10 — Legal, Ethics, OPSEC, Cheatsheet & Glossary