MAGISK MODULE ❯ Universal SafetyNet Fix 2.3.1

Search This thread

PiXinCreate

Member
Dec 21, 2017
40
9
I've Nokia 6.1 Plus A.K.A DRG running Android 12L (LineageOS 19.1 Official).
- Rooted with Magisk v25101.
- For spoofing, I've used Shamiko and USNF v2.3.1-Mod by @Displax. (GMS(unstable and gms) and Momo is selected in Denylist which is not enforced)
- Device is repartitioned to 4.5GB System and 1GB vendor as the device by default support only 2GB which is extremely less than expected.

It passes YASNAC. But Problem for me here is, on PIA checker, I'm getting all red and none of them seem to pass.
Also, Google Play displays the device as certified.
Also, Momo detects the abnormality within the device as shown below:
- Found files modified by Magisk modules.
- Device is running a custom ROM.
- Found Zygisk.
- Zygote is injected.
- Debugging mode is enabled.
- TEE broken.

Surpiresely, when I asked the ROM dev about the TEE, he claimed that if TEE is broken the device itself fails to boot, however, my device is currently turned on and running.

FYI, it has a finger print of A10 QKQ1.190828.002

I feel like it's the issue with the kernel. Any thoughts on this? Any fixes possible with "another" magisk module? How can I get this fixed?

@pndwal
 
Last edited:

CSX321

Senior Member
Aug 21, 2009
641
300
Southern IL USA
Should happen instantly if you clear Google Play Services and Google Play Store data... BTW, do you see Play Protect, Device is certified in Play Store, Settings? PW
FWIW, on my Pixel 6 I never stopped seeing "Device is certified", but Netflix and Hulu still took some time before they showed up again. I wanted to avoid clearing Play Services data, because it requires setting up my watch again, and it's kind of a pain.
 

stathis

Senior Member
May 10, 2015
149
12
Xiaomi Poco X3 NFC
Play Integrity API Strong integrity will fail after unlock bootloader
OnePlus, Realme, Oppo devices will disable hardware attestation after unlock bootloader.
Some Xiaomi devices will also disable hardware attestation but can't be restored after relock bootloader.
That can be the reason for apps to use Strong Integrity check
My phone Xiaomi Poco X3 NFC MIUI EEA GLOBAL 12.0.8 stable android 10. So if want relock my bootloader can't get back the hardware Attestation ?
 
  • Like
Reactions: pndwal

pndwal

Senior Member
Play Integrity API Strong integrity will fail after unlock bootloader
OnePlus, Realme, Oppo devices will disable hardware attestation after unlock bootloader.
Some Xiaomi devices will also disable hardware attestation but can't be restored after relock bootloader.
That can be the reason for apps to use Strong Integrity check
My phone Xiaomi Poco X3 NFC MIUI EEA GLOBAL 12.0.8 stable android 10. So if want relock my bootloader can't get back the hardware Attestation ?
X2

I have Redmi Note 8.

For which models is this confirmed? PW
 

LedgendaryEpics

Senior Member
Jun 14, 2018
195
51
There's this old app I was just reminded about existing called "island", there's also a Samsung counterpoint of this app, but the purpose of this app is to isolate other apps from files and other privacy purposes... I wonder if someone could experiment with it with certain apps and check back on their findings...?
 

rcbjr2

Member
Aug 12, 2010
47
4
This worked great and as soon as I installed it I was able to add my credit cards to Google Pay Wallet. Thanks!
 

bishoy ashraf

Senior Member
Aug 30, 2015
123
6
can i do anything to hide it any better?!
-does data encryption mess with any root detection (is encryption required by any app🥲)?!
 

Attachments

  • Screenshot_20220815-112245.jpg
    Screenshot_20220815-112245.jpg
    278.3 KB · Views: 115
  • Like
Reactions: gverma1

zgfg

Senior Member
Oct 10, 2016
7,814
5,227
can i do anything to hide it any better?!
-does data encryption mess with any root detection (is encryption required by any app🥲)?!
Data encryption is enforced by GOOGLE. Although at least three years old (Android 9/10) there are still people coming from the old devices for whom FBE is kind of 'mistery' - recently posted a longer post to Magisk thread how it works and WHY is it actually GOOD for users, not anything bad

Also, custom recoveries (up to Android 11) support FBE, hence no problem there either. Official TWRP.me does not support FBE for A12 yet but there are (beta stage) unofficial custom recoveries (for various devices) that already do support

Back to your question. No particular app requires - FBE is seamless to apps, Android kernel takes care of

However, if you have new Android without FBE, than it makes obvious that your phone is not stock. And that's what Momo warns about - actually, it warns that device without FBE is not secure

Eg, a thief reboots your phone to custom recovery, he does not need to know your unlock pin/password (bcs data are not encrypted) and he can freely copy your files (personal photos, documents, etc) to his PC and open them.
And that's what banking apps (their developers) might be also concerned about

