[Feature Request] Add Basic Radio Threat Notifications to Detect Interceptions

Layamir

On GrapheneOS we’re still blind to radio-level threats like fake towers or downgrade attacks. There’s no reason we can’t at least get basic detection and alerts with current APIs.

What could be detected:

Sudden drop from LTE/5G to 2G/3G

Rapid tower switching while stationary

Data loss while still connected

Country/network code mismatches

I would like to see a a warning as“ Possible network threat: unexpected downgrade to 2G”
Then i can enable optional auto-actions like Airplane Mode, modem block, etc.

We don’t need deep baseband access to get useful alerts. Even passive monitoring of TelephonyManager + some smart logic could provide real-time warnings that matter in high-risk areas.

ryrona

Layamir Sudden drop from LTE/5G to 2G/3G

GrapheneOS already provides full protection against this attack, but setting "4G only" or "5G or 4G only" mode, and disabling 2G support. Go to Settings -> Network -> SIM card -> Your SIM card to change those settings. Once you have prevented the attack entirely, there is no reason to be notified about it.

Layamir Rapid tower switching while stationary

Why is this an attack?

Layamir Data loss while still connected

Why is this an attack?

Layamir Country/network code mismatches

Isn't any dangers with this prevented by disabling roaming support?

Layamir

Nice to know that GrapheneOS offers solid mitigations like disabling 2G or locking to 4G/5G. But this feature request is about awareness, not just prevention in my opinion.

2G/3G downgrade: Even with 2G disabled, unexpected drops might signal tampering (e.g., SIM profile push, config errors). An alert helps verify settings are still intact.

Rapid tower switching: Could suggest a rogue base station or IMSI catcher, especially if stationary and signal quality is poor.

Data loss while connected: Useful for spotting denial-of-service, jamming, or interception attempts where connectivity is blocked despite appearing online.

MCC/MNC mismatches: Can indicate spoofed towers, forced roaming, or border region hijacks.

Passive monitoring via TelephonyManager could flag these events and help users in high-risk environments respond in real time, even without deep baseband access.

It’s about giving users visibility, not assuming protections always work flawlessly.

ryrona

de0u

Layamir If such code were written, how would it be tested?

Delaney

These features feel gratuitous. GrapheneOS considers networks to be hostile and the general consensus is to not connect at all by keeping your phone on aeroplane mode, or at the very least, use encrypted communications.

Layamir It’s about giving users visibility, not assuming protections always work flawlessly.

Informing the user that something has happened doesn't prevent it from happening, so I don't see the benefit here. Aeroplane mode sidesteps all of these so called threats anyway.

Sigismund

Layamir You seem to be suggesting that detecting stingrays is easy, as it's "common patterns" when such activity occur:

Layamir probably you live in a country with no fake towers... there are common patterns when they are present.

Yet EFF released rayhunter with some heuristic detections and as they say it this "may detect potential IMSI catchers" and they suggest uploading the data to verify further, instead of blindly trusting detections.

If you think you can detect it, why not contribute with code to make the detections better?

Layamir

Delaney probably you live in a country with no fake towers... there are common patterns when they are present.

Onlyfun

Delaney Informing the user that something has happened doesn't prevent it from happening, so I don't see the benefit here

Well same applies to medical testing, fire alarms, auditor app etc.
Don't see benefit in user being informed about security issue? Please share more thoughts on this.

jacksmith

Delaney Maybe it's not just about building systems to "inform users about network tampering etc" but possibly providing options to automatically restrict connections when such tampering is detected, and provide feedback about it at the same time.

Delaney

Layamir probably you live in a country with no fake towers... there are common patterns when they are present

If fake towers are such a big threat to you, then use aeroplane mode.

jacksmith Maybe it's not just about building systems to "inform users about network tampering etc"

If it's feasible to do in the first place, sure. I don't think it would be without Google's backing though and in my opinion, GrapheneOS' resources would be better spent on features that will actually work rather than mere detections.

de0u Potentially of interest: Android phones could soon warn you of “Stingrays” snooping on your communications

The problem, however, is that no current phones can do this. To unmask fake cell towers, Android phones need to have version 3.0 of Google's IRadio hardware abstraction layer, which has to be supported at the modem level.

