Bypass system DCL restrictions in GrapheneOS

[ItzELECTR0]

Is your feature request related to a problem?/你的请求是否与某个问题相关？

Parasitic launcher cannot be opened in GrapeneOS because it requires Shell to use DCL (dynamic code loading) via memory, which GrapeneOS heavily restricts it's access for system apps.

This issue causes any module that also uses DCL via memory with System, SystemUI or Android scope to enter a bootloop upon restart.

Graphene will not be changing this any time soon, causing anyone wanting to use Xposed modules on it to limit themselves to modules that don't use system apps as scopes or don't use DCL via memory.

Describe the solution you'd like/描述你想要的解决方案

LSPosed needs a custom implementation to bypass DCL via memory restrictions in GrapheneOS, not only for it's own functionality, but for the countless other modules that use DCL via memory on system apps, including the system itself.

Additional context/其他信息

No response

[JingMatrix]

Did you try this wonderful workaround discovered in #206 ?

[ItzELECTR0]

Yes, in fact. That doesn't solve the issue of modules that need system scopes though...

[JingMatrix]

Well, if that was what you wanted to achieve, it would be wiser to abandon GrapheneOS.
LSPosed is open source, any workaround we found here would be a security threat to the community of GrapheneOS.
I don't think it deserves our investment to joint this apparently endless friendly fight.

[ItzELECTR0]

Getting back to this.
I'm not sure it would be wiser to abandon what I consider my bare minimum in privacy to use plugins and modules that help me every day.

I used to have a rooted samsung but specifically bought a pixel to use GrapheneOS.
Imagine my surprise when I found out that most things I thought just worked, ended up breaking the whole system.
When it comes to rooting, it's purpose is to allow users to do things that their ROMs don't usually allow.
I don't see why GrapheneOS would be exempt from this, even if it weakens the security of the end user.
The ratio of security vs control should be in the hands of the user, right?
And if workarounds found here get solved by Graphene then yeah, sure, it would be an inconvenience to US
But it would strengthen the OS' security overall, which I guess is a good thing lol

All I ask is that you consider reopening this issue.
If it's too difficult a task to find a way to bypass it, that's fine.
But I'll appreciate that it was tried, even if just for the small amount of people actually rooting graphene.
I'm pretty sure I might be the only one fighting this hard to get it working anyway lmfao
I've got basically no coding knowledge when it comes to operating systems
But if I did, trust me I'd be trying to do it myself (And failing miserably, probably)

[JingMatrix]

I transfer your request as a discussion, since so far I have no idea how to possibly bypass it.
If others have interesting ideas, I would be glad to listen and try.

[ItzELECTR0]

I appreciate it mate

[nelsongt]

I'm on GrapheneOS and using the workround. I do not really understand everything but just wanted to mention that there is a fork of Magisk for GrapheneOS + Zygisk: https://github.com/pixincreate/Magisk

[ItzELECTR0]

Yeah I'm aware of it. But as far as I'm aware it doesn't really do anything other than make the built-in zygisk work. There isn't really any advantage to using it instead of regular magisk with NeoZygisk or ReZygisk. And it doesn't really have anything to do with this issue.

[nelsongt]

Ok thank for the explanation, was hoping it was more useful.

[raxod502]

Compile GrapheneOS from source, applying the following patch to frameworks/base:

