SafetyNet’s Hardware-based Attestation: What is it, How it Impacts Magisk Users, and How to Check for it

Google has now started using a new method to verify SafetyNet on Android devices which directly prevents Magisk from passing the SafetyNet checks. This new method of attestation is still not applicable to every Android device, at least not yet. In this post, we will discuss what this new SafetyNet hardware attestation is, its basic workflow, and its impacts on Magisk users. Further, we will show you how to check if your Android device uses SafetyNet’s hardware-based attestation.

Before we start talking about Google’s new hardware-based SafetyNet attestation and its impact on users with rooted Android devices, let’s take a quick rundown of what SafetyNet is.

SafetyNet is a set of APIs that could be employed by third-party applications to verify whether the Android device they are being used on has been tampered with in any manner. SafetyNet’s attestation API verify the device’s status against various factors (as per Google) like unlocked bootloader, presence of root binaries or third-party firmware (custom ROMs), and more.

When you (a user) root your Android device using Magisk, it creates an isolated environment that would allow passing SafetyNet checks despite the actual device status. Since the introduction of SafetyNet (about 3 years now), Magisk has been able to return “false” during the attestation for the unlocked bootloader status. This is what causes the real issue now, as we are going to discuss below.

Android’s new hardware-based attestation for SafetyNet

Back in March 2020, Magisk developer John Wu (more commonly known as ‘topjohnwu’ on XDA and Twitter) posted on Twitter about a new SafetyNet attestation method being partially rolled out to a handful of Android devices. The said method was then apparently rolled back and gave a clear indication that Google was surely testing it. And then in May, Google finally confirmed using a new hardware-based attestation for SafetyNet.

According to John Wu, in this new attestation, “It [Google Play Services] will send an unmodified Keystore certificate to SafetyNet servers, verify its legitimacy, and check certificate extension data to know whether your device has verified boot enabled (bootloader status)“.

Up until now, SafetyNet responses included two parameters: ctsProfileMatch and basicIntegrity. According to Google, there’s now a new parameter known as evaluationType. The value of this new parameter will be two string tokens, as follows.

• 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.

Developer John Wu has already introduced this new parameter within Magisk Manager (on the canary channel). This allows Magisk users to quickly evaluate if their device uses the new hardware-backed attestation.

Magisk’s ability to pass full SafetyNet checks in the present

The first thing that would concern every rooted Android device user is would Magisk still be able to pass all SafetyNet checks again? Apparently not. However, this depends on two particular things.

• First is the device you’re using. Starting with Android 7.0 Nougat, devices are required to have an isolated secure environment, which is directly responsible for this new SafetyNet check. If your Android device runs Android Marshmallow or lower, it might not be able to perform hardware-based attestation due to the lack of a proper isolated secure environment. This means Magisk would still be able to pass full SafetyNet checks and hide root access properly on such devices.
• The second factor is whether or not if the new hardware attestation is enforced on your Android device yet. If your device qualifies, it could just be a matter of time until the new attestation is forced. That’s exactly what we are here to instruct you on so that you can check if your Android device uses SafetyNet’s hardware attestation.

MagiskHide still works, but it depends

MagiskHide is among the major features offered by Magisk. For years now, users with rooted Android devices have been able to use it to hide root permissions and unlocked bootloader status from certain apps that might stop working. This includes banking/financial apps, famous games like Pokemon Go, etc.

Given the present situation, “MagiskHide is still effective to hide anything in userspace but is no longer capable of spoofing bootloader/verified boot status. To put it simply, we can still hide “root”, but not the bootloader status.“

And so, apps that only check for the presence of root binaries on a device with SafetyNet can still be used with MagiskHide. On the other hand, as pointed by John Wu, apps that check for the unlocked bootloader status (like the official McDonalds app) will fail to run completely or partially despite the best efforts.

Update: A workaround (Universal SafetyNet Fix)

