MAGISK MODULE ❯ Universal SafetyNet Fix 2.3.1

Search This thread

zgfg

Senior Member
Oct 10, 2016
7,803
5,211
I did see the posts, I'm asking if Play Integrity and Play Protect certification are the same thing.

And @plepew is exactly right. Seniority and expertise does not give anyone license to be rude or condescending. If you find yourself unable to respond in a patient, helpful manner, you should avoid posting at all. Remember that disrespect is absolutely not tolerated on XDA. Compliance with the Forum Rules is mandatory, and no one gets a free pass.
From the post and the linked article it should be understandable (if reading carefully before asking) that Google is going to replace SafetyNet API with the new API, and in the foreseeable future - as they say, old API will be removed by June '24, but they ask banking apps to adapt to the incoming API till Jun '23. We are now in Jul '22

Somebody asked how come the SN still works - of course it does since it is still the old SN API, not full-proof (that's one of the main reasons Google will replace) where we can still use the old known holes to bypass
 

V0latyle

Forum Moderator
Staff member
From the post and the linked article it should be understandable (if reading carefully before asking) that Google is going to replace SafetyNet API with the new API, and in the foreseeable future - as they say, old API will be removed by June '24, but they ask banking apps to adapt to the incoming API till Jun '23. We are now in Jul '22

Somebody asked how come the SN still works - of course it does since it is still the old SN API, not full-proof (that's one of the main reasons Google will replace) where we can still use the old known holes to bypass
Right, and I understand that SafetyNet and Play Protect are not the same thing. What I'm asking is if Play Integrity is an evolution or extension of Play Protect, or if it's going to replace both Play Protect and SafetyNet?
 
  • Like
Reactions: plepew and 73sydney

ipdev

Recognized Contributor
Feb 14, 2016
1,919
1
3,519
Google Nexus 10
Nexus 7 (2013)
Right, and I understand that SafetyNet and Play Protect are not the same thing. What I'm asking is if Play Integrity is an evolution or extension of Play Protect, or if it's going to replace both Play Protect and SafetyNet?
Play Integrity is a new (improved) way to check the same things.

It replaces Play Protect and SafetyNet.

There is a short video introduction on Google's website.
Play Integrity API - [developer.android] - Link

Along with a link to the documentation.

Quick links.
Introducing Play Integrity API - [YouTube] - Link
Overview of the Play Integrity API - [developer.android] - Link


Hope it helps more than confuse. 🙃

Cheers. :cowboy:
 

V0latyle

Forum Moderator
Staff member
Play Integrity is a new (improved) way to check the same things.

It replaces Play Protect and SafetyNet.

There is a short video introduction on Google's website.
Play Integrity API - [developer.android] - Link

Along with a link to the documentation.

Quick links.
Introducing Play Integrity API - [YouTube] - Link
Overview of the Play Integrity API - [developer.android] - Link


Hope it helps more than confuse. 🙃

Cheers. :cowboy:
That's the answer I was looking for, thank you!
 
  • Like
Reactions: 73sydney and ipdev

73sydney

Senior Member
That's the answer I was looking for, thank you!

@ipdev and @pndwal did a much better job than my earlier hit and run posting of an androidpolice article from just last month, which gives a roadmap of nearly 2 years...i guess it makes sense if theyve gone hard and early for their core apps...

Like most i only discovered this new paradigm shift by coming across the linked article when the smelly stuff hit the fan or from links from ipdev and pndwal
 

TraderJack

Senior Member
Oct 5, 2008
383
143
Google Pixel 3 XL
That's the answer I was looking for, thank you!
To be clear, the new "Play Integrity API" is a new check that is failing now on many systems.
I guess part of the issue is to figure out exactly why/how and determine if there is a fix. I don't think there is one that will last.

Previously we usually worried about two different checks to make sure all of our apps would download and function properly.

The first was "Play Protect certification" which is visible in the About section of the Play Store settings. I think there have been several methods that were used to determine certification here, but it isn't dependent just on the Play Store app, but more so the Play Services Framework.

It used to be that hiding these services using MagiskHide was sufficient, until Google enhanced and enforced the SafetyNet API, specifically the Hardware Attestation. That was the big rigmarole ~1-2 years ago and what Universal SafetyNet Fix (USNF) has allowed us to get by for the recent past. USNF basically spoofs a keystore which forces SafetyNet to fallback to using Basic instead of Hardware key Attestation (https://github.com/kdrag0n/safetynet-fix/blob/master/docs/details.md).

As mentioned there, we also still needed to pass Basic Attestation with CTS Profile/fingerprint which is where MagiskHide Props Config (MHPC) comes in to set a profile for a phone that will at least pass Basic Attestation.

Using all these things in conjunction (MagiskHide, USND, MHPC) is what has kept us in business for the past year or two.

Now the problems have come two-fold:

First, Magisk has changed and removed MagiskHide. The Deny list that comes with the new versions will disable Magisk from applying anything to those apps listed, but it doesn't hide the presence of Magisk to an app. The LSposed devs have created Shamiko which is a module which can hide Magisk, Zygisk and related modules. I'm not exactly sure how it works, I think it is probably similar to how the old MagiskHide did (don't quote me). But once you enable it as a Magisk Module it uses Magisk's "Configure Deny List" settings to enforce hide (NB: when using Shamiko you want to ensure that the "Configure Deny List" in Magisk settings is setup, but that you don't "Enforce DenyList" as Shamiko does its work instead).

Second, and the big issue at hand:
The introduction, and now partial enforcement of the new(er) Play Integrity API.

In the past, we could ensure that we were passing certification and SafetyNet checks by looking at the Play Store (device certified status), and running any one of the various SN checker apps available. However even passing those checks now is not enough to guarantee things will work anymore because of the new PI-API.

Others have linked above to some articles which explain the basics of how it works. @1nikolas has made the awesomely simple Play Integrity API Checker (which I'm sure there will be more of), which does a simple check to see if the device is passing the check. If you read the articles about how PI-API works and as @1nikolas cautions in another post, this app doesn't verify all the aspects that can be checked with this API. According to the doc overview 3 things can be verified:
  • Genuine app binary
  • Genuine Play install
  • Genuine Android device
I'm pretty sure the first two require the App checking to actually be uploaded to the Play Store, and I believe he is working on an updated app that can do that. App developers will be able to check all these things, but most likely the one giving us the biggest issue now (and the one @1nikolas does check for) is that it is a Genuine Android device.

The question is (which I'm sure others can answer), how is this API checking for and determining if we are on a genuine (or unmodified) device and why are we failing this check when SafetyNet is doing the same thing and we have been able to fool it?

I *think* the answer has to do with Hardware Attestation. Somehow the new PI-API is looking at the device fingerprint and saying "Hey you have a Google Pixel 3 XL running Android 12. You should support Hardware Attestation, so let's use it".
At this point, either the PI-API is finding another way to check for HA that USNF can't get around, or more likely (I *think*) it is failing HA and saying "Well, you should support Hardware Attestation, but the best I can do is Basic. And that isn't good enough...so something must be wrong...and therefore FAIL".

IOW, Basic Attestation was good enough for SafetyNet, but not for the new PI-API.

My further assumption is that the current workaround, which is to use MHPC to set an older device is simply matching devices and profiles to a list that Google is maintaining as to which devices should support the new API fully. Google is pretty confident that a Pixel 3 XL running 12 should support HA and the new API, but maybe they are concerned about breaking older devices so a 3XL running 9 is still set as a "soft pass" as it were in their databases.

This is my guess (also based on some other conversations in the forum here) as to why we are currently able to still work around the enforcement of the new PI-API by setting our devices to an older OS version (and/or possibly an entirely different model depending on our device).

Personally I tried all of the original workarounds but was still failing according to @1nikolas API Checker and GPay was telling me I couldn't add a card because my device was modified. Even so, Play Certification was OK and SafetyNet passed no problem.

I first tried to change my fingerprint with MHPC to "One Plus 5 - Android 9", but even after clears and reboots that didn't work. I then changed it to "Pixel 3XL - Android 9" and I was able to pass. Ofc I should probably have tried my phone model first, but someone with a One Plus 5 responded that fingerprint worked for them. I find it interesting (because I'm not sure why), the other fingerprint didn't work on my phone when it did function successfully on another (after all one whole point of MHPC is to emulate another device through its props).

Hopefully with the ground set with the above, those more knowledgeable can chime in to offer corrections, clarifications, and theories on where we can go now....
 

1nikolas

Senior Member
Jul 28, 2015
199
126
Heraklion, Greece
I'm pretty sure the first two require the App checking to actually be uploaded to the Play Store, and I believe he is working on an updated app that can do that
That is true but I was talking about the 3 flags of the "Genuine Android device" thing. The "old" (aka current) app only checks for MEETS_DEVICE_INTEGRITY but there are 2 extra flags, MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY which are (as far as I know) one to one with the SafetyNet Basic and CTS profile (but of course more strict). The latter 2 are available only for apps through the Play Store that's why I made a new better app for and uploaded it on Play Store. The only problem is that Google tells me they need to "Verify my ID" and this takes 2 business days (so that is tomorrow). In the meantime you can check the source code which is available on Github (frontend and backend)

Note: I havent actually tested the functionallity of the 2 extra flags because, well, I can't until the app is published on Google Play
 

pndwal

Senior Member
Are you talking about Play Protect certification? My Pixel 5 passes both SafetyNet and Play Protect, yet somehow GPay still detects root.
No... Play Protect status (at least currently) relies on SafetyNet API which was deprecated last month.

This concerns the SafetyNet replacement called Play Integrity. 😛 PW
 

TraderJack

Senior Member
Oct 5, 2008
383
143
Google Pixel 3 XL
That is true but I was talking about the 3 flags of the "Genuine Android device" thing. The "old" (aka current) app only checks for MEETS_DEVICE_INTEGRITY but there are 2 extra flags, MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY which are (as far as I know) one to one with the SafetyNet Basic and CTS profile (but of course more strict). The latter 2 are available only for apps through the Play Store that's why I made a new better app for and uploaded it on Play Store. The only problem is that Google tells me they need to "Verify my ID" and this takes 2 business days (so that is tomorrow). In the meantime you can check the source code which is available on Github (frontend and backend)

Note: I havent actually tested the functionallity of the 2 extra flags because, well, I can't until the app is published on Google Play
Would be good to know exactly what they mean how they are determined!
This is what is out there:


By default, device_recognition_verdict can have one of the following labels:

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.

No labels (a blank value) The app is running on a device that has signs of attack (such as API hooking) or system compromise (such as being rooted), or the app is not running on a physical device (such as an emulator that does not pass Google Play integrity checks).

If you opt in to receive additional labels in the integrity verdict, device_recognition_verdict can have the following additional labels:

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.

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.

Furthermore, if your app is being released to approved emulators, the device_recognition_verdict can also take on the following label:

MEETS_VIRTUAL_INTEGRITY The app is running on an Android emulator powered by Google Play services. The emulator passes system integrity checks and meets core Android compatibility requirements.


So what is interesting is my device (and I'm sure others) according to your app is simply showing MEETS_DEVICE_INTEGRITY.

At this point, they must not be opting in for the "additional labels" as mentioned above. If they are they certainly would not be delivering the MEETS_STRONG_INTEGRITY label. If they were it would mean that hardware-backed attestation was either not really necessary, or still being fooled by USNF.
 
Last edited:

1nikolas

Senior Member
Jul 28, 2015
199
126
Heraklion, Greece
Would be good to know exactly what they mean how they are determined!

Also this is interesting:
If you are having problems with your testing device meeting device integrity, make sure the factory ROM is installed (for example, by resetting the device) and that the bootloader is locked.

It checks for bootloader too (unless SafetyNet did that too)
 

TraderJack

Senior Member
Oct 5, 2008
383
143
Google Pixel 3 XL
Also this is interesting:


It checks for bootloader too (unless SafetyNet did that too)
Yes I also read that and found it interesting, but assumed anyone who wanted would read the full page (as you did!).
I believe, SafetyNet would have certainly checked for bootloader for HA.
But with USNF, we only were ever reporting Basic (saying we couldn't perform HA), so they would not have known if it was locked or not.
Now, according to my theory above, we have to prove our Hardware Attestation status through the new API in order to be given a STRONG rating.
 
  • Like
Reactions: 1nikolas

Orphee

Senior Member
Jan 31, 2008
1,713
787
Hi !

Samsung Galaxy S20 5G with Android 12.
as everybody there, new Google check killed Pay features.

My bootloader is unlocked
Magisk 25.2
Safetynet fix module

I used Props config to fake S20 ultra Android 10 from certified list.
Wiped Play services and GPay. rebooted.

It did the trick, for now.

GPay/Wallet is working again.
 
  • Like
Reactions: EViollet

desvariando

Senior Member
Jan 1, 2017
192
68
To be clear, the new "Play Integrity API" is a new check that is failing now on many systems.
I guess part of the issue is to figure out exactly why/how and determine if there is a fix. I don't think there is one that will last.

Previously we usually worried about two different checks to make sure all of our apps would download and function properly.

The first was "Play Protect certification" which is visible in the About section of the Play Store settings. I think there have been several methods that were used to determine certification here, but it isn't dependent just on the Play Store app, but more so the Play Services Framework.

It used to be that hiding these services using MagiskHide was sufficient, until Google enhanced and enforced the SafetyNet API, specifically the Hardware Attestation. That was the big rigmarole ~1-2 years ago and what Universal SafetyNet Fix (USNF) has allowed us to get by for the recent past. USNF basically spoofs a keystore which forces SafetyNet to fallback to using Basic instead of Hardware key Attestation (https://github.com/kdrag0n/safetynet-fix/blob/master/docs/details.md).

As mentioned there, we also still needed to pass Basic Attestation with CTS Profile/fingerprint which is where MagiskHide Props Config (MHPC) comes in to set a profile for a phone that will at least pass Basic Attestation.

Using all these things in conjunction (MagiskHide, USND, MHPC) is what has kept us in business for the past year or two.

Now the problems have come two-fold:

First, Magisk has changed and removed MagiskHide. The Deny list that comes with the new versions will disable Magisk from applying anything to those apps listed, but it doesn't hide the presence of Magisk to an app. The LSposed devs have created Shamiko which is a module which can hide Magisk, Zygisk and related modules. I'm not exactly sure how it works, I think it is probably similar to how the old MagiskHide did (don't quote me). But once you enable it as a Magisk Module it uses Magisk's "Configure Deny List" settings to enforce hide (NB: when using Shamiko you want to ensure that the "Configure Deny List" in Magisk settings is setup, but that you don't "Enforce DenyList" as Shamiko does its work instead).

Second, and the big issue at hand:
The introduction, and now partial enforcement of the new(er) Play Integrity API.

In the past, we could ensure that we were passing certification and SafetyNet checks by looking at the Play Store (device certified status), and running any one of the various SN checker apps available. However even passing those checks now is not enough to guarantee things will work anymore because of the new PI-API.

Others have linked above to some articles which explain the basics of how it works. @1nikolas has made the awesomely simple Play Integrity API Checker (which I'm sure there will be more of), which does a simple check to see if the device is passing the check. If you read the articles about how PI-API works and as @1nikolas cautions in another post, this app doesn't verify all the aspects that can be checked with this API. According to the doc overview 3 things can be verified:
  • Genuine app binary
  • Genuine Play install
  • Genuine Android device
I'm pretty sure the first two require the App checking to actually be uploaded to the Play Store, and I believe he is working on an updated app that can do that. App developers will be able to check all these things, but most likely the one giving us the biggest issue now (and the one @1nikolas does check for) is that it is a Genuine Android device.

The question is (which I'm sure others can answer), how is this API checking for and determining if we are on a genuine (or unmodified) device and why are we failing this check when SafetyNet is doing the same thing and we have been able to fool it?

I *think* the answer has to do with Hardware Attestation. Somehow the new PI-API is looking at the device fingerprint and saying "Hey you have a Google Pixel 3 XL running Android 12. You should support Hardware Attestation, so let's use it".
At this point, either the PI-API is finding another way to check for HA that USNF can't get around, or more likely (I *think*) it is failing HA and saying "Well, you should support Hardware Attestation, but the best I can do is Basic. And that isn't good enough...so something must be wrong...and therefore FAIL".

IOW, Basic Attestation was good enough for SafetyNet, but not for the new PI-API.

My further assumption is that the current workaround, which is to use MHPC to set an older device is simply matching devices and profiles to a list that Google is maintaining as to which devices should support the new API fully. Google is pretty confident that a Pixel 3 XL running 12 should support HA and the new API, but maybe they are concerned about breaking older devices so a 3XL running 9 is still set as a "soft pass" as it were in their databases.

This is my guess (also based on some other conversations in the forum here) as to why we are currently able to still work around the enforcement of the new PI-API by setting our devices to an older OS version (and/or possibly an entirely different model depending on our device).

Personally I tried all of the original workarounds but was still failing according to @1nikolas API Checker and GPay was telling me I couldn't add a card because my device was modified. Even so, Play Certification was OK and SafetyNet passed no problem.

I first tried to change my fingerprint with MHPC to "One Plus 5 - Android 9", but even after clears and reboots that didn't work. I then changed it to "Pixel 3XL - Android 9" and I was able to pass. Ofc I should probably have tried my phone model first, but someone with a One Plus 5 responded that fingerprint worked for them. I find it interesting (because I'm not sure why), the other fingerprint didn't work on my phone when it did function successfully on another (after all one whole point of MHPC is to emulate another device through its props).

Hopefully with the ground set with the above, those more knowledgeable can chime in to offer corrections, clarifications, and theories on where we can go now....
I am on Magisk on a custom ROM on Android 12 which mimics a Pixel 5 with Android 12 fingerprint. It only passes Basic integrity.
Play Integrity fails.

However, when removing Magisk, despite being on Android 12 and with Basic Integrity, "Play Integrity" passes.

So, there is something else behond hardware attestation, as otherwise I wouldn't be able to run the "Stock ROM" passing Play Integrity.
 

TraderJack

Senior Member
Oct 5, 2008
383
143
Google Pixel 3 XL
I am on Magisk on a custom ROM on Android 12 which mimics a Pixel 5 with Android 12 fingerprint. It only passes Basic integrity.
Play Integrity fails.

However, when removing Magisk, despite being on Android 12 and with Basic Integrity, "Play Integrity" passes.

So, there is something else behond hardware attestation, as otherwise I wouldn't be able to run the "Stock ROM" passing Play Integrity.
I don't think that is definitive.
Also. Define what you mean by "Basic integrity"? Are you speaking about SafetyNet?
 

pndwal

Senior Member
Would be good to know exactly what they mean how they are determined!
This is what is out there:



So what is interesting is my device (and I'm sure others) according to your app is simply showing MEETS_DEVICE_INTEGRITY.

At this point, they must not be opting in for the "additional labels" as mentioned above. If they are they certainly would not be delivering the MEETS_STRONG_INTEGRITY label. If they were it would mean that hardware-backed attestation was either not really necessary, or still being fooled by USNF.
But if MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY are one for one with original Basic Integrity and Compatibility Test Suite Profile match (I'm not sure they are 'one for one', but seems likely they are very similar at this point, and can still be made to fall back to a basic attestation/evaluation type), then these are likely opted for by the apps and passing (by using USNF)...

My conclusion is that GPay, Play Store etc are calling STRONG_INTEGRITY verdict in fact, but the basic DEVICE_INTEGRITY verdict is using fingerprint prop in a way that's not yet clear to me... It seems likely that this is actually bypassing hardware attestation for this verdict (a fallback to basic?) per some Google server end white or black-list of fingerprints currently...

It is clear that USNF is working currently for PI API as for S/N once a passing fingerprint is selected (at least for A11+ devices generally; A10- seem to pass PI's DEVICE_INTEGRITY verdict as is); this attestation will fail where the selected fingerprint fails old CTS Profile match or if USNF is simply disabled, indicating that a STRONG_INTEGRITY verdict is probably being effectively bypassed by USNF... PW
 

TraderJack

Senior Member
Oct 5, 2008
383
143
Google Pixel 3 XL
But if MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY are one for one with original Basic Integrity and Compatibility Test Suite Profile match (I'm not sure they are 'one for one', but seems likely they are very similar at this point, and can still be made to fall back to a basic attestation/evaluation type), then these are likely opted for by the apps and passing (by using USNF)...

My conclusion is that GPay, Play Store etc are calling STRONG_INTEGRITY verdict in fact, but the basic DEVICE_INTEGRITY verdict is using fingerprint prop in a way that's not yet clear to me... It seems likely that this is actually bypassing hardware attestation for this verdict (a fallback to basic?) per some Google server end white or black-list of fingerprints currently...

It is clear that USNF is working currently for PI API as for S/N once a passing fingerprint is selected (at least for A11+ devices generally; A10- seem to pass PI's DEVICE_INTEGRITY verdict as is); this attestation will fail where the selected fingerprint fails old CTS Profile match or if USNF is simply disabled, indicating that a STRONG_INTEGRITY verdict is probably being effectively bypassed by USNF... PW

I don't think I agree with much of that (FWIW).
To start. SafetyNet check is made up of several components, but the two most important are ctsProfileMatch and basicIntegrity. See here.

It would appear based on verbiage in the PI-API that MEETS_STRONG_INTEGRITY requires Hardware Attestation.
MEETS_STRONG_INTEGRITYThe 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.
I'll concede that the documentation isn't 100% clear. It clearly says has a "strong guarantee" but it also say "SUCH AS harware-backed proof of boot integrity" (i.e. HA). I think it is not unreasonable to assume that MEETS_STRONG_INTEGRITY requires a successful HA, which USNF will not produce.

I think MEETS_BASIC_INTEGRITY is on par with SafetyNet passing with basicIntegrity=True, whereas MEETS_STRONG_INTEGRITY would be SafetyNet passing with Hardware Attestation.

I'm also curious to how you believe that USNF is definitively working for PI API? We can assume that USNF is functioning as it did before. Meaning that when HA is requested, USNF causes it to failback to basic. This would therefore make the device pass SN with a qualification of basic which would therefore allow the device to meet the PI API requirement of MEETS_BASIC_INTEGRITY assuming that the CTS Profile is being matched to a device which currently does not require HA to meet it.

Again, these are my thoughts just looking at the available documentation and data we have so far. I'm interested in further discussion.

EDIT: AHA - I found I think part of what we are looking for:


I believe it is backing up my statements. It shows that the original SN checks of basicIntegrity and CTSProfileMatch only contribute to the decisions and are not a one-to-one match.

What is very interesting about this chart (and although it does reinforce what I was saying, it also muddles it with misinformation from other posts). Previously the documentation stated that MEETS_DEVICE_INTEGRITY is the standard response to device_recognition_verdict. It also says the additional data labels of BASIC_OR_STRONG can be delivered if requested.

However this chart seems to indicate that MEETS_BASIC_INTEGRITY can be returned independently of MEETS_DEVICE_INTEGRITY, which to me would be completely contradictory to what was being stated in the previously linked section.

Regardless, it shows that:
MEETS_BASIC_INTEGRITY is equivalent to a SafetyNet pass of ctsProfileMatch = True and basicIntegrity/Basic Evaluation. This is what USNF provides.
MEETS_STRONG_INTEGRITY is equivalent to a SafetyNet pass of ctsProfileMatch = True and basicIntegrity/HA Evaluation. This is not going to be achievable on almost any rooted/unlocked device.
 
Last edited:

zgfg

Senior Member
Oct 10, 2016
7,803
5,211
But if MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY are one for one with original Basic Integrity and Compatibility Test Suite Profile match (I'm not sure they are 'one for one', but seems likely they are very similar at this point, and can still be made to fall back to a basic attestation/evaluation type), then these are likely opted for by the apps and passing (by using USNF)...

My conclusion is that GPay, Play Store etc are calling STRONG_INTEGRITY verdict in fact, but the basic DEVICE_INTEGRITY verdict is using fingerprint prop in a way that's not yet clear to me... It seems likely that this is actually bypassing hardware attestation for this verdict (a fallback to basic?) per some Google server end white or black-list of fingerprints currently...

It is clear that USNF is working currently for PI API as for S/N once a passing fingerprint is selected (at least for A11+ devices generally; A10- seem to pass PI's DEVICE_INTEGRITY verdict as is); this attestation will fail where the selected fingerprint fails old CTS Profile match or if USNF is simply disabled, indicating that a STRONG_INTEGRITY verdict is probably being effectively bypassed by USNF... PW

More exactly, per Play Integrity API documentation, Device Integrity Verdict mapping table:


SafetyNet basicIntegrety = Play Integrity MEETS_BASIC_INTEGRITY

SafetyNet basicIntegrety + ctsProfileMatch with Basic attestation = Play Integrity MEETS_DEVICE_INTEGRITY

SafetyNet basicIntegrety + ctsProfileMatch with Hardware_backed attestation = Play Integrity MEETS_STRONG_INTEGRITY

Screenshot from the API doc attached

Edit: I see now that @TraderJack has already quoted that mapping table😁
 

Attachments

  • Screenshot_2022-07-25-20-37-56-926_com.android.chrome.jpg
    Screenshot_2022-07-25-20-37-56-926_com.android.chrome.jpg
    287 KB · Views: 229
Last edited:

Displax

Senior Member
Jan 19, 2015
289
1,007
26
Kyiv
So, here is my modification of USNF with Play Integrity API bypass.

It changes fingerprint to old 7.1.2 6.0 (LOL) and apply it only for GMS SafetyNet process (by Zygisk injection), so your original prints/security path level does not change. This avoids many side effects/problems with global props changing.

Updated:
Drop fingerprint to lowest possible (6.0) to ensure that no one use same Android version

Usage:
1. Delete/disable/reset MagiskHidePropsConfig (if installed).
2. Just install it over old Universal SafetyNet Fix and reboot device.

Many thanks to @1nikolas for integrity checker.

Source code: https://github.com/Displax/safetynet-fix/tree/integrity
 

Attachments

  • safetynet-fix-v2.3.1-MOD.zip
    91.6 KB · Views: 4,925
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    So 'a boring or unenterprising person' or a fan of "Casey Jones"?... You don't need to answer that! 😜
    "And you know that notion just crossed my mind." 🙃

    Had a quick look at mHide SafetyNet project though...
    Just from this:

    Magisk Module
    Module to help pass SafetyNet on devices that do not support hardware attestation...

    This module will
    • Generate a list of 'sensitive' properties on the device and set the values to the 'safe' setting(s) during boot.
    • Check and adjust some 'sensitive' properties during boot.
    • Set Magisk's Denylist to enforcing.
    • Add part of PlayServices to the DenyList.
    Requires Zygisk to be enabled in Magisk.
    ... I'm wondering:
    - Could this be made to be an ideal solution for older devices in the event that Zygisk fix in modded USNF cannot be activated for A7 and lower?
    That is the idea (attempt). 🙃

    Ie.
    • Do adjustments to sensitive props target only com.google.android.gms.unstable?
    • Can we not set Denylist to enforcing (for use with Shamiko etc)?
    • Can we do targeted hiding of root from com.google.android.gms.unstable process instead of adding this to denylist (like USNF)?
    (I'm assuming Magisk path is always in /sbin in legacy ramdisk booting devices; is this correct?)
    • Can we do com.google.android.gms.unstable targeted spoofing of the same old A6 fingerprint prop as @Displax's USNF mod uses to fix CTS Profile Match in uncertified ROMs? (Possibly this could be enabled as an option if there's any benefit leaving original fingerprint as is where ROM is stock... I'm not sure there is however...)

    At the time I started mHide SafetyNet, the only way to access the denylist was when enforcing.
    The only way to "hide" Magisk was to add SafetyNet and (if needed) GMS to the denylist.
    A lot has changed since then and part of the reason I shelved the project.
    mHideSN still works on newer devices that do not support 'Hardware attestation'.
    Plan to update and cleanup one more time before archiving the repo.

    ---

    As for merging parts of mhsn into USNF..

    The 'com.google.android.gms' part is only to "hide" Magisk from SafetyNet when enforcing the Denylist.
    Only added on Android 7.x and older with Magisk 24.x and newer.
    Adapted from the 'MagiskHide' code purge. Lines 230-231 | Lines 249-256
    Became the 'set_default_list' function.​

    Since there are now other methods to "hide" Magisk..
    I currently only included a denylist check for Android 7.x and below.
    Not the part to enforce the denylist.

    Not sure if other methods like 'Shamiko' work on Android 7.x and below?

    When other methods of "hiding" Magisk started coming out.
    Most of them using the denylist (instead of creating their own list).
    I was not sure if any current or future, needed to add gms to the denylist list?
    - Part of the reason for commit.

    ---

    Setting the sensitive [secure] prop(s) to the safe value is only limited to what I and others have found.
    This part works across all Android versions.
    Using a system.prop file for some and the resetprop command in the service script for others.​

    The 'system.prop' file is generated during the install.
    I tried to move them all into the service and/or post-fs script(s) to be more dynamic (check and adjust during boot) but, ran into some issues.
    Some device/manufacture props do not exist until very late after boot complete if at all.
    So back to creating a system.prop file during the module install.​

    If the following prop(s) exist, it is added to the system.prop file regardless of the current value.
    The prop is added with the safe value.
    I would prefer to only add insecure props with the safe value but, this is a work-a-round in case the props are set by another module(s).​
    These props will be set shortly after the post.fs stage.
    ro.adb.secure=1
    ro.boot.selinux=enforcing
    ro.boot.warranty_bit=0
    ro.build.tags=release-keys
    ro.build.type=user
    ro.debuggable=0
    ro.is_ever_orange=0
    ro.odm.build.tags=release-keys
    ro.odm.build.type=user
    ro.product.build.tags=release-keys
    ro.product.build.type=user
    ro.system.build.tags=release-keys
    ro.system.build.type=user
    ro.vendor.boot.warranty_bit=0
    ro.vendor.build.tags=release-keys
    ro.vendor.build.type=user
    ro.vendor.warranty_bit=0
    ro.warranty_bit=0
    Props that are checked and adjusted if need be in service script.
    If 'ro.boot.mode' is recovery, set to unknown
    If 'ro.bootmode' is recovery, set to unknown
    If 'vendor.boot.mode' is recovery, set to unknown

    If 'ro.boot.hwc' is CN, set to GLOBAL
    If 'ro.boot.hwcountry' is China, set to GLOBAL

    If 'ro.build.selinux' exists, delete (remove) it.
    I still question this one but, it was part of 'MagiskHide'.
    'ro.boot.flash.locked' if not 1, set to 1
    'ro.boot.vbmeta.device_state' if not locked, set to locked
    'ro.boot.verifiedbootstate' if not green, set to green
    'ro.boot.veritymode' if not enforcing, set to enforcing
    'ro.secure' if not 1, set to 1
    'sys.oem_unlock_allowed' if not 0, set to 0
    'vendor.boot.vbmeta.device_state' if not locked, set to locked
    'vendor.boot.verifiedbootstate' if not green, set to green

    Currently USNF includes a 'system.prop' file.
    By generating the 'system.prop' file during the install instead, we can check if the prop exists before adding it.
    This will help from adding non-native props to the device.
    Currently any one using USNF has the OnePlus and Samsung props set.
    No matter if it is a Google, LG, Motorola, Poco, ...., Xiaomi device.

    ---

    Without the Zygisk part of the module, You would have to set the fingerprint globally.
    The same as the MHPC module does.
    Set props early (post-fs) you will change it across the board.
    Set props late (service) you will set it after system has started.
    For example of the difference between setting props early and late, see my question and flar2's response in the DevCheck thread - Post #258.​

    ---

    Hope it helps explain more than confuse. 🙃

    Cheers. :cowboy:
    5
    Strong integrity = hardware attestation, basically, so no, no way to fix AFAIK. OnePlus devices at least up to the OnePlus 9 Pro still shipped stock with broken hardware attestation, so there's no way at all of getting it working on those devices.
    4
    That's what I have... (But Xiaomi device w/ A10)...
    The 1st thing i did was to put play services and frameworks to denaylist.
    ... Better remove everything from there except bank apps etc... PW
    4
    Hi all,

    Does anyone know if there is any fix for the "MEETS_STRONG_INTEGRITY" ?
    From what I've read, the "MEETS_DEVICE_INTEGRITY" and "MEETS_BASIC_INTEGRITY" are fixable using Displax's fix on the USNF (thank you so much for this).

    However, i didn't found anything related the strong integrity.
    Is this correct, or have I missed some step?
    I'm facing this on a OnePlus 5 and a Nothing 1

    Thanks
    Yes; purchase an Asus ROG Phone 3!

    This is the only device I know of where the OEM has messed up the Keymaster implementation in such a way that it will pass MEETS_STRONG_INTEGRITY verdict w/ unlocked bootloader... Other device's may also...

    An app requiring new MEETS_STRONG_INTEGRITY is equivalent to requiring old CTS Profile Match using HARDWARE_BACKED evaluationType. As such, banks have not yet required either (although they could) as doing so would exclude users / customers with
    1) Many late devices (many OnePlus and others) with broken keymaster implementations.
    2) Devices launched with Android 7 and earlier, even if running late Android.

    🤠 PW
    3
    guys this is new. this app detected shamiko

    edit:zygisk denylist fixed this. this is the first time i encounter shamiko will be the culprit
    Screenshot_2022-09-02-07-25-47-473_com.GameDuo.MadArcher.jpg
  • 276
    Universal SafetyNet Fix
    Magisk module​

    Magisk module to work around Google's SafetyNet attestation.

    This module works around hardware attestation and recent updates to SafetyNet CTS profile checks. You must already be able to pass basic CTS profile attestation, which requires a valid combination of device and model names, build fingerprints, and security patch levels.

    If you still have trouble passing SafetyNet with this module, use MagiskHide Props Config to spoof a certified device profile. This is a common issue on old devices, custom ROMs, and stock ROMs without GMS certification (e.g. Chinese ROMs).

    Android versions up to 13 Beta 3 are supported, including OEM skins such as Samsung One UI and MIUI.

    How does it work?
    The way this workaround works is relatively low-level. An in-depth explanation, as well as source code and ROM changes, can be found on GitHub.

    Ideally, this workaround should be incorporated in ROMs instead of overriding part of the ROM in a Magisk module. The ROM changes for it are linked above for ROM developers to use.

    Downloads
    Downloads and changelogs can be found on GitHub. The topmost release is the latest.

    Latest release
    v2.3.1

    Highlights
    • Fixed fingerprint on OxygenOS/ColorOS 12 (@osm0sis)
    • Support for Magisk 24+ module updates (@benjibobs)
    • Restored support for Android 7
    Other changes
    • Spoofed OnePlus OEM unlock status for futureproofing (@osm0sis)
    • Minor code improvements
    This version only supports Zygisk (Magisk 24 and newer).

    Source code

    If this helped you, please consider donating to support development: recurring donation for sustainable support or buy me a coffee. Thank you for your support!
    132
    So, here is my modification of USNF with Play Integrity API bypass.

    It changes fingerprint to old 7.1.2 6.0 (LOL) and apply it only for GMS SafetyNet process (by Zygisk injection), so your original prints/security path level does not change. This avoids many side effects/problems with global props changing.

    Updated:
    Drop fingerprint to lowest possible (6.0) to ensure that no one use same Android version

    Usage:
    1. Delete/disable/reset MagiskHidePropsConfig (if installed).
    2. Just install it over old Universal SafetyNet Fix and reboot device.

    Many thanks to @1nikolas for integrity checker.

    Source code: https://github.com/Displax/safetynet-fix/tree/integrity
    30
    Folks, the SafetyNet API was depreciated last Month with 'full turndown' slated for June 2024 and the introduction of the new Play Integrity API. It has also become clear that Google apps are simply the first to adopt the long foretold Play Integrity API; all responsible banks are bound to follow suit in short order, and at least before the June 2023 migration deadline.

    This means (assuming fully deployed Hardware Key Attestation doesn't come first 😬) that the need for a 'Universal Play Integrity Fix' has become quite urgent.

    We currently have workarounds involving using older fingerprint props by means of MHPC module (similar to fix needed for uncertified ROMs), but success/mileage varies per device and users of regular bank apps / gamers etc on stock devices will all soon be forced to experiment with MHPC prints also... This is hardly ideal.

    So I've made an issue report/request on USNF GitHub as follows. This information may be insightful to users here also...

    Please let me know here if I have missed anything important, or add any technically relevant details there...

    PLEASE DON'T spam that issue with unimportant details or queries... (The previous issue is already burgeoning w/ OT.) That's what this thread is for... 😛 :

    Please make 'Universal Play Integrity Fix' ... #204

    Fixes to expand 'Universal SafetyNet Fix' to become a 'Universal Play Integrity Fix' are needed.

    The SafetyNet Attestation API is deprecated and has been replaced by the Play Integrity API.
    https://developer.android.com/training/safetynet/deprecation-timeline

    New Play Integrity API is rolling out from June 2022, and evidently Google Play Store and Google Pay/Wallet are already using its verdict.

    June 2023 is the Migration Deadline for app developers. This will also allow their older app versions to continue working with SafetyNet API for a limited time.

    June 2024 is the End of life for SafetyNet API; its attestation will no longer work for any app version, and apps will receive an error.

    The new Integrity API has more strict requirements for passing attestation, and this seems to be enforced in Android 11+ particularly.

    Currently (evidently due to this), device security issues are detected by

    1. Google Pay/Wallet, which may state "You can't pay contactless with this device...(Your phone doesn't meet software standards)" on updating or attempting to add a card despite in-app Contactless setup stating "You're ready to pay contactless with your phone (Your phone meets security requirements)", and
    2. Google Play Store, which may no longer show apps like Netflix w/ Android 11+ (developers can 'exclude devices from their app's distribution based on their device integrity . Device exclusion is based on the latest device integrity verdict that the Play Store app receives from the Play Integrity API') despite in-app settings showing Play Protect 'Device is certified' result.
    I'm guessing that the 'passing' messages based on the old SafetyNet API are likely to realigned soon.

    A workaround that evidently allows Play Integrity API attestation to pass (and solve Wallet / Play Store issues also) has been discovered. It involves spoofing an earlier certified ROM, generally by using MagiskHide Props Config module to change fingerprint prop to one for Android 10 or earlier.

    Undoubtedly other apps will begin to detect broken TEE etc / fail as they migrate or begin integrating the Play Integrity API.

    A 'Universal Play Integrity Fix' will evidently require more understanding / research into how the fingerprint prop is used, and possibly other new behaviours.

    Here's hoping... 🙃 PW
    28
    ok so there is a solution

    get the magisk module riru

    after you get riru get LSPosed

    after you get LSPosed get xprivacylua (in the LSPosed app)

    select play services in the xprivacylua settings IN the LSPosed app

    AND in the xprivacylua app itself after you've restarted.

    clear play service data

    check safetynet in magisk - enjoy?

    I would reboot between each step just to be safe but I know it's necessary to load the xprivacylua module

    s/o to saitama_96 for discovering it or so I'm led to believe
    26
    Some useless statistics:
    My MOD was downloaded over 2k times.
    1,5k from XDA
    800 from GitHub

    I'm glad i made 2000+ people happier :) Thank you!