[Magisk] pndwal:
I don't need shipping level fixes or fixes for XiaomiEU custom spoofing, so I'm still using @Displax 2.4.0 mod 1.3... However I'm trying to keep appraised of changes here since work on official and @Displax USNF both seem to have stalled... (@Displax intended to update his fork with proper shipping level adjustments targeting GMS and actually began the process on his GitHub, but it still hasn't happened which is why A13+ launch version devices need a fix from elsewhere... Not sure what happened... Just hope things are not too bad in Kyiv... 😬)

Starting with a recent version (8.9?) @chiteroman said:

So that was a fix to be used in concept with @Displax modded USNF or XiaomiEU integrated spoofing...

The OP simply says:

It doesn't mention the main functions of USNF (injecting code to register fake keystore to trigger exception causing on device fallback to basic attestation, adjusting sensitive props, hiding root from GMS main and Droidguard processes or the two earlier prop based bypasses for server end enforcement of hardware-backed evaluationType for verdicts*) so it's not clear if later versions are complete solutions...

*Nb. These are all spoofs for props not matching Google's list of prop values identifying devices slated for prop based enforcement of hardware-backed evaluationType verdicts (they will then also be a mismatch for props expected on your device), ie prop mismatches including:

1) model prop, (ro.product.model) for S/N... 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... The mismatch is achieved in USNF simply by appending a space character to the real model value..

2) fingerprint prop, (ro.build.fingerprint)... Spoofing this became necessary after PI API came online and Google began blacklisting additional devices (ie blacklisted for allowing BASIC only evaluationType verdicts) based on fingerprint prop... The fingerprint prop mismatch (ro.build.fingerprint) was initially mostly needed 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 that 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)...

A third mismatch required for A13+ LV devices is set properly in @Displax 2.4.0 mod 1.3 build but can cause issues with VoWiFi etc as it wasn't properly set as a GMS targeted change, rather it's set globally so other system processes can see the mismatched prop causing issues... In @Displax 2.4.0 mod 2.0 it seems it may be set to 'nul' for most (all?) devices (apparently selected XiaomiEU ROMs also set it this way(?)) even though the spoof targets GMS... this also fails to work as a bypass since Google fixed the server end Pixel 2 ID based vuln...

This last needed mismatch is the focus of @chiteroman's PIF builds which simply set the prop to target GMS only (correctly) and may override 'nul' and other failing values... The proper setting is as follows:

3) Shipping level prop, (ro.product.first_api_level)... This affects all Android 13+ LV devices... Google now blacklists all devices shipping with Android 13+, API 33+, 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...

Re. PIF 9.0, Changelog on GitHub says:

and for PIF 9.1, only these changes are mentioned:

So again it's not clear if it continues to be an add-on fix... Maybe "One module" means a standalone fix?

🙂 PW