[INFO] Play Integrity API - replacement for SafetyNet

Search This thread

pndwal

Senior Member
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
Is there any way to join this private group?
 
  • Like
Reactions: chiteroman

V0latyle

Forum Moderator
Staff member
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
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
Naah, just wanna observe in silence 😂 Thanx for the hint, it's really... obfuscated 😝 And Nekogram is our friend ;)
 
  • Like
Reactions: pndwal

V0latyle

Forum Moderator
Staff member
Last edited by a moderator:

chiteroman

Senior Member
Nov 4, 2019
944
2,940
23
Oviedo
Xiaomi Mi A2 Lite
Samsung Galaxy A12
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
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: 32
  • Like
Reactions: V0latyle

HippoMan

Senior Member
May 5, 2009
3,542
2,681
Hippoland
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
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

pndwal

Senior Member
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.
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

pndwal

Senior Member
Telegram posts with external links are available publicly.
Telegram download links required a Telegram account.
For context, this:
Ok, so seems what I was told is actually still correct:
... 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...

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.
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

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

Senior Mod | DC Lead | MC
Staff member
Feb 20, 2011
13,427
32,325
Xiaomi Redmi 4a
Nokia 6.1 Plus (Nokia X6)
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
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.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 6
    how to dubug in my android phone TEE
    TEE is TRUSTED Execution Environment.
    Separate hardware with an embedded OS.
    Closed, you cannot debug


    2
    how can hacker TEE os , I want get some private key
    You can't. Any compromised private key will be revoked by Google and will therefore become useless.
    1
    how can hacker TEE os , I want get some private key
  • 81
    THIS IS NOT A SUPPORT THREAD. For questions and support regarding how to fix your Play Integrity verdicts, see the Play Integrity Fix thread.

    ⚠️BEFORE YOU ASK A QUESTION, READ THIS POST AND THE FAQ!⚠️


    ****Update 12/11/23****
    Google has been busy banning mismatched fingerprints, and as of now there is no "one size fits all" solution to spoof said prints. The best way forward is to find your own fingerprint and use it with @osm0sis's Play Integrity Fork.

    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.
    Like SafetyNet, Play Integrity allows app developers to select a tiered enforcement strategy based on their requirements for the target environment.

    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. However, the Play Protect certification result does depend on your DEVICE_INTEGRITY result. See here.
    Note: Your Play Certification may lag behind your Integrity verdicts. It is possible for Play Store to continue to report "Device is certified" even if you're failing DEVICE_INTEGRITY, and vice versa - it may still report "Not certified" even though you're passing. To fix this, wipe Play Store data.

    Why does this matter?
    Like SafetyNet, many payment, banking, and DRM apps use this API to determine a device's compatibility and security state. Failing verdicts may limit your ability to install and 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:
    Github
    This app not only checks Play Integrity verdicts, but checks for traces of root, Magisk, and Xposed:
    If you're a nerd and you want to see key attestation details, use this:
    Github
    What can I do to fix it?
    It depends on your device and software state.
    The only universal answer is this: You have to spoof a fingerprint from a device that isn't capable of hardware attestation, thereby causing Play Integrity to fall back to basic attestation. This print is ONLY spoofed to DroidGuard, the GMS root detection engine, so all other apps will still see your device's "real" print.
    There are two ways to do this: 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 a module like Play Integrity Fork, and find a fingerprint to spoof with it. It is important that you use your own, instead of a shared print. To select a random print, you can use PIFS; PixelFlasher will also do this for you.
    • If you are on a custom ROM, it is up to the ROM developer to "bake" the fix into their work. However, because this means you'll be sharing a fingerprint with everyone else who's using that ROM, there's a good chance it will get blacklisted by Google sooner.
    To find a custom fingerprint, read @simplepinoi177's guide here:
    The basics:
    • Look for devices that shipped BEFORE Android 8, but were updated to at least Android 8 during their lifetime
    • Don't go any older than Android 5.0 (API 21)
    • Don't go any newer than Android 8.1 (API 27)
    • Most of the information you need should be in build.prop; this is often in several places in the device build, I've found that /vendor/build.prop works well
    • Use Pixel Flasher to process the props and generate a custom print. See @badabing2003's guide here:
    Why doesn't the original Universal SafetyNet Fix work?
    This project is not consistently maintained and does not include the necessary fixes.
    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.
    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
    • Locked bootloader with custom firmware and custom AVB key will fail unless fixes are built into the firmware. STRONG will never pass.
    • 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.
    • 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.
    • 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. The only way your device will EVER pass STRONG is if you are on pure unmodified stock OEM firmware with a locked bootloader. Self signed firmware such as AVBroot, or signed custom firmware such as CalyxOS or GrapheneOS WILL NOT WORK.
    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.​
    12
    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...


    👀 🤠
    8
    Hey guys,
    I recently came across on this PlayIntegrityNEXT, I checked the OP and I did a bit of research but I didn't found anything about it here. Is this a reliable solution?
    I just started searching about Play Integrity for my old Galaxy S4 (running A12), since my main device pass by default using crDroid ROM (so I haven't needed it) and I don't know much about it.
    Finding fingerprint and all these sound a bit complicated, that project "playintegrinitynext" seems a bit easier, have anyone tried it yet?
    It does seem complicated at first, but things have been greatly streamlined by @badabing2003 with Pixel Flasher, @osm0sis with Play Integrity Fork, and @TheFreeman193 with PIFS.

    My issue with Play Integrity Next is that it ignores one of the major issues we've had up to this point - when specific fingerprints are in popular use, Play Integrity abuse detection seems to flag them resulting in mismatch detection that renders that print unusable for a while. I believe it is more wise for everyone to find a different print to use, because thus far, very very few who have done so have had those prints stop working.
    7

    MOD ANNOUNCEMENT

    All posts discussed here regarding Telegram links, the rules & policy of XDA concerning them, has been moved to THIS THREAD
    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.
    7
    May Google bans users who dont follow their rules. But is the requirements for RCS:

    A: SNet and Play Integrity?

    B: Full suite G-Apps installed?

    Google doesn't get the right to be like Apple, it super rich of them to so this.

    I'm crossing my fingers someone will reverse engineer the client for RCS and that the carriers will loft some slack for Apple.
    Well, I did more testing.

    Updated Messages, intentionally broke my print, killed Droidguard, checked integrity verdicts: 0/3. Unable to use RCS.

    Fixed print, killed Droidguard again, passed 2/3, RCS working again