yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
There are still some devices in the wild that can pass because of bad OEM implementation of Keymaster, trustchain data or its on-device handling and not having had keys revoked (yet) like Asus ROG Phone 3 (now with revoked keys) etc, and it's vaguely possible server end logic to override Droidguard/GMS signals and give a (free) pass where device doesn't actually qualify, like recent Pixel 2 walleye prop identifiers (that could also be exploited for other devices), still exists also.

Apart from these scenarios STRONG_INTEGRITY won't pass even with AVB SelfSigned (yellow) state which is no different to Unverified (orange) state as far as far as Play Integrity deviceIntegrity verdicts are concerned, which requires AVB Verified (green) state for both MEETS_STRONG_INTEGRITY and also for MEETS_DEVICE_INTEGRITY. The latter verdict can be spoofed where device is modded however.

Nb. MEETS_BASIC_INTEGRITY can properly pass (ie. no need to spoof/manipulate expected signals) even with a custom ROM installed as long as it's unrooted, selinux enforcing etc.

👀 PW
[Magisk] rodken:
Including, but not withstanding certain models of OnePlus devices.
[Magisk] pndwal:
I know of one or two devices that still pass STRONG w/o Verified AVB... Didn't know of any OnePlus devices although plenty are broken... Keep em quiet for sake of their users though... PW
[Magisk] dknight178:
Hi. Quick question - for oneplus devices with unlocked bootloaders (but unrooted) - will they pass basic and device integrity or not? Will device still remain certified? Thanks
[Magisk] V0latyle:
If they're working properly, then no - unlocked bootloader should result in all 3 verdicts failing. OnePlus may be the outlier (exception) to this because of bad Keymaster implementation, and even them I suspect it would be a case by case basis, not OEM wide.
[Magisk] dknight178:
Aww, thanks. And to confirm - every unlocking still requires device wiping, right?
[Magisk] V0latyle:
It should, yes.
[Magisk] zgfg:
It depends on the vendor but I think the implementation is mandated by Google
[Magisk] DineshValor:
Will failed all three just after bootloader unlock.

I'm using Oneplus Nord.
[Magisk] borisSweden:
So something came up in my mind, Google Pixel phones are kind of honeypots for Google to find exploits that users use. Its right there, Google wanting to make a iPhone rival, the Titan chip, unlocked bootloader isn't for people to do whatever they want, its to test security. Might as well try to jailbreak a Android phone just to not touch the bootloader. Also is "jailbreaking" even a concept in AndroidOS?

From reading previous posts, it easier to spoof and pass the test on other OEMs that implement Play Integrity and SN the halfassed way.
[Magisk] Umgak:
Not really, the concept of "Jailbreaking" primarily refers to the installation of unofficial apps, i.e. from Cydia, Sileo, or Zebra. On Android, the only thing you need to do to install an unofficial app is to simply allow unknown sources when prompted, and so in a sense, Android comes already "Jailbroken."
[Magisk] V0latyle:
False. The purpose of the bootloader is 1) to load the boot code, and 2) to verify the authenticity of said code. Unlocking the bootloader permits flashing and booting of custom software. Android security is designed in such a way to rely on the bootloader for proof of integrity all the way from the bootloader to the system image.

Comparing Android to iPhones is like apples vs walnuts. They might both grow on trees (be smartphones) but the similarity ends there. Remember that Steve Jobs threatened "thermonuclear war" on Samsung over Android phones. Apple designs their devices to intentionally brick if jailbroken. No Android OEM including Google does this.

Pixels are basically the Android prototypes and are used for CTS testing of new Android builds, but in the consumer sense, Google is simply marketing another Android device. They aren't used specifically to defeat user exploits. Vulnerabilities in Android are patched by the AOSP team, and although AOSP is heavily supported by Google, it is not proprietary.

Only because they aren't following the Android model. Andoid is designed to be resilient and secure. We have the freedom of being able to unlock our bootloaders and use patched or custom firmware, and Android will continue to function as intended. However, the difference is with Google's proprietary services, which depend on Android security features. Although Google markets developer friendly phones, they do not officially condone the use of Google Mobile Services on unlocked and/or modified devices.
[Magisk] borisSweden:
Question, wouldn't the XDA phone be the perfect phone for unlocked boatloader by implementing half-assed Play Integrity that circumvents Google infinite BS?
[Magisk] V0latyle:
You'll have to be more specific. Circumventing what, exactly, and to what end?

