Intents rewiring?

tempproc

Hi,

So it seems that a lot of the reasons why apps may break, especially when wanting to debloat or customise the apps and packages, but also the reason why a lot of private informations gets leak, is because of processes and apps intents, which paradoxically is also present as a way to secure operations and access from apps to the system, yet with no control on what AOSP or its app does.

I'd like to know what are your suggestion or ideas in order to block or if necessary rewire those intents so that the OS runs as intended (no pun) without having to run the actual packages, seems to me that it would be easy to remedy that with spoofing the intents for example?

Thanks.

MetropleX

tempproc especially when wanting to debloat or customise the apps and packages,

We do not support nor offer support when tampering with system apps, adb usage outside of recovery sideloading, usb debugging or developer options being active.

tempproc but also the reason why a lot of private informations gets leak

Evidential standard falls on you if making such a claim that GrapheneOS leaks private information.

tempproc I'd like to know what are your suggestion or ideas in order to block or if necessary rewire those intents so that the OS runs as intended (no pun) without having to run the actual packages

The OS contains those packages as intended to work as intended. Tampering or changing anything in the system is not intended.

tempproc seems to me that it would be easy

As an open source project if you have the requisite skills making this easy for you we do provide a build guide at:

https://grapheneos.org/build

Following the above you can apply and remove anything you want to on the explicit understanding you would not be using GrapheneOS and support for your changes would not and can not be found across our support channels. This forum included.

Good luck on your adventure.

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 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.

tempproc

MetropleX

Evidential standard falls on you if making such a claim that GrapheneOS leaks private information.

I never made this claim, rather I was contemplating the risk of having a lot of non-critical AOSP packages with different components or protocols that themselves could be compromised.

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.)

MetropleX

tempproc constantly communicating with system and outside...

They don't constantly communicate with the system or outside. You've mentioned Bluetooth needing contacts permission but these permissions for system components is different than those user facing apps/permissions.

It has the permission so that when a connection to a device is made such as a car head unit the permission pops up to ask if you want to share the contacts/calls with the device. If you don't you decline and that is it. If you do this permission in the bluetooth stack enables the facilitation of this interaction between phone and bluetooth device.

I've just deleted another one of your replies making erroneous unsubstantiated claims in another thread just like this one. Any further claims without it to demonstrate you actually understand what you are saying and claiming will be considered FUD and will lead to restrictions on your ability to interact on our forum.

Even the claim about wireless emergency alerts being spoofed shows a PoC requiring the installation of a malicious app and not for the latest API level it's not a PoC for anything working on GrapheneOS like this. You can even disable all WEA in GrapheneOS.

Just because system components are there also doesn't mean they are always running or in the background, they only run when they have requests passed to them.

Please stop misreading permissions that system components have as being the same as user facing user installed user controlled app permissions they are not.

These are core components of the operating system and the permissions they have are required for the operating system to function as it explains in the menu.

It's strange that Android even has the option to show information on these system components in the permission manager. It largely only serves to mislead users about how things work.

You should not be revoking permissions from base OS components or disabling them unless you want to break the device and end up needing to factory reset it from recovery.

It's a design flaw that Android shows system components included with bundled apps in the permission manager. They should be distinguished.

All AOSP components are open source and everyone can see what they do. If there was any security based vulnerability with them we would have addressed it with our modifications already. We wouldn't bundle something otherwise. Our OS is also open source, if people disagree for whatever their reasons (unsubstantiated or otherwise) people are free to build their own OS using ours as the base, we also don't stop users from making alterations using adb etc. What we do reserve the right for, is to withhold technical support or discussion across our channels for what is then essential an entirely different OS as would be demonstrated by Auditor.

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?

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.

tempproc

de0u

About the Print Spooler: there's no reason for it to run if I'm not using a printer, periods. Adds to the attack surface, but also battery and memory consumption. And it's my original logic: we should be able to disable them but as I understand this is not GOS approach, unless using adb.

For the WEA risk, it's a threat research that shows how WEA channel can be highjacked and then spoofed, which poses a more irl risk, like receiving a message that an 9 richter earthquake is about to happen and people should evacuate when it's not true or misinforming people. Also several time I've had this app exfiltrer Gigs of information, screenshort are somewhere in my archive. Anyways the same logic applies if not needing any emergency alert.

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.

tempproc

MetropleX

I will absolutely be using adb to disable some permissions and packages that are useless and that I know do not have dependencies. It's just not practical at all since with AOSP or other distribution there's many package disabler solution and somehow I can't find one for GOS.

But I also understand it is GOS approach to not cater to this capability outside of adb, I'll guess I'll go look at custo distros as recommended.

de0u

tempproc About the Print Spooler: there's no reason for it to run if I'm not using a printer, periods.

I am not aware of reasonable grounds for an outside agent to force you to run the AOSP Print Spooler on your device (nor am I aware of reasonable grounds for an outside agent to force anybody to provide a build of any AOSP variant that has or lacks the AOSP Print Spooler).

tempproc Adds to the attack surface, but also battery and memory consumption.

For the potential benefit of forum readers: personally I have never seen the AOSP Print Spooler register on my device's battery usage. Obviously any runnable code offers some attack surface, and any launched system service uses some memory and consumes some energy at launch. Whether any of those are significant in the case of this particular service is unknown. I looked briefly for vulnerability reports involving the Print Spooler and found one mention of the Print Spooler -- in a piece about potentially exploiting something else with more privileges (source). Perhaps there are reports of vulnerabilities in the Print Spooler (and perhaps there are unreported vulnerabilities).

tempproc For the WEA risk, it's a threat research that shows how WEA channel can be highjacked and then spoofed, which poses a more irl risk, like receiving a message that an 9 richter earthquake is about to happen and people should evacuate when it's not true or misinforming people.

The spoofing "attack" based on WEA that was mentioned before requires the installation of an app, and appears to require enabling a specific permission, and the app's description does not claim it works on modern versions of Android. Obviously people may differ in evaluating the seriousness of such a potential threat.

tempproc Also several time I've had this app exfiltrer Gigs of information, screenshort are somewhere in my archive.

The forum moderators have a general distaste for unsubstantiated alarming claims. If there is evidence behind this claim, making it available for evaluation might be productive. If evidence is not presented, presumably forum readers will draw their own conclusions.

Meanwhile, I believe the PrintSpooler source can be inspected here.

MetropleX

tempproc I will absolutely be using adb

As is your prerogative, we retain ours to not support devices that have had our OS tampered with in this way as well as to moderate promotion or advice to do so in our channels.

With this being the case you seem to have answered your own question as to the approach you'll be taking to remedy your concerns. This thread has run it's course.