yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
Well, the API is proprietary, and I have no doubt that Google has implemented some measure to ensure that the API itself has not been tampered with. One also must consider that if we DID successfully hack local Play Integrity, Google would no doubt patch it and reject token requests from vulnerable versions.

It's an interesting idea and I'm not trying to be dismissive or anything, but doing this would probably be very very hard in practice if not impossible, so unless we stumble across some sort of breakthrough, we have to settle for "good enough".
[Magisk] teknixstuff:
Yea, but we can just spoof whatever API tamper checks they want, since those will all also be in the same place as the API (or somewhere similar). And yes, google will push an update the moment we mod it, but we can just mod the updated version. A (probably quite easy) cat-and-mouse game of updates and patches will occur, and we will always stay one step ahead of google!
[Magisk] V0latyle:
Well, the assumption here is that we'd be able to reverse engineer it in the first place. Without being able to do so, the whole point is moot.
[Magisk] zgfg:
Sorry but APIs that use cryptographic keys are not that 'primitive'

I'm writing by heart but you can check for technical details in the documentation that has been included to the previous posts in this and other related threads

Application A that requests a signed response from the other 'application/service' B (being eg TEE in our case), sends also a randomly created (hence unique) nonce with its request.

Responder B must respond by including back also the nonce it received and the actual timestamp, together with its 'real' response data, and all that must be signed together by the private key of B

Therefore, if you provide an old, reused response from another, not modded device with locked Bootloader, that response would contain the wrong nonce and an expired timestamp - hence the receiver A will immediately know that your answer is fake and invalid

If you update the nonce and timestamp (with the new/actual ones) in that reused response from another device with locked BL, then the corresponding reused signature will no more match because that original signature was based on the concatenated string that included the old/original nonce and timestamp from the other device - hence A again knows that your answer is invalid

And the private key is in the hardware, Trusted Execution Environment Read Only Memory and TEE does not provide API to read the secret keys - hence you cannot reverse-engineer that private key from your ROM/firmware to make your own responses and sign them

Btw, if you think that you can really break TEE on Titan, then look for the current Google's reward offers - you could make a lot of money
[Magisk] teknixstuff:
I know about the nonce/timestamp, but I'm not saying to get the TEE response from the bootlocked device. Instead I'm saying to get the TEE secret (or whatever is needed to emulate the TEE) from the bootlocked device. And I get there's no API for getting TEE secrets, but since this would only have to be done once (and then just upload the secrets to XDA probably?), a hardware based attack (like Team Tweezers did on the Nintendo Wii SECUROM) could work, or an attack like Woron Scan does for SIM cards (which are basically just a TPM/TEE on a card). Also the source code for the TEE software is publicly available from google (search for "Trusty TEE"), and anyway the bootloader gets to send and run the TEE, so a hacked bootloader (or better yet a custom kernel impersonating the bootloader?) could reveal the secrets. Plus failing that, couldn't someone just write an app you can run on a bootlocked phone that allows to proxy the requests from any rooted/ROMed phone to it?
[Magisk] teknixstuff:
Reverse engineering an android app is not too hard (just look at all the ReVanced patches), and I'm fairly certain this is implemented in Google Mobile Services aka GApps, probably Google Play Services
[Magisk] zgfg:
How about 'industrial espionage' - the cat listens what their mice are doing and will blacklist the broken key😁
[Magisk] teknixstuff:
They can't really do that, because, for example, if we got the key from a Pixel 8, then ALL Pixel 8 devices (Potentially even all Google devices!) would no longer have a trusted key! Also if they tried to change the key, we could just grab the OTA and get it from there. Come to think of it, aren't they already somewhere in the factory images, since every time I install a ROM on my Pixel, I first format data from TWRP, which says something like "Erasing Titan M...", implying that the Pixel stock ROM must contain the secrets from the Titan!
[Magisk] zgfg:
That's the risk mngmt at the end - do they want/need to sacrifice all eg Pixel 8 devices or not

But again, Google does not require Strong Integrity for their own apps. Hence if they take the drastic step and blacklist, it will not affect Google's Wallet, etc

