yashsingh1/xdaforums huggingface dataset:
[Android Software Development] pndwal:
Nah... That'd be a confusing concept... I never suggested passing Hardware backed CTS!... Only killing USNF to fail all CTS attestation and see HARDWARE-BACKED as evaluation type (as this would indicate that Google still uses model prop based enforcement currently!!!)... Please do re-read what I said...

I simply want to know if someone with a late/up-to-date device using Magisk and USNF can disable USNF and say if they see BASIC or HARDWARE-BACKED Evaluation type in YASNAC app (since I'm wondering if Google has reverted model prop based hardware attestation enforcement recently) as I've said several times now...

Nb. Even with S/N showing BASIC Evaluation type in YASNAC app hardware-backed attestation may still actually be used since Sept 2021 as I mentioned in a post above... That's what happens on devices like mine where Google doesn't enforce hardware-backed attestation for API's...

Nah... They have broken keymaster implementation so could never pass Hardware backed CTS... Only Rog phone 3 can do that AFAIK since it has working keymaster implementation but broken droidguard attestation it seems...

See what?... I just misremembered what you said and thought you could pass S/N or PI deviceIntegrity w/o the bypass component of USNF on a late/up-to-date Xiaomi device... But now that's unclear... 🥴 PW
[Android Software Development] zgfg:
IMO, that was the magic word ("to fail") you forgot to say or I didn't have a concentration to observe in your novels

Ok, that makes sense - without USNF to see SN (but then the same for Play Integrity - but by opening the JSON response) FAILING but showing CTS Evaluation type Hardware

No, my two phones, both with Xiaomi.eu ROMs are not suitable for that tests
[Android Software Development] GT500x:
Hmm. I don't seem to be losing root... Based on everything I've read, I assume I should be OK with my current setup, would you agree? I.e. Magisk + USNF with just Wallet in the denylist and denylist enforced?

Thanks for your help.
[Android Software Development] pndwal:
Yup... Seems so... Root loss was just a thought, but I have no other ideas ATM, sorry... PW
[Android Software Development] pndwal:
🤷 IMO that's unnecessary... My first post

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88026669

was very clear...

'Novels' have been written since, even your first reply, because you didn't have the concerntration to read... and you kept confusing S/N's HARDWARE-BACKED Evaluation type response with "Strong-Integrity or Hardware CTS" (MEETS_STRONG_INTEGRITY or ctsProfileMatch = true) responses... Each is different... But your novels are interesting... 😅

There's nothing in PI response to indicate Evaluation type the PI API enforces, so I didn't mention the newer API so as it doesn't help and only complicates things...

Well given that I said "I'm trying to get HARDWARE-BACKED Evaluation type to show on either of my two Xiaomi unlocked devices" it's a bit obvious (a given) that it would be a failing result don't you think? 🙃

... So we're back to:

😜 PW
[Android Software Development] zgfg:
Good night man.

Not going to end up like your almost a neighbor
[Android Software Development] pndwal:
My almost-neighbor you mean?... Exactly what I was thinking! 😝 ... (Why disparage at all?)... Nite from antipodes... PW
[Android Software Development] iBART:
It used to work great, yesterday wallet stopped me to pay cause of device not fulfilling etc...

Today I tried YASNAC and i failCTS profile match, out of the blue.
[Android Software Development] knasiotis:
I have the same issue, exactly same behavior, after some minutes it fails, then some seconds later it passes. Miui 14 EU rom (stable) with mi 11 Ultra (star)
[Android Software Development] franky_z:
I was using the safetynet-fix-v2.3.1-MOD_2.0 modded by Displax. Then after Google One VPN suddenly stopped working I saw that in the backup section of the Google One app that my Pixel 7 Pro is recognized as "Huawei Nexus 6P" (don't know if that breaks vpn, some users also reported that Google One VPN stopped working). Same in the "Logged In Devices" section in the Google account on website. I tried some device information apps and there it is shown as Pixel 7 Pro.

Updated to Universal SafetyNet Fix 2.4.0 and its still regognized as Huawei Nexus 6P. Tried uninstall the module, reboot, clear data of Playstore and Google Services, reinstall, nothing helped.

I have read that some users have the same problem. Is there any solution yet?
[Android Software Development] pndwal:
Are you still running MHPC module w/ force basic attestation or device simulation props configured?... Just a guess! 🙃 PW
[Android Software Development] franky_z:
I only used safetynet-fix, didnt flash MHPC module...
[Android Software Development] GT500x:
After my last post I tried reflashing LineageOS, factory resetting, and starting over from scratch. Still having the exact same issue.
[Android Software Development] knasiotis:
Yeah it's very probable that google changed something with android 13
[Android Software Development] pndwal:
Actually, I forgot this:

@Displax's USNF mod and fix for PI deviceIntegrity verdict does indeed spoof Nexus 6P, this being the model for the mismatched fingerprint prop used to disable enforcement of hardware based attestation...

The ro.build.fingerprint prop is adjusted to an Huawei (angler) Nexus 6P iteration and should be targeting the GMS attestation process (com.google.android.gms.unstable) only with this very low API level (Android 6.0) print to ensure no device using the fix has a matching API level... Also, using old prints negates the need to match print with security patch date in order to pass CTS Profile match... See:

Drop fingerprint to lowest possible …

To ensure that no one use same Android version

- Original commit set Marlin (Android 7) print:

Import low "marlin" fingerprint

Nb. Since module uses zygisk to target only attestation process rather than set props globally, I'm assuming Google gets your device model from this process via their Play Services back end... I'm not a Pixel user so can only guess that this may affect your backup utility, VPN and more...

I'm also guessing that this may already be fixed in official 2.4.0 as while @kdrag0n presumably uses the same print, he's only spoofing this part-time having 'found a way to bypass Play Integrity that doesn't require spoofing the build fingerprint permanently to make sure the module doesn't cause any unnecessary breakage. This should minimize adverse effects by spoofing dynamically at runtime only when necessary.'

My guess is that Google have cached your device details - I believe they do this when you set up an account - so they likely have the print prop Huawei value from when you were running @Displax's modded USNF build... This likely remains (even after updating USNF) until you refresh your Google account or set up a new one for your device... Google may also check prop values periodically and it may just update eventually

...

... Of course I'm only guessing at the behaviours I've proposed above; the issue may still exist w/ official 2.4.0, but the above is my best guess and status-when-making-account may also explain why some phones reportedly show up as Pixel 7 Pro and others as Nexus 6P...

And I just remembered commenting on this issue here back in October:

https://xdaforums.com/t/january-3-2...7-pro-cheetah-safetynet.4502805/post-87633679

Incidentally, that thread would be you best bet for sounding out this issue further...

Hope it helps. 🤠 PW
[Android Software Development] franky_z:
I removed my Google Account, rebootet and logged in again, now Google One shows the right device. Thank you!

*vpn still does not work, but this I think is a different problem, here is the thread if some have the same problem:

https://xdaforums.com/t/vpn-not-working-anymore.4541685/page-2
[Android Software Development] osm0sis:
Nope. Unrelated. Everything's still janky as ****. 🙃
[Android Software Development] Lada333:
I was able to use tap to pay about 20 minutes ago, then 10 minutes later it no longer worked. Is paying using Google wallet broken for anyone else?
[Android Software Development] GT500x:
Maybe same issue we're having.

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88029829
[Android Software Development] osm0sis:
I have noticed YASNAC sometimes failing CTS with 2.4.0 as well, especially directly after boot. This wasn't the case with 2.3.1-MOD_2.1 that I've seen.
[Android Software Development] GT500x:
I installed 2.3.1-MOD_2.1 and so far it looks good!! Guess 2.4.0 needs a fix... Thank you!
[Android Software Development] Nergal di Cuthah:
I couldn't reproduce this, on my p6p, but isn't yasnac not the thing for checking since play integrity is in effect now
[Android Software Development] osm0sis:
Not fully phased out yet, and any gap in coverage is still suggestive of something being wrong with however 2.4.0 is selectively and temporarily spoofing.
[Android Software Development] pndwal:
Bit further...

Google says S/N API will work (back end server support will remain) till June 2024... Older app versions using S/N API will error-out from June 2023 however if their Devs fail to migrate to PI with a newer version build by this time...

I assume this means that YASNAC will also fail to work from this June unless Rikka & Xingchen build an updated 'dummy' "Yet Another SafetyNet Attestation Checker" app migrated to the new PI device integrity API simply to validate the current apps S/N attestation until June 2024...

FWIW, I guess the dummy app would necessarily be a contraction in that it would really be YASNACTAOCPIA (Yet Another SafetyNet Attestation Checker That Actually Only Checks Play Integrity Attestation)! 🤪 ... unless YASNAC could be built to call both S)N and PI APIs...

Still, I hope S/N checker app (even other than YASNAC) Devs consider doing this as it would be good to be able to check S/N responses simply for as long as possible for PI deviceIntegrity troubleshooting purposes...

Eg if PI deviceIntegrity is failing, good clues re. the cause are obtained if we can see if ctsProfileMatch = true or not, or if evaluationType = HARDWARE_BACKED or not (which is an indicator for working model prop based bypass for hardware-backed attestation enforcement exclusively - later prop based bypasses for hardware-backed attestation enforcement don't affect this response - for devices needing that assuming fallback to basic attestation using broken keystore trigger is not deployed). Even having having access to S/N basicIntegrity is useful as certain conditions can result in PI basicIntegrity failing while S/N basicIntegrity actually = true...

In summary, S/N attestation checkers and the S/N API continue to provide useful and unique measurements while they are supported... I believe PI deviceIntegrity / USNF solution for PI troubleshooting will only become more difficult with the demise of S/N API support.

🤠 PW
[Android Software Development] pndwal:
@ipdev

As I said here:

... Since no-one has confirmed that Google still (recently) enforces hardware-backed attestation for device integrity APIs in any devices using model prop checks, please would you find late/up-to-date devices with Magisk and USNF (not integrated SNF) installed among your beautiful

and oblige me by naming

... I'd really appreciate having confirmation for even just one reasonably common device... 😀👍 PW
[Android Software Development] Lada333:
I have also reverted to 2.3.1 mod 2.0, so far so good. Will report back if it breaks in the future.
[Android Software Development] Shenuka:
Brother can you explain how to doit please
[Android Software Development] ipdev:
I really need to put stickers on them so I know what is what. 🤪

Alot of those devices are old and used mostly for backwards compatibility testing. 🙂

It is still device dependent.

"BASIC,HARDWARE_BACKED" or just "BASIC".

I though my N200 supported hardware backed testing. 🤔

Maybe that was only on Android 11.

I remember being surprised when I first got it and 'TEE' seemed to be fixed on a OnePlus device. 🙃

(Current stock is Android 12.)

Here we go. :)

- Stock system(s), let me know if your are looking for a result from a custom rom. 🤪

Spoiler content hidden.

Spoiler content hidden.

Spoiler content hidden.

Spoiler content hidden.

A good (not too good) deal I got that I have not been able to unlock yet. 🙃

Cheers. :cowboy:

PS.

Save for the 9Pro 5G, all rooted with current Magisk.
[Android Software Development] pndwal:
Wow, yes... We have a major problem Houston...

I Hadn't noticed this till two days ago... Google Wallet was working for contactless payments at lunch, but for coffee afterwards it failed with 'device doesn't meet security requirements'... 🙁 (FWIW, I may have rebooted phone during lunch...)

Checked and deviceIntegrity was good, but immediately after a reboot got failed verdict and minutes later all is good again...

FYI Google Pay/Wallet somehow monitors device security even while app is closed (likely Google gets telemetry if lockscreen pattern/password is removed, deviceIntegrity is lost, etc), and contactless fails on next use... This occurs after bad device integrity verdicts, or if a user disables lockscreen pin or pattern... even if this is restored before opening Google Pay/Wallet, bank cards may have already been removed... So even brief loss of deviceIntegrity at startup is catastrophic for G Pay / Wallet! 😬

To avoid intermittent Play Integrity failures I've reverted to @Displax modded USNF also; all seems good and can't reproduce failed verdict...

To fix G Wallet however, despite knowing it would likely just come right in about a week, I tried the immediate fix as it's worked for me in the past:

...Bit of a saga begins...​

Uninstalled wallet, cleared Google Pay and Google Play Services data, rebooted, installed wallet again only to get the familiar "Google Pay is Currently Updating..." Screen that never goes away! .... No problem... I covered a fix for this in "Current fixes needed for Google Pay / Wallet" linked here:

Post in thread '[Discussion] Google Pay Magisk Discussion Thread' https://xdaforums.com/t/discussion-google-pay-magisk-discussion-thread.3906703/post-87481637

... Tried both clearing data and rebooting as well as uninstalling/reinstalling and nothing worked this time!... Still stuck on updating screen!

Finally resolved after removing all Play Store and Play Services updates, clearing their caches only, uninstalling Google Pay (even latest version doesn't show as 'Wallet' until online 'App is updating...' completes), rebooting, re-installing Google 'Wallet' --> Finally G Pay opens and updates to Wallet successfully!... No more security issue for contactless payments since reverted to @Displax modded USNF... 🙂

...End of Saga...​

But this part-time spoofing based on new hooks is only for fingerprint prop mismatch (for some devices on Google's list for HKA based verdict enforcement in PI API) AFAIK ... My device (Xiaomi RedMi Note 8T w/ stock MIUI A10) like many A8, 9 & 10 devices, actually needs none of the three prop based bypasses we now have to pass either S/N or PI deviceIntegrity; I do need the principal broken keystore based fallback to Basic attestation to pass these however...

Because of this, I think the issue is something other than temporary fingerprint prop spoofing... Could it be that the fake keystore is registered so late that I can run Play Integrity API Checker before it breaks HKA?...

Anyone else had G Pay/Wallet failing after installing USNF 2.4.0?...

👀 PW
[Android Software Development] rodken:
I've noticed the same hiccup sometime early last week.

-- I was about to perform the same regime of clearing caches and removing updates.

-- My inclination was to wait it out to see if it would correct itself - which it did after a few days.

-- YMMV
[Android Software Development] EViollet:
Very interesting.

Yesterday I was on a buying spree, paying for low of things with my phone until this message. In the evening it was working fine again.

I was thinking it could have been some limitation because I was using Google wallet too much, but it seems the problem is much more widespread, which is rather worrying...
[Android Software Development] Gleniu:
Just wanted you guys to know, that today I woke up to "you can't pay with this phone because it doesn't meet security requirements" notification. When I opened wallet, I got pop up saying the same. But when I opened "configure NFC payments" in wallet, I got all options ticked. I tried to pay and it is working fine. I believe that Google is trying something once again :(

I'm using Redmi Note 10 Pro with MIUI 13, Android 12, SafetyNet fix v2.4.0.

EDIT: Now the wallet app says that my "phone doesn't meet security requirements" in "configure contactless payments", but I can add cards and I can still use them. I also failed "meet_device_integrity" in Play Integrity Check app once, and on the second try it worked just fine. I'm starting to think that it is just a bug on Google's side. Similar thing happened one year ago and it affected factory locked, unrooted Pixels and Samsungs.
[Android Software Development] osm0sis:
I also failed Wallet "meeting security requirements" and clearing Play Services and Play Store was the only way to get going again.

I started fresh with a clean Lineage install yesterday and even with USNF 2.4.0 set up to run from before initial setup lead to failed PI and SN, but reverting to 2.3.1-MOD_2.1 got it all working out of the gate on my next factory reset.

P.S. Move /data/adb into /data/unencrypted before a factory reset in TWRP, then move it back afterwards to retain working Magisk modules from the beginning setup of a ROM. 🤑
[Android Software Development] Gleniu:
Eh... I cleared Play Services and Play Store, reinstalled Wallet, and I can't add a card. I get MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY in Play Integrity API Checker, but it doesn't work anyway. Bye, bye contactless payments, at least for some time. Why Google, why... Hope you magicians can give us a fix soon.

EDIT: OOOOH YEEEESSS! Downgrading to USNF 2.3.1-MOD_2.1 by Displax fixed it for me!
[Android Software Development] pndwal:
Folks:

Clearly new 2.4.0 is failing intermittently for many, and Google Pay/Wallet users particularly are getting failures w/ 'Device doesn't meet Security requirements' message as Google monitors device security even when Pay/Wallet is not invoked... I recommend using @Displax's USNF modded fork at least until official USNF is updated... (I gave what clues I have in post above). PW
[Android Software Development] DartGerion:
Hi, guys!

Apologize for errors in writing, English is not my first language. For me the Gpay was working until today. I've checked the API integrity and receive the UNEVALUATED results with all integrity red. I've attached the denylist and magisk modules. Right now my USNF mod is 2.3.1 v2.0 (i know there is newest one, i've tried it with same results). Can you, please, help me identify the culprit. MOMO detects only wrong partition, so i think it's just the bootloader unlock. My phone is Oneplus 7T Pro, running stock OOS11, unlocked BL.
[Android Software Development] qetuol:
My contactless paying in Wallet suddenly stopped working a few days ago. Did anything happened? YASNAC still passes Google Play reports my device is certified. (im rooted with denylist and safetynet 2.4.0) I did not change anything and it worked a few days ago.
[Android Software Development] TioCareca:
2.4.0 sometimes fail temporary at boot and wallet detect that and stop working even if after sometime after boot safetynet pass.
[Android Software Development] thomas140:
Hi guys,

I have been trying many ways but to no workaround to pass the integrity and CTS profile test which caused me unable to bypass the banking and gov app.

I have to dirty flash the same Rom to remove magisk temporarily in order to use the apps which is very time consuming.

I'm using Poco F1 with info below:

- Miui Eu 12.0.3

- Android 10

- Latest Magisk Canary 25.2

- Google Play store device is not certified after magisk installed.

- Tried with LSPosed with XprivacyLua and USNF 2.4.0 (failed)

-Tried with USNF 2.4.0 only (Failed)

Please help if there is any way to settle this.

Really appreciate if anyone can help.

Cheers.
[Android Software Development] christantoan:
This is probably off-topic and if so, can anyone please point me to where should I post to ask for advice about general apps root avoidance?

Since its latest update, I've been unable to open this app (the app's apk is attached just in case it's exclusive to my region) because it detects that my phone is insecure. My phone passes PI until basic integrity so maybe someone with strong integrity verdict can help me check if the app requires it.

View attachment 5820903

For information, I've tried HMA and DenyList with Shamiko.

Thank you in advance.
[Android Software Development] qetuol:
I don't think it is 2.4, because it stopped to worked when I was on 2.3.2 (I can't remember for sure, but it was a previous version). I just updated to 2.4 after that to see if it was resolved.

What I start to think now is that Gwallet now checks the strong hardware integrity, not just cts.
[Android Software Development] pajn:
Nah, it works for me again after clearing everything and I'm only passing basic. However it will check even when not using it and if it fails once it's gone forever. So since the check fails sporadically wallet will stop working after a while.
[Android Software Development] pndwal:
Try clearing Play Services data and all modules disabled except USNF... Also, can use older @Displax modded build unless device launched with A13 (Pixel 7 etc)... And you don't need Play Store in denylist... PW
[Android Software Development] qetuol:
Can you please specify what did you clear? I cleared wallet cache and data but didn't help.
[Android Software Development] pndwal:
People have had failures w/ all USNF builds... Even stock devices were failing G Pay/Wallet device security checks at one point!...

However recent failures w/ 2.4.0 are certainly due to new changes/regressions specific to that build... See posts above...

Nah... Still Passing fine w/ PI deviceIntegrity... PW
[Android Software Development] pndwal:
Can be a challenge... See my saga above:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88049087 👍 PW
[Android Software Development] pulpf:
the latest version is v2.3.1-mod 2.1 and it works very well
[Android Software Development] pndwal:
What, w/o PI deviceIntegrity?

Not usually forever... Generally rights itself after some time (a week sometimes) w/o intervention as long as PI deviceIntegrity has not failed again in the meantime. PW
[Android Software Development] pndwal:
Recent issues here are with latest official USNF, 2.4.0... PW
[Android Software Development] pulpf:
with 2.4.0 I have neither the fingerprint reader nor the payment
[Android Software Development] DartGerion:
Tried clearing everything in Play Service and Play Market as well as disabling basically everything in Magisk except USNF, still doesnt pass the integrity. However the GWallet started working again.
[Android Software Development] pndwal:
So definitely Google Play Services? (Not '... for AR' etc?)... So G Wallet working without deviceIntegrity?... Please show YASNAC results also (after disabling all modules except USNF)... PW