yashsingh1/xdaforums huggingface dataset:
[Magisk] HippoMan:
My complaint about the banks is not so much that they are trying to prevent fraud via rooted Android devices, but rather, that they are doing next to nothing to protect us against much more prevalent security threats, such as the fraudulent use of our home computers, and the fraudulent use of debit cards.

As I mentioned, a keystroke monitor can be installed on a hacked home computer, and the user's typed login credentials to banking sites can then be captured. And home computers around the world are regularly being hacked ... and there are many more of these cases than there are rooted Android devices.

To protect against cases like this, banks could require the use of anti-virus software on home computers before banking sites could be accessed ... but they don't.

Banks could issue credit-card-sized debit-card devices which have built-in fingerprint scanners to be used instead of the debit cards that are used today ... but they don't.

Banks could stop offering web-based banking services and instead, they could require home-computer users to access the banking sites via some sort of special software that must be obtained from the banks, and which would contain various checks on the home computer that must pass before access to the banking site would be granted by this software ... but they don't.

My complaint about the banks is that they are not doing enough to protect their and their users' security, and that they are mostly just going after low-hanging fruit like rooted Android phones, which comprise a very small percentage of the devices used world-wide for banking access, and upon which it is relatively inexpensive and uncomplicated to detect rooting and modding with the help of Google's security facilities and a few 3rd-party software modules.

Also, because most (all?) banks offer web-based access, I run a web browser on my rooted Android device and get full access to all banking capabilities offered by my bank. My bank doesn't prevent this, which means that their Android app (which does indeed perform root/mod checking) is useless to protect that bank's security from accesses via rooted Android devices.

What I consider to be stupidity of these banks' management is that they permit the banks' much-less-than-sufficient security policies which pretty much ignore the threats that I mentioned above, while only implementing stronger security in a very small percentage of cases (the comparatively tiny set of users who use rooted Android devices).
[Magisk] V0latyle:
They already require HTTPS...

Maybe, but good luck enforcing that, because unless the major browser developers were also to require antivirus, it wouldn't be easy to know whether there was or not. You and I both know that antivirus is mostly a waste of money, and requiring users to have third party software is a major privacy issue.

Maybe, but again...privacy. I don't particularly want my bank to have my biometric data. And as I stated already, trying to steal and use someone's debit card carries a lot more personal risk than sitting in an apartment in Russia and stealing credit card numbers over the Internet.

Sure, and if they did this, they could also require antivirus software as a dependency. I'm sure if they did, there would be a huge public issue. None of us HAVE to use the banks' apps. We can all use web browses on our phones.

We can keep going back and forth over this, but they aren't going after Android phones or users in any particular fashion. Google is simply providing them with a common means to determine the security and integrity of the device. Of course, there are some that are implementing specific root detection methods, and I could probably agree with you there - it's fairly low hanging fruit - but on the other hand, as I've stated previously, this is not so much to target white hats as it is a gross misunderstanding of the hacker community in general. They don't know, or care about, the difference between Magisk and a malicious rootkit.

And again, if you really want to complain about banks protecting their users...Go after the much larger issue of them trying to control what we can legally do with our money, instead of trying to force their users to comply with political and social agendas. We don't need nannies from the government or the banks.

I'll agree with you there.

But...we should probably carry on this debate in a different thread, as this thread is specifically intended to discuss Play Integrity and potential workarounds, not philosophical ideals.
[Magisk] HippoMan:
I have responded to you in my "cat-and-mouse" thread:

https://xdaforums.com/t/discussion-...ding-cat-and-mouse-game.4425939/post-87870573
[Magisk] V0latyle:
Interesting! Mine isn't showing developer options - I turned it on, but it doesn't appear in settings
[Magisk] pndwal:
You don't have the update either (check version)... Neither do I yet... Google staggering rollout (per region / device/ other?) I guess... PW
[Magisk] Lughnasadh:
I am on Play Store 33.6.13-21 (the version needed) but don't have Developer Options appearing in settings as well, even though I am a "developer". May also need a server side update, I'm thinking...or something else is stopping it from appearing.
[Magisk] V0latyle:
I wonder if it has something to do with the USNF mod?
[Magisk] Lughnasadh:
I'm not using that mod.
[Magisk] V0latyle:
Huh. Like @pndwal said we don't have the update...that tweet shows 33.6.13-21, and I'm on 33.5.16-21
[Magisk] pndwal:
You don't get Developer Options menu w/ Playstore DOs, but the extras show up... Eg I'm 'a developer' in 33.5.16-21 Play Store, so I see extra Internal app sharing for Devs / testers 😀:

