yashsingh1/xdaforums huggingface dataset:
[Magisk] usernamejames:
You are right, I didn't read carefully about the custom key and stuff but if there was a exploit managing to get keys of android verified without unlocking bootloader preventing the yellow bootstate could fix it or I don't know how they check the color, but with some luck a tee could fake the cor And, assuming this is not existent, then i believe not all devices are giving yellow mode in Android verified boot so spoofing a device could fix it.

And my last suggestion: could it work to run some kind of a proxy running all the check traffic for safetynet through a stock device that still succeeds Strong integrity?
[Magisk] pndwal:
Yep... both TrustedEnvironment and StrongBox are hardware provisioned...

No... All apps must migrate to PI by June 2023, and S/N will cease to function even for old versions by June 2024... PW
[Magisk] V0latyle:
Something I didn't realize until not too long ago is that the STRONG verdict is not a specific representation of security integrity in of itself - it just means that the BASIC and DEVICE verdicts are hardware backed.

So, just as pointed out on the documentation pages:

where:

ctsProfileMatch: The device and software signature matches that of a profile that has been tested for Google Play compatibility

basicIntegrity: The device and software does not appear to have been tampered with.

BASIC evaluationType: NOT guaranteed by hardware cryptographic methods

HARDWARE_BACKED evaluationType: The CTS profile and device integrity are guarateed using hardware cryptographic methods such as dm-verity, Verified Boot, Hardware Key Attestation, etc.

I had been thinking that STRONG_INTEGRITY meant a separate mechanism for 3 separate verdicts, but it really just means that the first 2 verdicts are guaranteed by hardware security.

Interestingly, one can potentially attain BASIC_INTEGRITY on a custom ROM without root; this is why users of LineageOS and others are still able to download most apps from the Play Store without much problem.
[Magisk] pndwal:
Mate, respectfully, perhaps you should read some references and try to understand the basics before just proffering unfounded hopes... Cos were starting to go round in circles...

Basically Google have been slowly ensuring vulns are eliminated/patched w/ better and better hardware implementation including cryptographically (military grade) signed keys, nonces generated by calling apps per Google's standards, Tamper-evident Storage, Named Persistent Values, arbitrary key pairs, key revocation, 'nearly-unbreakable signals', patches to restore a usable root of trust, authentication, bootstrap provisioning, provisioning refusals, cryptographic proof of fixes, short-life attestation keys, TGC DICE secrets, fuses, key pairs, bootloader hashing, DICE strategy, private keys, certificate chains, boot chains etc etc.

And much of this has been added since John's initial remarks:

BTW I told you how they check the colour:

AVB returns VerifiedBootState:

Verified (0),

SelfSigned (1),

Unverified (2), or

Failed (3),

These states simply correspond to green, yellow, orange and red in that order...

Not all? I'll bet hardly any (comparatively speaking) have self-signed images... Most modders by far will have orange boot-state!

Yeah?... 🤔

And my last suggestion: give it a go! 😀 PW
[Magisk] pndwal:
Sorry, but strongIntegrity is a third and separate verdict... It's the one no-one has used yet! ... You were right before...

Both APIs will enforce Hardware backed verdict where hardware exists and device is whitelisted by Google to use this... USNF uses tricks to trigger both fallback to BASIC Evaluation type and bypass of Hardware key based verdict enforcement... The result is we can pass either APIs in the second instance below just like an Android 7 device can...

If either S/N HARDWARE evalType or PI MEETS_STRONG_INTEGRITY labels were enforced, neither custom modded nor Android 7 (and lower) devices could pass.

You're looking at the mapping chart above... Please check it carefully:

App Devs can opt for either the PI standard deviceIntegrity verdict label only, or for all optional labels in addition... Assuming they opt for all (the only way to see strongIntegrity verdict anyway), a S/N full pass using Hardware evaluation type (TRUE, TRUE, HARDWARE_BACKED) maps to PI returning 3 labels (MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY) ... Of course bank apps haven't used the S/N equivalent either...

Banks currently only require S/N full pass using Basic evaluation type

(TRUE, TRUE, BASIC) which maps to PI returning 2 labels (MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY)... PW
[Magisk] usernamejames:
Thanks
[Magisk] V0latyle:
I think what I was trying to say is that MEETS _STRONG_INTEGRITY is not possible by itself or with either of the other verdicts being false.

