Can the file be named to something else and XPL still function properly? Does another portion of the app need to be changed to then route things to the renamed folder?A number of modules will break basicIntegrity even for S/N API, more for PI API... Some configurations in modules like XPrivacyLUA will also break ctsProfileMatch etc... Disabling all modules other than USNF is the correct approach for diagnosing issues...
Nb. Banks often detect XPrivacyLUA even after uninstalling as it doesn't clean up properly... Remove data/system/xlua folder to prevent this detection...
PW
MAGISK MODULE ❯ Universal SafetyNet Fix 2.4.0
- Thread starter kdrag0n
- Start date
So you mean folder/directory?... I don't know... Hardly used XPrivacy... Doubtful however... PW
Just a note that as of version 3.19.0 they seem to disable the protection. Probably due to many false positives according to the reviews.Yes, but you have to uninstall UNSF and give up official magisk. Also even you switch to another unofficial magisk, installing USNF will make it detects again. That's your choice ¯\_(ツ)_/¯
Also check this:
[Suggestion] Bypass Safetynet without using resetprop · Issue #253 · kdrag0n/safetynet-fix
We have few apps that detect dirty props change done by Magisk resetprop. This will make it is impossible to use these apps and make Safetynet passed on stock ROM. We need to change necessary props...github.com
I attached the last version I have (3.17.0) that still have the protection enabled just in case it can be used for further investigation.
Moving this here:
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:
Hope it works for you and please report your results...
PW
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...Wow, yes... We have a major problem Houston...
...
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...
Hope it works for you and please report your results...
PW
Last edited:
Thanks, why ask your own question when you can just snag something else'sMoving 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...
Anyway, cleared gpay & play cache this morning and about an hour later, after 2 days, it was working. Added the cards back and everything seems to be fine.
Thanks again
Last edited:
Answered really many times - the USNF removes GMS from DenyList deliberately and from the beginning of the module's development.
It has nothing to do with the issues you have now with Wallet
You can open USNF scripts and find the code where it removes GMS.
You can find how and why also on the GitHub and in the posts in this thread
Last edited:
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
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
Last edited:
For what it's worth, I found disabling Shamiko and turning on enforce denylist seems to have fixed it for me over the past few days.
Doubtful it'll fix sparodic fails; USNF doesn't rely on either for hiding normally...
I've just done this:
1) Fixed G Pay/Wallet installation
2) Put gms attestation/droidguard and main gms processes (main process not actually needed for my device w/ Magisk path = /sbin but shouldn't hurt) in denylist (NOT enforced) with Shamiko working in blacklist mode...
Nb. This won't work with DenyList functioning, but persists/works w/ Shamiko thanks to @ipdev's Only remove gms if Denylist is enforced commit.
... in case the issue is with USNF root hiding... This way Shamiko will be the second watchman...
I'm not confident this will fix failures (may not be a hiding issue as discussed) but so far so good with this configuration.
PWWhat is gms attestation/droidguard listed under?Doubtful it'll fix sparodic fails; USNF doesn't rely on either for hiding normally...
I've just done this:
1) Fixed G Pay/Wallet installation
2) Put gms attestation/droidguard and main gms processes (main process not actually needed for my device w/ Magisk path = /sbin but shouldn't hurt) in denylist (NOT enforced) with Shamiko working in blacklist mode...
Nb. This won't work with DenyList functioning, but persists/works w/ Shamiko thanks to @ipdev's Only remove gms if Denylist is enforced commit.
... in case the issue is with USNF root hiding... This way Shamiko will be the second watchman...
I'm not confident this will fix failures (may not be a hiding issue as discussed) but so far so good with this configuration.
It's the gms (Google Play Services) com.google.android.gms.unstable process that John referred to as the "SafetyNet" process...
It is now evident that this is more correctly termed an "Attestation / Droidguard" service.
Technical
Since S/N is now deprecated it's evident that the process is not API dependant... Also, reversers have recently revealed that it actually performs the handshaking between gms and DroidGuard, which is the actual attestation engine responsible for collecting many of the measurements (not all, but is responsible for the hardware keystore backed signals and more) that gms sends to Google's back end servers.
From Romain Thomas's whitepaper (Note this was written while SafetyNet was the only Device Integrity API available so still refers to many attestation functions as 'SafetyNet' functions):
https://www.romainthomas.fr/publication/22-sstic-blackhat-droidguard-safetynet/
PWMaybe 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.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...
Started problem today and made all procedures including v2.3.1-MOD_2.1 and no solution. CTS profile match fail. (Mi9 with EvoX 13)
Thanks updated play services and now I'm on 23.03.13. CTS now fails so I guess same as you?
JakeDHS07
Senior Member
Yup looks like there's gonna need to be an update 
. It's a damn good thing I don't need or use NFC hardly ever and just do this for fun otherwise I'd be very annoyed.
. It's a damn good thing I don't need or use NFC hardly ever and just do this for fun otherwise I'd be very annoyed.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
Last edited:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
4For those using Canary builds
Please be aware that in 25207+ major refactoring (of selinux rule patching) has broken many modules etc... This is likely the cause of issues with hiding using recent builds as Shamiko is affected... Please see discussion in Magisk Discussion thread...
You could revert to 25206 or wait for fixes hopefully in 25211... PW3
With Integrity and CTS do you refer to the deprecated SafetyNet or the 'new' Play Integrity API?so I'm on android 13, pixel 6a. Got Integrity
and CTS match and also Play Store as Certified. Although, still no google pay or banks access. Any hints to get this working or it this fix not fully functional on 13 as of yet?
Thanks!
Also, are you using USNF from this thread or the newer/better safetynet-fix-v2.4.0-MOD_1.2 from the other thread?
Look into the other USNF thread from Displax and find more info in the thread about GPay
Btw, banking apps do not rely only on PI API - they try many other detections od root, hence you might need (things vary from app to app) Shamiko, Hide My Applist or even the Magisk Delta fork
The best would be to search through the Magisk related threads here on XDA, how the other user(s) solved the root detection from your particular banking or similar app3
Yes! I was trying to find the link for that mod. This worked. Thanks!
2
It may help for us to know the app to see if anyone successfully bypased it. Remember that this is a race between a variety of different banking app developers and usnf developers. Both are trying to catch up with eachother, so my second question is have you tried the current displax fork of usnf (2.4.0 mod 1.2)?
As to your question alot of them are check for system changes, or even custom os,. But it depends on what you do with root. i use adaway which changes hosts and need systemless hosts and specifically use usnf for allowing netflix you do need magisk (or some root) for any SN or PI passing (such as usnf),i believe.2
... Unless using a custom ROM that integrates SNF (or own prop/signal spoofing)... Many do this... Some like official LineageOS never will...
While I prefer a 'clean' ROM like official LOS and to add-on Magisk and modules for integrity attestation fixes, integrated fixes in ROMs may actually be better when user doesn't intend to use Magisk/root (@kdragOn gives guides - two options - for Devs and develops SNF for native use in his Proton ROMs)... These ROMs have props and other spoofed signals set in /system and need no /system overlays (ie. Magisk mask) or code injection using hooking frameworks like Zygisk or Riru which present their own hiding challenges...
The issue is really the priority maintaining Devs give to keeping up with ever changing Google integrity attestation API standards and server-end changes in measurements and algorithms used for verdicts... USNF has traditionally been quick to implement fixes, and independent Devs like @Displax have been able to pick up the slack when @kdrag0n has been otherwise occupied... Some ROM Devs are diligently watching these developments and update their native fixes soon after USNF builds overcome changes, but others are slow... There are still custom ROMs that integrate SNF for SafetyNet but haven't yet included fixes for PI deviceIntegrity...
This means that when there is significant lag with updates for integrity attestations in a ROM, users may need to install Magisk & a USNF build... This can work depending on both ROM SNF and USNF Dev implementations, but can also lead to failure/conflicts as has been seen recently...
If a user adds Magisk to ROMs having built in SNF and the fix is up to date and working, no USNF module should really be added... All that will be required is adding the attestation/droidguard gms process and for most A11+ devices the main gms process (ie. com.google.android.gms.unstable and com.google.android.gms in Google Play Services) in denylist to hide Magisk/root from Google Mobile Services as the ROM handles the rest...
PW -
315Universal 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)
- Updated instructions for newer Android and Magisk versions
- Better debugging for future development
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 code215So, here is my modification of USNF with Play Integrity API bypass.
It changes fingerprint to old7.1.26.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 3.0:
No words needed, you understand everything yourself
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/integrity58So, here is my new modification of USNF with Play Integrity API bypass.
It is now based on top of original v2.4.0 codebase instead of v2.3.1, with adding new hiding algorithm for current realities and some code refreshing.
Changelog:
Version 1.2
* Fix crash and endless tests loop/failing on Android < 9.0 (bug from original version 2.4.0).
* Do not unpatch (revert) changes. To prevent possible tests failing after a while on some ROMs (cross conflicts).
Version 1.1
* Fix KeyStore hook desynchronization (tests randomly failing problem).
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.
Source code: https://github.com/Displax/safetynet-fix/tree/dev31Folks, 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...
:
Here's hoping... PW29So, created separate thread for my mod. Welcome)
[MODULE] [MOD] Universal SafetyNet Fix
Universal SafetyNet Fix [MOD] Magisk module...
forum.xda-developers.com
New posts
-
Development [ROM][13.0_r30][OFFICIAL] Evolution X 7.6.2 [03/05/2023]- Latest: underworld737
-
-
-
Development [ROM][13][raven] riceDroid 10.1[AOSP][PIXEL][UNOFFICIAL]- Latest: rayraycarter4