... Guess you should be seeing an extra setting for integrity API somewhere w/ 33.6.13-21! 😝 PW
[Magisk] V0latyle:
Ah, that makes sense. I didn't take screenshots before and after
[Magisk] pndwal:
... And now all 3 of @Lughnasadh's original XDA posts re. this feature are gone, like #184 above... 🤔

See this also:

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

... PW
[Magisk] DineshValor:
Possible to fix TEE broken issue? and nothing shown up in Key Attestation!

(Unlocked, stock firmware, Magisk + extra modules)
[Magisk] pndwal:
This really means HKA (hardware keystore based attestation) / keymaster implementation is broken, part of which is performed in TEE OS... TEE itself is not actually broken in OnePlus AFAIK... If you have Widevine DRM L1 security and can watch HD streams in Netflix, Disney etc it certainly isn't as decoding must be done in TEE...

No, we can't fix broken keymaster, but that's as good a result as any modders get for attestations... All good... until banks begin enforcing strongIntegrity verdict... PW
[Magisk] V0latyle:
Looks like USNF 2.4.0 will soon be on the way and should include the PI fixes. Wonder if there's an upcoming namechange to UPIF?
[Magisk] zagreous:
Just wanted to ask if anyone else has encountered this: My play integrity check returns all three integrities failed, but everything (e.g. wallet, Netflix, pokemon go) works just fine and momo only sees SELinux rules and bootloader. Is this just an error in the app or is smthn terribly wrong? Samsung galaxy s9 is the device in question.
[Magisk] ezdiy:
Indeed this has been reported by a lot of users using selective CTS profile spoofing. What does Safetynet (yasnac) say? Hunch: Spoofed profile might be forcing a compat code path to snet in gms (apps too?) that would be otherwise retired. Google will shutdown the server side of it in 6 months (Jun 2023), only then we'll see what goes on for sure.
[Magisk] pndwal:
Play Integrity API Checker? Could be network / Quota issues... Click < > at top after check to get details in Raw JSON Response... PW
[Magisk] zagreous:
This is what my apps return, maybe you can find smthn useful, if you have the time of course.
[Magisk] zgfg:
In the Play Integrity and SafetyNet, observe the button View JSON

Click on that, read what it says and provide their screenshots (if not visible at once, scroll till the end of JSONs and post the screenshots showing complete JSON responses)

Btw, do you maybe have a custom ROM without Google Play Services?

Also, make sure that the phone is connected to Internet

Google Play Services (GMS) is required and GMS must be able to connect to the Google servers
[Magisk] zagreous:
Lol I just ran tb checker so I could provide the json and suddenly i get 2 green ticks (basic and device integrity). Idk how that happened, since I just restarted my phone (again). Thank you for your time though.
[Magisk] V0latyle:
Pesky gremlins.
[Magisk] anshul3.sharma:
While requesting integrityToken using

"integrityManager

.requestIntegrityToken(

IntegrityTokenRequest.builder().setNonce(encodedNonce).setCloudProjectNumber(projectId).build());"

It is working for dev build variant, but for prod build flavor it is giving me below error

com.google.android.play.core.integrity.IntegrityServiceException: -1: Integrity API error (-1): Integrity API is not available.

The Play Store version might be old, or the application is not allowlisted to use this API.

Recommended actions:

1) Make sure that an app is allowlisted to use the API.

2) Ask the user to update Play Store.

