[DISCUSSION] Play Integrity API

Search This thread

10Maximus10

Member
Oct 25, 2022
35
0
Ok, but I argue that the fact that I have Zygisk-LSposed installed, does not attribute to any of my Momo detections

Neither for Ruru, TB-Checker nor SCheck - all those three fully pass in green not finding anything

NB:
TB-Checker extensively looks for XPosed artefacts but it fully passes in green

And actually HMA module for LSPosed helps to pass things for TB-Checker, SCheck and Ruru
I thought that lsposed can be detected because when I recently reflashed the stock firmware for some reason no matter what I did PI api always detected device modifications and failed so I thought that lsposed can also be always detected by some specific app.
 

zgfg

Senior Member
Oct 10, 2016
8,230
5,871
Xiaomi Mi 11
Xiaomi Mi 11 Lite 5G
I thought that lsposed can be detected because when I recently reflashed the stock firmware for some reason no matter what I did PI api always detected device modifications and failed so I thought that lsposed can also be always detected by some specific app.
My SN and PI pass (of course, cannot pass Strong Integrity - cannot trick TEE) with no problem with LSPosed installed
 

linus207

Senior Member
Apr 1, 2013
215
73
Nexus 6
Google Pixel 6 Pro
Hi. I have a riddle that I can't solve. I have two devices: Pixel 6 Pro (raven) and Pixel 7 Pro (cheetah). Both with unlocked bootloader. On Pixel 6 Pro I installed the RiceDroid rom.


It is very functional, does not really require root to give satisfaction from daily use. It runs banking applications, gpay (wallet) and has the accepted status of MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY.

Pixel 7 Pro, on the other hand, is quite a challenge. I installed Paranoid Android Topaz beta 1 on it


Due to limited usability, I rooted and installed Displax mod 2.0 USNF. I couldn't get MEETS_DEVICE_INTEGRITY despite combos with other Magisk modules (Shamiko, Husky, old USNF etc.) So I went back to absolute stock via the online android flash tool. Strangely, on absolute stock, without root, Pixel 7 Pro still shows only MEETS_BASIC_INTEGRITY and no wallet or Netflix or anything "requiring" internal payments accually works. This is a really incomprehensible situation for me considering how the predecessor (Pixel 6 Pro) behaves. I kindly ask for advice and tips.

Cheers
 

pndwal

Senior Member
Hi. I have a riddle that I can't solve. I have two devices: Pixel 6 Pro (raven) and Pixel 7 Pro (cheetah). Both with unlocked bootloader. On Pixel 6 Pro I installed the RiceDroid rom.


It is very functional, does not really require root to give satisfaction from daily use. It runs banking applications, gpay (wallet) and has the accepted status of MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY.

Pixel 7 Pro, on the other hand, is quite a challenge. I installed Paranoid Android Topaz beta 1 on it

Seems Ricedroid is based on lineage/crdroid... You'll see here that crdroid pulls SafetyNet Fix w/ Displax mod from here:
https://github.com/kdrag0n/safetynet-fix/pull/207
(Latest is this commit: c5ed4b1)

I don't see Paranoid Android on that page although that doesn't mean that they don't integrate a fix...

Personally I prefer to use clean ROMs (eg official LOS) that don't integrate spoofing and add these using Magisk as there are less issues with conflicting Magisk modules and when changes (eg Google server end) are made...
Due to limited usability, I rooted and installed Displax mod 2.0 USNF. I couldn't get MEETS_DEVICE_INTEGRITY despite combos with other Magisk modules (Shamiko, Husky, old USNF etc.)
Nb. Displax mod 2.0 USNF is enough for this; USNF settings will often interfere with that fix and your other solutions may be confusing you/the issue...

It is possible there is also an underlying custom ROM issue (as mentioned above or other) that prevents success...
So I went back to absolute stock via the online android flash tool. Strangely, on absolute stock, without root, Pixel 7 Pro still shows only MEETS_BASIC_INTEGRITY and no wallet or Netflix or anything "requiring" internal payments accually works. This is a really incomprehensible situation for me considering how the predecessor (Pixel 6 Pro) behaves. I kindly ask for advice and tips.
Device is not 'absolute stock' if bootloader is unlocked... AVB is reporting that so you don't have deviceIntegrity! - you need the @Displax modded USNF to spoof this by forcing the fallback (based on an exception error mod causes) to basic attestation as well as several prop mismatches needed to bypass hardware evaluation type enforcement... With old Basic attestation (as used in pre A8 devices) you can spoof deviceIntegrity as AVB signals are not backed by HKA.

