What is SafetyNet in Android? Why does it exist, how does it work, & how to bypass it?

Rooting an Android device gives the user access to a plethora of super powerful hidden features and system level operations and files. But, on the flip side, some apps and games refuse to work on rooted phones. We’re talking about apps like Android Pay (Also the Indian counterpart Tez, which is now Google Pay), many banking apps, games like Pokemon Go and Animal Crossing Pocket Camp. These are just some examples, there are a lot of apps and games that deny working (even starting) on rooted devices, and then there are some apps that’ll open up as usual, but will not allow the user to perform certain tasks, like the popular PhonePe app, which will open up, but restrict the user from transferring funds inside the app. The reason? SafetyNet. So what exactly is SafetyNet, how does it play with rooted devices, how to bypass it, and what else should you know about it? Let us explain.

Warning: this post is going to be very detailed & long, so you might want to grab some food and water.

Just for your convenience, here’s everything we’ll try to explain/answer in this post (you can click on the titles to jump to the respective section):
– What is SafetyNet?
– How does SafetyNet work?
– SafetyNet & rooted devices
– Why SafetyNet?
– Bypassing SafetyNet

What is SafetyNet?

SafetyNet is Google’s fence of security to protect Android devices from threats. It provides developers a set of services and APIs that help protect their app against various security threats, including device tampering, harmful apps, malicious URLs and fake users (bots).

How does SafetyNet work?

Like said, SafetyNet provides developers a set of services and APIs that they can integrate with their apps and games. These services check if the device software/hardware has been tampered with, if the content on a URL contains malicious apps, or if an app contains harmful codes, and whether or not a real user is interacting with an app. SafetyNet has the following APIs:

A. SafetyNet Attestation API

The Attestation API is kind of the MVP and is responsible for the tripping of SafetyNet on rooted devices. When the API is called by an app, all it does is check if the device has been tampered with (if the phone is rooted, if its bootloader has been unlocked, is running a custom ROM, if it has malware installed on the system, etc.,). It installs a program called ‘snet’ on an Android device as a part of the Google Play Services package that, according to Google, “provides access to Google services that help you assess the health and safety of an Android device.” Google doesn’t explain what exactly ‘snet’ does, or what it looks for in a device, but from what we’ve learned, it does two things: check whether the system partitions (boot, recovery, etc.,) have been modified from the factory state, and check whether a device fails CTS.

Devices that ship with Google’s suite of apps (Certified devices) need to pass the Android “Compatibility Test Suite” (abbreviated CTS). The SafetyNet Attestation API checks whether or not the device passes the CTS. Messing up with the system even slightly, even just unlocking the bootloader and not rooting, breaks CTS and hence the device fails the CTS tests, resulting in the tripping of SafetyNet.
The Attestation API, as of the time of writing this post, is optional for Apps & Games, and it is entirely upon the developers on whether or not to implement it. Most of the apps today won’t even call the API (check SafetyNet status). Read more about CTS here.

B. SafetyNet Safe Browsing API

Have you ever come across a red page on your browser that says that the web page you’re trying to access contains potentially harmful programs or malware? That’s thanks to the “Safe Browsing” feature by Google. How does it do that? Well, simply, Google’s web crawlers crawl millions of web pages every minute, and they use the API to scan web pages for malware, phishing, harmful codes, and programs. If a page is found having any of these, SafetyNet adds a warning page that the visitor sees before browsing the particular page/site on apps that make use of the Safe Browsing API, like Chrome. This API call can be implemented in apps (typically browsers), but it isn’t mandatory.

C. SafetyNet reCAPTCHA API

The SafetyNet service includes a reCAPTCHA API that, you guessed it, uses CAPTCHA to determine if a user interacting with an app is a real human or a bot. It thus helps the app stay protected from spam and other abuses, like bruteforce. This can be implemented in apps and games, but this too isn’t mandatory.

D. SafetyNet Verify Apps API

This one is just like the Safe Browsing API, except, it scans apps instead of web pages. The Verify Apps API allows apps to interact with the “Verify Apps” feature of Android (we’ve heard Chrome OS too) to determine, identify and protect from potentially harmful software. “Verify Apps” is a feature built into the OS that scans apps and games (very deeply) to find codes that could break Android’s security and prompts the user to disable/uninstall the app or game. You might have guessed it by now, the Play Protect feature makes use of this API. According to Google, if an app stores sensitive data, such as financial information, the devs should make use of this API to ensure maximum security.

You can read Android’s complete documentation and training guides on the APIs here. Also, there’s a very detailed analysis of what exactly is inside SafetyNet and how it works, written by a technical strategist, John Kozyrakis. We highly encourage you to check it out here if you’ve got some spare time & curiosity.

