Database Develop

[INFO] Play Integrity API - replacement for SafetyNet - Magisk

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 the Play Intergrity API
play.google.com
Github​​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
​​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 Android system.
play.google.com
Github​​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. 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.​​​
Spoiler: Boring Technical details:
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:​
Spoiler: Device integrity verdict mapping
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
​​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)​
​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:​​
Spoiler: Play Integrity migration 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.​

zgfg said:
But new devices have originally been released with A11 (or A12).
Hence, it's not possible to spoof A10 on those devices just by 'downgrading' the Android version
Then we come to the 'suggestions' to spoof fingerprints from a 'close device' (where A10 or earlier stock ROM was available) - but that just opens a Pandora box with who knows what kind of problems, because the same fingerprints are also used by system apps and services to drive various components:
- go to MHPC thread and find people who experimented with the same and lost fingerprint or the whole touch
- on another phone it could be camera or who knows what
- not to mention that spoofed CTS fingerprints may screw OTA and therefore brick the system
Click to expand...
Click to collapse
Yup... But this is what the @Displax mod solution is doing however, but targeting GMS... Also his USNF PR...
Also interesting:
This kills two rabbits:
• fix old SN CTS profile check on some weird Custom ROMs
• bypass Integrity (MEETS_DEVICE_INTEGRITY) for now.
Click to expand...
Click to collapse
https://github.com/kdrag0n/safetynet-fix/pull/207#issue-1317290126
@kdragon is taking interest... He's concerned about fingerprint mismatch issues too:
Have you noticed any features acting up with the old fingerprint?
Ideally, I think this should be scoped to Play Integrity code by identifying methods it calls near the beginning and end of integrity checks, and adding hooks to set and restore the fingerprint. I feel like setting a fingerprint that doesn't match the system in so many ways is bound to cause an issue somewhere.
Click to expand...
Click to collapse
So @Displax says it's "for now" / and is "just quick example (and core resolve) with temp fix for impatient people))... But need more testing with various devices." He agreed:
We need separate target hook for this (if feasible) - will be more polite solution...
Target process (one of?) "com.android.vending/com.google.android.finsky.integrityservice.IntegrityService"
Click to expand...
Click to collapse
https://github.com/kdrag0n/safetynet-fix/pull/207#issuecomment-1195951660
PW

pndwal said:
Yup... But this is what the @Displax mod solution is doing however, but targeting GMS...
Click to expand...
Click to collapse
Yeah, that's the point - he uses Zygisk to limit CTS prints only to GMS - therefore if you use getprop you won't see the CTS prints being changed (like if you would use MHCP for changing the prints)
See that USNF is Zygisk type module, MHCP is not - hence MHCP cannot filter the props changes only to particular app/process
Therefore, other apps (like camera, Samsung store, etc) are not troubled - they still see the proper props values

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

pndwal said:
Since many are asking:
I've posted some information about Play Integrity MEETS_STRONG_INTEGRITY being akin to SafetyNet Evaluation type HARDWARE with CTS Profile match, but since it became a WOT, I put it here:
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87274009
PW
Click to expand...
Click to collapse
I've been meaning to ask....Since Google is replacing SafetyNet with Play Integrity, is it safe to assume that there will come a day when app developers (particularly Google) remove SafetyNet support from their apps, at which point those of us with root will be unable to force "legacy" attestation as with the modified USNF? Of course this will mean that all versions of Android prior to the implementation of HA/TEE will be excluded as well, but it's not uncommon for developers to stop supporting older platforms.

pndwal said:
Some 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...
Click to expand...
Click to collapse
Would you consider possibly boiling this down to a fairly simpler explanation that we can sticky? It's likely this will be the topic of quite repetitive questions going forward.
I tried to explain it somewhat simply here, please let me know how far I missed the mark

