yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
If it helps at all...passing Play Integrity has been pretty trivial. Android version doesn't matter. Magisk Stable v25.2 + Displax's mod is all you need. I'm currently on the 14 beta with 26.1 and the same mod

The "cat and mouse" thing seems to be much less of an issue with GMS and Play Integrity than it is with third party apps. Yes, Google is still tinkering with PI but we've been able to keep up and there haven't been any major changes of late.
[Magisk] HippoMan:
Agreed. But as time goes on, more and more third-party apps that have nothing to do with finance are utilizing Google's security mechanisms and other mechanisms of their own, and they are falling into what we are now loosely labeling as the "banking apps" category. This is making everyday use of Android increasingly precarious and difficult for people with rooted/modded phones.

This is only going to get worse, I believe.
[Magisk] pndwal:
Well gms APIs do call/verify hardware-backed key pairs with hardware key attestation, but this doesn't need to be done through gms. Hardware attestation per se is not part of gms S/N of PI APIs...

S/N and PI APIs provide cryptographically-signed attestations after assessing the device's integrity... These may also be hardware key backed attestations, but should not be confused with hardware-level key attestations in general which are simply supported by the device itself where the root certificate within the key chain is signed using an attestation root key injects into the device's hardware-backed keystore by the device manufacturer at the factory.

So in reality any app can implement or call "Hardware attestation" themselves, even w/o gms APIs... Hardware-backed key pairs can be accessed with key attestation, the properties of hardware-backed keys can be verified and the schema of the attestation certificate's extension data can be interpreted even on devices w/o gms/GApps...

My post above links Google's documented method which was implemented in the RikkaW / vvb2060 Key Attestation app...

While their POC 'demonstrates the (unsafe) verification of a certificate and extensions on the Android framework and not on a server', Google's model does provide for testing these, as well as any revocation status, on a separate trusted server... Also, this method and the Key Attestation app will work without Google Play Services installed.

USNF only spoofs for gms because it's only designed to bypass Google's S/N and PI APIs... It can't thwart app's independent use of hardware-level key attestations whether used by Google (eg for Widevine DRM security/certification) or by banks etc.

👀 PW
[Magisk] pndwal:
... That's the nature of closed source!

Try the app on a stock locked pre-A8 device or check app prerequisites perhaps?...

If bank says A8 or above is required or app fails to open on a stock locked pre-A8 device, this would be a pretty good clue that strongIntegrity checking has been deployed... 😬 PW
[Magisk] V0latyle:
Yeah I was going to suggest setting up a virtual device. Android Studio still has the Pixel XL with the same 7.0 build it was shipped with.
[Magisk] pndwal:
Not sure if virtual device would give a proper indication... I haven't checked recent progress, but I know there were issues passing S/N initially... Haven't checked since PI deviceIntegrity verdict etc...

And such an app could also be failing to run due to some AVD anomaly being detected by bank... Actually I'd be surprised if bank didn't check virtualIntegrity in device_recognition_verdict too...

I guess if virtualIntegrity can be forced to fail (ie. machine not recognised as an Android emulator) along with strongIntegrity but deviceIntegrity and basicIntegrity were passing it could (possibly) be a good indicator... 😬 PW
[Magisk] V0latyle:
I have a Pixel 5 AVD set up that I was trying to root. I'll have to fire it up and see what Integrity Checker says
[Magisk] pndwal:
... Since virtualIntegrity is opt-in (only deviceIntegrity is available by default) I'm not sure whether Play Integrity API checker would show MEETS_VIRTUAL_INTEGRITY even in raw json... I know TB Checker does call all device integrity (device_recognition_verdict) labels however. PW
[Magisk] chiteroman:
Ok, someone explain why my ??? with unlocked bootloader and xiaomi.eu latest rom pass the STRONG integrity check. I will try to install Magisk and see if I still pass it but idk why I can pass it. I installed this rom like 5 mins ago and I see this.
[Magisk] chiteroman:
Ok guys, Google must be trolling me. should this be happening?
[Magisk] chiteroman:
I think I broke TEE
[Magisk] immortalwon:
@swer45 .
[Magisk] chiteroman:
Done
[Magisk] immortalwon:
I will answer ur question though, consider yourself lucky for finding that out. Your TEE environment is broken, similar to a user on this forum before.
[Magisk] chiteroman:
I've had this phone (I will not reveal the model) for a year and I've put everything, TWRP, Magisk, custom rom... And this has never happened to me. I do not know how it could have happened, I just went to check that the rom xiaomi.eu had been installed correctly and passed the safetynet but I ran into this. I do not know if it will help me xD.

