[INFO] Play Integrity API - replacement for SafetyNet

Search This thread
By:
Advanced…
P

pndwal

Senior Member
Jun 23, 2016
6,374
7,182
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
LaiKash said:
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.
Click to expand...
Click to collapse
AFAIK keystore/keymaster/keymint isn't broken in ROG Phone 3... Seems it has working keymaster implementation but the droidguard attestation is flawed...

FWIW, since DroidGuard itself is implemented as a custom virtual machine running dynamically loaded proprietary Google bytecode (unique for each attestation request) and when DroidGuardService is triggered it also checks latest DroidGuard version has been loaded as well, I believe that the Bootloader Verification it sources for Hardware Attestation as KeyStore.getCertificateChain is really the issue, so it comes back to the OEM's implementation of AVB and bootloader... Duplicating this in other devices, it seems, would depend on finding a boot chain or low-level vulnerability.

Some of the signals that ROG Phone 3's boot chain may be sending in error are outlined in this Google doc:
https://developer.android.com/training/articles/security-key-attestation

I put something (w/ help from @shoey63) about Rog Phone 3 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

Regarding the common failure of OEM's to test that keymaster, driodguard, AVB chain of trust, etc, responses are accurate and implementations comply with Google requirements/specs, Google seems to be tightening up at least w/ respect to broken keymaster implementations:
pndwal said:
...

Nb. Google have clearly been steadily increasing the number of prop values used to flag devices for hardware based evaluation type enforcement in their whitelist implementation for newer devices/OSs... Notably, the last addition exempts no API level 33+ LV devices!

This means that no stock (un-modded) 33+ devices will pass deviceIntegrity w/o HKA, so it seems that Google expect OnePlus and other OEM's to have fixed bad keymaster implementations in all devices launched w/ Android 13+...

If manufacturers mess this up again, their stock/locked devices can now never pass even deviceIntegrity verdict (unless Google revert the first_api_level flag that effectively whitelists all A13+ devices for HKA evaluation type enforcement), so these are effectively being forced to 'up their game' at this time... 🙃
Click to expand...
Click to collapse
Guess they may need to start revoking device certifications to force OEM's to take due care with bootloader / AVB implementations however...

🤠 PW
 
Last edited:
L

LaiKash

Member
Sep 24, 2019
5
1
pndwal said:
AFAIK keystore/keymaster/keymint isn't broken in ROG Phone 3... Seems it has working keymaster implementation but the droidguard attestation is flawed...

FWIW, since DroidGuard itself is implemented as a custom virtual machine running dynamically loaded proprietary Google bytecode (unique for each attestation request) and when DroidGuardService is triggered it also checks latest DroidGuard version has been loaded as well, I believe that the Bootloader Verification it sources for Hardware Attestation as KeyStore.getCertificateChain is really the issue, so it comes back to the OEM's implementation of AVB and bootloader... Duplicating this in other devices, it seems, would depend on finding a boot chain or low-level vulnerability.

Some of the signals that ROG Phone 3's boot chain may be sending in error are outlined in this Google doc:
https://developer.android.com/training/articles/security-key-attestation

I put something (w/ help from @shoey63) about Rog Phone 3 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

Regarding the common failure of OEM's to test that keymaster, driodguard, AVB chain of trust, etc, responses are accurate and implementations comply with Google requirements/specs, Google seems to be tightening up at least w/ respect to broken keymaster implementations:

Guess they may need to start revoking device certifications to force OEM's to take due care with bootloader / AVB implementations however...

🤠 PW
Click to expand...
Click to collapse

Could it be possible to emulate this same behaviour with an emulator so as to test it? Trying to replicate the strong integrity verification with a rooted emulator (with Play Store so that the Integrity API can be executed) could be a really good starting point for some tests :)
 
P

pndwal

Senior Member
Jun 23, 2016
6,374
7,182
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
LaiKash said:
Could it be possible to emulate this same behaviour with an emulator so as to test it? Trying to replicate the strong integrity verification with a rooted emulator (with Play Store so that the Integrity API can be executed) could be a really good starting point for some tests :)
Click to expand...
Click to collapse
Emulate the flawed boot-chain VerifiedBootState data in verifiable hardware-backed key pairs with the root certificate within thie chain of X.509 certificates signed with manufacturer's factory set attestation root key etc, etc?