If we are talking about Play Integrity, then no - PI depends on a continuous chain of trust starting all the way from the hardware embedded OEM certificate. Unlocked bootloader breaks that chain of trust, which is why it is impossible to get hardware backed attestation on an unlocked bootloader.

The only caveat to this has been bad implementation, but I don't really know the ins and outs of why some devices (Oneplus etc) have been able to provide false hardware backed attestation; I do know it has something to do with the keys, which have been subsequently revoked.

@pndwal @osm0sis and @zgfg would be more knowledgeable about this than I.
[Magisk] cosy6ay:
3 custom fp tested working in 14.6.

fail with osmosisV4.

any suggestions.

thanks
[Magisk] Fishawy:
Ensure that they're renamed correctly (custom.pif.json) and placed in the correct path (/data/adb/modules/PlayIntegrityFix).
[Magisk] sawdoctor:
Are you on QPR2 beta or any A14 beta tbh? Osmosis fork uses shadow hook which is broken on A14 beta
[Magisk] borisSweden:
It was years ago XDA launched a phone with the SD835. But forget it, as I use no gapps with microG, passing PIF is redundant for me using microG. As SN reached EOL, going the sandbox Gapps route will be mandatory.
[Magisk] V0latyle:
Can't say I've played much with sandboxing, how do you use apps that require any sort of security state like SafetyNet did?
[Magisk] Retrial:
Hey guys,

I recently came across on this PlayIntegrityNEXT, I checked the OP and I did a bit of research but I didn't found anything about it here. Is this a reliable solution?

