Hiding root and passing Safety Net

Table of Contents


MagiskHide works, but only IF your system is set up correctly and is compatible. In most cases nothing needs to be done except add apps to the Hide list and possibly hide the Magisk Manager itself. Keep reading for lots of tips and tricks.





Basics


Where to start

It’s always a good idea to read through, at least, the release thread for information about what Magisk is and how to get MagiskHide working. Other useful information can be found in the official Magisk Documentation over on GitHub and the support thread.

Known issues

There may be devices that have issues with MagiskHide. Check the release thread for information about currently known issues. While you're there, make sure to also take a look at the FAQ.

Requirements


Magisk can hide


Magisk can not hide


Make sure that your device conforms to the above requirements before continuing.







Hiding root from apps


There's a corresponding section about hiding root from apps and SafetyNet in the official Magisk documentation. That is also very well worth a look.

It might also pay to check out what others have been discussing about the app you are having trouble with. Take a look at the App resources for links to discussions and workarounds for a few select apps that are known to be troublesome when it comes to hiding root.

If you have apps that you need to hide root from, that detect that your device is rooted even if you can pass SafetyNet, here are a few tips (if you can't pass SafetyNet, see the section about SafetyNet). A good aproach would be to try one thing at a time and see if the app in question stops detecting root. No need to try all tips at once...











































Unfortunately, there are apps out there with their own ways of detecting root that may circumvent MagiskHide (also see “More hiding tips”). Magisk is constantly being updated and improved upon though, so it can pay to try again with a new Magisk update.

Hiding the Magisk Manager

This is done by going to the Manager settings and choosing “Hide Magisk Manager”. When this is done, the Manager is repackaged with a random package name and can therefore not be detected by any apps or services looking for com.topjohnwu.magisk. Since v6.1.0 of the Manager, the app name is also changed to simply "Manager" to circumvent apps and services detecting "Magisk" in the app name. If you have the app hidden, but it is still called "Magisk Manager", even though you are on app version v6.1.0+, try unhiding it and hiding it again. The name can't be changed when updating from an earlier version of the Manager if it is already hidden.

You can see if your Manager is hidden on the main screen of the app. Under the information about the latest Manager release there will be a package name consisting of a random string. The “Hide Magisk Manager” option will also be changed to "Restore Magisk Manager" in the settings on a hidden Manager.

Unhiding the Magisk Manager

Go to the Manager settings and choose "Restore Magisk Manager".

You can also unhide the Manager by uninstalling the repackaged Manager and manually install the apk. Get it from the (release thread or GitHub)

Can't hide the Magisk Manager

If you're having issues trying to hide (repackage) the Magisk Manager, this is often caused by having the Manager installed as a system app, either by you or the ROM creator. This is a bad idea... See "Can't hide the Magisk Manager" for more info.

USB/ADB debugging

If you haven’t yet, try disabling USB/ADB debugging to see if this helps you use your root detecting app.

OEM Unlocking

If you haven’t yet, try disabling OEM Unlocking to see if this helps you use your root detecting app.
WARNING On some devices (known: Huawei) both OEM Unlock and an unlocked bootloader is necessary for the fastboot flash command to work. This should not be the case on devices that use vanilla Android (Google), or stay close to vanilla Android. Please exercise caution.

Developer options

If you haven’t yet, try disabling Developer options to see if this helps you use your root detecting app.

Samsung Knox

If you have a Samsung device you have likely triggered Knox when rooting your device. This cannot be undone and it cannot be hidden, so if an app is using the Knox fuse to determine if you have been modding your device there is nothing that can be done.

I don't do Samsung, so I do not know how to determine if an app detects Knox or not, except that it might show up in a logcat. If the app works perfectly with Magisk and MagiskHide on a non-Samsung device, but doesn't on a Samsung it's very probable that it's Knox that is causing issues.

Nothing works

If you can't get it working even though you've tried everything, grabbing a logcat when the app detects root might show something (see "Asking for help/reporting bugs"). Save the log and post it in the General support thread, with plenty of details about the issue. Just make sure you've tried everything first.







App resources


A list of collected sources for discussions and known workarounds for apps that are particularly difficult to hide root from.

Blackberry Apps


Fate/Grand Order


Google Pay


Harry Potter: Wizards Unite


Pokémon Go


Snapchat










SafetyNet


There's a corresponding section about hiding root from apps and SafetyNet in the official Magisk documentation. That is also very well worth a look.

Passing SafetyNet

If everything works out, SafetyNet should pass with no further input from the user, as long as your device fulfills the basic requirements. Nothing needs to be added to the Hide list. You'll see in the Magisk Manager if it works by checking the SafetyNet status. If SafetyNet doesn't pass after enabling Hide, try rebooting (also see “MagiskHide isn’t working”).

Google continuously updates SafetyNet. Currently, no versions prior to Magisk v13.3 will pass SafetyNet without major workarounds.

What triggers SafetyNet?

There are two parts to the SafetyNet check, CTS Profile and Basic Integrity.

Examples of when ctsProfileMatch will report as false (failed):
- Uncertified device (the manufacturer haven't applied for Google certification)
- Unlocked bootloader
- Custom ROM
- Signs of system integrity compromise (rooting, etc)
- Signs of other attacks (Xposed, etc)

Examples of when basicIntegrity will report as false (failed):
- Signs of system integrity compromise (rooting, etc)
- Signs of other attacks (Xposed, etc)

Several (but not all) of the things mentioned above can be hidden by Magisk. See what Magisk can and cannot hide under Basics.

Test MagiskHide

First thing to do is to toggle MagiskHide off and on again. Sometimes MagiskHide stops working temporarily after an update of Magisk or the Manager. If SafetyNet still doesn't pass, make sure MagiskHide is actually working by using a root checker or a root app. Start by making sure the app can detect that your device is rooted. After that, add the app to the Hide list and see if it no longer can detect root. If that is the case, MagiskHide is working on your device. If you can't get it to work, see "MagiskHide Issues".

SafetyNet fails after an update

If SafetyNet starts failing after an update to either Magisk, the Manager or both it's usually fixed by toggling MagiskHide off and on (see ”Test MagiskHide above”). It might be necessary to reboot after toggling the setting off and on.

CTS profile mismatch vs Basic integrity

There are two parts to a SafetyNet check, CTS compatibility and Basic integrity. The CTS check is a server side checkup up that's difficult to spoof, while Basic integrity is done on the device side and is a lower level of security. Some apps only use the Basic integrity part of the SafetyNet API and thus can be used even if SafetyNet doesn't fully pass.

Checking if Basic integrity passes

You can check SafetyNet directly in the Magisk Manager, to see if you at least pass Basic integrity. If you can't pass SafetyNet, but Basic integrity shows as true, that basically means Google doesn't trust your device for some reason (also see "SafetyNet incompatible devices and ROMs" below). You should be able to fix this by matching prop values with a ROM that passes SafetyNet (see "Matching official prop values to pass SafetyNet" and "Spoofing device fingerprint" below).

SafetyNet incompatible devices and ROMs

There are devices/ROM’s that just won’t be able to pass SafetyNet. This might have to do with how the ROM is built, and if so there is nothing the user can do to change it.

But, fortunately, most of the time it is much simpler than that.

All custom ROMs are incompatible with SafetyNet out of the box (unless the ROM creator uses the described method below and uses a certified device fingerprint instead of the on that matches the ROM). This has to do with how Google certifies devices, CTS certification (Compatiblity Test Suite). If a device hasn’t passed the Google certification process, or if the ROM alters how the device is perceived by Google, it won’t be able to fully pass SafetyNet (CTS profile mismatch). You might be able to get basic integrity to report as true (see Checking if Basic integrity passes above) and this would mean that MagiskHide is working as it should and it's most likely a simple CTS certification issue.

You can match your ROM's ro.build.fingerprint (and possibly other props, like ro.build.version.security_patch) with an official ROM for your device, or any other device that is certified, to make it pass SafetyNet fully (see "Matching official prop values to pass SafetyNet" and "Spoofing device fingerprint" below).

Matching official prop values to pass SafetyNet

If you use an unofficial/developers ROM you might have to match an official/stable ROM's details (usually ro.build.fingerprint and possibly ro.build.version.security_patch) to pass SafetyNet (also see "Spoofing device fingerprint" below).

coolguy_16 have made a guide for Moto G 2015 here. Thank you to diegopirate for the tip.

Spoofing device fingerprint

Try changing your device's ro.build.fingerprint to a device's/ROM's that is known to pass SafetyNet. The Magisk module MagiskHide Props Config can do this. This can also be done with a boot script (don't forget to set the proper permissions for the script to execute) and the resetprop tool (also see "Sensitive props").

To change the device fingerprint with a boot script, add the following to a file you place in /data/adb/service.d (and don't forget to set the proper permissions for the script to execute):
#!/system/bin/sh
resetprop ro.build.fingerprint <fingerprint value>


If the device fingerprint is from an Android build after March 16 2018 you'll also have to match that build's Android Security Patch date (ro.build.version.security_patch). This is automatically done by MagiskHide Props Config, but otherwise you can go about it the same way as described above.

The response is invalid

This basically means that your device can't get a proper response from the Google servers, for whatever reason. It says nothing about wether your device actually passes SafetyNet or not...

If you get an invalid response result when checking SafetyNet it might mean that the app you're using to check SafetyNet hasn't been updated to work with the latest version of the SafetyNet API. Your best bet is always to use the Magisk Manager to check the SafetyNet result.

This response might also mean that Google's servers are down at the moment.

Another thing to try is to force close Play Services, clearing it's data and/or rebooting the device.

You could also try using a different GAPPS package (if you're on a custom ROM) or update the Play Services manually by downloading the latest version from APKMirror.

Make sure that you have a proper working internet connection and that there's nothing interfering (firewalls, etc).

SafetyNet check never finishes

If the SafetyNet status check never finishes (make sure to wait a while), it might mean that your Google Play Services aren’t working properly or have crashed. Try force closing Play Services, clearing data and/or rebooting the device.

You could also try using a different GAPPS package (if you're on a custom ROM) or update the Play Services manually by downloading the latest version from APKMirror.

SafetyNet API error

This error is usually caused by the Manager not having internet access or the snet.apk not downloading properly. Try clearing data for the Manager and make sure that you have a working internet connection when starting the SafetyNet check. The Manager need to download the necessary files to be able to do the check and internet access is required to get a response from Google's servers.

Device uncertified in Play store/Netflix (and other apps) won't install or doesn't show up

If some apps won't install or doesn't show up in the Play store, check the Play store settings. At the bottom there might be a section called "Device certification". Some apps won't install if this shows "uncertified" (a couple of known apps are Netflix and Mario Run). It might even be that your device show "certified" and they don't show up. Even if there isn't a "Device certification" section in your version of the Play store, try the below if you have issues with apps like Netflix not installing or showing up.

The solution is to make sure your device passes SafetyNet and then clear data for the Play store and reboot. If you have multiple users on your device, you might have to clear data for all users. Next time you open up the Play store, "Device certification" should show "certified" and the apps should be able to install/show up again. You might have to wait a bit before the apps show up. Some users have reported having to wait mere minutes, others several hours up to a whole day.

Permissive SELinux

MagiskHide can usually mask a permissive SELinux and let you pass SafetyNet anyway. But, it has been reported that this is not successful on all devices. If you have SELinux set to permissive, try changing it to enforcing and check SafetyNet again.

I still can't pass SafetyNet

Start by clearing data for Play Services and the Play Store. There have been reports of this making SafetyNet passing. It's also a good idea to read through the rest of the guide. For example More hiding tips, MagiskHide Issues, Other things to try, Asking for help/reporting bugs and other parts.

Changing ROM or completely wiping your device and starting out clean might also be a good idea.







MagiskHide Issues


Test MagiskHide

First thing to do is to toggle MagiskHide off and on again (a reboot might also be necessary). Sometimes MagiskHide stops working temporarily after an update of Magisk or the Manager. If it still doesn't work, make sure MagiskHide is actually working by using a root checker or a root app. Start by making sure the app can detect that your device is rooted. After that, add the app to the Hide list and see if it no longer can detect root. If that is the case, MagiskHide is working on your device. If you still can't get it to work, see "Asking for help/reporting bugs".

MagiskHide fails after an update

If MagiskHide starts failing after an update to either Magisk, the Manager or both it's usually fixed by toggling MagiskHide off and on (see ”Test MagiskHide above”).

MagiskHide doesnt show in the Manager

Your device’s kernel probably doesn’t have support for mount namespace (see ”Mount namespace issues” below).

MagiskHide isn't working

If you can’t get MagiskHide to work, either for SafetyNet or any other app detecting root, there are a few things you can try. Start by testing if MagiskHide actually works (see "Test MagiskHide" above).

Starting MagiskHide manually

MagiskHide is enabled by default and should start automatically on boot. If it isn’t working, try toggling MagiskHide off and on in the Manager settings. If MagiskHide just won't start when toggling it in the Magisk Manager (check the Magisk log, it might have started but the Manager doesn't reflect it), try starting it manually. This can be done in a terminal emulator (as su) by executing the following commands:
su
magiskhide --disable
magiskhide --enable


Mount namespace issues

If you see this line in the Magisk log (see "Asking for help/reporting bugs"): "proc_monitor: Your kernel doesn't support mount namespace", your device has a Linux kernel that is to old. The Linux kernel version has to be at least 3.8 (thank you TheCech12), or otherwise have the necessary features backported. It is possible to patch the kernel (see "MagiskHide Requirements"). Also, it might be a good idea to ask in your ROM/kernel thread or try a different ROM and/or kernel.

I still can't get MagiskHide to work

Take a look at the rest of the guide, there are more things to try in different sections. For example More hiding tips, Other things to try, Asking for help/reporting bugs and other parts.







More hiding tips


Dependencies

There are some apps that require one or more other apps or processes being added to MagiskHide. So if an app is asking for extra permissions, try hiding the corresponding app/process as well. As an example: for a banking app asking for permissions to make phone calls it might be necessary to add the Phone app as well as the banking app to MagiskHide. Unfortunately it's not necessarily the case that the app or process used for finding root asks for permissions (also see "Figuring out if an app has dependencies, looks for 'sensitive props', Busybox, etc" below).

Sensitive props

Some apps trigger if they find "sensitive props". Also, on some devices SafetyNet triggers if certain props are not set to the expected values. A few props are set to "safe" values by MagiskHide by default. These prop are known to trigger some apps that look for root and "tampered" devices. Currently these are:
ro.debuggable (set to 0 by MagiskHide)
ro.secure (set to 1 by MagiskHide)
ro.build.type (set to user by MagiskHide)
ro.build.tags (set to release-keys by MagiskHide)
ro.build.selinux (set to 0 by MagiskHide)

Some examples of other props to change may include:
ro.build.flavor
ro.build.description
ro.build.fingerprint
ro.bootimage.build.fingerprint
ro.build.oemfingerprint
etc...

Use the command "getprop" (without quotation marks) on the props in a terminal emulator to see what they're set to (see example below). Note that not all props used can be found in build.prop, there's also default.prop, etc.
getprop ro.debuggable

The props can be changed with a Magisk module or with a boot script (don't forget to set the proper permissions for the script to execute) and the resetprop tool.

If you have a ROM (stock is usually a good bet) that can pass SafetyNet or use an app on without modifications, check for props on that ROM that you can change to on the ROM you're having trouble with (also see "Figuring out if an app has dependencies, looks for 'sensitive props', Busybox, etc" below).

Please note that changing prop values may have other consequences for your device than just being able to pass SafetyNet or hide root. If you're experiencing issues after changing prop values, revert them and see if that helps.

Reverting prop values set by MagiskHide

If you for some reason need to reset the prop values that MagiskHide changes (see "Sensitive props" above), you can do this with the Magisk module MagiskHide Props Config. It can also be done by using a boot script that runs the resetprop tool to change back to the desired prop value. Add the following to a file you place in /data/adb/service.d (and don't forget to set the proper permissions for the script to execute):
#!/system/bin/sh
resetprop <property name> <value>

Add whatever property and value you need changed. Changing ro.build.type back to userdebug would look like this:
resetprop ro.build.type userdebug


Busybox

Some apps detect Busybox and see this as a sign of your device being compromised (rooted). Magisk should be able to hide any Busybox installed as a Magisk module. osm0sis has a great Busybox module available in the Magisk repo (install from the Magisk Manager, under "Downloads").

Figuring out if an app has dependencies, looks for "sensitive props", Busybox, etc

It can be tricky figuring out if an app is dependent on another app or process for detecting root, expects certain prop values, doesn't like Busybox or whatever is triggering a root warning within the app. Apart from trying one thing/prop at a time, finding this out could mean you have to decompile the apk to look at the source code (use search), grab a logcat when the app is detecting root, etc.

Detecting apps requiring root

There are apps that detect known apps that require root and refuse to work properly or even start if that is the case. Usual suspects include (but aren't limited to) busybox apps, Xposed installer, root hiding apps, etc.

This can be worked around by uninstalling or possibly freezing (Titanium Backup can do this, among others) the offending root app when you need to use an app detecting root apps and reinstalling/unfreezing it afterwards. Cumbersome, but it might work. There are also some Xposed modules that can hide apps from other apps, but having Xposed installed might cause other issues with tampering detection...

Magisk Core Only Mode

If you can't get MagiskHide to work, try enabling the Core Only Mode in Magisk Manager settings. Only MagiskSU and MagiskHide will be activated, and no modules will load. This is a good way for finding out if it's a module causing your issues without actually uninstalling the module.







Other things to try


Starting fresh

If you've been trying a lot of things and can't get Magisk to work properly it can be a good idea to start fresh. Start by uninstalling Magisk, flashing a clean boot image and installing Magisk again. If that doesn't work you could try wiping your device and starting out completely clean.

Older versions of Magisk

It is possible that an older version of Magisk may work if the latest does not. This is a last resort and should be considered unsupported. If the latest version of Magisk doesn’t work, but an earlier version does, please help fixing the issue by reporting it with all the necessary details (also see "Asking for help/reporting bugs").

Installation files for earlier releases of Magisk can be found on GitHub. If you need other versions, not available for download, the source code for these can be found in the same place, along with instructions on how to build Magisk.

Please note that there’s no guarantee that an older version of Magisk will work with the current Magisk Manager. Compatible apk's can be found inside the Magisk zip and all Manager releases can be found on GitHub.

Nothing works!

If nothing works and you just can't get Magisk to install/function properly on your device, check the troubleshooting section in the release thread for instructions on how to help topjohnwu fix any compatibility issues with your device. The best thing you can do if Magisk isn't compatible with your device is to provide as much details as possible and upload logs (recovery log, Magisk log, logcat, whatever is applicable) and a copy of your boot image in the release thread (also see "Asking for help/reporting bugs").

Canary releases

It's also possible that whatever problem you're facing has been fixed in code, but not yet released. For this you can use the the Canary bleeding edge build. It is a build by topjohnwu that is based on the latest (working) commits from GitHub. Keep in mind that it is a bleeding edge build and may be quite unstable. Only install of you know what you're doing!







Asking for help/reporting bugs


Asking for help

If you can't fix the problem yourself, start by looking in the support thread where you might find that someone else have had this problem as well. Search for your device and/or problem. If you can't find anything (it's a big thread), search again. If you still can’t find anything, provide as much information as possible (in the support thread). For example:







Reporting a bug

When reporting a bug, make sure you have the latest Canary bleeding edge debug build installed on your device. Otherwise any bug you're reporting may already be fixed upstream. It will also have much more detailed logging enabled (see below).

Logs

But what if I can't get logs?
Most of the time you can get some kind of log showing what is going on. Keep reading below to see what tools you have at your disposal.

But, if you really cannot get hold of any logs at least try to give as detailed instructions as possible on how to reliably reproduce the issue.

Which log?
Certain issues require different kinds of logs. Here's a list of examples (see further down for details on how to acquire the logs in question), but it's far from a complete list and only meant as an example of what logs may be useful:
















Get the log















Verbose logging
When reporting about issues and bugs, it's useful to have more verbose logging. To get the most information possible, make sure to install the Canary bleeding edge debug build. It has debug logging active and will show much more useful information. The log is then saved just as the normal Magisk log, described above. When reporting about Magisk bugs, it is required to use the Canary bleeding edge debug build and the verbose logging.

The Magisk log is empty

If your Magisk log is empty, it's likely that you have Android logging disabled. Try enabling it.

Could also mean it's faulty somehow. Try grabbing a logcat and see what happens (see above).

It might also be that your kernel/ROM wipes the /cache directory during boot, thus removing the log. See here for details.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki