yashsingh1/xdaforums huggingface dataset:
[Android Software Development] pndwal:
You'll just need to hide root from com.google.android.gms.unstable and probably com.google.android processes.

These are gms's attestation/droidguard and main processes... With USNF module, most devices running A11+ require both in denylist... W/o USNF just com.google.android.gms.unstable process may work, I'm not sure...

Shamiko is good proper root hiding so you can certainly use that... Denylist should also work as integrated SNF is not injecting code etc...

So remove USNF and the LSPosed solution, add the gms processes above and wait for ROM update/fix... Or move to a clean custom ROM... 👀 PW
[Android Software Development] immortalwon:
Wow! what a shame, did you change anything on your device to cause strong integrity to fail or did it simply just stop working due to what appears as Play integrity changes on googles end?
[Android Software Development] Displax:
Yes. Some new two blacklisted fields added: https://android.googleapis.com/attestation/status
[Android Software Development] immortalwon:
I got my answer, also did a quick google search

Trust but verify attestation with revocation

Billions of people rely on their Android-powered devices to securely store their sensitive information. A vital component of the Android security stack is the key attestation system. Android devices since Android 7.0 are able to generate an attestation certificate that attests to the security...

android-developers.googleblog.com

Apparently Google has godlike authority and can revoke any keys they want if they believe a device to be compromised. Guess they got their agents actively snitching in here
[Android Software Development] pndwal:
Ah... So G is watching modders or testing... Watching us seems more likely... Key revocation was bound to happen as Shawn Willden promised... To bad but... Party poopers? 😝 ... Nah, these Google actions are a no-brainer really...

www.twitter.com/shawnwillden/status/1278691557223411712

Do we know which are the latest?... Wonder if ROG Phone 3 is tagged for 'KEY_COMPROMISE' or 'SOFTWARE_FLAW'...

Thanks, PW
[Android Software Development] lm089:
So, having read the biggest part of this discussion I went ahead and ran YASNAC and Integrity Checker, both gave me a pass on BASIC, but fail on CTS / Device Integrity.

Checking PlayStore certification I saw that I had a slightly old-ish version, so I deleted data, rebooted etc, checked again. Still the same, but now it also said that certification failed.

Grabbed the ölatest available apk from APK mirror and installed it.

Result now is that Play Store app is V 34.something, but it claims my device was offline - which is not the case of course. I rebooted a dozen times but I can't get Play Store to reconnect.

I also tried to uninstall all updates of Play Store, reboot and reinstall latest apk, but it doesn't help either.

Before I completely mess up: anyone having an idea what is going on here? Thx!
[Android Software Development] pndwal:
Yup... And this:

www.twitter.com/shawnwillden/status/1237836365238337536?s=19

👀 PW
[Android Software Development] V0latyle:
Not sure this is the case. I only had to block GPay and Wallet, and I'm not even sure those were necessary. No system or other Google processes blocked, passed both Basic and Device. I'm only using USNF 2.3.1. mod 3.0. Pixel 5 on TQ1A 230205.
[Android Software Development] immortalwon:
The funny but sad thing is I doubt they even had the time to actually verify if the device itself is compromised. They arbitrarily revoked keys based on a random screenshot.

I could be wrong though, a billion dollar company could theoretically get a sample from the manufacturer. The timing though was way too quick.
[Android Software Development] pndwal:
🤔 ... Which custom ROM?

...But you're using USNF!... If your ROM really does integrate an attestation 'fix' (SNF) you should uninstall any USNF build and attestation should pass with nothing added if not rooted... if rooted you will certainly need to hide root from gms processes... 😬 PW
[Android Software Development] V0latyle:
Not custom, stock TQ1A

Dunno what to tell you....

View attachment 5833209

View attachment 5833203

View attachment 5833205

View attachment 5833207

View attachment 5833215
[Android Software Development] pndwal:
Well they likely perused submitted code when issuing certification for CTS/VTS but not carefully enough, and likely have simply confirmed a broken chain of trust implementation by revisiting the code... PW
[Android Software Development] pndwal:
Well the advice doesn't apply to your device then!... 🙃 You don't need to wait for SNF updates from ROM maintainer either!...