I just started searching about Play Integrity for my old Galaxy S4 (running A12), since my main device pass by default using crDroid ROM (so I haven't needed it) and I don't know much about it.

Finding fingerprint and all these sound a bit complicated, that project "playintegrinitynext" seems a bit easier, have anyone tried it yet?
[Magisk] sawdoctor:
Depends about what you mean. As far as I know it pulls the fingerprint directly from xaiomi EU . So when a fingerprint gets banned as soon as xaiomi update then your print will update.

Problem is if xaiomi don't update or take thier time you are left embarrassed at the checkout.

Best option is to find your own fingerprint from one of the excellent guides. I've been using mine since 1st December and still working fine
[Magisk] Lord Sithek:
From what I know, it isn't recommended solution by the guys sitting deep inside the topic, but more info to find in this thread
[Magisk] V0latyle:
It does seem complicated at first, but things have been greatly streamlined by @badabing2003 with Pixel Flasher, @osm0sis with Play Integrity Fork, and @TheFreeman193 with PIFS.

My issue with Play Integrity Next is that it ignores one of the major issues we've had up to this point - when specific fingerprints are in popular use, Play Integrity abuse detection seems to flag them resulting in mismatch detection that renders that print unusable for a while. I believe it is more wise for everyone to find a different print to use, because thus far, very very few who have done so have had those prints stop working.
[Magisk] GilDev:
How would that please be done? Using PIFS?
[Magisk] V0latyle:
Yes
[Magisk] borisSweden:
Well Sweden didn't go full Simple Jack on everything mandatory for banks, ID, electronic postmail, interbank payment, domestic streaming by adding SNet/PlayI checks, for now! But there are some international apps that require some support for EOL SNet. Mostly my apps check if the app is installed from the Play Store which is easy to fix with the companion app. But RCS being tied to PlayIntegrity is just playing dirty, a Instant messaging apps should NOT have a DRM!
[Magisk] V0latyle:
It's usually the app developers that make decisions regarding on device security. I'm not familiar with Swedish law so your mileage may vary.

RCS uses Play Integrity? What phone and messaging app? Just tested on my Pixel 5, RCS in the stock Messages app works even if I'm failing both BASIC and DEVICE.
[Magisk] chenxiaolong:
Unfortunately, it's seems like they've been doing an A/B test for this since at least the end of November. So far, one of my devices (Pixel 8 Pro) is affected. Changing between failing both BASIC and DEVICE and passing both BASIC and DEVICE very reliably determines whether these features work at all.

When failing the checks, activating RCS will work, but actually communicating over RCS will not. Neither does pairing a new linked device, communicating with an existing paired device, nor unlinking an existing paired device. These all fail with:

StatusRuntimeException. Notifying tachyon registration error listeners, error: 1, status: PERMISSION_DENIED
W/BugleNetwork( 7045): docf: PERMISSION_DENIED: The caller does not have permission
W/BugleNetwork( 7045): at io.grpc.Status.f(PG:1)
W/BugleNetwork( 7045): at doyh.a(PG:6)
W/BugleNetwork( 7045): at dobc.a(PG:1)
W/BugleNetwork( 7045): at cihz.a(PG:9)
W/BugleNetwork( 7045): at dohm.a(PG:3)
W/BugleNetwork( 7045): at doij.run(PG:2)
W/BugleNetwork( 7045): at dort.run(PG:2)
W/BugleNetwork( 7045): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
W/BugleNetwork( 7045): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
W/BugleNetwork( 7045): at java.lang.Thread.run(Thread.java:1012)
W/BugleNetwork( 7045): Failed to make RPC call: className=RevokeRelayPairingRpcHandler requestId=, responseId=0

It does at least fail somewhat gracefully though. It falls back to SMS/MMS and paired devices see the original device as being offline.

I happened to either be failing both BASIC and DEVICE or passing both BASIC and DEVICE. I haven't tested whether just passing BASIC is sufficient.
[Magisk] V0latyle:
Just tested with BASIC only, was able to send

Disabling PIF and rebooting, should fail all 3

Yep...failed all 3, but RCS still works fine on my Pixel 5.
[Magisk] borisSweden:
Oneplus 7T, no gapps, root with magisk, no denylist or Hide and I didn't need to use any SNet/PI module. Basically it was RCS UP, not the Google special sauce because I don't use Google Services. It even worked with Adaway so I wasn't blocking any API calls. For months I didn't update the app just to keep RCS enabled.

Either way Signal, Telegram and jailbreak iMessage isnt this picky. Cant wait for Apple pushing for UP so that Google dependencies gets dropped.
[Magisk] V0latyle:
I see there's an update available so I'll test more...but it doesn't seem to be a problem for me.
[Magisk] borisSweden:
May Google bans users who dont follow their rules. But is the requirements for RCS:

A: SNet and Play Integrity?

B: Full suite G-Apps installed?

Google doesn't get the right to be like Apple, it super rich of them to so this.

I'm crossing my fingers someone will reverse engineer the client for RCS and that the carriers will pick up some slack for Apple.
[Magisk] rocketda7331:
Does this mean that one can pass MEETS_STRONG_INTEGRITY? I was having discussion with some people in telegram, but I suppose I pushed them to the point of frustration..which I understand because the group isn't meant to satisfy my personal curiosity, even more when I am talking about things I should not talk about, but being me...I need answers (respectfully)!

For context person says using safetynetfix + changing props is enough to pass MEETS_STRONG_INTEGRITY for 5 different devices from various oems they have with unlocked bootloaders. Of course they don't claim to have broken hardware-backed attestation and this is where my brain breaks.

I will clarify: the claim comes from the fact that they say they pass all 3 checks in Play Integrity API tester app. This includes MEETS_STRONG_INTEGRITY. I have no trouble understanding getting a general "ya pass" response from safetynet, because that can be done when you hit the first 2 out of 3 at least. I have trouble understanding passing "MEETS_STRONG_INTEGRITY"

As per android docs:

Obviously I don't expect them to have broken hardware-backed attestation and in that scenario I would expect them to fail MEETS_STRONG_INTEGRITY. "has a strong guarantee of system integrity such as a hardware-backed proof of boot integrity" does not equal to me unlocked bootloader or whatever else modifications. Where am I going wrong in my understanding? How does changing props allow one to MEETS_STRONG_INTEGRITY? If we are using usnf and changing props to fool the system that we can't possibly do hardware based attestation because our devices are so old, how does that equal in getting passing grade? Is it because "hw based attestation not available" = "might as well pass"? By that logic all of us should pass? Do I need to see a brain doctor?
[Magisk] pndwal:
To be clear, hardware evaluation type is both used and this verdict type enforced for each verdict label in any device w/ the level of hardware support required for it.

This includes devices shipping with keymaster 3, Android 8.0+, but also means devices like OnePlus w/ that shipped broken keymaster implementations need to be exempted, so Google has implemented a system of whitelisting devices with working implementations based on

1) ro.product.model (for S/N and PI)