I recommend that you check this thread, especially the first 8 posts:
https://forum.xda-developers.com/t/unlock-bootloader-root-pixel-7-pro-cheetah-safetynet.4502805/
as there are really not issues getting deviceIntegrity on stock ROM. 😃
Welcome... 🙂 PW
 

linus207

Senior Member
Apr 1, 2013
215
73
Nexus 6
Google Pixel 6 Pro
So I was able to get DEVICE_INTEGRITY on rooted stock. Displax mod turned out to be the perfect and simplest solution.

For more customization I used lsposed+ and the aosp mods module.

Wallet works great, added cards and looks like it will function as it should.

I must admit that there is a lot of confusion on the forums and "online guides", probably due to the high volatility of the situation over time. Sometimes the simplest solutions turn out to be the best.

Thank you for the explanation about spoofing in custom roms based on crdroid/linage, it really explains a lot and finally sorted my mind.
 
  • Like
Reactions: pndwal

pndwal

Senior Member
@shoey63 and/or anyone else familiar with the Asus ROG situation, can you explain how the keystore is broken and how this allows Play Integrity to return STRONG verdict?
You may have missed the exchange here, but I recently analysed & made (educated) guesses w/ @shoey63's help. See here:
https://forum.xda-developers.com/t/discussion-play-integrity-api.4479337/post-87684705
and here:
https://forum.xda-developers.com/t/discussion-play-integrity-api.4479337/post-87684959

Basically It seems droidguard is erroneously sending basic attestation data flagged as hardware backed and this is the basic breakage in keymaster implementation...

Further, gms is not smart enough to challenge this (it would be very unusual after all) but the PI API has the smarts to recognise that some included data is not hardware backed and thus requires (the initial fingerprint) mismatched prop trigger for PI hardware enforcement bypass before accepting the attestation data...

👀 PW
 

V0latyle

Forum Moderator
Staff member
What's the deal with so many people jumping through hoops with Shamiko and lsposed to try to hide root? It would seem that the Play Integrity workaround should work for most people, the exception being apps that use specific root detection methods? In other words, hiding root shouldn't be necessary for most people; passing BASIC and DEVICE integrity should be the main concern, no?
 

zgfg

Senior Member
Oct 10, 2016
8,230
5,871
Xiaomi Mi 11
Xiaomi Mi 11 Lite 5G
What's the deal with so many people jumping through hoops with Shamiko and lsposed to try to hide root? It would seem that the Play Integrity workaround should work for most people, the exception being apps that use specific root detection methods? In other words, hiding root shouldn't be necessary for most people; passing BASIC and DEVICE integrity should be the main concern, no?
Hiding root is necessary for many users because otherwise they cannot use various banking apps, e-citizen apps, mobile device management, etc

