Hi everyone — I’d like to propose an exploratory module for Rayhunter that focuses on identifying suspicious or anomalous femtocell / small‑cell behavior using the Qualcomm DIAG telemetry Rayhunter already parses.
This is not intended as definitive rogue‑cell detection. Instead, the goal is to surface contextual indicators that may warrant further investigation, using lightweight heuristics layered on top of Rayhunter’s existing DIAG pipeline.
Rayhunter already provides strong visibility into OTA signaling through Qualcomm DIAG logs. However, one category of infrastructure that remains difficult for users to understand or contextualize is consumer femtocells / microcells, especially when:
deployed in unexpected locations,
misconfigured,
or repurposed for behavior that differs from normal carrier‑managed small cells.
There is currently no open‑source tool that focuses specifically on identifying anomalous femtocell patterns using DIAG‑level data. This module aims to fill that gap in a cautious, heuristic‑driven way.
These are preliminary ideas for patterns that could be surfaced to the user. All would be framed as “potential anomalies”, not as definitive findings.
Examples include:
PLMN identifiers that do not map cleanly to expected regional carriers.
MCC/MNC combinations typically associated with consumer femtocell hardware appearing in contexts where they would not normally be deployed.
PLMN tiers that do not match the expected hierarchy for the region.
For example:
The same small‑cell ID appearing in geographically distant or contextually implausible locations.
Low‑power cells broadcasting identifiers inconsistent with the surrounding macro network.
Sudden transitions to older RATs (e.g., LTE → UMTS → GSM) in situations where the surrounding macro network normally maintains higher‑tier coverage.
Consumer femtocells often produce:
unusually stable RSRP/RSSI values,
minimal fluctuation relative to device movement,
or consistent high‑strength signals in environments where macro‑cell variability is expected.
These patterns could be surfaced as “unusual stability” rather than labeled as malicious.
The module would:
use the existing DIAG parsing infrastructure,
add a lightweight heuristic layer,
avoid introducing new dependencies,
and operate purely as an analysis module, not a detection engine.
No changes to Rayhunter’s capture pipeline would be required.
To avoid overclaiming, the module would explicitly acknowledge:
femtocell behavior varies widely by carrier and region,
anomalies do not imply malicious intent,
DIAG data can be noisy or incomplete,
and heuristics must be conservative to avoid false positives.
The goal is to provide context, not conclusions.
I’m currently building out a test environment to gather DIAG logs from a variety of real‑world scenarios. Once the lab is fully operational, I’ll share:
sample DIAG snippets,
examples of anomalous patterns,
and early prototype heuristics.
For now, I’d appreciate feedback on:
whether this direction aligns with Rayhunter’s roadmap,
which DIAG fields or message types would be most appropriate to target,
and any prior work or constraints I should be aware of.
Thanks for taking the time to review this — looking forward to your thoughts.
— Eric
Please don’t use AI for your written communication, because as a direct result, a lot of this is super vague and not only doesn’t consider prior art, but doesn’t reference the existing codebase at all.
What makes femtocells special compared to fake base stations in general?
Do you want to refer to past recordings to find previous locations of a given ID? Do you want to integrate with public DBs?
Where do you get that “context” from? I.e. is the goal here to:
How did you come to these conclusions?