Developers should be aware that a local attacker with root privileges will always be able to defeat 'tamper-detection' checks on the client side, via tampering with the data Google Service feed to the SafetyNet service.
The advantage of using SafetyNet over conventional root-detection and tamper-detection approaches seem to be that it shifts the workload of attackers as follows: When attacking conventional root-detection mechanisms, an attacker can examine how the protection mechanism's controls are designed and disable these controls or feed them with manipulated data in ways they know the checks will be bypassed. On the contrary, SafetyNet is implemented in such way that only the data collection part of the system can be observed; not the implementation of most checks. For example, SafetyNet has the capability to retrieve a list of all files in the filesystem. An attacker attempting to defeat the system would need to examine all gathered data and make educated guesses over what Google would consider a sign of tampering. Note that the attacker wouldn’t be able to observe what the data sent to Google from a non-rooted device looks like; so the attacker cannot simply use that data.
In practice though, it seems that the current SafetyNet implementation can be easily defeated via moving the su binary to a different location and hooking a call that reads a file with information about the selinux status of the device.
We expect that in the future, Google will implement more checks like verification of the integrity of the /system partition, turn on some checks that are not currently enabled and do a better job in data correlation.
Developers that are already using a different system of rooting or tamper detection can include SafetyNet attestation results as an additional mechanism in their existing implementation.
SafetyNet research: John Kozyrakis, Technical Strategist at Synopsys
Google Play is a trademark of Google Inc.