MAGISK MODULE ❯ Universal SafetyNet Fix 2.4.0

Search This thread

73sydney

Senior Member
I thought I read somewhere: Turn ON airplane mode, Clear cache and data of the apps, Reboot and Turn OFF airplane mode before running the apps again.

some of us recommend doing the airplane mode thing for Google Play Store/Google Play Services when trying to pass the Integrity test after installing Magisk

not necessary for the average app
 

m0han

Senior Member
Apr 30, 2012
5,305
2,397

Attachments

  • Screenshot_20221208_180827.jpg
    Screenshot_20221208_180827.jpg
    33 KB · Views: 70
  • Like
Reactions: bombadier

Arealhooman

Senior Member
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 2.0:
Bypassing DEVICE_INTEGRITY for devices that shipped with Android 13+ (Pixel`s 7 )

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
Is this better than original
 
  • Haha
Reactions: pndwal

zgfg

Senior Member
Oct 10, 2016
8,201
5,837
Xiaomi Mi 11
Xiaomi Mi 11 Lite 5G
Did you read what you quoted?
It was developed to pass Play Integrity API when Google switched from SN to PI.
For many, it was needed to pass PI

Besides, you can easily switch back and force from the 'original' to this one. Modules are systemless - you disable or uninstall, all their changes will be gone

Hence nothing is stopping you to try. Btw, if the 'original' works for you, why changing the winning team.
But if you're not passing PI, then definitely try
 
  • Like
Reactions: pndwal and 73sydney

73sydney

Senior Member

He's possibly still asleep as its 5:30AM Sydney time, or starting his walk up his belltower on the way to work

USNF MOD v.2: Bypassing DEVICE_INTEGRITY for devices that shipped with Android 13+ (Pixel`s 7 )

It functionally makes no dfifference if youre

a) already passing with the non-modded one

or

b) whether you use v1.0 or v2.0 of the Modded version, if the non-modded one doesnt work, unless youre on a device launching with A13...

All the above will be moot within days when kdrag0n rolls out his updated official one
 
Last edited:

Arealhooman

Senior Member
He's possibly still asleep as its 5:30AM Sydney time, or starting his walk up his belltower on the way to work

