yashsingh1/xdaforums huggingface dataset:
[Magisk] 73sydney:
Some weird stuff there folks, sadly i cant comment as i departed Pixel after the 2XL because of the hardware issues post 2XL (i may be going back, somewhat reluctantly as i have been offered a 6 Pro at a good deal

Can you confirm if youre using shamiko and if the Enforce Deny List option is OFF in Magisk Manager's settings if you are....

Just for the record youre using the original Safetynet fix-MOD 2.3.1 right? have you tried uninstalling and using his later mod (MOD 2)?

Releases · Displax/safetynet-fix

SafetyNet & Play Integrity API workarounds for Magisk - Displax/safetynet-fix

github.com

Generally the only time i have seen Wallet -> Pay reversion is after clearing data for play services, and it takes some time (locking you out from opening it) as it "upgrades" back to Wallet...anecdotally this was noted by many during the period where people were scrambling when just plain old SafetyNet suddenly failed and Integrity Check was suddenly a thing and as Displax discovered the workaround...

Why its not automatically migrating to Wallet is puzzling....

And good call on font modules, people dont realise but even benign as they sound, they can give up the presence of root...

p.s. Just for an aside, as ive mentioned in here and main Magisk thread before, i havent even had Wallet (Pay before it) hidden for over 6 months (though most of the gang do)...so its not that on your end, its likely a services issue, but why....
[Magisk] pp085ster:
I do have a custom font installed via CFI, but my issue happens once I flash the USNF 2.3.1 MOD 2.0. If I disable that in magisk then I can go back into settings -> Google but I don't pass the verification checks. If I enable it however, I pass 2/3 verification checks but I can't go into Google settings. It's weird. Any help is appreciated.

I don't have Shamiko installed, but I do have the "enforce denylist" option ON. Attached the options I have selected on there.
[Magisk] Zilla0617:
I'm not using shamiko but I do not have Enforce Deny List off, should i? I am using Mod 2.0 of universal safetynet fix. When I updated to Nov Patch wallet came back (quick setting and lock screen still disabled) Unfortunately, my device was no longer certified in the play store so I deleted data and cache of play store and Google play services and it reverted back to the old GPay.

I hope you're right and wallet comes back after some time. I did this wipe before only to have GPay stick after Google play services settled. I read your advice back when you first mentioned it and have nothing hidden as well, I even deleted your GPay fix module and my transactions were working fine.

I'm currently using a module that changes font, but have no issues accessing Google menu, newer versions of it had the same issue of the inability to access Google menu within settings.
[Magisk] Zilla0617:
Google play services finally settled as it stopped keeping my device awake. I received a wallet update but it remained GPay. By chance do you know how long it will be for the switch to occur, (GPay to Wallet)?
[Magisk] Zilla0617:
I couldn't tell based on your response, but have you tried removing the font module and seeing if the issue occurs?
[Magisk] pp085ster:
You are the man! Indeed, apparently had to do with the font. It's a pity though cause I really like the font I was using. Does anyone know how to get around this limitation?
[Magisk] pndwal:
Just saw this yesterday while looking at Rikka's work:

https://github.com/RikkaW/FontLoader

Looks like it may be useful, but have no idea; please report success/failure!... 🙃 PW
[Magisk] m0han:
... is a Zygisk module. If you come across anything like this that works with Riru, please post.
[Magisk] pndwal:
Yeah... Funny how Rikka's moved to Zygisk despite her Riru largely inspiring it!... 🙃 PW
[Magisk] cadukmandi1337:
doesn't work sir, installation failed, your system API of 29 is less than the minimum api of 30? what, any solution? Magisk 25.2, rog phone 2 stock rom android 10, coz i got detected on ruru, Libc and Syscall file detection, the HMA is detected, i already use HMA beta 3.0.5, plz helb
[Magisk] 73sydney:
It does say Android 11+ API 30+ on the github page

The module cant modify a file that doesnt exist :)

Sorry but theres no equivalent function for Android -11

I am working on a Hide My Applist guide (with pictures) at the moment, that may help. Once i have that up, ill tag you and you can follow and see if you have it setup correctly and then also let us know what youre being detected on under those categories

For the majority of people Magisk 25.2 with Universal SafetyNet Fix (Mod/Mod2) by Displax, and Shamiko (Deny List NOT Force enabled) is enough to pass Integrity test (along with clearing data for Play Store and Play Services)
[Magisk] 73sydney:
As promised, linking you to the newly completed HMA guide:

Hide My Applist - A Brief Guide

Hide My Applist Guide Hide My Applist is a LSPosed module by Dr-TSNG (nullptr). Often referred to as HMA. In the simplest terms HMA aims to stop one app detecting a list of other installed apps. - It can often help stop your banking app(s) from...

xdaforums.com
[Magisk] V0latyle:
Shamiko isn't even required in most cases I believe. Play Integrity does not detect Zygisk and in fact has no way to do so.
[Magisk] 73sydney:
Sorry, i guess i quote it mostly as a solid base for everything after...
[Magisk] V0latyle:
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.
[Magisk] pndwal:
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:

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
[Magisk] Minecraftitsover90:
https://androidpay-users-pa.googleapis.com/cm/t/security/getstoragekey?forcehl=1&hl=en-AU

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?
[Magisk] pndwal:
So please confirm that you are actually using a @Displax USNF mod build, and show results of Play Integrity API Checker app incl. Raw JSON response (hit the '< >' symbol after running check)... PW
[Magisk] Minecraftitsover90:
Oh I didn't even realise there was a fork of it.

I was using the kdrag0n version of it and it didn't work.
[Magisk] pndwal:
Oh.. not sure how you 'tried all the known methods' if you didn't read back here at all! 🤪 PW
[Magisk] Minecraftitsover90:
Anyways

{

"apkCertificateDigestSha256": [

"CFMi+R9OCRrIqon0WdOwQgA4I9aG0m1sYPZuUf5a2ns="

],

"apkDigestSha256": "6eSwd6Ed+f4Pab9sXTvk+hqbA8VFtfdCnYlznf+zIbc=",

"apkPackageName": "rikka.safetynetchecker",

"basicIntegrity": true,

"ctsProfileMatch": true,

"evaluationType": "BASIC",

"nonce": "MDY0ZWFlMGQtMjhmMC00YjdjLWIzYzItNWVlMTA0YzY0NDg0CjIwMjItMTItMDlUMjM6NTA6NTkuOTM0KzEwOjMwCnNhbXN1bmcvYTcxbnN4eC9hNzE6MTEvUlAxQS4yMDA3MjAuMDEyL0E3MTVGWFhVM0JVQjU6dXNlci9yZWxlYXNlLWtleXMKMzAKMjAyMS0wMi0wMQo=",

"timestampMs": 1670592069860

}
[Magisk] Minecraftitsover90:
I didn't use the right app right or is this correct info?
[Magisk] Minecraftitsover90:
Also
[Magisk] pndwal:
Yup... You're not using the app I specified here... That's checker for deprecated S/N...

Anyways, you found the known new PI checker!... 😜 All good then... 😛 PW
[Magisk] Minecraftitsover90:
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.
[Magisk] 73sydney:
thats by design it stops people (like you) from selecting it when it *can* break things and its totally unnecessary...

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

SafetyNet & Play Integrity API workarounds for Magisk - Displax/safetynet-fix

github.com

please stop trying to break things....
[Magisk] Minecraftitsover90:
but i was following this guide originally

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
[Magisk] 73sydney:
It doesnt tell you to try and hide Google Play Services....
[Magisk] Minecraftitsover90:
Well somewhere I did then
[Magisk] pndwal:
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
[Magisk] ipdev:
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:
[Magisk] pndwal:
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... 😉

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... 🤔

... 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!...

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
[Magisk] ipdev:
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."​

Spoiler content hidden.

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

Spoiler content hidden.

Only after..

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. 🙃​

Someone points out they are enforcing the denylist.

Even though Shamiko notes that it is not working because denylist is enforcing. 🙃​

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." 🙃​

👍

Same here. 🙂

Cheers. :cowboy:
[Magisk] Minecraftitsover90:
So what can I do now?
[Magisk] pndwal:
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
[Magisk] Minecraftitsover90:
I

I am now using a @Displax USNF mod build and also I think I lost device integrity when I went to add a card in Google Pay/Google Wallet maybe when it went to contacting your bank or when I clicked on set up payment card.
[Magisk] pndwal:
To be precise, Enforce DenyList needed to be disabled to edit/modify it... I think it was accessible as Shamiko was already using it as a hidelist when not enforced...

Ah... So no modifications were allowed before Allow modifying denylist without enforcement even at boot-time! (ie magisk --denylist
DenyList Config CLI rm PKG [PROC] wouldn't work when not enforced?)... I hadn't understood this; thanks!

Fair enough... I was considering having dual root hiding methods (Shamiko + inbuilt USNF) applied to gms could cause issues and be a reason... If removal was 'erroring out' as you state below, we would have had dual hiding occuring w/ Shamiko before Allow modifying denylist without enforcement without issues anyway...

Is second case really an error or just status?

In terminal at least now I don't see 'true (0)' or 'error (1)', only 'Denylist is enforced' and 'Denylist is not enforced' respectively...

Ah, @kdrag0ns statement 'never load' needed qualifying... Thanks... Seems means 'never load in processes in (enforced) denylist' in reality... (dev speak / user speak?)

FWIW, I think denylist entries mean Magisk "reverts all changes it had done" (as you cite below) immediately, and also "denies further modifications" in these processes, ie it does 'never load' as he says in listed processes rather than needing to be "unloaded every time gms is called"... Praps I'm missing something here to... another fine point anyway...

So guess this still means CTS Profile Match should have been failing w/ gms in denylist... How did I miss this?(!)... Wait... I'll test again...

Yup, I'd missed it previously! 😬... w/ droidguard (attestation) process (com.google.android.gms.unstable) in denylist and DenyList enforced i get this:

Nb. Selecting main gms process (com.google.android.gms) does not affect the result on my device... Unless droidguard process is added RN8T w/ A10 MIUI passes deviceIntegrity... Guess on A11+ devices where Magisk is not in /sbin com.google.android.gms in denylist may also break USNF...

Yup... But perhaps enforcing denylist means Magisk modifications 'are never loaded' in called/spawned processes rather than needing unloading as @kdrag0n parlance suggests...

This seems to be what John was implying by "Magisk denies further modifications [after a process is added to denylist] and reverts all changes it had done [before it was added]" also... - Insertions are mine, but I think I'm interpreting this correctly(?).

Quite. 😁

Seems like mine, your photographic memory needs developing... (😝)

... More to follow... PW
[Magisk] pndwal:
Continued...

And this really sums up the whole need for

"magisk: Remove Play Services from DenyList …

The Zygisk module will never load if GMS is in the DenyList..."

I did envisage issues with multiple hiding solutions operating on one process as covered above, but these haven't been demonstrated anywhere...

However while denylist does hide by virtue of 'Magisk getting out of the way', it actually prevents Magisk modifications from affecting selected processes at all, unlike. hiding solutions, so any Zygisk based injection of code into a forked zygote process that loads and runs a new app's code cannot occur for instance.

Since USNF's key function works this way it must fail when gms droidguard process is in (enforced) denylist:

I believe that the various targeted prop changes needed to trigger hardware based verdict enforcement bypasses in S/N and PI also use Zygisk, so these functions will fail also...

I have to agree that it's the nature of denylist that necessitates the removal of at least the gms droidguard process from denylist (although I still think merely instructing users is to do this manually where needed is all that is needed and would actually cause less confusion)... 🙂

Anyway, thanks for helping me properly connect modification denial with the reason for magisk: Remove Play Services from DenyList commit. 👍

😂

🤣

I didn't mean to suggest that Shamiko users were dumb enough to enforce denylist... USNF would remove gms processes on next boot anyway...

Shamiko should really note somewhere that hijacked denylist really = hidelist, if only to create an excuse to fall about laughing at the confused gringo-user posts suddenly appearing in LSP TG threads everywhere...

😭

😋PW
[Magisk] pndwal:
That would be strange...

Did you do the wipe and try again?... disable USNF, reboots?... Removed all gms processes from denylist?...

Try the above again with ALL modules other than USNF_mod disabled... Ensure Zygisk = Yes in Magisk App home screen... PW