Only custom ROMs or customised stock builds can integrate fallbacks to basic attestation or bypasses for hardware-backed verdict enforcement... Other ROMs require Magisk root + USNF etc. 😜 PW
[Android Software Development] V0latyle:
I must have misunderstood you then. Maybe it's the American vs Australian thing, since we're on opposite sites of the globe maybe I need to stand on my head?
[Android Software Development] Olorin92:
Hey I have a similar setup to you (pixel with stock rom) - just out of curiosity, do you not need to use Shamiko? I thought at one point this was required so Google wallet and other things wouldn't get tripped....
[Android Software Development] V0latyle:
Nope. As far as I know, Shamiko is only needed when you need to hide root from apps that specifically detect it...if I'm not mistaken on its purpose.

Currently I don't even have DenyList enabled. I'm only using USNF 2.3.1 Mod 3.0...and that's it. Wallet works fine.
[Android Software Development] pndwal:
Actually, I think you just missed the members issue from the start. 😬

... For context, I posted this yesterday:

The user of custom PixelDust ROM asked:

You responded:

But the member wasn't asking if ROM-integrated prop changes/spoofing were implemented correctly... 🙃

The question was "How do i know if my custom rom integrates this?", meaning 'what indicates that the ROM does prop changes/spoofing natively, and that these might be conflicting with USNF module's settings?'...

The following convo was to establish:

1) that PixelDust does in fact spoof non-hardware-backed attestation capable device as well as ctsProfileMatch and non-Google-enforced hardware-backed verdict device

2) that the fix needed as a result of the latest Google changes therefore needs to be delivered by the ROM maintainer

3) that such custom ROMs (when working correctly) should simply have (passing) ctsProfileMatch and deviceIntegrity out-of-the-box...

4) that (when working correctly again) users of such ROMs who install Magisk should NOT install any USNF build anyway, but WILL need to hide root from gms processes (as described) since ROM doesn't implement root-hiding...

In short, users shouldn't install and will never need to install any USNF build... And of course if they do, they should remove gms processes from denylist...

Notwithstanding all this, I don't believe Americans and Australians are very different even though I'm neither...

However I can vouch for the benefit of standing on one's head as a way to gain perspective... I agree that you should try it... It's always worked for me! 🙃🙃🙃🙃🙃

Your antipodean friend, PW
[Android Software Development] pndwal:
Not for SafetyNet or Play Integrity deviceIntegrity while using USNF, nor for anything Google incl. G Pay/Wallet...

You will likely need it for bank apps that don't trust/rely on deviceIntegrity attestation and therefore detect traces of root using their own detection engines (like Promon) or other custom methods...

If you use the brand new XPosed module alternative to USNF from tehcneko:

https://github.com/Xposed-Modules-Repo/io.github.tehcneko.disablehardwareattestation

you will apparently need Shamiko for proper root hiding as disablehardwareattestation doesn't do it natively...

Nb. Hiding root from gms w/ denylist will break this attestation fix just as it breaks USNF due to preventing/reverting Magisk modifications in processes. However I suspect that other proper root hiding modules like the less sophisticated DenylistUnmount alternative will work in tandem with disablehardwareattestation despite the GitHub repo stating that Shamiko is required...

Nb. 2. I haven't tried disablehardwareattestation yet... I would be happy to receive reports on its benefits or usefulness...

No, it shouldn't be needed as USNF hides root from gms itself and other Google processes, eg Pay/Wallet, can have root concealed properly with basic denylist hiding.

However unlike DenyList, Shamiko can be used in tandem with USNF for hiding root from gms processes, so in view of recent USNF failures I am currently using Shamiko in conjunction with USNF to hide root from gms as an experiment per:

... So far so good... No further Pay/Wallet security warnings or deviceIntegrity failures for me to date!...

👀 PW
[Android Software Development] lm089:
Spent half the night to get back to where I was before messing up (see my post https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88127857). Now I'm nearly back at base with the following exceptions:

USNF is still V2.2.1_mod3.0, and I don't have the "original" playStore app but the one I d/l'ed from APK mirror.

Phone is working fine as before, but playStore still telling me I have no connection. And now Play Integrity API Checker is giving me a similar note "Error getting token from Google". Needless to say that I can access my Googledata from my phone, access privacy settings and drive etc.

I tried with and without putting play store and play services into the deny list, with and without Shamiko 0.6.1 etc.

Before I take a deep breath and do a clean new installation of LOS (currently backing up all my data) I'd love to understand what could be causing this. Anyone having an idea?

