Database Develop

[AOSP] sepolicy patch for Marshmallow ROMs

After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a

Stickied.

sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?

WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.

Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.

Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:

BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.

@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?

Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above

Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.

the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...

Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?

BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk

danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing

I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks

Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688

Thank you for your work!

Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.

I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.

It reminds me of Korean dramas ,

[Module] [Magisk] init.d link v1.3 | require Magisk 12.0+

Note: This module won't work with v10-v11.6 since some syntax err in the mounting scripts. More info here. https://github.com/topjohnwu/Magisk/commit/624b7616d082feced71bff0474c64c1b4afd5cc0
If you're using a beta one newer than v11.6. Try this module.
Init.d Link (Magisk)
Intro
The module solves the situation when /system/etc/init.d doesn't exist, some app, let's say Kernel Auditor Beta, doesn't recognize the *.d folder provided by MagiskSU and tries to create the init.d folder by itself. So we'd better symlink one from an available *.d — post-fs-data.d, service.d or su.d.
- The module symlinks a *.d folder as init.d,
- or simply create one systemlessly.
- Init.d scripts will be run by an existing superuser — MagiskSU, phh's superuser or SuperSU — or the kernel,
- but NOT by the module itself, in case of collision with the func of kernel.
Symlink Priority:
1. /magisk/.core/service.d (Magisk v12)
2. /magisk/.core/post-fs-data.d (Magisk v11)
3. /magisk/phh/su.d
4. /su/su.d
5. /magisk/.core/post-fs-data.d (Magisk v12)
6. /magisk/.core/service.d (Magisk v11)
The last resort will be the creation of a systemless init.d folder.
NOTE: init.d will be symlinked only if available *.d foler exists.
Installation
Flash it in RECOVERY ONLY.
Credit
https://github.com/laggardkernel/init.d-link by laggardkernel
Changelog
v1.3
- Fix mount of su.img
v1.2
- Update to module template v3
- Add link target info into module.prop.
- Reorder init.d link priority for Magisk v12:
1. /magisk/.core/service.d (Magisk v12)
2. /magisk/.core/post-fs-data.d (Magisk v11)
3. /magisk/phh/su.d
4. /su/su.d
5. /magisk/.core/post-fs-data.d (Magisk v12)
6. /magisk/.core/service.d (Magisk v11)
- There is also a post-fs-data branch keep post-fs-data.d at high priority by force.

Reserved.

How to use this module?

ngtung84 said:
How to use this module?
Click to expand...
Click to collapse
Just download the zip and flash it in your recovery. Then the module will create a /system/etc/init.d link directing to /magisk/.core/post-fs-data.d SYSTEMLESS. This will solve the pain that some apps, like Kernel Manager beta, don't recognize Magisk's post-fs-data.d and create a init.d itself to put their init scripts.

laggardkernel said:
Just download the zip and flash it in your recovery. Then the module will create a /system/etc/init.d link directing to /magisk/.core/post-fs-data.d SYSTEMLESS. This will solve the pain that some apps, like Kernel Manager beta, don't recognize Magisk's post-fs-data.d and create a init.d itself to put their init scripts.
Click to expand...
Click to collapse
I have some scripts. Can I put them into /system/etc/init.d created by this module?

You make some really nice little modules. I really believe you should submit them to the repo... It's gonna need some updating to the latest template and maybe also some updates for v12 though. From the v12 release notes:
It is recommended to run most scripts in the service mode (service.d/service.sh), except a. mounting files; b. patching system props; c. time critical operations
Click to expand...
Click to collapse

Didgeridoohan said:
You make some really nice little modules. I really believe you should submit them to the repo... It's gonna need some updating to the latest template and maybe also some updates for v12 though. From the v12 release notes:
Click to expand...
Click to collapse
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...

Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
Hm... Thank's for pointing that out. I'm not at all fluent enough in scripting to have caught that without some serious scrutiny, and I've not had the time for that today.
Perhaps we'll get an explanation from @laggardkernel about what's going on.

Didgeridoohan said:
Hm... Thank's for pointing that out. I'm not at all fluent enough in scripting to have caught that without some serious scrutiny, and I've not had the time for that today.
Perhaps we'll get an explanation from @laggardkernel about what's going on.
Click to expand...
Click to collapse
Best guess i can come up with is that stuff is left over from other experiments. He seems to be using the same repo for multiple projects and separating them with branches. That seems to have caused some cross contamination in his branches.
As a general development rule you should have one project/solution per repo. Your branches usually represent new features for the project.

