Google and the community have been playing a cat and mouse game for a long time over evading SafetyNet. The community enjoys tinkering with the software on their phones, which usually starts with bootloader unlocking. However, this trips SafetyNet, causing a number of popular apps to cease working on the phone, some of which are justifiably so because they rely on a tamper-proof environment for execution.
SafetyNet is aimed at app creators, but they can choose whether or not to use it. However, as an ordinary end user, you have two options: give up on Android’s modding potential and pass the SafetyNet compatibility tests, or risk being blacklisted by software publishers. This guide should let you pass SafetyNet even if you’ve rooted or installed a custom ROM on your smartphone.
What is SafetyNet?
Android is built to run without granting the end user any privileged access to the underlying subsystems. If a person with administrative (a.k.a. “superuser”) capabilities on an Android device has similar access to administrative (a.k.a. “root”) permissions on a Linux machine, they can virtually change or replace Android system applications and settings. From the standpoint of an app developer, this means that the device on which their program is operating may be compromised. Some form of abuse detection mechanism should be in place to check the device’s software and hardware surroundings and reassure app developers that everything is fine. This is when SafetyNet enters the picture.
While modding is an important component of the Android ecosystem, security standards sometimes necessitate a high level of rigor in the operating system. The Google Play Services include a set of abuse-detection APIs called SafetyNet. Third-party applications can use the SafetyNet Attestation API to see if the device’s software environment has been tampered with in any way. The API compares the current state of the target Android device and verifies the integrity of the environment against a known’safe’ value on the server-side by checking for things like bootloader unlock status, signs of superuser binaries, and more.
SafetyNet tripping and its consequences
SafetyNet tripping is caused by a series of events that differ from the factory setup of an Android device. Even if you simply unlock your phone’s bootloader and leave the factory-installed OS alone, the SafetyNet check may fail due to a “CTS profile mismatch” (where CTS stands for the Compatibility Test Suite) issue. You’ll almost certainly wind up with a SafetyNet failed status if you root your Android device or replace the base firmware with a custom ROM. As a result, you won’t be able to utilize apps or games on the device that use SafetyNet validation. This is particularly true for banking and other financial apps like Google Pay, which rely solely on the SafetyNet Attestation result and will not accept anything else.
When it comes to games, developers use SafetyNet for assessing the device’s integrity so that they can prevent rogue players from cheating or modifying in-game variables for unfair advantages. Last but not least, you can also come across examples where publishers are simply misusing Google’s tamper detection mechanism for no practical reason, which is why power users want to evade the detection routines.
In a nutshell, the modding community will have to choose between having access to root/custom ROMs/kernels/etc. or their preferred apps and games. This might sound like the end of aftermarket development on Android, but there is hope.
Pass SafetyNet attestation
There is no true universal solution to avoid the inspections because Google modifies the backbone of the SafetyNet Attestation API on a regular basis. Because the limits are based on a variety of criteria, you may be able to get around SafetyNet in a modified environment by faking the most important characteristics on legacy devices, but the same approach may not work on later phones. Because of the ever-changing nature of the anti-abuse API, the aftermarket development community has come up with a number of approaches for passing the SafetyNet tests. However, keep in mind that a general implementation isn’t viable. This is a cat-and-mouse game; one day you’ll be ahead, the next day you won’t.
Google is depending on the security of the phone’s Trusted Execution Environment (TEE) or dedicated hardware security module (HSM) for tamper detection as it moves toward a hardware attestation method. Finding a serious security flaw in a device’s isolated secure environment and exploiting it to spoof SafetyNet’s client-side response isn’t a viable strategy, but there are alternative options.
1. Restoring the original firmware and relocking the bootloader
This is perhaps the simplest way to pass SafetyNet, but it has its own merits and demerits. All you need to do is find the correct firmware for your Android device, flash it, and finally re-lock the bootloader. Of course, you’ll lose most of the bells and whistles of Android modding, but it actually makes sense when you need to use your device in a managed environment with strict security policies or you’re trying to sell your device.
2. Using Magisk
If you own a legacy Android smartphone, Magisk is your best bet to pass SafetyNet without much hassle. Even though the current Canary channel of Magisk doesn’t feature MagiskHide anymore, you can still stick to last stable release (v23.0) and utilize MagiskHide to hide root status from apps. Furthermore, you can install Magisk modules like MagiskHide Props Config to change the device fingerprint in order to pass SafetyNet.
Talking about the Canary channel, the new “DenyList” feature of Magisk is an interesting development, which allows users to assign a list of processes where Magisk denies further modifications and reverts all changes it had done. With an appropriate configuration, it can also be used to pass SafetyNet in some scenarios.
Lastly, there’s Shamiko — a work-in-progress module written on top of Zygisk (Magisk in the zygote process). It reads the list of apps to hide from Magisk’s denylist to hide Magisk root, Zygisk itself, and Zygisk modules to circumvent SafetyNet. However, Shamiko can only work after disabling the DenyList feature.
3. Using Universal SafetyNet Fix
Bypassing Google’s hardware-backed SafetyNet attestation technique is a tad bit difficult, but it’s not entirely impossible. The Universal SafetyNet Fix project by XDA Senior Member kdrag0n cleverly accomplishes this feat by forcing the basic attestation over the hardware-backed checks.
Notably, Universal SafetyNet Fix has a dependency on Magisk when it comes to passing the basic attestation part. The developer offers two different builds of the fix: The Zygisk variant for Magisk Canary and the Riru variant for stable Magisk.
Universal SafetyNet Fix: GitHub Repo ||| XDA Discussion Thread
4. ih8sn
In case you don’t want to rely on Magisk to pass SafetyNet attestation, you can try out an experimental add-on named ih8sn. After applying, it can spoof a plethora of prop values in order to circumvent SafetyNet checks like the MagiskHide Props Config module, but there’s no dependency on Magisk in the first place.
The ih8sn tool is maintained by several LineageOS developers, but the LineageOS project doesn’t officially endorse it yet. To know more, take a look at its codebase by following the link below.
Verification
After applying one of the aforementioned SafetyNet passing methods, you may wish to verify the result. The Magisk app comes with an option to initiate the SafetyNet checking routine right from its main menu, which is really handy. You can also opt for an open source app named YASNAC (short for Yet Another SafetyNet Attestation Checker) to check the status and (optionally) examine the JSON response.
That’s how you can use your phone to pass SafetyNet. With a little effort and care, you can restore Android’s true modding capability without having to worry about SafetyNet Attestation failures. We’ll be adding more SafetyNet passing ways to this guide in the future, so check back!