And AFAIK they cannot replace the TEE secrets by OTA - it won't be really a trusted environment then
[Magisk] HippoMan:
Yes, and I'm sure that there are cats who read our discussions here on an ongoing basis.
[Magisk] V0latyle:
Well, there ARE many bots that crawl this site every single day, cataloging everything contained herein...
[Magisk] zgfg:
Well, that's interesting. But the bots are also indexing for the Search machines (Google, Baidu)
[Magisk] HippoMan:
I have no doubt that at least some "cat" people just connect to XDA via their browsers like we do, and that they simply lurk here to read these modding/rooting-related discussions.

No bots are needed.
[Magisk] zgfg:
And they sometimes ask how to hide root from (their) apps. When they get answers, they fix in the next updates
[Magisk] Viiip_s1:
Thanks
[Magisk] mko000:
I actually thought about that while reading your posts...wouldn't that be an option maybe?
[Magisk] pndwal:
No.

That's exactly why AVB / root of trust / hardware keys / TEE OS environment etc were developed; to make these functions possible only in a seperate trusted OS environment and conversely, impossible in the rich OS (Android etc) environment, sometimes referred to (loosely) as userspace...

Many modders are confusing TEE with the Keymaster implementation associated with device/software integrity attestations... These attestations simply derive from a TEE OS environment and it's keystore... "Broken TEE" is generally a misnomer; eg only the Keymaster implementation may be 'broken' while HD video stream decoding, fingerprint scanning and other operations requiring TEE support continue to work fine.

On devices with a TEE implementation, the main processor is often referred to as “untrusted”, meaning it cannot access certain areas of RAM, hardware registers, and write-once fuses where secret data (such as, device-specific cryptographic keys) are stored by the manufacturer. Software running on the main processor delegates any operations that require use of secret data to the TEE processor.

TEE in Android is an OS in ARM Trustzone. It runs on the same processor as the Android OS, but isolated from the rest of the system by both hardware and software. TEE is thus a secure area inside the main processor where code is executed and data is processed in an isolated private enclave such that it is invisible or inaccessible to external parties. Here is Google's Trusty TEE, a 'Secure but open source TEE' (Nb. OEMs are free to implement various TEE OS's in their Android builds):

https://source.android.com/security/trusty

Note that being open source, there is no need to reverse engineer this TEE OS used in Pixels and many (most?) other Android devices.

Uses for TEE include the DRM framework for protected content (software running on the TEE processor can access device-specific keys required to decrypt protected content), mobile payments, secure banking, multi-factor authentication, device reset protection, replay-protected persistent storage, secure PIN and fingerprint processing, biometric scanner + other implementations for secure hardware, and even malware detection.

I put other technical details re. differences between REE and TEE etc here:

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

The rest is really just wishful conjecture having established its nigh on impossible to 'fake' a TEE OS implementing a manufacturer's certified cryptographic keys and other secured (secret) data, and even if the desired fake strong attestations could be produced (effectively bypassing the hardware backed checks for verified boot, ie that the device is Google CTS/VTS compliant), Google has demonstrated its ability and determination to revoke the appropriate embedded keys anyway...

Nb. Back in March 2020 John Wu had much to say on the emerging reality of TEE attested device integrity verdicts. Notable was this series of 6 FAQs answered:

https://twitter.com/i/web/status/1237830555523149824

And just a couple of years ago he said this:

https://twitter.com/i/web/status/1462383098667040770

👀 PW
[Magisk] V0latyle:
By the way @pndwal @zgfg is there any benefit to using @chiteroman's Play Integrity Fix over @Displax's Universal SafetyNet Fix MOD?
[Magisk] pndwal:
Yes, @Displax never got shipping level properly targeting GMS Droidguard with API level 32 for P7, P8 series and other A13+ launch version (API/SDK 33+) devices... It will work but can break VoWiFi and likely other functions due to global setting...

No advantage for most devices launched with A12 or less other than some ROMs with strange SNF implementations or spoofing for the fixed P2 STRONGINTEGRITY, especially XiaomiEU ROMs, extant... @chiteroman has apparently succeeded in bypassing many compatibility issues with such ROMs in PIF builds... PW
[Magisk] V0latyle:
Sounds good, I'll update the OP
[Magisk] oled65cxpua:
I am failing all checks. Could someone please help me diagnose what's causing the fail?

