[Discussion] Google Pay Magisk Discussion Thread

Search This thread

asripath

Senior Member
Jul 12, 2020
269
224
Redmi K20 Pro
Samsung Galaxy Tab A8
Don't bother fixing Pay/Wallet till you have deviceIntegrity...

It's pretty much useless posting issues like this w/o at least giving device details/ROM/mods... But I remembered you. 😉

OnePlus? RiceDroid?...

... I just posted re. this today:

🙃 PW

FWIW

Currently device just meets/passes basic integrity.

Have gpay in island work profile...
no issues so far in payments.

Maybe user's should explore that option too while waiting for custom roms to roll-out fix.
 
  • Like
Reactions: pndwal

_Raziel666

Senior Member
Jun 15, 2011
727
209
Athens
FWIW

Currently device just meets/passes basic integrity.

Have gpay in island work profile...
no issues so far in payments.

Maybe user's should explore that option too while waiting for custom roms to roll-out fix.
Just tried that but I get the message:
There was a problem settin the active account. Would you like to try again?

The only choice is "OK" and when pressed, it shows the same message.
 

V0latyle

Forum Moderator
Staff member
If your bootloader is unlocked, the only way you're going to be able to pass Play Integrity and use payment apps is with Magisk. I tried explaining this to you in the Magisk discussion thread. Without root, Magisk cannot load modules, nor can the fact the bootloader is unlocked be hidden.

If you're not going to use root, you should stay on the OEM firmware and keep your bootloader locked.

You can't have it both ways.
 
  • Like
Reactions: ipdev and rodken

_Raziel666

Senior Member
Jun 15, 2011
727
209
Athens
If your bootloader is unlocked, the only way you're going to be able to pass Play Integrity and use payment apps is with Magisk. I tried explaining this to you in the Magisk discussion thread. Without root, Magisk cannot load modules, nor can the fact the bootloader is unlocked be hidden.

If you're not going to use root, you should stay on the OEM firmware and keep your bootloader locked.

You can't have it both ways.
@asripath mentioned using Island's work profile and Island can work without root too, that's why I tried it.
 

_Raziel666

Senior Member
Jun 15, 2011
727
209
Athens
It still doesn't isolate apps from the device environment; since apps depend on the Play Integrity API, failing BASIC and/or DEVICE integrity will prevent payment apps from working.
For some weird reason (and long before all this crap with GPay), I found out that my banking app was refusing to work in my non-rooted phone, but when using Island the same app was working flawlessly in the work profile. Go figure...
 

V0latyle

Forum Moderator
Staff member
For some weird reason (and long before all this crap with GPay), I found out that my banking app was refusing to work in my non-rooted phone, but when using Island the same app was working flawlessly in the work profile. Go figure...
How long ago was this? Play Integrity is fairly new and was only introduced last year.

Your bootloader is unlocked, correct? Without fixes being baked into the Android build you're running, there are only two ways to be able to pass sufficiently to run payment apps:
  • Locked bootloader with unmodified firmware
  • Unlocked bootloader, Magisk root + Zygisk + modules to force basic attestation
There is no in between.
 

_Raziel666

Senior Member
Jun 15, 2011
727
209
Athens
How long ago was this? Play Integrity is fairly new and was only introduced last year.

Your bootloader is unlocked, correct? Without fixes being baked into the Android build you're running, there are only two ways to be able to pass sufficiently to run payment apps:
  • Locked bootloader with unmodified firmware
  • Unlocked bootloader, Magisk root + Zygisk + modules to force basic attestation
There is no in between.
I'm running a custom ROM (i.e. my bootloader is unlocked) in my surya. The problem with the banking (not payment!) app exists since an update they did a couple of years back.

Waiting for an update in the custom ROM I have that supposedly resolves the issue. If not, I will go down the road of root, etc.
 
  • Like
Reactions: pndwal

xabier-bo

Senior Member
Sep 17, 2014
150
29
Well...

Today I've been able to pay with GPay. It's a new risky sport: try to buy anything

Magisk 25.2; USNF 2.3.1 MOD 3; Enforce Deny List; and just clear GPay cache

It seems that for a couple of days we are allowed to pay...

Under his eyes! 😅
 

Dasher81