SafetyNet & rooted devices

If you haven’t jumped to this topic from the table of contents, you know how SafetyNet works. Rooted phones fail the CTS because the bootloader is in an unlocked state and that is visible in the boot image. This is mostly why SafetyNet fails on rooted phones with the reason being “CTS profile mismatch” or “CTS fail”. It is important to point out that CTS doesn’t only fail due to unlocked bootloaders, it is just one of the reasons why CTS fails.

Also, this is how systemless root is able to withstand CTS and pass SafetyNet. How you ask? With systemless rooting, the boot image is patched in a way so as to make it look like the stock boot image to CTS. You might have noticed this while flashing Magisk in TWRP, it says “patching boot image”.

It isn’t about rooting only though. Even if you’re running a non-rooted custom ROM, CTS might still fail, stating the device to not be Android certified. CTS checks tampering, that includes bootloader state, compatibility with Google Play Services, malware, monitoring, and others.

Why SafetyNet?

Android has been criticized since it’s inception for being less secure in comparison to iOS. Google keeps making Android better and more secure with time, and SafetyNet is just a part of that process. To answer “Why do we need SafetyNet?”, let us give this one scenario which shall make you realize why SafetyNet is important and not just a fuss.

There are millions of Android devices and the number just keeps on increasing with time, every second, also as you’re reading this. Also, in contrast to iOS, AOSP is Open Source, meaning there are thousands, if not hundreds, of different variants (forks) of AOSP running on these millions of devices. Some people are running the stock Grace UX on their newer Samsung phones, while some are still on the old TouchWiz UI, and some have shifted to custom ROMs like Lineage. In a situation like this, it is not possible for Google to scan each device every second manually to check if it’s (and if it remains) in fact compatible with and is not breaking Android’s security model. SafetyNet solves this by constantly pinging Google servers and sharing the device’s health status.

Why is this scanning necessary though? To answer this, you’ll need to understand how Android handles data. Mostly, an app’s data is stored on the data partition of the system storage. This data can be very easily accessed by third-party apps. In apps like Android Pay though (or any other financial/banking app), the data is sandboxed, meaning the data is contained within a closed environment inside the data partition. While in the sandbox, neither the app can share its data with any other third party app, nor any third party app can see, interact or share this app data. Apps can, however, break out of the sandbox using root privilege and/or extra intelligent malicious codes, and this, naturally, is a threat to the app and your money. This is why SafetyNet exists. Using SafetyNet, the app can simply refuse from being used on tampered devices, protecting no one else’s but your data and money. It might not seem that serious to some people, but it is incredibly tough to secure apps that include real money transactions.

But what when it comes to games (like Pokemon Go)? We don’t send money with them, then why exactly they use SafetyNet or why don’t they run on rooted phones? There might be a couple of reasons for this. First, to stop people from manipulating the app’s LVL and in-app purchases. What this means is that with just some lines of code, you can gain access to parts of the app which you would normally need to pay for. This, of course, requires root, because you need to access the codes. By restricting the app from running on rooted phones, they safeguard their app/game from being tampered with. Second, apps like Pokemon Go rely on location services to function, and on rooted devices, third-party apps can access this location data even when they aren’t running (before Android Q, which allows the user to grant an App location access only when it’s running in the foreground), and also, location can be faked with apps. Except these, there can also be other reasons, but we guess you get the idea. The basic reason is ‘security’.

If you’re still not convinced, here are some words from a security engineer at Android Pay on why SafetyNet is a feature and not a flaw.

SafetyNet isn’t the only way apps use to detect device tampering. There’s also a thing called KNOX on Samsung phones, that does the same thing but is only limited to Samsung’s stock flavor of Android.

Bypassing SafetyNet

Like everything else in this world, everything has a workaround, including SafetyNet. What ‘bypassing’ means here is hiding any tampering from SafetyNet and using apps (that rely on SafetyNet) that would not run otherwise. How exactly to do this? Well, the methodology is quite simple: to tell CTS that your device isn’t rooted, your device’s bootloader hasn’t been unlocked, etc. For the bootloader part, you’ll have to root the phone systemlessly. For the root detection, it can be hidden with modules like Magisk Hide (inside Magisk) & RootCloak (inside Xposed).

You’ll need to keep in mind that Google is constantly adding improvements inside SafetyNet and CTS to stop people from bypassing SafetyNet, so a method that works for you now isn’t a guarantee that it’ll continue to work in the future, or on other devices. Have a look at our guide on how to bypass SafetyNet if you want to try all possible ways to do it.

That’s all for this one, hope you got your SafetyNet questions answered and doubts cleared.