[INFO] Play Integrity API - replacement for SafetyNet

Search This thread
By:
Advanced…
P

pndwal

Senior Member
Jun 23, 2016
7,007
8,093
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
Lord Sithek

Lord Sithek

Senior Member
Dec 19, 2018
1,460
783
Xiaomi Redmi Note 4
Huawei Watch 2
pndwal said:
Does that matter?

You don't need to join group, but 26101 is not latest Alpha... I don't think much has changed though, and it probably does have the native bridge Zygisk loading changes...

26102 Alpha is in private discussion group... I can send file in conversation if you want... PW
Click to expand...
Click to collapse
Is there any way to join this private group?
 
  • Like
Reactions: chiteroman
V0latyle

V0latyle

Forum Moderator
Staff member
Feb 20, 2011
8,225
4
13,538
The Heartland of America
Google Pixel 5
Google Pixel 5a
I'm pretty Telegram illiterate, I can't even seem to download the file.

Screenshot_20230605-085858.png


I think I'm just gonna say screw it, I can still use my main banking app and the other one is only really for ATM access so I don't care about it.
 
  • Haha
Reactions: chiteroman
Lord Sithek

Lord Sithek

Senior Member
Dec 19, 2018
1,460
783
Xiaomi Redmi Note 4
Huawei Watch 2
pndwal said:
Yup... Invite link obfuscated in Magisk alpha release channel, pinned message no. 1... Or you can just listen to Rick Astley sing "Never Gonna Give You Up"... 😜

Chinese only, and be warned you'll get chewed up and spat out if you break any rules. 😂 PW
Click to expand...
Click to collapse
Naah, just wanna observe in silence 😂 Thanx for the hint, it's really... obfuscated 😝 And Nekogram is our friend ;)
 
  • Like
Reactions: pndwal
V0latyle

V0latyle

Forum Moderator
Staff member
Feb 20, 2011
8,225
4
13,538
The Heartland of America
Google Pixel 5
Google Pixel 5a
Last edited by a moderator:
  • Like
Reactions: pndwal and Lughnasadh
chiteroman

chiteroman

Senior Member
Nov 4, 2019
527
573
22
Oviedo
Xiaomi Poco X3 Pro
V0latyle said:
Yeah. If you read the policy, we allow one TG link for developers in the OP, with the condition that support and updates must be provided in the XDA thread. There's been a few developers that try to keep everything on TG, and that's the point where we consider it to be self promotion under Rule 5:

I'm not going to quote the TG policy here since you can just click on the far right link in my sig and read it, but you get the idea