Jman420 said:
Best guess i can come up with is that stuff is left over from other experiments. He seems to be using the same repo for multiple projects and separating them with branches. That seems to have caused some cross contamination in his branches.
As a general development rule you should have one project/solution per repo. Your branches usually represent new features for the project.
Click to expand...
Click to collapse
If you look in config.sh you'll see that the module isn't even using post-fs-data.sh (POSTFSDATA=false). And the files on GitHub doesn't match the files in the module zip. Look at update-binary in the zip and then on GitHub. In the zip you'll find the symlinking, but not on GitHub...
So yeah, I guess we're talking about a bunch of code left over from previous experiments.

Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
I took all of that setenforce stuff out of my script. And in my release notes it clearly stated when I release v1.2 that I added the script to AudModLib. However I removed it because I found a workaround in v1.3.
With Audmodlib we have only audio server media server, and system prop contextd permissible for ONLY system and priv apps. Which is what I had to replace with the setenforce stuff.
He's not doing anything shady when looking at the code, it looks like he was following my example. I would submit a git issue to tell him to update the mod.
Hope this clears things up man.

Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
1. Look into the config.sh;
2. Post-fs-data.sh, service.sh are NOT enabled;
3. Post-fs-data.sh, service.sh will NOT be copied to your device.
4. I use a template with some additional features myself. Maybe I'm too laggard to clean up unused codes. But I'm sure I commented out, disabled all unnecessary parts.

laggardkernel said:
Maybe I'm too laggard to clean up unused codes.
Click to expand...
Click to collapse
Ha ha!
But yeah, like it shows, you're gonna scare some people leaving it in there.
True, you'll only get scared if you don't look at the entire thing, but still...

laggardkernel said:
Maybe I'm too laggard to clean up unused codes.
Click to expand...
Click to collapse
hehehe, i see what you did there.
laggardkernel said:
1. Look into the config.sh;
2. Post-fs-data.sh, service.sh are NOT enabled;
3. Post-fs-data.sh, service.sh will NOT be copied to your device.
4. I use a template with some additional features myself. Maybe I'm too laggard to clean up unused codes. But I'm sure I commented out, disabled all unnecessary parts.
Click to expand...
Click to collapse
Yeah, deeper review does show that those scripts aren't installed or used. But leaving them there makes reviewing the module much harder since you have to go looking for that 1 flag which indicates they aren't used. As a developer if I see code in a script I expect that it's meant to be executed and a reviewer won't necessarily know which piece is correct (the flag disabling the script or the script itself).
The module is definitely benign, but on a quick surface review the dead code seems strange in the context of the module itself. Just a suggestion, but cleaning up that dead code would make the module easier to review and avoid having that code get executed accidentally or misinterpreted.
Didgeridoohan said:
But yeah, like it shows, you're gonna scare some people leaving it in there.
True, you'll only get scared if you don't look at the entire thing, but still...
Click to expand...
Click to collapse
Even a full review would raise some concerns with me. Mainly which is correct; having the script disabled or enabled. That concern can only be addressed through a discussion like this. A full review would make me feel a bit more secure since the script isn't executed, but would make me question whether the full functionality of the module is actually in place.
@laggardkernel This is all good work, so I hope you don't take any of this the wrong way. I just happen to do development (more accurately software engineering) as a career and see this kind of stuff all over the place in enterprise software and it makes my eyes bleed every time I see it. Now that I've gotten into a cyber security role I'm even more sensitive to this stuff since they end up constituting security holes (either maliciously or accidentally, usually the latter).

Flash it from recovery, it say Error... because there is already has init.D folder ?
So i have to delete the folder first ?

Vuska said:
Flash it from recovery, it say Error... because there is already has init.D folder ?
So i have to delete the folder first ?
Click to expand...
Click to collapse
If you already have init.d support you don't need this module.
And if you want proper help, where's your recovery log?

Does this module already support Magisk 13.1?

Magisker said:
Does this module already support Magisk 13.1?
Click to expand...
Click to collapse
Not yet. I haven't migrated to v13+ and I'm still waiting for the update of the all-in-one wiki.

laggardkernel said:
Not yet. I haven't migrated to v13+ and I'm still waiting for the update of the all-in-one wiki.
Click to expand...
Click to collapse
The template v4 is already there tho
https://github.com/topjohnwu/magisk-module-template