BTW: device is an OP6, running an unofficial LOS 20 ROM (see signature)
[Android Software Development] swieder711:
I'm on USNF 2.4. I am now failing CTS profile match and Strong Integrity.

My banking and corporate apps seem to be working and don't detect root.

Should I switch to USNF 2.3.1 Mod 3.0?

Edit: I switched to Mod3 and now pass CTS profile match. Strong Integrity still fails. Seems like this is the best we can do at this point. Stock P7P, unlocked bootloader and rooted.
[Android Software Development] gj4560:
Yes switch to Displax's mod 3.0 of USNF, if you are on a stock but rooted ROM or a custom ROM that doesn't spoof its props then that should allow you to pass CTS profile.
[Android Software Development] immortalwon:
Pm me what device you are using which originally passed strong integrity. You should have been failing strong integrity if your bootloader is unlocked. Don't post here your device cause there is snitches
[Android Software Development] V0latyle:
Strong integrity will never pass on an unlocked bootloader
[Android Software Development] shoey63:
Nah, did nothing. Strong integrity was working one day, the next day only basic integrity.
[Android Software Development] swieder711:
The upgrade button on magisk modules for USNF is triggering my OCD. Note to self: Must not hit button.

Hope to see Mod3 merged with V2.4 of USNF.
[Android Software Development] pndwal:
Guess you would have seen this?:

... True to their word, it seems Google has revoked keys needed for hardware keystore-backed verdicts... 🙃 PW
[Android Software Development] ipdev:
You can edit the module.prop file and comment out the last line.

/data/adb/modules/safetynet-fix/module.prop

Change

updateJson=https://raw.githubusercontent.com/kdrag0n/safetynet-fix/master/update.json

Add # to the beginning of the line to mark it as a comment.

#updateJson=https://raw.githubusercontent.com/kdrag0n/safetynet-fix/master/update.json

No more update channel, no more update shown. 🙃

Cheers. :cowboy:
[Android Software Development] shoey63:
Absolutely I saw it.

I replied to make it clear that it's all on Google's end. I did nothing myself to trigger the change from hardware backed to basic only.

My apologies to anyone who may have bought a ROG 3 based on my previous flaunting of being able to pass hardware backed attestation 😊
[Android Software Development] zgfg:
Wondering, if you took short time to read something from the previous posts, how many times it was commented that with unlock Bootloader you CANNOT pass Strong Integrity
[Android Software Development] SotYPL:
I can use wallet just fine on on my P7 feb patch with usnf mod 3.0 and shamiko but Chase bank app detects root when I try to add new zelle recipient. It was working fine before but it's not feb patch that broke it because my wife's P7 is still at january patch and it also stopped working. So it's either chase update or something else that google did. Both phones passes basic integrity and CTS profile in YASNAC and device and basic integrity in API checker.
[Android Software Development] lm089:
Not working for me. Did a complete clean install after I had messed up last night. I'm now up and running. Just to be sure I did an entire uninstall USNF MOD3 > reboot > re-install USNF MOD3 > reboot. But both YASNAC an Play Integrity API Checker just give me a pass on BASIC :(. And PlayStore complains of not being certified. Apparently all apps appear to be running fine, but the situation is making me kind of nervous. Probably that's the biggest problem here :D

What I have: OnePlus 6 running an unofficial LOS 20 (see signature) with TWRP, Magisk 25.2, USNF 2.3.1 MOD3.0, no Shamiko, no propsConfig. DenyList holds some apps that used to complain in the past (fainancial, car rental and ticketing etc.). Currently also PlayStore. I tried without PlayStore in deny list, but that doesn't seem to make any difference. I also tried USNF 2.4.0 instead of the modded one, btw. Again, no difference.

I'm sorry that this has all been asked before; I read approx the last 10+ pages in this thread here but have to admit that I just don't get it
[Android Software Development] immortalwon:
I was going to but google was too quick. We learned a valuable lesson though, if you have a device that can bypass HARDWARE attestation, keep it secret or bleep out important parts of the image haha
[Android Software Development] crypticc:
Assuming you've added all the subprocesses of the sensitive app you mention...I?

If so in my experience you will need following because it detects both developer mode (I think usb or WiFi debug to be specific) and Magisk apk:

Ensure developer mode disabled

Rename Magisk app using that setting in Magisk

AND Install ice box and add the hidden Magisk app into the ice box

Freeze Magisk

And then:

Wipe the bank app data then reboot again

Try your app again

Apologies if you've already done all of this.

Looking forward

For safety I always pause my sensitive apps whenever defrosting the renamed Magisk. And

I try to remember re-freezing Magisk before unpausing the app. (The ice app auto freeze seems temperamental to me)
[Android Software Development] crypticc:
Update:. Where the app @SotYPL mentioned continues to work. C iti app "technical" update that was released 3 Feb fails even with all those steps and the "isolated" processes on deny list.

This is with device and basic integrity passed, CTS also passed, wallet working, and freshly wiped and installed bank app. Checking permissions the only announced permission that Citi has that feels non standard is query all packages and run at start-up. Wonder which app it's looking for?
[Android Software Development] SotYPL:
Citi from 2/7/23 works for me without any additional steps you mentioned. It's just on magisk DenyList and Magisk is renamed.
[Android Software Development] crypticc:
V6.9 ? P.s. this is UK, was released 3 Feb
[Android Software Development] SotYPL:
So I guess we have completely different Citi app in US. My version is 9.58.1
[Android Software Development] Displax:
So, here is my new modification of USNF with Play Integrity API bypass.

It is now based on top of original v2.4.0 codebase instead of v2.3.1, with adding new hiding algorithm for current realities and some code refreshing.

Changelog:

Version 1.2

* Fix crash and endless tests loop/failing on Android < 9.0 (bug from original version 2.4.0).

* Do not unpatch (revert) changes. To prevent possible tests failing after a while on some ROMs (cross conflicts).

Version 1.1

* Fix KeyStore hook desynchronization (tests randomly failing problem).

Usage:

1. Delete/disable/reset MagiskHidePropsConfig (if installed).

2. Just install it over old Universal SafetyNet Fix and reboot device.

3. You may be needed to wipe GMS data (not cache) if there is no result immediately.

Source code: https://github.com/Displax/safetynet-fix/tree/dev
[Android Software Development] gj4560:
Some initial interesting behaviour I've found with this module is that if I run a test in YASNAC, both basic integrity and CTS profile fail (even after reattempting the test). However, if I then run a test in Play integrity API checker, both MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY pass, and if I go back to YASNAC and run a test, then basic integrity and CTS profile pass. I'm not sure why that happens and I hope in the period that both are failing it doesn't cause Google wallet to break (unless that is an issue with YASNAC itself).
[Android Software Development] Snowblind1991:
Thank you! Now even custom ROM (PE13+) have CTS check passed. You are a true magician!
[Android Software Development] Snowblind1991:
It didn't pass neither CTS neither basic in yasnak for like 10 secs, but then started to pass. Maybe it just requires time to load.
[Android Software Development] Snowblind1991:
Oh well, seems it starts to pass both tests after 3-4 scan in YASNAC. Hope it's just the way how it works then.
[Android Software Development] Displax:
Yes. Do not try to check SN/PI to early after reboot. Need some time for module to launch after system sturtup.
[Android Software Development] V0latyle:
Works for me, was on 2.3.1 Mod 3.0, now on 2.4.0 Mod 1.0
[Android Software Development] osm0sis:
I think this is exactly what's wrong with 2.4.0 in general though... PI and SN are failing due to it starting too late.
[Android Software Development] Displax:
Yep, but it is not big deal I think
[Android Software Development] crypticc:
And for banking apps that (per Google play) have permissions to run on boot? ^ above. Or don't they really?

I don't mean to diminish the efforts you've done at all of course. Constant gratitude to the folks like you that keep this scene going

Thanks

Chris
[Android Software Development] gj4560:
Funnily enough my bank doesn't really care about root, I just got a warning about it the first time I signed into the app and never again since. Didn't need to hide root or anything. I just hope the delay in the module starting won't cause Google wallet to break.
[Android Software Development] Displax:
No third party applications trying to check SN/PI status immediately after/during boot (at least I haven't seen them), usually they check it every time after opening.
[Android Software Development] pndwal:
Your signature indicates your ROM integrates an attestation (safetynet) fix: "[𝑹𝑶𝑴][𝟏𝟑]LineageOS 20.0 unofficial[𝑶𝑵𝑬𝑷𝑳𝑼𝑺 𝟔&6T][Gapps][OTA updates][

SafetyNet

][TWRP]", so this applies:

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

