yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
... But use of PI API continues to be much the same as S/N for now... Just adds need for fingerprint prop mismatch (as in @Displax's UNNF mod) and we still pass the equivalent of S/N w/ Basic Evaluation type (ie. deviceIntegrity) fine, so for now not much has changed really with migration to PI...

I put some stuff in response to @HippoMan here recently re. my take on how long we've got till "game over" for hiding and why I don't believe Google is going to preempt use of strongIntegrity verdict:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87551789

Nb. Even if migration to PI hadn't occurred, banks have long had the option to use the evaluationType along with CTS Profile match response in S/N to enforce HKA attestations but have chosen not to to date. strongIntegrity is essentially those responses combined and repackaged!

Go back in the conversation linked too (if you have time) for more on my perspective FWIW... 😝 PW
[Magisk] V0latyle:
Right. We're still able to pass basic and device integrity, and will likely still be able to do so...the question is who is going to require strong integrity. If it wasn't used before, why would it be used now?

I was under the impression that the USNF mod forced apps to use the SafetyNet API instead of Play Integrity but it sounds like this isn't true - it just changes how the device reports basic and device integrity, yes? Meaning, Play Integrity is still used, strong integrity still isn't available, but most apps don't require it anyway?

Is there a way to see what responses an app requires?

Also...I'm trying to keep the OP concise, simple, and accurate. Could you do me a favor and proofread, and let me know of any inaccuracies or other changes I should make? I'm not 100% sure on how an unlocked bootloader affects hardware integrity aside from AVB being disabled; I've made some general assumptions about TEE and the keystore.
[Magisk] zgfg:
For the first part - that was discussed in details, USNF does not force SafetyNet instead if PI API, it only tricks either of them not to use Trusted Execution Environment (hence eg in PI you obtain Device Integrity but of course you cannot get Strong Integrity)

For the second part - SaferyNet or PI API responds its JSON answer/verdict and you can read that - see the screenshot

The rest is up to the particular application what that app reads from the JSON verdict (eg, does it look for Strong Integrity or would it be satisfied with Device Integrity)

Btw, PI API documentation (links were also posted here) suggests that apps themselves do not read/analyze JSON responses from Google, but that instead they pass the JSON answer to their own servers (like to that bank's server) to make a decision there is your device safe or not.

Hence you cannot 'read what an app requires' (like does it look for Device or Strong Integrity) - you can only deduct from its behavior
[Magisk] V0latyle:
Ah, so going forward, we will just have to assume that if an app doesn't work, and we are passing both BASIC and DEVICE attestation, it's likely because it requires STRONG - but there's no way to verify whether that's actually the case?

Also, as I asked pndwal, could you proofread the OP? I am trying to keep it concise, simple, and accurate, and I've been operating on some assumptions as well as misunderstandings that are slowly being cleared up.
[Magisk] pndwal:
I believe it'll be banks first, and Google will likely follow...

Wasn't before or now as I mentioned in linked convo, because of the collateral damage among their customers... Adopting S/N enforced HK evaluation type or PI strongIntegrity now will break apps for all pre Android 8 devices w/o keymaster 3, most OnePlus devices due to broken OEM keymaster implementations and many others...

The decision to move to strongIntegrity verdict will evidently be made only when there is sufficient market saturation of A8+ devices and the number of devices with broken keymaster implementations and Android 7 and earlier devices in use is deemed acceptable collateral damage.

No... Just causes fallback to basic attestations and bypasses enforcement of the same, as well as making other adjustments that used to be handled by MagiskHide (details below)...

Not sure what you mean by 'changes how the device reports...'

The previous S/N fallback method (fake keystore registration causes exception to trigger this) and bypass for Hardware evaluation type enforcement (mismatched model prop triggers this) are both still required to allow Play Integrity verdicts to pass. USNF simply applies the fallback and HK enforcement bypass trigers... Some devices (mostly A11+) require a further trigger to bypass Hardware evaluation type enforcement (mismatched device fingerprint prop). @Displax's modded version adds this...

With the fallback and bypass triggers functioning, S/N and PI simply pass if requirements for CTS Profile match, sensitive prop values, hiding root from gms attestation process etc are also met as for pre A8 devices (where device defaults to Basic attestation and Hardware based evaluation types are not enforced)...

USNF provides the sensitive prop value adjustments and hides root from gms attestation process. The @Displax mod ensures the fingerprint prop is passing in addition (must be both mismatched and passing) which needed to be handled by MagiskHide Props Config for uncertified ROMs (China region, custom, beta, developer...) previously.

Play Integrity is the name of the API... The verdicts include the default deviceIntegrity verdict as well as optional basicIntegrity and strongIntegrity... All are available to Devs, but most (all?) Opt for the median default level... I don't know what apps might require the minimum optional basicIntegrity verdict, but it maps to the old Basic Integrity S/N response... Devs are simply not using strongIntegrity yet for the reasons I've outlined above...

Sometimes we can see this in their security engine (eg Promon) logs, but often we can't; app simply refuses to work.

It necessary breaks strongIntegrity as it can't be hidden from Hardware based attestation; the AVB verified state required to pass is Green; LOCKED state and key used to sign OS (for verification) was not set by the end user... It ordinary breaks deviceIntegrity also, but can be hidden by adjusting props and hiding traces of root... PW
[Magisk] V0latyle:
Yeah, so back to "just a matter of time"

I could have worded that better..."changes how PI reports device/software state"

Makes sense

Right, and I would assume that because AVB cannot verify images, there is no TEE?

Is the hardware keystore inaccessible when bootloader is unlocked?

Sorry if these seem like elementary questions, my understanding of Android security is pretty basic, and I may not always ask questions that make sense to someone who's more knowledgeable on the matter
[Magisk] pndwal:
I always said/thought it was... In post I linked for you above:

It does verify; it verifies non-green state!... And TEE works fine... Eg all your DRM / Widevine content is decrypted there... Bootloader unlock doesn't break TEE OS, and keymaster components still work there so AVB can verify yellow, orange or red states...

No. Keystore an keychain still work fine, eg MediaDrm uses these to obtain keys for decrypting protected media streams, in conjunction with MediaCrypto.

No need to apologise! 😝

... There's only so much time in a lifetime, and it's always a choice whether to generalise or specialise...

Donsen's Law states

With Android I've managed to generalise I think... Praps you've specialised...

With Magisk I've tended to do the same, although it's stowly become a specialist subject for me so it's allowed me to be a bit of both... But I'm well aware I've broken the mould...

Still not sure if I'll end up knowing everything about nothing or nothing about everything but... 🤔 😬 PW

Donsen was a wise fellow...

So was Murphy... I think...
[Magisk] V0latyle:
Interesting. So that's literally the only thing that's changed on the hardware side. AVB still verifies image integrity, TEE still works, and the hardware keystore is still available - the only thing that's different is that bootloader reports ORANGE state meaning that the kernel and OS cannot be guaranteed as OEM authentic.

So how exactly does Play Integrity discover the bootloader state? Can this be blocked or spoofed? How does an unlocked bootloader prevent Hardware Key Attestation from working proplerly?
[Magisk] pndwal:
Answered here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87566639

It doesn't... It works fine and attestations, eg deviceIntegrity, properly fail...

However after unlocking we can stop it working by registering a fake keystore which causes a fallback to Basic (non-hardware based) attestation when an exception is thrown...

At this point the attestation is performed in basic mode but hardware based evaluation type verdict is still enforced so deviceIntegrity etc will still fail to pass.

Other mechanisms are needed to bypass hardware evaluation type enforcement, 1) device model prop mismatch, and 2) for many devices (but not needed by some), a fingerprint prop (must still pass as certified also) mismatch... Now HKA is properly stopped/bypassed Basic and attestation is enablled/working and can pass... PW
[Magisk] V0latyle:
Question is if this is something they can easily patch on their end, or does this mean they're going to have to reinvent the wheel all over again to fix it
[Magisk] pndwal:
And apparently that wouldn't be universal as using Google's Trusty TEE OS is optional... OEMs can use their own or 3rd party TEE OS (although it would be an expense), and my guess is that Samsung etc may do that...