I am running Zygisk on Magisk Delta 26.1 (I can't run the beta version as it causes crashes) on Android 9 64-bit:

With Universal SafetyNet Fix v2.4.0-MOD_2.0:
[Magisk] V0latyle:
What device? Custom or stock ROM?

Have you tried Magisk Stable?

Try Displax USNF Fix 2.4.0_1.3
[Magisk] oled65cxpua:
Thank you for helping. I'm using Noxplayer emulator. I'm unable to run Magisk Stable. I tried Displax USNF Fix 2.4.0_1.3 and it still failed all three checks.
[Magisk] V0latyle:
Keep in mind that the point of this thread is to make people aware of what Play Integrity is, and how it affects using unlocked/modified phones that are already ostensibly ceritifed by Google. An emulator is a whole different ball game, becuase it doesn't have hardware that corresponds to a CTS approved device.

From the OP:

For a device to pass DEVICE_INTEGRITY it must match the hardware and software profile of one that has passed CTS and has subsequently been certified by Google to run Play Services.

You might be able to spoof a certified profile using MagiskHide Props Config.

You may also be able to get around this with this guide:

How to Fix the "Device is not Certified by Google" Error

Are you having trouble with signing in to your Google account? Can't access the Google Play Store or use Google apps like Gmail, Maps, Play Music, or Photos? Seeing a "device is not certified by Google" error? Here's how to fix that.

www.xda-developers.com
[Magisk] oled65cxpua:
Thank you. MagiskHide Props Config didn't work either, unfortunately. Do you think there could possibly be some other way of running Android apps that require device_integrity on PC? Could one spoof a CTS device to pass device_integrity while running Android through VirtualBox?
[Magisk] V0latyle:
I don't know enough about emulators to say. I have indeed played around with Android Virtual Devices in Android Studio, so I know any Google Nexus/Pixel device can be emulated, but I wasn't able to figure out how to root with Magisk because I don't know how the emulator images work.

At the end of the day, as I expressed above, the device profile has to be CTS certified, whether it's through spoofing or through registering your particular profile.
[Magisk] zgfg:
Btw, XDA (not the Forums) is detecting ad-blocker and I was not able to open the link

However, by enabling Desktop site, it opens😁
[Magisk] V0latyle:
Stuff like that is handled by @willverduzco or you can bring it up here, none of the moderators can fix site issues so if something isn't working we are just as limted as you are :)
[Magisk] willverduzco:
Interesting indeed, and thank you for flagging.

I see you were running standard Chrome for Android, so I assume no ad blocker was enabled. Was there by chance any system-wide ad blocking via hosts file and/or something equivalent being done by your router and/or DNS provider? All of those could lead to the same sort of anti-ad blocker flagging.
[Magisk] zgfg:
I know (earning money on ads) - I just observed but then realized that it can be easily tricked
[Magisk] zgfg:
Hmm, I'm wondering should I respond or not😁

But, yeah, I have AdAway on the phone
[Magisk] V0latyle:
Probably better to do that in the Feedback thread :)

+Quote, go to Feedback thread, Add Quote, reply
[Magisk] immortalwon:
No safetynet / play integrity fixes work on emulators. Someone has to create a specific bypass for an emulator like Nox or bluestacks for it to work. @chiteroman might be able to find a solution if he has time.
[Magisk] pndwal:
I don't know much about emulators either, but the following POC shows that it can be done...

Generally, USNF is for causing an exception/error to trigger fallback to fully 'basic' attestations to signals on a real device as well as for bypassing hardware backed attestation server end enforcement... Also, banks accept another attestation label designed for emulators and I'm not sure how the fact it's not a real android device is able to be hidden... I put info here a while ago:

https://xdaforums.com/t/module-mod-universal-safetynet-fix.4553699/post-88702211

However we got this information back in July:

https://xdaforums.com/t/poc-safetynet-bypass-for-emulators.4607061/

Video shows SafetyNet pass for "Genymotion" in YASNAC on emulator w/ 'Droidguard Emulator '. 😃

... Not much more since July apparently, but it's interesting... Looks like it could be pentester's dream if SDK progresses beyond PoC...

The second poster also has it working with 'Jamboree' running Android 12; this project:

https://github.com/freeload101/Java-Android-Magisk-Burp-Objection-Root-Emulator-Easy

Open issue in Devs own GitHub:

https://github.com/freeload101/Java-Android-Magisk-Burp-Objection-Root-Emulator-Easy/issues/49