magisk 14 does not mount magisk.img. It creates a different set up. There is no magisk folder at root containing post-fs-data.d and service.d folders. If they are not there in magisk 14, where are the scripts to be placed for running at boot. Anybody could help on this.

[Unofficial] Google Pixel family support

Let's bring some love to our google-phones!
[Reserved for feature meaningful content]
P.S. As of now, you may check my AFH folder with all my builds - https://www.androidfilehost.com/?w=files&flid=183895

[***Reserved***]

goodwin_c said:
Let's bring some love to our google-phones!
[Reserved for feature meaningful content]
P.S. As of now, you may check my AFH folder with all my builds - https://www.androidfilehost.com/?w=files&flid=183895
Click to expand...
Click to collapse
Where's the Magisk uninstaller for Pixel phones?

Haha called us fan boy's FML guess so..
Getting the 5min unroot like everyone else I guess.

Now that you have your own thread, any chance you'll be pushing to Git more frequently for those of use who can build it on our own?
I'd appreciate it if you could.

So the 13.3 will lose root with Magisk Hide enabled after a little bit. 13_10 (the previous version) should work, but will no longer pass Safety Net....is that the correct state of things?

skaforey said:
So the 13.3 will lose root with Magisk Hide enabled after a little bit. 13_10 (the previous version) should work, but will no longer pass Safety Net....is that the correct state of things?
Click to expand...
Click to collapse
Yes. Fix is on it's way. Hope i can publish it tomorrow.

admiralspeedy said:
Now that you have your own thread, any chance you'll be pushing to Git more frequently for those of use who can build it on our own?
I'd appreciate it if you could.
Click to expand...
Click to collapse
I'm trying my best. But it is pain in ass to merge official commits with my work. Sometimes it's hard to find time even to prepare new build. But i'll try to update github more offten

DodoGTA said:
Where's the Magisk uninstaller for Pixel phones?
Click to expand...
Click to collapse
It's second in my todo list. First i have to fix Hide crashes and installation issue (somehow magisk.img is not created properly on fresh installs). So, after that, i'll work on uninstall script

skaforey said:
So the 13.3 will lose root with Magisk Hide enabled after a little bit. 13_10 (the previous version) should work, but will no longer pass Safety Net....is that the correct state of things?
Click to expand...
Click to collapse
There's a temporary fix for 13_10 but it won't survive a reboot
Sent from my Pixel XL using Tapatalk

Soooperstar said:
There's a temporary fix for 13_10 but it won't survive a reboot
Sent from my Pixel XL using Tapatalk
Click to expand...
Click to collapse
I'm using a Tasker profile to keep this working for the time being. If it's cool, I could create an apk in a few hours that will do the same thing.

raynan said:
I'm using a Tasker profile to keep this working for the time being. If it's cool, I could create an apk in a few hours that will do the same thing.
Click to expand...
Click to collapse
Yea that would be cool
Sent from my Pixel XL using Tapatalk

I thought you could place a file in the /magisk/.core/service.d/ folder (with 755 permissions) that gets ran on startup to do the same thing?
resetprop --delete init.svc.magisk_pfs
resetprop --delete init.svc.magisk_pfsd
resetprop --delete init.svc.magisk_service
resetprop --delete persist.magisk.hide

Looks like my last local build of 13.3 is working solid (finally!), but i forgot my usb cable at office, so can't debug why creation of magisk.img fails during flashing.
So, for now i'm uploading build without fixed install step. Check my AFH!
p.s. new package is Magisk-v13.3-Pixel-b1.zip

getting "magisk image mount failed" with 13.3 and 13.3-b1 on my Pixel XL. Do I need to be on the latest bootloader? I'm using April's at the moment. I just freshly installed Lineage by invisblek

jkashuba07 said:
getting "magisk image mount failed" with 13.3 and 13.3-b1 on my Pixel XL. Do I need to be on the latest bootloader? I'm using April's at the moment. I just freshly installed Lineage by invisblek
Click to expand...
Click to collapse
This is known issue if you are installing latest build and before you had no Magisk. You can wait day or two until i will fix this, or you can use workaround: install Magisk v13 (new10 suffix) and after that install latest 13.3-b1

apologies for dbl reply. i didnt catch your post goodwin.
p.s. thx for all your hard work.

Installed 13.3-b1 with no issue. Root present and working, but SafetyNet is failing (was working previously under 13.3). I tried rebooting, but this did not help. This does not require a new apk, does it?