V0latyle said:
I've been meaning to ask....Since Google is replacing SafetyNet with Play Integrity, is it safe to assume that there will come a day when app developers (particularly Google) remove SafetyNet support from their apps,
Click to expand...
Click to collapse
I put info about this originally here:
https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87188299
Google is urging Devs to do just that; S/N API was already depreciated in June with 'full turndown' slated for June 2024... banks are urged to move to PI asap, and at least before the June 2023 migration deadline. If they do, their older versions will continue to function with S/N API till June 2024. If they don't, these will cease to gat needed attestations from June 2023.
V0latyle said:
at which point those of us with root will be unable to force "legacy" attestation as with the modified USNF?
Click to expand...
Click to collapse
No, the new API includes all of the same device state checks and app processees use either one or the other, (although GPay seemed to use one for the app info and the other for card setup... but I'm betting it's only due to progressive changes...) so S/N turnoff won't matter...
You'll notice that if CTS Profile match fails for example, Device Integrity will fail also... The new API is a little stricter, especially for A11+ devices but @Displax's new USNF covers new enforcement bypass needed for these devices... The old bypasses are also still needed... And an official Pull Request is pending. (My Android 10 device doesn't need any change from official USNF)
V0latyle said:
Of course this will mean that all versions of Android prior to the implementation of HA/TEE will be excluded as well, but it's not uncommon for developers to stop supporting older platforms.
Click to expand...
Click to collapse
This is the point of what I just posted; if Google swings the enforce HKA if supported for MEETS_DEVICE_INTEGRITY hammer first, banks likely won't move to MEETS_STRONG_INTEGRITY sparing pre A8 stock devices... If they don't, eventually banks will implement MEETS_STRONG_INTEGRITY which will exclude customers using pre A8 devices... Either way it's game over for modders at that point... At least that's what my deduction says!
See official dates, info, links from here:
https://developer.android.com/training/safetynet/deprecation-timeline
PW

V0latyle said:
I've been meaning to ask....Since Google is replacing SafetyNet with Play Integrity, is it safe to assume that there will come a day when app developers (particularly Google) remove SafetyNet support from their apps, at which point those of us with root will be unable to force "legacy" attestation as with the modified USNF? Of course this will mean that all versions of Android prior to the implementation of HA/TEE will be excluded as well, but it's not uncommon for developers to stop supporting older platforms.
Click to expand...
Click to collapse
That's something we can only speculate about.
Frankly, Google did not need Play Integrity - they could have simply forced CTS Profile checking through TEE (same thing as STRONG now) - but they didn't (yet)
Per specification, Google is not the final Judge. It only provides info how your device passes the Play Integrity API levels
If you are developer of a banking app, it is up to you would you allow DEVICE integrity, or would you require STRONG. Not even your banking app but better the banking server should make the final judgement (upon being passed the PI API test results)
Again, frankly, bankers could have already been checking do you pass CTS Profile with HARDWARE_BACKED or only BASIC, and allow only the first ones (they can also read that info with the old SafetyNet)
Btw, bankers (developers) can employ a more complex logic. Based on your phone model to require STRONG (new phones) or allow DEVICE (for older phones) - but it requires more work on their side

Wow.. another thread ... Perhaps we could condense this in @Didgeridoohan's GPay thread?
Anyway, since you asked me to critique:
V0latyle said:
The reason for this is that Google is sunsetting the SafetyNet and Play Protect certifications
Click to expand...
Click to collapse
I hadn't heard about Play Protect depreciation (it's still there currently, and Play Store is already using Play Integrity API!), but SafetyNet is already deprecated...
V0latyle said:
in favor of the new Play Integrity API, which uses 3 fields:
MEETS_DEVICE_INTEGRITY
The app is running on an Android device powered by Google Play services. The device passes system integrity checks and meets Android compatibility requirements. This is replacing SafetyNet's ctsProfile. This is what USNF fixes.
MEETS_BASIC_INTEGRITY
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. This is replacing SafetyNet's basicIntegrity, and means that Play Services has not detected root.
MEETS_STRONG_INTEGRITY
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.
This is replacing SafetyNet's Hardware Attestation, and uses the Android system's Trusted Execution Environment to guarantee process security. This will not pass with an unlocked bootloader, and cannot be spoofed as it specifically relies on hardware security; unlocking the bootloader "breaks" TEE.
The workaround for this is the modded USNF module by @Displax which forces the system to use the old SafetyNet API instead of Play Integrity.
Click to expand...
Click to collapse
Um, no...
It simply allows PI MEETS_DEVICE_INTEGRITY verdict in Android 11+ (generally), by creating a fingerprint prop SDK-level (and possibly other) mismatch that triggers bypassing of Hardware keystore attestation enforcement... The original USNF fallback trigger (fake keystone registration) and enforcement bypass (altered Model prop) are also needed for MEETS_DEVICE_INTEGRITY verdict, and these alone are enough for many devices (pre-Android 11 generally).
V0latyle said:
I imagine at some point in the future when SafetyNet is completely retired, app developers (especially large ones like Google) will eventually remove support for SafetyNet in their apps, which will mean that anyone whose device does not pass Play Integrity will not be able to use the app. This will include everyone running versions of Android older than 8.0, when TEE was implemented.
Click to expand...
Click to collapse
Hardware keystore and hardware TEE have been around at least since Android 6, but keymaster could not reliably verify the key pairs were in hardware... This was strengthened in Android 7 Keymaster 2 attesting to hardware backed keys, but only Android 8's Keymaster 3, with ID attestation allowing the device to provide proof of hardware identifiers, such as serial number or IMEI, was considered an attestation strong enough for HKA in android..
The other points are treated in my post above. PW

