MAGISK MODULE ❯ Universal SafetyNet Fix 2.3.1

Search This thread

pndwal

Senior Member
I'm haviong trouble to get Google Pay to work on my phone.

I have a Poco F3 with Lineage 19.1.

Yasnac still says the following:
Basic Pass
CTS profile Match Fail
You need pass here...
Evaluation Type Basic
Timestamp... today's date

Installed Magisk,
Zygisk+list activated, google play services gms and gms.unstable selected
Don't add these to denylist; USNF does proper hiding for these and will remove these from list on next boot anyway...
Universal Safetynet Fix activated
Magiskhide props config installed and pro values adjusted + certified fingerprint as per https://forum.xda-developers.com/t/discussion-magisk-the-age-of-zygisk.4393877/#post-86320349
Revert all changes here except selecting a late certified fingerprint per instructions...

Nb. Sensitive props are handled by USNF anyway, and MHPC function is only needed for those wanting SafetyNet pass on old (pre Oreo) devices w/o USNF...

Nb. 2. certified fingerprint is certainly needed for all official LOS releases due to their anti-spoofing policy, but may not be needed for unofficial LOS as many devs add fingerprint spoofing (ie. spoof a certified stock ROM) along with integrated USNF...
Any ideas what I could do next?
The above...

Once CTS profile match passes you may need to clear data in Google Play Store and/or Google Play Services to obtain Play Protect Device is certified result in Play Store settings...

Next, add Google Pay (only) to denylist and clear its data... You will need to set up cards again, but should be happy now...

Also,

