[DISCUSSION] Play Integrity API

[zgfg]

This is what my apps return, maybe you can find smthn useful, if you have the time of course.

In the Play Integrity and SafetyNet, observe the button View JSON

Click on that, read what it says and provide their screenshots (if not visible at once, scroll till the end of JSONs and post the screenshots showing complete JSON responses)

Btw, do you maybe have a custom ROM without Google Play Services?

Also, make sure that the phone is connected to Internet

Google Play Services (GMS) is required and GMS must be able to connect to the Google servers

 

[zagreous]

In the Play Integrity and SafetyNet, observe the button View JSON

Click on that, read what it says and provide their screenshots (if not visible at once, scroll till the end of JSONs and post the screenshots showing complete JSON responses)

Btw, do you maybe have a custom ROM without Google Play Services?

Also, make sure that the phone is connected to Internet

Google Play Services (GMS) is required and GMS must be able to connect to the Google servers

Lol I just ran tb checker so I could provide the json and suddenly i get 2 green ticks (basic and device integrity). Idk how that happened, since I just restarted my phone (again). Thank you for your time though.

 

[V0latyle]

Lol I just ran tb checker so I could provide the json and suddenly i get 2 green ticks (basic and device integrity). Idk how that happened, since I just restarted my phone (again). Thank you for your time though.

Pesky gremlins.

 

[anshul3.sharma]

While requesting integrityToken using
"integrityManager
.requestIntegrityToken(
IntegrityTokenRequest.builder().setNonce(encodedNonce).setCloudProjectNumber(projectId).build());"

It is working for dev build variant, but for prod build flavor it is giving me below error


com.google.android.play.core.integrity.IntegrityServiceException: -1: Integrity API error (-1): Integrity API is not available.

The Play Store version might be old, or the application is not allowlisted to use this API.

Recommended actions:

1) Make sure that an app is allowlisted to use the API.

2) Ask the user to update Play Store.

