Intents rewiring?

tempproc

MetropleX The aim is not to modify AOSP apps, but feed them with spoofed informations or in this case intent responses.

I don't understand why it would be intended by the OS for some of those apps to be constantly communicating with system and outside...

de0u

tempproc The aim is not to modify AOSP apps, but feed them with spoofed informations or in this case intent responses.

Is it possible to present a specific example of some "private information [that] gets [leaked]", or propose a specific change to the processing of a specific intent?

tempproc I don't understand why it would be intended by the OS for some of those apps to be constantly communicating with system and outside...

I think this is the second post in this thread in which detail-free allegations about privacy leaks are being made. Unsubstantiated alarmist claims are not the sort of material this forum supports.

(Genuine security vulnerabilities that should not be disclosed publicly may be reported in accordance with the "security.txt" protocol.)

tempproc

de0u

There's many apps in AOSP that it are preferable for some users to disable either because they're useless, pose a security or privacy hasard, consume processing/ram in a way that deteriorates the experience or autonomy etc...

One example is Wireless Emergency Alerts that can access SMS when it shouldn't since it's a separate broadcast system and could backdoor data through those channels (https://discuss.grapheneos.org/d/7965-understanding-wireless-emergency-alerts-app), could be maliciously spoofed (https://www.reddit.com/r/hacking/comments/iom2rs/spoofing_android_wireless_emergency_alerts_at_the/) and can potentially be breached through the different components and channels it uses (https://www.malwarebytes.com/blog/news/2025/11/millions-at-risk-after-nationwide-codered-alert-system-outage-and-data-breach)

Another one is Print Spooler which has a lot of permission, including the very problematic nearby devices permission which open a vector of attack that has been used in the past to MITM which should absolutely not be running when there is no intention of using a printer with the phone, for various reasons including the ones mentioned above.

A lot of AOSP processes and packages not only are uselessly deteriorating the experience but also pose those privacy and security risks for attacks. It is baffling that there's no solution to disable them besides ADB.

Understanding that one of the problem is all the intents prompts from the system, which is honestly is just dark UI design to me as they've been unnecessarily entwined with the core OS operations updates after updates to force them on users, I proposed that some intents be spoofed or get spoofed informations if they were to not to be disabled for system stability.

de0u

tempproc There's many apps in AOSP that it are preferable for some users to disable either because they're useless, pose a security or privacy hasard, consume processing/ram in a way that deteriorates the experience or autonomy etc...

GrapheneOS users who wish to disable various built-in system apps will likely need to do so via a custom build, for which instructions are provided by the project.

de0u

tempproc [...] Wireless Emergency Alerts [...] Print Spooler [...] a lot of AOSP processes and packages not only are uselessly deteriorating the experience but also pose those privacy and security risks for attacks [...]

The forum moderators are generally not in favor of unsubstantiated alarming allegations. If there is a specific vulnerability, responsible disclosure is available.

tempproc Understanding that one of the problem is all the intents prompts from the system [...] I proposed that some intents be spoofed or get spoofed informations [...]

So far in this thread it doesn't seem that any specific threats related to intents were described, nor were any specific remedies proposed.

userofgos

tempproc One example is Wireless Emergency Alerts that can access SMS when it shouldn't since it's a separate broadcast system and could backdoor data through those channels

See post #6 & #11 from the same thread you linked:

No, your phone is not "compromised" or "backdoored". This app handles emergency alerts (think natural disaster alerts, AMBER alerts and other alerts.)

As part of doing that (it flashes a screen on your phone whether it's locked or unlocked, and depending on the type of alert plays a loud siren as well), which is why it has the permissions it has.

It seems like you are misinterpreting what is actually happening. The permission to read your SMS messages is just part of having to grant it the SMS permission, which is completely normal. You'll notice that if you check every app which asks for the SMS permission, you'll find that there. It's not malicious, it's how the SMS permission works.

It is unfortunate that AOSP still lists permissions in that way, though tucked away in a menu because it confuses folks.

The WEA app needs to be able to send those alerts and be able to handle them so that it can activate the siren if it's a presidential/national alert. It is also important to put this in context. Wireless Emergency Alerts app is a system app. It being able to read SMS doesn't mean it's broadcasting that anywhere. It's part of AOSP and therefore part of GrapheneOS. It's harmless.

the attack surface is absolutely tiny compared to everything else. It's not a privacy or security issue. We added a toggle because the alerts can be a disruptive annoyance.

Did you read the even read the full article you linked below?

tempproc can potentially be breached through the different components and channels it uses (https://www.malwarebytes.com/blog/news/2025/11/millions-at-risk-after-nationwide-codered-alert-system-outage-and-data-breach)

This did not affect the Emergency Alert System:

To avoid confusion: CodeRED is not the same as the Emergency Alert System (EAS), which is the federal government-managed emergency notifications system. The CodeRED emergency notification system is a voluntary program where residents can sign up to receive notifications and emergency alerts affecting the city they live in.

CodeRED is NOT related to the Emergency Alert System (EAS), which is the federal government-managed emergency notifications system and recognizable by the telltale alert tone that residents may hear on TV, radio or via their cellphones. This service, which the Commonwealth of Massachusetts may deploy during a serious emergency, is not affected by the CodeRED outage and does not require anyone to sign up.

tempproc

de0u

I feel like this is gaslighting. Most of GOS security approach it seems is based on reducing attack surface, implementing hardened malloc/MTE as much as possible, as well as -preventing- other vectors of attacks, but it doesn't mean that it's addressing any specific known vulnerabilities or compromised packages....

So why are you asking me to substantiate things that are not allegations in the first place, but example of vectors and surfaces that are KNOW to allow for exploits like this example I posted https://www.reddit.com/r/hacking/comments/iom2rs/spoofing_android_wireless_emergency_alerts_at_the/ or even PrintNightmare type of attacks and if not MITM attack using spooling.

The original point was, since the stance from GOS seems to be to maintain all of AOSP system apps with no possibility of disabling or even changing permissions for those, under the reason provided that it "would break the system or lead to instabilities", one of the reasons specifically being because some system processes or components expect apps to be active and vice-versa through intents, could/should there be a way to spoof those informations in order for the system to operate as expected without those packages/processes having to be active?

tempproc

userofgos

I'm aware CodeRED is different from WEA but still a component that could be used to breach into the phone in various ways. My point, which I already made in several thread, that it would be great for a custom OS that boast security to have access and control on non-system critical bloat that Google ads, or at least have way to either disable or spoof information not to break dependencies or intent prompts

de0u

tempproc https://www.reddit.com/r/hacking/comments/iom2rs/spoofing_android_wireless_emergency_alerts_at_the/

Based on a quick look, I'm not sure I understand the nature of the "exploit". Is the "exploit" that an app that is manually installed on one's device can trigger a pop-up that looks like a WEA alert?

de0u

tempproc The original point was, since the stance from GOS seems to be to maintain all of AOSP system apps with no possibility of disabling or even changing permissions for those, under the reason provided that it "would break the system or lead to instabilities", one of the reasons specifically being because some system processes or components expect apps to be active and vice-versa through intents, could/should there be a way to spoof those informations in order for the system to operate as expected without those packages/processes having to be active?

I don't know how to address the general question about any/all intents, and it's not clear who might be able and willing to address it, beyond the answer already provided above (MetropleX). If a question were posed about some particular intent that might be different.

Meanwhile, I suspect that if a specific problem is reported with a specific system service then it would make sense to fix that problem, as opposed to writing code to spoof its regular operation. A "spoof Print Spooler" would require work to write and maintain (it seems plausible that Google adds features to Print Spooler over time). I suspect it would be less effort, and more productive, to audit the Print Spooler code from time to time, since some people do use it.

userofgos

de0u I'm not sure I understand the nature of the "exploit"

Same. Also, in order for this to work, it seems that you have to grant the app the Allow display over other apps permission - I wouldn't call that an exploit.

de0u

userofgos Also, in order for this to work, it seems that you have to grant the app the Allow display over other apps permission - I wouldn't call that an exploit.

I think it's possible that the "exploit" is that a regular app can't display over apps, but that a regular app can trick the WEA app into displaying an alarming pop-up over other apps. But I haven't spent a lot of time looking into it, so perhaps somebody who better understands the urgency of the threat will weigh in.