skaforey said:
Installed 13.3-b1 with no issue. Root present and working, but SafetyNet is failing (was working previously under 13.3). I tried rebooting, but this did not help. This does not require a new apk, does it?
Click to expand...
Click to collapse
try to re-enable Magisk Hide and wait minute or two to give it to settle
P.S. Next release will come with uninstall script

goodwin_c said:
try to re-enable Magisk Hide and wait minute or two to give it to settle
P.S. Next release will come with uninstall script
Click to expand...
Click to collapse
I disabled it, then re-enabled it, then rebooted, and it didn't fix it.....do i need to reboot after I disable it?

[Magisk v19+]Magisk Modules Remover and Magisk Modules Disabler

Hi everybody, here are my
MAGISK MODULES REMOVER and MAGISK MODULES DISABLER
WARNING !!!
Flashing a phone carries risks,neither me nor XDA can not be held responsible
in case of malfunction of your device
In addition, patches "Magisk Modules Remover" and "Magisk Modules Disabler" were designed entirely by @edzamber
No modification of said patches, sharing on another forum than XDA, or hosting at another host file
will not be tolerated without my approval!
Explanations
If like me you have installed an incompatible Magisk Module causing bootloop
or FC from any system application making it unusable phone,
or if you simply need to remove all Magisk Modules,
my twices patchs are done for you !!!
NOTE
Theses patchs only working with Magisk v19.0 or up because of Magisk image location have change.
This will not working with olders Magisk versions. !!!
For Remove all Magisk Modules
Magisk Modules Remover
This patch will remove all modules from Magisk
Use it for cleanning or fix a bootloop cause by any incompatible Module
For Disable all Magisk Modules
Magisk Modules Disabler
This patch will disable all modules from Magisk
Use it for disable all modules without remove or fix a bootloop cause by an incompatible Module
How to
Copy Magisk Module Remover or Magisk Module Disabler zip to the root of your internal card or external card
Flash choosen zip via TWRP Recovery this will remove or disable all Magisk modules
Enjoy ​

Two things:
The mount path for the Magisk image has been /sbin/.core/img since Magisk v14.5. The /magisk folder was just a compatibility symlink.
You're mounting /system rw! That's a big no-no since a huge selling point for Magisk is the systemlessness.

Didgeridoohan said:
Two things:
The mount path for the Magisk image has been /sbin/.core/img since Magisk v14.5. The /magisk folder was just a compatibility symlink.
You're mounting /system rw! That's a big no-no since a huge selling point for Magisk is the systemlessness.
Click to expand...
Click to collapse
Oh great !
Thanks for that, i modify my script :good:
Edit :
Done

Your script is life saver Mate Thank you!!!

Magisk Modules Remover and Magisk Modules Disabler updated to work with Magisk 19+
Enjoy [emoji6]

You saved me from having to do much more to my phone, very simple, disabled all modules, was able to access phone again and magisk to uninstall the incompatible module, thank you so much!!! Great scripts

Alberhasky said:
You saved me from having to do much more to my phone, very simple, disabled all modules, was able to access phone again and magisk to uninstall the incompatible module, thank you so much!!! Great scripts
Click to expand...
Click to collapse
Thanks mate [emoji106]

Thanks man, great script. why it isnt popular yet great work..

Thanks mate. Save my day

Great! I've just installed xposed from Magisk and it got stucked. I have tried serveral patches with no luck, but your script save my phone. Thanks!!!

thanks, you just saved me some stress :good:

@edzamber You're still mounting /system rw? Like I've previously posted in this thread, a major selling point of Magisk is it's systemless modifications, so why do you go and modify people's system partitions for them?

Didgeridoohan said:
@edzamber You're still mounting /system rw? Like I've previously posted in this thread, a major selling point of Magisk is it's systemless modifications, so why do you go and modify people's system partitions for them?
Click to expand...
Click to collapse
Hi bro
If you looked to my script you surely saw that i remove something into system/app. So i need to mount system rw.