2) ro.build.fingerprint (for PI, mostly A11+ devices initially require this) and now

3) first_api_level for PI (A13 launch version devices require this)

and after an exception is thrown due to failure to access keystore causing attestation to be performed in Basic evaluation type mode, the above parameters are checked to determine if this (Basic) attestation can be accepted.

USNF leverages the current means to cause both the fallback to Basic attestation (a similar exception to the one described above thrown when making an attestation call due to a fake keystore provider being registered achieves this) and bypassing of Hardware evaluation type verdict enforcement (mismatches with checked props on Google server end whitelists achieves this).

My statement

Does NOT mean that one can pass strongIntegrity checks. It simply means hardware evaluation type enforcement can be bypassed for deviceIntegrity checks, and this is needed because hardware evaluation types are used by default where available. Effectively Google sees device as not having hardware support (like legacy pre A8 devices) as props don't match with their whitelists. The attestation can pass because basic evaluation types are allowed for this.

The strongIntegrity check is a different beast entirely, and requires hardware evaluation types (basic types are not allowed) in any case so HKA cannot be bypassed even for devices with broken keymaster implementations.*

This is why banks have not yet migrated to this check; it will necessarily exclude all Android 7 and lower devices as well as many OnePlus and other devices.

* A notable exception is Asus Rog Phone 3 which passes stringIntegrity w/ unlocked B/L... I'm not sure how that's occuring, but it seems that the attestation service that evaluates the runtime environment is somehow sending cryptographicly signed but spurious data to Google servers...

Please can you say which TG group contains this discussion and give date(s) as I'm interested in eyeballing that...

Hope this helps... 😛 PW
[Magisk] TrumpXi:
Does this mean that with my OnePlus (9) launched with A11, if I root and mod and then install the SafetyNet attestation fix, I will get HARDWARE level certification for Play Integrity API? Or I should use my second pristine banking device?
[Magisk] pndwal:
As I said, this "does NOT mean that one can pass strongIntegrity checks" w/ a modded device, even just bootloader unlocked!

Without USNF etc your device WILL use hardware evaluation and fail both deviceIntegrity and strongIntegrity... The module simply causes an allowed fallback to Basic Attestation and bypasses hardware based verdict enforcement so you can pass deviceIntegrity, but you CANNOT bypass enforcement for strongIntegrity... That's what makes it strong!

Also if your OnePlus model is among devices w/ broken OEM keymaster implementation you should be thankful Google allows the fallback / bypasses since such devices wouldn't normally pass even deviceIntegrity, even w/ stock system and locked bootloader! ... Basic evaluation type fallback occurs automatically on such devices (locked B/L or not) as simply calling hardware keystore causes an exception that causes the fallback to Basic. Also, props checked (model prop etc) are not on Google's lists for devices suitable for hardware keystore based attestation enforcement so at least for deviceIntegrity HK enforcement is automatically bypassed...

Other custom modders also be happy such devices / broken keymaster implementations exist since, frankly, enforcement bypassing on the basis of prop signals that we / USNF take advantage of are really only intended to exempt devices with genuinely broken keymaster...

Long live irresponsible OEM's like OnePlus! 😁 😛

Why not...

... But why do you want "HARDWARE level certification for Play Integrity API" when it's not even enforced by banks or Google yet?!

Isn't the deviceIntegrity pass everyone else is using enough for you? 😜 PW
[Magisk] usernamejames:
Is there something known about hardware strong play integrity/Safetynet hardware integrity fix by using the tee exploit? The maybe someone tried such a thing already. If so, I am very interested in some info about it.

I believe some devices vulnerable to the critical TEE exploits supported actually hardware integrity checks for safety net and such. Only issue is that for installing such a module you would need to (temporary) downgrade to android 5 stuff and you would need adb connection with laptop, but pretty sure it would work.

Basically: my very risky but working idea is:

- get a device with TEE exploit and hardware integrity support

- exploit it and copy the hardware check code out of the tee

- pretend with your new script to be that phone and infect your own TEE environment with this stuff.

I know it risky and a lot of effort, but at some point pretty sure it's worth it. I think I have already seen a banking app requiring hardware integrity.

NOTE: I believe google revoked hardware integrity for some vulnerable TEE devices, but I'm still confident this could work: Because A:not all vulnerable devices are blacklisted. I believe Huawei had in 2018(when they still made devices with Google stuff) had a TEE exploit. A exploit critical enough that based on my very limited knowledge would be enough to do the trick and B: even if devices get blacklisted for hardware integrity, you still can spoof old dates, trigger temporary internet disconnection and such to let hardware integrity fix work. If someone made a module for this then Google could still patch it all, so this would probably be a close source propetary paid fix
[Magisk] V0latyle:
@pndwal will be more knowledgeable on this than I am, but what I gathered from the discussion thus far is that because the bootloader is unlocked, none of the code can be guaranteed as authentic and genuine, including TEE. Trusty still works, but all results are essentially declared "untrusted". For hardware authentication to work, there has to be a solid chain of trust starting from the bootloader itself; with an unlocked bootloader, several "links" in the chain are missing.

Remember that bootloaders are proprietary code and not subject to the GPL, unlike Android itself which is designed to be open source. So, even if what you described was possible, you'd still be missing the secure "foundation" of a locked bootloader with OEM root of trust.
[Magisk] usernamejames:
Look. I don't know much about it, but if you manage to exploit your TEE then even with a unlocked bootloader the code that makes safety net hardware check succeeding is still out there. It won't disappear. So just take the code that you need and relock bootloader again. I have seen people succeeding getting a (unrelated) widevine L1 key extracting out of there TEE and wifevine L1 keys aren't usable too if you have unlocked bootloader. So, probably my story is still full of holes, I don't think this is the dealbreaker.

I edited my message about the Qualcomm 2016 tee exploit in specific because I fell in doubt that any of the vulnerable CPUs for this ever supported hardware integrity checks
[Magisk] usernamejames:
For now passing hardware integrity is pretty useless but at some point Google won't allow basic integrity phones anymore. Hardware inegrity checks are already around the 6 year old so any phone not supporting it is already not supported anymore by any company
[Magisk] V0latyle:
TEE currently has a $1.5m bounty for exploits. SafetyNet is more or less irrelevant now, although some of the same mechanisms are still in play - what SafetyNet used as the HARDWARE_BACKED evaluationType is now MEETS_STRONG_INTEGRITY.

It's also worth noting that device integrity is only part of the (in this case insurmountable) obstacle. You'd have to figure out a way to trick the Google Play servers too.

Well...we don't really know that. They could, but they've already had the ability to for quite some time, and for reasons only known to them, they haven't.
[Magisk] usernamejames:
Those $1,5m bounty's are already paid and you can find many exploits of it at GitHub. The only thing you have to do is getting a phone with a vulnerable cpu, downgrade all your software to old versions and you are good to go. I doubt that it's hard to trick the Google play servers.

Again a link to a other story: there is (at XDA) a trick requiring root to spoof a pixel phone to get unlimited photo storage at Google photos. I mean: here you can already trick google servers by only spoofing a old pixel phone without really big master tricks.

Edit: https://github.com/enovella/TEE-reversing a list of known exploits sti being exploited In the wild and typo
[Magisk] rodken:
Which also explains why one can never install OTA's successfully regardless how many times a user reflashes the original boot file and/or use Magisk to circumvent the issue.
[Magisk] usernamejames:
At the moment is unlocked you won't pass hardware integrity checks, but the stuff you need to pass the checks are still in your tee. The only reason that you can't install OTA is being unlocked l, but if you would try the same thing in a locked state ( which is obviously impossible except if trusted OTA roms are allowed in locked state) it will work again
[Magisk] usernamejames:
I really hope that some developer would actually try it, but its a lot of work for basically nothing. And in 2024 the Google play basic integrity checks still work for some reason. So I don't expect someone doing it, but I'm pretty sure that bypassing this checks won't necessarily have to be over from the day google requires hardware integrity