Add Magisk systemless support

[topjohnwu]

Hello @rovo89, long time no see! In the time since last time we had conversation here on Github (for systemless support of Xposed), I had created a quite popular project Magisk, which basically is another root method, but most importantly provides a simple, easy to use systemless interface.

The first few systemless versions of Xposed by me requires quite a few adjustments for several paths, and has some rough edges. However since recent versions of Magisk, the interface itself is much more advanced, and can handle adding tons of additional files into /system without issues. The result is that Xposed binaries do not need to be modified - you just need to place them in the right place, and Magisk will mount the files to the target location for you.

However, one small issue appears: for the prop file /system/xposed.prop, some devices cannot handle adding files to system root. I do not want to recompile app_process just to change this single path, as a temporary solution, I ended up hex editing the binaries to load from /xposed.prop, which actually links to /magisk/xposed_<sdk>/xposed.prop. The reason for choosing /xposed.prop is simply due the fact that it's shorter than /system/xposed.prop. BTW, it is also trivial to add the patch to the native Xposed source, you can consider adding the path /magisk/xposed_<sdk>/xposed.prop (or /xposed.prop if you're lazy lol) to one of the lookup paths for the prop file.

Since I am the maintainer of all systemless versions, I think it would be reasonable to add the prop path to the main app (thus this PR), and the patch is extremely trivial.

On another topic, my experience with SuperSU using the post-fs-data mode doesn't work reliably (which is the initial motivation to create Magisk), and since it is only a barebone rooting solution, many adjustments has to be done (just like my early versions of Systemless Xposed). I'm not sure what you plan is, but I would suggest that it will be a better idea to make the "official" systemless version as a Magisk module. In addition, my project is 100% open source, so you wouldn't need to depend on proprietary SuperSU 😉

For more info regarding systemless Xposed, check out my XDA Thread SDK 25 version of systemless Xposed on my Magisk Online Repo

[rovo89]

Glad that you ask. 😃 I had actually looked into adding official systemless support for Nougat, and I had also looked at Magisk, but I got quite confused about what is required to make a Magisk module.

The work I had started for SuperSU - but actually also any other rooting tool that provides a callback early enough and waits for it to return - was rather simple. There would be a script that would be installed into su.d (or similar), which would mount --bind the Xposed files over the original files in /system. The script, along with the Xposed files, xposed.prop and the custom BusyBox (to have a common and well-known environment) would simply be copied to /su by the Xposed Installer while the system is up and running. No recovery magic required, especially no fiddeling with .img files (duplicating what SuperSU does to them with all the merging etc.), just plain extraction and maybe a bit of permission adjustments. Uninstalation woud work in a similar way.

For Magisk, I was looking for something close to that, but I didn't find that. I found templates, but it would require me to copy a whole lot of files into my ZIP (where most of the logic is duplicated for everyone implementing a module, only a few spots are adjusted), overwrite my update-binary etc. That's not something I want to do. I could live with adding a config file so that Magisk knows how to handle my package, and then I could maybe pass the ZIP on to the Magisk tool at runtime and it would take care of unpacking it to the right spots). Is there something like that available, to keep the logic included in the package ZIP to a minimum?

[topjohnwu]

Of course, you can do everything in your own fashion! I created the module template for people with zero programming or scripting experience. One example is the Busybox-Installer by @osm0sis, which does not use my template at all: the scripts even supports installing to /system and SuperSU su.img installation 😀

My documentation has covered all the details of a module's structure. Basically you need to create a folder, create a file module.prop as module metadata (same logic as AndroidManifest.xml), and place your files into system in the same location as it would in the real /system. Also, create a file named auto_mount to tell Magisk to mount the files for you, so you don't need to write a script to mount stuffs into /system.

One advantage of Magisk over raw script bind mounting is that it can actually add files into /system, like /system/framework/XposedBridge.jar, /system/lib(64)/libxposed.so etc., so it works just as if it was installed in /system. For the small issue I already mentioned in the last post (/system/xposed.prop), if you move the file to something like /system/etc/xposed.prop (or anywhere NOT in /system root), then the Magisk systemless version and original system installed version would be 100% identical, no changes needed at all!

Last note, in my current Systemless Xposed implementation, I also added a script called post-fs-data.sh. This basically is only for linking /xposed.prop -> /magisk/xposed_<sdk>/xposed.prop, and for SDK 22 specifically an extremely dirty workaround as it requires to rename all odex to odex.xposed (I used some tricky Magisk hacks to accomplish it 😜). You wouldn't really need to bother that though.

If you need more information, reach me anytime and I'm willing to help! Also, if you want more reading lol, here is the full Magisk documentation

[topjohnwu]

Oh, and for the script callback, there is actually plenty of them 😄 You can place the general shell script into /magisk/.core/post-fs-data.d to run scripts in post-fs-data boot stage, it is guaranteed to wait till everything is done, plus it is also have a full busybox environment, which would help a lot in some scripting. More details are all in my full documentation.

For SuperSU, the su.d will first try to run in post-fs-data mode, if fails (which it would, some devices doesn't have proper support for the exec command in init.rc), it will fall back to late_start mode.

[roshanravan]

I am glad that you two masters are working together, can you guys also find a solution to bypass zygote process and SafetyNet? Anyways we love you guys, thank you for your time and projects

[rovo89]

Great! Thanks for the detailed answer. I really just had a brief look at how Magisk works. I'll check it out again once the dust has settled with all the bug reports for the Nougat version.

[lwl12]

Is this pr merged into the 3.1.3 installer?

[rovo89]

Nope, still too many incompatibilities that I had to fix first.

[lwl12]

OK, wish you have a wonderful day😋

[prezesvito90-ui]

.