[Magisk] pndwal:
Thanks mate... I know I often present a WOT but, for those who make an effort to scale it, the view will improve from the top...

Here's another one for you, just because I feel some are still driving the car without fully appreciating what's going on under the hood:

Re. PIF's primary function

People often forget that the primary USNF and PIF function that allows device integration attestations to be spoofed, introduced from the outset in USNF after Google rolled out an update to make SafetyNet opportunistically use hardware-backed cryptographic attestation if the device supports it on January 12, 2021, is the breaking of hardware key based attestation on the device, ie the injection of code that causes this type attestation to fail and that results in the fallback to traditional basic-only SafetyNet (and now Play Integrity), attestations... This has always been needed in USNF/PIF, always causes GMS/DroidGuard to send only basic attestations and never required spoofing any props or fields used to identify devices.

What changed on September 2, 2021 was simply that Google started enforcing hardware-backed attestation in the S/N API's backend based on device information. This essentially means that Google began blacklisting some (not all) devices for passing device integrity verdicts, including S/N ctsProfileMatch, when a 'blacklisted' device produces traditional basic-only attestations... It DOESN'T mean that device is no longer sending traditional basic-only attestation measurements, NOR does it additional measures are needed for the fallback to basic-only attestation; THAT STILL WORKS FINE!

To be clear, devices running USNF were supplying traditional basic-only attestations post September 2, 2021, but verdicts necessarily failed (couldn't pass) if a device was on Google's hardware-backed attestation-capable-devices list because Google's evaluationType was now set to HARDWARE_BACKED.

ProtonAOSP began circumventing this by altering the device model name (last ROMs were spoofing BuildField) and this bypass (for hardware-backed evaluationType server end enforcement) was soon added to the 'portable' USNF module. It was equally as necessary as the (primary) fallback mechanism for many devices, but really a secondary function... Since then Google has added other properties/fields to those used to identify devices for which they wish to enforce the hardware-backed evaluationType (ie. blacklist device for passing integrity verdicts using basic-only attestations) including device fingerprint and shipping (first API) level... Recently they've also added prop and field based checks that break basic-only evaluationType if spoofing is detected even when using print/prop/field combinations that don't trigger hardware -backed evaluationType on the matched device, thus greatly limiting the available pool of devices that are available for spoofing purposes...

The key point is that these spoofs to misrepresent the device by means of print/prop/field combinations

do not

somehow produce a fallback to BASIC-only attestation.

.. That's already occurring when USNF or PIF is running and Zygisk is available for the code injection that breaks hardware key (TEE) based attestation! The print/prop/field spoofs simply tell Google not to block a verdict from passing when BASIC-only attestation is supplied by the device (ie. by GMS/DroidGuard).

To put it another way, if PIF were working to allow passing DEVICE_INTEGRITY on a hardware key capable device and we were to disable just the code that breaks hardware key based attestation, ie. PIFs primary function (leaving print/prop/field spoof and other functions working), both SafetyNet API's evaluationType (displayable) and PI API's hidden evaluation type would be only BASIC (meaning simply that HARDWARE_BACKED is not required; this actually still allows hardware-backed verdicts to pass) but the device (ie. DroidGuard/GMS) would be collecting and providing the Google server hardware-backed attestations and, obviously, the result will now be failure to meet DEVICE_INTEGRITY primarily because we can't spoof Verified boot state.

evaluationType is just that; the type of evaluation Google allows to pass, not the type of attestation measurements provided. 🙄 PW