Seems like GrapheneOS couldn't add this as a feature for the currently supported phones even if they wanted to. It relies on appropriate hardware.

de0u

Onlyfun Don't see benefit in user being informed about security issue? Please share more thoughts on this.

If code to detect odd cellular events were written, how would it be tested? For each release a designated GrapheneOS developer would drive by the nearby known-fake cell site? Or, for each release a designated GrapheneOS developer would go into the GrapheneOS Cellular Lab's Faraday cage and turn on the fake cell site?

Onlyfun

de0u how would it be tested?

Each release I not sure, but I guess it could be done on common basis with developer's airplane mode testing?

de0u

Potentially of interest: Android phones could soon warn you of “Stingrays” snooping on your communications

orydeatemi

It's anecdotal, but for those who'd be interested in implementing this stuff, the old timers remember SRLab's SnoopSnitch.

Then there's another thing called YAICD.

I'd love to know how what Google is proposing is different to what was on Qualcomm chips 10 years ago.

Layamir

This is about awareness, not just prevention. Kinda a smoke allarm.
Yes, GrapheneOS can already block many attacks (like 2G coercion), but that doesn’t mean we should remain blind to events that might signal:

rogue tower presence (IMSI catchers, forced downgrades),

profile tampering (silent config pushes),

or targeted interference (for example jamming causing phantom “connectivity”).

There are useful signals available today without HAL 3.0 or baseband hacks.
I think with current AOSP APIs, it is possible to monitor:

sudden RAT downgrades despite preferred network locks,

unexplained MCC/MNC changes without location updates,

repeated tower hops while stationary,

signal inconsistencies (e.g. sudden RSRP/RSRQ drops without motion).

These aren’t definitive proof of attack of course but neither is a phishing link. We flag anomalies, not certainties in these cases.
Testing is practical. Here's how:

In lab: SDR test rigs (srsRAN, OpenBTS) in Faraday cages to simulate base stations and replay rogue scenarios, sure.

In the field: similar to EFF's RayHunter model crowdsourced passive logs + community validation, not “proof by detection.”

This doesn’t need to be perfect to be valuable, just informative without being noisy.
What would it cost GrapheneOS?

A small, optional background service (_500–800 LOC Kotlin),

No HAL/kernel dependencies,

Opt-in toggle under “Developer - Experimental” to avoid user confusion.

This would feed logs to adb for community testing long before becoming a user-facing feature.

de0u

Layamir Testing is practical. Here's how:

In lab: SDR test rigs (srsRAN, OpenBTS) in Faraday cages to simulate base stations and replay rogue scenarios, sure.

In the field: similar to EFF's RayHunter model crowdsourced passive logs + community validation, not “proof by detection.”

Is there reason to believe that the GrapheneOS project already has Faraday cages with SDR-based cell-site emulators, or is it suggested that the project take that on, or is a specific partner organization being suggested?

Layamir A small, optional background service (500–800 LOC Kotlin),

That seems like a testable claim, in the sense that 500-800 lines of Kotlin implementing it would be strong evidence.

Sigismund

Onlyfun what about the equipment needed to fully test it? How will you simulate it?

Onlyfun

Sigismund I said that I don't know exactly how. But it is quite obvious that similar methods to the ones used in testing of 'airplane mode' don't you think?

Sigismund

Onlyfun I said that I don't know exactly how. But it is quite obvious that similar methods to the ones used in testing of 'airplane mode' don't you think

No I don't think so, because capturing traffic is way easier than making one, especially in this context.

locked

I am almost certain i read somewhere that stingray threat notifications are coming to android 16.

wizoatk

locked

Something like this?

Android Authority - Android 16 can warn you that you might be connected to a fake cell tower

Android 16's new "network notification" feature can potentially expose when your device is connected to a fake cell tower

TL;DR

Android 16 is adding a new security feature that can warn you when your phone might be connected to a fake or insecure mobile network created by a “stingray” device.

This feature alerts you to unencrypted connections or when the network requests your phone’s identifiers, which can help detect when surveillance might be happening.

Due to new hardware requirements, this protection will likely only be on new devices launching with Android 16, such as the upcoming Pixel 10.

[...]

locked

wizoatk Yes, that....