Speaking of Telegram, can someone help me figure out how to download the file? I don't have Telegram on my phone and while I have an account (that I don't frequently use) I'd rather not join the channel
Click to expand...
Click to collapse
To download the file you must have Telegram installed in your phone and had an account :(

But I can share it :D
 

Attachments

  • app-release.apk
    11.3 MB · Views: 31
  • Like
Reactions: V0latyle
HippoMan

HippoMan

Senior Member
May 5, 2009
2,348
1,107
Hippoland
pndwal said:
I think it was Oswald I discussed this with previously... 🤔

Seems you can download without Telegram "by joining a Telegram group called Files Web Downloader" or similar:
https://techlizar.com/how-to-download-telegram-files-without-telegram/
but "you’ll need to join the group and forward the downloadable link" before "they will convert the link as a fast downloadable link", but that's no good due to need to register...

Apparently a Telegram bot called GetPublicLinkBot might work per link above. "You can use it to download any large files without Telegram... This bot will generate a direct download link for any file you send it" but it didn't work in my test:
View attachment 5926479
... Doubt such third party file-mirroring solutions would be acceptable to XDA anyway, at least unless 3rd party links are used... Original TG links still require registered account to work. PW
Click to expand...
Click to collapse
So, given the policies in force in that TG group, there are obstacles to downloading the Alpha software and discussing it there.

And sadly, given XDA's own policies, there are even additional obstacles to sharing the software.

However effective the Alpha software might possibly be, it hardly seems worth the trouble of trying to obtain it and use it.
 
Last edited:
  • Like
Reactions: Stillhard
P

pndwal

Senior Member
Jun 23, 2016
7,007
8,093
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
HippoMan said:
So, given the policies in force in that TG group, there are are obstacles to downloading the Alpha software and discussing it there.

And sadly, given XDA's own policies, there are even additional obstacles to sharing the software.

However effective the Alpha software might possibly be, it hardly seems worth the trouble of trying to obtain it and use it.
Click to expand...
Click to collapse
Guess many will think that, others not...

I'm running it just to test 3/4 baked native bridge loaded Zygisk (some 3 months in the making already)
IMG_20230606_140548.jpg

Refactor zygisk to use native bridge to inject
#6659 opened on Mar 2 by yujincheng08
• Approved 2 of 3 tasks

and I have no issues that need discussing... I have got helpful responses from @canyie (a main Alpha discussion administrator) in the past however... Policies are quite normal... It is a Chinese community... Need translation solution like Nekogram or a translation bot... No different to XDAs English only policy really...

Actually I built and tried yujincheng08's (Shana on TG) Metagisk nbzygisk test branch Magisk yesterday to see if it's progressed since last Alpha. Not many will want to build themselves (and there's not much difference anyway) so Alpha builds are good option for testing.

I can say many more bank app apps run with this already than with official TJW Magisk (native bridge loading was adopted by Riru to make that hooking framework's memory hidable too and is a thus well tested concept)... Most will want simply to wait for fully baked NB loaded Zygisk expected in Magisk 27.0+ (or perhaps an earlier Canary).

If any are desperate to use their bank apps, this has a good chance of success... I have no such need but can't see any issues if people want to try... Or not... Or wait...

Installation issues (bypassing signature checks etc) are not unique and many here are used to/can give advice on testing bleeding edge Magisk... 😶 PW
 
Last edited:
  • Like
Reactions: chiteroman
P

pndwal

Senior Member
Jun 23, 2016
7,007
8,093
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
karandpr said:
Telegram posts with external links are available publicly.
Telegram download links required a Telegram account.
Click to expand...
Click to collapse
For context, this:
pndwal said:
Ok, so seems what I was told is actually still correct:
pndwal said:
... Rules were strictly no TG except one per development thread in OP originally, then was told still no links to TG threads needing registration but can link relevant information on public threads but CANNOT give TG links as file sources regardless...
Click to expand...
Click to collapse

The cited rule
What about download links?

Download links from hosts, platforms or other sources are allowed as long as they do not require registration. Some Telegram links require registration for downloads, so they will not be allowed. Please check them before posting.
Click to expand...
Click to collapse
may possibly apply to WhatsApp (can that be accessed without registering an account? 🤔) per its banner heading, but for TG the statement "Some Telegram links require registration for downloads, so they will not be allowed" seems wishful, superfluous and misleading to me as all Telegram links require registration for downloads unless I'm mistaken. 🙁 PW
Click to expand...
Click to collapse

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...
 
Last edited:
karandpr

karandpr

Senior Mod | DC Lead | MC
Staff member
Feb 20, 2011
13,034
29,989
Xiaomi Redmi 4a
Nokia 6.1 Plus (Nokia X6)
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.
 
  • Like
Reactions: Oswald Boelcke, pndwal, V0latyle and 1 other person
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
P
pndwal
Deic
[Magisk v14.0] Universal SafetyNet Fix | Universal Hide [v2 Beta 5]
Replies
2K
Views
874K
N
Noweir
Didgeridoohan
  • Locked
[GUIDE] Magisk and MagiskHide installation and troubleshooting (Magisk v20.4)
Replies
62
Views
437K
L
Lethaltooth
O
[MAGISK 16][Battery Saver][6.0+] ENABLE DOZE on Google Play Services
Replies
1K
Views
338K
knightofzealot
knightofzealot

Top Liked Posts

24 Hours 30 Days All time
  • There are no posts matching your filters.
  • 4
    A
    Arcline
    In case it's helpful, some banking apps rely on local bootloader attestations instead of Play Integrity, as it was in my case. The lsposed module "BootloaderSpoofer" fixed this problem. Took me half a year to figure this out.
    View
    3
    zgfg
    zgfg
    borisSweden said:
    How do I test Integrity if I have a "older" Play service version?
    Click to expand...
    Click to collapse
    Google Play Services, its GMS process is just a man-in-the-middle or 'messenger'

    It downloads the.apk (so called droidGuard), you will find (not just the latest but also the whole bunch of their older versions) at:
    /data/data/com.google.android.gms/app_dg_cache
    Open each subfolder there, it will contain one version of the apk

    And that the.apk (droidGuard) performs SaferyNet/PlayIntegrity attestation

    Attached is a hacker's pdf study that was already discussed and circulated here on XDA in this or similar theeads

    That's how it works since 2019 or so (already at the time of SafetyNet, prior to Play Integrity), hence if your Google Play Services supports attestation, it should already work that way

    This makes possible for Google that they don't depend on the new/old GMS. Instead they can always (without user's consent) update:
    - the.apk (droidGuard)
    - bytecode that droidGuard always calls from Google server (and that bytecode actually collects data for attestation)
    - SafetyNet/PlayIntegrity verdict logic that Google server sends at the end (telling you what you pass or not)

    That's the way how they eg two months ago closed their flaw with Strong Integrity - they didn't need at all to update ours Google Play Services - and they didn't

    They oftenly, once or twice a week update the.apk (droidGuard) and nobody could know how often and when they update the verdict logic on their server and even the bytecode that the.apk pulls on every attestation
    View
    2
    P
    pndwal
    Arcline said:
    In case it's helpful, some banking apps rely on local bootloader attestations instead of Play Integrity, as it was in my case. The lsposed module "BootloaderSpoofer" fixed this problem. Took me half a year to figure this out.
    Click to expand...
    Click to collapse
    Glad you got to the bottom of that... Baffles me why they bother to do local validation and stop short of Googles model gift-horse... It must have a nice mouth... 🤪
    View
    2
    P
    pndwal
    V0latyle said:
    I believe the Play Integrity fix is supposed to do this as well.
    Click to expand...
    Click to collapse
    Nah... Key Attestation (Verifying hardware-backed key pairs) is an independent approach... PW
    View
    2
    V0latyle
    V0latyle
    intel_core_i7 said:
    Probably a misunderstanding then. Reading your statement I felt like you are somewhat asking developers to implement strong, while being a rooted user, very weird?
    Click to expand...
    Click to collapse
    Nope, was asking the rhetorical question of "why aren't they using PI" but as you pointed out, if they did, that would affect a significant portion of their user base
    intel_core_i7 said:
    After all, we have already known that the big banking bois and Google has won the modding game with PI strong.
    Click to expand...
    Click to collapse
    Eh...dunno if it's so much a game as it is mousetraps and idiots. Someone always builds a better mousetrap, then eventually someone makes a better idiot
    View
  • 37
    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.​
    ​
    Why doesn't the original Universal SafetyNet Fix work?
    This project is not consistently maintained and does not include the necessary fixes. Please use @Displax's fork.​
    ​
    Do I need to pass STRONG integrity?
    This is ultimately up to the individual app developer. We don't know which ones may require this result, we only know which ones don't. Google, coincidentally, is not one of these - to use GPay/Wallet, you only need BASIC and DEVICE.​
    ​
    Please note that the only attestation requriements Google can enforce is for thier own apps. They cannot require any third party app to use hardware backed attestation. That's the whole point of providing the Play Integrity API - it's simply a means for developers to determine how secure your device is.​
    ​
    It's also worth noting that many if not most "security intensive" apps out there rely on third party security engines that often look for additional signs a device might be modified; see the next point below.​
    ​
    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
    • chekcing whether USB Debugging is enabled
    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 (unless fixes are baked in). 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
    10
    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
    7
    simplepinoi177
    simplepinoi177

    MOD ANNOUNCEMENT​

    All posts discussed here regarding Telegram links, the rules & policy of XDA concerning them, has been moved to THIS THREAD

    XDA & Telegram

    I'm creating this thread, but if any Senior...
    forum.xda-developers.com forum.xda-developers.com
    At the very least, this is not the thread to discuss it as this thread is about "[INFO] Play Integrity API - replacement for SafetyNet" and even if OP is okay with off-topic discussion, discussing it in a dedicated thread in "About xda.developers.com" section or even the "Feedback/Recommendations for XDA" thread would be a more appropriate and conducive location for such a discussion than here. Please direct/continue further discussions to the above URL.
    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
    Displax
    Displax
    pndwal said:
    @Displax may say more later...
    Click to expand...
    Click to collapse
    For STRONG integrity you just need:
    1. Buggy "walleye" product, device, model and fingerprint "google/walleye/walleye:8.1.0/OPM1.171019.011/4448085:user/release-keys".
    2. Set derivative "DEVICE_INITIAL_SDK_INT" to "O" (26) for GMS.
    3. Set global prop "ro.product.first_api_level" to >= 33 / or `null`. Or delete it at all.

    Check this commit: https://github.com/Displax/safetynet-fix/commit/79f6ef22db5eeb717c57a9bd00ee90b8d7cd2201
    View

New posts