edzamber said:
Hi bro
If you looked to my script you surely saw that i remove something into system/app. So i need to mount system rw.
Click to expand...
Click to collapse
Yes, I did see that. And I was curious what your where going to say about it...
The .replace file is used by Magisk to clear out a directory, systemlessly. In other words: you're already removing that file with your first rm command.
You might want to start by doing your homework and learn a bit about how Magisk modules work before you try to tamper with them...
And I'm not you bro.
(I'm not even gonna ask what the rest of that script is about.)

Didgeridoohan said:
Yes, I did see that. And I was curious what your where going to say about it...
The .replace file is used by Magisk to clear out a directory, systemlessly. In other words: you're already removing that file with your first rm command.
You might want to start by doing your homework and learn a bit about how Magisk modules work before you try to tamper with them...
And I'm not you bro.
(I'm not even gonna ask what the rest of that script is about.)
Click to expand...
Click to collapse
Nevermind mate, all People that use my script havn't report me any problem so... And more this script even save some users from clean re-install their Rom... But no problem i will do my homeworks... After my holidays [emoji6]
Cheers

edzamber said:
Nevermind mate, all People that use my script havn't report me any problem so... And more this script even save some users from clean re-install their Rom... But no problem i will do my homeworks... After my holidays [emoji6]
Cheers
Click to expand...
Click to collapse
Sure, the script actually does what's advertised. That's not what I'm having issues with.
I'm having issues with the stuff that's not advertised, that is actually completely unnecessary and may cause some users more headache then they want.
If you're going to throw scripts out there you have at least some kind of responsibility to actually know what you're doing. Right now it's quite clear that you don't fully do...
Sure, everyone can make mistakes (I know, I've done plenty), but if you don't take the time to learn from them what's the point?

Just registered to say thank you! You made my day after trying other fixes that have not worked!

MaRe884 said:
Just registered to say thank you! You made my day after trying other fixes that have not worked!
Click to expand...
Click to collapse
Welcome [emoji2]

Worked for me2!
Dude I really want to get closer to you right now, if you know what I mean.
I really appreciate your help and would suck your **** right now, by that I mean that it worked, while all other scripts did not.
So be proud of yourself and thanks a lot man!

LozziStyle said:
Dude I really want to get closer to you right now, if you know what I mean.
I really appreciate your help and would suck your **** right now, by that I mean that it worked, while all other scripts did not.
So be proud of yourself and thanks a lot man!
Click to expand...
Click to collapse
Hé hé, welcome mate [emoji4]
But please don't suck it, my wife is already doing it [emoji1787][emoji1787][emoji1787]

Modules not working in Canary Build

Hi Guys,
My Pixel 2XL "magically automatically" updated itself to Android 11, so I've been forced to migrate to the Canary build of Magisk
to get root back etc.
The problem I have, is that the modules are not being 'detected' despite being installed.
EG: Active Edge Mod for Pixel, module is installed in Magisk, but the app doesn't detect the installation.
Same for other Magisk modules.
I'm hoping its something simple I need to do to detect these, I've searched, but found no definitive answer.
Anyone have any suggestions? Or can point me to more info on canary?
Thanks in Advance!

I noticed v21 has been released, so I jumped back to the stable channel and updated app to 8.0.1, but strangely still have the same issue!
Modules aren't being detected.
I get the following error when I try to run energized in terminal;
/system/bin/energized[13]: .: /sbin/ .magisk/modules/energizedprotection/system/bin/setupFiles.sh: No such file or directory

You've got two rather special modules there, so they're hardly the benchmark for if things work or not.
For Active Edge Mod you're probably better of asking for help with the developer. And judging by that error the Energized developer also need to update their module, since that path no longer exists on A11 (and it's bad practise to hardcode the path like that anyway). You could edit the energized file in the module directly, to point to the correct path (check the module thread, I'm sure someone has brought this up already).
So, in conclusion: unless there are other more "normal" modules that doesn't work there's no issue and you need to contact the developers of these two modules so that they can fix them.

Thanks @Didgeridoohan, I wasn't aware that the paths had changed. That would explain a lot...
Out of curiosity, what would you consider a "normal" module? For testing purposes..
Cheers!

Thanks @Didgeridoohan, I wasn't aware that the paths had changed. That would explain a lot...
Out of curiosity, what would you consider a "normal" module? For testing purposes..
Cheers!

I always like @osm0sis' modules. They utilise the module installer scripts very nicely and pretty much always work (and if they don't something usually has gone horribly wrong).

Well, hijack the module installer scripts nicely.

Well, I do have @osm0sis BusyBox Magisk Module installed, but I think I read a tweet that TopJohnWu was incorporating a busybox binary in Magisk..
I can see that all of my Magisk modules (except Systemless Host) has a "folder icon with an i" on it. Can't find what that means.. and I get a blank screen when i press it.

Magisk has had Busybox integrated for ages... Lately it's become more usable for scripts and modules though. It's not exposed to the rest of the system like @osm0sis module is.
The icon you're seeing is the module readme. Click that and it should open in the window that you see.