Recently, Google made security changes which make sure fails check when Magisk is installed.

This was Tweeted by John Wu (Magisk developer) , here and here. Some excerpts:

So here we go, after years of fun messing around using Magisk, it seems that Google FINALLY decided to "fix" SafetyNet to something useful, and that is to use key attestation to verify device status (after 3 years since introduced to Android's platform!)

Let's face it. Fun is over guys.

(Emphasis added)

Edit: From Github

Disable MagiskHide by default

Since SafetyNet CTS is impossible to achieve, leaving MagiskHide on by default no longer serves a purpose.

For more details regarding the latest SafetyNet changes, please check: https://twitter.com/topjohnwu/status/1237656703929180160 https://twitter.com/topjohnwu/status/1237830555523149824

MagiskHide's functionality will continue to exist within the Magisk project as it is still extremely effective to hide modifications in userspace (including SafetyNet's basicIntegrity check).

Future MagiskHide improvements may come, but since the holy grail has been taken, any form of improvement is now a very low priority

It looks to me that Google could/should have implemented this earlier but didn't and the CTS check being done from within Magisk wasn't comprehensive.

Please demystify this in simple terms (to the extent possible) for folks who don't understand the innards of Android (like me).

  • 2
    If I get it correctly from the tweets the bootloader unlocked state is now determined by code that runs in the TEE, a security part available in most ARM CPUs that is hardened against manipulation. Also the code executed in it can't be changed. This code checks somehow the bootloader state and prepares the signed data sent to Google. The Google server then decides if or if not your devices passes the check.
    – Robert
    Commented Mar 12, 2020 at 12:41
  • @Robert Yes, but am trying to understand more in terms of why now Vs earlier when apparently mechanism was in place. Plus, CTS check earlier was also being done by a server I thought but it seems to be Google. As said, simplify for dummies!
    – beeshyams
    Commented Mar 12, 2020 at 12:45
  • 1
    From my understanding the main problem is that the boot loader check has been moved into the TEE and that it can only performed there (before it was executed outside of TEE?). TEE is like a separate OS, we don't have root to and it is running only signed code. Hence you can't modify or manipulate the check. You can only decide not to run it.
    – Robert
    Commented Mar 12, 2020 at 12:56
  • Somehow this isnt true yet. Am on Android 10, 5 March Security Update, Magisk and EdXposed installed. And safetyNet still pass. Commented Mar 18, 2020 at 4:01
  • @OtnielYoreiza yes, it has been reported that older Android versions are not yet affected in some cases. I am little surprised in your case. Have you tried to install some app that doesn't work if Safety Net is broken - to double check (Magisk check is sometimes faulty)
    – beeshyams
    Commented Mar 18, 2020 at 4:26

2 Answers 2


This is the latest (as on 30 August 21) on safety net. What are the changes in Magisk?

John Wu (Magisk Developer) posted updates today, which clarifies the reasons.

Earlier, SafetyNet API wasn't fully / correctly implemented, the way it was meant to be :

From what we've seen so far, key attestation doesn't seem to be fully enforced yet, as devices with incompatible, potentially buggy(?) keymaster implementations (e.g. some OnePlus devices) that result in attest key cmd failures still pass SafetyNet regardless.

bootloader reports the device status via kernel cmdlines, and init will reflect them in properties, and apparently SafetyNet was using those values. All those stuff is in userspace, so Magisk can simply manipulate it

Now, with the Feature Preview: SafetyNet Attestation API evaluationType, there will be two types of evaluation, BASIC and HARDWARE_BACKED for a complete evaluation with remote validation (as against local) :

HARDWARE_BACKED - When we use the available hardware-backed security features of the remote device (e.g. hardware-backed key attestation) to influence our evaluation.

We’re currently evaluating and adjusting the eligibility criteria for devices where we will rely on hardware-backed security features.

Can this new system be hacked?

Looks very unlikely

IMO it is theoretically possible to alter control flow in SafetyNet's code to force it to always use BASIC evaluation by using some hooking framework like Xposed, however these kind of code injection is basically impossible to hide (memory space analysis).

To hack this thing, you have to either find a vulnerability in TEE firmware (which will be patched ASAP once found) or hardware (less likely to happen) to break the cryptography.

Breaking TEE won't be easy, which is why many security researchers are actively working on it.

(Emphasis added in all quotes)

How to check if Google has implemented hardware Attestation for my device?

Edit Magisk canary has been updated to show evaluation status and once the API is implemented, you will see more details (failing SafetyNet). Or, follow instructions on this XDA post to check attestation method using logcat

enter image description here

For more information see SafetyNet's hardware attestation will make hiding root in Magisk really hard

Edited on 16 December 20

And the final nail in the coffin for fooling safety net detection

Johnwu in

HW based evaluation is impractical to "hack" (except tricks to make it fallback to basic), and I lost all interest in improving the current way of hiding.

  • Another tweet of 13 Dec 2020

If passing SafetyNet is the only use of Magisk for you, then yeah, bye Face with rolling eyes ( in response to So... magisk is completely useless right now?...)

  • If I have a device with unlocked bootloader, but not yet rooted (meaning boot partition is stock), will my device still fail the HARDWARE_BACKED attestation check? It'd be great if you could edit your answer to include that.
    – Gokul NC
    Commented Jul 1, 2020 at 15:24
  • @Gokul NC Of course not! Unless your device is not CTS cleared, which won't be the case unless you have a very cheap device
    – beeshyams
    Commented Jul 1, 2020 at 15:28
  • Okay. I have another doubt; apologies for my ignorance. Say my device has failed the SafetyNet HARDWARE_BACKED check. Now, my bank application is trying to invoke the SafetyNet Attestation API using a method that it has. What if I write a Xposed hook to intercept my bank app's method which is responsible for calling the attestation check API, and alter the codepath of the method to make the app bypass calling the SafetyNet Attestation API itself?
    – Gokul NC
    Commented Jul 1, 2020 at 15:57
  • 1
    @GokulNC Yes, it will fail the check. This is because all hardware backed implementations are required to report whether or not verified boot is enabled, and it must be disabled for an unlocked bootloader. Therefore the check will fail even if your ROM is clean.
    – Dev
    Commented Nov 25, 2020 at 23:38
  • 1
    There seems to be a new workaround see Xda-Blog post: if Magisk pretends that the android device does not support hardware attestation. Of course this works only if the device claims to be an older device. Thus this is not a long-term workaround.
    – Robert
    Commented Feb 1, 2021 at 14:37

It appears that Google may have chosen not to enforce this checking, even though it was implemented for a short while (a few days?). At first, the Magisk developer, John Wu, sounded quite pessimistic about it, going even so far as to say that the fun was over.

A few days after the tweets from John Wu that were referenced in the question, however, on March 14, John Wu tweeted again, and this time he said

So apparently CTS is just passing again out of nowhere? Maybe Google is still testing things out?

I'm over it anyways. Google is apparently willing to use key attestation for detection. Since MagiskHide is still there, people can still always use it as usual.

In my own test in late May 2020, with MagiskHide not enabled, SafetyNet failed, but with MagiskHide enabled and targetting my test app, SafetyNet passed, meaning that MagishHide could still defeat SafetyNet. The test was run on a Pixel 3 with android 10.

So, Google may have the capability to detect Magisk, since the boot loader check had been moved into the TEE, but they have somehow stopped doing that, for reasons known only to Google.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .