[Discussion] Google Pay Magisk Discussion Thread

Search This thread
By:
Advanced…
P

pndwal

Senior Member
Jun 23, 2016
5,507
6,060
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
V0latyle said:
I could be wrong, but for most people, the "solid base" of Magisk modules (assuming stock ROM with root) is just USNF Displax mod. If other modules or modifications are installed then more elaborate hiding measures might be necessary but in general the modded USNF alone is sufficient to pass basic and device integrity.
Click to expand...
Click to collapse
FWIW, USNF (now w/ @Displax' mods) is the defacto replacement for basic MagiskHide functions that provided an environment attestation API (SafetyNet) bypass...

MagiskHide also provided proper 'root' hiding from apps but always remained basic as John has tired of / lost interest in bypassing app's increasingly sophisticated custom root trace detection methods for some years now.

This has meant that more sophisticated root hiding has been the province of solutions like
'Servicely' (to disable services with isolatedProcess enabled that can 'easily bypass MagiskHide), vv's Unshare and later Canyie's MomoHider Magisk modules in combination with Magisks own hidelist.

XPosed modules like Hide My Applist were also added to the list of hiding solutions as Devs have found ways to (arguably) abuse ability to detect apps they deem indicators of execution environment compromise despite Google's efforts to limit this 'improper' use of permissions like QUERY_ALL_PACKAGES...

With Zygisk-generation Magisk (24+), even basic root trace hiding has been 'sunsetted' in Magisk itself... As John said:
• It's not a secret that specifically designed modules can indeed utilize the DenyList feature for "hiding" purposes
• DenyList, however, is only meant to "revert all Magisk changes". It will not attempt to manipulate any other signals on the device
• Since Magisk already provides root permissions, modules don't actually need to rely on DenyList for hiding. They can do everything themselves
• There are already modules out there that directly manipulates root detecting processes / system services to workaround HW KA
Click to expand...
Click to collapse

So newer efforts to provide root hiding have had to re-implement proper methods (not simply reverting Magisk modifications in processes which actually breaks much hiding). This means that solutions like Shamiko, while 'hijacking' denylist for convenience, are actually re-imlementing denylist as a hidelist. In this sense at least Shamiko is now supplying the 'solid base' hiding once provided by MagiskHide (but it's not needed for passing SafetyNet or Play Integrity attestations as you said)...

Of course other 'base' hiding is also supplied by Shamiko, eg xhook hiding for LSPosed and other modules was previously integrated in Riru as Riruhide but many were unaware of its existence. With 24+ Magisk there is no such integrated hiding but Shamiko is hiding (most?) traces of xhook/Zygisk now...

Being a Canyie initiative, Shamiko adds the unshare (isolated process) and other hiding done by her MomoHider as well as tmp mount and more hiding for further traces now detected by banks... PW
 
  • Like
Reactions: beeshyams, ipdev, pedritopl and 7 others
M

Minecraftitsover90

Member
Oct 12, 2014
11
0
this url is what gpay uses to determine if gpay works on your device or not for security reasons
the request body in hex in the file below with my bearer token gave me this

�
�&Google Pay can't be used on this phone�Your phone may be rooted or altered in a way that doesn't allow Google Pay to confirm that it meets security standards.

<a href="https://support.google.com/pay/answer/7643995">Learn more</a>"N
Htype.googleapis.com/google.internal.tapandpay.v1.AttestationErrorDetails�ˍ��0

I have already tried all the known methods to try to get it to work but its not working including the one to pass google play certification and what not.
my device is Samsung Galaxy A71 running firmware A715FXXU3BUB5 or in this case Build RP1A.200720.012.A715FXXU3BUB5

how could i fix this?
 

Attachments

  • request.bin
    46.1 KB · Views: 6
Last edited:
M

Minecraftitsover90

Member
Oct 12, 2014
11
0
pndwal said:
Oh.. not sure how you 'tried all the known methods' if you didn't read back here at all! 🤪 PW
Click to expand...
Click to collapse
Anyways
{
"apkCertificateDigestSha256": [
"CFMi+R9OCRrIqon0WdOwQgA4I9aG0m1sYPZuUf5a2ns="
],
"apkDigestSha256": "6eSwd6Ed+f4Pab9sXTvk+hqbA8VFtfdCnYlznf+zIbc=",
"apkPackageName": "rikka.safetynetchecker",
"basicIntegrity": true,
"ctsProfileMatch": true,
"evaluationType": "BASIC",
"nonce": "MDY0ZWFlMGQtMjhmMC00YjdjLWIzYzItNWVlMTA0YzY0NDg0CjIwMjItMTItMDlUMjM6NTA6NTkuOTM0KzEwOjMwCnNhbXN1bmcvYTcxbnN4eC9hNzE6MTEvUlAxQS4yMDA3MjAuMDEyL0E3MTVGWFhVM0JVQjU6dXNlci9yZWxlYXNlLWtleXMKMzAKMjAyMS0wMi0wMQo=",
"timestampMs": 1670592069860
}
 

Attachments

  • Screenshot_20221209-235150_Yet Another SafetyNet Attestation Checker.png
    Screenshot_20221209-235150_Yet Another SafetyNet Attestation Checker.png
    257.2 KB · Views: 31
M

Minecraftitsover90

Member
Oct 12, 2014
11
0
Minecraftitsover90 said:
Anyways
{
"apkCertificateDigestSha256": [
"CFMi+R9OCRrIqon0WdOwQgA4I9aG0m1sYPZuUf5a2ns="
],
"apkDigestSha256": "6eSwd6Ed+f4Pab9sXTvk+hqbA8VFtfdCnYlznf+zIbc=",
"apkPackageName": "rikka.safetynetchecker",
"basicIntegrity": true,
"ctsProfileMatch": true,
"evaluationType": "BASIC",
"nonce": "MDY0ZWFlMGQtMjhmMC00YjdjLWIzYzItNWVlMTA0YzY0NDg0CjIwMjItMTItMDlUMjM6NTA6NTkuOTM0KzEwOjMwCnNhbXN1bmcvYTcxbnN4eC9hNzE6MTEvUlAxQS4yMDA3MjAuMDEyL0E3MTVGWFhVM0JVQjU6dXNlci9yZWxlYXNlLWtleXMKMzAKMjAyMS0wMi0wMQo=",
"timestampMs": 1670592069860
}
Click to expand...
Click to collapse
I didn't use the right app right or is this correct info?
 
M

Minecraftitsover90

Member
Oct 12, 2014
11
0
Now it decides to take away device integrity

I Must be doing something wrong.for this to happen
weird thing is rebooting causes magisk denylist to untick google play services.
 

Attachments

  • Screenshot_20221210-081329_Play Integrity API Checker.png
    Screenshot_20221210-081329_Play Integrity API Checker.png
    303.4 KB · Views: 35
7

73sydney

Senior Member
Jul 21, 2018
3,055
3,211
Sydney
Google Pixel 6 Pro
Samsung Galaxy Watch 4
Last edited:
  • Like
Reactions: ipdev
7

73sydney

Senior Member
Jul 21, 2018
3,055
3,211
Sydney
Google Pixel 6 Pro
Samsung Galaxy Watch 4
  • Like
Reactions: ipdev
P

pndwal

Senior Member
Jun 23, 2016
5,507
6,060
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
Minecraftitsover90 said:
...
I Must be doing something wrong.for this to happen
weird thing is rebooting causes magisk denylist to untick google play services.
Click to expand...
Click to collapse
The gms attestation (droidguard) process also known formerly as the 'SafetyNet' process, used to be added to hidelist on toggling MagiskHide... With Zygisk era Magisk users began adding this to denylist manually (along with main gms process if using A11+)...

Since denylist isn't proper hiding, denylist can be disabled or hijacked by other solutions like Shamiko and for convenience/ease of use in a 'universal fix', USNF began hiding root from the attestation process itself using a Zygisk based hiding mechanism since Zy-USNF became available... Of course if root is also hidden w/ denylist based methods there may be conflicts with USNF inbuilt hiding, so any gms processes were simply removed to ensure if USNF is broken things are restored on reboot...

With the @ipdev commit mentioned above, this removal only occurs if denylist is enforced... I did discuss this but the idea was passed at the time... This means that if Shamiko is used there is now potential for conflict as the attestation process is slated for both inbuilt root hiding and Shamiko hiding even after reboot if a user adds the process to denylist... I'm not sure (since I haven't added com.google.android.gms.unstable recently), but it appears native USNF hiding for gms doesn't conflict with Shamiko hiding anyway... I couldn't reproduce conflicts w/ denylist enforced on my device either however...

Anyway, no hiding in addition to native USNF hiding is needed for com.google.android.gms.unstable process...
Minecraftitsover90 said:
but i was following this guide originally
www.xda-developers.com

How to pass SafetyNet on Android after rooting or installing a custom ROM

It is possible to pass SafetyNet, even after extensive modding like rooting or installing a custom ROM. Check out how to do that here!
www.xda-developers.com www.xda-developers.com
Click to expand...
Click to collapse
I can't see any recommendation to hide root from com.google.android.gms.unstable (attestation) process here however...

But thanks for the link... Some notes on it:

That article seems old/flawed despite being updated in Oct... Also there's some inaccuracies there... I just posted these comments there (at end of article):
Shamiko is for hiding extra traces of root/modified environment apps detect; it has nothing to do with passing SafetyNet or Play Integrity deviceIntegrity verdicts for that matter (except that it may adjust a few sensitive props that affect those attestations)... @MishaalRahman's (former XDA Editor-in-chief) older comments here may also be misleading in this instance... Perhaps he meant 'reliable way to hide traces of root'...

Universal SafetyNet Fix is a complete solution for passing S/N, but may need to be complimented w/ a separate solution (eg MagiskHide Props Config)for setting passing fingerprint and security patch date prop combinations if running China region, custom, developer, beta etc ROMs...

Now that S/N API is deprecated and banks etc are migrating to Play Integrity API deviceIntegrity attestation, the go-to solution is a forked/modded USNF build by @Displax that adds extra prop mismatch based triggers for bypassing hardware based verdict enforcement in Play Integrity API to allow deviceIntegrity verdict to pass... @kdrag0n has already begun efforts to integrate these PI 'fixes' in official USNF...

Since the principal trigger here employs a mismatched but passing fingerprint prop targeting the gms attestation (droidguard) process only (rather than settings prop globally), use of MHPC configured fingerprint etc is no longer needed even for China region or custom ROMs... Using Zygisk for targeted prop application also means this solution is far less likely to break OEM specific functions...

Also, I note that YASNAC was only offered since SafetyNet Check was removed from Magisk... PW
Click to expand...
Click to collapse

👀 PW
 
  • Like
Reactions: 73sydney, okij and ipdev
ipdev

ipdev

Recognized Contributor
Feb 14, 2016
2,217
1
4,328
Google Nexus 10
Nexus 7 (2013)
73sydney said:
thats by design it stops people (like you) from selecting it when it *can* break things and its totally unnecessary...

github.com

safetynet-fix/post-fs-data.sh at master · Displax/safetynet-fix

Google SafetyNet attestation workarounds for Magisk - safetynet-fix/post-fs-data.sh at master · Displax/safetynet-fix
github.com github.com

please stop trying to break things....
Click to expand...
Click to collapse
pndwal said:
The gms attestation (droidguard) process also known formerly as the 'SafetyNet' process, used to be added to hidelist on toggling MagiskHide... With Zygisk era Magisk users began adding this to denylist manually (along with main gms process if using A11+)...

Since denylist isn't proper hiding, denylist can be disabled or hijacked by other solutions like Shamiko and for convenience/ease of use in a 'universal fix', USNF began hiding root from the attestation process itself using a Zygisk based hiding mechanism since Zy-USNF became available... Of course if root is also hidden w/ denylist based methods there may be conflicts with USNF inbuilt hiding, so any gms processes were simply removed to ensure if USNF is broken things are restored on reboot...

With the @ipdev commit mentioned above, this removal only occurs if denylist is enforced... I did discuss this but the idea was passed at the time... This means that if Shamiko is used there is now potential for conflict as the attestation process is slated for both inbuilt root hiding and Shamiko hiding even after reboot if a user adds the process to denylist... I'm not sure (since I haven't added com.google.android.gms.unstable recently), but it appears native USNF hiding for gms doesn't conflict with Shamiko hiding anyway... I couldn't reproduce conflicts w/ denylist enforced on my device either however...

Anyway, no hiding in addition to native USNF hiding is needed for com.google.android.gms.unstable process...

I can't see any recommendation to hide root from com.google.android.gms.unstable (attestation) process here however...

But thanks for the link... Some notes on it:

That article seems old/flawed despite being updated in Oct... Also there's some inaccuracies there... I just posted these comments there (at end of article):


👀 PW
Click to expand...
Click to collapse
There is no reason for the USNF module to police the DenyList for other modules. ;)
The USNF module is only affected when gms is added to the DenyList when Enforcing.​

If Shamiko requires gms to be added or removed from Magisk's DenyList, it is on Shamiko to controle it.
I am not a big fan of modules sourcing the DenyList instead of creating their own list. :(

Cheers. :cowboy:
 
  • Like
Reactions: 73sydney, okij, asripath and 1 other person
P

pndwal

Senior Member
Jun 23, 2016
5,507
6,060
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
ipdev said:
There is no reason for the USNF module to police the DenyList for other modules. ;)
Click to expand...
Click to collapse
Sure... It's a fine point and I didn't mean to argue the toss on this again...

I just noted that potential for conficts now exists here (and really only did because your adjustment was cited rather than the original commit and reason)... Also, I said 'potential' because I haven't been able to produce any such issue whether w/ denylist or Shamiko on my RN8T... 😉
ipdev said:
The USNF module is only affected when gms is added to the DenyList when Enforcing.​
Click to expand...
Click to collapse
As I said, it remains an anecdotal issue to me since I couldn't produce conflict (couldn't 'break things') even w/ denylist enforced despite original reason for commit:
magisk: Remove Play Services from DenyList …
The Zygisk module will never load if GMS is in the DenyList. Instead, we
have the module force-enable DenyList unmounting after forking.
Click to expand...
Click to collapse
... It did load for me... 🤔
ipdev said:
If Shamiko requires gms to be added or removed from Magisk's DenyList, it is on Shamiko to controle it.
Click to expand...
Click to collapse
... or simply tell users in some obscure doc or TG post not to put gms processes in denylist! 😝
ipdev said:
I am not a big fan of modules sourcing the DenyList instead of creating their own list. :(
Click to expand...
Click to collapse
Sure... Me neither... But I can understand the convenience of the method... Saves implementing a GUI or special user-edited file...

Frankly, it wouldn't worry me if gms removal was eliminated completely... If users have issues when not following a simple usage note not to put gms processes in denylist I think they'd probably figure out the problem with less bother than the inexplicable gms removal on reboot has caused!...

Actually, if any 'child-proofing' measures are really needed for this, I think I'd prefer the Shamiko "Module is not working because..." message approach was adopted, but that's just me... In the end it's @kdrag0n's call, and I'm grateful for what we've got any get in future... 😋 PW
 
  • Like
Reactions: ipdev, 73sydney and beeshyams
ipdev

ipdev

Recognized Contributor
Feb 14, 2016
2,217
1
4,328
Google Nexus 10
Nexus 7 (2013)
pndwal said:
Sure... It's a fine point and I didn't mean to argue the toss on this again...

I just noted that potential for conficts now exists here (and really only did because your adjustment was cited rather than the original commit and reason)... Also, I said 'potential' because I haven't been able to produce any such issue whether w/ denylist or Shamiko on my RN8T... 😉
Click to expand...
Click to collapse
That is one of the reasons I wrote it the way I did. 🙃
To try and prevent conficts.​
Since USNF is not affected when the denylist is not enforced, just ignore it.
Let what ever the user adds to the list stay there, do not mess with it.

Before Allow modifying denylist without enforcement, the denylist was only accessible when enforcing.
The original command would only run when enforcing and error out when not enforcing.
Once the denylist was accessible when not enforcing, the command would run regardless of denylist status.
"Since there is no need or reason to remove gms from the Denylist when not enforcing, why remove it?
Use a scalpel instead of a machete."​

The magisk --denylist status command returns true (0) when enforcing.
When not enforcing, the command returns an error (1).

pndwal said:
As I said, it remains an anecdotal issue to me since I couldn't produce conflict (couldn't 'break things') even w/ denylist enforced despite original reason for commit:

... It did load for me... 🤔
Click to expand...
Click to collapse
The USNF module will load and run just fine even if you are enforcing the denylist and include gms.
The module will just be unloaded every time gms is called. 🙃

When enforcing the denylist, every time a process in the list is called..
Magisk tries to "get out of the way" by unloading and reverting as much of itself as possible.
No modules will be active to the process while it is called.

When not enforcing the denylist, Magisk has no use for the denylist.
It is about as important to Magisk as your grocery shopping list. 😝

Took me a little bit to find where I read the "get out of the way" part. 🙂
State of Magisk: 2021
That being said, I strongly value the ability for apps to fully “opt-out” of modding, and it is important to me that Magisk is able to “get out of the way”, so a minor subset of the MagiskHide infrastructure will remain. Users will be able to assign a denylist of processes where Magisk denies further modifications and reverts all changes it had done. Magisk will not spoof/alter/manipulate any non-Magisk related signals or traces to circumvent any device state detection.

pndwal said:
... or simply tell users in some obscure doc or TG post not to put gms processes in denylist! 😝

Sure... Me neither... But I can understand the convenience of the method... Saves implementing a GUI or special user-edited file...

Frankly, it wouldn't worry me if gms removal was eliminated completely... If users have issues when not following a simple usage note not to put gms processes in denylist I think they'd probably figure out the problem with less bother than the inexplicable gms removal on reboot has caused!...
Click to expand...
Click to collapse
Only after..
  1. They make a post claiming they followed the instructions and it does not work.
    Normally adamant that it is the module's fault not their own. 🙃​
  2. Someone points out they are enforcing the denylist.
    Even though Shamiko notes that it is not working because denylist is enforcing. 🙃​
  3. Someone points out they are enforcing the denylist and include gms in the denylist.
    "I have the USNF module installed and I still fail SafetyNet." 🙃​

