[INFO] Play Integrity API - replacement for SafetyNet
- Thread starter V0latyle
- Start date
Late LSPosed generally hides itself from Play Integrity API... Try disabling all XPosed modules and keep LSPosed Magisk module enabled...
And please say if succeed / which module causes issues...
PWok I will try it nowLate LSPosed generally hides itself from Play Integrity API... Try disabling all XPosed modules and keep LSPosed Magisk module enabled...
And please say if succeed / which module causes issues...
I found it. its Xprivacylua module from Lsposed I disable it and it fix everything
Yup, that's often a culprit and also detected by banks easily due to folder it creates in /data/system...
What's more, if you install Ruru detector from here:
https://github.com/byxiaorun/Ruru
you will probably see that Xprivacylua is still detectable after uninstalling! That's because uninstall routine doesn't clean up properly...
If detected you'll need to remove data/system/xlua folder manually and check again...
PW
Is there a guide somewhere on how to use the "additional" modules such as LSposed + Shamiko?
My main bank's app somehow still detects root and disables fingerprint login. My secondary bank's app won't work at all - after blocking in DenyList, it still complains about USB Debugging being enabled.
My main bank's app somehow still detects root and disables fingerprint login. My secondary bank's app won't work at all - after blocking in DenyList, it still complains about USB Debugging being enabled.
There is HMA thread about HMA. Shamiko doesn't require special settings (just Zygisk and DenyList). You can try also App Data Isolation (Magisk module) and DevOpts Hide (for LSPosed) to hide Dev. Options
I tried 25.2 with just Displax USNF module, then 26.1 with Lsposed+Shamiko and DenyList unenforced
Didn't work for this particular app.
I wish there was a way to see exactly what methods an app was using to detect root or other modifications
Try latest Magisk Alpha, maybe apps are detecting original Magisk zygisk.
I'm not sure I want to switch to a different branch. Everything else works so I'm not exactly inclined to break everything just because one thing doesn't. Lol.
Download the apk from their Telegram, completely uninstall Magisk, and then boot to TWRP and flash the apk to install Alpha. Zero problems in my device.
So you can download it, give root permissions to Alpha and direct install it.
Random Telegram channel? The dev is one of the contributors of official Magisk, LSPosed and Shamiko. I don't think it's a random telegram channel
Give it a try
: [search in Google lol]
Last edited:
Do I have to replace Magisk core with the Alpha core? Or just use the app?So you can download it, give root permissions to Alpha and direct install it.
Random Telegram channel? The dev is one of the contributors of official Magisk, LSPosed and Shamiko. I don't think it's a random telegram channel
Give it a try
Similar threads
- Sticky
- Locked
Top Liked Posts
-
There are no posts matching your filters.
-
2
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
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 idiot2
Official Google API documentation:
Overview of the Play Integrity API | Google Play | Android Developers
developer.android.com
1
Read my post again, I'm afraid you're the one jumping to conclusions my friend. My point was, and your statement reinforces this, that an app not working on man unlocked/rooted device might not even be using Play Integrity.
Your point is a good reason as to why that might be the case. STRONG attestation is only available on 8.0+ devices, and since there's so much fragmentation in the Android market, it makes sense for a developer to seek alternatives for security attestation that are friendlier to older devices and Android versions1
And also, some of the mousetraps (not the better ones) are made by some of the better idiots.1
mmm ... If we're discussing the comment following these:
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...
, ie:
, I assumed member was saying Starling seems to be using key attestation with server side validation and extraction of extension data to detect compromised device, not asking anything... Again (assuming the comment was a continuation of the conversation), this provision for polling AVB etc, is independent of Google's device integrity APIs, whether deviceIntegrity, strongIntegrity or other verdict labels...
Actually, evidently Starling bank is not using either S/N / PI APIs or the Key Attestation method (unless changes are in last week)...
Seems it's been simply detecting these traces:
- Any Zygisk including Magisk Delta and Magisk Alpha, (Shamiko doesn't help ATM)
- Magisk's resetprop; any module using this is detected.
- su binary.
https://forum.xda-developers.com/t/banking-app-starling-detecting-magisk.4576421/post-88866509
PW -
39Play 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
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 devicesplay.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
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.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 SafetyNetctsProfileMatch. 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 SafetyNetbasicIntegrity. 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 SafetyNetHARDWARE_BACKEDevaluationType. 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: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 bootloaderFortunately, 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)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 isBASICandDEVICE. But if they really want to ensure that they're running on a trusted platform, they can requireSTRONGattestation, 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: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.10Some Insight on the New Cat and Mouse Game...
Since many are asking:
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...
7MOD 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.6FYI: 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
6
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
