MAGISK MODULE ❯ Universal SafetyNet Fix 2.4.0

Search This thread

badabing2003

Recognized Contributor
Sep 17, 2012
1,579
1,860
Hulu isn't available: "This app is not compatible with your device"
Is it possible that the device is identified something other than Pixel5a and the app is not compatible with that specific device.
I have seen people complain that with the SNF sometimes Three device is recognized as Nexus or something really old.
Somehow it does not happen to all.
Check your device at Google and see if it sees it correctly?
Perhaps uninstall SNF, reboot, and reinstall.
Just an idea.

Update, somehow I missed the last few responses,
All good then
 
  • Like
Reactions: V0latyle

pndwal

Senior Member
Settings > Apps > Google Play Protect Service
That's interesting... I've never seen this... I get:
IMG_20221122_135746.jpg

IMG_20221122_141439.jpg

IMG_20221122_140830.jpg

but don't appear to have Google Play Protect Service app... 🤔

What Play Store version do you have? PW
 
Last edited:

zgfg

Senior Member
Oct 10, 2016
8,210
5,843
Xiaomi Mi 11
Xiaomi Mi 11 Lite 5G
All Apps > 3 dots > Show System
Xiaomi, A12

I have five apps and services containing the word Play in the name (including system ones - otherwise Google Play Services will not show), but none with the name Google Play Protect Service - screenshot(s)

And I've never seen that one

Please provide its package name?

However, I've found something about:

and accordingly, the package name seems should be:
com.google.android.odad

but I don't have a package with that name installed

Actually, I've searched in the Terminal emulator for all similar packages by:
su
pm list packages -f | grep protect
pm list packages -f | grep play
pm list packages -f | grep services
pm list packages -f | grep odad
...


and it finds Google Play Store app, Google Play Services app, etc, but nothing like Google Play Protect Services

Btw, do you happen to have Pixel (and maybe Android 13)?

PS: Google Play Protect Service can be found on ApkMirror
 

Attachments

  • Screenshot_2022-11-22-06-38-36-992_com.miui.securitycenter-edit.jpg
    Screenshot_2022-11-22-06-38-36-992_com.miui.securitycenter-edit.jpg
    297.3 KB · Views: 93
  • Screenshot_2022-11-22-07-26-24-035_sarangal.packagemanager-edit.jpg
    Screenshot_2022-11-22-07-26-24-035_sarangal.packagemanager-edit.jpg
    194.4 KB · Views: 93
Last edited:

pndwal

Senior Member
Xiaomi, A12

I have five apps and services containing the word Play in the name (including system ones - otherwise Google Play Services will not show), but none with the name Google Play Protect Service - screenshot(s)

And I've never seen that one

Please provide its package name?

However, I've found something about:

and accordingly, the package name seems should be:
com.google.android.odad

but I don't have a package with that name installed

Actually, I've searched in the Terminal emulator for all similar packages by:
su
pm list packages -f | grep protect
pm list packages -f | grep play
pm list packages -f | grep services
pm list packages -f | grep odad
...


and it finds Google Play Store app, Google Play Services app, etc, but nothing like Google Play Protect Services

Btw, do you happen to have Pixel (and maybe Android 13)?

PS: Google Play Protect Service can be found on ApkMirror
Good share! 👍

The XDA article indicates it's still rolling out seperated Google Play Protect Service and reportedly it has only hit A12+ devices to date (I have only A10 + A11 devices at present)... It'll be one to watch...