pndwal said:
Actually, if any 'child-proofing' measures are really needed for this, I think I'd prefer the Shamiko "Module is not working because..." message approach was adopted, but that's just me... In the end it's @kdrag0n's call, and I'm grateful for what we've got any get in future... 😋 PW
Click to expand...
Click to collapse
👍
Same here. 🙂

Cheers. :cowboy:
 
  • Like
Reactions: 73sydney, pndwal and Lughnasadh
P

pndwal

Senior Member
Jun 23, 2016
5,507
6,060
Sydney
Redmi Note 8
Xiaomi Redmi Note 8 (2021)
Minecraftitsover90 said:
So what can I do now?
Click to expand...
Click to collapse
Please confirm that you are actually using a @Displax USNF mod build... It's still not clear although it's usually needed for deviceIntegrity w/ A11+...

Next, consider and say what changes you made between having and loosing deviceIntegrity... Nb. Even when nothing is wrong with a setup any longer, clearing Google Play Services data is sometimes (often?) needed to restore deviceIntegrity etc... Some users have even needed to disable USNF module (official or forked), reboot, enable and boot again to fix...

Seems you did tick Google Play Services (gms) processes... See discussion above... Perhaps screenshot w/ MEETS_DEVICE_INTEGRITY missing was taken before rebooting (ie gms in denylist not yet removed and still breaking the PI fix)?... Could be an added module etc too... PW
 
