[Magisk] pndwal:
I see posts have come and gone here...

I started to answer some concerns here that may seem legitimate if basic functions are not understood however... Didn't have time to finish and post till now, but wanted to provide some of the nuts and bolts of "Play Integrity fixes" currently available for modders (USNF, PIF + ROMs integrating a 'SNF') as well as some of their evolution... I hoped that this might edify users and alay concerns, so I've finished it... It's also all publicly available information but, of course, not all modders have investigated thoroughly...

Yes, fingerprint prop mismatch is needed for bypassing server end hardware-backed verdict enforcement... Must be a passing print and generally security patch date must match, but the matching patch date isn't needed for old fingerprints so Devs simply choose one that will work universally... More below...

Yes... Injecting code to register fake keystore is the principle function... This causes an exception which causes the fallback to basic-only attestation... Some prop changes targetting GMS are also essential to allow for server end acceptance of such a basic-only attestation... Some devices using keymaster 3+ (ie hardware backed attestations) still only need the exception trigger (no prop based bypasses), however others needed model prop model mismatch (generally a space is simply appended to model) for SafetyNet and Play Integrity APIs, next Google started blacklisting devices for basic-only PI API verdict use on the basis of device fingerprint (nb. this wasn't implemented in S/N) so USNF added the fingerprint spoofing mentioned, and lastly they blacklisted all devices launched with A13+ on the basis of shipping level prop so, only for these devices, first API level is changed from 33 or 33+ in future to 32...

Seems highly unlikely hackers could use USNF functions (unless you downloaded from a bad source or they have been otherwise able to disguise a nefarious root mod as a USNF build/fork on your device 🤔) since the only GMS process that is spoofed is the Droidguard/attestation process, and it is only responsible for communicating device and app and integrity and app licensing (account details) measurements... Also, these spoofs only include 3 main props for the mismatch bypasses, a fake keystore registration for the on-device fallback to basic attestation, a couple of additional prop changes to prevent fingerprint scanners etc from failing on certain devices, as well as the sensitive prop adjustments previously handled by MagiskHide... They don't involve altering anything that might identify specific devices like account details etc although Google/GMS does poll such info of course.

The issues both @kdrag0n and @Displax wrote of in USNF PRs etc were generally just the issues @Didgeridoohan also covers in MHPC documentation... Simply, global prop spoofing can cause unexpected issues, particularly the three primary props USNF adjusts... Generally these are device or OEM specific functions, eg backup facilities, OEM appstores like Galaxy store, high-end camera functions, even (lately) VoWiFi... Therefore prop changes targeted GMS Droidguard process only are best. (Nb. @Displax's mod 1.3 does this for model and fingerprint but unfortunately he didn't produce an update with targeted spoofing for shipping level... It's set correctly but globally so Pixel 7 series users can have issues with VoWiFi etc making @chiteroman's PIF fork better for A13 launch version devices as it now does do targeted shipping level spoofing.) Further, with 2.4.0 @kdrag0n introduced part-time spoofing (only at GMS Droidguard process runtime) as he anticipated that even with targeted spoofing further such issues may be experienced... Unfortunately official 2.4.0 had timing and other issues and he hasn't updated it. @Displax produced several fixes for this meant to be an interim fix only, but official still remains unfixed (works well enough for banks for some but not all... Google Pay/Wallet users have consistent issues with it)...

FWIW, USNF used old angler fingerprint ("google/angler/angler:6.0/MDB08L/2343525:user/release-keys", from Huawei made Google Nexus 6P) as soon as a fingerprint mismatch was needed to bypass server end hardware-backed evaluationType enforcement for some devices until @Displax's 2.4.0 mod 1.3 (as a very old passing fingerprint from Android 6 would a: ensure that the mismatch is achieved for all HK capable devices, and b: negate the need for adjusting security patch prop (ro.build.version.security_patch) date value to match the fingerprint prop value used, a requirement introduced in March 2018)...

The walleye print only began to be adopted with certain custom ROMs like XiaomiEU to achieve STRONGINTEGRITY based on Google's fake passing strong verdict for Pixel 2 devices launched with the first of 3 shipping API levels (apparently to allow early models to pass STRONGINTEGRITY when locked despite having broken Keymaster implementations) when it was discovered that this could be exploited... Soon, @chiteroman was producing PIF builds using walleye print to achieve the same, and @Displax produced his strong passing mod 2.0... Of course Google have since patched this embarrassing (conceited?) vuln/bug/internal spoof, so walleye print no longer benefits modders really... I expect that if @Displax does supply an updated USNF I expect it will revert to the angler print... I'm not sure if PIF has restored this; it may still be spoofing walleye... So use of @Displax 2.4.1 mod 2.0, a PIF build, or custom XiaomiEU or other custom ROM that followed suit would account for your device being seen as Pixel 2, and rest assured it's quite by design.

Hope this clears up some concerns about the functions of USNF and forks... 🙂 PW