New member
Jul 21, 2018
3
0
Poco f3 custom pixalos rom

Pay and revolut stopped working, now working again thankfully

Magisk 25.2
USNF 2.3.1 MOD 3
Enforce Deny List (block google services, pay, play and banking apps)
clear GPay cache
 

m0han

Senior Member
Apr 30, 2012
5,565
2,675
... Unlocked bootloader, Magisk root + Zygisk + modules to force basic attestation... There is no in between.
Magisk Delta (latest, almost always) + Riru +...... works for me (as of now) on Poco X3 (Karna) running AICP A12.1 (10-Feb release).

I'm running a custom ROM (i.e. my bootloader is unlocked) in my surya..... Waiting for an update in the custom ROM I have that supposedly resolves the issue....
:giggle:

Well...It seems that for a couple of days we are allowed to pay...Under his eyes! 😅
:D
 

cmstlist

Senior Member
Jan 11, 2010
3,374
524
Toronto
Google Pixel 4a
Just wanted to be sure, on my device:
- Pay/Wallet are in DenyList
- Play Store is in DenyList
- Play Services is NOT in DenyList (because we need SafetyNet fix to be able to do its thing)

Is that what's recommended for best results or did I get any of it wrong?
 

pndwal

Senior Member
If your bootloader is unlocked, the only way you're going to be able to pass Play Integrity and use payment apps is with Magisk.
No it's not!
I tried explaining this to you in the Magisk discussion thread. Without root, Magisk cannot load modules, nor can the fact the bootloader is unlocked be hidden.
But it can be hidden!
If you're not going to use root, you should stay on the OEM firmware and keep your bootloader locked.
Why?
You can't have it both ways.
But you can! 😜

I've explained it to you in Universal SafetyNet Fix discussion thread...

But for clarity and for others, root and USNF are only needed for fixing device integrity attestations when a ROM doesn't implement native fixes, or, as in this member's case and many many more recently, where the ROM's integrated integrity attestation solution requires updating by maintainers because of changed Google server end checks etc...

Your statement may apply to stock public, developer, and beta ROMs as well as clean custom ROM builds like official LineageOS, but it's definitely false as users of custom unofficial LineageOS and even many official builds of the likes of Evolution X, CrDroid, Proton, RiceDroid, Bliss, Paranoid, Resurrection Remix, etc, etc, etc do enjoy passing SafetyNet and PI deviceintegrity with neither root nor USNF module etc!

Many (most?) of these ROM maintainers pull commits directly from @kdrag0ns current Proton builds (per his recommendation; and he supplies two technically different variations of SNF for Devs to choose from) which generally pass integrity attestations natively (ie. w/ NO root!), and augment these with @Displax's up-to-date fixes... Others likely build with their own variations on SNF...

I personally prefer a 'clean' ROM (no integrated prop/signal manipulation or spoofing) + Magisk + USNF variants to pass device integrity verdicts, but many want a custom ROM without root... It's a personal choice to adopt either approach... And a custom ROM Dev's choice...

😬... 😉 PW

XDAVOBanner.gif

... Gotta love that signature!

- First time I've seen it... Usually access XDA from phone... 😁
 
Last edited:
  • Like
Reactions: Flr Power

V0latyle

Forum Moderator
Staff member
No it's not!

But it can be hidden!

Why?

But you can! 😜

I've explained it to you in Universal SafetyNet Fix discussion thread...
My assumption was:
stock public, developer, and beta ROMs as well as clean custom ROM builds like official LineageOS,
I understand that custom builds may implement native fixes and do not require root...or additional fixes in that case.
View attachment 5833399
... Gotta love that signature!

- First time I've seen it... Usually access XDA from phone... 😁
9 yrs in the Marines. You can take the man out of the Corps but you can't take the Corps out of the man
 

pndwal

Senior Member
For some weird reason (and long before all this crap with GPay), I found out that my banking app was refusing to work in my non-rooted phone, but when using Island the same app was working flawlessly in the work profile. Go figure...
The key thing that breaks device integrity and attestations to the same (incl. old S/N API) is unlocked bootloader... Root is a secondary sign that a device is tampered.

If a ROM doesn't attempt to hide AVBs broken chain of trust in userspace attestations, Magisk modules can do this... Nothing can properly hide this in hardware-backed attestations.