Maybe... doubtful... ...But I'm certainly the wrong person to be asking... 😝 PW
 
I

immortalwon

Senior Member
Mar 11, 2017
232
97
pndwal said:
Emulate the flawed boot-chain VerifiedBootState data in verifiable hardware-backed key pairs with the root certificate within thie chain of X.509 certificates signed with manufacturer's factory set attestation root key etc, etc?

Maybe... doubtful... ...But I'm certainly the wrong person to be asking... 😝 PW
Click to expand...
Click to collapse

Should I buy this used phone from someone asus rog 3 if I want to have strong device integrity with unlocked bootloader? Asking for a friend
 
V0latyle

V0latyle

Forum Moderator
Staff member
Feb 20, 2011
6,757
2
11,013
The Heartland of America
Google Pixel 5
Google Pixel 5a
immortalwon said:
Should I buy this used phone from someone asus rog 3 if I want to have strong device integrity with unlocked bootloader? Asking for a friend
Click to expand...
Click to collapse
There's not really any point to passing STRONG_INTEGRITY, as there are no apps that depend on it. Most apps that are not security sensitive depend only on DEVICE result (to ensure they're running on a compatible platform) while those that are use the BASIC result as well as a mild guarantee of platform integrity. Google knows that both of these can be defeated and are not a secure guarantee, which is why they implemented HARDWARE_BACKED attestation in SafetyNet (now Play Integrity STRONG) but as far as I know, very few if any apps actually use it. As @shoey63 has demonstrated, the only "easy" way to pass all 3 is factory state locked, as with any other device; while it is capable of passing STRONG while unlocked, it's taken some work to get there.
 
  • Like
Reactions: rodken
I

immortalwon

Senior Member
Mar 11, 2017
232
97
V0latyle said:
There's not really any point to passing STRONG_INTEGRITY, as there are no apps that depend on it. Most apps that are not security sensitive depend only on DEVICE result (to ensure they're running on a compatible platform) while those that are use the BASIC result as well as a mild guarantee of platform integrity. Google knows that both of these can be defeated and are not a secure guarantee, which is why they implemented HARDWARE_BACKED attestation in SafetyNet (now Play Integrity STRONG) but as far as I know, very few if any apps actually use it. As @shoey63 has demonstrated, the only "easy" way to pass all 3 is factory state locked, as with any other device; while it is capable of passing STRONG while unlocked, it's taken some work to get there.
Click to expand...
Click to collapse
Thanks for the explanation. Only reason I am concerned is because one day Google will require this high level of integrity and I would like to remain unlocked and bypass the security they implement
 
V0latyle

V0latyle

Forum Moderator
Staff member
Feb 20, 2011
6,757
2
11,013
The Heartland of America
Google Pixel 5
Google Pixel 5a
immortalwon said:
Thanks for the explanation. Only reason I am concerned is because one day Google will require this high level of integrity and I would like to remain unlocked and bypass the security they implement
Click to expand...
Click to collapse
Well...there's no guarantee they will. They had the ability to require HARDWARE_BACKED evaluationType in SafetyNet but they never did for any of their own apps, and as far as I know, neither did any app developers. There's no saying whether they will or won't. The one thing that "protects" us is the fact that all pre Android 8 platforms are not capable of hardware key attestation, therefore they will never pass STRONG Integrity.

So while it's entirely possible that they could, it's worth noting that they always could since Android 8 (or at least whenever SafetyNet supported hardware backed attestation), but they never did.

Therefore the question is really whether they would start doing something that they never did before despite having the ability to do so for quite some time. If they could but they didn't, why would they start?
 
  • Like
Reactions: immortalwon
Lughnasadh

Lughnasadh

Senior Member
Mar 23, 2015
5,176
6,063
Google Nexus 5
Huawei Nexus 6P
  • Like
Reactions: DaKing1512, ipdev, chichino84 and 1 other person
V0latyle

V0latyle

Forum Moderator
Staff member
Feb 20, 2011
6,757
2
11,013
The Heartland of America
Google Pixel 5
Google Pixel 5a
Lughnasadh said:
Displax updated his mod to 2.3.1-MOD_3.0. Not sure if it will help.

github.com

Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

