[Magisk] pndwal:
Just a bit of clarity on basics of how USNF and forks (inc. PIF) work as there's clearly quite a lot of confusion...

To get passing verdicts, keymaster 3+ compliant devices (Android 8.0+ devices excluding many of those where OEM messed up implementation) need USNF (or similar solution) to

1) produce the fallback to cause Droidguard VM and GMS to supply BASIC-only measurements/data to Google backend. This is USNF's key function and since 2.0.0 (Riru) has been achieved simply by injecting code (now using Zygisk) into gms to register a fake keystore, and in turn this produces an exception (error) that results in the fallback to BASIC-only measurements/data. Previously, replacing or 'shimming' the keystore had various measures of success in producing the needed fallback...

This works at device level and was always required where keymaster 3+ works because mixed BASIC and HARDWARE_BACKED signals will be collected by default in such devices and this necessarily results in failing DEVICE_INTEGRITY verdicts since the hardware backed signals cannot be spoofed and and contain 'strong' attestations to bootloader state (Unverified or SelfSigned) etc, etc.

At a later time, Google started to 'enforce' such HARDWARE_BACKED evaluationTypes (really means Google servers automatically fail BASIC-only attestations by blacklisting devices identified on the basis of various device prop(ertie)s for verdict passing purposes), so USNF began to

2) bypass hardware-backed verdict enforcement. This secondary function is achieved by ensuring that the prop combinations used to identify devices Google has flagged for enforcement of hardware-backed attestations for some measurements/data never match expected values for the device. Ie, this bypass is purely based on simple prop combination mismatches. This works at server (backend) level since the data/measurements are processed by Google to generate the cryptographically-signed attestation to the device's integrity bound to the nonce that the caller app provided...

This is not always required; some or all props USNF handles may need altering per device... Many devices that don't have official Android 11+ ROM updates for example, need no prop based HARDWARE_BACKED evaluationType bypasses at all despite requiring the fallback trigger (1) to work...

So far Devs have discovered that the following props polled for hardware-backed verdict enforcement need altering to create a mismatched prop combination sufficient to bypass the enforcement, and USNF uses targeted spoofing (in gms only unlike MagiskHide Props Config module's global changes) to adjust their values:

- a) ro.product.model for both S/N and PI... While not all devices require this, USNF always appended a space character to model value originally in order to create the mismatch needed by some devices; in PIF, @chiteroman now simply uses model value associated with the mismatched fingerprint (b) to achieve this... Any value including phone models sporting hardware keystore/Keymaster 3+ worked in practice since it's the the prop combination (model, fingerprint and more) that must not match values Google expects/uses for blacklist purposes. Nb. While most device specific functions should not be affected since the spoof targets GMS Droidguard/attestation process only, when users log in to Google accounts the spoofed model may show for some devices.

- b) ro.build.fingerprint for PI... Mostly A11+ devices initially required changing this value as Google began enforcing on the basis of fingerprint regardless of model value... USNF originally applied a passing (CTS/VTS certified) old Nexus 6P (angler) or Pixel XL (marlin) fingerprint prop universally... Now PIF has applied various others... Nb. These must simply not be on Google's blacklist (ie not match expected values) and pass CTS/VTS profile matching by being properly signed/genuine and either being old enough to predate the (March 2018) requirement for security patch prop (ro.build.version.security_patch) date value to match the fingerprint prop value, or the corresponding security patch prop date value must be ascertained and spoofed in addition in order for the fingerprint prop to be valid... Also, there's actually NO need for the print to predate Keymaster 3 devices.

- c) ro.product.first_api_level for PI... A13 launch version devices require this mismatch, and shipping API level was generally set to 32 only for devices >=33... Now, PIF often uses values lower than 32.

Of course, USNF and forks do other things in addition, especially restoring functions previously performed by (now sunsetted) MagiskHide, ie

- Hiding root from the GMS Droidguard/attestation and main processes natively (ie. DenyList or HideList solutions are not required),

- Adjusting 'sensitive' (suspicious) prop values

as well as

- Setting a few extra props in specific devices to avoid breaking biometric and other functions,

etc, but the key takeaways from the above discussion are that the exception based on-device attestation type fallback (hardware backed + basic --> basic only) and the prop based server-end hardware backed evaluationType enforcement bypasses (HARDWARE_BACKED + BASIC --> BASIC-only)

are 1) entirely different things, and 2) USNF/PIF's principal functions...

👀 PW