yashsingh1/xdaforums huggingface dataset:
[Magisk] zgfg:
You can find in this thread a link to the official Google documentation about Play Integrity API (you can google for the documentation directly on the Net), and also one interesting hacker's reverse-engineering study

Also, a flow chart and lot of posts describing how it works

Hence no eed now to recapitulatiing again - who wants to know, could/should search for

Just 'shortly" - an app asks Google Play Services (GMS) to attest PI, it generates and includes a unique token and actual timestamp to the request

DroidGuard collects data/info and sends to Google's server

Google's server responds it's verdict,, ie which of the three PI tiers the phone passes, it includes the timestamp and token from the original request and signs all that together by Google's private keys

GMS forwards the verdict JSON from Google's server back to the requestor app

Requestor app validates the signature by using G public key.

You cannot submit/reuse a 'wrong' verdict' from another phone passing PI fine since you don't have G private key to sign that verdict together with this new/actual timestamp and token from the app's request.

Or you cannot provide the old response together with it's old token and timestamp (in that case it's old signature would match), since the requestor app will validate the timestamp and token

Actually, Google recommends that your app does not generate the token neither to validate the response (somebody could temper your app), but that your (eg, banking) servers generate the token when requesting PI API attest, and that the app just forwards the obtained G verdict back to the app's server to validate the signature, responded timestamp and token and to decide what to do based on the verdict obtained from the Google's server

Hence, same data - same spoofs by using PIF module v13.7 or v13.8 with Sailfish or Taimen prints that were good to pass Device Integrity today morning, became 'banned' today afternoon - Google servers started to respond verdicts with Device Integrity failing on then

Hence my previous answer was not funny, I really asked you, do you mean to hack G servers to prevent Google updating their algiruthms that calculate the verdicts.

BCS, that's what is "happening and changing in the background"

Edit: And no use of blocking the.Network - without the verdict from G server the requestor app will not allow to continue. Hence no way to 'block'
[Magisk] sawdoctor:
I've sent it to you via pm as chiitoman never published it on xda only in the telegram group
[Magisk] BrimoFan123:
My understanding is that we need:

1. Install PlayIntegrityFix_PROPS-v2.1

2. Content of the default pif.json file need to be replaced with our own values taken from not rooted device following above guide

3. Reboot phone

4. Check Integrity using Play Integrity API Checker

I have collected the output of "adb shell getprop" from my old phone at each stage of stock ROM installation:

1. Stock ROM Android 9:

SECURITY_PATCH=2019-07-05

FIRST_API_LEVEL=26

2. Some upgrade on Android 9:

SECURITY_PATCH=2019-12-01

FIRST_API_LEVEL=26

3. Upgrade to Android 10:

SECURITY_PATCH=2020-04-01

FIRST_API_LEVEL=26

FINGERPRINT's string is different but PRODUCT, DEVICE, MANUFACTURER, BRAND and MODEL are of course the same.

Is there a chance one of these props would work with PlayIntegrityFix_PROPS-v2.1?

Asking because none of them worked with v13.7
[Magisk] BeachNYC:
13.9 works on OnePlus 10 Pro running OS 13.1. Google Pay working fine, phone passes integrity tests. Thank you!
[Magisk] zgfg:
Take the Osm0sis script, go 'manualky' line by line and fill your pif.json based on his description in the post and logic in his script. Test your PIF JSON with v2 .1 and you will know. Test some variations if needed
[Magisk] Vision:
Like i had say if you and @osm0sis and @pndwal say to update i do it, this version is better than v13.3 stable?
[Magisk] V0latyle:
What I'm wondering is...How does Google know what to fix?
[Magisk] Vision:
Because us here say to much many time, and Google of course see it 😂 and we use the same fingerprint to spoof and send the same in API Servers and Google block this fingerprint
[Magisk] Fishawy:
Many thanks or this. Please make it a sticky post in your own PF thread so it doesn't get lost in the sea of posts here :D
[Magisk] zgfg:
Or, why not - Google's tester has now a rooted phone with the PIF module installed.

When the module gets updated, (s)he clicks to update

If he monitors this thread he knows how to analyze the logs and find the built-in spoofs. Or he could inspect the siurcenfrom GitHub

Much easier, he can also test with PI API Checker and open the JSON response to read the timestamp, nonce and the checker's package name. Based on that he can find on their server what were the spoofed prints submitted in his request - and there they see how the new version of the module spoofs the prints