Google SafetyNet attestation workarounds for Magisk - Release v2.3.1-MOD_3.0 · Displax/safetynet-fix
github.com github.com
Click to expand...
Click to collapse
It did...I think. I'm not sure what broke it in the first place. I'm on the stock February release and 2.3.1 Mod 2.1 was working before...well, before I tried the 14 DP then went back to the February release.
phaino00 said:
Were you able to get CTS Profile restored to passing state via MHPC?
Click to expand...
Click to collapse
No. Pixel 5 on TQ1A, was passing BASIC but kept failing DEVICE. Tried changing fingerprint, no dice. Tried forcing basic attestation, didn't help. Not sure what fixed it but I'm back on the stock fingerprint now
 
  • Like
Reactions: Lughnasadh and phaino00
phaino00

phaino00

Senior Member
Oct 24, 2010
1,457
648
Lake Worth Corridor
Google Nexus 4
HTC Glacier: myTouch 4G
I started failing device after update to Feb tq1a stock image. Tried all variations of mods and nothing. I unrooted and locked bootloader a few days ago. I'll probably try the updated displax 's updated mod after unlocking bootloader today or tomorrow. Tough few days without root...lol

Update:. Unlocked the bootloader again and re-rooted stock tq1a Feb image. Installed Displax's SafetyNet mod (ver 3.0). Passing integrity checks again.

Thanks to all for the info.👍
 

Attachments

  • Screenshot_20230209-112453.png
    Screenshot_20230209-112453.png
    133.2 KB · Views: 54
  • Screenshot_20230209-112441.png
    Screenshot_20230209-112441.png
    56.5 KB · Views: 54
Last edited:
  • Like
Reactions: V0latyle
S

SchWeinSAuG

Senior Member
Sep 7, 2013
305
42
Samsung Galaxy Tab S2
OnePlus 5
phaino00 said:
I started failing device after update to Feb tq1a stock image. Tried all variations of mods and nothing. I unrooted and locked bootloader a few days ago. I'll probably try the updated displax 's updated mod after unlocking bootloader today or tomorrow. Tough few days without root...lol

Update:. Unlocked the bootloader again and re-rooted stock tq1a Feb image. Installed Displax's SafetyNet mod (ver 3.0). Passing integrity checks again.

Thanks to all for the info.👍
Click to expand...
Click to collapse
hey there

what your status in play protect certification in playstore ?
mine keeps beeing uncertified, even i pass both tests in YASNAC
you got MHPC module installed?

Also rooted Stock Tq1a. Displax Savenet mod 2.4.0 v1.2
 
V0latyle

V0latyle

Forum Moderator
Staff member
Feb 20, 2011
6,757
2
11,013
The Heartland of America
Google Pixel 5
Google Pixel 5a
SchWeinSAuG said:
hey there

what your status in play protect certification in playstore ?
mine keeps beeing uncertified, even i pass both tests in YASNAC
you got MHPC module installed?

Also rooted Stock Tq1a. Displax Savenet mod 2.4.0 v1.2
Click to expand...
Click to collapse
What device?

If Play Integrity reports MEETS_DEVICE_INTEGRITY, Play Store should report Cerified
MHPC should not be necessary on stock firmware.
 
  • Like
Reactions: SchWeinSAuG
phaino00

phaino00

Senior Member
Oct 24, 2010
1,457
648
Lake Worth Corridor
Google Nexus 4
HTC Glacier: myTouch 4G
SchWeinSAuG said:
hey there

what your status in play protect certification in playstore ?
mine keeps beeing uncertified, even i pass both tests in YASNAC
you got MHPC module installed?

Also rooted Stock Tq1a. Displax Savenet mod 2.4.0 v1.2
Click to expand...
Click to collapse
Play store is certified. I only have displax's 2.4.v1.1 installed and gpay is working too.

As @V0latyle mentioned, play store should be certified if you pass device integrity.
 
  • Like
Reactions: SchWeinSAuG
You must log in or register to reply here.

Similar threads

T
  • Locked
  • Sticky
Magisk - The Magic Mask for Android
Replies
56
Views
6M
T
topjohnwu
Didgeridoohan
  • Sticky
[MODULE] [DEPRECATED] MagiskHide Props Config - SafetyNet, prop edits, and more - v6.1.2
Replies
7K
Views
1M
xunholyx
xunholyx
Deic
[Magisk v14.0] Universal SafetyNet Fix | Universal Hide [v2 Beta 5]
Replies
2K
Views
866K
N
Noweir
Didgeridoohan
  • Locked