V0latyle said:
Would you consider possibly boiling this down to a fairly simpler explanation that we can sticky? It's likely this will be the topic of quite repetitive questions going forward.
I tried to explain it somewhat simply here, please let me know how far I missed the mark
Click to expand...
Click to collapse
You may also see this answer (we are all talking the same things, maybe with slightly different words):
https://forum.xda-developers.com/t/...agisk-discussion-thread.3906703/post-87274309

I admit it's a little hard to wrap my brain around this.
My understanding of the Play Integrity API was originally that in order to meet Play Integrity as a whole, devices would have to meet the BASIC, DEVICE, and STRONG integrity. I didn't know the apps looked at those qualities directly - I thought Play Integrity checked these, and if any of them was false, Play Integrity would report that integrity is compromised.
I promise I'm not being obtuse...
So the way it REALLY works is that the API is a method by which the apps can check these properties; it doesn't rely on a Google specific process (because AOSP)
Which means I still don't quite understand...how does the modded USNF allow apps such as GPay and Wallet to ignore the MEETS_STRONG_INTEGRITY?
It's clear to me that almost any device should return MEETS_BASIC_INTEGRITY, and that we have to use workarounds such as USNF to be able to return MEETS_DEVICE_INTEGRITY, and that we will never be able to return MEETS_STRONG_INTEGRITY because of HKA vs unlocked bootloaders.

V0latyle said:
I admit it's a little hard to wrap my brain around this.
My understanding of the Play Integrity API was originally that in order to meet Play Integrity as a whole, devices would have to meet the BASIC, DEVICE, and STRONG integrity. I didn't know the apps looked at those qualities directly - I thought Play Integrity checked these, and if any of them was false, Play Integrity would report that integrity is compromised.
I promise I'm not being obtuse...
So the way it REALLY works is that the API is a method by which the apps can check these properties; it doesn't rely on a Google specific process (because AOSP)
Which means I still don't quite understand...how does the modded USNF allow apps such as GPay and Wallet to ignore the MEETS_STRONG_INTEGRITY?
It's clear to me that almost any device should return MEETS_BASIC_INTEGRITY, and that we have to use workarounds such as USNF to be able to return MEETS_DEVICE_INTEGRITY, and that we will never be able to return MEETS_STRONG_INTEGRITY because of HKA vs unlocked bootloaders.
Click to expand...
Click to collapse
Here (again) link to Google's doc:
Overview of the Play Integrity API | Google Play | Android Developers
developer.android.com
Pay attention to verdict - but better spend 15 minutes to read the whole
And in YASNAC, you can also read the JSON with eg details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)

zgfg said:
Frankly, Google did not need Play Integrity - they could have simply forced CTS Profile checking through TEE (same thing as STRONG now) - but they didn't (yet)...
Click to expand...
Click to collapse
FWIW, the real reason for the change was to provide an inclusive Integrity solution that
helps protect your apps and games from potentially risky and fraudulent interactions, allowing you to respond with appropriate actions to reduce attacks and abuse such as fraud, cheating, and unauthorized access.
Click to expand...
Click to collapse
by combining existing SafetyNet attestation in Device Integrity fields with the new Application integrity and Account details fields in a single API.
PW

V0latyle said:
I admit it's a little hard to wrap my brain around this.
My understanding of the Play Integrity API was originally that in order to meet Play Integrity as a whole, devices would have to meet the BASIC, DEVICE, and STRONG integrity. I didn't know the apps looked at those qualities directly - I thought Play Integrity checked these, and if any of them was false, Play Integrity would report that integrity is compromised.
I promise I'm not being obtuse...
So the way it REALLY works is that the API is a method by which the apps can check these properties; it doesn't rely on a Google specific process (because AOSP)
Which means I still don't quite understand...how does the modded USNF allow apps such as GPay and Wallet to ignore the MEETS_STRONG_INTEGRITY?
It's clear to me that almost any device should return MEETS_BASIC_INTEGRITY, and that we have to use workarounds such as USNF to be able to return MEETS_DEVICE_INTEGRITY, and that we will never be able to return MEETS_STRONG_INTEGRITY because of HKA vs unlocked bootloaders.
Click to expand...
Click to collapse
Apps can use MEETS_DEVICE_INTEGRITY by default, using any distribution channel. Registration with Google Play allows use of MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY in addition...
Flow chart:
PW