The issue of ROM-integrated device integrity attestation fixes conflicting with Magisk module USNF may depend on the way Rom Devs/maintainers implement spoofing, but many custom ROMs seem to have this issue... 👀 PW
[Android Software Development] osm0sis:
I think Play Services can check it directly after boot though, which then caches that failed attestation, and that's why we started seeing Wallet failures, etc. with 2.4.0...
[Android Software Development] Displax:
Might work with 2.4.0_1.0
[Android Software Development] pndwal:
But this is the reason many have reverted to your builds!...

The issue may not affect 3rd party apps but it is real and breaking Google Pay/Wallet for reasons I've mentioned here several times. Eg:

The contactless payment setup message "Device doesn't meet security requirements" may suddenly appear after a few days or after a restart, but the issue is real and due to Google full-time monitoring of device security inc. password/pattern lock removal, banks have sometimes already removed their cards from users G Pay/Wallet and sent an email regarding security concerns before G Pay/Wallet app has even been used/invoked...

I haven't tested your latest build so something may have now changed, but I'm sure we'll see reports here from other G Pay/Wallet users...

I put a comment about this problem in this open issue:

https://github.com/kdrag0n/safetynet-fix/issues/248#issuecomment-1405942010

We had perhaps a week or two before Google made their latest changes (affecting devices enforcement of hardware-backed verdicts w/o matching fingerprint prop to additional props) to test 2.4.0, and the issue showed up within days of its release... This is important to note since there has been much confusion about the two seperate issues, namely:

1) Intermittent loss or late application of attestation fixes, and

2) Google changes breaking deviceIntegrity...

Hope this helps, 👀 PW
[Android Software Development] Fishawy:
And that's exactly what happened now with 2.4.0 MOD 1.0: Integrity and YASNAC pass after few minutes, but Google Wallet's "doesn't meet security requirements" is here on my P7P.

Unfortunately wiping GMS data doesn't help, and neither reverting to 2.3.1 MOD 3.0.
[Android Software Development] gj4560:
I just preemptively reverted to 2.3.1 mod 3.0 in case the same happens to me. I'm on the same phone and the module having a delayed start definitely seems like it could cause issues at some point.
[Android Software Development] pndwal:
Something like that is definitely occurring...

G Pay/Wallet itself doesn't get disabled, but "Pay contactless setup" can be disabled with "Device doesn't meet security requirements" and banks informed of security issues even in the background / between G Pay/Wallet sessions...

I don't know which APIs are collecting/sending the data since I'm not sure if Play Services monitors screen-lock pattern/fingerprint changes etc, but guess gms may be monitoring deviceIntegrity full-time while it or some other app/API monitors screen lock status... Either way several indicators of tampering seem to be monitored full-time for G Pay/Wallet and it's back end may be informed of security issues w/o contactless payments being invoked...

... Seems we already have confirmation above that @Displax's current 2.4.0 based modded USNF build doesn't fix this issue...

🙃 PW
[Android Software Development] ipdev:
A while back, HuskyDG suggested I include killing GMS on boot complete.

I did not see a difference when I tested with it included.

Nor did I get an answer when I asked why I should include killing GMS.

What else would you expect. HuskyDG seems to avoid answering direct questions. 🙃​

usnf/magisk/service.sh at testing · ipdev99/usnf

Google SafetyNet attestation workarounds for Magisk - ipdev99/usnf

github.com

---

I am currently using MOD3 (with slightly different scripts). 🙃

Do you think killing GMS after boot complete would help with the (10 second delay?) using USNF base v2.4.0?

Might be enough of a delay for GMS to restart after killing it on boot complete? 🤔​

Cheers. :cowboy:
[Android Software Development] frostyboy_in_aus:
Pixel 7 Pro, Jan update, stock rom.

Play Integrity Checker - device integrity and basic integrity passes

Play Store is certified

Citibank AU is working

My problem is with Wallet - I am unable to add any card to it. When I click "Add to Wallet", it says the card could not be added and to try again later, and if I go to Pay Contactless Setup - Add a payment card - a circle keeps spinning and then I am taken back to the "finish setting up contactless".

I have cleared data and cache and rebooted many times for Google Play Services, Play Store, Wallet, Play Protect, Google Services Framework.
[Android Software Development] pndwal:
What does Pay contactless setup say re. meeting security requirements? PW
[Android Software Development] frostyboy_in_aus:
It has a tick "Your phone meets security requirements".