Thanks for the heads up, I just saw this tweet from Google's head of security about this and it looked bad haha.

https://twitter.com/i/web/status/1237836365238337536
[Magisk] HippoMan:
Feel free to redirect anyone and anything you wish to that thread.

I couldn't care less about whether anyone reads the OP of that thread nor anything else in that thread before posting. Nor do I care whether there are lots of repeated posts there.

And finally, nothing in that thread will ever fit into the category of "off topic".

Because of all this, some people might even think of that thread as WOM: "Write-Only Memory". If so, I don't care.
[Magisk] chiteroman:
But it's very strange, I'm using xiaomi.eu that changes evaluationType to only BASIC, but for me it's BASIC, HARDWARE_BACKED. I only have Shamiko to hide root and in Key Attestation Demo it shows my bootloader is unlocked.

Never happened me this before...
[Magisk] chiteroman:
It is different from what happened to @shoey63 because in Key Attestation shows locked bootloader...
[Magisk] pndwal:
Fake keystore isn't causing exception to trigger fallback to basic attestation, or droidguard output signals are somehow locked/frozen to give results per locked bootloader... PW
[Magisk] chiteroman:
What?
[Magisk] pndwal:
you still have hardware evaluationType... USNF fake keystore isn't producing fallback and results are still per locked bootloader... PW
[Magisk] chiteroman:
I dont have USNF, only Shamiko. Also before I installed Magisk I already pass strong. Im just using Xiaomi.eu rom with TWRP. If I install USNF I fail strong (tested)
[Magisk] pndwal:
Ah yes...