Those apps use various other methods to detect root - eg, although you pass Play Integrity (SN), those apps still seek themselves (not through Google's PII/SN) for su, initrc, LSPosed module and/or even for the presence of Magisk app, etc

If they detect, they complain that device is unsecure and user cannot open them to eg configure his banking logging account, etc

More or less, that's all because stakeholders for those apps know that PI/SN attestation is not full-proof, ie, that many users successfully spoof CTS attestation although their Bootloaders are unlocked, custom ROMs installed, boot partition patched with Magisk and so.
Hence they look for other detection methods that are harder (specially for newbies) to spoof

And the tricky part is that you cannot know what they detected and how (obviously, they don't tell you to help you to 'fix') hence the only way is to experiment by various methods

Some method that work for one device/ROM may not work for the other, and of course a method that works for one app ma not work for the other.
But still, most of that is common but unfortunately many users are lazy to follow discussions, read/learn in time and then they ask for help although they didn't even try basic things
 
Last edited:

V0latyle

Forum Moderator
Staff member
Hiding root is necessary for many users because otherwise they cannot use various banking apps, e-citizen apps, mobile device management, etc

Those apps use various other methods to detect root - eg, although you pass Play Integrity (SN), those apps still seek themselves (not through Google's PII/SN) for su, initrc, LSPosed module and/or even for the presence of Magisk app, etc

If they detect, they complain that device is unsecure and user cannot open them to eg configure his banking logging account, etc

More or less, that's all because stakeholders for those apps know that PI/SN attestation is not full-proof, ie, that many users successfully spoof CTS attestation although their Bootloaders are unlocked, custom ROMs installed, boot partition patched with Magisk and so.
Hence they look for other detection methods that are harder (specially for newbies) to spoof
Makes sense

I guess what is bugging me is when someone recommends using Shamiko + lsposed as a fix for PI dependent apps not working. Google Wallet doesn't work? Here, install three modules and configure a bunch of confusing DenyList crap, instead of just installing one module and calling it a day

Occam's razor.
 
  • Like
Reactions: Lord Sithek

zgfg

Senior Member
Oct 10, 2016
8,230
5,871
Xiaomi Mi 11
Xiaomi Mi 11 Lite 5G
Makes sense

I guess what is bugging me is when someone recommends using Shamiko + lsposed as a fix for PI dependent apps not working. Google Wallet doesn't work? Here, install three modules and configure a bunch of confusing DenyList crap, instead of just installing one module and calling it a day

Occam's razor.
That's again the lack of knowledge and understanding

Eg, some user needs to hide root from his banking app. To pass he does not only need USNF but also eg Shamiko, LSPosed + Hide My Apps, etc

Then he tests Wallet and it works for him (bcs, among other things, he did install USNF)

Then another user asks only for Wallet and the first user tells him, you need all those (USNF, hide Magisk app, Shamiko, blue shirt, white socks, umbrella, sunglasses, who knows) bcs he had all that, he passed Wallet but he doesn't really know what of all that was really necessary just for Wallet

And then that 'guide' spreads around like conspiracy theories do (they are sometimes more catchy than the simple truth)
 
Last edited:

pndwal

Senior Member
Makes sense

I guess what is bugging me is when someone recommends using Shamiko + lsposed as a fix for PI dependent apps not working. Google Wallet doesn't work? Here, install three modules and configure a bunch of confusing DenyList crap, instead of just installing one module and calling it a day

Occam's razor.
Google knows S/N / PI are easy to bypass, but don't seem to regard the 'white hat' modding community as high risk, and aren't in a big hurry to preempt enforced use of hardware based attestation verdicts either... In this sense they don't seem to be working against this community (contrary to what some Google haters keep asserting) at all, but they do need to be seen to be providing reliable means for developers of security dependant apps to determine if runtime environment has been tampered, so they've provided evaluationType and strongIntegrity attestations capable of doing this...

The issue for banks is that there there is no inclusion of hardware-backed device model labels with these attestations (at best they can poll props for such information which can be spoofed) which means that there is no assurance that deploying evaluationType or (current) strongIntegrity attestations in their apps on a per-device basis won't be bypassed any more than the likes of deviceIntegrity verdict...

This means that Google have effectively ensured that strongIntegrity verdict needs to be deployed access the board (if at all) to be totally reliable, and that users of any devices launched with Android 7 or less (incl. those now running up to date A12, 13 etc) as well as so many modern OnePlus and other devices (all launched with broken keymaster implementations at least until very recently) would be collateral damage in this event.

... So banks have understandably held off from using the foolproof strongIntegrity (and previous evaluationType) verdict... I believe Google intend to leave things this way and not preempt its use, ie they'll let the banks choose the time (when they deem there is sufficient market saturation of A8+ devices etc) to migrate apps to strongIntegrity verdict use... (New meaning to 'Google is your friend '?)

This also means (as I see it) that Google won't ever use root detection methods other than PI deviceIntegrity for Google Pay (they simply don't want to be seen to lack confidence in their own API for code execution environment security) at least until strongIntegrity is adopted by banks as the necessary new level of gatekeeping required for environment security... At that point I predict that Google will also follow suit...

Banks, on the other hand, have no such qualms using as many extra means to detect device/execution environment tampering as are available, and will often spend money/resources to develop new ones... These generally use PI deviceIntegrity API, but already augment this with a substantial (and. growing) list of root/modified environment detection means, many of which can be bypassed but tools like Skamiko, HMA etc...

So while Google Pay and many banks need nothing more than PI deviceIntegrity passing, other banks, increasingly concerned about (and affected by?) nefarious use of integrity API bypass mods to commit fraud, require methods equal to their integrated security engines (eg Promon) and their customised detections to fool apps into running on modded devices...

I believe this game (both of developing new tactics to coner the mouse, and of developing new methods to outsmart the cat) will only (finally) end with strongIntegrity deployment by banks...

The cat will win and have supper then... but we can have some fun meanwhile... 😝 PW
 
Last edited:
  • Like
Reactions: V0latyle

HippoMan

Senior Member
May 5, 2009
2,035
825
Hippoland
[ ... etc. ... ] Banks, on the other hand, have no such qualms using as many extra means to detect device/execution environment tampering as are available, and will often spend money/resources to develop new ones...

[ ... etc. ... ]

And yet, these same banks gladly issue debit cards to their customers, and these cards are just as easy to steal as mobile devices, and they have many fewer "security" measures associated with them than most of these banks try to implement within mobile devices.

Lots of these cards are set up with credit-card-like clearing mechanisms and can be used without PINs for purchases. Therefore, it is easier to commit fraud via stolen debit cards than via stolen or hacked Android devices.

Furthermore, these banks allow their customers full web-based access to their finances via desktop computers which can be hacked with keystroke-capturing malware that can then be used to determine the victims' login ID's and passwords that are utilized to access these banks' web sites.

And all these desktop computers are rooted, and the banks do nothing to cripple any software on these desktop computers, nor do they even try to force their users to install anti-virus software before allowing web access to their banking sites.

And there are many more desktop computers and debit cards in use in the world than there are rooted Android devices, and much more fraud is committed via compromised home computers and via stolen debit cards than could possibly ever be committed via hacked or stolen rooted Android devices.

I believe that the monetary value of all the fraud that has been prevented by Android-device-crippling "security" software is lower than the amount of money spent by banks to develop and maintain the anti-rooting and anti-modding facilities that they utilize.

I'm not talking about Google themselves here; rather, I'm referring to the stupidity of the management of these banks.

But there's no law against being stupid, and therefore, we mice will be increasingly at the mercy of these cretinous cats.
 

pndwal

Senior Member
And yet, these same banks gladly issue debit cards to their customers, and these cards are just as easy to steal as mobile devices, and they have many fewer "security" measures associated with them than most of these banks try to implement within mobile devices.

Lots of these cards are set up with credit-card-like clearing mechanisms and can be used without PINs for purchases. Therefore, it is easier to commit fraud via stolen debit cards than via stolen or hacked Android devices.

Furthermore, these banks allow their customers full web-based access to their finances via desktop computers which can be hacked with keystroke-capturing malware that can then be used to determine the victims' login ID's and passwords that are utilized to access these banks' web sites.

And all these desktop computers are rooted, and the banks do nothing to cripple any software on these desktop computers, nor do they even try to force their users to install anti-virus software before allowing web access to their banking sites.

And there are many more desktop computers and debit cards in use in the world than there are rooted Android devices, and much more fraud is committed via compromised home computers and via stolen debit cards than could possibly ever be committed via hacked or stolen rooted Android devices.

I believe that the monetary value of all the fraud that has been prevented by Android-device-crippling "security" software is lower than the amount of money spent by banks to develop and maintain the anti-rooting and anti-modding facilities that they utilize.

I'm not talking about Google themselves here; rather, I'm referring to the stupidity of the management of these banks.

But there's no law against being stupid, and therefore, we mice will be increasingly at the mercy of these cretinous cats.
Just realised I replied to the wrong member above... Corrected now...

Anyway, I was simply elaborating on why banks need more detection bypasses than Google's G Pay/Wallet (which goes to the issue of users confusing what bypasses are actually required)... Just stating how things are / developed / are developing...

Did I say anything wrong?... 🙃 PW
 

V0latyle

Forum Moderator
Staff member
Just realised I replied to the wrong member above... Corrected now...

Anyway, I was simply elaborating on why banks need more detection bypasses than Google's G Pay/Wallet (which goes to the issue of users confusing what bypasses are actually required)... Just stating how things are / developed / are developing...

Did I say anything wrong?... 🙃 PW
No, he's just being a little obstinate and ignoring the fact that it's much less "risky" to attempt to exploit vulnerabilities on devices and obtain financial information that way...carrying a stolen card can get you caught, and installing a card skimmer is risky, too. I think it's pretty pointless to rail against the big bad banks when they try to take (necessary) steps to protect their customers, simply because it means that using their apps may not be possible a few white hats. As pndwal said, we are collateral damage.

Google certainly isn't trying to screw us, and if you really want to find issue with banks, I could tell you all about ESG divestments, asset management firms like BlackRock buying up entire subdivisions of single family homes, and companies like PayPal who refuse to let their customers use their services to purchase perfectly legal things such as firearms. Bank Australia will no longer issue loans for new gasoline or diesel cars in as little as 2 years, despite the lack of necessary infrastructure to support EVs.

And if you want to talk about the evils of Google...Look at their arbitrary ranking of search results, to the point of suppressing vital information, as well as their daughter company YouTube which exercises heavy handed censorship against anyone with views to the right of center, while permitting sexually suggestive and disturbing material for children.

But that's another story...
 
  • Like
  • Haha
Reactions: rodken and pndwal

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    @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
    2
    @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
    2
    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
    1
    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:
    Github

    If you're a nerd and you want to check key attestation, use this:
    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:


    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.
    1
    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.
  • 13
    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:
    Github

    If you're a nerd and you want to check key attestation, use this:
    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.

    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 evaluationType. 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:
    1665499433643.png


    The most fundamental change is this: Play Integrity, by default, uses hardware methods to verify BASIC and DEVICE integrity, but also uses the same hardware methods as proof of boot and system integrity. What this means is that Play Integrity uses stronger (and unbreakable!) methods as "proof" of the BASIC and DEVICE verdicts, and uses the availability of these hardware backed methods to determine the STRONG_INTEGRITY verdict.

    These hardware methods include hardware-backed key attestation as well as Verified Boot to verify that a device has not been tampered with. 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 if Play Integrity defaults to unbreakable hardware backed attestation, what can we do if this is broken or unavailable on our devices?
    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)
    1667488774837.png

    You can find that module here:


    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:
    1665497085076.png


    For more information, please read the discussion in this thread.
    8
    Some Insight on the New Cat and Mouse Game...

    Since many are asking:
    Is there a fix for this? ... Can't pass MEETS_STRONG_INTEGRITY.
    I'm posting this WOT. 🤪

    I predict some will like it, some won't... You've been warned! 😜

    FWIW, Play Integrity MEETS_STRONG_INTEGRITY is akin to SafetyNet Evaluation type HARDWARE with CTS Profile match...

    Banks could have used this before (w/ S/N API) but haven't as it would have excluded too many users/devices/customers... Nothing has actually changed with new PI API; MEETS_STRONG_INTEGRITY will exclude the same group, so it's doubtful they'll rush to require this verdict...

    Basically, the means to enforce Hardware key-backed Attestation has already been here w/ either of these attestations, but banks don't want to exclude all those w/Android 7 and below, or many w/ broken keymaster 3+ implementations in Android 8+ devices (CTS Profile match with HARDWARE Evaluation type / MEETS_STRONG_INTEGRITY won't pass with locked bootloader), eg most OnePlus devices (nb. Keymaster may have been fixed in OnePlus devices launched with Android 12+)...

    I'm guessing the banks may well leverage this at some point if the time arrives when they feel there is a sufficient critical mass of devices w/ working hardware-backed keymaster (ie w/ hardware keystore, A8+) to trade against the number of modded (bootloader unlocked) devices in use especially if they deem Google slow to close the fallback-to-basic-attestation loophole that has allowed modders to bypass hardware based attestation to CTS Profile match enforcement (by triggering fallback to BASIC Evaluation type as well as bypassing enforcement) and also to allow its counterpart, MEETS_DEVICE_INTEGRITY verdict. (Nb. This verdict should not properly be obtained on modded devices, and it requires the same attestations as S/N as well as the same tricks to trigger fallback to BASIC attestation and bypass enforcement) The incentive to use this foolproof means is also certainly being weighed constantly against the cost / need to use their own custom means of sophisticated 'root' detection...

    Google also, as other authorities have commented, appears to be waiting for some 'acceptable' percentile / critical mass of such devices in use to be reached also, before they swing the 'big hammer' that is Hardware-backed Key Attestation enforcement and that will definitely spell the endgame for modders' use of bank apps, and possibly for OnePlus users and others whose devices have broken keymaster*

    *Nb. There are exceptions, eg Asus ROG Phone 3, where broken keymaster actually results in PI MEETS_STRONG_INTEGRITY and S/N CTS Profile match with Evaluation type HARDWARE regardless of bootloader status instead of the converse...

    It seems likely to me that OnePlus and other devices with broken keymaster can be spared if Google do prevent on-device triggering of fallbacks to basic attestation use simply by using device info contained in the cryptographic attestation sent to Google servers instead of userspace model props etc now used, to bypass enforcement at the server end. If they do this it would be a concession as modded OnePlus etc may then still be able to pass CTS Profile match / DEVICE_INTEGRITY while other modern modded devices won't...

    This would, however, be a way to swing the hammer a bit sooner, and either way, as can be seen from the above, they may be forced to do this once banks do indicate a willingness to enforce
    MEETS_STRONG_INTEGRITY in order to stop a landslide that would prevent all stock locked Android 7 and lower devices using bank apps etc... Or maybe they'll just let the landslide go and force bank app users to upgrade devices...

    Hopefully this gives some insight regarding what pressures may finally force Google to properly deploy (ie. strictly enforce) Hardware-based Key Attestation on devices that support it...

    Personally, I think Google has exercised great restraint, possibly out of some regard for the modding community since I can't see any other compelling reason not to have properly enforced CTS Profile match with HARDWARE Evaluation type where supported or Hardware attested MEETS_DEVICE_INTEGRITY sooner, unless the matter of ensuring that the API properly sees hardware identifiers (ie. these cannot be spoofed, which I believe would again require cryptographic server-side attestation that the device doesn't indicate the presence of hardware keystore) for bypassing hardware attestation enforcement in devices launched with Android 7 and earlier is proving difficult (but I'm fairly sure this mechanism will be a simple matter for Google and probably already in place)... 😛

    It may well be that Google is benevolently holding off but is using/will use MEETS_STRONG_INTEGRITY uptake data as tha natural indicator of the banks propensity for reliable HKA... My bet is that if Google doesn't have immediate plans to move to srtict HKA enforcement for MEETS_DEVICE_INTEGRITY, then they will when the banks themselves move to use the even stricter MEETS_STRONG_INTEGRITY verdict...


    👀 🤠
    5
    RL does hold me tight lately.
    ...which is why I already moved a few posts @V0latyle requested. Got your back! (y)
    5

    Tech = Spy-Biz, HippoMan

    FWIW, I'm answering this here (might be the best place...):
    Its none of the banks business to stop their clients from using rooted devices. Theyre just adding another hindrance to smooth banking operations thereby possibly hampering their own business by wasting both their and their clients time. Thats Stupidity!
    Well, seems that's a popular option here, but it's also a highly subjective one...
    Bank Devs did you hear? Pls discuss this with your bosses. Its like going backwards instead of forward.
    And you're going to need to do better than that... Even if banks themselves didn't persue these initiatives (ostensibly to protect their interests / bottom line) they're being driven by many other powerful entities...

    The Open Mobile Terminal Platform (OMTP) first defined TEE in their "Advanced Trusted Environment:OMTP TR1" standard around 2007, and for some 15 years Hardware implementations for a hardware isolation mechanism with a secure operating system running on top of this along with an associated "hardware root of trust" have been progressively adopted and implemented not just in/by mobile devices / ARM SOCs (TrustZone, first iterations in 2008, but not much further development/excited customer till 1012, and more), but also by Apple (Secure Enclave is a hardware feature found in most versions of iPhone, iPad, Mac, Apple TV, Apple Watch and HomePod), AMD (Platform Security Processor, PSP, 2013, and more), IBM (IBM Secure Service Container, 2017, and more),
    Intel (Trusted Execution Technology / Management Engine, 2008 and more),
    RISC-V SOCs (MultiZone™ Security Trusted Execution Environment, 2018, and more)...

    The aim of tee on SOC is to to reduce the attack surface... Typical applications include DRM functionality for controlling the use of media (ie. media security) and preventing any unapproved use of a device (ie. device/data security)...

    And it's not just banks who are interested in this; Service providers, mobile network operators (MNO), operating system developers, application developers, device manufacturers, platform providers and silicon vendors are the main stakeholders contributing to the standardization efforts around the TEE in SOC and implementation...

    Banks are simply impatient as, at least in Android, secure TEE implementation for device security is un-developed, flawed, lagging, arguably broken even... unlike in iOS (iOS Secure Enclave) ... And that's a problem, not just for Google...

    So banks do their own security checks... Simply because Android Verified Boot doesn't work for them... I mean attestation to it in the usable deviceIntegrity verdict can't be trusted... I mean it's hardly 'verified', is it?... It's 'chain of trust' can't be trusted because components can be spoofed so Verified Boot can't be trusted, and all because of TEE not being usefully implemented (ie. to allow detection of tampering with a runtime environment along with either a hardware based attestation to the device model or to a working implementation of keymaster for enforcing hardware evaluation type)... And it's not useful presently because the simple implementations of both SafetyNet evaluationType and Play Integrity strongIntegrity will necessarily fail all devices using Android 7 and below as well many OnePlus and other devices with broken keystore implementations if adopted (because attestation doesn't include the information in parentheses above) making this option largely impractical...

    Don't expect that banks won't adopt PI strongIntegrity verdict use sooner or later however... they're only waiting for a certain critical mass of compliant devices (which only they will determine)... or for a better solution (read: more useful hardware based attestation to a trusted, non-tampered runtime environment)...

    Moreover, the efforts banks are making in persuing their own detection of tampered runtime environments as an interim measure only highlights their own interest/ stake in TEE in SOC implementation of keystore/keymaster attestation for device security and standardization...

    I totally agree!

    And as I've mentioned here before, every desktop computer is a rooted device, and of course we don't see the banks trying to hinder us from accessing their services from our computers.

    And banks gladly issue us debit cards which we keep in our wallets that are just as easy to steal as mobile devices.

    Rooted Android devices are just low-hanging fruit. And the amount of fraud that's prevented by trying to fight against Android root is minuscule, given the extremely small percentage of mobile device users who want to use rooted Android devices. I wouldn't be surprised if the amount of money that banks spend for anti-Android-modding software development exceeds the maximum amount of money that could be lost via the hacking of modded Android devices.
    But as I've told you before, and as the above should make abundantly clear, TEE and other, especially hardware backed, means to detect tampered execution environments for an application developer's code are here to stay in mobile devices, and are arriving in PCs also... cos like banks, Google and iOS etc, Microsoft is doing the maths also...
    In 2021, protections built into Windows, Azure, Microsoft 365, and Microsoft Defender for Office 365 have blocked more than 9.6 billion malware threats, more than 35.7 billion phishing and other malicious emails, and 25.6 billion attempts to hijack our enterprise customers by brute-forcing stolen passwords—that’s more than 800 password attacks per second...
    https://www.microsoft.com/security/...for-windows-11-will-help-protect-hybrid-work/

    Hardware and software makers hope TEEs provide a long-term solution for using sensitive data in a more secure manner on smartphones, PCs, cloud systems, and virtualized workloads...
    https://www.hpe.com/us/en/insights/...with-trusted-execution-environments-2102.html

    And Microsoft are already spruiking Windows 11 as a "Zero Trust" solution for PC advanced security needs...

    Guards against sophisticated attacks​

    Protects down to the firmware level with hardware security features that shield user credentials and other critical data.

    Secured-core PCs and hardware-based security​

    Secured-core PCs deliver the highest level of Windows 11 protection including advanced protection of firmware and dynamic root of trust measurement.

    Windows 11 security innovations​

    Microsoft optimizes Windows 11 for Zero Trust protection. Read the Windows 11 Security Guide for a quick overview.
    https://www.microsoft.com/en-us/windows/business/windows-11-secured-core-computers

    Anyway, as I see it, we are able to have a bit of fun beating the system, or really subverting mobile OS's security models only because these have been slow to implement proper / useful "zero trust" protections... The fun's sure to end sooner or later however cos we live in the real world!... And being real, you and I both know 'bank devs' will NEVER convince their bosses to abandon these advances either! (...ok, ok... advancement, regression, it's your call... or is it?... Who do we think we are???)...

    Eh guys?

    ... The only way you'll get your wish is by cobbling together enough funds to buy the banks, Google, the SOC makers and the OEMs you love ... Then you'll have a fighting chance. 🙂...

    Wish you luck... PW
    4
    I am not sure about the Google Pay Magisk Discussion Thread but, posts (including mine) related to Play Integrity in the Universal SafetyNet Fix 2.3.1 thread seem to start around Post # 1,796.

    All the posts about Play Integrity (that are not related to the USNF module) would have to be moved and kept in order to this thread.
    I am not sure how easy that would be to do, since a lot of the discussion included linked posts in the responses.

    Maybe @mrjuniork has an idea of the best and easiest way to do it?

    Cheers. :cowboy:

    PS.
    Sorry to ping you mrjuniork.
    I might be wrong but, it looks like you will be the one who gets stuck moving the posts.
    🙃