zgfg said:
Here (again) link to Google's doc:
Overview of the Play Integrity API | Google Play | Android Developers
developer.android.com
Pay attention to verdict - but better spend 15 minutes to read the whole
And in YASNAC, you can also read the JSON with eg details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)
Click to expand...
Click to collapse
I have read this and keep going back but I'm no developer and my general understanding of Android is less than elementary
pndwal said:
Apps can use MEETS_DEVICE_INTEGRITY by default, using any distribution channel. Registration with Google Play allows use of MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY in addition...
Click to expand...
Click to collapse
This is where it's still confusing to me. Because according to that statement, it sounds like developers can choose what guarantee of security they want...but
pndwal said:
Flow chart:
PW
Click to expand...
Click to collapse
This makes it sound like Play Integrity is not so much a framework as it is a service, meaning at some point app developers will have no choice?
Or am I right on both accounts, but app developers can either call the Play Integrity API, or they can call the device security fields alone?

@ipdev @pndwal @zgfg @TraderJack I know it's a lot of work, but could you please move your posts on Play Integrity into this thread as described above? The idea is to have one thread to discuss this topic, as well as a place to point other users to should they have questions. If someone would like to volunteer their post, I can copy/paste into the OP so we have an up front explanation of what Play Integrity is, how it works, and what it means for rooted/modded users.

V0latyle said:
@ipdev @pndwal @zgfg @TraderJack I know it's a lot of work, but could you please move your posts on Play Integrity into this thread as described above? The idea is to have one thread to discuss this topic, as well as a place to point other users to should they have questions. If someone would like to volunteer their post, I can copy/paste into the OP so we have an up front explanation of what Play Integrity is, how it works, and what it means for rooted/modded users.
Click to expand...
Click to collapse
Is it possible to move the posts without copy-pasting them?
I mean it is if I mark it is Report and ask you to move - but then it's more work for you. Hence some other way?