Sandboxing apps can prevent these from accessing userspace signals that attest to tampering and can work especially if the app fails to test why it cannot access device integrity attestations... However many apps are not satisfied when S/N or PI attestations cannot be accessed and will also look for signs of sandboxing as well as spoofed environment signals...

The level of sophistication for insecure execution environment detection in bank apps varies wildly; those employing professional 'security' engines like Promon are tougher nuts to crack...

🤠 PW
 
Last edited:

pndwal

Senior Member
If your bootloader is unlocked, the only way you're going to be able to pass Play Integrity and use payment apps is with Magisk ... Without root, Magisk cannot load modules, nor can the fact the bootloader is unlocked be hidden.

If you're not going to use root, you should stay on the OEM firmware and keep your bootloader locked.

You can't have it both ways.
My assumption was:

I understand that custom builds may implement native fixes and do not require root...or additional fixes in that case.
Assumptions or not, those were sweeping generalisations that failed to consider countless modders using custom ROMs that spoof environment checks... 😁

Interestingly, even @kdrag0n recommends the non-root ROM integrated spoofing approach from his Proton project as the 'ideal' solution for custom ROMs:
ROM integration
Ideally, this workaround should be incorporated in custom ROMs instead of injecting code with a Magisk module. See the ProtonAOSP website for more information.
https://github.com/kdrag0n/safetynet-fix#rom-integration

This way @kdrag0n has made it easy for ROMs to pass device integrity attestations natively and without root or USNF... We shouldn't forget that XDA is principally a mobile software development community supporting custom ROM modders as well as root users...

9 yrs in the Marines. You can take the man out of the Corps but you can't take the Corps out of the man
... Guess I'm taking a risk contradicting you then! 😜... (We seem to miss a lot on XDA if not using a larger-screen device...)

Should I be glad I'm down under and you're way up there standing on your head? 😝

Best regards, PW
 
  • Like
Reactions: Flr Power