They could eg monitor how many same spoofed prints they receive all with the PI API Checker's package name gr.nikolasspyr.integritycheck - BCS, real users with those genuine old phones, not rooted, do not even know for PII API Checker and never test with

IMO, the most complicated part on the Google side is to make a decision.to ban or not

Should they ban those (spoofed) Sailfish or Taimen prints and thus IMO also affectt the users with genuine Taimen and Sailfish phones - when eg

some banking apps request PI API attestation for their phones, but G servers would now respond with failed Device Integrity BCS Google decided to ban Sailfish and Taimen

So, it's a risk managemnt

And btw, that's how they have now accelerated with banning the spoofed prints. They put in place a procedure where to track the conversations, how to test, what requests to mine on the servers and who on their side will be responsible to make decisions

I'm just curious, was it really worth all that effort. Eg, our dev could know how the number of downloads from GitHub, specially how many downloads were now upon Google banned v13.7 and v13.8 and regular PIF users who really depend on this module had to update to v13.9

I think it's still relatively a 'small' number - or maybe not.

Eg, for one of my module"s (nothing related to PI API) I had 27.5 K downloads since my last update in August. I guess, PIF should have many more regular users (specially now when Xiaomi.eu users have to use it - Xiaomi.eu may easily account 100K users base)
[Magisk] badabing2003:
Yes, I figured it might easily get buried here, so I stickied in the thread I had control over.
[Magisk] glennza:
Will Pixel Flasher work with KernelSU? I'm guessing no.
[Magisk] Klappp:
Does it work with KernelSU or only Magisk?
[Magisk] badabing2003:
The part about extracting build.prop / creating a pif from it and editing / testing (which is the relevant parts to this thread) yes.

If you're asking about gaining root access like in Magisk (which is the other features on PF) then no, there is no support for KernelSU installation through PF.
[Magisk] glennza:
Nice. That is good enough for me :)
[Magisk] prot-:
Are we just playing cat and mouse with Google indefinitely with updates or is there something solid being worked on ? Or is there something we are meant to do to hide the fingerprint in clear instruction?

Sorry if this has been asked over and over but can't find an easy clear answer
[Magisk] zgfg:
Game could not be played indefinitely. There is only a finite number of the old phone models whose prints are valid to be used in spoofing
[Magisk] HippoMan:
In this forum, you can see what's being worked on. It's as solid as it can be right now.

On the other hand, it's likely that over time, the Googlefrinchians will make their own phone sanitization procedures more solid, which means, sadly, that the usability of modded and rooted phones will continue to deteriorate over time.
[Magisk] BROKEN1981:
This is probably a stupid question. I have a Pixel 6 Pro. Why can't I just take a fingerprint of a stock Pixel 6 Pro to spoof my own device? Why use an older device?
[Magisk] ashus:
I assume all new devices will be required to pass STRONG validation via hardware and DEVICE will not be sufficient for them. Spoofing their device fingerprint would be useless.
[Magisk] hugson:
Yesterday I was suddenly unable to use Google Wallet on my rooted Android 13 OnePlus 8 Pro phone. When I got home I loaded the latest Play Integrity Fix and cleared the relevant cache and data settings. "Play Integrity meets device integrity" continued to fail. So I put the phone aside, intending to reinstall my Pixel Experience Rom later. Several hours later I reran the Play Integrity app having not touched the phone in the interim period, and to my astonishment it worked.

Today I can use Google Wallet. But Play Integrity gives me this:

-----

Error getting token from Google

The calling app is making too many requests to the API and hence is throttled.

This shouldn't happen. If it does please open an issue on Github.

-----

Hence this message
[Magisk] _MartyMan_:
V7 also working (Basic + Device) after a double reboot. 👍
[Magisk] gpvecchi:
So, this module replaces safetynet fix?
[Magisk] westruk:
Now we have a choice)
[Magisk] chiteroman:
Yes, when you install it, safetynet-fix will be removed.
[Magisk] supermansaga:
Yes, but presumably the original v1.3 by Displax himself should also be able to achieve it? At least that is my pixel 7 pro situation

Appreciate the hard work, but sorry, what's the advantage of yours over displax's v1.3 again? Thx
[Magisk] shellster:
Thank you so much. I'm finally able to pass all checks on a Pixel 6a (Calyxos Android 13). I was not able to do this with either the original SafetyNet Fix or Displax's additions.
[Magisk] chiteroman:
Works in broken KeyMaster devices like OnePlus and don't modify prop first_api_level in all namespaces.
[Magisk] chiteroman:
Yep, Google patched Strong bypass.
[Magisk] pndwal:
This I don't understand...

Broken keymaster devices fall back to basic-only attestations on device naturally (due to exception when registering keystore or a set flag) AFAIK, and Google exempts these from model and fingerprint prop based server end hardware-backed verdict enforcement, so they need only sensitive props reset + hiding root from possibly two GMS processes to pass deviceIntegrity assuming a passing fingerprint prop is also set if custom, China region, developer, beta ROM... Why should USNF not work also?... (Sensitive props, root hiding and fingerprint prop are all sorted!)... 🤔 PW
[Magisk] chiteroman:
Not all devices have the KeyMaster completely broken, some devices when they have the bootloader locked it works perfectly and can pass the Strong, but when they have the bootloader open this KeyMaster is broken, Trusty (or the OS that implements the OEM in the TrustZone) does not generate the certificates or sign them so they fail the DEVICE verdict (CTS).

What kdrag0n proposed and Displax maintains in its module is to change the props in the getService of the AndroidKeyStore, if this Provider does not exist then the props are not changed and the verdicts will fail.

My module will just inject itself at app startup and change the device model and then do the trick to drop the exception in the getCertificateChain.

Also, it's all done from scratch, native libraries and Java code, the only exceptions are the props files that are changed.
[Magisk] ele3131:
Tested V7 and it fails CTS while v2.4.0-MOD_1.3 works (Samsung S9 Snap - CrDroid A12)
[Magisk] pndwal:
Thanks for this clarification!...

Please indulge my curiosity/ignorance a little more as I'd love to understand this property...

Are you saying that in USNF the change to prop values (ie. to register a 'fake keystore', cause an exception and fallback to basic-only attestation) relies on the correct keystore provider working in the first place (Which would be an issue where OnePlus breaks that, and I had assumed that that the exception was always triggered where device/driodguard was using hardware backed attestation signals)?...

And that your module injects into GMS zygote at runtime (BTW, I think since 2.4.0 USNF uses a similar approach, "spoofing dynamically at runtime only when necessary" although the official build still has major timing/other issues) and ensures that the getService props are changed (ie. a fake keystore provider does trigger an exception in getCertificateChain and fallback occurs) so that deviceIntegrity passes with basic-only signals even where a keystore provider was not found (due to a keymaster anomaly where it seems AVB chain of trust certificates aren't produced by TEE OS if B/L is unlocked)?

... I'd appreciate it if you could point out where my understanding may not be correct. 👍

Really appreciate your efforts for modders. 🙂 PW
[Magisk] chiteroman:
Crdroid didn't spoof props by default?
[Magisk] ele3131:
I don't think so, maybe because it's a old version (8.11) idk.
[Magisk] chiteroman:
New update released! V7.1

Changelog:

- If your device has first_api_level less than 33, the module won't hook prop and close itself (less code in memory).

- Bring back Provider setProps way, so devices with custom ROM should spoof props properly now.

Check OP or update from Magisk app.
[Magisk] chiteroman:
Check new version.
[Magisk] ele3131:
New version works fine! Thanks for the update =)
[Magisk] ashok:
The new version only passes Basic in OOS 13.1 with KernelSU
[Magisk] famusc:
Hello, I'm on Xiaomi 13 ultra (with xiaomi.eu) and I just installed latest 7.1. Sometimes it passes both play integrity and safetinet and sometimes it doesn't: if I try twice in a row, first try fails and the second passes. Is that normal? Does it need a sort of settling time? Or maybe should I try old version 7 (if someone can upload it again) or displax 1.3?

@chiteroman any idea?

Thanks
[Magisk] strayh_:
How do I fix this?

View attachment 5978919
[Magisk] V0latyle:
It's because too many people are checking. Use Play Store internal check or use TB Checker

@chiteroman may be a good idea to post something like this in the OP so that people don't keep asking the same question over and over again
[Magisk] HippoMan:
Is there any way to find out the build props of a ROM simply by examining the contents of the ROM's flashable installation file? ... i.e., without installing the ROM on any device?
[Magisk] badabing2003:
Yes,