On the 14th of January 2021, developer Danny Lin (kdrag0n) released the Universal SafetyNet Fix Magisk module that fixes SafetyNet on devices with hardware-backed attestation. The module basically blocks GMS from using key attestation at the framework level to force basic attestation.

• More info: How to fix SafetyNet’s Hardware Attestation using Universal SafetyNet Fix

There is no workaround

As noted above, Google Play Services now send Keystore certificates for attestation. The private keys from these are derived from the device’s isolated secure environment. Breaking into these keys would require to find a vulnerability in TEE firmware (Trusted Execution Environment) or if there are serious bugs in it, both of which would be patched as soon as Google finds out about it.

Developer John Wu explained that it’s possible to spoof the bootloader unlock status by injecting custom code using hooking frameworks (like Xposed) so that SafetyNet always returns the “BASIC” evaluation instead of “HARDWARE_BACKED”. But it would further be impossible to hide the code injection itself, which will defeat the purpose of Magisk Hide.

He further added that rooting and passing full SafetyNet would require either of the following things:

1. A kernel exploit that gives us root
2. A bootloader bug that allows us to trick TEE/SE or load custom images
3. Leak TEE/SE private keys
4. Find a hardware bug in the SOC

The reason why Magisk doesn’t touch any of these things or workarounds is that they could be patched anytime. This defeats the practicality of using Magisk, given how huge the Android ecosystem is (number of devices, Android versions, etc).

Frequently Asked Questions (F.A.Q)

Given the number of questions, a lot of Magisk users had after this new SN attestation method, the developer posted a FAQ on Twitter to address them. We are going to list these questions below, along with the answers provided by John Wu himself.

Question 1: SafetyNet is passing fine on my device

• Answer: “It seems this new measure is not fully enforced, most likely to prevent false negatives. If your device is old, or somehow key attestation fails in keymaster HAL, SN will simply ignore it.”

Question 2: Xposed/Riru module allows me to pass SafetyNet

• Answer: “The SN [SafetyNet] test in Magisk Manager is technically *not* a proper attestation. Proper SafetyNet checks will verify results on a remote server, not on the device which can be manipulated by code injection frameworks.”

Question 3: Can’t we just create a fake SafetyNet test result?

• Answer: “Nope, SafetyNet responses come from Google servers and are signed with Google’s private key, which we do not have access to.”

Question 4: Can’t we modify GMS directly?

• Answer: “This is technically what MagiskHide is doing. We create an isolated ‘safe environment’ for the detection process, and it goes through Google’s API to create a *legit* SafetyNet result that does not reflect the real status of the device.
  However, 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)”

Question 5: Can we fake a certificate (+ manipulated extension data)?

• Answer: “Nope. Check how a trusted execution environment (TEE) works. Unless there are serious implementation bugs in your ARM TrustZone (or security co-processor like Google’s Titan M), you cannot break the cryptography.”

Question 6: Is MagiskHide meaningless now?

• Answer: “It depends on your expectation. MagiskHide is still effective to hide anything in userspace but is no longer capable of spoofing bootloader/verified boot status.
  To put it simply, we can still hide “root”, but not the bootloader status.”

How to Check if your Android Device uses SafetyNet’s Hardware-based Attestation

You now know how this new attestation can impact both SafetyNet checks and MagiskHide’s usage on rooted Android devices. So we figured it would come in handy if you could check whether or not your Android device uses SafetyNet’s hardware attestation or not. This could be done through two ways/methods as detailed below.

FYI, the first method is the easiest, but will only work if your device is rooted. If your phone isn’t rooted, opt for the instructions under Method 2.

Method 1: Using Magisk Manager

John Wu recently announced that the in-built SafetyNet checker in the latest version of Magisk Manager (on Canary channel) incorporates the new “evaluationType” field. So, you could simply run a SafetyNet check through Magisk Manager to know if your Android device uses the new hardware attestation or not.

Note: Ensure that you’re using the latest Canary version of the Magisk Manager app. If not, you can get the APK from the official Github page and install it on your phone.

