Question about systemless modules vs actual modification - Magisk

I'm new to Magisk, and one thing I'm confused about is the role of the various systemless modules.
1. Essentially, is there anything that I *can't* do normally with Magisk (that I would be able to do if it were rooted any other way) that I *have to* have a module for?
For example, when you have modules to have systemless hosts or systemless Busybox - does that mean that when you use Magisk, you *can't* install or work with these things without those modules, or does it mean that you still could do it normally, but the modules just give you an option to do it without actually modifying anything?
2. If the answer is that I can still do everything normally, but the modules just give me the *option* to do it without actually modifying /system, then why does it matter?
For example, I've never minded having an adblock application actually modify the hosts file when I've rooted in the past before Magisk, so what advantage is there to redirecting them to a fake hosts file? If anything, I would think it increases the chance that something will go wrong or that there will be an incompatibility somewhere along the way.

Everything that Magisk does systemlessly can be done in the old and normal way of modifying system files.
The main advantage for me to use Magisk modules is that all the modifications are still there after a system update (since they'll be in the Magisk image which is kept in /data/adb). I won't have to redo them like I used to before Magisk...
For those that care about updating their device through an OTA, systemless modifications will also make sure that will still work, sort of. You'll still have to keep a stock recovery and restore your stock boot image before updating, but with newer devices that's getting a lot easier. More details here: https://topjohnwu.github.io/Magisk/tutorials.html#ota-installation

Didgeridoohan said:
Everything that Magisk does systemlessly can be done in the old and normal way of modifying system files.
The main advantage for me to use Magisk modules is that all the modifications are still there after a system update (since they'll be in the Magisk image which is kept in /data/adb). I won't have to redo them like I used to before Magisk...
For those that care about updating their device through an OTA, systemless modifications will also make sure that will still work, sort of. You'll still have to keep a stock recovery and restore your stock boot image before updating, but with newer devices that's getting a lot easier. More details here: https://topjohnwu.github.io/Magisk/tutorials.html#ota-installation
Click to expand...
Click to collapse
Gotcha! It's not obvious for people new to Magisk whether using a systemless root forces you to do everything in a systemless manner afterwards or not, so I really appreciate your clarifying this.

Haphim said:
Gotcha! It's not obvious for people new to Magisk whether using a systemless root forces you to do everything in a systemless manner afterwards or not, so I really appreciate your clarifying this.
Click to expand...
Click to collapse
No worries. Just want to point out that systemless root isn't Magisk specific. SuperSU and phh's superuser are two examples of root solutions that were systemless long before MagiskSU was a thing...

Related

CM-su still being detected by Magisk, Magisk Hide not working

Hi,
I'm currently so confused as to why my Magisk isn't working. I'm currently running the last CM 13 snapshot for the Galaxy S5 (G900F, klte), and root and Xposed work fine via Magisk.
However, what isn't working is Magisk Hide, and I'm not sure why. However, I'm noticing that even though I fully unrooted cm-su (using SuperSU, in a way that means the only root I can select in Dev Options is ADB only), I'm still getting cm-su detected by Magisk.
I'm confused -- is there anyway I can remove it? I've tried looking through TWRP file manager, but whenever I do so, I can't even see /system/ files, and mounting only mounts to USB, but that's unrelated.
Thanks for any help!
intcompetent said:
Hi,
I'm confused -- is there anyway I can remove it? I've tried looking through TWRP file manager, but whenever I do so, I can't even see /system/ files, and mounting only mounts to USB, but that's unrelated.
Click to expand...
Click to collapse
I don't think SuperSU removes the in-built CM superuser. Use the UNSU zip by osmosis instead. https://forum.xda-developers.com/showthread.php?t=2239421
Also magisk hide will NOT hide Xposed. Yes not even systemless 87.1 Xposed.
SuperSU removed its own root only, CM root is unaffected.
Also, Magisk hide only works with Magisk's own phh root.
And, as far as I know, it can't successfully hide Xposed either. Doesn't matter if it is systemless or not.
Cheers for the replies.
I wasn't aware that Magisk Hide didn't hide Xposed, that's my bad.
As for the presence of CM-SU, SuperSU did do something, as the Developer Options root option is now ADB only while previously it offered the option to Apps too. I'll try unsu.
Here's what I'm meaning btw: imgur.com /a /yTOTw (sorry for the link bypass, there's no other way for me to simply demonstrate the issue) (as you can see in the first screenshot, Magisk detects "cm-su" along with phh. When phh was disabled before I removed cm-su, it only detected cm-su, hence leading me to believe cm-su remains).
e: tried unsu, still cm-su remains. At this point, I'll leave it -- I presume that it's permanently ingrained into the ROM. I've gotten around the restriction I was facing anyway, and I'll adjust. Thanks anyway!
intcompetent said:
Cheers for the replies.
I wasn't aware that Magisk Hide didn't hide Xposed, that's my bad.
As for the presence of CM-SU, SuperSU did do something, as the Developer Options root option is now ADB only while previously it offered the option to Apps too. I'll try unsu.
Here's what I'm meaning btw: imgur.com /a /yTOTw (sorry for the link bypass, there's no other way for me to simply demonstrate the issue) (as you can see in the first screenshot, Magisk detects "cm-su" along with phh. When phh was disabled before I removed cm-su, it only detected cm-su, hence leading me to believe cm-su remains).
e: tried unsu, still cm-su remains. At this point, I'll leave it -- I presume that it's permanently ingrained into the ROM. I've gotten around the restriction I was facing anyway, and I'll adjust. Thanks anyway!
Click to expand...
Click to collapse
If there are SU files in /system/bin and /system/xbin, then CM root was not removed. Not completely.
To actually remove it you have to delete those files.
Pwnycorn said:
If there are SU files in /system/bin and /system/xbin, then CM root was not removed. Not completely.
To actually remove it you have to delete those files.
Click to expand...
Click to collapse
@intcompetent Osmosis's unsu zip removes those files. If those files are still there after flashing the unsu zip, I'd ask in his thread.
knpk13 said:
@intcompetent Osmosis's unsu zip removes those files. If those files are still there after flashing the unsu zip, I'd ask in his thread.
Click to expand...
Click to collapse
Or just remove them manually, jeez. It's just two files.
I've been doing it manually for months and everything works as intended.
As an a closer, there's nothing there. I presume that Magisk is picking up something freaky from somewhere, or something's up, but I'm good guys. I won't need anymore help.
Cheers!
I found this zip around somewhere. I believe it works to remove all root (systemless as well) and I've always flashed it before rooting normally. It should also remove CM root afaik.
As a test, after flashing, check and see if you pass safetynet before installing magisk
intcompetent said:
As an a closer, there's nothing there. I presume that Magisk is picking up something freaky from somewhere, or something's up, but I'm good guys. I won't need anymore help.
Cheers!
Click to expand...
Click to collapse
I
L

PetNoire's SafetyNet Spoofer! (Universal SafetyNet Fix mod)

PetNoire's SafetyNet Spoofer
This module tries to pass SafetyNet on devices/roms that don't.
This started when i put LineageOS on my phone and couldn't play Pokemon GO anymore. much sadness was had.
i searched around for a fix and found universal-safetynet-fix. Awesome! it let me play pokemon again but it broke everything else root related while it was enabled.
So, i worked on updating it to be compatible with magisk 17. and i got it! (download at the bottom)
but, well.. there was a lot in that code that didn't need to be there anymore. (does anyone even use magisk 12?!)
and worse still, my phones stock image used a thumbprint, not a fingerprint. with it in usnf, it didnt even pass basic integrity!
so i got to work and PetNoire's SafetyNet Spoofer was born!
Disclaimer:
I am not responsible for bricked devices, dead SD cards,
thermonuclear war, or you getting fired because the alarm app failed.
I also do not support hacking/altering any other apps with your root powers.
i made this purely to legitimately play a game on a customized system.
Information
Features:
Resets system props to a factory state
spoofs the device fingerprint or thumbprint
has a friendly command tool to change finger/thumbprint settings
Use:
Flash it with TWRP or MM.
by default, it spoofs the same device that unsf did which is enough for most uses. Congrats, you're done!
you can also use the pnss command as root to change, reset, or disable the fingerprint spoofing.
run the 'pnss' command from terminal for usage information
example command:
Code:
su
pnss set thumb MyDeviceThumbprint/8.1/etc/etc
Requeriments
Magisk v17
Installation
Flash the .ZIP from TWRP or MM Module page
Reboot
Known issues
thumbprint mode is only passing BasicIntegrity, not CTS
Donations
If you feel I helped you, you can buy me a coffee here
Credits
@Deic - the original creator of universal-safetynet-fix here
@PetNoire - porting it to magisk 17, breaking it further, and adding thumbprint support
Download
Please DO NOT share the module itself or the download link, share the thread only.
vv
@PetNoire May I ask a favour (as I've done to other users that hav updated @Deic's module to the current template in the past)? If you're going to re-release the module with the current template, at least please fix it so that it no longer replaces Magisk's internal Busybox with it's own. Really bad practice and we never did get @Deic to fix that before he disappeared...
If you need a specific module Busybox, place it in the module folder instead and call the commands from there, or make sure that the users know that they have to install @osm0sis Busybox, or if you're really in a pinch just use the internal Magisk Busybox then, but at least don't replace it with one that have the possibility to mess up Magisk's internal functions.
Also, it would be a good idea if you gave @Deic a bit more credit than you're doing right now (a tiny, tiny link at the top of your post just isn't enough), no matter that he's MIA. All you've really done is to transfer his module to the current template and added a check for the current Magisk version and it's paths. I'd suggest you make that more apparent so you don't risk being accused of passing someone else's work off as your own.
Didgeridoohan said:
@PetNoire May I ask a favour (as I've done to other users that hav updated @Deic's module to the current template in the past)? If you're going to re-release the module with the current template, at least please fix it so that it no longer replaces Magisk's internal Busybox with it's own. Really bad practice and we never did get @Deic to fix that before he disappeared...
If you need a specific module Busybox, place it in the module folder instead and call the commands from there, or make sure that the users know that they have to install @osm0sis Busybox, or if you're really in a pinch just use the internal Magisk Busybox then, but at least don't replace it with one that have the possibility to mess up Magisk's internal functions.
Also, it would be a good idea if you gave @Deic a bit more credit than you're doing right now (a tiny, tiny link at the top of your post just isn't enough), no matter that he's MIA. All you've really done is to transfer his module to the current template and added a check for the current Magisk version and it's paths. I'd suggest you make that more apparent so you don't risk being accused of passing someone else's work off as your own.
Click to expand...
Click to collapse
Thanks for the tip on busybox. I thought it was pretty weird that it replaced it like that for 2 commands but was more concerned about getting it to work at all. I'll look into fixing that soon.
update: i think i almost have it working on magisk's busybox but still working out some bugs.
And I'll edit it to give him some more credit right away.
PetNoire said:
Thanks for the tip on busybox. I thought it was pretty weird that it replaced it like that for 2 commands but was more concerned about getting it to work at all. I'll look into fixing that soon.
Click to expand...
Click to collapse
That would be great.
I thought I'd give some insight into what the module actually does, for those that are wondering, since it might get lost in translation between the different updates to the module by others than @Deic.
The USNF module is made up of two parts. For one, it changes the device fingerprint to a certified one to pass the ctsProfile check (the in-built one is a Xiaomi print, but IIRC you can also use the device stock fingerprint if it's already certified). This is also something that can be done with a Magisk boot script (post-fs-data.d or service.d) and the resetprop tool:
Code:
resetprop ro.build.fingerprint <certified fingerprint value>
There are also Magisk modules available that do the same thing (apart from USNF).
Device Spoofing Tool by @Dreamer(3MF) is one (although it also changes a whole lot of other props to simulate a OnePlus 2).
And there's also my MagiskHide Props Config that changes the build fingerprint to one of your choice.
Or, if you don't care about the systemlessness, you can directly edit your build.prop file and change the current ro.build.fingerprint to a certified one.
So, for the device fingerprint and passing the ctsProfile there are a few options.
The second part of USNF is the custom MagiskHide (as described in the OP). The thing here though, is that for the majority of devices it is not necessary anymore, since (as it also says in the OP) @topjohnwu have fixed most of those issues. From what it seems, from user reports in different threads, this is only necessary on some MIUI releases (Xiaomi devices). The module actually started out as a "Xiaomi SafetyNet fix" (check the module id), but the build fingerprint part turned out to be useful for other devices, so @Deic changed the name to "Universal". All other devices should be good with only changing the device fingerprint.
So far, it doesn't seem like the custom MagiskHide from the module is interfering in any way with the real thing. But, considering that it hasn't been updated in over a year, who knows.
Class dismissed.
Is there any reason to keep the code for old magisk? Does anyone still use 12-14?
Seems to have helped on my S8 with KingROM
My Magisk updated to 17.1 and then GooglePay started getting upset that I had rooted, mucked around with various things including the 'MagiskHide Props Config' module which my S8 never seems happy with (random reboots when installed) but this seems to do the trick.
I installed via Magisk Manager but it seemed to kill the Magisk install when I rebooted, reinstalled Magisk and now all seems ok so a big thumbs up from me
I wonder how the magiskhide part (at least the "add", etc. scripts) can work, because you use the old outdated "/magisk"-folder, that is no longer supported since 16.3 (or so).
Oberth said:
My Magisk updated to 17.1 and then GooglePay started getting upset that I had rooted, mucked around with various things including the 'MagiskHide Props Config' module which my S8 never seems happy with (random reboots when installed) but this seems to do the trick.
I installed via Magisk Manager but it seemed to kill the Magisk install when I rebooted, reinstalled Magisk and now all seems ok so a big thumbs up from me
Click to expand...
Click to collapse
For some reason it doesn't always work the first time. Usually just rebooting fixes it.
jenslody said:
I wonder how the magiskhide part (at least the "add", etc. scripts) can work, because you use the old outdated "/magisk"-folder, that is no longer supported since 16.3 (or so).
Click to expand...
Click to collapse
I thought I changed it all. You sure there isnt some kind of version check? I'll look at it later
Again first goal was to get it working. Next goal is to make it awesome
Hmm.. this doesn't work with my phone (HTC one M8). After I flashed it, wiped cache (TWRP), it said "complete" on the log, then it will never boot to my OS, stuck on the HTC logo, no boot animation. I use TWRP
winzzzzz said:
Hmm.. this doesn't work with my phone (HTC one M8). After I flashed it, wiped cache (TWRP), it said "complete" on the log, then it will never boot to my OS, stuck on the HTC logo, no boot animation. I use TWRP
Click to expand...
Click to collapse
In-Case Of Facing A Bootloop/Bootscreen Issue Due To Flashing A Module, Download CoreOnlyMode4Magisk From This Thread https://forum.xda-developers.com/apps/magisk/module-core-mode-bootloop-solver-modules-t3817366 Then Flash It Thru TWRP Recovery.
winzzzzz said:
Hmm.. this doesn't work with my phone (HTC one M8). After I flashed it, wiped cache (TWRP), it said "complete" on the log, then it will never boot to my OS, stuck on the HTC logo, no boot animation. I use TWRP
Click to expand...
Click to collapse
Does it boot after disabling the module?
From twrp>advanced>terminal:
HTML:
Mount -o loop /data/adb/magisk.img /mnt
Touch /mnt/universal-safetynet-fix/disable
The reboot
so.. i kind of deleted the whole magiskhide clone from the module and just left the prop configs and its totally passing safetynet now. so i guess the normal magiskhide is enough and is just missing some prop resets.
@PetNoire I still failed to pass safetynet, When I flashed the module, my magisk was erased, but then I just saw from this thread that a reboot is needed. After reboot my magisk came back, but It' says "Requires Additional Setup" I ignore it and then checked if safetynet will pass, It failed.
I'm using stock CM FLARE S4 ROM android 5.1.
Sorry for my English.
Thankyou for the reviving this module. :good:
Godbless you.
PetNoire said:
so.. i kind of deleted the whole magiskhide clone from the module and just left the prop configs and its totally passing safetynet now. so i guess the normal magiskhide is enough and is just missing some prop resets.
Click to expand...
Click to collapse
That was kind of the point of my longish text above... All you need to pass on a device that doesn't fully pass SafetyNet (ctsProfile fails while basicIntegrity passes), is usually just to change ro.build.fingerprint to a certified fingerprint (and there are several ways to go about that, but the Magisk way always involves the resetprop tool somehow). Custom ROMs, developer versions of OEM firmwares (Oneplus 6 beta, for example), and otherwise uncertified devices can usually pass SafetyNet like this.
Didgeridoohan said:
That was kind of the point of my longish text above... All you need to pass on a device that doesn't fully pass SafetyNet (ctsProfile fails while basicIntegrity passes), is usually just to change ro.build.fingerprint to a certified fingerprint (and there are several ways to go about that, but the Magisk way always involves the resetprop tool somehow). Custom ROMs, developer versions of OEM firmwares (Oneplus 6 beta, for example), and otherwise uncertified devices can usually pass SafetyNet like this.
Click to expand...
Click to collapse
This was just the first one that gave me any success so I initially assumed it was because of the hiding. I wasn't even able to pass basic integrity without this one and most others didn't help either. I tries yours at one point with no success. Do you change all the "dangerous props" that this one does?
PetNoire said:
This was just the first one that gave me any success so I initially assumed it was because of the hiding. I wasn't even able to pass basic integrity without this one and most others didn't help either
Click to expand...
Click to collapse
Basic integrity passing has nothing to do with the device fingerprint or other props. With Magisk, that usually means that MagiskHide isn't working (for whatever reason, most of the times it just needs a restart) or you have something installed that MagiskHide can't hide (like Xposed, remnants of other kinds of root, etc).
Edit: Scroll down a little here for a table of examples of what will cause a true or false cts profile or basic integrity response.
https://developer.android.com/training/safetynet/attestation#compat-check-response
iamcurseal said:
@PetNoire I still failed to pass safetynet, When I flashed the module, my magisk was erased, but then I just saw from this thread that a reboot is needed. After reboot my magisk came back, but It' says "Requires Additional Setup" I ignore it and then checked if safetynet will pass, It failed.
I'm using stock CM FLARE S4 ROM android 5.1.
Sorry for my English.
Thankyou for the reviving this module. :good:
Godbless you.
Click to expand...
Click to collapse
I don't know what Tue additional setup does, but I always do it and its been working. Also your device may have thumbprint props instead of fingerprint.
Run this in a terminal and let me know what you get
Code:
getprop | grep print
PetNoire said:
I tries yours at one point with no success. Do you change all the "dangerous props" that this one does?
Click to expand...
Click to collapse
My module changes all the common fingerprint props, but as far as I know, it's only ro.build.fingerprint that is important for the ctsProfile check.
Didgeridoohan said:
Basic integrity passing has nothing to do with the device fingerprint or other props. With Magisk, that usually means that MagiskHide isn't working (for whatever reason, most of the times it just needs a restart) or you have something installed that MagiskHide can't hide (like Xposed, remnants of other kinds of root, etc).
Edit: Scroll down a little here for a table of examples of what will cause a true or false cts profile or basic integrity response.
https://developer.android.com/training/safetynet/attestation#compat-check-response
Click to expand...
Click to collapse
I wiped all partitions, installed lineage 15, installed magisk and enabled hide and it wouldn't pass basic at any point. Even still its never passed it without this module. It didn't even pass it on the clean install, before magisk

Is Magisk Faux root?

I have been rooting my Androids since the original G1 and obviously have always used a traditional root method. I have been trying to do some research on what to do with my next device, traditional root or systemless. The obvious advantage of systemless is passing safety net and probably not have to worry about using root cloak, although root cloak still serves me well to this day. The disadvantages I have found is that because Magisk doesnt actually modify system files it just puts a modified file over the existing one on boot you cannot actually simply go into say root explorer, take any file on the system partition and modify it. Which to me seems like a major disadvantage to anyone who likes to modify files in the system partition. I mean something as simple as swapping out a font file is not longer just a copy paste and change permissions. Am i completely off base on this thinking? Please correct me if I am wrong. The only part that seems to be a huge disadvantage to true root is no one is actually developing SuperSU anymore now that ChainFire sold it from what I understand but there is still the old school superuser app that i believe was open source and could be developed on, as I understood the Superuser apps only denied or granted superuser authority did not actually root the device in the first place anyway.
First of all, SuperSU was systemless root long before Magisk...
I believe you're confusing MagiskSU with Magisk modules and Magic mounting. It's perfectly possible to alter /system while Magisk is installed, as long as you don't have a module that is magic mounting files over that particular part of /system. If that's the case, you'll just be trying to alter the Magisk mask instead of the actual files. If you're not using modules, or if you keep Core Only Mode enabled this won't be an issue.
But, even with magic mounting active you've got full access to the original /system files in /sbin/.magisk/mirror.
Didgeridoohan said:
First of all, SuperSU was systemless root long before Magisk...
I believe you're confusing MagiskSU with Magisk modules and Magic mounting. It's perfectly possible to alter /system while Magisk is installed, as long as you don't have a module that is magic mounting files over that particular part of /system. If that's the case, you'll just be trying to alter the Magisk mask instead of the actual files. If you're not using modules, or if you keep Core Only Mode enabled this won't be an issue.
But, even with magic mounting active you've got full access to the original /system files in /sbin/.magisk/mirror.
Click to expand...
Click to collapse
ah yes i do recall hearing about systemless SuperSU but it seemed that it just installed SuperSU on the user partition and not as a system app and still allowed modifying the system partition. Sorry for my ignorance about this just tough to google how magisk actually works compared to normal root. So if I have magisk it is systemless root but I can still modify the system partition? Thats good to know. What about when it comes to Xposed, can you use normal Xposed with systemless root or do you have to use systemless xposed? Im currently running lolipop with full root and xposed framework but have a new device with Oreo that Ill probably give Magisk a shot with I just want to know the differences I should expect with what you can and cannot do.
Joe333x said:
ah yes i do recall hearing about systemless SuperSU but it seemed that it just installed SuperSU on the user partition and not as a system app and still allowed modifying the system partition. Sorry for my ignorance about this just tough to google how magisk actually works compared to normal root. So if I have magisk it is systemless root but I can still modify the system partition? Thats good to know. What about when it comes to Xposed, can you use normal Xposed with systemless root or do you have to use systemless xposed? Im currently running lolipop with full root and xposed framework but have a new device with Oreo that Ill probably give Magisk a shot with I just want to know the differences I should expect with what you can and cannot do.
Click to expand...
Click to collapse
Yes you can use normal xposed on systemless root, systemless root basically roots by patching the kernel's ramdisk with the SU binary them magisk just install it's remaining binaries in the data partition and them proceeds to hide them through some Linux mounting tricks (it's just a simplified explanation) it's still normal root but the system partition gets intact,magisk and it's modules (in it's repository) use systemless installations as to hide from integrity checks like safetynet and allows you to more easily retain mods during rom updates,other than that magisk is just root with module and hiding functionality
---------- Post added at 12:53 AM ---------- Previous post was at 12:46 AM ----------
Joe333x said:
ah yes i do recall hearing about systemless SuperSU but it seemed that it just installed SuperSU on the user partition and not as a system app and still allowed modifying the system partition. Sorry for my ignorance about this just tough to google how magisk actually works compared to normal root. So if I have magisk it is systemless root but I can still modify the system partition? Thats good to know. What about when it comes to Xposed, can you use normal Xposed with systemless root or do you have to use systemless xposed? Im currently running lolipop with full root and xposed framework but have a new device with Oreo that Ill probably give Magisk a shot with I just want to know the differences I should expect with what you can and cannot do.
Click to expand...
Click to collapse
And if you are wondering how systemless mods (magisk modules) work they are basically 'mirrored' to the system partition during start up but the module itself is in the data partition
DanGLES3 said:
Yes you can use normal xposed on systemless root, systemless root basically roots by patching the kernel's ramdisk with the SU binary them magisk just install it's remaining binaries in the data partition and them proceeds to hide them through some Linux mounting tricks (it's just a simplified explanation) it's still normal root but the system partition gets intact,magisk and it's modules (in it's repository) use systemless installations as to hide from integrity checks like safetynet and allows you to more easily retain mods during rom updates,other than that magisk is just root with module and hiding functionality
---------- Post added at 12:53 AM ---------- Previous post was at 12:46 AM ----------
And if you are wondering how systemless mods (magisk modules) work they are basically 'mirrored' to the system partition during start up but the module itself is in the data partition
Click to expand...
Click to collapse
Thanks for the explanation I appreciate it, so now i guess my only question left is after I use magisk to root and then modify a file on the system partition will I now not pass safety net? I typically dont care about passing since I havent in years but just figured its a question worth asking.
Joe333x said:
Thanks for the explanation I appreciate it, so now i guess my only question left is after I use magisk to root and then modify a file on the system partition will I now not pass safety net? I typically dont care about passing since I havent in years but just figured its a question worth asking.
Click to expand...
Click to collapse
If you are on an old device it's possible you still will pass,but sometimes altering an file on the conventional way will trip safetynet,that's why systemless modules are a thing
Just altering regular files shouldn't affect things though. It usually takes ROM level alterations...

Rooting with SuperSu?

I used SuperSu many, many years ago and figured I would give it a try an old e5 Plus that's been collecting dust in a junk drawer. Using Platform Tools, TWRP and a SuperSu zip the whole process took maybe 10 minutes.
I noticed that all of the guides here use Magisk and they look fairly complicated for the average user. Is there a reason why it's favored over SuperSu? Now that I'm rooted, can I use Magisk and all of its features (modules, etc)?
SuperSU is more easily detected by banking apps, Netflix, Disney+, Google Pay etc. As it modifies the system partition while Magisk is a system-less root.
dbohnine said:
Now that I'm rooted, can I use Magisk and all of its features (modules, etc)?
Click to expand...
Click to collapse
I think you can install Magisk using the SuperSU root. But anyway if you want to use Magisk features, you will need to install Magisk.

Question Clarification help

Been out of the rooting scene since the Droid RAZR HD, had a chance on my Pixel 1 but passed it up. Now im getting back into it and theirs a LOT of changes and some things dont have full guides or are missing pieces. Steps so far: Unlock Bootloader -> Patch image with Magisk -> Flash patched image to gain root -> Enabled Zygote to setup bypassing safety net check/basic integreity/CTS profile match ( is it worth it if i only use one app affected by it?). Currently looking at Magisk modules and wondering if i also want LSposed or EDsposed which requires RIRU, correct? If i have Zygisk enabled this makes RIRU incompatible, correct? So no Xposed/EDsposed/LSposed modules unless i use Magisk 25.1 Delta version, (Comes with Zygote bootloop protecion) that re-enables magisk hide and can make RIRU work again? Still hazy on the a/b slots with no official TWRP to use and how to flash ROMS and update them without breaking things, Google really messed things up with project treble, geez. Also, anything else i want to take care of at the moment? Thanks.
C00ljoe said:
Been out of the rooting scene since the Droid RAZR HD, had a chance on my Pixel 1 but passed it up. Now im getting back into it and theirs a LOT of changes and some things dont have full guides or are missing pieces. Steps so far: Unlock Bootloader -> Patch image with Magisk -> Flash patched image to gain root -> Enabled Zygote to setup bypassing safety net check/basic integreity/CTS profile match ( is it worth it if i only use one app affected by it?). Currently looking at Magisk modules and wondering if i also want LSposed or EDsposed which requires RIRU, correct? If i have Zygisk enabled this makes RIRU incompatible, correct? So no Xposed/EDsposed/LSposed modules unless i use Magisk 25.1 Delta version, (Comes with Zygote bootloop protecion) that re-enables magisk hide and can make RIRU work again? Still hazy on the a/b slots with no official TWRP to use and how to flash ROMS and update them without breaking things, Google really messed things up with project treble, geez. Also, anything else i want to take care of at the moment? Thanks.
Click to expand...
Click to collapse
this does work
https://forum.xda-developers.com/t/...ootloader-update-root-pass-safetynet.4356221/
unlock the spoiler at the bottom to pass safetynet.
download the two modules from the github.
place them on the phone.
in magisk enable zygisk and deny list
load the modules inside magisk 25.1
i did them one at a time rebooting after each.
go back into magisk enable enforcing deny list.
top right show system apps
check mark any banking/gpay
check mark google store and play services.
reboot. it should pass safetynet and be certified. i have only tested this with google pixel experience rom.
to load a custom rom. you fastboot -w (from factory rom) then fastboot boot twrp.img. go to advanced and adb sideload. then adb sideload the custom rom you want. ignore errors that print in twrp and reboot. all of the aosp roms have their own custom recovery that they load. so you can use their recovery to adb sideload magisk.apk or rename it to zip and flash it.
note all screen locks/pin locks/swipe locks/finger print locks/face locks must be disabled before starting this process. twrp can't remove them. due to decryption not fully functional yet in twrp
Okay thanks. What about RIRU and Xposed/Edsposed/LSposed modules or have you not messed with them? After i flash LineageOS, will I loose root or retain it? Will flashing a new ROM with mess anything up besides the lock screen issue you mentioned? By " loading the modules in magisk 25.1" do you mean the safety net fix and cts profile spoof modules? What are you most used or most recommended apps that require root. Thanks
LSPosed has both zygisk and Riru variants. Not sure on compatibility with the XPosed modules though.

Categories

Resources