Hiding root and passing Safety Net
I am no longer involved in the Android modding scene and haven't been for some time. I don't have the energy or will to take it up again... This guide will no longer be updated.
If anyone feels like taking over, give me a holler.
So long and thanks for all the fish.
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 enable MagiskHide (since Magisk v20.4 it is disabled by default), add whatever apps or services that detect root 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.Requirements
- Enabled MagiskHide (from Magisk v20.4 it is disabled by default).
- A Linux kernel version of at least version 3.8 or a kernel that has the necessary features (mount namespace) backported. For kernels lacking this feature, the relevant patches are: set CONFIG_NAMESPACES=y in defconfig, and apply this patch. More info in this article: Namespace file descriptors.
Magisk can hide
- Magisk and most modules (it depends on what the module does).
- MagiskSU.
- Unlocked bootloader on device not using hardware backed key attestation (also see under "Magisk can not hide").
- Permissive SELinux (most of the time. There have been reports that a permissive SELinux triggers SafetyNet even with MagiskHide enabled). But, just don't keep SELinux permissive... It's never a good idea.
- Some prop values (see "Sensitive props").
- The Magisk app (separate option in the app settings).
Magisk can not hide
- Other known root apps (see "Detecting apps requiring root").
- Remnants of previous root method, including any root management apps (a good way to remove most remnants of root is osm0sis unSU script).
- Files and folders on your device (TWRP, Titanium Backup, etc, see Files on the internal storage).
- Unlocked bootloader on devices using hardware based key attestation (see Unlocked bootloader).
- A tripped Samsung Knox counter.
- Xposed (deactivate it or uninstall). It doesn't matter if it's systemless, Magisk can't hide it.
- EdXposed. Detection of EdXposed can sometimes be worked around with newer release of EdXposed and/or features like the EdXposed Manager blacklist.
- USB/ADB Debugging (disable under Developer options in Android settings).
- Developer options.
- Some Magisk modules - Depending on what the module does, it may not be able to be hidden by MagiskHide.
- Some modifications to /system. Make sure to use Magisk modules so that any modifcations you do are systemless...
Make sure that your device conforms to the above requirements before continuing.
Hiding root from apps
First, it might 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...
It is quite common for apps to update with new detection methods and new ways of circumventing MagiskHide surfaces from time to time. So, if an app has been working before and suddenly starts detecting root after an update, it might pay to go through the list again and try the tips available or test the latest Canary update. Here's an example of a current detection method that MagiskHide can't deal with (one of several that are currently known): https://github.com/topjohnwu/Magisk/issues/2406
If the app you're using has implemented one of these detection methods there's likely not much you can do at the moment. If you're capable, analysis of these methods are always welcome and any useful information can be posted on the Magisk Github repo, either as an issue or a pull request.
- Make sure MagiskHide is enabled (since Magisk v20.4 it is disabled by default) and works, if you haven't already. Easiest is to add an app that uses root to the MagiskHide list. If it no longer can detect that your device is rooted, MagiskHide works. If it doesn't work, the first thing to test is to toggle MagiskHide off and on again (also see "Test MagiskHide"). Without MagiskHide active and working, apps may trigger on many things. See "Magisk can hide".
- Make sure that the app in question is selected in the Hide list (Under MagiskHide in the Magisk app). But, don't go crazy... Only add those apps that actually detect root. If you add too many unnecessary apps and processes you will very likely experience system instabilities (also see "System instabilities")
- Note that this is only possible on Android 5+. Many apps look for the Magisk app as a sign of your device being rooted. For this you can use the feature to hide the app (repackage it with a random name), see “Hiding the Magisk app” below. If the app still detects Magisk, first make sure that the hiding of the app actually worked and that you haven't ended up with two Magisk apps installed. Unfortunately, the way that Android works, it is almost impossible for an app to completely hide from other apps and services without advanced hacks (like Xposed). If an app still can detect Magisk, even if you have it on the Hide list, the app is repackaged and everything else from this list of tips is ok, try to uninstall the Magisk app and see if this helps. If that works, you might be out of luck and the only way to fully use the app in question is to regularly uninstall and then reinstall the Magisk app... But, before saying that for sure try using an isolation app (see "Isolation Apps" below) to make sure the troublesome app can't detect other apps on your device
- Also make sure that your device conforms with the basics for MagiskHide to work and take a look at what Magisk can and cannot hide (also see "Basics").
- Passing SafetyNet, both CTS profile and basic integrity, is a good start. That way you know that MagiskHide is working and the apps that do use SafetyNet won't trigger that way. See SafetyNet for more details on that.
- Some methods may check for an unlocked bootloader. Magisk have always been successful at hiding the bootloader state, but since March 2020 Google have shown us that they are implementing proper hardware key attestation where it will be impossible for Magisk to hide the bootloader state anymore. Currently, Google have not yet fully implemented this, but will likely do so soon. Once this is done it will be impossible to pass the CTS profile of SafetyNet and as a result to hide from any app or service that use SafetyNet. See the Unlocked bootloader in the SafetyNet section for more details and possible workarounds.
- Make sure you're up to date with the latest Magisk version. Magisk and MagiskHide is constantly being improved upon and there might have been changes that impact the app you're trying to hide root from.
- Also, if MagiskHide suddenly stops working after an update to Magisk or the Magisk app, try toggling MagiskHide off and on again in the app settings.
- It might also be worth to try the latest Canary bleeding edge build. It might have been updated with an improved MagiskHide. You'll find the apk for the Canary app on GitHub.
- You may also have to clear data for the app in question since some apps “remember” root after finding it the first time.
- One way apps may detect Magisk is by using isolatedProcess in their services to prevent MagiskHide from detecting that they're running (details here). This can be worked around though, since we have root (as topjohnwu have said: "we are root, we are not limited"), with vvb2060's Riru module Enhanced mode for MagiskHide, or if you do not want to use EdXposed/LSPosed you can try to disable the service that is using isolatedProcess with apps like App Manager or Servicely. Unfortunately, finding which service to disable can be the hard part of this method, since you might have to go through a bunch of processes in the app to figure out which one it is. And on top of that the service name might change whenever there's an update to the app. Hopefully, topjohnwu's plans to change Magisk to use zygote injection rather than ptrace in a future release of Magisk should make MagiskHide capable of dealing with this natively.
- Using a custom ROM may sometimes trigger apps. Popular ROMs like LineageOS are particularly affected. The detection methods will differ, but it could be something as simple as running a general getprop command and filter on "lineage". Also see "Prop values" further down.
- If your device isn't encrypted there are apps that will refuse to work. I currently do not know if there are any ways of hiding the fact that the device is unencrypted (prop changes, etc).
- Some apps also detects other root apps on your device (TitaniumBackup, Xposed/EdXposed, etc) and stop working if they detect these. You can test by uninstalling these apps (also see "Detecting apps requiring root"). You might be able to use a Work Profile app or isolation app to get around this issue (see "Isolation apps" below).
- Another popular variant of root detection is that the app looks through your internal storage and triggers if it finds any files or folders that may hint at you having a rooted device (Titanium backup, TWRP, Magisk zips, etc). You can either delete or rename these files and folders, or use a Work Profile app or isolation app to get around this issue (see "Isolation apps" below). If you want to find all files of a particular name (for example Magisk related files), you can use the find command in a terminal:That will find all files or directories on your internal storage that contains the string "magisk" (case insensitive).
find /sdcard/ -iname "*magisk*"
- MagiskHide does not work on apps installed to adoptable/external storage. Any apps you want to hide root from has to be installed to the internal storage.
- Most Magisk modules can be hidden by MagiskHide, but that depends on exactly what the module does. If you can't figure out what is triggering an app, try disabling all modules. If the app no longer triggers you can enable your modules one by one until you find the culprit. Xposed and EdXposed are two well known mods that can't be fully hidden by Magisk.
- The app may also rely on other apps/services that detect root (also see "Dependencies").
- If you've previously had your device rooted with a different root solution it is possible that there are remnants of that triggering whatever app you're having trouble with. Uninstall any superuser management app you might still have and run osm0sis' unSU script to remove any traces. Magisk should reinstall itself, but if not you can just reinstall.
- Some apps will connect to an external web service that performs the check for it. This might mean that adding the app to the Hide list or repackaging the Magisk app won't help. One solution to this issue is to simply block the connection to the web service. One way is to use Magisk's Systemless Hosts and AdAway's "Log DNS requests" feature to figure out what domain to block. You can then add this domain directly to the AdAway blacklist and apply the hosts file. Keep in mind that you're disabling part of the apps security. See this thread for an example.
- Update your device to a newer Android version. It is not possible to fully prevent detection on devices with Android versions lower than 7.0 (and the Magisk app can only be hidden on Android 5+).
- From Magisk v19.4 this detection method is no longer possible, but I'll leave the tip in here for those who refuse to update (for whatever reason). There is a very simple but currently effective detection method that started surfacing recently. It's easily circumvented by simply running the following command in a terminal: This will prevent the apps that use this method to read the file. The command needs to be run at every boot, so as not to have to do it every time it is very convenient to put the command (without the "su -c" part since it isn't necessary to call su in the boot scripts) in a service.d boot script.
su -c chmod 440 /proc/net/unix
- It was discovered by topjohnwu that many OEMs ship their devices with a broken implementation of how /proc is handled and thus there are procfs leaks letting apps monitor information about other processes on your device (see here for an in-depth write-up) . This will let those apps detect Magisk... Since Android 7.0 this is not supposed to be allowed, but manufacturers being manufacturers, and whatever. From Magisk v18.0 MagiskHide will fix the leak on any Android 7.0+ devices. Unfortunately, nothing can be done about this on earlier Android versions.
- There's always a possibility that the ROM you are using have some props that makes it possible for an app or service to decide if your device is "compromised" or not. An example is persist.sys.root which can be found on some ROMs (Lineage) and need to be set to 0. That is just an example though, and determining if other props is being detected require a lot of analysing. Changing props can be done directly in the prop files (if /system can be mounted rw on your device), by a Magisk boot script or with the Magisk module MagiskHide Props Config.
- It has been reported that some apps go to extremes and blacklist your device with the bank/service provider/etc. If that's the case you're likely going to have to reflash your device or otherwise change your device id to get around it. This is kind of uncommon though. Consider it a last resort.
- If none of the above works, try disabling USB debugging, OEM Unlocking (see "OEM Unlocking" below before doing that), developer options, etc (see ”Magisk can not hide”). There are also apps that need a little more TLC when trying to hide root from them. Take a look at App Resources below. Also keep reading the rest of the guide...
Hiding the Magisk app
Keep in mind that full obfuscation of the Magisk app is only possible of Android 9 and newer versions. If full obfuscation is possible, the app will install a stub app that loads the rest of the app dynamically from it's own data folders. There is nothing in the stub that can be identified as the Magisk app.Hiding the app is done by going to the app settings and choosing “Hide Magisk app”. When this is done, the app 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 app, the app name is also changed, by default to "Settings" (in earlier releases this was "Manager") to circumvent apps and services detecting "Magisk" in the app name, but you can pick your own app name as well to make the app completely anonymous. If you have the app hidden, but it is still called "Magisk app", 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 than that if it is already hidden.
You can see if your app is hidden on the main screen of the app. Under the information about the latest app release there will be a package name consisting of a random string. The “Hide Magisk app” option will also be changed to "Restore Magisk app" in the settings on a hidden app.
Unhiding the Magisk app
Go to the app settings and choose "Restore Magisk app".You can also unhide the app by uninstalling the repackaged app and manually install the apk. Get it from the (release thread or GitHub)
Can't hide the Magisk app
If you're having issues trying to hide (repackage) the Magisk app, this is often caused by having the app installed as a system app, either by you or the ROM creator. This is a bad idea... But, there might be other reasons as well. See "Can't hide the Magisk app" for more info.Isolation apps
If an app is detecting the hidden Magisk app or other root apps or files/folders on your device that hint at a rooted/modified device, you might be able to use an isolation app to prevent it from doing this. There are a few different apps you can use. There's Storage isolation that can be used to gain full controll of what parts of your internal storage an app can see. You can also isolate apps in a Workspace profile with apps like Island or Shelter (of which the latter is open source, yay).There are also many different ways of isolating apps and processes using Xposed/EdXposed/LSPosed. See below for more.
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. Be careful with this option though. There is a chance that it can cause issues.WARNING 1 On Samsung devices, toggling OEM Unlocking might be enough to lock the bootloader. This might mean you end up with a device that can't boot.
WARNING 2 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.Riru/Xposed/EdXposed/LSPosed and root hiding modules
It might also be possible to use Riru orXposed/EdXposed/LSPosed modules to help hide root from apps. This is a constantly developing field, so I won't list available modules here. You can search yourself and take a look at that might be available. It is possible that Riru/Xposed/EdXposed/LSPosed itself will be detected though...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
Microsoft
Pokémon Go
Snapchat
SafetyNet
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 can see in the Magisk app if it works by checking the SafetyNet status, or in the SafetyNet checker of your choice (just make sure that you use one that is properly updated to check the SafetyNet status). If SafetyNet doesn't pass after enabling Hide, try rebooting (also see “MagiskHide isn’t working”).Google continuously updates SafetyNet, so just because you can pass toda it doesn't mean you will tomorrow.
Prerequisites
To be able to pass SafetyNet you need to have Google's Services installed. MicroG won't cut it...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, EdXposed, LSPosed, etc)
Examples of when basicIntegrity will report as false (failed):
- Signs of system integrity compromise (rooting, etc)
- Signs of other attacks (Xposed, EdXposed, LSPosed, 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 make sure that MagiskHide is enabled (since Magisk v20.4 MagiskHide is disabled by default), or if it is on toggle MagiskHide off and on again. Sometimes MagiskHide stops working temporarily after an update of Magisk or the Magisk app. 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".It can of course also be any other mod that you've done to your device outside of Magisk, so check those as well.
Unlocked bootloader
If your device has an unlocked bootloader and shipped with an Android version newer than 8 it will very likely be using hardware backed key attestation to check the bootloader state. That is impossible to circumvent and CTS will fail. Fortunately there is a way of forcing SafetyNet to use a basic attestation instead, by using this Magisk Module, Universal SafetyNet Fix:https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-1-1-0.4217823/
In combination with the above fix, or on devices that have a broken implementation of the hardware attestation, you might need to spoof your devices model as something else than your actual device. This can be done with a simple boot script and the resetprop tool, or by using MagiskHide Props Config's Force BASIC key attestation feature. Some have reported success by using MagiskHide Props Config to simply delete the ro.product.model prop from their systems, but this could have some unforeseen consequenses. See the module documentation for best practices.
The Universal SafetyNet Fix also changes model props since v2.1.0, but only for Play Services. That way you won't end up with strange UI/UX glitches due to mismatching model values.
It might also be possible to fool Google Play Services by using XPrivacyLua and limit Google Play Services from tracking you.
A combination of the above might be necessary to fully pass SafetyNet.
Topjohnwu has written a faq on hardware key attestation that can be found here:
https://twitter.com/topjohnwu/status/1237830555523149824?s=20
And XDA has a very good article on this as well:
https://www.xda-developers.com/safetynet-hardware-attestation-hide-root-magisk
Since this part of SafetyNet checks for an unlocked bootloader you might be tempted to simply lock the bootloader again. This is a bad idea... Most devices will be permanently bricked if you lock the bootloader on a modified device. There are some devices that you can lock the bootloader on even if it isn't stock, but this is not recommended unless you know exactly what you are doing. Be warned...
SafetyNet fails after an update
If SafetyNet starts failing after an update to either Magisk, the app 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.Both CTS profile and Basic integrity fails
MagiskHide needs to be enabled. Start there. If MagiskHide is enabled and working (see Test "MagiskHide" above), and both checks fail you might be successful if you clear cache for Google Play Services. If that doesn't help you should also make sure that you don't have other root solutions installed (old or preinstalled in your ROM, also see "Magisk can not hide") or any kind of mod or module that is triggering SafetyNet (see "Check your modules and mods" below).CTS profile fails but Basic integrity passes
MagiskHide needs to be enabled (yes, basic integrity can pass even if MagiskHide is disabled). Start there. If MagiskHide is enabled and working (see Test "MagiskHide" above), and you still can't pass the CTS profile check, but Basic integrity shows as true, that basically means Google doesn't trust your device for some reason (also see "Unlocked bootloader" above and "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).CTS profile passes but Basic integrity fails
This means that SafetyNet is actually failing and you are likely using a mod like the Xposed HiddenCore module that is trying to spoof the CTS profile check result. In reality you're failing both CTS profile and Basic integrity (see above).This might be successful against some apps that haven't properly implemented the SafetyNet check. But it won't have any effect on a properly implemented SafetyNet check.
Both CTS profile and Basic integrity passes
Everythings good. You can stop reading (at least this section of the guide).Check your modules and mods
In March 2020 Google didn't just start using hardware key attestation (see "Unlocked bootloader" below), but they also tightened down what kind of modifications SafetyNet detects. For example, bind mounts in a module may now trigger SafetyNet.If you suddenly start failing both CTS and basic integrity, try disabling or uninstalling the last module you installed (or try disabling all modules). If you can pass SafetyNet fully with that (or all) module disabled you know it is a module that is causing the issue. If you do not know which module disable each module individually until you find which one is the culprit.
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 the SafetyNet CTS profile check (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>
Depending on your ROM and/or device you might also have to edit ro.bootimage.build.fingerprint, ro.system.build.fingerprint, ro.vendor.build.fingerprint and ro.odm.build.fingerprint. It's not necessary for passing the CTS profile check, but if your ROM has one of these other props and you don't match them with the used fingerprint you may get a warning at boot about your device having an internal problem.
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.
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 doesn't mean that SafetyNet is failing. It is usually caused by the app you are using to check SafetyNet not having internet access, can't reach Google's servers for whatever reason or the snet files not downloading properly if you're using the Magisk app. If you're using the Magisk app, try clearing data for it and make sure that you have a working internet connection and no firewall or other services that could be limiting internet connection for the Magisk app when starting the SafetyNet check. The app 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. If clearing the Magisk app's data and trying again doesn't help, try a different SafetyNet checker. It might be that Google has updated the API and that the app needs an update to accommodate this.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.Passing SafetyNet with EdXposed installed
Google can detect if you have EdXposed installed, but you can usually work around this by making sure you're using the latest release (usually the Canary releases) and using things like the EdXposed Managers Blacklist feature and enabling it for Google Play Services, Play Store and Services Framework.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 Magisk app. 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 app or both it's usually fixed by toggling MagiskHide off and on (see ”Test MagiskHide above”).MagiskHide fails after rebooting
On some devices MagiskHide can't seem to stay enabled across a reboot. It will look like it is enabled, but the service isn't actually running. The solution is to toggle MagiskHide off and on again after rebooting. This can become tedious, so it's better to create a late_start service boot script (service.d) that can do it for you. Something like this:#!/system/bin/sh while [ "$(getprop sys.boot_completed)" == 0 ] do sleep 1 done magiskhide disable magiskhide enable
MagiskHide doesnt show in the Magisk app
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
If you have MagiskHide enabled it should start automatically on boot. If it isn’t working, try toggling MagiskHide off and on in the app settings. If MagiskHide just won't start when toggling it in the Magisk app (check the Magisk log, it might have started but the app 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 (apart from props for the bootloader state):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 app, 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...
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 app. Compatible apk 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, 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 XDA support thread or as an issue on GitHub (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! The Canary Magisk app is available on GitHub.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:- Detailed description of the issue and what you've tried so far, what has worked and what hasn't (as an example, did you test MagiskHide?).
- Details about your device, Android version, ROM, custom kernel, mods, etc.
- Logs! A bug report or a report about some kind of issue that is not accompanied by logs will likely be ignored. Always provide logs! And when providing logs, do NOT paste them into your post. Attach as a file or upload the file somewhere and provide the link. If you can't provide logs for some reason, at least try to give detailed instructions on how to reliably reproduce the issue.
Reporting a bug
When reporting a bug, make sure you have the latest Canary bleeding edge 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).All bug reports should be made on the the Magisk Github repo. The same tips that are outlined above apply.
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:- Installation of Magisk or modules fail - If installing from recovery, you'll need the recovery log and if installing from the Magisk app you need to save the installation log.
- Magisk/modules/MagiskHide isn't working as it should - The Magisk log should as a rule always be included whenever there are issues with Magisk core features. Some modules provide their own logging for if there are issues (see the specific modules thread/documentation).
- The Magisk app crashes - A logcat when the crash occurs will be necessary.
- Other apps/my system are/is misbehaving/crashes - A logcat showing the issue will be necessary.
- The device randomly reboots - After the reboot, grab the console-ramoops and/or last_kmsg.
- The device doesn't boot/bootloops - A logcat during boot (either through ADB or a boot script) or dmesg are the only thing that really could show what's going on. A Magisk log might be good for complementary information.
- The device only boots to bootloader/recovery - After the reboot, grab the kmsg file.
- Something doesn't work right -If something about your system or Magisk just doesn't work right, a dmesg or boot logcat might show what's wrong.
- Etc...
Get the log
- Recovery log from installation (in TWRP, go to Advanced - Copy log). If you experience errors when installing Magisk or modules through recovery. Note that this log HAS to be saved right after you've done whatever you're trying to save a log of. If you reboot inbetween there is a good chance that the info will be lost. The log might still be found in /cache/recovery after rebooting, but any subsequent reboots to recovery will overwrite the relevant information.
- Installation log from the Magisk app (press "Save log" after installing Magisk or a module). If you experience errors when installing Magisk or modules in the Magisk app.
- Magisk log save from the Magisk app or in /cache (or /data/cache on A/B devices) through recovery if you don't have root access. If the log is empty, see "The Magisk log is empty" below. Note that when reporting about issues and bugs it is required to use verbose logging (see "Verbose logging" below).
- Logcat. Grab it via ADB, an app or a logcat bootscript (see below). It might be a good idea to start by clearing the log so you don't end up with a lot of useless info before whatever you're trying to catch; "logcat -c" with ADB and there's usually an option for it in the app. Useful when other parts of the system are aren't working properly or if it's something that doesn't show up in the Magisk log. Also immensely useful if the Magisk app is crashing or having other issues. If you can't get root access it's easiest to hook up your device to a computer and use ADB. If your device isn't booting, it might be possible to grab a logcat during boot with ADB.
- Logcat boot script. This is useful if your device won't boot for some reason, or if you're experiencing other boot related issues. The script might even work when ADB logcat doesn't (since ADB won't work until later in the boot process). Place a file (doesn't matter what you name it) in /data/adb/post-fs-data.d, give it execution permission and put the following code snippet in it (thank you jenslody and jcmm11 for help with the script). Tip: press the "Grab" button below the code block to download a file ready to be renamed and placed in post-fs-data.d.This will save a logcat to a file named boot.log and save it to your internal storage (/sdcard) as soon as possible during boot and you won't need a PC or other device to run ADB from. The first 30 seconds will be saved, but if this isn't enough you can adjust the sleep time in the script to fit your needs. If you want a more automated script creation process you can try the TeMeFI App by XDA recognised contributor DiamondJohn. It is highly customisable (the boot script option can be found under the logcat menu) and can also be used for a number of other information collecting purposes.
#!/system/bin/sh { logcat -f /cache/bootlog.log & sleep 30 kill %1 Loc='/data/media/0' until [ -e ${Loc}/testx ] do sleep 1 touch ${Loc}/testx done rm -f ${Loc}/testx [ -e ${Loc}/bootlog.log ] && mv -f ${Loc}/bootlog.log ${Loc}/bootlog_last.log cp -f /cache/bootlog.log ${Loc}/bootlog.log rm -f /cache/bootlog.log exit } &
- dmesg Can be run directly from the device or through ADB, but root is necessary. The command is simply "dmesg > /sdcard/dmesg.txt" (or whatever path you want to use or file name you want to give it). If running through ADB, put "adb shell su -c" in front of the command.
- Module log Sometimes modules have their own set of logs that might be useful when troubleshooting issues with a particular module. See the module documentation for details.
- console-ramoops If experiencing random reboots, the console-ramoops file, found in /sys/fs/pstore, might show what's going on.
- kmsg/last_kmsg If experiencing random reboots or booting to bootloader/recovery, the kmsg files, found in /proc, might show what's going on.
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 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, this is a requirement.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.