To use a metaphor...

Let's say you have a vault containing cryptographic material (as we do in the military). To gain access to the safe, all you'd really need is just the lock code/combination. But, since this is a very important safe, we also ensure that only allowed personnel may enter the vault, and we have an audit trail showing things like when someone is given access, when that person enters the vault, when that person accesses cryptographic material, what exactly happens to that material (transfer to another device for example).

In most circumstances, for material classified Secret, the first two are good - the user is approved and provides a valid key. But for super sensitive material classified Top Secret/Secure Compartmentalized Access, you'd want to be able to verify everything on the spot before the user is given access - ensure they are indeed approved, that the person who approved them is approved, all the way back to the "root trust", and same thing for the key they are using - even though it may be valid, we must verify that they're supposed to have it, that the vault code wasn't supposed to be changed, and so on and so forth.

Let's say something goes wrong - user presents the wrong key, or they are not on the approved list. The audit trail clearly won't support valid access (and the audit is the least of the user's concerns, as they are now being fitted with leg irons by the MPs and will be facing courts martial)

I'm probably making it way too complicated. You've done a great job of explaining everything, @pndwal
[Magisk] pndwal:
Ah ... Ok... Bit like workings behind a navy/spy thriller! Glad you're enjoying the puzzle!

However the reason "STRONG_INTEGRITY is not possible by itself or with either of the other verdicts being false" may be very simple; By providing all the labels an app dev may choose which one (ie. which level of integrity/security attestation) to mandate. Any attestation tier is available for enforcement... More below...

Also, re:

... Well it is true that hardware evaluation type must necessarily be used for any environment evaluations supported by hardware components if strongIntegrity verdict is to pass... And if we examine the label descriptions we see that MEETS_STRONG_INTEGRITY does pretty much overlap MEETS_DEVICE_INTEGRITY in particular. I've underlined the common parts here:

However, considering that the basicIntegrity and deviceIntegrity labels don't require "a strong guarantee of system integrity such as a hardware-backed proof of boot integrity" for either level of device integrity/security to be indicated, strongIntegrity does in fact embody 'a specific representation of security integrity in of itself'... Requiring 'a strong guarantee of system integrity' is what makes this a higher tier of attestation to Device Integrity; nb. In order to pass strongIntegrity, requirements for passing deviceIntegrity also necessarily change since strongIntegrity can fail when deviceIntegrity is passing... Also, with this 'guatantee', there is no possibility of bypassing HKA as we can with deviceIntegrity.

So this is true in a sense, but considering that higher tier labels, including deviceIntegrity, necessarily require the lower tiers in any case, strongIntegrity does really introduce 'a separate mechanism', one that is only enforced for strongIntegrity level attestation... The fact that the lower tier labels accompany MEETS_STRONG_INTEGRITY doesn't change the fact that 'a separate mechanism' (HKA, other) has in fact been used; it actually just gives app Devs the opportunity to enforce any one of the three as mentioned above.

So both perspectives may be correct, but viewing this as a tiered system of verdicts may be more apt.

Yup.

S/N basicIntegrity maps directly to PI basicIntegrity and was originally described this way:

https://developer.android.com/training/safetynet/attestation#use-response-server

I wasn't aware this affected Play Store availability at all... Can we not use that w/o basicIntegrity pass? 🤔

I assumed it shouldn't make a difference since it doesn't indicate Android compatibility testing or device certification... I know ctsProfileMatch is needed for Play Protect certification in Play Store and does indicate Android compatibility testing (even if spoofed). 🙂 PW
[Magisk] V0latyle:
I think the reason why I was confused was because of the use of HARDWARE_BACKED attestation; by default, Play Integrity will use "true" hardware methods to verify both of the lower tier results, which is why without the fallback of the @Displax mod an unlocked device will fail all 3.

I'm not 100% sure on this but I believe this is why some custom ROM users get the "This app is not compatible with your device" message in Play Store, even if the app works with the device on stock firmware...

So an app can request any one of the responses alone? Such as:

Developer has no requirements for target platform, no request.

Developer is not concerned with security environment but wants to ensure app only runs on compatible devices, BASIC_INTEGRITY

Developer is not concerned with compatibility but wants to ensure app runs on untampered systems: DEVICE_INTEGRITY

Developer wants a strong guarantee that device and firmware have not been tampered with and can provide a sterile hardware authenticated security environment: STRONG_INTEGRITY

Any single one of these or any combination can be used by the developer?
[Magisk] zgfg:
Open PI API Checker, Check, tap to view JSON, scroll till the end

This is what you get. The rest is what of that and how you use it, eg are you ok with Device Integrity or you become picky when you see that Strong Integrity was missing

That's also described in the specs, PI API returns the JSON (verdict), you (your app, even better your own server - bcs your app can be tampered) decide is it ok for you or not

Btw, PI API Checker similarly reads the same JSON, if it finds Basic Integrity it marks that green, otherwise red, and so on for the other Integrity flags
[Magisk] pndwal:
Yup... And YASNAC will give S/N JSON too... Also, run Key Attestation Demo also from Xingchen (vvb2060?) and Rikka for much insight on hardware processes etc... PW
[Magisk] pndwal:
Pretty sure hardware is only used for ctsProfileMatch / deviceIntegrity verdicts. (Apparently nothing changed in relation to ease of subverting this attestation even with HKA)...

But that wasn't so with S/N basicIntegrity!... Has something changed with PI basicIntegrity?

basicIntegrity can pass with unlocked bootloader and certified or uncertified stock as well as custom ROMs and no such mods or attestation 'fixes'...

The tampering this lenient verdict does detect includes signs of system integrity compromise including rooting, signs of other active attacks such as API hooking etc...

Perhaps you are thinking of unlocked bootloader w/ root?... USNF does also hide root from GMS attestation (droidguard) process...

Ah... Apps, not Play Store itself... Sorry I misunderstood...

Anyway, this bears out my understanding above; w/ no Magisk, clearly no @Displax mod fallback can work so isn't needed for basicIntegrity(?)

However, this is interesting...

I know that ctsProfileMatch failure has historically restricted app availability in Store where these require this verdict to pass... Netflix FAQ pages recommend checking Play Protect Certification where this app is missing from Store which is logical since both Netflix and [actually app doesn't anymore but does require it for Play Store distribution except when updating] Play Protect require ctsProfileMatch...

More recently apps been restricted that require new PI deviceIntegrity pass despite Play Protect stating Device is certified... Clearly Play Protect had not (last time I checked) been updated to PI API. These apps show up again on fixing deviceIntegrity.

So evidently apps in Play Store that require integrity attestation are either now simply restricted on the basis of new deviceIntegrity across the board, or actually on the basis of the specific attestation flag required... If this is the case (and it's a reasonable assumption), there will potentially be apps hidden that require the minimum basicIntegrity when ROMs fail to pass this...

Thanks for helping me fill in gaps!

A dev can choose to see deviceIntegrity alone even w/o Google Play registration and when using other distribution channels... The other labels are considered additional Device integrity field response labels (this can be confusing) and are optional but require Google Play registration to access...

This is also why Play Integrity API Checker app was quite basic (couldn't display full JSON until it was approved/appeared in Play Store...

If registered and opting for additional labels, a dev is in a position to choose which one to enforce for his app... I can't see any point enforcing more than one since it's a tiered system... [Edit: see next post]

🤠 PW
[Magisk] pndwal:
Actually opting for additional Device integrity field labels allows a dev to employ a "tiered enforcement strategy"...

This makes it possible to "build an anti-abuse strategy with multiple tiers of enforcement. After you opt in to receive additional labels... Thus, you can prepare your backend server to behave differently depending on the range of possible responses."

I guess a dev could then configure various app features to be disabled or restricted per the integrity attestation tiers returned...

Nb. Unregistered (non Play Store distribution) allows only use of deviceIntegrity label and Number of API calls allowed per day is capped at the standard "Up to 10,000"...

Registration allows both options for additional labels and for applying for an increased daily API call cap...

👀 PW
[Magisk] mko000:
Never mind.
[Magisk] V0latyle:
Okay. So, it sounds like the mechanism used for verifying STRONG integrity also verifies BASIC and DEVICE integrity....in a sense - with any system modifications (custom software), root, and unlocked bootloader, the device will fail STRONG integrity and cannot guarantee the authenticity of BASIC and DEVICE integrity. STRONG integrity is only available in a pristine environment - locked bootloader, OEM firmware, OEM root of trust, which ostensibly means that the device will also pass BASIC and DEVICE integrity.

We've established that, assuming the same definitions as SafetyNet:

MEETS_BASIC_INTEGRITY: The device running your app likely hasn't been tampered with (root and/or system modifications not detected).

MEETS_DEVICE_INTEGRITY: The profile of the device running your app matches the profile of a device that has passed Android compatibility testing through CTS. Play Integrity does not allow the use of this label by itself.

MEETS_STRONG_INTEGRITY: The device is able to guarantee by means of hardware authentication, image verification, and other means that the Android security environment is sterile and uncompromised

So:

A modified device CAN potentially pass BASIC and DEVICE integrity, because we can force the BASIC evaluationType.

A device that passes STRONG integrity will always pass BASIC and DEVICE integrity

@pndwal I think you had mentioned some devices with broken keystores that were still able to pass STRONG integrity on an unlocked bootloader? Do you have more information on these - i.e., firmware was completely stock, no root? Or was STRONG integrity still available even without BASIC or DEVICE?
[Magisk] shoey63:
ASUS ROG Phone 3

Stock Rooted 12.1

Zygisk, Shamiko and MHPC to spoof an earlier version gets Strong Integrity to pass.
[Magisk] V0latyle:
Interesting. Can you disable modules and check again? I assume STRONG will fail if BASIC and DEVICE fail

What is the "Key attestation" screenshot from?
[Magisk] shoey63:
Only meets basic Integrity without spoofing an older fingerprint and locked bootloader.

Attestation app is in Play Store

Edit: And 3 strikes if you don't hide Google play services gms and gms.unstable in deny list.
[Magisk] V0latyle:
How did you spoof a locked bootloader? MHPC?

What do you mean by 3 strikes?

For the sake of sharing, here's what I see on my Pixel 5 (unlocked, stock firmware, Magisk)
[Magisk] shoey63:
MHPC, USNF, Shamiko, Magisk Hide all spoof locked bootloader by manipulating /proc/cmdline on boot I believe.

By 3 strikes I mean failing integrity on all 3 levels.

Your key attestation showing Device locked= no and unverified boot state would be standard on any device failing "MEETS_STRONG_INTEGRITY"
[Magisk] V0latyle:
Well, I am using USNF 2.3.1 Displax mod, and this is what I get:

I assume only "broken" devices like the RoG are able to spoof a locked bootloader?
[Magisk] shoey63:
Without using hacks such as USNF to force a fallback to software based "basic" attestation, yes (as far as I know).
[Magisk] V0latyle:
That's what I'm using, still shows unlocked
[Magisk] shoey63:
That's because the app checks for hardware based key attestation. No script or module will get that app to show locked if it is unlocked.

It's also the reason you can't get it to meet strong integrity. An unlocked bootloader can't be spoofed to show locked when hardware integrity checks are used.

The currently known exception is ROG 3.

But by using USNF mod the Play integrity check falls back to software based basic, where on the software level, it sees a locked bootloader, and no root, allowing basic and device Integrity to be passed.

But of course, a basic Integrity device (or one spoofed to look like it), will never meet strong integrity as hardware checks aren't used.
[Magisk] zgfg:
+ a clarification:

Key Attestation app does not execute SN / PI API check to test if BL is locked or not (if it would use them, it will be spoofed) - it checks that somehow directly

That also means that other (banking) apps could do the same, and then USNF module, DenyList or even Magisk Delta (MagiskHide) would not help to hide 'root' (unlocked BL) from them
[Magisk] pndwal:
If you mean signals collected, this is all done by droidguard, yes...

Yup... Root etc may be hidden from attestation/droidguard process to pass basic integrity and CTS Profile, model and other props may be spoofed to pass deviceIntegrity... Of course if strongIntegrity is passing it would generally indicate that neither Basic attestation fallback nor HK enforcement bypass triggers have been used because HK attestation to bootloader etc would necessarily fail strongIntegrity...

... Except in the case of Asus ROG 3, in which it now seems there are at least 2 bugs in keymaster implementation; 1) It's using Basic attestation out of the box (ie. fake keystore registration to trigger exception --> Basic attestation fallback is not needed), 2) fingerprint prop mismatch based HK enforcement bypass erroneously allows strongIntegrity to pass...

Yup...

Well it must be used by itself for those apps not choosing to register with Google Play... I wrote this in last post!...

AFAICS, yup, yup and yup...

All I know was from @shoey63, and I think member addressed all this... 👍 PW
[Magisk] pndwal:
Many thanks for clearing up your method...

Please could you do me a big favour and post complete Key Attestation (scrolled page if it works) screenshots for the 3 scenarios:

1) Zygisk, Shamiko and MHPC spoofing mismatched print active + gms processes in denylist...

2) Zygisk and Shamiko active + gms processes in denylist...

3) Zygisk, only active + gms processes removed from denylist...