Tip: read USNF GitHub page linked in OP as well as read back thru changelogs... Most (all?) you need to know is covered there (but OP hasn't updated OP in this thread)...

👀 PW
 
Last edited:
  • Like
Reactions: ipdev

otimmy

New member
Jun 30, 2022
2
2
You need pass here...

Don't add these to denylist; USNF does proper hiding for these and will remove these from list on next boot anyway...

Revert all changes here except selecting a late certified fingerprint per instructions...

Nb. Sensitive props are handled by USNF anyway, and MHPC function is only needed for those wanting SafetyNet pass on old (pre Oreo) devices w/o USNF...

Nb. 2. certified fingerprint is certainly needed for all official LOS releases due to their anti-spoofing policy, but may not be needed for unofficial LOS as many devs add fingerprint spoofing (ie. spoof a certified stock ROM) along with integrated USNF...

The above... Also,
Tip: read USNF GitHub page linked in OP as well as read back thru changelogs... All you need to know is covered there (but OP hasn't updated OP in this thread)...

👀 PW
Thank you for your answer.

I started by removing the items from denylist, went to check YASNAC, and now Google Pay is working. :)
 
  • Like
Reactions: ipdev and pndwal

smo69

Senior Member
Jul 16, 2012
55
7
Google Pixel 6 Pro
Hey, newbie question here, but I'm reading a lot of issues in particular with fingerprint readers and apps on One Plus, OPPO, Poco, etc., but what's the failure rate for Safteynet Fix on Pixel devices? I stopped rooting my phone 2 years ago because I couldn't put up with the constant maintenance of Safteynet and apps randomly failing on me, so I'm wondering if rooting is still even worth the hassle. Yes, using a Pixel 6.
 

Gyration3046

New member
Jul 1, 2022
1
0
Poco x3 pro with LOS 19.1 MicroG , Magisk 25.1 and with the lastest USNF 2.3.1 Yasnac safetynet check says Google Play Services API error 13: error . What does that mean ?

edit: i found the fix i should have enabled device registration but now doesnt pass cts match
 
Last edited:

Sneakdovi

Senior Member
Dec 5, 2014
470
36
I'm unable to pay with GPay.
I'm on Oneplus 8pro C20 with root.
I have done everything suggested in the Github post for the USNF and MagiskHideProps:
Basic Integrity: Pass
CTS: Pass
But the payment is rejected.

Is anyone experiencing this?
 
Last edited:

astralmaster

Member
Jul 11, 2022
8
0
Has anyone tried to make this work on an Android emulator? To pass the Safetynet? Is it even doable on standard AOSP images? How would one achieve that?
 

astralmaster

Member
Jul 11, 2022
8
0
I would suggest hardly anyone. Most people use it on an actual Android device.
Why do you feel it is important to have it running on an emulator?
There is an app I want to run on an emulator that streams videos but has this safety net check - Google Play store app doesn't even show it when running from an emulator (it is not searchable/downloadable in the app). I could just get an apk and install it manually but this app constantly releases new versions and having Google Play store would mean easier updating. If there is another method apart from Play Store app that could do the same thing, I would settle for it, but I do not know of any, unfortunately.
 

TioCareca

Senior Member
There is an app I want to run on an emulator that streams videos but has this safety net check - Google Play store app doesn't even show it when running from an emulator (it is not searchable/downloadable in the app). I could just get an apk and install it manually but this app constantly releases new versions and having Google Play store would mean easier updating. If there is another method apart from Play Store app that could do the same thing, I would settle for it, but I do not know of any, unfortunately.
try aurora store 😉
 

rodken

Senior Member
Jan 11, 2010
1,009
393
Zygisk+list activated, google play services gms and gms.unstable selected
Google Play Services became unstable [Google Play Services keeps stopping] after updating from v. 2.2.0 to v. 2.3.1.
-- Force stopped Play Services, cleared cache, cleared data and restarted [to no avail].
--
Uninstalled GPay and reinstalled GPay [to no avail].
--
Force stopped Play Store, cleared cache, cleared data and restarted [to no avail].
--
Uninstalled USNF v. 2.3.1 > restarted > reflashed USNF v. 2.2.0 [hit pay-dirt].

N.B.: These are just my findings considering that there are other avenues that I could've visited.
 

Makishima

Senior Member
Jun 3, 2013
264
42
Xiaomi Mi A3
Google Pixel 4a
Google Pay has updated to Google Wallet and now it says that my device is insecure for contactless payments, whereas right before it worked just fine. Google Pixel 4a Stock + Magisk latest + Zygisk denied everything to do with Google wallet. Also USNF 2.2.1
 

zgfg

Senior Member
Oct 10, 2016
7,650
5,055
Google Pay has updated to Google Wallet and now it says that my device is insecure for contactless payments, whereas right before it worked just fine. Google Pixel 4a Stock + Magisk latest + Zygisk denied everything to do with Google wallet. Also USNF 2.2.1
Not using GPay/Wallet but do you have:
- Zygisk enabled
--Denylist not enforced
- latest Shamiko module installed

And try to add Wallet to DenyList
 

Nova_Max

New member
Jul 21, 2022
4
1
Not using GPay/Wallet but do you have:
- Zygisk enabled
--Denylist not enforced
- latest Shamiko module installed

And try to add Wallet to DenyList
Something in the root detection changed when Google Pay updated to Wallet.

Previously I used Magisk Hide and the sqlite fix but that stopped working yesterday.
Now I updated to the latest Magisk and I am using:
-Shamiko (with Wallet in denylist)
-Universal SafetyNet
-GPay Sqlite fix
-Magisk app hidden

Wallet is still not working even though SafetyNet and Play Certification passes.
I also tested with Oprek which shows everything as passed.
Momo only mentions TEE but isn't able to detect root.

So I think they are using a new way to detect root.
 

zgfg

Senior Member
Oct 10, 2016
7,650
5,055
Something in the root detection changed when Google Pay updated to Wallet.

Previously I used Magisk Hide and the sqlite fix but that stopped working yesterday.
Now I updated to the latest Magisk and I am using:
-Shamiko (with Wallet in denylist)
-Universal SafetyNet
-GPay Sqlite fix
-Magisk app hidden

Wallet is still not working even though SafetyNet and Play Certification passes.
I also tested with Oprek which shows everything as passed.
Momo only mentions TEE but isn't able to detect root.

So I think they are using a new way to detect root.
Probably they improved detections

Btw, did you Clear Cache and Data for Wallet before retesting?

There is a Magisk Delta Fork (you can find on GitHub and there is also the XDA thread)

It's based on latest Magisk v25.2 but you can have Zygisk (optionally) and the old MagiskHide (seems stronger for hiding than DenyList) - you could try

If going for Delta I'd suggest to disable Zygisk and DenyList while still on the official Magisk and all modules relying to Zygisk.
Then you change Magisk app for Magisk Delta app (I use his Delta Canary version on my second phone), patch img from Delta app, flash the patched img - then reboot and start configuring MagiskHide, and re-enable Zygisk and it's modules (optionally)
 

ai024

Member
Nov 13, 2019
6
3
@AndDiSa You can check the Google Wallet contactless payment status by tapping on your avatar in top right corner, then "Tap to pay setup".

Mine says "Phone doesn't meet security requirements" :(
 

pndwal

Senior Member
Google Pay has updated to Google Wallet and now it says that my device is insecure for contactless payments, whereas right before it worked just fine. Google Pixel 4a Stock + Magisk latest + Zygisk denied everything to do with Google wallet. Also USNF 2.2.1
Google Pay / Wallet issues; see last page in this thread (I posted fixes for related issues here also):
https://forum.xda-developers.com/t/...agisk-discussion-thread.3906703/post-87179213

And yes, Google Wallet should be selected in denylist... 👀 PW
 
Last edited:
  • Like
Reactions: 73sydney and rodken

73sydney

Senior Member
fwiw, i had zero issue after doing the wallet update last night

Its important to note that while the app name has changed to Wallet, the packagename seems to remain the same, as i discovered when i checked my Deny List afterwards....

quite why its causing issues for some is a bit of a puzzle...
 
  • Like
Reactions: rodken

Top Liked Posts

  • 4
    So I rooted my brick??? If apps fail to run with root then what good is root???
    Rooting enables a user to have administrator-level permissions to the operating system environment, allows normal users to install custom Roms, alternative software kernels, update to the latest version of Android OS on an older phone, run root apps, remove or bypass bloatware, etc etc. It is also a very important tool for development / developers / software/hardware testing / pen-testers etc etc...

    Modders have also been enjoying the power-use it makes available and unlike Apple, Google is not inclined to prevent any of these advantages of root; Rootability is good for their business model, a selling point for OEM partners and devices and ultimately good for their bottom line and mobile OS promotion.

    Subverting / spoofing security signals however is quite a different matter, and is arguably NOT the purpose of root... It's certainly not an official function in Android...

    When it comes to running proprietary software on anything other than the verified-secure system a vendor agreed to provide software for, these are just our 'wants', and off course banks are concerned (understatement?) when AVB (Android Verified Boot) / DM Verity (Device Mapper Verity), SafetyNet, Play Integrity and other security measures are bypassed...

    Have we just come to expect these personal conveniences simply because we've been on the pigs back for so long?...

    Well when we're unceremoniously ditched, some of us will understand, some will wake up and smell the roses, and others will just continue to hate Google... for taking away our free ride... and just for being big... and successful...

    For me It's a no-brainer that Google must / should meet the hightening security demands of institutions supplying the software Android users want before indulging a small modding community... They'd be nothing other than stupid not to...

    I don't doubt Google want to indulge us (they are our benefactors as providers of the only moddable mobile OS with any sort of respectable presence after all; not 'evil'!)... And they have for quite a while, and quite knowingly to boot!...

    But do the maths!!! - They need to look after corporate partners as well as be seen to be offering a platform that is capable of keeping up with emerging security issues and requirements including a fundamentally infallible system of attestation to a secure operating environment for proprietary code as is expected by both banks and the average bank customer and Android user...

    Hope this helps just a few more here to Get Real! ...

    However...

    When apps do fail to run with root (and they will), both root and development will continue as well as practically all root apps, even if some of us will have to find a new mode of transport...

    MagiskHide is dead... RootHide may be dying too,

    ...but Long Live Root! 😁 PW
  • 99
    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
    25
    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!
    22

    Little update:
    Drop fingerprint to lowest possible (6.0) to ensure that no one use same Android version.
    And renamed module version to original one to avoid misunderstandings with original project.
    17
    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....
  • 269
    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!
    99
    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
    25
    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!