👀 PW
[Magisk] V0latyle:
@pndwal so as to not clog up Displax' thread...

Could you explain why ro.product.first_api_level is relevant as pertaining to original shipping API level, vs current API level?

Any idea why 33+ allows spoofing STRONG_INTEGRITY?
[Magisk] zgfg:
Some things remain as originally shipped, hence it's an important info about the capabilities of the phone.

And if you change it can affect not only PI API but also Camera, Fingerprint, etc

But it's strange that spoofing to higher version helps to spoof Strong Integrity
[Magisk] pndwal:
Actually, spoofing API level 32 for LV 33+ devices was the third prop based mismatch needed to bypass hardware backed verdict enforcement for P7 etc...Now seems we need 33? (This is still unclear to me) or hidden shipping level for DEVICE_INITIAL_SDK_INT as I mentioned in my earlier reply to you...

Apart from this information I really am no wiser than you re exploiting Google's strongIntegrity anomaly... @Displax may say more later... PW
[Magisk] Displax:
For STRONG integrity you just need:

1. Buggy "walleye" product, device, model and fingerprint "google/walleye/walleye:8.1.0/OPM1.171019.011/4448085:user/release-keys".

2. Set derivative "DEVICE_INITIAL_SDK_INT" to "O" (26) for GMS.

