[Magisk] pndwal:
Moving this here as info may benefit others.

Some disambiguation regarding hardware -backed verdict enforcement, fallback to basic attestation and other USNF workings.

No, if server resolves gms data as ctsProfileMatch=true then that's what's sent back with the original nonce and the same is true of basicIntegrity.

The SafetyNet Attestation API provides a cryptographically-signed attestation, assessing the device's integrity. In order to create the attestation, the API examines the device's software and hardware environment, looking for integrity issues, and comparing it with the reference data for approved Android devices. The generated attestation is bound to the nonce that the caller app provides.

https://developer.android.com/training/safetynet/attestation

This mechanism is much the same in new Play Integrity API also, except that there are additional criteria for passing verdicts... Eg basicIntegrity in S/N will pass with permissive selinux without changing signals for that, but PI API basicIntegrity will fail at the same time... We can pass that too with additional prop changes however.

Because without it keymaster 3+ (Android 8+) compliant devices are using hardware-backed security features including Key attestation for some of the measurements and reference data sent...

Many are still confused about BASIC (only) evaluationType... This does NOT mean that device is not supplying such hardware -backed measurements/data, and the API will default to this data to compute response fields when it's available, so verdicts will be failing.

What evaluationType=BASIC DOES mean is that Google server-end hardware-backed verdict enforcement (prop based) has not been activated for your device or has been bypassed. If evaluationType=HARDWARE_BACKED, BASIC, hardware-backed measurements/data will be required where expected for keymaster 3+ devices so BASIC-only evaluations will necessarily fail.

Further, evaluationType may be 'BASIC' for S/N (and this can be easily seen) but 'HARDWARE_BACKED, BASIC' for PI purposes... See note on altered props used to bypass hardware-backed verdict enforcement for S/N and PI below*

So to get passing verdicts, keymaster 3+ compliant devices need USNF or similar solution to

1) produce the fallback to supply BASIC-only measurements/data. This is USNF's key function and is achieved simply by injecting code (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.

This works at device level and always required. And to

2) bypass hardware-backed verdict enforcement. This secondary function is achieved by ensuring that the props used to identify devices Google has flagged for enforcement of hardware-backed measurements/data never match expected valued. Ie, this bypass is purely based on simple prop mismatches. This works at server (backend) level since the data/measurements are processed by Google to generated attestations.

This is not always required; some or all props USNF handles may need altering per device.

* So far Devs have discovered that Google polls the following props for hardware-backed verdict enforcement, so USNF causes mismatches by using targeted spoofing (in gms only unlike MagiskHide Props Config module's global changes) to adjust their values:

- ro.product.model for both S/N and PI (not all devices require this at least for S/N but USNF always appends a space character to model value).

- ro.build.fingerprint for PI (mostly A11+ devices initially required this but USNF always uses passing (CTS certified) old Nexus 6P (angler) fingerprint prop.

- first_api_level for PI (A13 launch version devices require this, and shipping API level is set to 32 only for devices >=33)

Proton is the model for any wanting to integrate @kdrag0ns SNF approach in a ROM.

Since a Dev builds a ROM there isn't the obstacle of read only /system partition, and code can be baked in rather than overlaid.

It seems API hooking is used to target gms with prop changes as well as altered keystore data... I'm hazy on hooking usage and native code injection, so I may not be strictly correct about this...

The methods, including fake keystore registration are otherwise very similar and he has provided more details for Devs:

https://github.com/kdrag0n/safetynet-fix#rom-integration

The Proton info. discusses additional SNF functions like setting 'sensitive' props early. It also links a commit with this (old) info on bypassing opportunistic hardware-backed attestation:

Well again I'm hazy on this, but it seems source code isn't modified; calls for the attestation certificate chain from KeyStore are apparently just intercepted and fake data returned while prop values are also spoofed for gms at runtime, but yes, gms is targeted to fix both S/N and Play Integrity verdicts.

Specifically hardware key based attestation is effectively broken in the Droidguard/Attestation service com.google.android.gms.unstable in order to cause the fallback to basic attestation.

Nb This is what was formerly referred to as the 'SafetyNet' service, but I'm now properly calling it the Droidguard/Attestation service since S/N is depreciated and this process actually connects gms to the Droidguard VM engine that collects device integrity measurements securely.

Yes, it's easy to alter props globally like MHPC module does, but for the props dealt with for attestation purposes this can break stuff, eg device/OEM specific functions and apps like Galaxy store, backup utilities, proprietary camera features etc etc

Riru/Zygisk solutions mean that targeted spoofing (ie. only in gms) can be used so other processes see expected values...

Well while the method has changed from setting available flags for basic attestation to registering a fake keystore, evidently source code for gms is unchanged as mentioned.

Seems we need Zygisk (or Riru) hooking for targeted prop changes as well as to hook attestation calls and fake lack of hardware key attestation support.

🤠 PW