[Magisk] pndwal:
A FYI...

Basic USNF functions (and basis for new experimental PIF builds)

Nb. These are to pass deviceIntegrity (necessarily includes basicIntegrity) verdicts when devices ordinarily collect hardware backed signals (attestation data) which are used for the deviceIntegrity verdict by default where keystore data is available... Nb. 2. strongIntegrity should not ever be met on B/L unlocked devices as no mechanism to allow 'basic' attestation signals to be used for this device integrity label is implemented... The current exceptions are clearly due a Google oversight (bug, vuln) that likely won't be extant for long.

Current USNF builds facilitate both

1) the main injection of code into gms droidguard (attestation) process (to register a fake keystore which causes the exception (error)) to trigger collection of "basic" evaluationType signals instead of those that would otherwise be hardware backed (on device) from droidguard, and

2) spoofing device properties (props) to bypass (server end) enforcement of hardware-backed evaluation type verdicts (ie. including the hardware-backed evaluationType signals expected on Android 8+ (Keymaster 3+) LV (launch version) devices) for devices identified as HK (hardware keystore) compliant (for strong integrity attestation purposes) but polling these properties...

Of course it also

3) adjusts another (long) list of 'sensitive' props to benign values when these indicate the presence of root or related modifications (as MagiskHide used to),

4) actively hides root from GMS, specifically from the Droidguard (attestation) process, and

5) adjusts several other device specific properties to ensure the module doesn't break hardware like (biometric) fingerprint scanners etc...

There may be other 'housekeeping' functions I've neglected in addition....

-----

Prop-based HK backed verdict enforcement bypasses

Regarding 2) above, we need to understand that to bypass Google's enforcement we must spoof mismatched props , ie. props not matching any on the Google blacklist. (Nb. this blacklist is to prohibit the use of 'basic' device integrity attestations in place of HK backed attestations.) Of course they will then also be a mismatch for props expected on your device. (These spoofed values now all are set to target GMS only to avoid issues... Other apps will still see the globally set original fingerprint prop (except in new experimental device attestation fix modules etc)...

The first bypass prop needed was model (ro.product.model) for S/N, and PI API continues to poll this prop...It was introduced when Google began enforcing HK backed verdicts on some (not all) HK capable devices and before PI API came online... While changing this prop to any unlisted value (eg "creamcheese") works, the mismatch is achieved in USNF simply by appending a space character to the real model value to avoid unnecessary issues...

The second became necessary only after PI API came online and Google began blacklisting based on fingerprint prop in addition to model... The fingerprint prop mismatch (ro.build.fingerprint), at least initially, was mostly needed (it seems) for A11+ LV devices... @Displax chose the currently used fingerprint ("google/angler/angler:6.0/MDB08L/2343525:user/release-keys", from Huawei made Google Nexus 6P) 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 (which requirement was later introduced in March 2018)...

The third affects all Android 13+ LV devices... Evidently Google are now blacklisting all devices shipping with Android 13+ first_api_level in PI API. When ro.product.first_api_level = 33+ (Android 13+), the value is reset to 32 (Android 12L) to achieve the mismatch...

🤠 PW