I'm afraid this is a bit of a WOT...
HippoMan said:
I also don't believe that the Googlefrinchians are out to get us modders. But neither do I believe that they are giving us a reprieve ... at least not consciously.
Furthermore, I doubt that the slowness in banana-ing FP's is due to anything more than corporate carelessness and inertia.
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! ![🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (1)](https://i0.wp.com/cdn.jsdelivr.net/joypixels/assets/6.6/png/unicode/64/1f601.png "🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (1)")
And that's what I alluded to above:
pndwal said:
and I (and others) have pointed out specific ways they could easily have shut down this cat-and-mouse game, fight, war, whatever you might call it, years ago to the detriment of modders and with no collateral damage to locked/stock system GPay users, bank customers etc including those with non-DroidGuard-spec-hardware-key-compliant devices...
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...
When Google moved S/N and later PI to their 'opportunistic' use of hardware backed attestation model, they introduced two tiers of the thing; ctsProfileMatch w/ HARDWARE_BACKED evaluationType and it's PI equivalent, STRONG_INTEGRITY where HARDWARE_BACKED evaluationType is always used, and ctsProfileMatch w/ BASIC-only evaluationType and it's PI equivalent, DEVICE_INTEGRITY where a HARDWARE_BACKED evaluationType was initially not enforced for any devices (for nearly a year it just relied hardware keystore w/ Keymaster 3+ working on the device) but later was 'enforced' for numerous devices by means of basic measurements (typical signals and measurements along with reference data) obtained via GMS.
So here wehad (and still
have) the use of hardware-backed security featuresincluding key attestation
being 'enforced' only by means of basic measurements, and that's an irony and a weakness that's totally unnecessary, but does allow modders to spoof a MEETS_DEVICE_INTEGRITY verdict. Further, from that time onwards Google have been "evaluating and adjusting the eligibility criteria for devices where we will rely on hardware-backed security features", ie. they've constantly adjusted the basic (spoofable) props, fields and other(?) measurements used for this, but they have never fixed the one thing that allows us to spoof, namely the use of basic measurements for the device identification used to enforce HARDWARE_BACKED evaluationType.
With device security and and hardware capability (KeyDescription in schema) such as Keymaster version etc available in hardware key extension data since Android 7 and device identifiers (AuthorizationList in schema) including Brand, Device, Product, Serial, Imei, Meid, Manufacturer, Model etc included since Android 8, the obvious question is "Why haven't Google simply fixed this thing by using their own Key attestation extension data schema?"... They could easily have been done with modders being able to hack this, simply by polling the key pair extension data above to enforce HARDWARE_BACKED evaluationType for all Keymaster 3+ devices apart from models they wish to exempt (eg OnePlus w/broken OEM Keymaster implementation); then they'd properly be leveraging hardware-backed key attestation signals (opportunistically) to enforce such an attestation in S/N or PI APIs...
By not doing this (and they're not stupid; they know they can ![🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (2)](https://i0.wp.com/cdn.jsdelivr.net/joypixels/assets/6.6/png/unicode/64/1f606.png "🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (2)")
) 'they're giving us a reprieve'. (Obviously the reprieve ends when some begin using the STRONG label.)
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. ![🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (3)](https://i0.wp.com/cdn.jsdelivr.net/joypixels/assets/6.6/png/unicode/64/1f600.png "🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (3)")
HippoMan said:
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
HippoMan said:
And again, I doubt that the management even think about us modders at all.
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/
HippoMan said:
Yes, I'm sure that there are some individual Googlefrinchian employees in addition to TJW who do think about us modders and sympathize with us. However, I doubt that they are able to have more than a microscopic level of influence on corporate policies.
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
![🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (2024)](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/h8AAvMB+NzmkbcAAAAASUVORK5CYII=)