Top Liked Posts

  • There are no posts matching your filters.
  • 4
    Thanks to pndwal's suggestions, I confirm what rogerinnyc wrote above. On my S10e I'm using Ambassadii ROM 5.6 and Magisk 26.1 the Zygisk option is enabled. I set denials for GPay/Wallet, Google Play Services, banking applications and the Allegro application (a popular shopping platform in Poland, something like eBay). Also, I have the safetynet-fix-v2.4.0-MOD_1.2 module installed in Magisk. Without the Shamiko module installed in Magisk and without Enforce Deny List enabled, a strange thing happens. Namely, the GPay/Wallet application worked, but the banking applications detected the root.
    I believe GPay/Wallet would usually fail after some time unless you still pass Play Integrity deviceIntegrity verdict because ROM integrates SNF or it's own spoofs for this...

    It's not surprising bank apps fail without denylist (they actively search for root) / Shamiko (proper hiding for traces of Zygisk etc)...
    When Enforce Deny List was enabled, banking applications did not detect the root, but GPay/Wallet stopped working and showed that the device does not comply with security rules. Only the installation of the Shamiko module with the DISABLED Enforce Deny List in Magisk solved the problem. Both GPay/Wallet works and other banking apps don't see root. I did not tested removal of safetynet-fix-v2.4.0-MOD_1.2 module and leaving Shamiko module alone anymore. But my current combination of modules works for me. Thank you, Dear Friends, once more for your hints.
    Having Play Services, specifically the droid guard/attestation process com.google.android.gms.unstable in active denylist breaks Zygisk based USNF builds (note, it will remove these from denylist on next boot for this reason) because DenyList reverts/prevents Magisk modifications in listed processes unlike old MagishHide. (It's really now a development tool, not a hiding tool.) In this case USNF injects code in gms to register a fake keystore to cause the fallback to basic attestation that's it's key function, so we can't hide root front gms using Denylist... Shamiko on the other hand is a proper hiding module and simply uses denylist (for convenience) as a hidelist, so it doesn't break USNF in this case...

    Zy-USNF builds hide root from gsm processes itself, so they shouldn't be added in denylist anyway... This should be done to pass device integrity verdicts if you use pre-Android 8, devices with broken keymaster implementations or revoked keys, or when ROM integrates it's own SNF/spoofing, and USNF is not used/needed but never with Zy-USNF.

    GPay/Wallet needs passing PI deviceIntegrity and you need to check this is passing with a Play Integrity checker app... You'll see this fail as soon as denylist is enforced...

    Bank apps on the other hand often employ their own checks for traces of root and some don't check deviceIntegrity. Some only check deviceIntegrity and some do both...

    Hope it helps your understanding of this.

    🤠 PW
    3
    Just adding my experience to this thread, FWIW. On a OnePlus 9 Pro, rooted, Android 13 stock, and using the official Magisk 26.1. All I have installed is Shamiko 0.7 -- no Universal Safety Net Fix, no MagiskHide Props Config. In Magisk settings, Zygisk is enabled (as is required by Shamiko), but not Enforce Deny List. My Configure DenyList includes Google Wallet and Google Play Store, but not Google Play Services. With that configuration, Google Wallet has been working consistently. I can't speak to the various banking apps -- but I use Chase with this configuration (but the setup to get it working is not straight-forward, involving using an older apk version initially, and functionality for secure messages doesn't always work).

    I did have a problem with opening Wallet after a reboot and getting a pop up warning that your device does not meet security requirements, but I could simply dismiss that and Wallet would still work (and "tap to pay setup" would show "Your phone meets security requirements" still). I think that may have been Magisk taking some time to load. I've gone into Battery settings for Magisk and enabled it both to run in the background and to autolaunch and that issue hasn't (yet) re-occurred.

    Interestingly, with this configuration, using YASNAC (Yet Another SafetyNet Attestation Checker), my device would fail both Basic Integrity and CTS Profile Match, even with Google Wallet working. Once I added Universal Safety Net Fix 2.4, YASNAC would pass my device. So far, no ill effects from having both Shamiko and USNF installed and running. But Shamiko alone was sufficient for Google Wallet purposes.

    YMMV.

    P.S. I should add that once you have the Magisk/Module set up you want, you should clear cache (and, I believe but am not certain it's needed, data) for Google Play Store and Google Play Services and and Google Wallet and reboot.
    3
    Thanks to pndwal's suggestions, I confirm what rogerinnyc wrote above. On my S10e I'm using Ambassadii ROM 5.6 and Magisk 26.1 the Zygisk option is enabled. I set denials for GPay/Wallet, Google Play Services, banking applications and the Allegro application (a popular shopping platform in Poland, something like eBay). Also, I have the safetynet-fix-v2.4.0-MOD_1.2 module installed in Magisk. Without the Shamiko module installed in Magisk and without Enforce Deny List enabled, a strange thing happens. Namely, the GPay/Wallet application worked, but the banking applications detected the root. When Enforce Deny List was enabled, banking applications did not detect the root, but GPay/Wallet stopped working and showed that the device does not comply with security rules. Only the installation of the Shamiko module with the DISABLED Enforce Deny List in Magisk solved the problem. Both GPay/Wallet works and other banking apps don't see root. I did not tested removal of safetynet-fix-v2.4.0-MOD_1.2 module and leaving Shamiko module alone anymore. But my current combination of modules works for me. Thank you, Dear Friends, once more for your hints.
    3
    GPay/Wallet needs passing PI deviceIntegrity and you need to check this is passing with a Play Integrity checker app... You'll see this fail as soon as denylist is enforced...
    It happens exactly as you said. So denylist enforcement in Magisk should be disabled. Shamiko module properly hides the root for all the rest bankig/shopping apps :)
    2
    You have updated USNF from this thread or the newer/better/modded version from another thread (please don't ask which thread - every second post is about, just scroll back, where, why, etc)

    I didn't know there were two different variants. I got it from kdrag0n's github. is there a new better one?
    (I'll take a look in the meantime)

    edit: it worked, omg thank you so much.

    here's the thread with the other, working version of USNF, for convenience for anyone bumping into this post:

  • 62
    The new Google Play services update caused this.

    Temporary workaround:

    1. Disable Google Pay/Find My Device as Device Administrators in Settings > Security & location > Device Administrators.

    2. Search "Google Play services" in the Settings search bar.

    3. Press the three dots and press "Uninstall previous updates".

    4. Download this update - https://www.apkmirror.com/apk/google-inc/google-play-services/google-play-services-14-7-99-release/
    Pick your needed edition (arm or arm64, etc.), download it and install it.

    5. Disable Background data access for Google Play Services and Google Play in their respective App Info pages.

    6. Download Google Pay from the Play Store.

    7. Set up your cards. Enjoy!

    Never EVER update Google Play services manually, until a Magisk update is available that bypasses the upgraded SafetyNet. Note that Google Play services is responsible for adding/verifying the card, not the Google Pay app! Hence why there seems to be an overlay when adding a card/verifying an existing one.

    Tested Google Pay versions:

    2.79.x-2.83.235070858 - working

    Tested Google Play services versions:

    14.7.99, 16.0.86 - working with Magisk 18.1

    14.8.49-16.x- working with Magisk 18.2 Canary
    32
    This thread is inspired by the PoGo Magisk discussion thread. It's meant to keep the clutter of "Google Pay doesn't work" posts out of the main Magisk threads.

    Please use this to discuss issues with Google Pay and possible solutions.


    There's a working solution here:
    https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87198517


    For general tips on first getting SafetyNet to pass fully, check here:
    https://www.didgeridoohan.com/magisk/MagiskHide#hn_SafetyNet
    29
    Ok. I tried this and it worked on gms 17.1.22, allowing one to add cards and pay in store. Warning YMMV, but this is the process I did to get this working. One caveat is that Google pay does not register the "recent transactions" on the Google pay app. Another caveat is that I suspect users will have to reverse some step if gms is updated and then reapply, but this still needs to be confirmed

    Without further ado, here is my process:

    1) download a SQL database editor. I used

    https://play.google.com/store/apps/details?id=com.tomminosoftware.sqliteeditor&hl=en_US

    2) download a terminal emulator program. I used terminus but any terminal emulator should work.

    3) make sure Google pay is forced close, if it is open.

    4) open SQL editor. Navigate to /data/data/com.google.android.gms/databases

    5) open dg.db

    6) change any value that lists "attest" in the name (first column) to 0 in the third column. Mine was showing a value of 10 in the third column for each of these values. (Column c for sqlite databse editor I used)

    7) open the terminal emulator.

    8) get root access (su)

    9) cd /data/data/com.google.android.gms/databases

    10) type: chmod 440 dg.db
    This makes dg.db read only (for owner and group, and no access for world.)

    11) reboot

    I suspect when gms is updated, one will have to go back to steps 10 and 11 and chmod 660 dg.db to allow new keys to be written to the database, and then go back and redo all these steps to reset the attestation values back to 0.

    If there is still an error, verify in sqlite database editor that all attest release keys values in dg.db are 0 when dg.db is read only (owner and group).

    Again, YMMV but this worked for me, so I give it back to the community now.

    Edit: recent activities did show up soon afterwards for the payment method.

    Cheers,
    B.D.
    28
    The app is finally public! (thanks Google for taking a week to approve this 🤦)
    I made it beta testing since I haven't tested it on much devices. If you find any problem, please open an issue here and I'll take a look at them once I return from vacation.


    Source code:

    If you are curious, the possible outcomes I've seen are:
    • 3 ticks (unrooted samsung)
    • tick/tick/x (unrooted redmi note 4 with unlocked bootloader)
    • x/tick/x (my rooted a11 op7t)
    23
    UPDATE 1/8/2022
    This app is officially discontinued in favor of a new app I published on Play Store. Read more here:

    ====================
    ORIGINAL MESSAGE:

    I just made this simple app which tells you if your device passes the new Play Integrity API (which is presumably what Google Pay and Play Store use to detect root now). If you don't trust random apks from the internet feel free not to use this. I'll upload the source code at a later time since it's very junk now (probably on github).
    You can use it to play around and see if you manage to get it to pass without having to mess with Google Pay. There are screenshots of the 2 possible outputs (pass screenshot is from an online emulator).
    Also I didn't test it much since I don't have many devices that can pass. Hope it works fine 🤞

    Hope this helps someone find a solution :)

    EDIT:
    Here is a quote from Google of what exactly "Does not meet device integrity" mean:
    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).
    ...
    If you are having problems with your testing device meeting device integrity, make sure the factory ROM is installed (for example, by resetting the device) and that the bootloader is locked.