... So seems your eu ROM is one that definitely integrates SNF ('SafetyNet Fix') or similar spoofing?... If so it should be using the same technique for fallback to basic, yet you still have HARDWARE_BACKED... PW
[Magisk] chiteroman:
Yes, xiaomi.eu ROMs already include safety net spoof integrated (you don't need Magisk module). But never happened me until now... Very strange.
[Magisk] pndwal:
Actually, seems you'd fail strongIntegrity w/ USNF because fallback works... So perhaps in-ROM spoofing is incomplete... Can you check to see if USNF (when installed with magisk) does actually produce BASIC evaluationType in PI API Checker raw JSON?...

Ordinarily wilh a ROM integrating SNF, you'd need to add droigduard/attestation gms process and main gms process in denylist if Magisk is installed to continue to pass deviceIntegrity... PW
[Magisk] shoey63:
Must be using a different method to customary USNF spoofing. We seriously need to find out what method that is . . . .
[Magisk] chiteroman:
Yes, I tried It and I fail strong because of that. USNF module force the evaluationType to BASIC.
[Magisk] chiteroman:
I'm using this ROM: https://xiaomi.eu/community/threads/miui-14-stable-release.67685/

But I used it in the past and NEVER pass strong until yesterday I installed again.

And it's impossible that ROM have a bypass because unlocked bootloader ALWAYS (should) fail strong. My Samsung A12 fail strong with unlocked bootloader like my actual phone in the past.

Maybe I broke TEE flashing something bad? It's very strange.
[Magisk] chiteroman:
Also I post this as bug in xiaomi.eu: https://xiaomi.eu/community/threads/meets_strong_integrity-pass-bug.68941/

And one developer said that he doesn't know why I have 2 evaluationType.
[Magisk] V0latyle:
Sorry if I was confusing.

I'm still not quite clear on this...

What's the difference between evaluation type and verdict type?

You said developers can't choose the former but they can choose the latter; is this referring to the MEETS_x_INTEGRITY responses?

Are applications able to see these responses themselves, or does the API present some sort of "layer" between the application and the verdicts?
[Magisk] pndwal:
Yup; the 3 (4 incl. emulators) MEETS_x_INTEGRITY response verdicts + blank for device_recognition_verdict call can be chosen; Client app will see either

MEETS_DEVICE_INTEGRITY

or

No labels (a blank value)

by default... All others are optional and require Play Store distribution of app...

EvaluationType is the old S/N field ideally set by the presence of hardware keystore for HKA, but currently capable devices can spoof incapable ones; That's the function of Universal SafetyNet Fix, and the same fallbacks / bypasses work for both S/N and PI APIs.

The only possible S/N API evaluationType responses are

BASIC

or

HARDWARE_BACKED

A (near) equivalent for evaluationType in new PI API is obtained by combining deviceRecognitionVerdict field verdicts, ie.

MEETS_xxx_INTEGRITY combinations...

https://developer.android.com/google/play/integrity/migrate

Please see Play Integrity API summary of workings and flowchart details interaction with / reliance on Google Play server as with app server here:

https://developer.android.com/google/play/integrity

🤪 PW
[Magisk] mrjuniork:
@V0latyle

Mate, thx for the workload, really appreciate it 😁

@ipdev

Thx for pinging me, not a problem at all. And yes, it will be me taking care of this 😉

And thx as well for linking one of the initial discussion openers 👍

So hold your horses, I'm gonna get this done sometime today (which refers to Europe).

RL does hold me tight lately.

Cheers,

mrjuniork
[Magisk] zgfg:
Thanks. I will then mark my posts to be moved here. But now on the road trip, hence when I find time
[Magisk] shadowstep:
...which is why I already moved a few posts @V0latyle requested. Got your back! (y)
[Magisk] Oswald Boelcke:
Please see above post by @shadowstep who moved quite a lot of posts to this thread minutes ago.
[Magisk] mrjuniork:
Mate, you rock! Really appreciate it 😍

Is there anything left to be done, coz I'm gonna check a little later to see what's happening. I'm on mobile now and just wanted to check in.

So what's the progress?

Cheers 🫡
[Magisk] vMAC:
Pardon my ignorance, but why can apps like XPrivacyLua not spoof a TEE status of hardware-backed just as it spoofs a hardware based IMEI or S/N?
[Magisk] zgfg:
You are quoting the post with links to the Play Integrity documentation.

Please read and study the original doc, and you will understand the answer to your question

Sorry but if it would not be clear from the document itself, I doubt it would be clear from somebody's rewriting/reinterpretating the Google's doc

TEE has to do the 'calculation' (verification of CTS Profile, that includes if Bootloader is unlocked, etc) and sign its result by its private key.

That result goes to Google server and Google server verifies both the result and was it really signed by TEE

If you know how signing and authenticating works, you will understand that man-in-the-middle attack (somebody else submits the result instead of TEE or changes the content of TEE's signed result) is practically impossible (modern cryptography)

On the other side, Google eg offers up to 1.5 M $ if anyone breaks the TEE module itself on the new Titan processor

It's not a simple thing as spoofing a number like IMEI. You (Lua, whatever) don't ask TEE to read IMEI number, to sign its result (the number plus its signature) and you don't submit that result to an external server (out of your control) for verification

Now reading my answer above, I see (as stated at the beginning) that reading and studying the official documentation is by far more valuable than my attempt trying to explain the things
[Magisk] pndwal:
This from the horse's mouth:

(Those who've kept up with comments from John Wu won't need to bother opening this unless, like mine, they possess a photographic memory that needs developing... And for those who haven't kept up, be aware that the information contained herein may require some assimilation...)

Spoiler content hidden.

😬 PW
[Magisk] mrjuniork:
How nice it'd be to have the possibility of putting that many pictures in spoiler tags and/or inserting them as thumbnails...oh wait..🤔

Spoiler content hidden.
[Magisk] HippoMan:
I can't speak for anyone else, but for me, my editorializing about what I perceive as banks' stupidity doesn't mean that I have any expectation about these banks changing their policies. In other venues, I also editorialize about other things (for example, certain societal trends) which also have little, if any chance of changing.

Anyway, it's of course important for security purposes to reduce the attack surface, but rooted/modded Android devices make up much less than one percent of the attack surface area that banks need to pay attention to. And even with the use of the security tools that Android offers, I still believe that the banks pay proportionally more for their anti-Android-modding software development (which in many cases goes beyond the mere use of Android's Safety Net and Play Integrity facilities) than the losses they would incur without having developed this additional software.

But like I said, I have no expectation of any banks making any changes to these policies.

There's no law against being stupid.
[Magisk] HippoMan:
I now will editorialize about a proposed solution to this issue which also has very little, if any chance of actually occuring in the real world ...

I propose what I will call a "double device": i.e., two complete Android devices inside of one case. They would be designed to use the same screen, buttons, and sensors as each other, with the choice of which device has access to the screen, buttons, sensors, etc. at any given time being controlled completely by hardware and determined by the setting of a hardware switch that the user could utilize.

They also could be made to share some storage.

One device could be loaded up with a pristine, non-rooted, non-modded, Google-approved OS, while the other one could be loaded up with whatever modded OS is desired.

The banking and other mod-proofed apps would be utilitized on the pristine device.

Of course, this device would be costly, and two SIM cards would probably be necessary, although perhaps there could be some sort of hardware-based solution for sharing a SIM ... but any such SIM sharing is not a necessary feature for my proposed device.

Anyway, I would definitely be willing to pay the cost of such a device, and at least a few other people might also be happy to buy such a thing.

But I know that it will be a cold day in hell before any such device actually appears in the real world.

However, I can dream ...
[Magisk] V0latyle:
I think you're making some pretty broad assumptions here. From a developer perspective, there's really no way to tell the difference between a device that has been intentionally compromised, such as devices rooted by users, and a device that is unintentionally compromised. So, they just check to see whether the device has been compromised at all. That's where APIs such as Play Integrity come in - they provide a way for the developer to ensure that the device security is intact. It's not out of any animosity towards developers, power users, or modders...they're trying to develop a software product suitable for the general public, while protecting the secure assets of said general public (as long as the assets in question is money, not privacy). You used the example of "every PC is a rooted device". Yes, but how many banks are developing Windows platform applications for consumer use? Few, if not none.

As @pndwal pointed out, you can rail against this as much as you want, but it's not going to change anything.

Further, this thread is specifically intended for discussion on the mechanism that is Play Integrity, not ideological rants, so please stay on topic.
[Magisk] HippoMan:
Yes. Play Integrity (and SafetyNet in the past) are used for the purpose of identifying compromised devices, and the use of these Google-supplied features doesn't cost the banks very much, relatively speaking.

I'm talking about all the other efforts that many banks make which go beyond Play Integrity and Safety Net. Not all banks go this far, but those who do are spending (OK, I'm willing to say "wasting") programmer-hours and money going after a minuscule attack surface.

And I'm not the one who moved my comments about this topic into this thread. I'll now stop ranting about non-Play-Integrity issues here.
[Magisk] Tech = Spy-Biz:
There are so many ways they can secure any transaction, it was never about security, thats a hoax, whos gonna hack the daddy of all hacks ;)? Google just wants to push other agendas through apps that are important for android users and what better than banking apps? coz people want tosecure their transactions, security is the alibi google uses. It's not windows that anyone can hack, android based on super strong Linux, no way google feeling so threatened about security. It's for the Billion dollar Ad Revenues and Big Data Analytics forselling to Government Agencies, thats all, Homeland Security too.
[Magisk] V0latyle:
Again...this isn't the place to rant. The point of this thread is to discuss the Play Integrity API.
[Magisk] HippoMan:
Feel free to carry on with our editorializing in the following thread:

https://xdaforums.com/t/discussion-magisk-the-root-hiding-and-mod-hiding-cat-and-mouse-game.4425939/

... and more specifically:

https://xdaforums.com/t/discussion-...ding-cat-and-mouse-game.4425939/post-87403123

... and also this:

https://xdaforums.com/t/discussion-...ding-cat-and-mouse-game.4425939/post-87403193

I created that thread for the purpose of discussing issues such as these.
[Magisk] V0latyle:
Don't get me wrong, I share a lot of your frustrations...while I don't necessarily agree with a lot of your assumptions, this will eventually mean that rooters/modders like us will no longer be able to use secure applications that depend on Play Integrity, once support for legacy SafetyNet is removed. Pretty much the only thing on our side is the high degree of fragmentation in Android - there are still millions of devices out there running older builds of Android that do not support Play Integrity due to HKA and other mechanisms, but once developers decide to remove support for older platforms, that will be the end, because we cannot and will likely never be able to spoof STRONG_INTEGRITY.
[Magisk] immortalwon:
Best to keep it quiet honestly, the more attention, the more google will send their investigators. Enjoy it while it lasts is what I would recommend.
[Magisk] chiteroman:
Yes but which are the benefits now? Are there apps that checks strong?
[Magisk] immortalwon:
Not yet, but probably the banks will start rolling it out soon after safetynet is eliminated in 2024.
[Magisk] HippoMan:
And not just banks. More and more non-banking apps are eventually going to jump on the Play Integrity bandwagon, thereby rendering root more and more problematic as time goes on.
[Magisk] chiteroman:
One question @shoey63 , your rog phone still shows an unlocked bootloader after being blacklisted? Or you did something to change that?. Because my phone have the TEE active even with unlocked bootloader. I think my TEE is completly broken. Maybe I can lock my bootloader... ?
[Magisk] shoey63:
Yep, still says locked even though unlocked.