Old integrated Play Protect seems to be still using S/N API... I'm wondering if Play Protect calls new PI deviceIntegrity for device certification... If so, I'm guessing (as I've indicated previously) Google will probably wait for banks to pre-empt any move to strongIntegrity...

No doubt if this service does use PI API, both the Device intgrity and the additional available PI payload responses (Application integrity and Account details) will be useful in combination with scans for harmful software / malware... Nb. The additional responses were a major reason for overhauling the original S/N API... PW
 
  • Like
Reactions: 73sydney and ipdev

cbomb1337

Senior Member
Jan 22, 2019
219
59
melbourne
OnePlus 7
OnePlus 7 Pro
Been having this issue since day 1 on my Pixel 7 trying to have root and contactless working side by side. Whenever I flash the USNF MOD 2.0 via Magisk, I gain the ability to pass 2/3 integrity checks, however I lose the ability to enter my Google settings page (clicking on settings -> Google does nothing), and GPay stops working altogether - cannot access the "wallet" section. I have tried flashing USNF MOD 2.0 then going into airplane mode, clearing cache for Google Play Services, Google Play Store and GPay, rebooting and deactivating airplane mode.
This also hasn't worked. Does anyone have any idea as to what is going on here? It looks like some conflict with a Google service, but have no idea how to troubleshoot it.
Thanks in advance!
I get a weird issue like that when installing the universal safetynet fix I lose my google wallet and it reverts to gpay. I wonder why. I'm using Pixel 6 I have yet to test if the tap and go g pay if it works ill try it today.
 

pndwal

Senior Member
Been having this issue since day 1 on my Pixel 7 trying to have root and contactless working side by side. Whenever I flash the USNF MOD 2.0 via Magisk, I gain the ability to pass 2/3 integrity checks, however I lose the ability to enter my Google settings page (clicking on settings -> Google does nothing), and GPay stops working altogether - cannot access the "wallet" section. I have tried flashing USNF MOD 2.0 then going into airplane mode, clearing cache for Google Play Services, Google Play Store and GPay, rebooting and deactivating airplane mode.
This also hasn't worked. Does anyone have any idea as to what is going on here? It looks like some conflict with a Google service, but have no idea how to troubleshoot it.
Thanks in advance!
Looks like your enquiry may have fallen through the cracks here... Sorry!

Did you get it sorted?

Nb. Clearing cache is usually not enough for such a scenario... always clear data, or do so if cache clearing fails...

Clear data for the three apps you mentioned (but may incl. Google Wallet now instead of Google Pay) and reboot before first trying G Play/Wallet again (nb. rebooting first is critical or you may have persistent issues w/ Activity list/other later)...

I put details on this here:
https://forum.xda-developers.com/t/...agisk-discussion-thread.3906703/post-87481637

If this doesn't help it may be a P7 or P7 series / A13 launch version specific issue with latest prop mismatch based hardware verdict enforcement bypass added in @Displax's USNF mod 2... I haven't seen such an issue mentioned, but users / OP in this thread will likely have the best advice:
https://forum.xda-developers.com/t/unlock-bootloader-root-pixel-7-pro-cheetah-safetynet.4502805/

🤠 PW
 

pp085ster

Senior Member
Sep 5, 2010
352
101
Santa Cruz
Google Pixel 7
Looks like your enquiry may have fallen through the cracks here... Sorry!

Did you get it sorted?

Nb. Clearing cache is usually not enough for such a scenario... always clear data, or do so if cache clearing fails...

Clear data for the three apps you mentioned (but may incl. Google Wallet now instead of Google Pay) and reboot before first trying G Play/Wallet again (nb. rebooting first is critical or you may have persistent issues w/ Activity list/other later)...

I put details on this here:
https://forum.xda-developers.com/t/...agisk-discussion-thread.3906703/post-87481637

If this doesn't help it may be a P7 or P7 series / A13 launch version specific issue with latest prop mismatch based hardware verdict enforcement bypass added in @Displax's USNF mod 2... I haven't seen such an issue mentioned, but users / OP in this thread will likely have the best advice:
https://forum.xda-developers.com/t/unlock-bootloader-root-pixel-7-pro-cheetah-safetynet.4502805/

🤠 PW
Issue turned out to be due to a custom font I was using. Here's what ended up working for me to be able to continue using a custom font as well as get gpay working simultaneously. Thanks!
 
  • Like
Reactions: 73sydney and pndwal

73sydney

Senior Member
I noticed the safety net modules seem to make my play services use alot more cpu is that normal. I tested it by removing the module and clearing play services data and it fixed it.
i dont see that here, Pixel 6 Pro

had you tested and were you passing Integrity Test

because i could see if you hadnt and play services was banging around in the background failing that *might* explain it - if that were true, id do the perennial advice...put the device in airplane mode, clear data for Google Play Services and Store, reboot, toggle airplane mode off and test again
 
  • Like
Reactions: pndwal

cbomb1337

Senior Member
Jan 22, 2019
219
59
melbourne
OnePlus 7
OnePlus 7 Pro
After testing for a week this module by displax and husky dg on my p6 it eats my battery up. Google play services gms goes crazy. It sometimes stops draining when I was tinkering with components of the app but ended up going back to draining heavy I remove module and draining stops. I reflashed rom and flashed module and drain comes back. It also removed my google wallet and brings gpay app back. Not sure if it works I tried it days ago using zip pay and it worked and tried my bank card yesterday and it failed.
 
Last edited:

Top Liked Posts

  • 2
    On Google Pixel 5, I installed january update last weekend. Since today only, I can't pass integrity check anymore.

    I followed V0latyle and Homeboy76 guides, tried with Kdrag0n(2.4) and Displax's (3 available versions) modules. Each time I flashed in Magisk then wiped Play Store, Play services and Wallet cache and data.

    Deny list is configured but not enforced since I use Shamiko. I tried both ways tho, but unsuccessful in both.

    No changes in my modules since I updated so I don't think one of them caused it, but here's the lists:

    My modules in magisk are
    - AOSP Mods Full 2.6.0
    - Builtin Busybos 1.0.4
    - Debloater 17.3.3
    - Magisk Bootloop protector 1.5
    - mindetach 2.3
    - Shamiko 06
    - Universal SafetyNet Fix 2.4.0 (Kdrag0n)
    - Youtube Revanced 18.03.36
    - Zygist Lsposed 1.8.5 mod

    In Lsposed, modules are :
    - AOSP mods
    - Let me downgrade
    - UniversalAuth
    - UpdateLocker
    - XprivacyLUA

    Any idea what I'm missing and what could be a fix?
    Try uninstalling xprivacylua and delete all the folders it created in system and sdcard. That was what tripped integrity checker for me before
    2
    Holy Moly you made me happy!

    I didn't find any folder to delete, but first try with Displax latest mod + clear data from Play Store, Play service and Wallet did the job.

    I reinstalled XprivacyLUA, so far so good 🤞 Still have to go out and test the wallet.

    Thanks Captain! May I ask how did you find out?
    I tried everything and at some point deleted all my magisk and xposed modules to test individually

    Be careful about using xprivacy, it may trip integrity again at some point. I removed it completely and now all works fine
    1
    Try uninstalling xprivacylua and delete all the folders it created in system and sdcard. That was what tripped integrity checker for me before
    Holy Moly you made me happy!

    I didn't find any folder to delete, but first try with Displax latest mod + clear data from Play Store, Play service and Wallet did the job.

    I reinstalled XprivacyLUA, so far so good 🤞 Still have to go out and test the wallet.

    Thanks Captain! May I ask how did you find out?
  • 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
    So this has brought up a question: we've talked about how Play Integrity affects pre Android 8/Keymaster 3 devices because they aren't capable of the SN HARDWARE_BACKED / PI STRONG_INTEGRITY attestation. I must have misunderstood because I was under the impression that even bone stock pre-A8 devices would fail all 3 results of PI;
    No...

    These actually pass basicIntegrity and deviceIntegrity because there is no need to trigger any fallback or bypass any l hardware backed evaluation type enforcement... They were designed to use basic attestation and Google allows this for deviceIntegrity verdict so stock pre-A8 devices will show passing basicIntegrity and deviceIntegrity verdicts just like we can achieve w/ USNF etc... 🙂 Stock A8+ devices will show passing strongIntegrity in addition... 😀

    The purpose of USNF has always been simply to allow Android 8+ LV (launch version)/Keymaster 3+ devices to pass these verdicts/attestations with unlocked bootloaders just as devices not meeting hardware requirements always have (ie. simply by hiding root from the droidguard process, adjusting sensitive props, etc)... And such a mod is needed simply because A8+ devices will normally fail deviceIntegrity (and possibly basicIntegrity) verdicts due to their being designed to use keymaster 3+ (ie. 'strong' hardware keystore backed attestation), even when attesting to deviceIntegrity components, where it exists
    is it more correct to state that the major difference is that they are only capable of basic evaluationType, therefore they CAN still pass BASIC_INTEGRITY and DEVICE_INTEGRITY?
    Yup... And they do so by default! (assuming a stock/locked device, or assuming root is hidden from droidguard process, sensitive props are adjusted, etc where unlocked)...
    After all, this is what the USNF mod does, isn't it - downgrades the fingerprint to force basic evaluation instead of hardware backed?
    No!... 😬 Please don't confuse forcing a fallback to basic evaluation type attestations (the key USNF function) with bypassing enforcement of hardware based evaluation type verdicts (a secondary function). Without bypassing, that enforcement will still cause a failing verdict despite droidguard/gms actually sending passing basic evaluation type attestations... We need to get our heads around these two separate functions and their differences!!!...

    Fallback to basic evaluation type is forced by fake keystore provider registration/subsequent exception in Play Services on attempting HKA (hardware key based attestation)...

    Nb. This trigger is the key one, is needed by most A8+ LV devices, and cannot be achieved by any simple prop manipulation!...

    Further, the fingerprint prop is not actually touched by current official USNF release, but is by the new pre-release build... It was introduced in @Displax's modded fork and was added to provide the additional mismatch w/ prop settings expected for device/device configurations Google has whitelisted for hardware based evaluation type enforcement required for some devices... It appears to be needed for many A11+ devices that previously required the model prop mismatch introduced a long while ago for S/N API...

    Nb. This enforcement bypass is not needed on my A10 MIUI A9 LV device, nor by many other devices...

    Summary:

    USNF achieves fallback to basic evaluation type by registering a fake keystore provider to trigger this, not by any prop changes!

    All the prop changes are due to Google adding enforcement of hardware evaluation type even where the evaluations performed have already dropped to 'basic' as the fallback type... Read "Device may be doing basic evaluation type attestation but that is still not accepted because device meets criteria in Google's prop based 'Enforce hardware based evaluation type' whitelist"...

    Nb. All hardware keymaster 3 compliant devices default to hardware evaluation type so will need the USNF fallback trigger if modded...

    Nb. 2. In devices w/ broken keymaster implementations like OnePlus, fallback is triggered naturally by the exception thrown when Play Services attempts to use key attestation. This simply passes as Google hasn't flagged/won't flag these devices for hardware evaluation type enforcement...

    Some (not all... maybe most...) hardware keymaster 3 compliant devices are included in Google's 'Enforce hardware based evaluation type' prop based whitelist. These require (in addition to the fallback trigger) adjustments to one or more of the following props (ie. to cause mismatches with expected device prop values) in order to bypass hardware based evaluation type enforcement by not meeting Google's defined whitelist criteria. So far these include:

    1) ro.product.model for S/N and PI (not all A8+ LV devices required this) [official 2.3.1+]

    2) ro.build.fingerprint for PI (mostly A11+ devices initially required this) [@Displax modded 2.3.1 fork, official 2.4.0+]

    3) first_api_level for PI (A13+ launch version devices require this) [@Displax modded 2.3.1 fork, official 2.4.0+]

    Nb. Google have clearly been steadily increasing the number of prop values used to flag devices for hardware based evaluation type enforcement in their whitelist implementation for newer devices/OSs... Notably, the last addition exempts no API level 33+ LV devices!

    This means that no stock (un-modded) 33+ devices will pass deviceIntegrity w/o HKA, so it seems that Google expect OnePlus and other OEM's to have fixed bad keymaster implementations in all devices launched w/ Android 13+...

    If manufacturers mess this up again, their stock/locked devices can now never pass even deviceIntegrity verdict (unless Google revert the first_api_level flag that effectively whitelists all A13+ devices for HKA evaluation type enforcement), so these are effectively being forced to 'up their game' at this time... 🙃

    👀 PW
  • 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
    189
    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!