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