IMSI catcher detector apps: what a phone will not let them see

A mobile handset contains two computers. One runs the operating system and the applications. The other, the baseband, runs the radio: it implements the protocols that talk to the network, and it is deliberately isolated, because it is subject to regulatory certification and because a fault in it affects the network as well as the device.

Applications live on the first computer and can only learn about the radio what the operating system relays from the second. That relay was built to support features people expect: how strong the signal is, which network is in use, whether data is available. It was not built to support protocol analysis, and it exposes almost nothing about the message exchange in which an identity is disclosed.

So a detector app is working from a summary. It can generally see the identifiers of the current cell, a signal measure, the generation in use, and sometimes a list of neighbours. From that it must infer whether the cell is what it claims to be, which is a question the summary was never designed to answer. Platform changes over the past decade have narrowed the summary, on privacy and stability grounds that are defensible in themselves and that happen to remove exactly the fields this category of tool needs.

Given a summary, the available approaches are all comparative. A tool can compare the current cell against cells it has seen before in the same place, against a public database of known cell identifiers, or against a model of what a plausible cell looks like. Each approach fails differently, and the failures are structural.

Comparison against history needs history, so it is weakest exactly where a person is most likely to want it: somewhere they have not been before. Comparison against a database inherits the database’s coverage, and a legitimate new cell is indistinguishable from an illegitimate one until somebody surveys it, which means a network expanding normally generates alarms. Comparison against a model of plausibility depends on the model, and real networks contain implausible-looking cells for ordinary reasons: temporary capacity at events, indoor systems, cells that serve a single building.

The one signal that survives all of this reasonably well is the change of generation, which is why it appears on every page here that touches detection. It is not a summary artefact and it is not a coverage question: a modern handset in an area with modern coverage reporting older service is describing something specific, and the reason it is strong evidence is that an attacker wants the downgrade.

The practical value of these tools is in the aggregate. A single alert carries very little; a record showing that the same anomaly occurs at the same place on the same kind of day carries considerably more, because the coincidence is what is informative and no single reading can contain a coincidence.

It also helps to know which questions are outside the category entirely. Nothing installed on a handset can detect an observer that only listens, because a passive observer transmits nothing for the handset to notice, and this is why paging exposure has no app-shaped answer. Nothing on the handset can attribute an anomaly to an operator, an agency or anyone else, and the reason that attribution matters is set out in the comparison of the two kinds of interception. And no app can retrospectively tell you whether an identity was collected last week.

What does change the exposure, where a handset offers the setting, is refusing the older generations outright and preferring networks that conceal the subscriber identity. That is a configuration decision, and it acts on the mechanism instead of reporting on it.