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.
-
9New huge update for the Xposed module, also now the repo it's in LSPosed repo so it will appear in LSPosed app. You will want to install it
GitHub - swer45/AttestationSpoofer: Xposed module that spoofs a fake root of trust in local attestations
Xposed module that spoofs a fake root of trust...
github.com
As you can see, now the module will spoof a locked bootloader with a verified boot state in RootOfTrust. This should work in all devices that have a TEE or StrongBox. If someone crash tag me and I will try to fix it.
Also I'm working in Magisk module (Zygisk), but it's difficult XD.7GitHub - chiteroman/AttestationSpoofer: Xposed module that spoofs a fake root of trust in local attestations
Xposed module that spoofs a fake root of trust...
github.com
5
'Hate' is a strong word!...
Anyway, when the original CyanogenMod bundled all proprietary GApps for one thing, Google issued their infamous "Cease And Desist" order and Steve Kondik thought his baby was dead!...
However Google were quick to clarify that although custom OS's could not legitimately bundle GApps (Nb. other ROMs still do), users are welcome to 'sideload' the same (as devices themselves are generally certified through CTS while custom ROMs are not)...
So OpenGapps was formed to offer legitimised seperate packages, Steve continued with CM project, users continued to use vanilla CM (and later LOS) with proprietary Google Apps, and all in the custom mod world was sweet again...
Of course Google must have realised they nearly shot themselves in the foot with that action, but they scrambled to offer a solution / compromise that wouldn't result in the death of CM or custom ROMs as we know them...
I think the Lineage team simply see that Google is actually the custom modders benefactor and is (in reality) supportive of them and custom mods/ROMs in general if Devs play by the rules, and LOS is simply willing to do so...
Also, they are in the best position to get their custom ROM approved/certified in future (see my post above) by being careful 'not to subvert Google's security model' by tampering expected signals... Note that Magisk now follows this same policy, and I think that's not just because John is a Googler now; it's also a sign of his maturity as a responsible dev...
And ensuring that the main custom mods (ROM, root/overlay framework) comply in no way prevents "those passionate about hiding" from "doing their job"!... Both history and you are proving that.
Personally I think LOS is great and follows a great tradition! PW5
With this module you can start the CIB Egypt Mobile Banking which is the only app I know they check if you have an unlocked bootloader. Enjoy
5
I updated the Xposed module with better hooking method to don't affect another apps. This afternoon I will work in Zygisk module, I will try to do it. -
324Universal 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 code222So, 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/dev33So, created separate thread for my mod. Welcome)
[MODULE] [MOD] Universal SafetyNet Fix
Universal SafetyNet Fix [MOD] Magisk module...
forum.xda-developers.com
31Folks, 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... PW
New posts
-
-
-
Hard Bricked oneplus 8t not starting EDL mode
- Latest: TheNewHEROBRINE