Why some custom ROMs do not use FBE, maybe ask developer(s)
 
Last edited:

pndwal

Senior Member
can i do anything to hide it any better?!
-does data encryption mess with any root detection (is encryption required by any app🥲)?!
Data encryption is enforced by Google...

Back to your question. No particular app requires - FBE is seamless to apps...

However, if you have new Android without FBE, than it makes obvious that your phone is not stock. And that's what Momo warns about - actually, it warns that device without FBE is not secure
I'm guessing bank apps, like Momo, may not distinguish between FDE and FBE, and it seems it would be simple to combine encryption detection with device information available in a number of props to deduce if a device (most since A6 Marshmallow in fact, and all since A10 Q) was required to be encrypted and thus may be 'rooted' or modified...

It also seems likely that a bank might simply disqualify all unencrypted devices and state 'device does not meet security requirements' instead of 'device has been modified'...

Technical:

Full Disk Encryption (FDE, like hard-drive protection) has been around since Android 4.4.

Encryption and secure boot became mandatory out-of-the-box for all but low memory Google certified devices and those not supporting AES crypto performance above 50MiB/sec, basically devices w/ processors based on ARM Cortex-A7,
with Android 6.

Android 7.0 and later versions support file-based encryption (FBE, like iPhone), but OEMs could implement either FDE or FBE till Android 9 with Android 10 mandating FBE.

The exemption for low-end devices also ended with Android 10 (which introduced the new Adiantum encryption mode targeting ARM Cortex-A7 and improving encryption speeds 5 fold over AES) and the Android Compatibility Definition Document requirement that all new Android devices now be encrypted.


🤠 PW
 

zgfg

Senior Member
Oct 10, 2016
7,814
5,227
I'm guessing bank apps, like Momo, may not distinguish between FDE and FBE, and it seems it would be simple to combine encryption detection with device information available in a number of props to deduce if a device (most since A6 Marshmallow in fact, and all since A10 Q) was required to be encrypted and thus may be 'rooted' or modified...

It also seems likely that a bank might simply disqualify all unencrypted devices and state 'device does not meet security requirements' instead of 'device has been modified'...

Technical:

Full Disk Encryption (FDE, like hard-drive protection) has been around since Android 4.4.

Encryption and secure boot became mandatory out-of-the-box for all but low memory Google certified devices and those not supporting AES crypto performance above 50MiB/sec, basically devices w/ processors based on ARM Cortex-A7,
with Android 6.

Android 7.0 and later versions support file-based encryption (FBE, like iPhone), but OEMs could implement either FDE or FBE till Android 9 with Android 10 mandating FBE.

The exemption for low-end devices also ended with Android 10 (which introduced the new Adiantum encryption mode targeting ARM Cortex-A7 and improving encryption speeds 5 fold over AES) and the Android Compatibility Definition Document requirement that all new Android devices now be encrypted.


🤠 PW
You can read fileencryption tags for /userdata filesystem from vendor/etc/fstab.* file.but it requires root

However, without root, you can read from:
getprop ro.crypto.type

If it returns file it refers to FBE, block refers to FDE (and empty to no encryption)

----

Now also a link to Full Disk Encryption doc:

----

Regarding my Xiaomi Mi 9T - phone was originally released with MIUI 10/A9, hence with FDE

When upgraded to A10 or A11, Data (Internal storage) was reformatted to FBE Adiantum encryption (recently I checked its /userdata filesystem definition, FBE encryption, in the fstab file and been surprised finding it looking 'strange', but then realized it actually corresponds to the Adiantum tags)
 
Last edited:
  • Like
Reactions: 73sydney

Velfess

Senior Member
Jun 21, 2012
77
9
Vilnius
The latest is safetynet-fix-v2.3.1-MOD.zip

If you go through his posts, you will see that the first came the other one, then two or so days later version number was downgraded to safetynet-fix-v2.3.1-MOD.zip

Also, the latest is shown on his GitHub:
Anyone able to edit props when using this modded safetynet fix?
Using this mod made wallet work (many thanks). But now I'm unable to run `props qemu.hw.mainkeys 1` command in termux, to hide navbar.
(I get `/system/bin/sh: props: inaccessible or not found` error)


Sorry, my bad, I accidentally deleted MagiskHideProps mod. Question no longer relevant.
 
Last edited:
  • Like
Reactions: 73sydney

pndwal

Senior Member
However, without root, you can read from:
getprop ro.crypto.type

If it returns file it refers to FBE, block refers to FDE (and empty to no encryption)
Yup, so bank apps can see if a device is encrypted or not irrespective of whether FDE or FBE type, and disqualify these either simply as not meeting security requirements, or as modified where device information is also evaluated... PW
 
  • Like
Reactions: ipdev and 73sydney

zgfg

Senior Member
Oct 10, 2016
7,814
5,227
can i do anything to hide it any better?!
-does data encryption mess with any root detection (is encryption required by any app🥲)?!
However, without root, you can read from:
getprop ro.crypto.type

