[Magisk] pndwal:
I'm afraid this is a bit of a WOT...

You're still overlooking the obvious reason they haven't had to let us get away with Spoofing Verified boot state, CTS/VTS compliance etc needed for a MEETS_DEVICE_INTEGRITY verdict at all (and I've been over the details that follow with you before). There's also the fact that they seem to be happy enough to allow spoofing of user-space signals for this purpose at least until other parties flip the STRONG_INTEGRITY switch...

For precisely the reason that they didn't need to use spoofable measurements to enforce HARDWARE_BACKED evaluationType for the default deviceIntegrity MEETS_DEVICE_INTEGRITY verdict, I say they

have

given us a reprieve and, at least since March 2020, they could easily have shut spoofing this down for all on devices launched with Android 8+ except those with "broken TEE" (broken OEM Keymaster implementations) who don't need the spoofed props/field sets anyway.

Whatever the reason for which they have favoured modders ('white hat' hackers) this way, I don't believe it's 'corporate carelessness or inertia'. Google understands their own Key Attestation model (they even give a Key Attestation sample that uses the ASN.1 parser from Bouncy Castle to extract an attestation certificate's extension data to demonstrate how Devs can set up their own independent Verified Key Attestation using embedded hardware backed data from the CertificateChain) and what it's capable of, but clearly they've knowingly avoided hardening their opportunistic use of it, no doubt because security-centred development can always move to the STRONG (opt-in) deviceIntegrity implementation for PI if/when they wish... And that's another thing; Google have structured that in a way that puts Devs wanting to implement it 'between a rock and a hard place' but that favours modders for now... Again, the very design of this thing allows us to continue to spoof Verified boot state, CTS/VTS compliance and MEETS_DEVICE_INTEGRITY, none of which we have any business passing or achieving if we're honest, and it gives modders a reprieve for the time being! 😁

And that's what I alluded to above:

Even John Wu thought spoofing S/N was all over in March 2020... Why are we still here? Simply because of Google haven't used the obvious fix, Hardware Key Attestation based signals for enforcement of server side HARDWARE-BACKED evaluationType on capable devices, against modders...

Spoiler content hidden.

Another obvious question is 'why has G not thwarted targeted spoofing when it does actually work?'... That would be as simple as polling global prop values by using a mechanism within DroidGuard or an API separate from PI (or even several), to kill DEVICE_INTEGRITY where DroidGuard attestation values don't match... Or, 'why not nobble modders ability to use 'public' prop/field sets 'universally' across multiple devices'?... Simple as checking keymasterVersion or keyMintVersion (from key extension data) against the device associated with the prop/field set seen by DroidGuard...

The only reason I can see not to, is that Google is not really serious (doesn't care to, wants to avoid being the 'bad guy', somehow believes DEVICE_INTEGRITY should remain true to it's original use of basic measurements despite the move to opportunistic use of HKA or whatever) about hardening the DEVICE_INTEGRITY verdict and therefore is just going through motions of hobbling print sets for user-space spoofing... In other words, they're giving us a reprieve by going easy on us as always, never (when you consider their alternatives) going hard and fast. 😀

The RCS issue we're concerned with only occurs because PIF spoof breaks it!!... It actually still works fine on rooted/modded devices where PIF is disabled!... So how's that Google's fault?; PIF just needs fixing!!...

Seems @kdrag0n already anticipated this and made major changes to avoid USNF breaking other stuff relying on DroidGuard attestation data even when not using S/N or PI... He apparently knew DroidGuard wasn't necessarily an exclusive tool for device integrity APIs... Sadly, he left the scene after only one build with his "Dynamically patch build fingerprint in GMS process" commit which will "unpatch" after that process ends, but unfortunately while @Displax fixed several issues with 2.4.0, he found unfixed issues that may affect some devices and then simply disabled the "unpatch" function. Next, @chiteroman forked a @Displax build with unpatch disabled for his PIF, and now PIF is what it is!

I've done my best to alert those who might be able to make PIF work w/o breaking features like RCS too. Take a look here:

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

Also, I put details of Google's investment in this thing (compare Apple's reticence to get behind GSMA initiative) over close to a decade since acquiring Jibe Mobile in 2015 (for it's E2EE), ups and downs with carriers etc, and what they're trying to accomplish before September this year here:

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

and here:

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

Of course they do... I've linked many comments from G team leaders and engineers (from twitter, Reddit etc) about how they appreciate the modding community, 'avoid harming', liaise with "leaders in the modding community" regularly etc, and you know it too... Here's just one such article (from the Android Hardware-backed security team leader):

www.reddit.com/r/Magisk/comments/ofrbqh/comment/h4y62f3/

Well, if even the leader for hardware-backed security has been "holding regular meetings with various leaders in the modding community for seven years now [that'd be 10 now], to get their feedback and to give them a heads up on security features" etc, that's a pretty good start in my book... Surely if he can't influence corporate policy there ain't much hope for most Googlers... And he does seem sympathetic...

... Sorry for the WOT... PW