(https://developer.android.com/googl...del/IntegrityErrorCode.html#API_NOT_AVAILABLE).

Can anyone please help here
[Magisk] V0latyle:
@pndwal I've updated the OP yet again to reflect what we discussed about Android 8 devices.

The basics as I understand them:

Pre 8.0 devices are not capable of hardware backed attestation; so Play Integrity defaults to basic; should pass both BASIC and DEVICE_INTEGRITY in most cases even with an unlocked bootloader although the latter may require other alterations such as MHPC

Android 8.0+ devices default to hardware backed attestation, meaning that all 3 verdicts will only pass on a locked bootloader and OEM firmware

USNF mod forces basic attestation method for rooted 8.0+ devices, so they're basically in the same camp as the pre 8.0 devices

No apps are currently known to require STRONG_INTEGRITY
[Magisk] iamthecarley:
Thank you SO much for not only giving solution(s), but for explaining each bullet point in such depth and detail. This is extremely helpful in giving not only the "what" but also the "how" and "why" - much appreciated.
[Magisk] pndwal:
Actually for unlocked/rooted devices both basicIntegrity and deviceIntegrity will require hiding root from droidguard (attestation) gms process as a minimum for passing verdicts and many will need changes to sensitive prop values also. Old MagiskHide did this. Or users can add droidguard (attestation) gms process in denylist (w/ or w/o Shamiko or other hiding) and use MHPC to adjust sensitive prop values (does this even with nothing configured by user). Or just run USNF (From v2.3.1: Restored support for Android 7... Actually I think he means A7 and older per commit: magisk: Allow limited installation on Android 7 and older … "In general, users on such old versions of Android don't need to bypass

hardware-backed attestation... so allow them to install the module without the Zygisk part.") to fix sensitive props... Users may still need to hide root from droidguard (attestation) gms process manually in this case as Zygisk parts won't load... I'm not sure...

All 3 together, yes... 2 can pass /unlocked bootloader... (... The pedant in me is showing. 🤪)

Yup...

FWIW I'm working on a simplified explanation for Google's progressive employment of hardware-backed attestation, USNF's evolving bypass and fallback methods and clarification of common misunderstandings for USNF discussion thread... It's taking a while as I have limited time ATM with long days (also very flakey internet w/ vodafail and patchy WiFi in small-town Taree)... 🤠 PW
[Magisk] DartGerion:
Hi, guys!

Apologize for errors in writing, English is not my first language. For me the Gpay was working until today. I've checked the API integrity and receive the UNEVALUATED results with all integrity red. I've attached the denylist and magisk modules. Right now my USNF mod is 2.3.1 v2.0 (i know there is newest one, i've tried it with same results). Can you, please, help me identify the culprit. MOMO detects only wrong partition, so i think it's just the bootloader unlock. My phone is Oneplus 7T Pro, running stock OOS11, unlocked BL.
[Magisk] 21prods:
Hello to all.

I've got a phone with LOS installed on it. For some time I've been using 'ih8sn' to enable Google Pay, but recently it began to state that my phone is no longer secure.

Since then, I've seen that the problem comes from the change from Safetynet attestation to Play Integrity.

Is there any way to pass Play Integrity without magisk in a custom ROM? I'm happy without rooting my phone and 'ih8sn' was perfect for me (up until a couple of days, at least).

Thanks in advance
[Magisk] V0latyle:
Yes...if the fixes in USNF are implemented in that ROM
[Magisk] 21prods:
So, not much to do for the time being, at least from my side, as I don't have any knowledge to do that and I very much doubt Lineage will ever do it.

Thanks for the clarification
[Magisk] pndwal:
Official LOS will never do it... Many unofficial builds do however... But a number of users of ROMs w/ integrated SNF are reporting similar intermittent Play Integrity failures to what those using latest USNF are reporting ATM... PW
[Magisk] Arcline:
What do you guys think about KernelSU in connection to play integrity?
[Magisk] V0latyle:
What about it? @pndwal can provide more insight than I can but I don't think this would make any real difference to our current situation. We are already able to "hide" root, so having root built into the kernel won't make much difference from a detection standpoint, at least not yet. Furthermore, the issue with hardware backed attestation is the "link" between the system's cryptographic authentication and the hardware keystore; an unlocked bootloader breaks this link, and circumventing this would require not just one but two major breakthroughs - you'd have to reverse engineer the bootloader to the point where you could provide a "fake" guarantee of root of trust, and you'd have to decrypt the aforementioned link.

Basically, think of it this way: The kernel and system are sitting at one end of a encrypted "pipe"; the hardware keystore is at the other end. If the bootloader is unlocked, the pipe's integrity cannot be guaranteed, and the system knows this. So, you'd not only have to figure out a way to fool everything into thinking the pipe is secure, but you'd also have to figure out how to successfully "tap" the pipe by breaking the encryption.
[Magisk] pndwal:
I'm not up to speed with this... Just read this (interesting read):

https://www.xda-developers.com/kernelsu-gki-root/

I can't see why the challenges with respect to bypassing Play Integrity detections or hiding root / modified OS environments in general would be any easier or much different with the KernelSU approach either however...

Looks like an interesting Magisk alternative with similar potential for systemless modules etc by @weishu in much the same way as @weishu's VirtualXposed and Taichi are interesting alternatives to mainstream LSPosed... I imagine LSP support for Magisk (which is also adapting for GKI etc) may be the telling factor in development progress and uptake level differences between these two root alternatives for some considerable time, but I'm not a betting man... PW
[Magisk] oliversum:
Same here, but I'm using Universal SafetyNet Fix v.2.4.0 and Zygisk - LSPosed v.1.8.6 (6712).
[Magisk] DartGerion:
Read back a bit, maybe those tips might help you.
[Magisk] oliversum:
Thanks for your reply!

Yes, I did, but so far I didn't find a solution...

Interestingly enough: Right after a restart I get "meets_basic_integrity", but not device nor strong integrity.

A few seconds later I don't even reach "meets_basic_integrity" anymore.
[Magisk] pndwal:
You may have other issues also, but see this:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88052749

👀 PW
[Magisk] LaiKash:
Do we know why in ASUS ROG Phone 3 the keystore is broken? I'm interested on it and why exactly it can pass the STRONG hardware verification.
[Magisk] pndwal:
AFAIK keystore/keymaster/keymint isn't broken in ROG Phone 3... Seems it has working keymaster implementation but the droidguard attestation is flawed...

FWIW, since DroidGuard itself is implemented as a custom virtual machine running dynamically loaded proprietary Google bytecode (unique for each attestation request) and when DroidGuardService is triggered it also checks latest DroidGuard version has been loaded as well, I believe that the Bootloader Verification it sources for Hardware Attestation as KeyStore.getCertificateChain is really the issue, so it comes back to the OEM's implementation of AVB and bootloader... Duplicating this in other devices, it seems, would depend on finding a boot chain or low-level vulnerability.

Some of the signals that ROG Phone 3's boot chain may be sending in error are outlined in this Google doc:

https://developer.android.com/training/articles/security-key-attestation

I put something (w/ help from @shoey63) about Rog Phone 3 here:

https://xdaforums.com/t/discussion-play-integrity-api.4479337/post-87684705

and here:

https://xdaforums.com/t/discussion-play-integrity-api.4479337/post-87684959

Regarding the common failure of OEM's to test that keymaster, driodguard, AVB chain of trust, etc, responses are accurate and implementations comply with Google requirements/specs, Google seems to be tightening up at least w/ respect to broken keymaster implementations:

Guess they may need to start revoking device certifications to force OEM's to take due care with bootloader / AVB implementations however...

🤠 PW
[Magisk] LaiKash:
Could it be possible to emulate this same behaviour with an emulator so as to test it? Trying to replicate the strong integrity verification with a rooted emulator (with Play Store so that the Integrity API can be executed) could be a really good starting point for some tests :)
[Magisk] pndwal:
Emulate the flawed boot-chain VerifiedBootState data in verifiable hardware-backed key pairs with the root certificate within thie chain of X.509 certificates signed with manufacturer's factory set attestation root key etc, etc?

Maybe... doubtful... ...But I'm certainly the wrong person to be asking... 😝 PW
[Magisk] immortalwon:
Should I buy this used phone from someone asus rog 3 if I want to have strong device integrity with unlocked bootloader? Asking for a friend
[Magisk] V0latyle:
There's not really any point to passing STRONG_INTEGRITY, as there are no apps that depend on it. Most apps that are not security sensitive depend only on DEVICE result (to ensure they're running on a compatible platform) while those that are use the BASIC result as well as a mild guarantee of platform integrity. Google knows that both of these can be defeated and are not a secure guarantee, which is why they implemented HARDWARE_BACKED attestation in SafetyNet (now Play Integrity STRONG) but as far as I know, very few if any apps actually use it. As @shoey63 has demonstrated, the only "easy" way to pass all 3 is factory state locked, as with any other device; while it is capable of passing STRONG while unlocked, it's taken some work to get there.
[Magisk] immortalwon:
Thanks for the explanation. Only reason I am concerned is because one day Google will require this high level of integrity and I would like to remain unlocked and bypass the security they implement
[Magisk] V0latyle:
Well...there's no guarantee they will. They had the ability to require HARDWARE_BACKED evaluationType in SafetyNet but they never did for any of their own apps, and as far as I know, neither did any app developers. There's no saying whether they will or won't. The one thing that "protects" us is the fact that all pre Android 8 platforms are not capable of hardware key attestation, therefore they will never pass STRONG Integrity.

So while it's entirely possible that they could, it's worth noting that they always could since Android 8 (or at least whenever SafetyNet supported hardware backed attestation), but they never did.

Therefore the question is really whether they would start doing something that they never did before despite having the ability to do so for quite some time. If they could but they didn't, why would they start?
[Magisk] V0latyle:
Welp, I broke CTS profile on my device somehow and USNF 2.3.1 MOD 2.1 isn't fixing it. Time to try MHPC...
[Magisk] Lughnasadh:
Displax updated his mod to 2.3.1-MOD_3.0. Not sure if it will help.

Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

SafetyNet & Play Integrity API workarounds for Magisk - Release v2.3.1-MOD_3.0 · Displax/safetynet-fix

github.com
[Magisk] D€INOS:
Didnt work for me
[Magisk] Lughnasadh:
Yeah, seems to be working for some but not for others.
[Magisk] phaino00:
Were you able to get CTS Profile restored to passing state via MHPC?
[Magisk] V0latyle:
It did...I think. I'm not sure what broke it in the first place. I'm on the stock February release and 2.3.1 Mod 2.1 was working before...well, before I tried the 14 DP then went back to the February release.

No. Pixel 5 on TQ1A, was passing BASIC but kept failing DEVICE. Tried changing fingerprint, no dice. Tried forcing basic attestation, didn't help. Not sure what fixed it but I'm back on the stock fingerprint now
[Magisk] phaino00:
I started failing device after update to Feb tq1a stock image. Tried all variations of mods and nothing. I unrooted and locked bootloader a few days ago. I'll probably try the updated displax 's updated mod after unlocking bootloader today or tomorrow. Tough few days without root...lol

Update:. Unlocked the bootloader again and re-rooted stock tq1a Feb image. Installed Displax's SafetyNet mod (ver 3.0). Passing integrity checks again.

Thanks to all for the info.👍
[Magisk] SchWeinSAuG:
hey there

what your status in play protect certification in playstore ?

mine keeps beeing uncertified, even i pass both tests in YASNAC

you got MHPC module installed?

Also rooted Stock Tq1a. Displax Savenet mod 2.4.0 v1.2
[Magisk] V0latyle:
What device?

If Play Integrity reports MEETS_DEVICE_INTEGRITY, Play Store should report Cerified

MHPC should not be necessary on stock firmware.
[Magisk] SchWeinSAuG:
pixel 6a.

gonna try with mod v3 and without MHPC
[Magisk] V0latyle:
Make sure you reset props before you remove MHPC. You want to start from a "clean slate" so to speak with the OEM fingerprint.
[Magisk] SchWeinSAuG:
👍 thx mate
[Magisk] phaino00:
Play store is certified. I only have displax's 2.4.v1.1 installed and gpay is working too.

As @V0latyle mentioned, play store should be certified if you pass device integrity.
[Magisk] SchWeinSAuG:
ok, ill try reset fingerprint and remove MHPC module. i also registered device ID , Google Service framework ID several times and deleted data of all play apps, including framework.. no luck.

lets see..
[Magisk] pndwal:
So you should have new Play Protect Service system app by now ... Try clearing data for that, if not, Play Services and Play Store data at the same time...

No need for MHPC if using any late USNF w/ PI hardware-backed verdict enforcement bypass (based on fingerprint prop mismatch)...

No need to register device ID w/ Google to allow GM's/play services if spoofing ctsProfileMatch etc... That's needed for unlocked uncertified (China region etc) devices not spoofing props in order to legitimately use Google Apps per their concession for custom ROMs... It is possible that they could block Play Protect 'Device is certified' for registered devices (China region devices using GApps this way don't get 'Device is certified' back at least without spoofing props) so I'd avoid registering... even though they probably don't block...

🤠 PW
[Magisk] SchWeinSAuG:
ok , thanks for the insights. good to know.

ill give it a try asap. will keep posting
[Magisk] SchWeinSAuG:
thanks all.

With reset fingerprint and uninstall MHPC and the latest displax's Mod, Device now is finally certified.

oh boy , i should have come here a week ago 😂

have a good day