(https://developer.android.com/googl...del/IntegrityErrorCode.html#API_NOT_AVAILABLE).

Can anyone please help here

 

[V0latyle]

@pndwal I've updated the OP yet again to reflect what we discussed about Android 8 devices.

The basics as I understand them:

• Pre 8.0 devices are not capable of hardware backed attestation; so Play Integrity defaults to basic; should pass both BASIC and DEVICE_INTEGRITY in most cases even with an unlocked bootloader although the latter may require other alterations such as MHPC
• Android 8.0+ devices default to hardware backed attestation, meaning that all 3 verdicts will only pass on a locked bootloader and OEM firmware
• USNF mod forces basic attestation method for rooted 8.0+ devices, so they're basically in the same camp as the pre 8.0 devices
• No apps are currently known to require STRONG_INTEGRITY

 

[iamthecarley]

Play Integrity API

What is Play Integrity?
Play Integrity has replaced SafetyNet for the most part, with a deadline of June 2024, when Google's SafetyNet servers will go offline. Apps that continue to exclusively depend on SafetyNet will no longer work once this happens. Most developers have already migrated to Play Integrity.

Is Play Integrity the same as Play Protect?
No. Play Integrity provides users with the ability to verify device compatibility and security, much like SafetyNet did. Play Protect is a part of the Play Store that ensures that your device is certified, and helps to protect against malware. In this context, "certified" refers to whether or not your device has passed Android compatibility testing. This is also used for part of the Play Integrity checks. More information here


My device passes SafetyNet but I can't use Google Pay/other apps.
Don't rely on SafetyNet as a good assessment of your device's compatibility and security. It is possible to pass SafetyNet, but fail Play Integrity.
Rooted Pixel 5 on stock firmware: USNF 2.3.1 shows SafetyNet Pass using YASNAC, but device fails Play Integrity DEVICE_INTEGRITY check.

How do I know if my device is passing Play Integrity checks?
To check Play Integrity status, you can use this app:

Play Integrity API Checker - Apps on Google Play

Get info about your Device Integrity through the Play Intergrity API

play.google.com

Github

If you're a nerd and you want to check key attestation, use this:

Key Attestation Demo - Apps on Google Play

Demo for Key Attestation feature of the Android system.

play.google.com

Github

What causes a device to fail Play Integrity checks?
It depends on your Android version and device state. If you're on an old version of Android prior to 8.0, even an unmodified device will only pass BASIC_INTEGRITY and DEVICE_INTEGRITY, because they are not capable of hardware backed attestation methods. Android 8.0+ devices that are not modified or unlocked should pass all 3; Android 8.0+ devices with unlocked bootloaders will fail all 3, because the unlocked bootloader state means hardware backed attestation is not possible.

What do I do if my device is failing all 3 checks?
You can use the Universal SafetyNet Fix Magisk module 2.4.0 or higher, which forces basic attestation similar to pre Android 8. If you're on rooted OEM firmware, this should be sufficient for most apps including Google Pay. Custom ROMs and Chinese OEMs may have to use fingerprint altering methods to pass. It is not possible to pass STRONG integrity on an unlocked bootloader...unless it's"broken", like an ASUS ROG. Fortunately, this isn't a big deal, as no app developers are known to require that verdict.

Now, details on what Play Integrity is and how it works...


SafetyNet has been discontinued in favor of the new Play Integrity, which uses stronger methods to verify the security of a device. This is why many rooted users have been unable to use security sensitive apps, such as banking and DRM. There is a workaround for this.

But first, details on the new API.
The three elements in Play Integrity are:

• MEETS_DEVICE_INTEGRITY: Corresponds to SafetyNet ctsProfileMatch. The app is running on an Android device powered by Google Play services. The device passes system integrity checks and meets Android compatibility requirements. (Device profile matches that of a device that has passed Compatibility Test Suite) A device that fails this will appear as Uncertified in Play Store.
• MEETS_BASIC_INTEGRITY: Corresponds to SafetyNet basicIntegrity. The app is running on a device that passes basic system integrity checks. The device may not meet Android compatibility requirements and may not be approved to run Google Play services. For example, the device may be running an unrecognized version of Android, may have an unlocked bootloader, or may not have been certified by the manufacturer. Most devices should pass this, even if they're rooted.
• MEETS_STRONG_INTEGRITY: Corresponds to SafetyNet HARDWARE_BACKED attestation. The app is running on an Android device powered by Google Play services and has a strong guarantee of system integrity such as a hardware-backed proof of boot integrity. The device passes system integrity checks and meets Android compatibility requirements. An unlocked bootloader will ALWAYS fail this label because boot integrity cannot be verified, meaning that hardware backed attestation methods cannot be used.

This table shows the relationship between SafetyNet and Play Integrity responses:
View attachment 5732079

The most fundamental change is that Play Integrity, by default, uses hardware methods to verify BASIC and DEVICE integrity, which is why simply having an unlocked bootloader will cause the device to fail all 3 results. However, Play Integrity also uses hardware methods (if available) to verify device security state in addition to the aforementioned checks. This is STRONG integrity, which relies on hardware-backed key attestation as well as Verified Boot to verify that a device has not been tampered with and MEETS_STRONG_INTEGRITY. It is not possible to pass STRONG integrity on an unlocked and/or modified device, or a pre Android 8 device. (Notable exception being devices with broken keystores such as ASUS ROG)

It is worth noting that SafetyNet always provided the means for developers to force hardware backed evaluation types; none did, including Google. The same seems to still be true; most app developers require DEVICE verdict, "secure" apps require BASIC and DEVICE, but none are known to require STRONG

So this all sounds rather depressing. What do we do?
Fortunately, we have the ability to force a basic attestation method that prevents the use of hardware checks, meaning it is possible to partially pass. Universal SafetyNet Fix 2.4.0 does this:
(Response from Play Integrity Checker on my rooted Pixel 5 with Universal SafetyNet Fix MOD by Displax)
View attachment 5751415
You can find that module here:

Releases · kdrag0n/safetynet-fix

Google SafetyNet attestation workarounds for Magisk - kdrag0n/safetynet-fix

github.com

As far as how this is going to affect us in the future, it's up to the app developers to decide what results they want. In most cases, all they care about is BASIC and DEVICE. But if they really want to ensure that they're running on a trusted platform, they can require STRONG attestation, which cannot be spoofed or bypassed. BASIC and DEVICE can, because they use the same mechanisms that SafetyNet did. The million dollar question is whether they ever will.


For those interested in the timeline:
View attachment 5732061

For more information, please read the discussion in this thread.

Thank you SO much for not only giving solution(s), but for explaining each bullet point in such depth and detail. This is extremely helpful in giving not only the "what" but also the "how" and "why" - much appreciated.

 

[pndwal]

@pndwal I've updated the OP yet again to reflect what we discussed about Android 8 devices.

The basics as I understand them:

• Pre 8.0 devices are not capable of hardware backed attestation; so Play Integrity defaults to basic; should pass both BASIC and DEVICE_INTEGRITY in most cases even with an unlocked bootloader although the latter may require other alterations such as MHPC

Actually for unlocked/rooted devices both basicIntegrity and deviceIntegrity will require hiding root from droidguard (attestation) gms process as a minimum for passing verdicts and many will need changes to sensitive prop values also. Old MagiskHide did this. Or users can add droidguard (attestation) gms process in denylist (w/ or w/o Shamiko or other hiding) and use MHPC to adjust sensitive prop values (does this even with nothing configured by user). Or just run USNF (From v2.3.1: Restored support for Android 7... Actually I think he means A7 and older per commit: magisk: Allow limited installation on Android 7 and older … "In general, users on such old versions of Android don't need to bypass
hardware-backed attestation... so allow them to install the module without the Zygisk part.") to fix sensitive props... Users may still need to hide root from droidguard (attestation) gms process manually in this case as Zygisk parts won't load... I'm not sure...

• Android 8.0+ devices default to hardware backed attestation, meaning that all 3 verdicts will only pass on a locked bootloader and OEM firmware

All 3 together, yes... 2 can pass /unlocked bootloader... (... The pedant in me is showing. )

• USNF mod forces basic attestation method for rooted 8.0+ devices, so they're basically in the same camp as the pre 8.0 devices
• No apps are currently known to require STRONG_INTEGRITY

Yup...

FWIW I'm working on a simplified explanation for Google's progressive employment of hardware-backed attestation, USNF's evolving bypass and fallback methods and clarification of common misunderstandings for USNF discussion thread... It's taking a while as I have limited time ATM with long days (also very flakey internet w/ vodafail and patchy WiFi in small-town Taree)... PW

 

[DartGerion]

Hi, guys!
Apologize for errors in writing, English is not my first language. For me the Gpay was working until today. I've checked the API integrity and receive the UNEVALUATED results with all integrity red. I've attached the denylist and magisk modules. Right now my USNF mod is 2.3.1 v2.0 (i know there is newest one, i've tried it with same results). Can you, please, help me identify the culprit. MOMO detects only wrong partition, so i think it's just the bootloader unlock. My phone is Oneplus 7T Pro, running stock OOS11, unlocked BL.

 

[21prods]

Hello to all.
I've got a phone with LOS installed on it. For some time I've been using 'ih8sn' to enable Google Pay, but recently it began to state that my phone is no longer secure.
Since then, I've seen that the problem comes from the change from Safetynet attestation to Play Integrity.
Is there any way to pass Play Integrity without magisk in a custom ROM? I'm happy without rooting my phone and 'ih8sn' was perfect for me (up until a couple of days, at least).
Thanks in advance

 

[V0latyle]

Hello to all.
I've got a phone with LOS installed on it. For some time I've been using 'ih8sn' to enable Google Pay, but recently it began to state that my phone is no longer secure.
Since then, I've seen that the problem comes from the change from Safetynet attestation to Play Integrity.
Is there any way to pass Play Integrity without magisk in a custom ROM? I'm happy without rooting my phone and 'ih8sn' was perfect for me (up until a couple of days, at least).
Thanks in advance

Yes...if the fixes in USNF are implemented in that ROM

 

[21prods]

Yes...if the fixes in USNF are implemented in that ROM

So, not much to do for the time being, at least from my side, as I don't have any knowledge to do that and I very much doubt Lineage will ever do it.
Thanks for the clarification

 

[pndwal]

So, not much to do for the time being, at least from my side, as I don't have any knowledge to do that and I very much doubt Lineage will ever do it.
Thanks for the clarification

Official LOS will never do it... Many unofficial builds do however... But a number of users of ROMs w/ integrated SNF are reporting similar intermittent Play Integrity failures to what those using latest USNF are reporting ATM... PW

 

[Arcline]

What do you guys think about KernelSU in connection to play integrity?

 

[V0latyle]

What do you guys think about KernelSU in connection to play integrity?

What about it? @pndwal can provide more insight than I can but I don't think this would make any real difference to our current situation. We are already able to "hide" root, so having root built into the kernel won't make much difference from a detection standpoint, at least not yet. Furthermore, the issue with hardware backed attestation is the "link" between the system's cryptographic authentication and the hardware keystore; an unlocked bootloader breaks this link, and circumventing this would require not just one but two major breakthroughs - you'd have to reverse engineer the bootloader to the point where you could provide a "fake" guarantee of root of trust, and you'd have to decrypt the aforementioned link.

Basically, think of it this way: The kernel and system are sitting at one end of a encrypted "pipe"; the hardware keystore is at the other end. If the bootloader is unlocked, the pipe's integrity cannot be guaranteed, and the system knows this. So, you'd not only have to figure out a way to fool everything into thinking the pipe is secure, but you'd also have to figure out how to successfully "tap" the pipe by breaking the encryption.

 

[pndwal]

What do you guys think about KernelSU in connection to play integrity?

What about it? @pndwal can provide more insight than I can but I don't think this would make any real difference to our current situation...

I'm not up to speed with this... Just read this (interesting read):
https://www.xda-developers.com/kernelsu-gki-root/

I can't see why the challenges with respect to bypassing Play Integrity detections or hiding root / modified OS environments in general would be any easier or much different with the KernelSU approach either however...

Looks like an interesting Magisk alternative with similar potential for systemless modules etc by @weishu in much the same way as @weishu's VirtualXposed and Taichi are interesting alternatives to mainstream LSPosed... I imagine LSP support for Magisk (which is also adapting for GKI etc) may be the telling factor in development progress and uptake level differences between these two root alternatives for some considerable time, but I'm not a betting man... PW

 

[oliversum]

Hi, guys!
Apologize for errors in writing, English is not my first language. For me the Gpay was working until today. I've checked the API integrity and receive the UNEVALUATED results with all integrity red. I've attached the denylist and magisk modules. Right now my USNF mod is 2.3.1 v2.0 (i know there is newest one, i've tried it with same results). Can you, please, help me identify the culprit. MOMO detects only wrong partition, so i think it's just the bootloader unlock. My phone is Oneplus 7T Pro, running stock OOS11, unlocked BL.

Same here, but I'm using Universal SafetyNet Fix v.2.4.0 and Zygisk - LSPosed v.1.8.6 (6712).

 

[DartGerion]

Same here, but I'm using Universal SafetyNet Fix v.2.4.0 and Zygisk - LSPosed v.1.8.6 (6712).

Read back a bit, maybe those tips might help you.

 

[oliversum]

Read back a bit, maybe those tips might help you.

Thanks for your reply!
Yes, I did, but so far I didn't find a solution...

Interestingly enough: Right after a restart I get "meets_basic_integrity", but not device nor strong integrity.
A few seconds later I don't even reach "meets_basic_integrity" anymore.

 

[pndwal]

Thanks for your reply!
Yes, I did, but so far I didn't find a solution...

Interestingly enough: Right after a restart I get "meets_basic_integrity", but not device nor strong integrity.
A few seconds later I don't even reach "meets_basic_integrity" anymore.

You may have other issues also, but see this:
https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88052749

PW

 

[LaiKash]

Do we know why in ASUS ROG Phone 3 the keystore is broken? I'm interested on it and why exactly it can pass the STRONG hardware verification.