3. Set global prop "ro.product.first_api_level" to >= 33 / or `null`. Or delete it at all.

Check this commit: https://github.com/Displax/safetynet-fix/commit/79f6ef22db5eeb717c57a9bd00ee90b8d7cd2201
[Magisk] V0latyle:
Oh okay, so this is a bug in Google's evaluation of the Pixel 2, so all we are doing is changing fingerprint to walleye as if it shipped with Android 13...?
[Magisk] pndwal:
Thanks for the additional details (buggy walleye props, DEVICE_INITIAL_SDK_INT setting etc)

Glad to see shipping level will be set to target 'unstable' (droidguard/attestation) gms process (to do) to fix issues too... 👍 PW
[Magisk] sawdoctor:
The pixel fold shipped with API level 33 could this be the reason that it kept failing strong with the latest test builds or something completely different?
[Magisk] V0latyle:
It has got to be something different because the Pixel 7 and 7 Pro both shipped with Android 13.0 / API 33
[Magisk] chiteroman:
@pndwal

Nop, if you set that prop to null it won't work in some devices (like @Stillhard's one). So I force set it to 33, we will see if it works 👀
[Magisk] intel_core_i7:
So Google wants to extends the PI API to the whole web too...
[Magisk] V0latyle:
DRM has been around long before Android. Back when they were hashing out the details for DVD, there were a few companies (like Divx) who wanted DVDs to be single view only - you'd have to pay a fee every time you wanted to watch it again. We see this now with some digital content.

Play Integrity doesn't have anything to do with DRM, beyond simply providing an interface for applications to determine device state. Google isn't enforcing anything in this regard - as I pointed out to other users, your beef would be with the app developers, not Google...

And not that I'm defending them by any means, they've been just as complicit in censorship and privacy violations as the rest of Big Tech.
[Magisk] chiteroman:
Give me the result of this prop: ro.build.gms_fingerprint

You can get it from PC using: adb shell getprop ro.build.gms_fingerprint

android_frameworks_base/core/java/com/android/internal/gmscompat/AttestationHooks.java at 13852185c3ba641b677ee041b5cae074bf0263e8 · ArrowOS/android_frameworks_base

Contribute to ArrowOS/android_frameworks_base development by creating an account on GitHub.

github.com
[Magisk] calmfish:
google/walleye/walleye:8.1.0/OPM1.171019.011/4448085:user/release-keys
[Magisk] chiteroman:
That's why you pass Strong 😉
[Magisk] calmfish:
I see - so by happy coincidence Arrow has the fingerprint and build props of a device which for whatever reason presently returns a strong result?

Which conversely most likely means that the exact opposite will be true in some number of units of time when google fix their bug!
[Magisk] pndwal:
Many custom ROM maintainers read these pages, or at least recent commits from various S/N and PI fix solutions to implement natively... PW
[Magisk] calmfish:
Of course - but they didn't time travel 10 months ago from when that build was released until now to be able to read these recent commits :)
[Magisk] pndwal:
Well yes... iirc custom ROMs (XiaomiEU?... Any you may see the irony here) actually borrowed that fingerprint prop first. Then Magisk Devs/modders reported and ran with it...

ROM maintainers follow other ROM innovations too...

Re USNF, if you check PRs by @Displax and others you'll see that countless ROMs pull the commits even before they're implemented in official @kdrag0n builds... ROM Devs often use SNF framework from @kdrag0n Proton project as a starting point...

Anyway, word and code travels fast in the custom mod world!

Perhaps Magisk community was a bit slower than custom ROM Devs this time... 😜 PW
[Magisk] baiqiao:
if the bootloader unlocked, are there any android phone that can pass basic and device integrity without root?

i use xiaomi stock miui 14 with an unlocked bootloader no root no twrp simply unlock it and be done but only pass basic.
[Magisk] chiteroman:
Yes, you must install a custom ROM. If you like MIUI I recommend you xiaomieu
[Magisk] V0latyle:
Short answer: No. Play Integrity is intended to "prove" basic and device integrity using hardware methods, so if the bootloader is unlocked and no hiding mechanisms are in place, all 3 will likely fail.

This question was answered in the OP, by the way.
[Magisk] chiteroman:
We need to try with another devices like "taimen" (Pixel 2 XL) and see if it's still working.
[Magisk] pndwal:
Just to clarify, basicIntegrity may pass unlocked w/o further action depending on sensitive props device sets, but this only uses basic attestations anyway...

deviceIntegrity uses hardware-backed attestations where available by default and requires a solution to cause fallback to basic as well as prop based bypasses for server end hardware evaluation type verdict enforcement on many devices plus the setting of sensitive props to non-suspicious values... This can be done both with root + USNF module (also hides root from GMS), or without root with a ROM integrating a SNF solution.... Many custom ROMs do this, many don't... PW
[Magisk] intel_core_i7:
So I went on facebook today, and saw @huskydg made a facebook post about side effects of bootloader unlocking (in Vietnamese)

There is already an app which demands strong verdict, which is ironically, FaceApp. An app that can collect your face data...

An adware/spyware/botnet or whatever is it needs the best security, apparently.
[Magisk] pndwal:
Guess you mean this app and following discussion:

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

👀 PW
[Magisk] mrspeccy:
I observe a very strange behavior of PlayIntegrity on a Samsung Galaxy A54 (SM-A5460) with Chinese stock rom A5460ZCS4AWF7 (which includes Google Services) and locked boot loader. The devices passes PlayIntegrity (Basic, Device and Strong Integrity) exactly once after a fresh install. Any subsequent call to PlayIntegrity returns failed "DeviceIntegrity" and "StrongIntegrity" - only BasicIntegrity passed. Clearing data of Play Services and GSF does not help to pass Device/StrongIntegrity aftwards either. The only way to pass the three categories again seems to be a factory reset. Again, afterwards DeviceIntegrity and StrongIntegrity pass exactly once.

Does anyone understand the internals of PlayIntegrity sufficiently to come up with a possible explanation for this strange behavior?
[Magisk] pndwal:
Please clarify; did you ever unlock B/L? (Or have you locked it with custom keys?)... Ever install custom ROM?

May be a /persist (partition) issue...

Please see comments/links I put in a thread reporting a similar issue in poco device (and note the thread title):

- https://xdaforums.com/t/cts-fail-even-with-locked-bootloader.4613007/post-88837771

- https://xdaforums.com/t/cts-fail-even-with-locked-bootloader.4613007/post-88839819

Do your due diligence, but I'd try the second suggestion before flashing /persist (unless you have a backup from your device as this will include unique numbers for IMEI, S/N, BT, WiFi, MAC etc unlike the generic /persist image in ROM), especially if you've never actually messed with that... (Nb. Seems issue can occur simply due to downgrading directly from A13 to A11 or similar... Go A13, A12, A11 etc).

Hope this (or clues linked) helps... 🙂 PW
[Magisk] mrspeccy:
Thank you. I saw these threads earlier, but the solutions refer to Xiaomi (I have Samsung) devices. Moreover, I cannot unlock the bootloader on the Chinese variant SM-A5460 that I own. Currently, there is only a single stock firmware available and I already reflashed that several times. Downgrade to an earlier one is prohibited without root.

How can it be that I pass DeviceIntegrity exactly once after a factory reset?
[Magisk] pndwal:
Well I did wonder about Chinese variant w/ 'global' ROM incl. GMS... Do you know if it's standard? If so, I'm guessing two variants should work for you model locked; one for mainland China and one for Hong Kong... But I'm not sure and not familiar with Samsung... Basically, I thought China region ROMs don't qualify for GMS, nor does Chinese government allow this, but I'm not certain about this...