[GUIDE] Magisk and MagiskHide installation and troubleshooting (Magisk v20.4)
Replies
62
Views
434K
L
Lethaltooth
O
[MAGISK 16][Battery Saver][6.0+] ENABLE DOZE on Google Play Services
Replies
1K
Views
336K
knightofzealot
knightofzealot

Top Liked Posts

24 Hours 30 Days All time
  • 2
    karandpr
    karandpr
    pndwal said:
    But short of becoming a developer representative it appears there is actually no way to link to official file sources if these are TG hosted,
    Click to expand...
    Click to collapse
    Well yes. Some Telegram developers also don't want their work on XDA. So they end up mass reporting the posts and more work for mods.
    Being a developer representative is the best way imo.

    pndwal said:
    and the statement "Some Telegram links require registration for downloads, so they will not be allowed" seems to be an understatement and somewhat misleading. 🙃 PW
    Click to expand...
    Click to collapse
    If I click the link and it requires registration, its not allowed.
    regardless of the nature of links. (Telegram or otherwise)
    View
    2
    P
    pndwal
    V0latyle said:
    I'm not sure I understand your point


    There's not really any reason for confusion. What @karandpr is trying to say, and you seem to be mistaken on, is that SOME TG file links require registration. Apparently if the file is hosted in a channel and that channel is made public, ANYONE can download the file even if they don't have a Telegram account, therefore it's OK.

    However, if the file is hosted in a GROUP, which are by nature private, a TG account would be required to access the file, therefore we don't permit the link on XDA.
    Click to expand...
    Click to collapse
    I wonder if you've tried then... Magisk Alpha is one of many public channels I have bookmarked... Here's a link to test if you can get the file without a TG account...
    https://t.me/magiskalpha/574

    Guess It's ok to post it since you're sure public channel file links are ok... If it proves true I'll be quite happy about it! 😃
    V0latyle said:
    It's very simple: If you can access the file without using a Telegram account, it's OK.
    If you have to login to Telegram to access the file, it's not OK.
    Click to expand...
    Click to collapse
    Looking forward to your test!
    V0latyle said:
    Personally I'd recommend that someone not use TG to host their files simply for this sake; being a member of XDA gets you free premium benefits on AndroidFileHost so might as well use that.
    Click to expand...
    Click to collapse
    That's great, and I do appreciate it...

    Maybe we can convince vv (Nangong Xueshan) to open an account and Alpha thread w/ English only support?
    V0latyle said:
    But, since TG is popular and many use it, we are trying to compromise.
    Click to expand...
    Click to collapse
    Glad to hear it... All best with public TG files. 👍 PW
    View
    1
    P
    pndwal
    karandpr said:
    Well yes. Some Telegram developers also don't want their work on XDA. So they end up mass reporting the posts and more work for mods.
    Being a developer representative is the best way imo.
    Click to expand...
    Click to collapse
    Good points. 👍
    karandpr said:
    If I click the link and it requires registration, its not allowed.
    regardless of the nature of links. (Telegram or otherwise)
    Click to expand...
    Click to collapse
    I've understood this policy properly for some time which is why I initially expressed surprise that a TG file source link seemed to be acceptable here, but the OP and others didn't realise that all TG download links require registration so none are allowed...

    With a rule that says "Some Telegram links require registration for downloads, so they will not be allowed", the reason for the confusion is obvious to me.

    Can I suggest a simple fix?... Just state the rule plainly... "As long as Telegram file download links require registration they will not be allowed". 😬 PW
    View
    1
    V0latyle
    V0latyle
    pndwal said:
    I was responding to this:

    If that's true then XDA members wanting official TG hosted file sources are being penalised AFAICS, even if it's really about 'free and fair sharing of information'. PW
    Click to expand...
    Click to collapse
    I'm not sure I understand your point

    pndwal said:
    Good points. 👍

    I've understood this policy properly for some time which is why I initially expressed surprise that a TG file source link seemed to be acceptable here, but the OP and others didn't realise that all TG download links require registration so none are allowed...

    With a rule that says "Some Telegram links require registration for downloads, so they will not be allowed", the reason for the confusion is obvious to me.

    Can I suggest a simple fix?... Just state the rule plainly... "As long as Telegram file download links require registration they will not be allowed". 😬 PW
    Click to expand...
    Click to collapse
    There's not really any reason for confusion. What @karandpr is trying to say, and you seem to be mistaken on, is that SOME TG file links require registration. Apparently if the file is hosted in a channel and that channel is made public, ANYONE can download the file even if they don't have a Telegram account, therefore it's OK.

    However, if the file is hosted in a GROUP, which are by nature private, a TG account would be required to access the file, therefore we don't permit the link on XDA.

    It's very simple: If you can access the file without using a Telegram account, it's OK.
    If you have to login to Telegram to access the file, it's not OK.

    Personally I'd recommend that someone not use TG to host their files simply for this sake; being a member of XDA gets you free premium benefits on AndroidFileHost so might as well use that. But, since TG is popular and many use it, we are trying to compromise.

    For lack of a better thread I'm going to see if we can move the TG discussion here
    View
    1
    P
    pndwal
    @V0latyle

    Sorry, I seem to have neglected to give the link... Added now in post above. 👍 PW
    View
  • 6
    Lughnasadh
    Lughnasadh
    FYI: Migration deadline (for app developers) and full turndown deadlines for SafetyNet Attestation API have been extended.

    Migration Deadline: End of January 2024
    Full Turndown: End of January 2025

    Discontinuing the SafetyNet Attestation API | Android Developers

    developer.android.com developer.android.com
    View
    6
    karandpr
    karandpr
    V0latyle said:
    Someone had demonstrated to me at some point that TG files can be made publicly available. But I don't remember who. The only thing I can suggest is getting one of the more Telegram knowledgeable mods in here like @karandpr or @Oswald Boelcke or @alecxs
    Click to expand...
    Click to collapse
    Telegram posts with external links are available publicly.
    Telegram download links required a Telegram account.
    View
    4
    karandpr
    karandpr
    pndwal said:
    For context, this conversation:















    So it seems that despite the rule update and the fact that many here use Telegram to communicate or to peruse forums, we still cannot link even main Magisk test forks from principal Magisk Devs like @vvb2060's Alpha (with no GitHub published releases) or other apps etc published (for root hiding etc) there...

    Also, @ipdev recently made me aware of the "official XDA-Developers Telegram chat hub"... ("Here you will find links to all official XDA Telegram chat groups. The XDA-Developers Telegram chats are run by members of XDA Management with help from various trusted community members.")
    https://t.me/xdadevelopershub

    I couldn't find rules there against posting or linking files and many have been posted... So I wonder if an acceptable workaround for regular XDA members would be to post such files in the XDA TG General Discussion channel, then reply to that post with a reference to the app/mod like "The Alpha build is 13mb" and link that post (not a download source itself; only a source of 'pertinent information' 😉) from an XDA forum response to a member asking about such releases(?)... 😛

    As a for-instance, I ran early versions of Shamiko and posted on XDA about this new hiding module's development long before @nullptr gave it a public GitHub home, but I couldn't post a source for release files when members asked for it as it was only available on TG for some time...

    Now (since the extinction of MagiskHide) Shamiko is a staple module for XDA Magisk users too, but it would still be taboo here if it hadn't been for @nullptr's (and @canyie's?) initiative, because of XDA policy... 😐 🤔 PW
    Click to expand...
    Click to collapse
    Well you can also ...

    Step 1: Get permission from the devs to post on XDA.
    Step 2: Post on XDA on their behalf as a maintainer or representative or diplomatic envoy or whatever. Give ample credits to the original author.
    Step 3: For 1 project, you can link to their Telegram channel/group or whatever as per the current rules.

    If there is a download in Telegram downloads, you can ask the author permission for mirroring on XDA or in a separate telegram post.

    If you want, you can create a rollup thread with multiple Magisk dev channels, that's fine too. But make sure to write that in OP.
    Peeps on internet who don't want to trawl on telegram will get it here.
    View
    4
    V0latyle
    V0latyle
    HippoMan said:
    Ah ... so the final end of Life As We Know It (regarding rooting and modding) has been postponed for an extra year.

    This gives developers more time to turn their otherwise non-banking apps into banking-like apps which are crippled or don't run at all under root.

    We should enjoy our apps on our rooted devices now, while we still can.
    Click to expand...
    Click to collapse
    Bro...

    This changes literally nothing. Most contemporary apps have already been migrated to Play Integrity. Developers have always had the ability to use SafetyNet attestation to determine device and OS integrity. Play Integrity does the exact same thing. It is completely up to the app developers to require hardware backed attestation, via a vis MEETS_STRONG_INTEGRITY, and nothing is changing regarding that. I do not know of any apps that require that result; all of the apps that otherwise detect root are doing so via their own methods completely outside of Google Play Services.

    The SafetyNet turndown has not, does not, and will not affect our ability to use every day root or our ability to spoof basic/device integrity responses.
    View
    4
    A
    andy242
    pndwal said:
    For context, this conversation:















    So it seems that despite the rule update and the fact that many here use Telegram to communicate or to peruse forums, we still cannot link even main Magisk test forks from principal Magisk Devs like @vvb2060's Alpha (with no GitHub published releases) or other apps etc published (for root hiding etc) there...

    Also, @ipdev recently made me aware of the "official XDA-Developers Telegram chat hub"... ("Here you will find links to all official XDA Telegram chat groups. The XDA-Developers Telegram chats are run by members of XDA Management with help from various trusted community members.")
    https://t.me/xdadevelopershub

    I couldn't find rules there against posting or linking files and many have been posted... So I wonder if an acceptable workaround for regular XDA members would be to post such files in the XDA TG General Discussion channel, then reply to that post with a reference to the app/mod like "The Alpha build is 13mb" and link that post (not a download source itself; only a source of 'pertinent information' 😉) from an XDA forum response to a member asking about such releases(?)... 😛

    As a for-instance, I ran early versions of Shamiko and posted on XDA about this new hiding module's development long before @nullptr gave it a public GitHub home, but I couldn't post a source for release files when members asked for it as it was only available on TG for some time...

    Now (since the extinction of MagiskHide) Shamiko is a staple module for XDA Magisk users too, but it would still be taboo here if it hadn't been for @nullptr's (and @canyie's?) initiative, because of XDA policy... 😐 🤔 PW
    Click to expand...
    Click to collapse
    The problem xda had was a few Devs were using XDA to promote their telegram groups and not contributing to xda at all. Several of these Devs were then selling their work on telegram. All though the xda rules are far from ideal, this is what they were trying to stop
    View
  • 31
    V0latyle
    V0latyle
    Play Integrity API

    What is Play Integrity?
    Play Integrity is an API that is used by applications to determine device compatibility and security state. It has replaced SafetyNet for the most part, with a deadline of January 2025, 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.​

    How is Play Integrity different from SafetyNet?
    In many ways, it's very similar. It uses many of the same checks as SafetyNet, but the responses have been made a bit simpler. ​

    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. The Play Protect certification result does depend on your DEVICE_INTEGRITY result, but it is possible to pass Play Protect while failing Play Integrity, and vice versa, see here. ​

    Why does this matter?
    Like SafetyNet, apps use this API to determine a device's compatibility and security state. Failing verdicts may limit your ability to use those apps.​

    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. Make sure you are specifically checking your device's Play Integrity verdicts.​
    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 do so through the Play Store.​
    ​
    Tap the Profile icon in the upper right, go to Settings > About > Tap Play Store version 8 times. This unlocks developer mode in the Play Store.​
    Now go to Settings > General > Developer options > Check integrity.​
    ​
    If you prefer a clear visual indicator, you can use this app:​

    Play Integrity API Checker - Apps on Google Play

    Get info about your Device Integrity through...
    play.google.com play.google.com
    ​
    This app not only checks Play Integrity verdicts, but checks for traces of root, Magisk, and Xposed:​

    TB Checker - Safetynet & Root - Apps on Google Play

    All in one tools check android devices
    play.google.com play.google.com
    ​
    ​
    If you're a nerd and you want to see key attestation details, use this:​

    Key Attestation Demo - Apps on Google Play

    Demo for Key Attestation feature of the...
    play.google.com play.google.com
    ​
    What can I do to fix it?
    It depends on your device and software state.​
    Fixing this requires artificial measures - either you'll have to use a Magisk module, or the fixes in the module must be baked into the ROM you're using.​
    • If you are on the OEM ROM, or a custom ROM that hasn't been "fixed", you can use the USNF Displax Mod to pass BASIC and DEVICE verdicts. This "tricks" Play Integrity into thinking that the device is not capable of hardware backed attestation, which will force a fallback to basic attestation. You MUST be rooted with Magisk to use this module. Unrooting will still fail.
    • If you are on a custom ROM that has Play Integrity fixes baked in, you should already be passing. Please refer to that ROM's thread for support.
    You shouldn't need to use MagiskHide Props Config with this module, even if you're on a custom ROM.​
    Note: There is no solution that can be flashed in recovery.​
    For support with this Magisk module, see this thread.​

    Do I need to pass STRONG integrity?
    This is ultimately up to the individual app developer, but to my knowledge, none - not even Google - are requiring a STRONG verdict for any of their apps. This could change, but again, it's up to the individual app developer. While Google does provide the Play Integrity API, they do not require that your device passes, nor do they enforce anything on the behalf of third party apps - they only implement requirements for their own apps, such as GPay/Wallet.​
    ​
    If you are having problems with a specific app, chances are that app uses its own root detection methods; you may need to use additional modules such as Shamiko. You can post in this thread for help.​
    ​
    I'm passing BASIC and DEVICE but an app is still detecting root. What do I do?
    Some apps may implement their own root detection methods. Oddly enough, it seems that Google has documented a means for app developers to verify crytographic hardware keys without using Play Integrity at all,

    Other methods of root detection may include:​
    • checking for the presence of a SU binary
    • checking for the presence of a root manager app such as Magisk or SuperSu
    • checking for traces of Zygisk / Xposed / LSPosed
    • checking for permissive SELinux
    It's a game of cat and mouse with these, as the methods they use are not always clear. Please be aware that this thread is ONLY intended for support with passing Play Integrity, and questions regarding hiding root for individual apps should be referred to the this thread.​
    ​
    ​
    What causes a device to fail Play Integrity checks?​
    It depends on your Android version and device state:​

    • Locked bootloader with stock firmware running Android 7.1.2 or older will only pass BASIC and DEVICE. STRONG will never pass.
    • Locked bootloader with stock firmware running Android 8.0 or newer should pass all 3
    • Unlocked bootloader with unrooted stock firmware will fail all 3. STRONG will never pass.
    • Unlocked bootloader with Magisk rooted stock firmware will fail all 3 unless specific Magisk modules are used. STRONG will never pass.
    • Unlocked bootloader with custom firmware will fail all 3. STRONG will never pass.
    Versions of Android prior to 8.0 will only pass BASIC_INTEGRITY and DEVICE_INTEGRITY even if unmodified. Hardware backed attestation was introduced in Android 8.0; previous versions are not capable.​
    ​
    What do the verdicts mean?​
    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) << Google recently revoked ASUS ROG keys, this device won't pass STRONG even on a locked bootloader​
    ​
    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 MOD by @Displax does this:​
    (Response from Play Integrity Checker on my rooted Pixel 5 with Universal SafetyNet Fix MOD by Displax)​
    1667488774837.png
    ​
    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. ​
    ​
    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.​
    ​
    ​
    For those interested in the timeline:​
    ​
    1684775003484.png
    ​
    ​
    For the majority of us, this does not matter, unless you're using an old app that has not migrated to Play Integrity. For app developers, this means that new apps must use Play Integrity.​
    ​
    ​
    For more information, please read the discussion in this thread.​
    View
    9
    P
    pndwal
    Some Insight on the New Cat and Mouse Game...

    Since many are asking:
    vMAC said:
    Is there a fix for this? ... Can't pass MEETS_STRONG_INTEGRITY.
    Click to expand...
    Click to collapse
    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...

    👀 🤠
    View
    6
    karandpr
    karandpr
    V0latyle said:
    Someone had demonstrated to me at some point that TG files can be made publicly available. But I don't remember who. The only thing I can suggest is getting one of the more Telegram knowledgeable mods in here like @karandpr or @Oswald Boelcke or @alecxs
    Click to expand...
    Click to collapse
    Telegram posts with external links are available publicly.
    Telegram download links required a Telegram account.
    View
    6
    Lughnasadh
    Lughnasadh
    FYI: Migration deadline (for app developers) and full turndown deadlines for SafetyNet Attestation API have been extended.

    Migration Deadline: End of January 2024
    Full Turndown: End of January 2025

    Discontinuing the SafetyNet Attestation API | Android Developers

    developer.android.com developer.android.com
    View
    5
    shadowstep
    shadowstep
    mrjuniork said:
    RL does hold me tight lately.
    Click to expand...
    Click to collapse
    ...which is why I already moved a few posts @V0latyle requested. Got your back! (y)
    View

New posts