SafetyNet Explained: Android Pay & Rooted Devices
Understanding Android Rooting and its Implications
Gaining root access on your Android device unlocks a broader range of applications and provides more extensive control over the operating system. However, this modification can introduce compatibility issues with certain applications.
Specifically, some apps – such as Google’s Android Pay – are designed not to function on devices with root access.
How Google Detects Rooted Devices: SafetyNet
Google employs a security system known as SafetyNet to identify whether a device has been rooted. Upon detection, access to specific features is restricted.
This system serves as a protective measure, ensuring the integrity of services like Android Pay.
Beyond Google: Third-Party App Compatibility
The limitations aren't exclusive to Google's services. Numerous third-party applications also exhibit incompatibility with rooted Android devices.
These apps may utilize alternative methods to determine if a device has been rooted, preventing their operation to safeguard against potential security risks.
It's important to note that the methods for detecting root access can vary between different applications.
- Root access grants enhanced control.
- SafetyNet is Google’s root detection system.
- Third-party apps may employ independent root checks.
Understanding SafetyNet: How Google Detects Rooted Android Devices
Related: Enhance Your Security – Consider Apple Pay or Android Pay for Transactions
Android operating systems incorporate a feature known as the SafetyNet API, integrated within the Google Play Services layer on officially supported Android devices. According to Google, this API facilitates access to services designed to evaluate the integrity and security of an Android device.
Android developers can utilize this API within their applications to ascertain whether the device on which it is running has undergone unauthorized modifications.
The SafetyNet API is specifically engineered to identify instances of device tampering. This includes detection of rooted devices, those running custom ROMs, or systems compromised by low-level malware.
Android devices that are pre-loaded with the Google Play Store and associated applications are required to pass Google’s Android Compatibility Test Suite (CTS). Modifying a device through rooting or installing a custom ROM renders it incompatible with the CTS. The SafetyNet API leverages this principle to determine root status by verifying CTS compliance.
Furthermore, Android devices not originally shipped with Google’s applications—such as inexpensive tablets sourced directly from manufacturers—will also be flagged as non-CTS compatible, even without any user modifications.
Google Play Services operates by downloading and executing a program called "snet" in the background on your device. This program gathers device data and transmits it to Google on a recurring basis.
Google utilizes this collected information for diverse purposes, including gaining insights into the broader Android ecosystem and assessing the integrity of device software. While the specific criteria employed by snet remain undisclosed, it likely verifies the unmodified state of the system partition.
You can independently verify your device’s SafetyNet status by installing applications like SafetyNet Helper Sample or SafetyNet Playground. These apps query Google’s SafetyNet service and display the received response regarding your device’s status.
For a more in-depth technical analysis, refer to the blog post authored by John Kozyrakis, a technical strategist at Cigital, a software security firm. He provides a detailed examination of SafetyNet’s functionality.
App-Level Implementation of SafetyNet
The utilization of SafetyNet by app developers is entirely voluntary. Developers retain the discretion to integrate it into their applications or forgo its use altogether.
SafetyNet functions solely as a preventative measure, restricting an app’s operation only when the developer explicitly programs it to do so on rooted devices.
Prevalence of SafetyNet Checks
A significant number of applications do not incorporate checks utilizing the SafetyNet API. Even those apps that do utilize the API, such as the example test applications, will continue to function even if a negative response is received.
Developer Responsibility for Enforcement
For SafetyNet to effectively block functionality, the app developer must actively query the API and implement logic to cease operation upon detecting modifications to the device’s software. Android Pay, developed by Google, serves as a practical demonstration of this implementation.
Understanding the Core Functionality
Essentially, SafetyNet doesn't inherently break apps. It provides developers with information, and it is their responsibility to act upon that information if they desire to restrict app usage on compromised devices.
The decision to enforce restrictions based on SafetyNet results rests entirely with the individual application developer.
Android Pay Incompatibility with Rooted Devices
Google’s Android Pay mobile payment system is non-functional on Android devices that have been rooted. Upon attempting to initiate the application, users encounter a notification stating, “Android Pay cannot be used. Google is unable to verify that your device or the software running on it is Android compatible.”
This restriction extends beyond simply rooting a device; utilizing a custom ROM will also trigger this incompatibility. The SafetyNet API determines that the device is not “Android compatible” when operating with a ROM not originally installed by the manufacturer.
Understanding the SafetyNet API
The issue isn’t solely related to gaining root access. Should a device become compromised by system-level malware capable of monitoring Android Pay and similar applications, the SafetyNet API will also block functionality. This preventative measure is a security benefit.
Rooting a device fundamentally alters Android’s established security protocols. Android Pay typically safeguards payment information through Android’s sandboxing capabilities. However, this sandboxing can be circumvented on rooted devices.
Because Google cannot reliably assess the security level of Android Pay on a rooted device or one running an unrecognized custom ROM, access is denied. A detailed explanation of this issue was provided by an Android Pay engineer on the XDA Developers forum.
Why is this restriction in place?
- Root access compromises the security sandbox.
- Custom ROMs introduce unpredictable software environments.
- Google cannot guarantee data protection on modified systems.
Essentially, the SafetyNet API acts as a gatekeeper, ensuring Android Pay operates within a secure and verified environment. This protects both users and the payment ecosystem.
Alternative Root Detection Methods Employed by Applications
While SafetyNet represents a common method for applications to ascertain whether they are executing on a rooted device, it is not the sole technique utilized. Samsung devices, for instance, incorporate a security framework known as KNOX. Rooting a Samsung device invariably triggers the KNOX security system.
Consequently, Samsung Pay, the mobile payment application developed by Samsung, will cease to operate on devices that have been rooted. KNOX is currently leveraged for this functionality, but SafetyNet could be implemented for the same purpose.
Beyond SafetyNet, numerous third-party applications will restrict usage if root access is detected. These applications often achieve this by directly verifying the existence of recognized rooting applications and processes on the device.
Maintaining a current compilation of applications incompatible with rooted devices proves challenging. However, RootCloak offers several such lists. Although these lists may not always be entirely up-to-date, they represent the most comprehensive resources currently available.
A significant proportion of these incompatible applications are within the banking and mobile wallet sectors. They block access on rooted phones as a security measure, aiming to safeguard your financial data from potential interception by malicious software. Furthermore, video streaming applications may also deny functionality on rooted devices, functioning as a form of Digital Rights Management (DRM) to deter the recording of copyrighted content.
Circumventing App Restrictions
A continuous back-and-forth is occurring between Google and users attempting to bypass its security measures, specifically with SafetyNet. Google frequently updates SafetyNet to counteract methods used to circumvent its protections. For instance, Android developer Chainfire pioneered a technique called "systemless root," which roots Android devices without altering the system partition.
Initially, SafetyNet failed to identify these devices as compromised, allowing services like Android Pay to function. However, Google subsequently updated SafetyNet to recognize this new rooting approach. Consequently, Android Pay is now incompatible with systemless root configurations.
Exploiting App Verification Processes
The success of bypassing app restrictions often depends on the specific method an application employs to detect root access. In some cases, it's possible to deceive these checks. Reports indicate that certain Samsung devices can be rooted without triggering the KNOX security feature, preserving functionality with Samsung Pay.
For applications that simply scan for root applications installed on the system, the Xposed Framework module, RootCloak, offers a potential solution. This module aims to mislead apps into believing the device is not rooted.
Applications Affected by Root Detection
RootCloak has been reported to enable functionality with apps like DirecTV GenieGo, Best Buy CinemaNow, and Movies by Flixster, which typically do not operate on rooted devices. However, if these applications are updated to integrate Google’s SafetyNet, this method of circumvention becomes less effective.
General App CompatibilityThe majority of applications will continue to operate without issue after a device has been rooted. The primary exceptions are mobile payment applications, alongside certain banking and financial services. Subscription-based video streaming platforms may also attempt to prevent access to their content.
Should a necessary application fail to function on a rooted device, reverting to the original, unrooted state is a viable option. Restoring the device to its factory settings should re-enable the app’s functionality.
Image Credit: Danny Choo on Flickr