Rayhunter: an EFF IMSI catcher detector for the Orbic RC400L hotspot

What Rayhunter detects, and who the Orbic hotspot is for

Rayhunter is a project for detecting IMSI catchers, also called cell-site simulators or stingrays. Those are radios that impersonate cell towers so that nearby handsets connect to them, which is how they collect identifiers and, in some configurations, intercept traffic. Rayhunter's approach is passive: it does not try to jam or block anything. It watches what the cellular network is doing and looks for behaviour that normal towers do not produce.

The target user is not a signals-intelligence analyst. The README states the project is designed to be as easy to install and use as possible, regardless of your level of technical skills, and to minimize false positives. That second goal shapes the whole design. A detector that fires on every anomaly is useless to a journalist or an activist, because they cannot triage it. Rayhunter would rather miss a marginal case than train its users to ignore alerts.

The hardware choice follows from the same logic. Rayhunter was first designed to run on a cheap mobile hotspot, the Orbic RC400L. A hotspot is a disposable, single-purpose device: you are not putting a daemon on the phone that holds your contacts. Community work has extended support to some other devices, listed on the project's supported-devices page, but the Orbic RC400L remains the reference target.

How the daemon, the web UI and the Rust workspace fit together

The repository is a Cargo workspace with several members: lib, daemon, check, rootshell, telcom-parser, and installer, with installer-gui/src-tauri present but excluded from default-members. The comment in Cargo.toml is explicit that installer-gui is still experimental and requires many new packages from cargo and the underlying operating system. That is a useful signal about which parts of the tree the maintainers consider settled.

The daemon is the piece that runs on the device and does the monitoring. The lib member holds shared code, and telcom-parser handles the cellular message parsing, which is where the actual detection logic has to live: the daemon observes signaling messages and the parser turns them into something the detection rules can evaluate. The check directory suggests a separate test or validation path rather than everything being crammed into the daemon binary.

There is also a JavaScript side. The root package.json declares a private npm workspace with two workspaces, daemon/web and installer-gui. So the daemon ships a web interface, and the installer GUI is a Tauri application, which matches the src-tauri path in the Cargo members list. In practice this means the user-facing surface is a browser page served by the device, not a terminal. That is consistent with the stated goal of not requiring technical skill: you connect to the hotspot, open a page, and read what it found.

The rootshell member is worth noting. Getting a monitoring daemon onto a consumer hotspot requires some level of privileged access to the device, and a component named rootshell in the workspace is where that concern is isolated rather than spread across the daemon.

Installing Rayhunter and running a first monitoring session

The README does not inline installation steps. It points to a separate installation guide on the project site and says to check it to get started. Because the exact flashing procedure depends on the device, and because the guide is the authoritative source, treat what follows as orientation rather than a substitute: confirm each step against the installation page before you run it, and do not improvise flags.

The workspace layout is the one concrete thing the repository itself states. Cargo.toml lists the members as lib, daemon, check, rootshell, telcom-parser, installer and installer-gui/src-tauri, and it keeps installer-gui out of default-members because that crate is still experimental and pulls in many extra cargo and system packages. So a default workspace build covers everything except the GUI, and the GUI is a deliberate opt-in.

The root package.json is also explicit about the JavaScript side. It declares a private npm workspace with exactly two workspaces, daemon/web and installer-gui, which is where the daemon web UI and the installer GUI dependencies come from.

{
    "name": "rayhunter",
    "private": true,
    "workspaces": [
        "daemon/web",
        "installer-gui"
    ]
}

The repository root also contains docker_make.sh and make.sh, which indicates a container-based build path alongside a local one. Neither is documented step by step in the README, so read them before running them rather than assuming they are equivalent.

Once the daemon is on the device and running, the workflow described by the project is: connect to the hotspot, open its web interface, and watch the detection output accumulate. The README does not document rollback or how to restore a device to stock firmware, so plan for that before you start rather than after.

Where Rayhunter is the wrong tool

The most important limitation is coverage. Rayhunter runs on a hotspot, not on the phone you actually carry. If you want to know whether your personal handset is being tracked, a detector sitting in a separate device in your bag answers a related but different question: it tells you what is happening in the radio environment around you, not what your specific phone connected to. Anyone expecting phone-level attribution will be disappointed.

Device support is the second constraint. The project began with the Orbic RC400L and other devices arrived through community effort. That means support quality is uneven by nature. A device added by a contributor may not have the same depth of testing as the original target, and the supported-devices page is the only place that distinction is tracked. Before buying hardware for this, check that page rather than a retailer listing.

False positives are the third. The README frames minimizing false positives as a design goal, which is an admission that the underlying signals are ambiguous. Cellular protocol anomalies have innocent explanations, and a detection is a prompt to look more carefully, not a verdict. If your workflow cannot tolerate that ambiguity, Rayhunter will generate noise you cannot use.

Finally, the project carries its own legal disclaimer. It states that running the program is believed not to violate laws or regulations in the United States, that the project is not responsible for civil or criminal liability from use of the software, and that users outside the US should consult an attorney in their country. That is the project telling you the legal position is jurisdictional, and it is not something a tool review can resolve for you.

Rayhunter compared with a general-purpose SDR monitoring setup

The obvious alternative approach is a software-defined radio with a general-purpose analysis stack. With an SDR you get raw samples across a wide frequency range, you can decode many protocols, and you are not limited to one device or one vendor. Nothing about that setup is tied to a hotspot.

The difference is where the work sits. An SDR gives you a signal; you supply the interpretation. You need to know what you are looking for, write or configure the detection, and maintain the whole chain yourself. Rayhunter inverts that: it ships a fixed device, a fixed parser, and a fixed set of detection rules, and in exchange you get an answer without building an analysis pipeline. The project's stated emphasis on ease of use and low false positives only makes sense against that trade-off. You are accepting a narrower instrument in return for not having to be the instrument.

That also explains the hardware lock-in. An SDR setup travels across devices; Rayhunter is bound to a supported list that the project maintains. If your device is not on it, the SDR route is the one that still works, at the cost of considerably more setup and expertise.

Release cadence, maintenance and the GPL-3.0 licence

The project is not archived, and the last push to the repository was on 2026-09-21. Releases have been frequent: v0.11.2 on 2026-05-28, v0.12.0 on 2026-08-03, and v0.13.0 on 2026-09-16. For a tool that parses cellular signaling, that cadence matters, because detection rules need to track how networks behave and which devices are supported.

The upgrade cost is mostly on the device side. Because the daemon runs on a hotspot you have modified, updating means going back through the installation path rather than running a package manager upgrade. The README does not document an in-place update mechanism, and it does not document rollback either. Budget time for re-flashing, and keep a note of which release you installed so you can tell whether a behaviour change came from the network or from a version bump.

The licence is GPL-3.0. In practical terms for an adopter: you can use and modify the software, and if you distribute a modified version you take on the obligations that come with a copyleft licence, including making the corresponding source available under the same terms. If you are embedding Rayhunter in a product, or shipping a modified daemon to other people, that is the point to involve someone who can read the licence properly. This is not legal advice, and the project's own disclaimer is broader than the licence question.

Editorial conclusion

Adopt Rayhunter if you already own or are willing to buy a supported device, you accept that a detection is a signal to investigate rather than proof, and you have read the legal disclaimer that the project places in its own README. Skip it if you need coverage on a phone you carry daily, if you need a product with a support contract, or if you cannot act on an alert. Before relying on it, verify three things: that your exact device appears on the supported-devices page, which release you are installing, and what your local law says about operating the hardware.

Frequently asked questions

Official sources

1. EFForg/rayhunter on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases