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,320
2,428

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,230
5,874
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
    Interesting fork of a very experimental fork of @Displax's fork of official USNF!... 😃 😜 PW
    Brutal commit log... If it is real it looks fake/spam as hell. I wouldn't trust giving that thing zygote access on my device...

    3
    Hi, I was having problems passing CTS Profile Match today.
    Device: Pixel 7 Feb Update
    Tried v2.4.0 and v2.3.1-MOD_2.1 without success.
    This last module have worked for me, hope for your devices too!
    Interesting fork of a very experimental fork of @Displax's fork of official USNF!... 😃 😜 PW
    2
    Maybe I am doing something wrong but I followed this process but I am unable to add cards to gpay/wallet. Any thoughts? I'm on a pixel 6a Feb 2023 update.
    I've needed to wipe data for Play Store , Wallet/Pay and Play Services at least but twice even that wasn't enough; removing all updates for Play Store , Wallet/Pay and Play Services also, rebooting (very important) and starting fresh fixed it... 😬 PW
    2
    Better ping the member:

    😶

    ... Did you see any especially suspect commits?... Just tooo many since Dec... Seems to be trying to do all kinds of root hiding (Shamiko's job) too...

    But security is the big issue for sure... PW
    Nah just judging by the repetitious and nonsensical commit names. It's chaos. I mean look at this page of them: https://github.com/Jukmisael/safety...&branch=myfix&qualified_name=refs/heads/myfix
    1
    Moving this here:



    Nice interception of that ball! 😉

    Yup, the method I previously posted in G Pay Magisk Discussion thread didn't work for me either this time...

    Not sure it will clear w/o intervention... Try what I wrote in this thread... May need to clear updates, caches and uninstall G Pay again before rebooting and reinstalling as mentioned in last paragraph re. my recent saga:

    Be sure to do the reboot or you may need to go through hoops to get other issues fixed even if G Pay updates to wallet and works again, eg Activity list never populates issue...

    Hope it works for you and please report your results...

    🤠 PW
    Maybe I am doing something wrong but I followed this process but I am unable to add cards to gpay/wallet. Any thoughts? I'm on a pixel 6a Feb 2023 update.
  • 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
    8
    Folks, a number of members have reported intermittent failures for G Pay/Wallet security checks even with @Displax modded USNF builds, and I can confirm that after a good run this has also occurred on my device:
    https://forum.xda-developers.com/t/...agisk-discussion-thread.3906703/post-88100463

    It seems that @Displax modded USNF builds may be more consistently maintaining deviceIntegrity, but that there may have been some Google change that trips detections sporadically... 🤔

    Clues:

    I only have a few clues, but I believe we can eliminate Prop-based device ID bypasses because my device (Xiaomi RN8T) doesn't require any of the 3 prop-based device ID bypasses for Google's hardware-based verdict enforcement for devices they identify that way...

    So I wonder if Fake keystore-based attestation type fallback can kick in late or otherwise fail. This is doubtful because I haven't seen any Zygisk failures and believe the code for fake keystore registration in gms is injected at boot-time so hardware attestation data delivery should remain broken as fallback trigger... I may be missing something here however...

    This leaves the module's setting of new sensitive prop values and consistent hiding of root from gms attestation/droidguard process (Nb. my device has /sbin as magisk tmpfs mount path) in doubt.

    I suspect the issue may lie with the modules root hiding implementation for gms, but this is only an educated guess at best and the fact that those on custom ROMs w/ SNF but w/o USNF are reporting the same issue (not sure if any w/o Magisk have reported yet) might indicate that it's not this...

    This one may be a doozy to diagnose... Hold on to your hats... And plastic cards... 🙃 PW
    6
    @Displax hello.

    Should we still use your mod from here https://forum.xda-developers.com/t/...tynet-fix-2-4-0.4217823/page-91#post-87198517

    Or the new 2.4.0 update includes your fixes and should be the only option from now on?

    Perhaps i shouldnt need to explain deductive reasonsing (top down logic), but ill have a crack :)

    Read the last few posts and decide if you think the issues reported so far (font/overlay modules) affect you

    If Yes, use 2.3.1 Mod 2.1 for now
    If Not, use latest
    6
    HI!!!
    Im installed last SafetyNet 2.4.0 and if i put google services in deny list i get "HARDWARE_BACKED" but if i reboot my phone google services gone from deny list and then my SafetyNet pass...how i can fix pls???
    That is correct if you you have the Magisk DenyList Enforcing. 🙃
    kdrag0n - safetynet-fix - [GitHub] - commit

    When Enforcing, Magisk is disabled and restores as much as possible while the processes on the denylist are called.

    If you add any one part of "Google Mobile Services" (com.google.android.gms) to the denylist, Magisk will revert all changes possible when the process is called.
    In other words, the Zygisk part of this module will not be active while GMS is called.​

    I will let pndwal explain it more since he better at explaining things than I am. 😊
    Over to you @pndwal. 😁

    If you are not Enforcing the denylist, then this is an issue. :unsure:

    Cheers. :cowboy:
  • 295
    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
    190
    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!