Can't pass hardware backed anymore no matter what I try.

I might try spoofing your rom's fingerprint 😋

If you lock your bootloader you will factory reset your device, and most likely it won't boot until you flash the stock boot image.
[Magisk] chiteroman:
Lol, mine says unlocked in Key Attestation Demo and Root of trust all bad checks but still pass Strong.

if I give you my rom's fingerprint strong will fail, because your TEE doesn't have the same key. But you give me an idea, I will try something.

i won't lock bootloader by the moment, when I get another phone maybe I will do it, I don't want a hardbrick now XD.
[Magisk] chiteroman:
Ok, do you have an explanation for this?

Why I pass strong when I have a CTS of banned device?
[Magisk] immortalwon:
The only thing I can think of is your rom is doing some excellent spoofing which overrides magic props module. Try downgrading the rom and see if you can still pass strong integrity.
[Magisk] chiteroman:
Official latest rom don't work. Let me check something...
[Magisk] chiteroman:
Yep, my TEE is completly broken. Xiaomi.eu works because it patches some sensible props. I will try to install latest official rom with Magisk Alpha and hide everything.
[Magisk] pndwal:
Why would they?... PI hasn't really changed anything... Sure, criteria for passing verdict has been tightened a bit, eg selinux enforcing now required, but similar additions were made to S/N API prior to PI!...

All PI has done is allowed for additional Application integrity (eg PLAY RECOGNISED) and Account details (eg LICENSED) verdicts (S/N only comprised a in device integrity verdict) within the API as well as simplifying responses, eg S/N ctsProfileMatch: true + evaluationType: BASIC, HARDWARE_BACKED is now combined as PI's MEETS_DEVICE_INTEGRITY...

Banks have been able to access strong integrity verdicts since droidguard first used hardware key based attestation from the getgo, ie when S/N introduced evaluationType labels... None chose to...

PI is really just a Google progression, a re-branded S/N implementation as it's no longer just about device integrity... The depreciation or death of S/N won't sway the banks IMO... Their decision to delay implementing PI strongIntegrity is purely a numbers game.

Banks will surely implement such a verdict when they deem the resulting 'colateral damage' to their userbase (customers) has been sufficiently reduced (and no doubt they are monitoring the numbers using pre Android 8, OnePlus and other devices with bad keymaster implementations etc closely)... That won't depend on Google and could be at any tick of the clock...

Personally, I think it's still too soon, but possibly the ball will start rolling in affluent lands where most already have up-to-date/late devices...

🙃 PW
[Magisk] chiteroman:
I tried official rom again with Magisk and tried to hide bootloader but nothing works. Xiaomi.eu includes very deep changes to hide bootloader status, if I try @Displax USNF it will fail cause only BASIC evaluation, so I will stay in xiaomi.eu rom. The problem of official rom is the google play certification, thata why I fail strong. But my TEE is still broken XD. The real question here is how I managed to did that and how long I have it and I didn't know.
[Magisk] toonTT:
My idea is more of a fantasy tale and probably is outside the scope of reality, but wouldn't a custom bootloader be able to help pass ''STRONG'' checks ?

It would not resolve TEE related issues without exploits.
[Magisk] V0latyle:
No, because you'd still need the OEM cryptographic keys. Bootloaders are proprietary, unlike the rest of Android, so you'd have to reverse engineer the OEM code, which means modifying (and ostensibly distributing) copyrighted material.
[Magisk] chiteroman:
If you do that and publish it online, Google will block the fingerprint of your phone and you can have the bootloader and TEE hacked that you will not pass the STRONG check.