MagiskHide - Hiding root and passing Safety Net
Universal SafetyNet fix module
The module is outdated and also replaces Magisk internal busybox with an incompatible one. Not recommended.Or you can use the Universal SafetyNet Fix module. Spoofing the device fingerprint is part of what it does.
Check the logs
Magisk v15+ have introduced a much improved daemon that will restart automaticallyTake a look in the Magisk log. In there you should see something like this (just an example, YMMV):
<log example removed>
If there are no entries in the log about MagiskHide starting, take a look under "Restarting the MagiskHide daemon" below and "Starting MagiskHide Manually".
Restarting the MagiskHide daemon
Sometimes the MagiskHide daemon needs to restart, or haven't properly started on a reboot. Fix this by toggling MagiskHide off and then on again in settings. You can also try disabling MagiskHide, rebooting and then enabling it again.If you previously have had MagiskHide functioning on your device, but suddenly it stops working, it's a good chance the MagiskHide daemon hasn't properly started on boot. Toggle off and on (and possibly reboot) and you should be good. If not, keep reading under "Starting MagiskHide Manually".
MagiskHide isn't unmounting folders as it should
Unmounting of folders is no longer showed in the Magisk log, since Magisk v13.1.If MagiskHide isn't unmounting as it chould for the processes/packages added to the Hide list (there are no "hide_daemon: Unmounted" entries in the log or there are entries showing that the unmount failed ("hide_daemon: Unmount Failed")), see "MagiskHide isn't unmounting folders as it should".
If you don't see any entries in the Magisk log for "hide_daemon: Unmounted", MagiskHide isn't functioning as it should and can't hide Magisk from apps and processes that trigger if root is found. There are a few reasons as to why this might happen. See "Kernel logcat support", "Logger buffer size", and "Mount namespace issues". Of course, these might not be the only reasons. If you're lucky, one of the solutions below will work for your particular case.
If there are entries in the Magisk log showing that the unmount failed ("hide_daemon: Unmount Failed"), take a look at what folder it's failing for and disable the corresponding Magisk module. If you can't work out what module is causing the issue, disable them all and enable one by one until you find the culprit. If it is one of your installed modules causing the issue, ask for advice in the module's support thread.
It might be that you have to rely on manually starting MagiskHide to make it unmount folders properly (known: some Xiaomi devices/MIUI). See "Starting MagiskHide manually".
Magisk v12 can't hide root (but v11.6 could)
The changed prop values have been reintroduced with Magisk v13.1.If you have an app that you can hide root from with Magisk v11.5/v11.6 but not after upgrading to v12, you need to take a look at the "Sensitive props" section. In Magisk v11.5 and v11.6, Magisk Hide would alter a few build.prop values, specifically a couple of the usual suspects mentioned in "Sensitive props". These are ro.build.tags and ro.build.type. This was reverted with Magisk v12 since it has the potential to cause issues and is better left to the users discretion.
So, if you can fool an app with Magisk v11.5/v11.6, but not with v12. Try changing ro.build.tags and/or ro.build.type to "safe" values.
Scripts are no longer used in Magisk v13.1.
If you have a device where you find you have to start Magisk Hide manually to pass SafetyNet, try editing the enable script (found in /magisk/.core/magiskhide) and change the last line to:
This might make Magisk Hide work properly on your device.
Busybox conflict
Busybox is no longer bundled with Magisk since v13.1.If you already have busybox installed or your ROM comes with it built-in, enabling Magisk busybox may cause a conflict that breaks Magisk Hide. Either use and update the existing installation or remove it if you want to use Magisk busybox.
Magisk v13.1+ does not have these issues.
Since beginning of June 2017, SafetyNet has been updated. Magisk v12 and lower versions can't pass. The solution is to enable Core Only Mode in Magisk Manager settings and you might also have to disable systemless hosts. In Magisk v13.0 beta, this has been fixed (but of course, there might be other issues present). Note that this guide is written for Magisk v12 and the tips in it may not be applicable for Magisk v13 beta. I'll update the guide for v13 when it is released from beta.
For users of Magisk v12 Deic have made a Magisk module that might make SafetyNet pass with modules active. Note that this module will also change your device's fingerprint to match a Xiaomi Mi 6 (for devices/ROMs that have no CTS certification), also see "Spoofing ro.build.fingerprint". yochananmarqos have made a version of the module that leaves out the fingerprint part, for users that could pass SafetyNet before the update. See the links for details.
Module link removed from the guide since it does so much more than just editing the fingerprint.
Deic have updated his Xiaomi SafetyNet fix module to be a Universal SafetyNet Fix module that does just this. It'll change your devices fingerprint to match an official one for Xiaomi Mi 6. It'll also make Magisk v12 pass SafetyNet with modules installed.
IMO it'd be best if you could use a fingerprint that more closely matches your device (you'll find it in the build.prop file). If you're on a custom ROM that doesn't pass SafetyNet and the stock ROM does, use the stock ROM's prop values, etc. To change the fingerprint set by the module, unzip it and open up the post-fs-data.sh file in a text editor that can handle Unix line endings (on Windows this means Sublime, Atom, Notepad++ etc). Change the following two lines to match your device's stock ROM:
$RESETPROP "ro.build.fingerprint" "Xiaomi/sagit/sagit:7.1.1/NMF26X/V8.2.17.0.NCACNEC:user/release-keys" $RESETPROP "ro.bootimage.build.fingerprint" "Xiaomi/sagit/sagit:7.1.1/NMF26X/V8.2.17.0.NCACNEC:user/release-keys"
An app still detects the original prop value
No longer applicable.If Magisk Hide doesn't start properly at boot, it can be started by toggling Hide off and on again in settings. But, when doing this, some of the prop values changed by Magisk Hide may not get set properly. Try rebooting your device and see if Hide starts up properly. If it doesn't it might be one of your modules causing issues.
If it's a prop value you're changing yourself with a Magisk module and you're using system.prop to set the value, try moving the script to post-fs-data.sh and use resetprop instead. See here for more resetprop syntax. Example:
system.prop code: ro.build.tags=release-keys post-fs-data.sh code: resetprop ro.build.tags release-keys
Samsung KNOX
Removed from the guide since the feature doesn't seem to work anyway.If you're having issues with Samsung KNOX, use a KNOX checker app from the Play store to see if it reports as triggered or not. Samsung pay and other Samsung apps/services that check KNOX have been reported to still see the KNOX counter as triggered, even though it gets masked by Magisk Hide.
Since Magisk v11.5 resetprop is added to PATH and can be called directly through shell and apps.
/data/magisk/resetprop ro.build.tags release-keys
This part is no longer necessary since Magisk v11.5. It's changed by Magisk by default. Only do this if you're using an earlier release.
Some Samsung users with custom ROMs have reported that they have had to do some modifications to the permissions for a couple of files related to SELinux to pass SafetyNet. These files are "/sys/fs/selinux/enforce" and "/sys/fs/selinux/policy". The "enforce" file should have permission 640 (rw-r-----) and the "policy" file should have permission 440 (r--r-----). This can be easily automated with Magisk's General Purpose Boot Scripts (see here for details) or a Magisk module. The lines needed for the script are:
#!/system/bin/sh chmod 640 /sys/fs/selinux/enforce chmod 440 /sys/fs/selinux/policy
Permissive SELinux
Magisk Hide uses a pseudo-enforcing SELinux state to mask a permissive kernelYou can check if it’s SELinux causing problems by typing (without quotation marks) “getenforce” in a terminal emulator. If it reports permissive you can try temporarily setting it to enforcing by typing “setenforce 1” (this requires root access) and see if this makes SafetyNet pass. To make SELinux permissive again, use “setenforce 0” or reboot your device (if it’s permissive by default). If you want a more permanent solution it can be done with Magisks General Purpose Boot Scripts. See here for details. The lines needed for the script to set SELinux to enforcing are:
#!/system/bin/sh setenforce 1
