4

As widely reported on different sites, and also discussed on this site (here and here), earlier this year, Google made changes to SafetyNet so that it could detect bootloader/verified boot status even with MagiskHide enabled. The developer of Magisk, John Wu, at that time tweeted that because Google was using the Trusted Execution Environment (TEE), its check on bootloader status could not be defeated. For example, he wrote:

this new update utilizes hardware-based key attestation. It will send an unmodified keystore certificate to SafetyNet servers, verify its legitimacy, and check certificate extension data to know whether your device have verified boot enabled (bootloader status)

Unless there is serious implementation bugs in your ARM TrustZone (or security co-processor like Google's Titan M), you cannot break the cryptography.

He basically concluded:

Let's face it. Fun is over guys.

Yet, on March 14, John Wu tweeted:

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.

And another tweet from him on April 3 that I didn't quite understand:

THE BIG GOOGLE HAMMER IS BACK! Say bye bye to SafetyNet, we'll (not) miss you...

Did that mean Google would somehow be removing SafetyNet, or at least not utilizing its capabilities to detect bootloader status?

So there was some doubt beginning to surface in mid March. 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 MagiskHide, and it was working out in the field with real devices, but they have somehow stopped doing that? Does anyone know what is going on with SafetyNet? Was the feature temporarily reverted? Will it be coming back to SafetyNet, and if so, when?

Improve this question
8
  • 1
    It is subjective (related to device and OS), nothing can be said with any certainty. See various forums on XDA and your answer depends on what you read
    – beeshyams
    Commented May 31, 2020 at 15:07
  • Hmm, I wonder if there are any indications about what Google is thinking? Or is it just people speculating about what Google is doing?
    – auspicious99
    Commented May 31, 2020 at 15:13
  • it's all speculation - no one knows
    – beeshyams
    Commented May 31, 2020 at 15:14
  • 1
    Thanks, hopefully if somebody knows, they could help to write an answer here.
    – auspicious99
    Commented May 31, 2020 at 15:17
  • 1
    @jkmartindale Thanks, but I've already referenced that question, which was asked earlier, when it was assumed that magisk would fail SafetyNet checks "hereafter". However, since mid March, the situation has changed, and that's what I'm asking about.
    – auspicious99
    Commented May 31, 2020 at 17:30

1 Answer 1

Reset to default
3

(29 June 2020) It looks like Google is just being cautious, and preparing a new field in the SafetyNet response.

According to the SafetyNet API Clients Team

We have started rolling out a new feature that will provide developers with insight into the types of signals/measurements that have contributed to each individual SafetyNet Attestation API response.

Our JWS responses now have a new optional field named evaluationType. The value of this field will be a list of comma-separated string tokens, where each token represents an enum-like value.

Currently, the following string tokens may be indicated::

  • BASIC - When we use typical signals and measurements along with reference data during our evaluation.
  • 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.

Examples of field values that you may expect:

  • {“evaluationType”: “BASIC”}
  • {“evaluationType”: “BASIC,HARDWARE_BACKED”}

We’re currently evaluating and adjusting the eligibility criteria for devices where we will rely on hardware-backed security features. So please do not use the presence or value of this field as a signal by itself (for now).

Note that this feature has not been officially documented yet. Presently, we’re only communicating it to this announcement-list to collect feedback.

We encourage you to use our feedback form based on your experience with this new feature as well as the overall service.

Thanks & Regards, SafetyNet API Clients team

So once testing for this new feature is completed, it looks like hardware-backed key attestation will be put in place. Which means, from then on, SafetyNet would be able to detect bootloader/verified boot status even with MagiskHide enabled.

John Wu is still fighting back

(updated on 29 June 2020)

John Wu is trying to persuade Google to not blindly apply SafetyNet hardware-backed attestation across the board. He tweeted:

I advocate @AndroidDev to restrict hardware-backed SafetyNet evaluation to "real" security sensitive apps. Developers should go through an application process to qualify this level of API access. It is ridiculous for McDonalds to refuse to run on a bootloader unlocked device.

Meanwhile, it appears that the SafetyNet checks will still fail even if the bootloader is re-locked, as we see here, tweeted 3 July 2020

Bad news: it is confirmed that for those who wants to re-lock their bootloader with self signed images (possible on Pixel devices), SafetyNet with HARDWARE-BACKED evaluation will still NOT pass CTS check.

(Updated on 13 Dec 2020) John Wu now tweets

Let me get this out of the way: since I have a full time job now, I don't have much time for Magisk; I need prioritization. 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.

Improve this answer
4
  • 1
    @beeshyams Thanks, I had already posted this URL groups.google.com/forum/#!topic/safetynet-api-clients/… earlier today, so it is clear what is happening.
    – auspicious99
    Commented Jun 29, 2020 at 10:14
  • @beeshyams Anyway, it is good to know ; so more apps may be using SafetyNet in the future. Do you think that would be "better" alternatives for rooting in that case?
    – auspicious99
    Commented Jun 29, 2020 at 10:26
  • I feel it is for the better. Make a choice - you want root or secure apps. You can't have both //Better alternatives are possible, we had many before Su, root kit apps and now Magisk. Once John Wu quits development, one may find new methods. I feel Magisk is the best we ever had and likely to be in a while. For me, I will put off upgrading to 11 till the picture is clear (I don't need any SafetyNet) but use banking apps that don't like root. If root can be hidden as John says, I am good :)
    – beeshyams
    Commented Jun 29, 2020 at 10:37
  • 1
    @beeshyams Or one phone for root, one for banking/secure apps :-). Yes, I agree with you, Magisk was very skillfully done.
    – auspicious99
    Commented Jun 29, 2020 at 11:16

You must log in to answer this question.

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