4.1 About this Volume

The Orbic RC400L is the device Rayhunter was first built on, the one its documentation treats as the default, and the one a first-time user in the Americas is steered toward. Understanding it in depth pays off twice: it is the most likely unit a reader will actually own, and because the other supported hotspots share its architecture (a Qualcomm modem, a small embedded Linux system, a DIAG interface, a web admin UI), understanding the Orbic is most of the way to understanding the rest.

This volume stays at the platform level — the modem, the diagnostic interface, the storage, power, and display, and a high-level account of how root is obtained. It deliberately contains no step-by-step exploit; the install mechanics belong to Volume 6, and even there the posture is “run the project’s installer,” not “here is how to write one.” The goal here is to understand what Rayhunter is talking to when it reads the control plane.

4.2 Why the Orbic is the reference device

Three properties made the Orbic RC400L the natural first target, and they still make it the recommended starting point:

• It is cheap and plentiful on the used market. A used Orbic is typically a roughly-US$30-or-less purchase. That price point is central to the whole Rayhunter thesis — a detector anyone can afford — and it is why the project optimized for this device first.
• It has a well-understood root path. The community established a reliable way to root the Orbic early, and Rayhunter’s installer automates it. The install is as close to push-button as a firmware-level operation gets.
• Its Qualcomm modem exposes exactly the DIAG interface Rayhunter needs. The RC400L is built on a Qualcomm modem (the MDM9207, an LTE Cat-4 part) whose diagnostic interface is the window through which Rayhunter sees the control plane.

A useful piece of buying trivia from Volume 3 bears repeating because it is Orbic-specific: the unit is also sold Kajeet-branded (identical hardware), and most Verizon-branded units the community has seen are actually unlocked — so a cheap carrier-branded listing is usually fine rather than a locked dead-end.

4.3 The Qualcomm MDM9207 modem

The heart of the RC400L is the Qualcomm MDM9207, an LTE Category 4 modem SoC. Category 4 places its throughput ceiling at the familiar ~150 Mbps down / ~50 Mbps up class — unremarkable as a modem, and entirely beside the point for Rayhunter, which cares about the modem’s signaling, not its data rate.

What matters for this tool is the architectural fact that the MDM9207 is a small, self-contained modem SoC running its own firmware and a lightweight embedded Linux userland around it. The modem handles the cellular protocol stack — cell selection, attachment, the RRC and NAS signaling of Volume 2 — and it exposes that activity, for engineering purposes, over a diagnostic interface. Rayhunter’s daemon runs on this same embedded system and reads that interface locally; there is no separate application processor and no Android in the way, which is part of why the device is so small and cheap.

Table 1 — 3. The Qualcomm MDM9207 modem

Property	Orbic RC400L
Modem SoC	Qualcomm MDM9207
LTE category	Cat-4 (~150/50 Mbps class)
Platform OS	Lightweight embedded Linux on the modem SoC
Market	Primarily the US / Americas (band-matched)
Form factor	Pocket mobile hotspot with a small display
Rayhunter-relevant feature	Qualcomm DIAG diagnostic interface

Note. The EFF’s Orbic device page advertises a broad set of bands; for Rayhunter the load-bearing facts are the MDM9207 modem and its DIAG interface, not the throughput class. Band coverage matters only insofar as the unit must be able to see the networks in its region (Volume 3 §7).

4.4 The DIAG / QMI interface Rayhunter rides

This is the most important section in the volume, because the DIAG interface is the whole mechanism of the tool.

Qualcomm modems expose two related host-facing interfaces that recur throughout Rayhunter’s world:

• QMI (Qualcomm MSM Interface) — the control/management interface used to operate the modem (bring it up, configure it, query status). It is how the embedded system normally drives the modem.
• DIAG (Diagnostic) — the engineering/diagnostic firehose. Over DIAG, a privileged host can subscribe to a stream of the modem’s internal log events, including the raw control-plane messages it is exchanging with the tower. This is what Rayhunter reads.

Rayhunter’s relationship to these is strictly one-directional for detection: it reads the DIAG stream. It subscribes to the diagnostic events, captures them continuously to storage, and runs its analyzers over them. It does not use DIAG to inject signaling or alter the modem’s behavior — consistent with the defensive-only posture of Volume 1. The diagnostic log Rayhunter records is in Qualcomm’s QMDL format, which is exactly why QMDL is one of the export formats a user can pull off the device (the other being PCAP, produced for analysis in standard packet tools). Volume 5 details the capture-and-analyze pipeline; the point here is simply that DIAG is the tap and QMDL is what comes off it.

   ┌──────────────────────── Orbic RC400L ─────────────────────────┐
   │                                                                │
   │   cellular   ┌───────────────┐   QMI  (control / manage)       │
   │  ◀────────▶  │  MDM9207      │ ───────────────────────────▶    │
   │   air i/f    │  modem        │                                 │
   │              │               │   DIAG (diagnostic firehose)    │
   │              └──────┬────────┘ ───────────────────────────▶    │
   │                     │                        │                 │
   │                     ▼                        ▼                 │
   │              embedded Linux          ┌───────────────┐         │
   │              userland                │  Rayhunter     │         │
   │                                      │  daemon: reads │         │
   │                                      │  DIAG → QMDL,  │         │
   │                                      │  analyzes      │         │
   │                                      └───────┬────────┘         │
   │                                              │ web UI :8080     │
   └──────────────────────────────────────────────┼─────────────────┘
                                                   ▼
                                       browser over Wi-Fi / USB-forward

4.5 Storage, display and battery

The Orbic is a self-contained appliance, and three physical subsystems matter to how Rayhunter is used day to day.

Storage. The device has onboard storage where Rayhunter writes its QMDL recordings; unlike the TP-Link units (which require a FAT-formatted microSD for recordings, per Volume 3), the Orbic does not depend on a card to capture. A recording accumulates while the device is on, and the web UI is where recordings are listed, reviewed, downloaded, and deleted. Because a QMDL/export file “may contain sensitive information such as your IMSI,” storage and the exported files are themselves data to handle with care — a point Volume 7 returns to.

Display. The RC400L has a small screen. Rayhunter’s primary on-device signal is a colored line across the top of that display: green while running and recording, and changing to yellow dots, orange dashes, or solid red when an analyzer raises an alert, graded by severity. The line is the whole on-device UX — it is deliberately glanceable, so a non-expert can be told “if the line is not green, look at the web UI.” The line stays in its alerted state until the device reboots or a new recording is started.

Battery. The unit is a battery-powered pocket hotspot with a removable battery in the reference design. For Rayhunter that means it can run untethered as a carry-along watcher, within the limits of its battery; for continuous deployment it can also run on USB power. The practical operating choice — pocket-passive versus powered-stationary — is an operational-posture question (Volume 10), not a capability one.

4.6 Connectivity: USB, Wi-Fi, and Wi-Fi client mode

The Orbic reaches the outside world three ways, and each maps to a way of using Rayhunter.

• Wi-Fi (hotspot). The device’s own access point. A phone or laptop joins it and reaches the Rayhunter web UI at http://192.168.1.1:8080. This is the normal field path.
• USB. Over USB the web UI can be reached by forwarding the port (adb forward tcp:8080 tcp:8080, then http://localhost:8080). USB is also the normal transport for the installer.
• Wi-Fi client mode. The Orbic can run its hotspot and simultaneously join an existing Wi-Fi network — the feature noted in Volume 3 for the Orbic, Moxee, UZ801, TMOHS1, and Wingtech. In client mode the UI is reached at the device’s address on that network (http://<device-ip>:8080). This is what makes the Orbic sit cleanly beside the GL-iNet GL-BE3600 travel router: the Orbic can join the travel router’s network as a client while still serving as a detector, so the whole kit shares one local network.

Tip. For a stationary “always-watching” deployment, Wi-Fi client mode plus USB power turns the Orbic into a headless sensor reachable from the rest of the local network — no need to keep a client joined to its own AP just to see the UI.

4.7 How root is obtained — at a high level

Rayhunter needs root on the device so its daemon can read the DIAG interface. The account here is deliberately at the “what happens,” not “how to do it yourself,” level — the practical path for a user is simply to run the project’s installer (Volume 6).

At a high level:

1. The user connects a computer to the Orbic over USB (or Wi-Fi), reaching the device’s admin interface.
2. The project’s installer binary authenticates to the device’s admin interface using the admin credentials (on the Orbic, the default admin password is the Wi-Fi password; Kajeet/Smartspot units differ from Verizon ones).
3. The installer uses an established technique to obtain privileged execution on the embedded Linux system — the “rooting” step. On the Orbic this is well-trodden and automated; the installer handles it.
4. With privilege obtained, the installer places the Rayhunter daemon on the device so that it starts automatically, reads the DIAG stream, records QMDL, runs the analyzers, and serves the web UI on port 8080.
5. The device reboots, and from then on Rayhunter runs on its own whenever the device is powered.

A couple of device-level specifics are worth knowing because they surface in normal use. The default install does not leave a general root shell or ADB exposed; a shell can be obtained on demand through the installer’s utility path when needed (older or USB-variant installers behaved differently and exposed ADB and a fakeroot path). And the admin-password detail matters: resetting it on the Orbic is a physical action — hold the button under the back cover until the unit restarts.

Posture. The rooting step is what makes the whole passive detector possible, and it is also the reason the hardware list is so specific (Volume 3): root is firmware- and revision-dependent. Nothing in this step adds a transmit or offensive capability — it grants read access to a diagnostic port, nothing more.

4.8 Living with the device: OTA risk and the admin password

Two ownership habits keep an Orbic Rayhunter unit healthy, both introduced in Volume 3 and grounded here in the platform.

Keep it off the carrier network after flashing. A carrier OTA firmware push can move the device onto a revision that disturbs or closes the Rayhunter install. The practical rule is that the Rayhunter-flashed Orbic is a detector, not a daily data modem — it should not be the device whose SIM is live on a carrier that might push updates. For an active data path, the hub’s GL-iNet GL-BE3600 is the right tool; the Orbic watches while the travel router carries traffic. (Rayhunter can still detect with an inactive SIM, so keeping it off a carrier does not blind it.)

Know the admin credentials and the reset. The Orbic’s admin password defaults to its Wi-Fi password (and differs on Kajeet/Smartspot versus Verizon units). The installer needs it, and the web UI uses the same credentials. If it is ever lost, the physical reset — holding the button under the back cover until the unit restarts — returns it to defaults.

With the reference device understood from modem to display, the next volume turns to the software: the Rust daemon’s architecture, the QMDL/DIAG capture pipeline, the analyzer model category by category, the warning UX, the sources of false positives, and the honest framing that holds the whole tool together — detection, not prevention; signal, not proof.

Platform facts reflect the public Rayhunter documentation and the Orbic RC400L’s published specifications as of 2026-10-17. The rooting account is intentionally high-level; the supported, automated install path is the project’s own installer, covered in Volume 6.