Hope info. helps... 🤠 PW
[Magisk] oled65cxpua:
Would I just be better off buying an old Galaxy S7 or S8 and then running Zygisk and chiteronman's fix in order to run an app that performs integrity checks while rooted?
[Magisk] pndwal:
Probably not... S8, launched with A7, will never pass PI STRONGINTEGRITY even stock/locked...

Unlocked/rooted, any device can pass DEVICEINTEGRITY... When banks start enforcing STRONGINTEGRITY devices launched with A8+ / Keymaster 3+ will be able to return to locked/stock and run such apps... Pre A8 LV devices won't be able whether unlocked/rooted or locked/stock...

🤠 PW
[Magisk] oled65cxpua:
Then I should probably just buy a Galaxy S9 or A9? Anything that was released after Android 8?
[Magisk] V0latyle:
I think @pndwal got a little ahead of himself. If your intent is to test an app on a rooted device, the only thing that matters is whether the device supports the minimum Android version the app needs. Since you'll be rooted you cannot pass STRONG integrity.

I'd personally avoid Samsung devices for development testing. Get a Pixel. Looking on Swappa, I'm seeing S9s for about $80; for that price you can get pretty much any Pixel up to the 4a.
[Magisk] pndwal:
If you want be able to pass STRONGINTEGRITY by restoring stock images/locking in future, then yes, however banks may wait a long while before accepting customers with older devices as collateral damage... ie. there will likely be no great rush to migrate to that...

Of course once that occurs no modders, whether with old or new devices, will be able to use devices with custom mods for bank apps etc... 👀 PW
[Magisk] pndwal:
Actually I missed that you're the emulator guy (or gal?) due to broken conversation...

To add clarity regarding real devices, you don't actually need PIF or other USNF fork solutions to pass DEVICEINTEGRITY on pre A8 / keymaster 3 devices anyway. (Since these use BASIC only attestations in any case you need neither USNF's on device fallback trigger or the prop based server end hardware-backed verdict enforcement bypasses.)

Stock ROMs should simply pass DEVICEINTEGRITY with some simple adjustments to a few 'sensitive' props (setting these to non-suspicious values) eg by installing Shamiko, and after rooting, by additionally hiding that from GMS by adding Google Play Services main (com.google.android.gms) and Droidguard/attestation (com.google.android.gms.unstable) processes to denylist...

USNF builds essentially facilitates passing DEVICEINTEGRITY verdicts using BASIC only evaluationType on devices that ordinarily default to HARDWARE_BACKED attestations, ie those with hardware for keymaster 3.

👀 PW
[Magisk] V0latyle:
Well crap.

Phone rebooted itself at some point and lost root. Re rooted, I'm passing 2/3 Integrity labels, but Wallet says this even after clearing data.
[Magisk] immortalwon:
Clear cache + storage data of Google play services, google wallet, Google Play Store & google services framework.

NOTE: You will have to re-add your CC to the wallet.
[Magisk] V0latyle:
Yeah, just did, everything is good now.
[Magisk] V0latyle:
Looks like Google tried to implement something similar in Chrome:

Chrome not proceeding with Web Integrity API deemed by many to be DRM

Back in July, Google's work on a Web Integrity API emerged and many equated it to DRM. The company announced today it's not proceeding...

9to5google.com
[Magisk] intel_core_i7:
I brought it up here before, but google deciding to drop it is a relief
[Magisk] pndwal:
Yeah... I think your point

was largely missed due to video's equating it with DRM as the Google9to5 article alludes to in the title "Chrome not proceeding with Web Integrity API deemed by many to be DRM"...

Looks like Louis Rossmann's prediction "Google's attempt to DRM the web should fail" came true however. 🙃 PW
[Magisk] intel_core_i7:
One thing most people complaining missed is that there's already something similar on their phones - PI. No one seemed to mention it while talking about web environment integrity
[Magisk] V0latyle:
I don't know much about the proposal but it sounds to me like it would have been more oriented towards desktop users.
[Magisk] Dima064:
Hello. I've encountered a problem where on YASNAC I get both ctsprofile and basic integrity passed but on Play Integrity Checker it shows that I have only Basic integrity. I use J710FN with Custom ROM labeled as A7 Port, so basically every app thinks I have an A7. Play Store also shows my device as uncertified. Anything I can do to fix this rather than factory reset?
[Magisk] V0latyle:
Did you read the first post? That should always be the first thing you do. Learn why this is the case, try the recommended solutions, and if those don't work, ask your question.
[Magisk] Dima064:
I did read the post and the thing is that I use the mod of USNF with Shamiko and it worked once and never again (I installed the ROM 3 days ago). The ROM's creator has quit modding my model, so I'm empty-handed I think.
[Magisk] pndwal:
Folks, watch space from here:

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