diff --git i/core/java/android/ext/settings/app/AswRestrictMemoryDynCodeLoading.java w/core/java/android/ext/settings/app/AswRestrictMemoryDynCodeLoading.java
index 2dd6e8da635e..4360cf09f3a7 100644
--- i/core/java/android/ext/settings/app/AswRestrictMemoryDynCodeLoading.java
+++ w/core/java/android/ext/settings/app/AswRestrictMemoryDynCodeLoading.java
@@ -37,23 +37,6 @@ public class AswRestrictMemoryDynCodeLoading extends AppSwitch {
     @Override
     public Boolean getImmutableValue(Context ctx, int userId, ApplicationInfo appInfo,
                                      GosPackageState ps, StateInfo si) {
-        if (appInfo.isSystemApp()) {
-            if (shouldAllowByDefaultToSystemPkg(ctx, appInfo.packageName)) {
-                // allow manual restriction
-                return null;
-            }
-            if (SELinuxFlags.isSystemAppSepolicyWeakeningAllowed()) {
-                return null;
-            }
-            si.immutabilityReason = IR_IS_SYSTEM_APP;
-            return true;
-        }
-
-        if (ps.hasFlag(GosPackageStateFlag.ENABLE_EXPLOIT_PROTECTION_COMPAT_MODE)) {
-            si.immutabilityReason = IR_EXPLOIT_PROTECTION_COMPAT_MODE;
-            return false;
-        }
-
         return null;
     }

This forces GrapheneOS to allow configuration of DCL settings for all apps regardless of whether they are system-level or not. You can simply go to Settings and toggle on the required DCL setting for Shell. The runtime logic for validating DCL calls directly into the Settings code, and there is built-in support for system apps to allow DCL (e.g.: Vanadium), so no additional steps are required.

[raxod502]

Well, I compiled GrapheneOS 2026032000 yesterday and found that it failed to boot. Again. This has been a common occurrence for me during past upgrades because of unannounced breaking changes and absolutely piss-poor observability in the GrapheneOS build process.

I've had sufficiently many problems with GrapheneOS that are mostly the result of intentional hostility from the development team against root access and what they consider to be non-recommended setups that at this point I've decided that rather than upgrading any further I will instead migrate to a different, more compatible distribution, such as /e/OS.

Note that I was still using KernelSU 1.0.5 with the new build, since newer versions have other problems - I reported some at tiann/KernelSU#2942, tiann/KernelSU#3369, tiann/KernelSU#3368, tiann/KernelSU#3367, tiann/KernelSU#2775.

Because of the continued documentation problems with KernelSU, I will also be considering alternative root solutions when I migrate off GrapheneOS. At this point I haven't done any research on this, though, so I can't comment on how other options compare.

[ItzELECTR0]

Well in that case I don't think I will be doing my builds with KernelSU. I've used Magisk on GOS in the past and it worked without issues. Though on recent GOS builds, Zygisk would not work at all, neither NeoZygisk nor ReZygisk. At that point I just removed root solutions from my device since I wasn't able to do much with them anyway without the DCL patch. If I get that working though, I might start using root again.

As per earlier statements of mine in this discussion, GOS is what I consider my bare minimum when it comes to privacy, so alternative distributions aren't something I'm considering. If root and a bit of privacy was all I wanted, LineageOS would've been enough as it supports both DCL and KernelSU without creating a custom build at all. But I cannot go without the sandboxed Google services or the per-app network permission. MicroG unfortunately cannot cut it for me, yet anyway.

[raxod502]

I used to use Magisk on GrapheneOS. But it stopped working, and upstream indicated that attempts to fix that would not be accepted: topjohnwu/Magisk#7606.

I originally migrated from upstream Magisk to a fork that maintained GrapheneOS support, but even that wasn't sufficient to get Frida working; I eventually migrated to KernelSU to resolve that problem: frida/frida#2743.

Frankly, GrapheneOS seems to me to be the main common denominator for problems - intense hostility towards discussion of ROM customization or interoperability with third-party tools will do that - but you can make your own tradeoffs.

[ItzELECTR0]

I fully agree that as great a GOS is, it is also a thorn in the side of those who want to get more out of their devices than what their ROM offers. That's always been the reason I started rooting and would root any device that I own with any ROM I install on it.

I absolutely despise what modern mobile devices have become. They are trackers and data harvesters you willingly carry in your pocket everywhere you go. That is why I find GOS to be the only viable option for me as it actively minimizes the amount of data that gets out of my device.

At this point my choices would be to accept remaining unrooted and keep having my device secure and private, or migrate to LineageOS with KernelSU and try to make microG work for me. Both extremely annoying options.

[Enovale]

Does core/res/res/values/config_ext.xml in platform frameworks not get saved anywhere? As long as it's not embedded in some kind of file with checksums it should be able to be modified with a magisk module. I just don't know enough about android development to know where. I've also tried ripgrepping a running system for this array in /data and /system and not found anything of note, but I'm kind of grasping at straws here.

[Enovale]

I found a solution! Ironically, an XPosed module can be used! Here's mine: https://github.com/Enovale/GrapheneFixer

It basically implements the patch here as a module: #340 (comment)

I've gotten Global Icon Pack working where it wasn't before!

[lefuglyduck]

Full solution for anyone trying to make Vector work on GrapheneOS without having to go through a maze of threads:

Preamble:

1. I'm using GOS 16 (2026061601 - last release). I haven't yet upgraded to GOS 17 because I want it to "stabilize" before upgrading, so these instructions may not work with GOS 17.
2. As of today's date I'm using the pixincreate version of Magisk (30700).

Steps:

1. Disable "Secure app spawning" (in Settings). (Source)
2. Install the Vector module. I'm using canary 3057 (Release build) - newer and/or older versions may also work.
   2.1) The last step will probably not work. If it does, congrats, you (probably) don't need to continue with these instructions.
3. Based on these instructions:
   3.1a) On your computer, with your phone connected (via wifi or usb), install Vector manger as a user application using the following command (though I recommend you doing 3.1b instead):
   adb shell su -c cp /data/adb/modules/zygisk_vector/manager.apk /data/local/tmp && adb pull /data/local/tmp/manager.apk && adb install ./manager.apk
   3.1b) Alternative, if you're using aShell You (or other similar adb shell tools) on your phone you may run (in root mode):
   pm install /data/adb/modules/zygisk_vector/manager.apk
   3.2) Open Vector manager as a normal application from your launcher. If the manager is not functioning, you can alternatively use the cli tool /data/adb/lspd/cli.
4. Download and install GrapheneFixer using the instructions. The last step is particularly important: make sure to set to allow "Dynamic code loading via memory" and reboot.
5. Test to make sure Vector can be opened via the system notification.
6. (Optional) you may uninstall the Vector app in your launcher, it can still be accessed via the notification.

[DADA30000]

Interesting why it suddenly started working without any problems now.

[ItzELECTR0]

Seriously? I've been unrooted for quite a while now. Though if this is true there's a chance I'll try it again.

[DADA30000]

yeah, I just install Vector module and it just... works
Only thing I did is disabled secure app spawning so that zygisk would ofc work
Although keep in mind that I use latest dev build of KSU Next, integrating it into kernel src and then building graphene with it from src, so maybe it did some of it's own fixes for this or smth. But I too had some time ago problems with DCL that I solved for some time with just installing manager apk, so uh yeah.

[ItzELECTR0]

Interesting. I don't have as much free time these days so figuring out how to build Graphene from source and WITH KSU built into it might be a bit of an adventure I cannot go on right now. But I might look into it.