1. To check, launch the Magisk Manager application on your Android device first.
2. Go to Magisk’s Superuser menu by pressing the shield icon on the bottom navigation bar.
   
3. Tap on “SafetyNet”. If you’re performing the SN check for the first time, Magisk would prompt you to “Download Proprietary Code”. Press “YES” to confirm.
   
4. Wait for a few seconds for the attestation results.

There will be a new third field in the attestation card called “evalType“. If it shows the value as “BASIC“, it means that the new attestation is not yet enforced on your device. On the other hand, if it’s “HARDWARE“, it means that your Android device is now using SafetyNet’s hardware-based attestation.

Method 2: Analyzing the Device Logs

If your phone isn’t rooted, there’s an alternate way to check for SafetyNet’s hardware attestation. That is by taking a logcat while performing the SN check and then analyzing the log file for the “evaluationType” parameter. The parameter’s value (BASIC or HARDWARE_BACKED) can clearly indicate if the new attestation is applicable to your device yet, or not. This method was provided by XDA senior member Displax over here.

To check using this method:

1. Download and install a SafetyNet checker application on your Android device. XDA member Displax suggests using the “SafetyNet Helper Sample” app for this purpose.
2. The next thing you will need is a tool to take a logcat on your device. You can use ADB for this if you’re familiar with it, but we would be using the “Logcat Reader” app for demonstration, as it’s much easier to use for any average user.
3. Launch the LogCat Reader app on your device. When you launch the app, it would prompt you to grant the required “READ_LOGS” permissions. To do this, you will need to execute the following ADB command from your PC:

   adb shell pm grant com.dp.logcatapp android.permission.READ_LOGS

4. Once the permissions have been granted, simply force-close the app or restart the device (preferred).
5. Relaunch the Logcat Reader app and press the circular icon on the top-right of the screen to start capturing the log.
   
6. Now launch the “SafetyNet Helper Sample” app and tap “Run SafetyNet Test”. Wait until the test completes.
   
7. Once the test finishes, go back to the Logcat Reader app and press the square icon on the top-right to stop log recording. The app should now prompt you to view or share the captured log. Tap on “View”.
   
8. Press the search icon and input “evaluationType” in the field.
   
9. To verify if your Android device uses the new SafetyNet attestation method, look for the value of the evaluation parameter.
   • If it shows “BASIC”, then the new attestation is not yet enforced on your device.
   • If it shows “BASIC, HARDWARE_BACKED”, it means that the device now uses hardware-based attestation for SafetyNet.

Concluding

Google’s attempt with this new attestation method is surely a step forward in terms of Android security. But it surely has a solid impact on rooted users. They would be forced to choose between either rooting their device or using the apps that would fail to work fully or partially given for the unlocked bootloader status.

Magisk developer John Wu himself has tried to persuade the Android development team to only allow hardware-based attestation for apps that really concern security. He surely made his point on how some apps could abuse the API.

For all we have learned by now, is that there’s no easy to go around SafetyNet’s hardware attestation when it concerns the overall practicality. The only way the situation could get better is if Google places its own measures for apps to qualify for such strong attestation.

I understand that a reliable service for verifying device security status is important. However it shall not be abused and used to remove a significant portion of functionality on the few chosen to give up some security. This creates a hostile ecosystem against hobbyists.

— John Wu (@topjohnwu) June 29, 2020

We hope this post has provided you with some insights regarding the new hardware-based attestation for SafetyNet on Android, how it works, and impacts users with a rooted phone.

Before we end this post, we would like to present our deepest gratitude to Magisk creator John Wu, for always keeping us up-to-date with regards to these new SafetyNet implementations. Further, we would like to extend our thanks to Mishaal Rahman (Editor-in-Chief, XDA-Developers) for his detailed writeup on the matter. His piece has provided us with major chunks of information and explanation.

//Source: XDA-Developers & topjohnwu’s Twiiter