zgfg said:
Is it possible to move the posts without copy-pasting them?
I mean it is if I mark it is Report and ask you to move - but then it's more work for you. Hence some other way?
Click to expand...
Click to collapse
No, only moderators can move posts (and we have forum specific moderators so it wouldn't be me lol)
Else, you can copy/paste and request the old post be deleted

V0latyle said:
I have read this and keep going back but I'm no developer and my general understanding of Android is less than elementary
Click to expand...
Click to collapse
X2
V0latyle said:
This is where it's still confusing to me. Because according to that statement, it sounds like developers can choose what guarantee of security they want...
Click to expand...
Click to collapse
Well Hardware evaluationTypes are used if available by default even if just calling Device_Integrity. That's why @kdragon uses both fake keystone (causes exception which triggers fall back to basic attestation) and altered Model prop (mismatch causes enforcement of a Hardware based verdict to be bypassed, ie. the forced basic attestation becomes acceptable)...
The statement "JSON ... details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)" may be misleading; really, MEETS_STRONG_INTEGRITY only indicates a passing STRONG_INTEGRITY verdict using hardware TEE; of course, unlocked devices will fail to return MEETS_STRONG_INTEGRITY and there will be no indication whether hardware TEE was used or not in PI, unlike old S/N attestation... Conversely, CTS Profile will be checked in TEE (ie. we see S/N HARDWARE evaluationType) to attest to DEVICE_INTEGRITY if it's available by default (ie. on A8+ devices), but if it fails there is no indication from PI API that hardware TEE was used, and no indication if hardware was used if it succeeds either unless STRONG_INTEGRITY succeeds also...
Don't confuse evaluationType with the choice of verdict type; Devs can choose any of three levels for verdict but cannot choose evaluationType used; Hardware will be used if it's available for that type unless userspace tricks are used to spoof device and cause fallbacks...
V0latyle said:
but
This makes it sound like Play Integrity is not so much a framework as it is a service, meaning at some point app developers will have no choice?
Click to expand...
Click to collapse
It's an API, (Application Programming Interface) requiring server-end support by Google; I gave you the dates / link a couple of times now for 'Migration deadline' & 'Full turndown' of S/N API at which point there will be no choice but to use PI API...
V0latyle said:
Or am I right on both accounts, but app developers can either call the Play Integrity API, or they can call the device security fields alone?
Click to expand...
Click to collapse
Sorry, are you referring to Play Integrity response labels?... These are all part of Play Integrity, of course!?
Main signals (responses) are defined as:
- Application integrity
- Account details
- Device integrity
For Device integrity, device_recognition_verdict is called.
By default, this can have one of the following labels:
MEETS_DEVICE_INTEGRITY
or
No labels (a blank value)
If you opt in to receive additional labels in Device integrity, device_recognition_verdict can have the following additional labels:
MEETS_BASIC_INTEGRITY
or
MEETS_STRONG_INTEGRITY
and for emulators only
MEETS_VIRTUAL_INTEGRITY
These 'fields' are all called via the Device Integrity API.
https://developer.android.com/google/play/integrity/verdict
PW
PS. Just did this on 140 min flight from Broken Hill to Sydney... Just landed...

I am not sure about the Google Pay Magisk Discussion Thread but, posts (including mine) related to Play Integrity in the Universal SafetyNet Fix 2.3.1 thread seem to start around Post # 1,796.
All the posts about Play Integrity (that are not related to the USNF module) would have to be moved and kept in order to this thread.
I am not sure how easy that would be to do, since a lot of the discussion included linked posts in the responses.
Maybe @mrjuniork has an idea of the best and easiest way to do it?
Cheers.
PS.
Sorry to ping you mrjuniork.
I might be wrong but, it looks like you will be the one who gets stuck moving the posts.

Related

From this day onwards, apps that Change state of SELinux are forbidden on Google Play Store. Those, who have such apps, have 14 days to fix violations or their apps will be removed.
Here's example of message from google:
This is a notification that your application, SELinux Mode Changer, with package ID com.mrbimc.selinux, is currently in violation of our developer terms.
…
REASON FOR WARNING: Violation of the dangerous products provision of the Content Policy:
“Don’t transmit or link to… items that may introduce security vulnerabilities to or harm user devices, apps, or personal data.”
After a regular review, we have determined that your app lowers a user’s device security by modifying or disabling SELinux on the device. To ensure a safe user experience for Play users, we have determined that apps with this functionality are noncompliant.
Please remove this functionality from your app within 14 days to achieve policy compliance. Once approved, your application will again be available with all installs, ratings and reviews intact.
This notification also serves as notice for other apps in your catalog. You can avoid further administrative action by immediately ensuring that no other apps in your catalog are in violation of (but not limited to) the above policy. Please also ensure your apps’ compliance with the Developer Distribution Agreement and Content Policy.
All violations are tracked. Additional suspensions of any nature may result in the termination of your developer account, and investigation and possible termination of related Google accounts. If your account is terminated, payments will cease and Google may recover the proceeds of any past sales and/or the cost of any associated fees (such as chargebacks and transaction fees) from you.
If you feel we have made this determination in error -or feel that this functionality has been misinterpreted, please submit an appeal to the Google Play policy team through this Google Play Help Center article.
The Google Play Team
New definition of "dangerous product
Google play content policy
Google play distribution agreement
What are we going to do?

I can confirm this issue as I also received this message by Google-Play some hours ago.
My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.
As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").
What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?

funtax said:
I can confirm this issue as I also received this message by Google-Play some hours ago.
My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.
As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").
What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?
Click to expand...
Click to collapse
Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.

jerryfan2000 said:
Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.
Click to expand...
Click to collapse
Might I ask you which apps and features are affected?

PhinxApps said:
Might I ask you which apps and features are affected?
Click to expand...
Click to collapse
Button Savior (root). Assistive Zoom, oneClick Scroll. In my app, I create a jar with private API invocation in it and start the jar as a shell command by exec or something that I dont quit remember.

I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?

arpruss said:
I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?
Click to expand...
Click to collapse
Hmm, the e-mail is just a warning.. I think the apps will be removed in 13 days.
The title shouldn't matter, I assume it's just a scanner/grep which they run against eg. the classes.dex and search for "setenforce".
My app doesn't use this command normally, nor is it an app which is used by the 0815-user - it cannot be a human who decides about good/bad
But does this help us in any way?

This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.
https://mega.co.nz/#!jhgA3Spb!oOS9ru9q5dDfS5V9iHLFXUTiuZVTSbNk1iyrLrq-lus

tmjm28 said:
This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.
https://mega.co.nz/#!jhgA3Spb!oOS9ru9q5dDfS5V9iHLFXUTiuZVTSbNk1iyrLrq-lus
Click to expand...
Click to collapse
Thanks for sharing!
I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.

funtax said:
Thanks for sharing!
I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.
Click to expand...
Click to collapse
... which isn't possible on bootloader locked (exploit freed) devices

Has anyone an idea how to exactly interprete this message from Google?
I assume they parse the APK for "setenforce" and blame all apps which use it.
I fully understand and confirm Google's decision, no matter that it's realy a pain in the a** for some of us.
So, what are your thoughts about the following:
1. use a crypted version of "setenforce 0" which hopefully bypasses Google's scanners
2. do the modifications you need to do and hope this modifications are still working after enforced-mode is active again (how would a "execmod"-exception perform if the text-relocations have been made while SELinux was off?)
3. now call setenforce again but with "1", to re-renable SELinux
In other words:
1. would SELinux recognize that a text-relocation was made while it was disabled and then activated?
2. would it be ok to temporary disable SELinux but then re-enable it shortly after the required modifications?
@Chainfire: maybe #1 is something you might know due to SuperSU?

Removed setenforce 0 and surprisingly my app is still working. Guess newer superSU can bypass selinux restriction to some level.

jerryfan2000 said:
Removed setenforce 0 and surprisingly my app is still working. Guess newer superSU can bypass selinux restriction to some level.
Click to expand...
Click to collapse
Yes, that's correct. SuperSU sets itself to "permissive" in most times afaik - so if you run your restricted commands via SuperSU, you might not get problems with SELinux.
But if another process/pid is running into issues with SELinux, that won't help you.

To anyone still having to modify the SELinux state I would advice you guys to use the Audit messages.
You might not even need to change SELinux to permissive. It's even mentioned in Chainfire's SU documentation in detail.

Catalyst06 said:
To anyone still having to modify the SELinux state I would advice you guys to use the Audit messages.
You might not even need to change SELinux to permissive. It's even mentioned in Chainfire's SU documentation in detail.
Click to expand...
Click to collapse
This might indeed help some of the devs to adjust their commands to work with SELinux enforced - good hint, pretty sure many users are not familar with that
Ohh.. I must adjust myself: I wasn't aware of the SELinux-patcher. Might be an acceptable workaround?

funtax said:
1. use a crypted version of "setenforce 0" which hopefully bypasses Google's scanners
Click to expand...
Click to collapse
If Google catches this, they may be more tough on you.
I got notices for 3 variants of my Spirit FM apps. Was just a debug/test menu item.
Not needed for my Spirit2 app, but the Spirit1 app did direct access to audio and other devices and won't work on Lollipop otherwise. Not a big deal for Spirit1 really though, because I will likely never release a non-beta compatible with Lollipop.
So I removed the code.
Now I have a tricky issue because I was trying to slowly roll out a new version to KitKat users. So now, 80% of my Lollipop users may still have the "bad" app and I can only fix that by increasing the KK rollout to 100%.
Wonder if Google will kick me at the 14 day mark if I don't go to 100%.

mikereidis said:
Now I have a tricky issue because I was trying to slowly roll out a new version to KitKat users. So now, 80% of my Lollipop users may still have the "bad" app and I can only fix that by increasing the KK rollout to 100%.
Wonder if Google will kick me at the 14 day mark if I don't go to 100%.
Click to expand...
Click to collapse
Any news since? It seems Google pulled the trigger...

Sine. said:
Any news since? It seems Google pulled the trigger...
Click to expand...
Click to collapse
I went to 100% with my rollout just to be on the safe side.
I have had no followup problems. My affected apps are still selling.
Would have been nice for Google to send a "Thank you for co-operating" email.
I am sorry to hear that the SCR Pro developer has had his developer account terminated.
Termination is an EXTREME measure seemingly intended for confirmed malware spreaders.
I think it is VERY rare (if not impossible) to get a terminated account re-instated. I don't recall ever hearing of a re-instatement.
All of us small developers dependent on Google Play for our income are just a few Google mouse clicks away from having our indie careers ended and Google just does not care.

Why are they doing this?
I'm not sure if this is a good decision from Google. I fully understand that this could help to protect users, but in my opinion, a warning on the device would have been enough.
Android should be an open System. A user installing a permissive kernel, or changing a existing one to permissive mode, could be expected to know what she or he is doing.
I have to recompile the kernel for my SM-P605 because it was the only way to get it to work in permissive mode. Without the ability to do the mode switching by app, I have
to do this ugly changes by hand or make them persistent. Without this I'm even not able to do a chroot and run another Linux-distro on such a device. Forcing developers
to bypass such restirctions is the bigger security issue. If I'm not able to do such things, I could just as well buy a device made by apple.
What would a normal Linux user say, if he isn't allowed to get root access or couldn't download programs which don't work on a Kernels not enforcing SELinux.

mame82 said:
I'm not sure if this is a good decision from Google.
Click to expand...
Click to collapse
Google doesn't care.
Android is now dominant, and Google is closing it off, going closed source on the increasingly important Gapps/GMS etc.
Android Auto, TV, Wear, Play, etc. etc: closed source.
DRM will come and Google doesn't want us bypassing it. We already have it in locked bootloaders for non-Nexus.
This likely makes business sense for Google. They are the new Microsoft, not quite as evil perhaps, but getting closer all the time.

So I finally bit the bullet to install LineageOS 14.1 on my phone, using Magisk and all that but I have looked quite a bit before posting this, and even in that giant thread for the SafetyNet Fix which appears to be abandoned. Surprised no one forked it to continue.. Anyway...
From my research thus far, I'm seeing some moderate success from modifying the build.prop values to an official source perhaps. If I'd known this, I would of probably attempted to get it from the official ROM before I flashed LineageOS on to try and bypass that check. But so far, a few things I have done just simply won't work which is forcing Google Pay to fail working as well.
My experience with modifying the build.prop is pretty much nill. I'm a novice Linux user, but there are certain things I tend to never touch, even on Android. I've not seen anything that was comprehensive as to what specifically edit, and what to change the values to. (this is largely because its device specific usually) Luckily, both the banking apps I use work fine, its just Google Pay I'm having issues with because of the CTS Profile. Basic Integrity passes, so I at least know Magisk is working to some degree.

In a pinch you can use whatever device fingerprint you can get a hold of.
You've done some research, so you might already have seen this:
https://forum.xda-developers.com/showpost.php?p=75489540&postcount=1636
Follow those instructions and you should be good to go. You can use the provided fingerprint in that post, but like you say, it's good to use one for your device (what is your device, by the way). Ask in your device's forum if someone can provide you with a stock fingerprint.

Technically speaking, I already stated my phone which happens to be in the thread title. But I'll ask over there and hope for the best.
Though yes, I did run into that particular post. No guarantee it'll work, but guess I could try it once I get the line I need.

TwinShadow said:
Technically speaking, I already stated my phone which happens to be in the thread title. But I'll ask over there and hope for the best.
Though yes, I did run into that particular post. No guarantee it'll work, but guess I could try it once I get the line I need.
Click to expand...
Click to collapse
Oh yeah... I missed the title, didn't I? :laugh:
If you can pass basic integrity but not the cts profile, most of the times it simply is a matter of using a certified fingerprint. On every single ROM with uncertified fingerprints I've tested, this has been the case. But of course, YMMV...

Kernel Z5c support to safetynet
https://androidfilehost.com/?fid=889764386195916464

For those of us with unlocked or rooted devices, I have some bad news to report. Some very, very bad news!!!
John Wu, @topjohnwu, the creator of Magisk, just confirmed that the current SafetyNet CTS Profile error issue is probably permanent, and that it's unlikely to be fixed anytime soon because Google has significantly strengthened SafetyNet. He's confirmed that Google is now utilizing hardware-backed cryptography, specifically hardware-level key attestation, leveraging the device CPU's Trusted Execution Environment (TEE) for additional security.
John Wu's Twitter Post on SafetyNet Failure Issue
If you know a little about cryptography, you will appreciate that, if properly implemented, hardware-backed cryptography is almost IMPOSSIBLE to break. This means that all of our previous SafetyNet fixes will now be obsolete since Google will now be rigorously checking the validity of the source of our cryptographic keys.
What is Android Keystore Key Attestation
Google is now verifying that the cryptographic keys it relies on to validate our devices are kept in a secure, hardware-backed keystore on each device, making key extraction near-impossible, and nullifying all our previous validation hacks. This will, for example, prevent spoofing of device certification (CTS Profile) as we currently do with our custom ROMs, and our devices will now appear in the Play Store app as "not certified."
What this means is that the unrestricted freedom we once enjoyed with our custom ROMs has now come to an end. It's easy for us hobbyists to feel victimized by Google, but we're not the target since we're a very small minority of the more than 2 billion Android users worldwide. The aim, instead, is to protect the security of the Android platform by restricting the activities of hackers and criminals who use rooted or otherwise-compromised Android devices to perpetrate their criminal activities.
Unfortunately, it's no longer business as usual. I don't know how this will end, but I don't see it ending well for us in the custom ROM community. To repeat John's final words of his twitter post, "Let's face it. Fun is over guys."

No more bank apps, no more Netflix on rooted. What a sad really don't want say good bye to rooted nor those apps

Thanhbat said:
No more bank apps, no more Netflix on rooted. What a sad really don't want say good bye to rooted nor those apps
Click to expand...
Click to collapse
Hi Thanhbat. I feel sad too. This is not a good situation. Presently, all we can do is wait and see what happens, and hope for the best. People are actively trying to find a solution, but right now it doesn't look good.

Hi to all i've Magisk installed on my device and i have not this problem. This appear randomly on some device or this is someting that will happend in the near future?
I Use a Redminote 7 Global, with last global firmware and pixelexperience.

Dust3k said:
Hi to all i've Magisk installed on my device and i have not this problem. This appear randomly on some device or this is someting that will happend in the near future?
I Use a Redminote 7 Global, with last global firmware and pixelexperience.
Click to expand...
Click to collapse
Wait until March security patch come

SafetyNet FIX https://forum.xda-developers.com/apps/magisk/safetynet-fix-google-update-march-2020-t4063679

Hello together,
I have described everything here .... Chrome, GPay, McDonalds, Pokemon are working for me - at the moment
https://xiaomi.eu/community/threads/...droid-q.52556/
https://xiaomi.eu/community/threads/...y-false.53400/
Regards Kater

PixelPro said:
For those of us with unlocked or rooted devices, I have some bad news to report. Some very, very bad news!!!
John Wu, @topjohnwu, the creator of Magisk, just confirmed that the current SafetyNet CTS Profile error issue is probably permanent, and that it's unlikely to be fixed anytime soon because Google has significantly strengthened SafetyNet. He's confirmed that Google is now utilizing hardware-backed cryptography, specifically hardware-level key attestation, leveraging the device CPU's Trusted Execution Environment (TEE) for additional security.
John Wu's Twitter Post on SafetyNet Failure Issue
If you know a little about cryptography, you will appreciate that, if properly implemented, hardware-backed cryptography is almost IMPOSSIBLE to break. This means that all of our previous SafetyNet fixes will now be obsolete since Google will now be rigorously checking the validity of the source of our cryptographic keys.
What is Android Keystore Key Attestation
Google is now verifying that the cryptographic keys it relies on to validate our devices are kept in a secure, hardware-backed keystore on each device, making key extraction near-impossible, and nullifying all our previous validation hacks. This will, for example, prevent spoofing of device certification (CTS Profile) as we currently do with our custom ROMs, and our devices will now appear in the Play Store app as "not certified."
What this means is that the unrestricted freedom we once enjoyed with our custom ROMs has now come to an end. It's easy for us hobbyists to feel victimized by Google, but we're not the target since we're a very small minority of the more than 2 billion Android users worldwide. The aim, instead, is to protect the security of the Android platform by restricting the activities of hackers and criminals who use rooted or otherwise-compromised Android devices to perpetrate their criminal activities.
Unfortunately, it's no longer business as usual. I don't know how this will end, but I don't see it ending well for us in the custom ROM community. To repeat John's final words of his twitter post, "Let's face it. Fun is over guys."
Click to expand...
Click to collapse
https://youtu.be/LiQor-mXNq8

Hello!
Is the magisk safe to use, or will i get banned in netflix/google account etc?
Thank you for any answer regarding my issue

That depends on what you mean by safe.
You are unlocking your bootloader and modding your device when installing Magisk, so you are in some ways making your device less safe against certain kinds of things (like if someone gets physical access to your device, etc).
Many apps look for modifications and a rooted device and won't work if they detect it. That's where MagiskHide comes in and can hide Magisk from most detection methods. Google is stepping things up though and they have briefly showed us that they are on the way to implement proper key attestation in the SafetyNet CTS profile check. That is not something that Magisk will be able to hide from and as soon as that is implemented properly there is nothing we will be able to do.
So far you shouldn't be worried about getting banned (most of the time), but some services will not work if they can detect root. Netflix is one of them, Google Pay, banking apps, some games, etc. Some services might ban you (maybe Snapchat), but as far as I've seen those are in the minority.
Another aspect of being safe is that you should be careful with what apps you allow to have superuser access. With su, an app/service can wreck all kinds of havoc...
There's a lot to be said on this subject and I'm sure others will join in. If you search around a bit you can find lots of info on pros and cons of having an unlocked booloader, rooting, modding your device, etc.

Overall I'd say yes, the Magisk is safe. The Magisk and the modules that are available, much like the hammer and sickle, has the ability to be abused by the users when used for other purposes outside of its scope.
It's not malware either, if that's what you meant.

it is safe if you are know what you doing

MagiskHide is dropped in v24. According to the developer's blog, there will remain a feature that “will be able to assign a denylist of processes where Magisk denies further modifications and reverts all changes it had done". What will this feature do in the future? Will it satisfy those picky apps that don't like rooted phones? And most importantly, are there any other hiding mechanisms in the pipeline that's supposed to replace MagiskHide?

petersohn said:
MagiskHide is dropped in v24. According to the developer's blog, there will remain a feature that “will be able to assign a denylist of processes where Magisk denies further modifications and reverts all changes it had done". What will this feature do in the future? Will it satisfy those picky apps that don't like rooted phones? And most importantly, are there any other hiding mechanisms in the pipeline that's supposed to replace MagiskHide?
Click to expand...
Click to collapse
Yes, they are. The changes made in v24 allows for even more powerful hiding mechanism, but they need to be added as separate modules. Please consult this thread: https://forum.xda-developers.com/t/discussion-magisk-the-age-of-zygisk.4393877/