[Android Software Development] pndwal:
No...

These actually pass basicIntegrity and deviceIntegrity because there is no need to trigger any fallback or bypass any l hardware backed evaluation type enforcement... They were designed to use basic attestation and Google allows this for deviceIntegrity verdict so stock pre-A8 devices will show passing basicIntegrity and deviceIntegrity verdicts just like we can achieve w/ USNF etc... 🙂 Stock A8+ devices will show passing strongIntegrity in addition... 😀

The purpose of USNF has always been simply to allow Android 8+ LV (launch version)/Keymaster 3+ devices to pass these verdicts/attestations with unlocked bootloaders just as devices not meeting hardware requirements always have (ie. simply by hiding root from the droidguard process, adjusting sensitive props, etc)... And such a mod is needed simply because A8+ devices will normally fail deviceIntegrity (and possibly basicIntegrity) verdicts due to their being designed to use keymaster 3+ (ie. 'strong' hardware keystore backed attestation), even when attesting to deviceIntegrity components, where it exists

Yup... And they do so by default! (assuming a stock/locked device, or assuming root is hidden from droidguard process, sensitive props are adjusted, etc where unlocked)...

No!... 😬 Please don't confuse forcing a fallback to basic evaluation type attestations (the key USNF function) with bypassing enforcement of hardware based evaluation type verdicts (a secondary function). Without bypassing, that enforcement will still cause a failing verdict despite droidguard/gms actually sending passing basic evaluation type attestations... We need to get our heads around these two separate functions and their differences!!!...

Fallback to basic evaluation type is forced by fake keystore provider registration/subsequent exception in Play Services on attempting HKA (hardware key based attestation)...

Nb. This trigger is the key one, is needed by most A8+ LV devices, and cannot be achieved by any simple prop manipulation!...

Further, the fingerprint prop is not actually touched by current official USNF release, but is by the new pre-release build... It was introduced in @Displax's modded fork and was added to provide the additional mismatch w/ prop settings expected for device/device configurations Google has whitelisted for hardware based evaluation type enforcement required for some devices... It appears to be needed for many A11+ devices that previously required the model prop mismatch introduced a long while ago for S/N API...

Nb. This enforcement bypass is not needed on my A10 MIUI A9 LV device, nor by many other devices...

Summary:

USNF achieves fallback to basic evaluation type by registering a fake keystore provider to trigger this,

not by any prop changes

!

All

the prop changes are due to Google adding enforcement of hardware evaluation type even where the evaluations performed have already dropped to 'basic' as the fallback type... Read "Device may be doing basic evaluation type attestation but that is still not accepted because device meets criteria in Google's prop based 'Enforce hardware based evaluation type' whitelist"...

Nb.

All

hardware keymaster 3 compliant devices default to hardware evaluation type so will need the USNF fallback trigger if modded...

Nb. 2. In devices w/ broken keymaster implementations like OnePlus, fallback is triggered naturally by the exception thrown when Play Services attempts to use key attestation. This simply passes as Google hasn't flagged/won't flag these devices for hardware evaluation type enforcement...

Some

(not all... maybe most...) hardware keymaster 3 compliant devices are included in Google's 'Enforce hardware based evaluation type' prop based whitelist. These require (in addition to the fallback trigger) adjustments to one or more of the following props (ie. to cause mismatches with expected device prop values) in order to bypass hardware based evaluation type enforcement by not meeting Google's defined whitelist criteria. So far these include:

1) ro.product.model for S/N and PI (not all A8+ LV devices required this) [official 2.3.1+]

2) ro.build.fingerprint for PI (mostly A11+ devices initially required this) [@Displax modded 2.3.1 fork, official 2.4.0+]

3) first_api_level for PI (A13+ launch version devices require this) [@Displax modded 2.3.1 fork, official 2.4.0+]

Nb. Google have clearly been steadily increasing the number of prop values used to flag devices for hardware based evaluation type enforcement in their whitelist implementation for newer devices/OSs... Notably, the last addition exempts no API level 33+ LV devices!

This means that no stock (un-modded) 33+ devices will pass deviceIntegrity w/o HKA, so it seems that Google expect OnePlus and other OEM's to have fixed bad keymaster implementations in all devices launched w/ Android 13+...

If manufacturers mess this up again, their stock/locked devices can now never pass even deviceIntegrity verdict (unless Google revert the first_api_level flag that effectively whitelists all A13+ devices for HKA evaluation type enforcement), so these are effectively being forced to 'up their game' at this time... 🙃

👀 PW