[Magisk] pndwal:
I will re-word the linked post for clarity, but "needed mismatches with Google's prop-based HARDWARE_BACKED evaluationType enforcement lists" simply means

... In other words we spoof props where expected values are used as identifiers for devices flagged for enforcement are identifiers...

I agree that

over-simplifies it however... Thanks 👍😊

A bit of history:

Google of course uses props to identify devices for which they wish to enforce HARDWARE_BACKED evaluationType verdicts. (They've evidently added devices for enforcement as they've tested or checked that their Keymaster implementations etc won't preclude SafetyNet pass or DEVICE_INTEGRITY if blacklisted for BASIC-only evaluationType.)

The first props they used for this were model props... It was widely assumed the we needed to spoof an old pre Keymaster 3/Android 8 device model, and MHPC used such old prints from the same OEM but default for "Force BASIC key attestation" (a misnomer really as it simply bypasses Google's HARDWARE_BACKED verdict enforcement to allow Basic-only evaluationType verdicts)... Soon it was discovered that a mismatch with what Google expected based on other props in the attestation was all that was required... Even model values from models/devices also having enforced HARDWARE_BACKED verdicts worked as the value didn't match expected values for your device...

Custom setting closely related models (could be selected based on existing fingerprint list) became the recommended method in MHPC (although the default old (pre Keymaster 3) model selection didn't change). This was to avoid breaking OEM specific services like Galaxy Store, and was critical as MHPC globally spoofs... Of course any mismatched value would work, even "cream cheese", but, only with targeted spoofing in Riru/Zygisk based USNF did it become largely unnecessary to use real model values... USNF adopted @Displax's method of simply appending a space chr to the real prop value so Google account etc would always show the correct model while the extra character was good for the mismatch/bypass...

So this is as stated:

The next prop based enforcement of HARDWARE_BACKED verdicts was fingerprint prop based... Suddenly expected prints no longer worked in non AVB Verified boot state devices; what was needed here was a passing print that also did NOT match expected values... Another prop mismatch although you are correct that this one requires prints not slated for enforcement and CTS/VTS certified also...

The last introduced prop based enforcement is Shipping level (first API), and targets all A13+ launch version devices... The expected values are API/SDK level 33+... The solution is to use working but mismatched (unexpected) level values of 32 or less...

Well not really so, although many including Devs keep repeating this...

While many passing props may be based on pre Keymaster 3 (threshold for HARDWARE-BACKED attestations) devices, we what is really required is simply to spoof devices where Google doesn't enforce hardware backed evaluationType verdicts at server end... And Google has not enforced such verdicts for a number of devices that use/are compliant with hardware attestation, eg. Pixel 2 (walleye) print can still be used as working spoof for other devices despite that device using hardware attestation... Also, apart from any devices Google still hasn't tested or added enforcement for, many (even recent) OnePlus and other devices that naturally fall back to basic attestation due to bad OEM Keymaster implementations will have usable props as Google won't/doesn't enforce hardware backed evaluationType verdicts for these...

See this post:

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89184236

PIF is a USNF fork, and all basic functions are still essentially the same, including mismatched model prop; PIF generally uses prop sets now, but with expected model values (no mismatch), the bypass/fix will fail for many devices...

Sure... Oversimplified... I'll reword... 👍 PW