USNF MOD v.2: Bypassing DEVICE_INTEGRITY for devices that shipped with Android 13+ (Pixel`s 7 )

It functionally makes no dfifference if youre

a) already passing with the non-modded one

or

b) whether you use v1.0 or v2.0 of the Modded version, if the non-modded one doesnt work, unless youre on a device launching with A13...

All the above will be moot wihin days when kdrag0n rolls out his updated official one
Wait this module will be updated ”within days”?
 

varunpilankar

Senior Member
Jul 8, 2012
245
66
Sony Xperia SP
Moto X
I'm trying to make Paytm Tap to pay work using Mod2.. But still no luck.

Check the screenshots.
 

Attachments

  • Screenshot_20221209-131830.jpg
    Screenshot_20221209-131830.jpg
    351.4 KB · Views: 68
  • Screenshot_20221209-131956.jpg
    Screenshot_20221209-131956.jpg
    103.1 KB · Views: 65
  • Screenshot_20221209-132005.jpg
    Screenshot_20221209-132005.jpg
    199.7 KB · Views: 62
  • Screenshot_20221209-132017.jpg
    Screenshot_20221209-132017.jpg
    207.8 KB · Views: 61

pndwal

Senior Member
I'm trying to make Paytm Tap to pay work using Mod2.. But still no luck.

Check the screenshots.
You may be missing the point of this module.

It's simply to allow you to pass PI deviceIntegrity when you don't!... If you already pass, updating won't help you further (except that it does help OnePlus and some other device users with other issues however, but I believe only if running A12+ w/ official USNF which combination can break fingerprint scanners etc; the @Displax mod builds some updated fixes for these devices/issues connected with spoofing props), and in your case running A10, it may not be needed at all as many devices pass PI deviceIntegrity w/ A10 or less and official USNF...

To put it simply, if you weren't passing deviceIntegrity before installing, then the @Displax USNF mod/fork is doing its job perfectly... There are simply other detected traces of root or apps, folders or other signals associated with custom modding that are being detected by your app and need addressing...

The basics are:
- Zygisk = Yes on Magisk home screen.
- (Bank/other) app in denylist. (Enforce DenyList enabled.)
- PI deviceIntegrity passing.
- Full Magisk App replaced with hidden stub App

Next things to try:
- Shamiko module. (Enforce DenyList disabled.)
- LSPosed module and configure Hide My Applist Xposed module properly.
- Check for and remove/rename folders associated with TWRP etc.
- Run detection apps like Momo to determine what else may be detected on your device...

Nb. Clear app's data after any detection/failure and before any new test...

Hope it helps. 🙂 PW
 

pndwal

Senior Member
Google? The company that made the phone? Isn’t it software?
Very low level firmware... Looks like broken droidguard implementation to me, but OEM is responsible to implement keymaster functions...

Rog Phone 3 seems to be unique in allowing strongIntegrity to pass (specifically AVB always reports Device Locked = True / Bootloader Locked)...

Many others have broken keymaster implementations, most famously OnePlus, and I'm not aware of any that have been fixed with updates!... This appears, at least in part, to be the reason for Google's apparent whitelisted-device based system of bypassing hardware based verdict enforcement which, of course, is the only reason we can thwart integrity attestations on our modded devices!... 😛

It seems that the recent emphasis on Google projects like Treble, Mainline and others, with all their GSI/GKI/other complexities (ostensibly to address fragmentation and improve compatibility for Long-Term Supported updates, uninhibited Android platform release upgrades, ability to contribute kernel changes back to upstream Linux etc) may also be to facilitate easier fixes for broken / buggy droidguard, keymaster implementations, Widevine DRM, generic TrustyTEE or custom TEE OS and any number of other critical firmware components however... Time will tell, but it's precisely the time all this takes that is giving modders the extra leases-of-life we are enjoying!...

I, for one, am in no hurry to see such 'issues' fixed! 😁 PW
 
Last edited:

Top Liked Posts

  • 4
    You just need to edit the service script after installing the module.
    No need to edit, this change already present in my MOD
    1
    Wow, yes... We have a major problem Huston...

    I Hadn't noticed this till two days ago... Google Wallet was working for contactless payments at lunch, but for coffee afterwards it failed with 'device doesn't meet security requirements'... 🙁 (FWIW, I may have rebooted phone during lunch...)

    Checked and deviceIntegrity was good, but immediately after a reboot got failed verdict and minutes later all is good again...

    FYI Google Pay/Wallet somehow monitors device security even while app is closed (likely Google gets telemetry if lockscreen pattern/password is removed, deviceIntegrity is lost, etc), and contactless fails on next use... This occurs after bad device integrity verdicts, or if a user disables lockscreen pin or pattern... even if this is restored before opening Google Pay/Wallet, bank cards may have already been removed... So even brief loss of deviceIntegrity at startup is catastrophic for G Pay / Wallet! 😬

    To avoid intermittent Play Integrity failures I've reverted to @Displax modded USNF also; all seems good and can't reproduce failed verdict...

    To fix G Wallet however, despite knowing it would likely just come right in about a week, I tried the immediate fix as it's worked for me in the past:

    ...Bit of a saga begins...

    Uninstalled wallet, cleared Google Pay and Google Play Services data, rebooted, installed wallet again only to get the familiar "Google Pay is Currently Updating..." Screen that never goes away! .... No problem... I covered a fix for this in "Current fixes needed for Google Pay / Wallet" linked here:
    Post in thread '[Discussion] Google Pay Magisk Discussion Thread' https://forum.xda-developers.com/t/...agisk-discussion-thread.3906703/post-87481637

    ... Tried both clearing data and rebooting as well as uninstalling/reinstalling and nothing worked this time!... Still stuck on updating screen!

    Finally resolved after removing all Play Store and Play Services updates, clearing their caches only, uninstalling Google Pay (even latest version doesn't show as 'Wallet' until online 'App is updating...' completes), rebooting, re-installing Google 'Wallet' --> Finally G Pay opens and updates to Wallet successfully!... No more security issue for contactless payments since reverted to @Displax modded USNF... 🙂

    ...End of Saga...


    But this part-time spoofing based on new hooks is only for fingerprint prop mismatch (for some devices on Google's list for HKA based verdict enforcement in PI API) AFAIK ... My device (Xiaomi RedMi Note 8T w/ stock MIUI A10) like many A8, 9 & 10 devices, actually needs none of the three prop based bypasses we now have to pass either S/N or PI deviceIntegrity; I do need the principal broken keystore based fallback to Basic attestation to pass these however...

    Because of this, I think the issue is something other than temporary fingerprint prop spoofing... Could it be that the fake keystore is registered so late that I can run Play Integrity API Checker before it breaks HKA?...

    Anyone else had G Pay/Wallet failing after installing USNF 2.4.0?...

    👀 PW

    Yes sir. Same here - Uninstalled GW, wiped Google Store and Play Services. Disabled 2.4.0, pulled the modded version from @Displax and installed then rebooted. Downloaded GW - Added cards and all good. For now...
    1
    I wasn't able to add bank card to the Wallet.
    Using Magisk Alpha which is hidden,
    Google Play Services and Google Play Store added to DenyList,
    Shamiko and Universal SafetyNet Fix 2.4.0 are installed,
    Play Integrity API Checker says Device and Basic Integrity pass,
    YASNAC says Basic integrity and CTS profile match both pass
    I have clear data for Google Play Services, Google Play Store and for Wallet, phone rebooted but still getting: "Couldn't finish setup to pay in stores. This phone can't be used to pay in stores"

    Then I have uninstalled USNF 2.4.0, reboot, installed safetynet-fix-v2.3.1-MOD_2.1.zip and finally bank card added to the Wallet.
    1
    Hey.
    So with all modules (including USNF) the safetynet and PI Integrity shows "Not passed" (Duh).
    The MOMO shows just that it found the SU folder and detected Magisk.
    When everything excluding the @Displax modded USNF is turned off (and also Play Services data cleared) the results are on the screenshots below. Note: Deny list is enforced and only Google Wallet and some banking apps are added, nothing more.
    YASNAC passes with flying colours. The device integrity in 2 apps fail to be checked and return UNEVALUATED results. Json is also attached.
    What's baffling is that even now, the Google Wallet worked (I checked it now in the supermarket terminal).
    Yes, I missed something in JSON... While Unevaluated results DO NOT apply to deviceIntegrity as I mentioned already (These are for appIntegrity - appRecognitionVerdict and accountDetails - appLicensingVerdict ... These are different signals from deviceIntegrity within the new Play integrity verdict), I'm no longer sure deviceIntegrity is actually supplying a proper response since while documentation says "device_recognition_verdict can have one of the following labels:
    MEETS_DEVICE_INTEGRITY
    No labels (a blank value)
    MEETS_BASIC_INTEGRITY
    MEETS_STRONG_INTEGRITY
    MEETS_VIRTUAL_INTEGRITY"
    the value"deviceRecognitionVerdict": generally appears before labels, and that is missing altogether...
    https://developer.android.com/google/play/integrity/verdict#device-integrity-field

    Of course a blank value is really No label as seen above, so
    "deviceIntegrity": {},
    may still be a properly evaluated response... I'm just not sure...

    I'm still leaning towards the latter being the case, but I'm equally confused by working Wallet/contactless payments...

    do JSON results change now modules are removed w/ a flush of Play Services data?

    Nb. If deviceIntegrity correctly = blank/no label, this is what is indicated:
    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).

    and it is clearly a more sensitive detection than old basicIntegrity for S/N... and this is why I mentioned:

    Anyway, it seems something is now breaking PI's more sensitive basicIntegrity verdict... Again, please report check w/ all modules disabled except USNF... This user also had passing S/N but failing PI basicIntegrity due to modules on OnePlus 7 device w/ stock ROM:
    https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-87891641

    Also, please check your selinux status is enforcing regardless of results disabling modules... (Are you a viper4android user?)... PW
    Apart from permissive SELinux, you may break system partition/digest checks if you have ever run ANY system mods (even changing simple file permissions), eg twrp flashable mods etc, and even if you have fully reverted these, on current ROM... If you suspect this, flashing system again should fix...PW
    1
    I wasn't able to add bank card to the Wallet.
    Using Magisk Alpha which is hidden,
    Google Play Services and Google Play Store added to DenyList,
    Shamiko and Universal SafetyNet Fix 2.4.0 are installed,
    Play Integrity API Checker says Device and Basic Integrity pass,
    YASNAC says Basic integrity and CTS profile match both pass
    I have clear data for Google Play Services, Google Play Store and for Wallet, phone rebooted but still getting: "Couldn't finish setup to pay in stores. This phone can't be used to pay in stores"

    Then I have uninstalled USNF 2.4.0, reboot, installed safetynet-fix-v2.3.1-MOD_2.1.zip and finally bank card added to the Wallet.
    Thanks for your experience/confirmation per recent discussion here!... My initial experience here:
    https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88049087

    👀 PW
  • 19
    While we still waiting official public release of 2.4.0, i am compiled this version myself from latest source.
    So if you can't wait to try - you are welcome :)

    Public release is up. Use it instead.
    14
    Public release of v.2.4.0 now available.

    12
    OP and thread title have been updated in order to reflect the latest changes.
    Cheers
    10

    Latest Universal SafetyNet Fix (yup, no name change yet... by June? 😝) Release notes:​


    v2.4.0 (early access)
    Pre-release

    Highlights​

    • Play Integrity bypass without breaking device checks or causing other issues
    • Disabled use of hardware attestation on Pixel 7 and newer (@anirudhgupta109)

    Other changes​

    • Updated instructions for newer Android and Magisk versions
    • Better debugging for future development
    It's taken a while to find way to bypass Play Integrity that doesn't require spoofing the build fingerprint permanently, but I wanted to make sure this module doesn't cause any unnecessary breakage. Just like the original goal of Universal SafetyNet Fix, this minimizes adverse effects by spoofing dynamically at runtime only when necessary. Enjoy!

    👍 PW
    7
    /me waits for the usual people asking the forum elders via PM for copies of the early access module....because its happened before

    hint: most of us wont/dont have it, so dont do it, any one asking will be reported and get a nice little holiday if not their account closed as this counts as requests for warez....just a tip

    everyone will get a copy free when kdrag0n feels like releasing it widely....no one will die if they dont have it right now
  • 291
    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 custom ROMs instead of injecting code with a Magisk module. See the ProtonAOSP website for more information.

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

    Latest release
    v2.4.0

    Highlights
    • Play Integrity bypass without breaking device checks or causing other issues
    • Disabled use of hardware attestation on Pixel 7 and newer (@anirudhgupta109)
    Other changes
    • Updated instructions for newer Android and Magisk versions
    • Better debugging for future development
    This version only supports Zygisk (Magisk 24 and newer).

    It's taken a while to find a way to bypass Play Integrity that doesn't require spoofing the build fingerprint permanently, but I wanted to make sure this module doesn't cause any unnecessary breakage. Just like the original goal of Universal SafetyNet Fix, this minimizes adverse effects by spoofing dynamically at runtime only when necessary. Enjoy!

    If you found this helpful, please consider supporting development with a recurring donation for rewards such as early access to updates, exclusive behind-the-scenes development news, and priority support.
    Alternatively, you can also buy me a coffee. All support is appreciated ❤️

    Source code
    188
    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 2.1:
    Hide "Enable OEM Unlock" setting

    Updated 2.0:
    Bypassing DEVICE_INTEGRITY for devices that shipped with Android 13+ (Pixel`s 7 )

    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
    31
    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!