If it returns file it refers to FBE, block refers to FDE (and empty to no encryption)
can i do anything to hide it any better?!
-does data encryption mess with any root detection (is encryption required by any app🥲)?!
Yup, so bank apps can see if a device is encrypted or not irrespective of whether FDE or FBE type, and disqualify these either simply as not meeting security requirements, or as modified where device information is also evaluated... PW
Maybe, by using eg MHCP and late_start service mode and by setting ro.crypto.type to eg block or file, it could be possible to trick Momo to prevent detecting that Data is not encrypted.
However, it might affect other apps and services (thus suggesting late_start service mode as maybe less risky)
 
Last edited:
  • Like
Reactions: ipdev

triggerhappy_

Member
Jan 16, 2022
32
23
Seems to be working fine on the latest A13.0.0 - Pixel 6 Pro
(raven-tp1a.220624.021-factory-d8ddfdca+Kirisakura_Raven-4.1.0_A13_stable).
1660667195693.png
 

pershoot

Inactive Recognized Developer
Dec 1, 2008
7,990
4,361
I just upgraded to Android 13; Bramble. No issues (USNF 2.3.1-MOD, Latest Magisk + Zygisk, new Wallet app.).
 
  • Like
Reactions: EViollet

Top Liked Posts

  • 1
    having some really weird issues where GPay and my Pixel 6 Pro tells me that it doesn't meet the right requirements for pay, yet I can still make payments by tapping... this was using the unmodded USNF 2.2.0. if i remove that and install the modded version, I still get the same quirk except in Magisk I see this update icon for this module even after rebooting. anyone know how to fix the update issue,
    There's no issue... Icon is greyed out so there's no update... That'll change when there is...
    as well as the requirements message?
    Check you now have deviceIntegrity passing in Play Integrity API Checker.

    This had probably failed prior to installing @Displax USNF mod/fork but Google has been turning new Play Integrity hardware attestation evaluation type enforcement on and off spasmodically for different devices and at different times lately...

    If passing now G Pay/Wallet error message may just go away after some days...

    For immediate fixes:

    Clear Google Play Services data.

    Clear G Pay/Wallet data and reboot before starting app again (important to avoid issues like Activity list failing to populate)... Take any updates and set up cards again as needed...

    If you can't see G Pay/Wallet in Play Store, clear Play Store data then check Play Protect says Device is certified in Play Store settings...

    🤠 PW
    1
    Very strange, today Google play store show me again the Netflix and some other apps which had been missing since July, I don't have changed anything in my phone, I have Xiaomi Poco X3 NFC android 10, magisk 23 with magisk hide com.google.android.gms.unstable and module riru 26.1.3 and Universal SafetyNet Fix 2.1.1 by kdrag0n
    Play Store now relies on Play Integrity API since SafetyNet is deprecated and will hide many apps in store if deviceIntegrity verdict fails...

    As mentioned above, Google has been turning new Play Integrity hardware attestation evaluation type enforcement on and off spasmodically for different devices and at different times lately...

    It seems Google has simply reverted this enforcement for your device recently, but you should probably apply a bypass fix as it's likely they'll restore enforcement when they've sorted out any regression issues for your device...

    Clearly you cannot use @Displax modded USNF version with Play Integrity fix with pre-Zygisk magisk. You can try @huskydg's Riru compatible mod here however:
    https://github.com/HuskyDG/safetynet-integrity-fix

    👀 PW
    1
    Play Store now relies on Play Integrity API since SafetyNet is deprecated and will hide many apps in store if deviceIntegrity verdict fails...

    As mentioned above, Google has been turning new Play Integrity hardware attestation evaluation type enforcement on and off spasmodically for different devices and at different times lately...

    It seems Google has simply reverted this enforcement for your device recently, but you should probably apply a bypass fix as it's likely they'll restore enforcement when they've sorted out any regression issues for your device...

    Clearly you cannot use @Displax modded USNF version with Play Integrity fix with pre-Zygisk magisk. You can try @huskydg's Riru compatible mod here however:
    https://github.com/HuskyDG/safetynet-integrity-fix

    👀 PW
    Oh, understand, I have read about this, until now I'm little lucky until broke again and not see the apps, so now I see again the apps who hide it in Google Play from the July until post this
    1
    Oh, understand, I have read about this, until now I'm little lucky until broke again and not see the apps, so now I see again the apps who hide it in Google Play from the July until post this
    I jinxed, now disappear again the apps from Google Play 🤣😂
  • 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
    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
    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
    3
    Im not super concerned, but if it ever gets that bad, i reckon we start a class action and call it "classroot" or "right to root", which here in Oz would have an entirely different context....

    Just imagine the reactions on my mates faces when I said "Oh I root my phone" for the first and last time.

    Never again.
  • 277
    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!
    134
    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.
    3. You may be needed to wipe GMS data (not cache) if there is no result immediately.

    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!