I'm very interested to know what changes, particularly:

'Bootloader is Locked' and

'Root of trust' entries:

Device is locked: true

Verified boot state: verified

This would be quite enlightening / much appreciated... 👍 PW
[Magisk] shoey63:
@pndwal

Time for some tests.

Starting with stock A12 with unlocked bootloader

It seems ROG 3 TEE is more busted than I thought! No hiding mechanisms active yet still showing bootloader locked🤔

Next, Rooted with Magisk, Zygisk only active + gms processes removed from denylist...

Oh dear 😱 API checker is NOT happy!

Now we'll do Zygisk and Shamiko active + gms processes in denylist...

Ok, so not detecting root, Shamiko is doing its thing with the props but Latest A12 firmware for ROG 3 isn't certified. Well soon fix that...

Nb. This covers tests 1and 2

And lastly....

Revert to an older certified fingerprint, and all good👍
[Magisk] zgfg:
Since your Key Attestation constantly shows that BL is locked (btw, it doesn't utilize SN/PI API for its check), it means that your ROG 3 does 'not know' that Bootloader was unlocked

Ie, the method Key Attestation uses to check if BL is unlocked, somehow returns locked BL (in all conditions), although the BL is unlocked

Hence, I would conclude that TEE is 'not broken' on your phone but it probably also reads that BL is 'locked' like the Key Attestation does

And that's the reason that you can pass Strong Integrity
[Magisk] shoey63:
Yep, you're right. Hardware backed pass on both spoofed A10 and unmodified A12 fingerprints.
[Magisk] pndwal:
👍

So a data collected using Basic evaluation is being passed to S/N and P/I APIs as Hardware evaluated data... I think what's happening is much as I described... Could be the DroidGuard signals that are broken! 😛 👍 PW
[Magisk] shoey63:
Sure have. And I use Shamiko to handle dangerous props, with MHPC dealing with only the print so the "Zygisk and Shamiko active + gms processes in denylist" test passing just basic Integrity is what you expected.

Here's the results with fingerprint reset in terminal anyway
[Magisk] pndwal:
Haha... Ta mate...

So do you actually disable MagiskHide props function in MHPC? And does it cause issues otherwise? PW
[Magisk] shoey63:
Yes i actually do and no it doesn't.

Shamiko has it covered.

Edit: If Shamiko is disabled, the props revert to the sensitive values, so it's definitely doing the job.

And yet Key Attestation still reports locked bootloader even if verifiedbootstate=orange and other props not set to safe values.

Weird Huh?
[Magisk] XRed_CubeX:
I have unevaluated as result on integrity checker, how can i bypass it? Anyone have any advice? Forgive me the stupid question
[Magisk] zgfg:
How does exactly the result look like - screenshot?
[Magisk] pndwal:
This:

https://developer.android.com/google/play/integrity/verdict#application-integrity-field

https://developer.android.com/google/play/integrity/verdict#account-details-field

👀 PW
[Magisk] XRed_CubeX:
I don't know, the first requirement is very vague, the other two should be respected
[Magisk] V0latyle:
Did you install the Magisk module linked in the OP?
[Magisk] 10Maximus10:
Yes I tried it with original USNF, displax fork and even a fork by huskydg and none of them worked. It's weird because before I reinstalled the stock rom play integrity worked fine even on the original USNF.
[Magisk] pndwal:
What is device, ROM, Android version?... PW
[Magisk] 10Maximus10:
Motorola Moto g7 power stock rom Android 10
[Magisk] pndwal:
Do you see Zygisk = Yes on Magisk home screen?...

Try w/ @Displax Mod version instead of Mod 2.0... You don't need to the latter... PW
[Magisk] 10Maximus10:
Yes I enabled zygisk. I will try it
[Magisk] pndwal:
Still need to confirm Zygisk is working per home screen...

This is TJW Magisk, not Delta etc?... PW
[Magisk] 10Maximus10:
The older version didn't work and this isn't Magisk delta