2.1 About this Volume

Every alert Rayhunter raises is a statement about the cellular control plane — the signaling that sets up, maintains, and tears down a device’s relationship with a network, as distinct from the user plane that carries the actual data. To read those alerts with any judgment, an engineer needs a working model of how a device registers, what identities it exposes and when, how the control plane differs across 2G/3G/4G/5G, and precisely what a cell-site simulator can and cannot make a handset do. That is this volume.

The treatment is engineer-grade but deliberately category-level. It explains what a CSS does and why those behaviors are observable; it contains no instructions for building or operating one. The goal is comprehension of the detection surface, not of the attack. Where the detail would cross into offensive procedure, the volume stops at the category and names the defensive consequence instead.

The single idea the whole volume serves is the one Volume 1 introduced: what is observable from the handset side is a subset of what a CSS might do. By the end, that boundary should be precise rather than a slogan — the reader should be able to say, for a given behavior, whether a device like Rayhunter can see it, and why.

2.2 Identities: IMSI, IMEI, TMSI, GUTI — and why they matter

Cellular privacy turns almost entirely on which identity is on the air at a given moment, and whether it is permanent or temporary.

Table 1 — 2. Identities: IMSI, IMEI, TMSI, GUTI — and why they matter

Identity	What it is	Permanent?	Privacy weight
IMSI	International Mobile Subscriber Identity — the subscriber identity stored on the SIM	Permanent	High — uniquely identifies the subscriber; the prize for a catcher
IMEI	International Mobile Equipment Identity — the hardware serial of the device	Permanent	High — identifies the handset itself, independent of SIM
TMSI	Temporary Mobile Subscriber Identity (2G/3G/4G)	Temporary, reassigned	Low by design — a short-lived alias used in place of the IMSI
GUTI	Globally Unique Temporary Identity (4G/5G)	Temporary, reassigned	Low by design — the LTE/5G temporary alias

The entire modern design intent is that the permanent identities (IMSI, IMEI) should cross the air interface as rarely as possible, with temporary aliases (TMSI, GUTI) doing the day-to-day work. A network assigns a temporary identity and then addresses the device by it, refreshing it periodically so that an eavesdropper cannot track a subscriber by watching for a fixed value.

This is exactly the design that a cell-site simulator subverts. The classic IMSI-catcher move is to force the device to reveal its permanent identity — to send an identity request for the IMSI (or IMEI) rather than accepting the temporary alias, typically early in the exchange, before the device has any assurance that it is talking to a legitimate network. When a device coughs up its IMSI in a context where an honest network would have been content with a TMSI/GUTI, that is one of the clearest tells a handset-side detector can hope for — and it is the basis of Rayhunter’s most important analyzer (covered in Volumes 5 and 8).

Note. The newest air interface, 5G standalone, introduces concealment of the permanent subscriber identity on the air (a public-key scheme that hides what older generations call the IMSI). That raises the detection bar for the “forced IMSI” tell on pure-5G attachments — one reason the detectable surface narrows on newer networks, as §6 develops.

2.3 How a device attaches to a network

Attachment is a negotiation. The following is the LTE case, which is the one Rayhunter’s heuristics are most tuned to; 2G and 5G differ in the specifics but share the shape.

   UE (modem)                      Network (eNodeB + core)
   ──────────                      ───────────────────────
   1. listen to broadcasts  ◀───── System Information Blocks (SIBs):
      choose the "best" cell        cell identity, priorities, neighbor
                                    lists, reselection rules
   2. RRC connection setup ──────▶  establish a signaling radio bearer
   3. attach / registration ─────▶  the UE requests attachment
   4.                       ◀─────  (normally) AUTHENTICATION request
   5. mutual auth           ─────▶  UE and network prove identity to
                            ◀─────  each other (LTE: mutual)
   6.                       ◀─────  SECURITY MODE command: choose ciphers
   7. ciphered signaling    ◀────▶  temporary identity (GUTI) assigned

Two moments in that sequence are where a cell-site simulator operates, and where a handset-side detector watches:

• Before step 5 (authentication). In the window after the device has camped on a cell but before mutual authentication completes, the device will answer certain messages — including an identity request — without yet having any proof the network is genuine. A catcher exploits this window to pull the IMSI/IMEI. An honest LTE network almost never needs the permanent identity here; it has the temporary alias.
• At step 6 (security mode). The security-mode command selects the ciphering algorithm. If a cell commands the null cipher (EEA0 in LTE) at this step, nothing is encrypted thereafter — something that should essentially never happen outside a test lab or a narrow, regulated emergency case.