@osm0sis already stated that you would need build.prop from system and vendor.
[Magisk] hugson:
Thank you for your help. The Play Store internal check works perfectly (I should have thought of that myself). But the TB checker shows a fail against Device Integrity, so I'm not sure why.
[Magisk] oldman20:
great, google play store now certified, but my bank detect rooted when using zygisk :(( (current running kernelsu)
[Magisk] HippoMan:
Thank you.

I missed that message.
[Magisk] sir_bazz:
Thanks for all your efforts guys.

It's hard to understand why it's needed though, as the only other solution, (in many cases), is to go back to our outdated, unsupported, and unmaintained OEM ROMs, forgoing all the newer security fixes that only custom ROMs can provide.
[Magisk] HippoMan:
Yes. As the usability of Android continues to deteriorate, going back to older OS's is an improvement.
[Magisk] JpegXguy:
Google apps have admin level access to my phone but deny me the same thing. This doesn't happen for PC. They recently tried to bring an integrity API to chrome and there was a huge backlash (but they will try again!)

And you are correct about certain anticheats, I just don't encounter that because I don't really game.
[Magisk] rseiler:
What's the litmus test for the efficacy of custom.pif.json in /data/adb/modules/playintegrityfix if you were already passing beforehand by virtue of 13.9 alone?
[Magisk] DanGLES3:
Google Apps don't exactly have admin level access, they have privileged access which is still nowhere near as powerful as root
[Magisk] thesingular:
Unlike Google apps which caches play integrity results for a period of time, once banking apps detect root, they save that status indefinitely or not save at all. If it saves that, the only way to revert it is to clear the data of the banking app(or uninstalling and reinstalling it, which does pretty much the same thing except you'd have to download it again). So please clear the data of the banking app and try again. If it still detects root, please install the latest Shamiko module if you haven't already, clear the data of the banking app, reboot and try again.

Edit: If it's only when using Zygisk and fine when not using it (I just noticed and in that case it seems the bank doesn't save the status at all.), then just install the latest Shamiko module and reboot before trying again.
[Magisk] xdatin1:
After update to version 13.9 my banking apps wont work and I have Trust - Systems security error: This build was signed with public keys
[Magisk] osm0sis:
Try this one: https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/page-175#post-89189197
[Magisk] arda99:
I didn't see the PR earlier...imho as all these(stat/fopen/access) done in few μs so no difference when handling few files.
[Magisk] c3k:
Previous is true?

Adding an account I've received a login notifications coming from a Nexus 5X, so I understood pif was masking even on 12.3.

But...:

- json reply in play store reports my real device (S21), which app see the masked device?

- Google Pay was blocked when I install 12.3, after two days works again, yesterday blocked again (I lost MEETS_DEVICE_INTEGRITY), maybe Google blocked my real fingerprint, confirming it's not masked, but seems to come and goes in the Google's blacklist

Now I have to start the research for an acceptable fingerprint (🥳😒), but I'd like to understand a little bit more how the things works.
[Magisk] zgfg:
If your fingerprints were ok to pass PI on your modded phone (unlocked BL, etc), then why would you need to spoof them by themselves ('replace' them by the same ones)?

Obviously, yours are not good BCS Google reads from them that your phone was released with the built-in Trusted Execution Environment (protected 'environment' on the chipset), hence Play Integrity must push Strong attest on your phone, it will not accept fallback to Device Integrity. And you cannot spoof TEE to pass Strong Integrity once you have unlocked your Bootloader - root cannot temper TEE

Instead, you have to use spoofed fingerprints, them PI will say ok, you have no (valid) TEE, we cannot attest Strong Integrity so let's test Device Integrity instead, and then Device Integrity (purely software based) can be spoofed with root and you will pass Device (but no Strong)

Without the spoofs, PI will not bother to test Device Integrity (to give you a chance to spoof) - it forces Strong first and from the Strong it recognizes that the phone was modded, hence in the verdict you have: neither Strong passing checkmark (tested but failed) nor Device passing (not even tested)
[Magisk] Vision:
Yeah true all, for that the pif.json is important feature
[Magisk] xdatin1:
My banking apps works now.

Thanks
[Magisk] habeck.colibretto:
Yeah. Instead of 13.9 chiteroman PIF your works. Have you changed fingerprint or what?
[Magisk] beeshyams:
Thanks for a nice explanation 👍

It leaves me with a doubt, probably a stupid one. I am getting old and tired of these cat and mouse games. So, if I unroot by Pixel 6a (which has TEE, I guess) and keep the BL unlocked, am I still in trouble. Of course I will not pass strong integrity but will that cripple my usage of Play Store, Gpay etc?

I could lock the BL but I don't want to go through the hassle of setting up everything
[Magisk] osm0sis:
Nope, just fixed when some of the props are getting set.

See https://github.com/chiteroman/PlayIntegrityFix/pulls

I'm at work right now on night shift, but hopefully will have time to fix things to chiteroman's liking in the morning when I get home. 🤞🙂
[Magisk] BrimoFan123:
I'm passing Device Integrity with PlayIntegrityFix_PROPS-v2.1 and custom values in pif.json file.

Wallet works not giving any security related errors/warnings although I did not made a payment with this PIF version yet.

Custom fingerprint gives a higher chance to be not banned by G.

I'm really happy :)
[Magisk] zgfg:
Nope. Unlocked BL is a gateway for modding the phone. Locked BL is one of the items on the Strong Integrity checklist

IMO, like, it seems your firmware is official but cannot be 100% sure since with the unlocked BL maybe the ROM was modified and it's just well-hidden

Or, more likely, currently you have the official firmware but since your BL is unlocked, you or a thief who comes in a possession of your phone can flash something (custom ROM or custom Recovery) that could access your existent data, etc

If the BL is locked, then no fkashing is possible without unlocking BL - but that (as relocking,, too) would inevitably format your Data first

Moreover, relocking BL requires both Factory reset and official firmware (locked BL does not allow booting to the ROM not signed by the vendor)

Hence locked or not BL is a very good sign how 'safe' is your phone
[Magisk] sawdoctor:
Thanks for all the work, time and effort you are spending on this. It's really appreciated, so few people keeping the modding community alive ATM.

Really doesn't get said often enough Thank you
[Magisk] beeshyams:
Inevitable I guess that I need to lock BL

Having said that, only hope is the "risk management" you spelt out plus if they aggressively push for strong integrity, their own apps like Gpay would take a big hit and that wouldn't help. OTOH, it probably makes sense(at least to me) to make the BL unlockable if they go aggressive. Google isn't anti-modders the way I look at it by allowing easy unlock (no queue, no waiting period etc), so I am optimistic that they wouldn't go aggressive anytime soon... But ego knows.

Thanks again for your patient explanation
[Magisk] Gersp52366:
And if, for example, we take the rooting method via Msm Download Tool

just change boot.img in the firmware for patches

As a result, it will turn out that the bootloaders will be blocked and root access will be on the phone

Then will it be possible to pass meets_strong_integrity?
[Magisk] zgfg:
Cannot tell you about the quirks.

But as said, locked BL is ONE OF the items on the Strong Integrity checklist

Here, again, posting the link to Google's official PI API documentation. It's not a single page - observe Next,Next, at the bottom of the pages, there is a LOT to read

You will find details what shall exactly be tested and guaranteed by each Integrity tier

Overview of the Play Integrity API | Google Play | Android Developers

developer.android.com

And don't forget - Strong Integrity checks are executed on the TEEE and signed by the TEE private key, hence could not (uppercase SHOULD NOT like with the meaning as in the IETF RFC 2119) be tempered by eg a custom ROM you flashed by MSM
[Magisk] mrspeccy:
Me too. I have installed PlayIntegrityFix_PROPS-v2.1 and taken the fingerprint of a roughly 5 year old phone (which is still in use, by the way) to pass DeviceIntegrity on my rooted Android 13 device. I agree custom fingerprints are the way forward for now.
[Magisk] Gersp52366:
can you tell me how you took the print?
[Magisk] bakaekze:
🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com
[Magisk] BrimoFan123:
Run "adb shell getprop > c:\temp\props.txt" on your PC while you have your "old" not rooted phone connected to that PC.

My assumption is that you know how to enable USB debugging in Developer Options and you have android platform-tools (adb) available on your PC.

Then get the values from the properties in props.txt and map as follow into json file:

ro.product.name -> PRODUCT

ro.product.device -> DEVICE

ro.product.manufacturer -> MANUFACTURER

ro.product.brand -> BRAND

ro.product.model -> MODEL

ro.build.fingerprint -> FINGERPRINT

ro.build.version.security_patch -> SECURITY_PATCH

ro.product.first_api_level -> FIRST_API_LEVEL

There could be different properties depending on Android version as I understood from one of previous posts so please scroll this thread and find details.