🙃 PW
[Magisk] pndwal:
Please run Play Integrity check... 😉 PW
[Magisk] V0latyle:
Yeah I'm failing DEVICE, Displax mod 1.3 with Magisk 26.3

I wonder if Google could somehow enforce hardware backed verification by comparing device platform (hardware and software) with evaluation type (basic vs hardware backed)?

For example, on devices with Android 8.0, or at least those that launched with 8.0 or later, they should be able to pass all 3 if unmodified, so I wonder if Play Integrity could check for some sort of mismatch - device is on Android 14 for example but evaluation type is basic, when it should be hardware
[Magisk] zgfg:
No need for them to enforce Strong Integrity. They have already enforce proper Device Integrity checking and spoofs do no more work as of today
[Magisk] V0latyle:
So we know for a fact that's what is happening?
[Magisk] zgfg:
See in the other thread - PIF module
[Magisk] V0latyle:
Passing again with @chiteroman's v12
[Magisk] pndwal:
Told you! 😜 PW
[Magisk] V0latyle:
You did?
[Magisk] pndwal:
Well,

...

Same same... 😜 PW
[Magisk] V0latyle:
Not quite what it was from my perspecitve.

I had no idea something had thrown a wrench into the works and caused previously passing devices to fail. Y'all pointed that out, and @zgfg mentioned Google had all but defeated our fixes. So it sounded to me like we didn't know of a solution. Only upon reading through @chiteroman's thread did I realize that some people have been passing using v12 of his mod.
[Magisk] pndwal:
🤷 Sorry then...

Had tried to help both the fella above and you saying 'check that discussion' and 'check your own Play Integrity'... Guess I should have spelled it out, but apparently I've done that too often.

... The 'Told Ya' was only tongue in cheek since

which I 😍'd... PW
[Magisk] V0latyle:
No harm no foul, good buddy
[Magisk] Lubo99:
Same here... I dont know what happened
[Magisk] zgfg:
Since you are in the wrong threado - gogle for:

XDA Play Integrity Fix

open that thread, read what was posted there since yesterday, download and install the module from its OP post #1 (unless you have Xiaomi.eu MIUI 14, then the module will not work) to have your Device and Basic Integrity passing again
[Magisk] asamofal:
Thanks, it helped me too.
[Magisk] Lubo99:
yes i found yesterday solution chiteroman's fix
[Magisk] Nekromantik:
on my pixel 7 pro stock ROM i cant pass saftynet anymore using Play Integrity Fix latest

might try go back to USNF
[Magisk] sawdoctor:
Which version? PIF V12 onwards are all working. USNF is now completely broken thanks to Google
[Magisk] V0latyle:
I didn't have any trouble using PI Fix. Installed it, disabled USNF, passing BASIC and Device.
[Magisk] Nekromantik:
tried 12.2 and 12,3

when I use saftynet checker apps they cant check if I pass it or not

never seen that before
[Magisk] pndwal:
Message like this?:

Doesn't mean PIF is failing... It's cos everyone's checking using non-commercial app... See:

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

😜 PW
[Magisk] Nekromantik:
Ah ok.

Even so wallet did not work on either versions.

Usually I just enable zygisk. clear cache on play services and google wallet and reboot and i can use wallet but now i cant use wallet keeps saying does not meet requirements.
[Magisk] pndwal:
Clearing caches isn't enough... must clear data or wait a few hours or days... And that's assuming you have DEVICE_INTEGRITY...

The conversation I linked explained how to get inbuilt Attestation check results that shouldn't be subject to a quota (via Play Store Developer menu, not regular Developer options)... Did you check verdict? 🙃 PW
[Magisk] Nekromantik:
it says device integrity

will try clearing data on play services and try again next week
[Magisk] V0latyle:
@pndwal Remind me, is it possible (at least theoretically) to pass STRONG with locked bootloader and custom root of trust? Assuming the CTS profile is approved.