Last edited:
  • Like
Reactions: 73sydney
You must log in or register to reply here.

Similar threads

T
  • Sticky
Magisk General Support / Discussion
Replies
54K
Views
6M
Arealhooman
Arealhooman
T
  • Locked
  • Sticky
Magisk - The Magic Mask for Android
Replies
56
Views
6M
T
topjohnwu
T
  • Locked
[CLOSED][BETA][2018.7.19] Magisk v16.7 (1671)
Replies
7K
Views
3M
T
topjohnwu
Heisenberg
[Discussion] PokeMon Go Magisk Discussion Thread
Replies
5K
Views
633K
djkrish5610
djkrish5610
Deic
[Magisk v14.0] Universal SafetyNet Fix | Universal Hide [v2 Beta 5]
Replies
2K
Views
858K
D
Deleted member 8425317

Top Liked Posts

24 Hours 30 Days All time
  • There are no posts matching your filters.
  • 3
    zgfg
    zgfg
    BesoC said:
    No, it does not set by itself. I had problems enabling its driver, one thread on XDA was strongly suggesting to set SELinux to permissive. I did and it worked, so... 🤷‍♂️. However, now when I reverted it back to enforcing, Viper still works 😊
    I did not search for STRONG_INTEGRITY, my bad
    Click to expand...
    Click to collapse
    Good that V4A V2.7 works for you with Enforcing mode (as it should)

    Btw, there are two newer versions:

    1) Repackaged V4A - finding and patching audio drivers when they are scattered to other system folders (needed for some devices):

    GitHub - programminghoch10/ViPER4AndroidRepackaged: A refined ViPER4Android installer.

    A refined ViPER4Android installer. Contribute...
    github.com github.com

    2) (1) + Reverse engineered V4A alpha v0.2.0 support for 64-bit audio drivers (needed on some new devices that could not fall-back to 32-bit audio drivers):

    GitHub - AndroidAudioMods/ViPERFX_RE: Reverse Engineering of ViPER4Android FX

    Reverse Engineering of ViPER4Android FX...
    github.com github.com

    Both also don't require SE Linux Permissive. Might need AML v4.2 (recently updated):

    PS:
    And don't forget to enable Legacy mode (and of course, Master limiter)
    View
    2
    AndrzejDwo
    AndrzejDwo
    BesoC said:
    Anything else I've missed?
    Click to expand...
    Click to collapse
    you missed play integrity check result. the other thing is that you have too many apps on deny list imo, this might result with the opposite result than expected, also you don't need magisk hide props when you use usnf mod by displax, and the last but not least - would be good to switch to ENFORCING SE LINUX if possible, i never tried to setup Gwallet on permissive tbh.

    cheers
    View
    2
    AndrzejDwo
    AndrzejDwo
    BesoC said:
    OK.
    • Removed MHPC from magisk modules
    • Removed everything from denylist except Google Wallet
    • Set SELinux to enforcing - I set it to permissive earlier because of Viper4AndroidFX
    • Reboot
    Still PI checker shows red cross for MEETS_STRONG_INTEGRITY
    Click to expand...
    Click to collapse
    that's normal and gwallet should work
    View
    2
    P
    pndwal
    BesoC said:
    OK.
    • Removed MHPC from magisk modules
    • Removed everything from denylist except Google Wallet
    • Set SELinux to enforcing - I set it to permissive earlier because of Viper4AndroidFX
    • Reboot
    Still PI checker shows red cross for MEETS_STRONG_INTEGRITY
    Click to expand...
    Click to collapse
    Perfect!...

    I didn't say you need strongIntegrity... When Google/banks start enforcing that it'll be a sad day for modders... Also, customers using any device w/ A7 or less + many modern OnePlus etc w/ broken keymaster will be collateral damage... deviceIntegrity is what you need ATM as stated... PW
    View
    2
    zgfg
    zgfg
    BesoC said:
    • Set SELinux to enforcing - I set it to permissive earlier because of Viper4AndroidFX
    Click to expand...
    Click to collapse
    If using V4A FX 2.7.2.1, it doesn't set SE Linux to Permissive and you should not need to force Permissive manually

    And no need for Strong Integrity was already answered by others (and for the mater of fact, the same was commented numerous times in this thread already)
    View
  • 61
    JarlPenguin
    JarlPenguin
    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
    View
    32
    Didgeridoohan
    Didgeridoohan
    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
    View
    29
    B
    BostonDan
    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.
    View
    27
    1nikolas
    1nikolas
    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.

    Play Integrity API Checker - Apps on Google Play

    Get info about your Device Integrity through...
    play.google.com play.google.com

    Source code:

    GitHub - 1nikolas/play-integrity-checker-app: Get info about your Device Integrity through the Play Intergrity API

    Get info about your Device Integrity through...
    github.com github.com

    GitHub - 1nikolas/play-integrity-checker-server: Node-js server for the Play Inegrity API Checker app

    Node-js server for the Play Inegrity API...
    github.com github.com

    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)
    View
    23
    1nikolas
    1nikolas
    UPDATE 1/8/2022
    This app is officially discontinued in favor of a new app I published on Play Store. Read more here:

    [Discussion] Google Pay Magisk Discussion Thread

    This thread is inspired by the PoGo Magisk...
    forum.xda-developers.com forum.xda-developers.com

    ====================
    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.
    Click to expand...
    Click to collapse
    View

New posts