I do know unscrupulous sellers have sold China region devices with fake 'Global' ROMs in the past. (Both Google and various OEMs have introduced measures to make this difficult now)...

Must say I'm suspicious about your ROM... If it's locked with custom keys (AVB yellow state) you won't pass strongIntegrity, and would only pass deviceIntegrity if the ROM integrates spoofing to allow integrity verdicts based on basic-only attestation evaluationType... You will only get strongIntegrity with officially signed ROM (AVB green state)...

It's also strange that Key Attestation app cannot display verified boot state... Almost like hiding unverified keys is intended... 🤔 PW
[Magisk] Yuri_Rosas:
Guys, if I put room stock and lock the bootloader, can I pass all the tests again?

It turns out that I'm a driver at uber, and apparently they're blocking the use on phones that don't pass the safetynet and Google play integrity. Uber started blocking devices exactly on August 4th... I can only block the bootloader as a last attempt. What's weird is that so many drivers have their devices locked by uber without having a custom room.

I will be forced to use an old Android with the possibility of Bricking my phone so ... Sad
[Magisk] pndwal:
Should be fine... Test with Play Integrity API Checker... Exception seems to be where /persist data has gotten messed up...

Doubtful they'd require strongIntegrity... Generally deviceIntegrity is enough, and should have that w/ Magisk and @Displax fork of USNF module...

Of course if they do extra detections like many banks, you'd need to experiment and take further measures to hide Magisk App, Zygisk, Developer options, TWRP, applist etc...

🤠 PW
[Magisk] Yuri_Rosas:
Currently I'm with pixel experience, and with magisk and module Hide props config e universal safynet fix modded by displax. He passes 100% on safetynet and fails on play integrity.

One of the banks I use is also detecting root.

I have a report of someone who blocked the bootloader and solved the problem. And another person who says he didn't.. I'm going to have to play Russian roulette.

There's no way to circumvent play integrity yet, right?

I also did the whole zygisk process and applist of magisk, hidden magisk and etc.
[Magisk] pndwal:
Please say what fails... Can't be 100% for S/N, but banks never used evaluationType label so pass with basic-only evaluation was ok... Now need equivalent deviceIntegrity...

Please say device also... PW
[Magisk] Yuri_Rosas:
My phone is xiaomi redmi k20, also known as mi9t. Also known as Davinci.

I use 3 different banks. Only one detected root.

When I was a room miui.eu, He didn't pass the cts profile test, yet all the banks worked well.
[Magisk] pndwal:
Ah... You said failing PI... But deviceIntegrity is the best to can expect w/ unlocked B/L... deviceIntegrity = S/N w/ basic only evaluationType... Just that your checker doesn't show that... YASNAC does...

XiaomiEU is custom but close to stock MIUI... Does spoof props, apparently badly at times... May be the issue with that... Assume It didn't pass w/o Magisk installed?

Pixel Experience is another ROM that spoofs many props and has caused many issues when used with Magisk and USNF also... Not sure if all PE ROMs integrate a SNF however...

ROMs that spoof device integrity related props do this to pass verdicts w/o root, but there are often compatibility issues once rooted... I prefer ROMs clean from such prop spoofing for use with root, eg official LineageOS (see their policy); just means no unexpected surprises.

Also, many banks now detect Zygisk, suspicious apps and more... Uber may do that too... You may need upcoming Magisk w/ native bridge loaded Zygisk (or try POC builds in Alpha fork) + Shamiko, also LSPosed + HMA and possibly other fixes if you decide to keep device unlocked...

Up for a challenge? 😁 PW
[Magisk] mrspeccy:
Actually, Samsung and several Chinese manufacturers (e.g. Xiaomi, Oppo, Vivo) still include a basic GSF in their China roms and allow the user to enable "Google Services" under Android Settings - which is not interesting for the ordinary Chinese user but for people using the phone abroad. However, Huawei roms do not come with such an option, probably because of the US ban in 2019.

The Samsung rom on the phone is an official variant from https://samfw.com/firmware/SM-A5460, more precisely A5460ZCS4AWF7. I also reflashed the rom using Odin (Samsung's official ROM flashing software) but this did not change the PlayIntegrity issue. I tried the mainland china (CHC), Hongkong (TGY) and Taiwan (BRI) variants, with no significant change in behavior. Other roms cannot be flashed because of region lock and locked boot loader.