The system information of step 1 is itself a detection surface. The SIBs an honest cell broadcasts have a characteristic completeness and set of reselection priorities. A catcher that broadcasts SIBs steering devices toward 2G/3G frequencies, or that omits fields an honest SIB1 would carry (timing for the subsequent SIBs), leaves a fingerprint before the device has even connected.

2.4 The control plane across generations: 2G → 5G

The detectability of a CSS depends heavily on which generation the device is on, because the security model changed fundamentally over time.

Table 2 — 4. The control plane across generations: 2G → 5G

Generation	Network authenticates to device?	Encryption	Catcher leverage	Detector leverage
2G (GSM)	No (one-way only)	Weak; can be absent	Highest — no network authentication at all	A device on 2G, or forced to 2G, is itself the tell
3G (UMTS)	Yes (mutual)	Yes	Lower than 2G	Downgrade-to-2G and identity patterns
4G (LTE)	Yes (mutual)	Yes	Pre-auth window + downgrade + null-cipher	Rich: SIB anomalies, early identity requests, EEA0, redirects
5G NSA	As LTE (uses LTE control plane)	As LTE	As LTE	As LTE
5G SA	Yes (mutual); IMSI concealed on air	Yes	Reduced — permanent ID concealed	Narrower; the “forced IMSI” tell weakens

The practical consequence runs through the entire tool: the richest detection surface is LTE and 2G. 2G is inherently suspect because it never authenticates the network, so a forced downgrade to 2G is both the classic attack and a strong signal. LTE is where most of Rayhunter’s analyzers live, because its control plane is verbose and its anomalies are well characterized. The move toward 5G standalone, with its concealed subscriber identity, is precisely the direction that shrinks the handset-observable surface — not because attacks become impossible, but because several of the tells a passive detector relies on are designed out of the newer air interface.

This is also why “forced 2G downgrade” recurs as a theme. Because 2G is the weakest link, a common CSS strategy is to release the LTE connection and redirect the device to a 2G cell, or to broadcast system information that raises the priority of 2G/3G frequencies so the device reselects down on its own. Both are visible from the handset side — the first as a connection-release-with-redirect, the second as a SIB that over-prioritizes legacy frequencies — and both are among the behaviors Rayhunter flags.

2.5 What a cell-site simulator actually does

At the category level, a cell-site simulator combines some subset of the following behaviors. None of the descriptions here is a recipe; each is paired with the handset-observable consequence that matters for detection.

Table 3 — 5. What a cell-site simulator actually does

CSS behavior (category)	Mechanism, in brief	Handset-observable consequence
Be the most attractive cell	Present itself so the device prefers it during cell selection/reselection	A cell appears that the device reselects to in an unusual way
Catch the IMSI/IMEI	Issue an identity request in the pre-authentication window	An identity request for the permanent ID, early / without auth
Force a 2G downgrade	Release + redirect to a 2G carrier, or broadcast SIBs prioritizing 2G/3G	A connection-release-redirect, or a SIB6/SIB7 that over-prioritizes legacy RATs
Command a null cipher	Select EEA0 at the security-mode step (RRC or NAS)	A null-cipher (EEA0) indication where none should appear
Broadcast incomplete system info	Omit fields an honest SIB1 would carry	A SIB1 missing scheduling for expected further SIBs
Man-in-the-middle	Relay between the device and a real network	Harder to see directly; inferred from the combination of the above

The important structural point is that the strongest evidence is rarely a single one of these in isolation — it is a combination. An identity request on its own can be legitimate; an incomplete SIB on its own can be a misconfigured tower. The two together, in the right sequence, are a far stronger indicator than either alone. Rayhunter’s design reflects this: it has analyzers for the individual tells, and it treats certain combinations (notably an incomplete-SIB condition alongside an IMSI-request pattern) as a materially stronger signal than the components. Volume 8 walks the analyzers one by one with exactly this combinatorial logic.

2.6 The detectable surface — and its limits

This is the center of the volume, and the fact that most shapes how Rayhunter should be used.

What a handset-side detector can see:

• Identity requests for the permanent IMSI/IMEI, especially before authentication.
• Connection-release messages that redirect the device to 2G/3G.
• System-information blocks that raise the priority of legacy (2G/3G) frequencies.
• Null-cipher (EEA0) selection at the RRC or NAS layer.
• System-information blocks missing fields an honest cell would carry.
• The sequence and timing of all of the above — the control-plane choreography that distinguishes an honest attachment from a suspicious one.

What it fundamentally cannot see:

• Intent. The DIAG stream shows behavior, never motive. A misconfigured but legitimate tower can produce several of the same signatures as a hostile one.
• The user plane of others. A detector reads its own device’s control plane; it is not a sniffer of other people’s traffic and cannot be.
• A purely passive catcher. A CSS that only listens — for instance, one designed to harvest identities it can capture without actively reconfiguring the target — leaves far less of a control-plane fingerprint, and may leave none a handset can see.
• Attacks that avoid the observable tells. A sophisticated CSS operating entirely within LTE/5G, never forcing a downgrade, never requesting the permanent identity in the clear, never commanding a null cipher, presents a much smaller surface. The newer the air interface, the smaller that surface.
• Certainty. Because legitimate causes exist for every individual signature, no single observation is proof.

The honest framing, restated. A passive detector is a smoke alarm, not a fire investigator. It is tuned to the behaviors that cheap and common catchers rely on — principally identity harvesting and 2G downgrade — which is exactly why it is useful: those are the attacks most people are most likely to encounter. It is correspondingly weaker against stealthy, modern, or purely-passive adversaries, and it never crosses from “this is worth investigating” to “this is an attack.” Volume 1’s ledger and Volume 8’s triage guidance both rest on this section.

2.7 Why a passive handset-side detector can exist at all

It is worth being explicit about the enabling condition, because it also explains Rayhunter’s hardware constraints (Volume 3) and its reference device (Volume 4).

A modem does not normally expose the raw control-plane signaling it exchanges with a tower. Qualcomm modems, however, implement a diagnostic interface — the DIAG port — that was built for engineering, testing, and field debugging. Over DIAG, a host can request a stream of the modem’s internal events, including the control-plane messages it is sending and receiving. This is the window Rayhunter looks through. It does not need a special radio or an SDR; it needs a modem whose DIAG interface can be reached, and the privilege (root) to read it.

   ┌─────────────┐   control-plane signaling   ┌──────────────┐
   │  Cellular   │ ◀─────────────────────────▶ │   Qualcomm   │
   │   tower     │     (2G/3G/4G/5G air if)     │    modem     │
   └─────────────┘                              └──────┬───────┘
                                                        │ DIAG
                                                        │ (diagnostic
                                                        │  firehose)
                                                        ▼
                                                 ┌──────────────┐
                                                 │  Rayhunter   │  reads only;
                                                 │  daemon      │  never injects
                                                 │ (records +   │
                                                 │  analyzes)   │
                                                 └──────────────┘

Two consequences follow directly, and both are developed later in the series. First, the hardware must be a Qualcomm-modem device with a reachable DIAG interface, and it must be rootable so the daemon can read that interface — which is why only specific hotspots on specific firmware/hardware revisions are supported (Volume 3). Second, because everything comes from DIAG, the detector is strictly bounded by what the modem chooses to surface there — the detection ceiling of §6 is, concretely, the DIAG stream’s contents. The passive posture and the hardware requirement are the same fact: Rayhunter is a reader of a diagnostic port the modem already produces.

2.8 The vocabulary this series uses

A compact glossary so later volumes can be terse. The full glossary is in Volume 10.

Table 4 — 8. The vocabulary this series uses

Term	Meaning as used here
CSS / IMSI catcher / Stingray	A device impersonating a legitimate base station to harvest identities or manipulate the target
Control plane	The signaling that sets up and manages the connection, as opposed to the user plane that carries data
UE	User Equipment — the phone or modem
(e/g)NodeB	The base station (NodeB 3G, eNodeB 4G, gNodeB 5G)
DIAG	The Qualcomm modem diagnostic interface Rayhunter reads
QMDL	The Qualcomm diagnostic log format Rayhunter records and can export
PCAP	Packet-capture format Rayhunter can also produce for analysis in standard tools
SIB	System Information Block — the broadcast carrying cell parameters and reselection rules
EEA0	The LTE “null cipher” — no encryption
NAS / RRC	Non-Access Stratum (device↔core signaling) / Radio Resource Control (device↔base-station signaling)
IMSI / IMEI / TMSI / GUTI	Permanent subscriber / permanent equipment / temporary (2–4G) / temporary (4–5G) identities
Downgrade	Being pushed from a stronger air interface (LTE/5G) onto a weaker one (2G/3G)

With the threat model and the detection surface established, the next volume answers the first practical question any prospective user has: which hardware actually runs this firmware. It carries the series’ mandatory supported-hardware table.

Facts in this volume reflect the public Rayhunter documentation and standard 3GPP control-plane behavior as of 2026-10-17. The treatment is category-level by design; it describes what a cell-site simulator does in order to explain detection, and contains no construction or operation guidance for one.