yashsingh1/xdaforums huggingface dataset:
[Magisk] xantrk:
Surprisingly, it didn't work. I tried resetting GSF again but couldn't get it to work. Whatever device chrome detected is sticky but not a huge deal for me as I didn't commit to passkeys big time, but I do love to use them. Something worth being aware in long term I guess. Will keep unpatched boot trick in mind! Thanks a lot
[Magisk] Vision:
Can we add with notepad the pif.prop for add our fingerprint and compression again in the module zip and after flash it ?
[Magisk] zgfg:
In the zip file before you flash - you can unzip, edit, re-zip and reinstall the module with your changes

Once installed (and rebooted), in the module's folder

/data/adb/modules/playintegrityfix

(btw, no problem to edit with MiXPlorer granted root)

After changing the prop file, reboot

It applies only to v13.1 - earlier module versions did not have that PIF.prop file
[Magisk] zgfg:
See post #2496 (just above, posted right after your Q)
[Magisk] Vision:
Thanks, just show it. One last about that, extract the pif.prop edit with notepad and after with 7-zip send back and replace the original and that's it ? No specific compression?
[Magisk] iruiz2:
Exactly.

Or, you can edit it in your android phone and reboot.
[Magisk] Vision:
Thanks for answer and advice
[Magisk] zgfg:
Yes but.you must make sure that zip file has the same structure as the.original

Eg, that when you open your zip, that it would not contain a folder:

Play_Integrity_Fix-...

bcs some zippers want to include additional folder into zip, and then put the files into that folder.

But Magisk app would fail to read/install such an improperly formatted module's zip file

but directly files and subfolder as on the screenshot

I actually always unzip modules, edit prop and sh files and re-zip directly on the phone, by MiXplorer (in Download folder) and then (re) install them
[Magisk] immortalwon:
The question is: Where do we get fingerprints and / or other props to use successfully? This reminds me of the magiskhideprops config module.
[Magisk] mac796:
I was gonna try pulling them from some of of my old phones when I get time.
[Magisk] mac796:
So for me to pull the props values off an old device. I take it it has to be rooted. Then would it need to be put back to stock and bootloader locked for those values to work, to pass?
[Magisk] pndwal:
It'll be failing ctsProfileMatch if it's older than the one paired with your current ROM simply because you need to match Security patch level date value with the print for prints dated after March 2018 as I've been saying... If you can do that it should passed ctsProfileMatch but you'll likely need to go to Android 10 or earlier prints to pass DEVICE_INTEGRITY anyway, and Google may have blacklisted device using earlier prints since the started enforcing HARDWARE_BACKED evaluationType using fingerprint prop...

Fingerprint prop simply must not be used for blacklisting devices by Google... It doesn't necessarily have to be for a device that didn't launch with hardware attestation compliance (ie Keymaster 3+, Android 8+)...

Nb. I haven't played with configurable PIF yet... PW
[Magisk] pndwal:
Oh... I'm not familiar with pass keys for encryption, but I guess you may need to return props to same state when device was encrypted. 🤔

If that was unrooted, unpatched boot.img may work... Could just be changes in modules or ROM if custom... Hope something works... PW
[Magisk] pndwal:
Hh

Did you clear G Pay/Wallet data since DEVICE_INTEGRITY was fixed?... Otherwise cached verdicts should reset but may take days... PW
[Magisk] jurluk:
WIth this pif.prop I have few questions now.

What does this mean? Until now these values where hardcoded and everyone who installed fix had the same fingerprint?

I guess that we should change values to actual values of our device?
[Magisk] Vision:
Oh understand. Thanks for answer and advice, very useful. Can add anyone old fingerprint or need some specific ?
[Magisk] pndwal:
Yup...

You can try, but aim would be to spoof prop values not on Google's list for enforcing HARDWARE BACKED evaluationType; no real need to match your device...

This is really to allow users to set working spoofs in the event that Google blocks current default props...Or you can try to find working combinations in anticipation of a Google block or change... Or not... Your choice. 😜 PW
[Magisk] HRSE:
1. If I want to add persist.adb.notify=0, what should the content of pif.prop be like?

2. Would I need to remove all Zygisk modules if I were to upgrade to PIF v13.1?
[Magisk] sawdoctor:
So the logic behind it is to say to Google " please just leave us alone, if you blacklist/block PIF we can just change it on the fly."
[Magisk] HippoMan:
And they most likely *will* blacklist/block, and we therefore *will* have to change it on the fly.

It'll just be another escalation of the cat-and-mouse game.
[Magisk] xSnowLeopardx:
I'm going to be the guy not updating from a working 13 situation. Will update, of course, if it breaks.
[Magisk] sawdoctor:
But going off what @osm0sis said Google just want us to be more discreet so if we all have the same fingerprint it's kinda obvious, if we start to use different ones individually then Google might leave us alone
[Magisk] Lobod:
Or they will drop the backward compatybility and force us to stop :/
[Magisk] zgfg:
You cannot add your custom props to pif.prop

- However, you can to the service.sh script.

Open the script and you'll see how it redefines various other props, eg:

resetprop ro.boot.flash.locked 1

So add your own like:

resetprop persist.adb.notify 0

- Alternatively, add to the system.prop:

persist.adb.notify=0

But better use service.sh since system.prop spoofs might be applied too early (before the booting completes) and then be overwritten by System when booting will complete

Again, after editing in the module's folder you have to reboot

To be understood:

- pif.prop spoofs target (via Zygisk) only the com.google.android.gms.unstable process (PI API)

- service.sh and system.prop spoofs affect all apps and processes on the phone (if they ask for those props)

And be aware that when you update the module, your changes will be gone - you'll have to modify the file(s) again
[Magisk] Vision:
With Total Commander without root, in the old devices go to root folder after system copy and paste the build.prop. This work for me in my old devices without root
[Magisk] HRSE:
thanks, it works.
[Magisk] HippoMan:
I'm not sure whether or not they actually *want* us to be discreet ... we can only speculate about their actual thoughts and motives.

Nonetheless, being more discreet can only help us. A sudden influx of many connections with the same fingerprint could easily get their attention.
[Magisk] NAKOLS:
Thank you for the pif.prop file, I've tested some fingerprints and I've found an alternative fingerprint that passes device integrity, I hope I'm ok for the moment. Working also on latest Xiaomi.eu ROM rebuild
[Magisk] mac796:
Thanks
[Magisk] tdog0101:
thanks -- I believe I did (as I was repeating procedure done prior to installing PIF v.12). But happy to try again. Question: should I keep PIF v.13.1 on device and then just clear data/caches? Or should I alternately remove PIF v.13.1 first, clear data/caches, and then reinstall v.13.1? -- unsure if one method is better than the other.
[Magisk] osm0sis:
Ah! I'd forgotten that one, good idea! Lots of fingerprints there, though the corresponding security patch dates for the newer ones (after March 2018) would need to be calculated/guessed.

I mean... You're on the right track, maybe look into that? 😁😘

I've been harvesting build.props directly from dumps so far, which has also been fun. 🤠

@chiteroman, you'll have to add some logic (md5 or grep for the fingerprint?) to the module installation script to not overwrite a custom pif.prop if it already exists, so a module update doesn't mistakenly kill people's new unique configs. 🐙
[Magisk] Lobod:
I have tried build.props from my old Xperia XZ1 but it failed :C

I must get my even older Xperia X and XZ compact...
[Magisk] osm0sis:
Until @chiteroman can add SECURITY_PATCH spoofing you should look for a print older than March 2018 to try. If it still doesn't work then it's probably a blocked print already, or you got some part of PRODUCT, DEVICE (should be the same) or FINGERPRINT incorrect.
[Magisk] Ramonry12:
Noob question,this update would be for a possible verification for STRONG_INTEGRITY or is it just in case Google messes something up and possibly breaks DEVICE_INTEGRITY etc?
[Magisk] krkhaha:
My problem was start after update to a14
[Magisk] Vision:
No STRONG_INTEGRITY only if google block one, you change with another in pif.prop and pass again DEVICE_INTEGRITYView attachment 6035131View attachment 6035135
[Magisk] osm0sis:
Dodoodoo... *whistling nonchalantly*
[Magisk] makeyourself:
Unless we have devices that are several years old wouldn't that mean that our devices WOULD indeed all be on Google's list for hardware backed evaluation only? So presumably most of us would need to spoof a different device?

I am still pretty confused about this whole thing. Google APPEARS to have blocked the old fingerprints that were being used by USNF and PIF. If l remember rightly, one of these was some Huawei device and another was an Asus device (can't remember the exact models now). So what happened to people out there who still have these devices and don't even have an unlocked bootloader? Contactless payments are blocked for them?! Yet not for other old devices?! Even though Google would have been able to entirely forsee that if they blocked the Huawei and Asus devices then we would just use the fingerprints of other old devices, in a random way if necessary!? It doesn't seem to quite add up.
[Magisk] chiteroman:
Is it necessary the SECURITY_PATCH ? I didn't know about that.
[Magisk] osm0sis:
After around March 2018 apparently, yeah. I'll PM you some corroborating evidence. 😛

Noted that they use a different function to set it here: https://github.com/Evolution-X/fram...a2b199a20afb1bf354de3307e8fd5885a4f4d9de9L224

setVersionFieldString instead of setPropValue, so you'd just have to add an exception to your pif.prop parsing and set it however it needs in your own function.

Edit: Looks like you've got new PM's disabled, but I sent one to our old conversation which looks like it worked?
[Magisk] zgfg:
Didn't check more about the default bullhead prints but everything is ok with my Aug '23 Security Patch and Oct Google Play System updates (A13)
[Magisk] gigavolthavoc07:
Does my system detects my phone as a Xiaomi 14 If i change the device and model as Xiaomi 14 in pif.prop? I'm using the v13 and it's still working fine but i want to try the v13.1's pif.prop feature
[Magisk] osm0sis:
I think we're talking about something different.

I'm saying if you use any print from after March 2018 to spoof you need to also spoof a security patch date at the same time in order to pass Device Integrity. That's what @pndwal was saying as well, and was noted back in the MHPC module days.

(I know the actual print in that EvoX commit isn't after the time frame, but it's an example of patch spoofing, which was why I referenced it.)
[Magisk] VuYeK:
Noob question: where can I get/generate another fingerprint?
[Magisk] iruiz2:
It only spoofs another phone for the Play Integrity verification, not system wide. So the rest of the system "sees" the correct phone model.
[Magisk] V0latyle:
PLEASE read the OP!

Neat....what is it? Script to set older security patch?
[Magisk] osm0sis:
Takes a ROM dump's build.prop you provide and generates a pif.prop for you. 😉
[Magisk] pndwal:
You can just clear data. PW
[Magisk] pndwal:
For many fingerprint props to work, adjusting Security patch date to match began to be required from March 16 2018 and soon after for others as discussed:

And per:

https://github.com/Magisk-Modules-R...ices-fingerprint-to-pass-the-ctsprofile-check

👍 PW
[Magisk] AsadP2013:
@chiteroman Just wanted to say thanks for your efforts on this module.

It's great to know there are individuals like yourselves out there willingly taking their time out to create some sort of fix/resolution.
[Magisk] chiteroman:
Ok, I will add it.
[Magisk] Vision:
When you add it, for those not use security patch, what write inside in the pif.prop, leave it blank?
[Magisk] chiteroman:
Currently if you pass a blank value it will be set to null, so thanks for indirectly reporting a bug xD.

One more thing to fix. 😂
[Magisk] osm0sis:
Just don't include that line if your fingerprint doesn't need it, like it is now. I sort of wrote my build.prop parsing script in advance of the feature, so it behaves that way too, only adding it if it's certain it's necessary (based on the fingerprint date, though there are builds from June 2018 that still have a 171019 fingerprint date, so it's not a perfect science. 🤷)
[Magisk] Vision:
Yeah exactly, i read the idea of @osm0sis for security patch and i think and for those not have it must be null 😂
[Magisk] Vision:
Understand, so @chiteroman must add it, if not have the line inside in the pif.prop for security patch just ignored, and for other if want it inside detects it
[Magisk] pndwal:
+ @chiteroman

So how do we revert to original device prop easily?... Is that what happens when line is removed?... I'm guessing not ATM

Eg. @Displax was adding space chr to existing model prop value to get required mismatch... I asked if it's still needed for any devices since fingerprint based enforcement was added; he said he'd already tested and it was still required for some devices...

Also, what about props like shipping level (first API)?... It would be good to clarify how we can 1) keep and view default module values, 2) revert to device values and 3) add different/custom values...

Eg. shipping level (first API) should only be altered by module as required; can we have a way to change it if we wish, or use other than default value of 32?)

👍 PW
[Magisk] pndwal:
I think @chiteroman means null is not good; it should always have a date as value, so it's a bug... PW
[Magisk] pndwal:
Great!

Also, can we see clearly the exact prop in label? Eg. "ro.build.version.security_patch"?...

And what is easiest way to check all currently set prop values seen by GMS Droidguard/attestation process?

👍 PW
[Magisk] zgfg:
Logcat?!

11-21 00:06:40.775 30340 30340 D PIF/Java: Loaded 6 properties!

11-21 00:06:40.775 30340 30340 D PIF/Java: [FINGERPRINT]: Xiaomi/lisa/lisa:13/RKQ1.211001.001/V14.0.12.0.TKOCNXM:user/release-keys -> google/bullhead/bullhead:8.0.0/OPR6.170623.013/4283548:user/release-keys

11-21 00:06:40.776 30340 30340 D PIF/Java: [BRAND]: Xiaomi -> Google

11-21 00:06:40.776 30340 30340 D

PIF/Java: [PRODUCT]: lisa -> bullhead

11-21 00:06:40.776 30340 30340 D PIF/Java: [MODEL]: 2109119DG -> Nexus 5X

11-21 00:06:40.776 30340 30340 D PIF/Java: [DEVICE]: lisa -> bullhead

11-21 00:06:40.776 30340 30340 D PIF/Java: [MANUFACTURER]: Xiaomi -> Google
[Magisk] pndwal:
Ta... I just meant for pif.prop file labels though... Edit for clarity... PW
[Magisk] zgfg:
IMHO, logcat replied to your second part:

>>And what is easiest way to check all currently set prop values seen by GMS Droidguard/attestation process?

Logcat shows which six props were spoofed for GMS

Where their exact prop names are likely (for some of them there are duplicates in the props):

PRODUCT=ro.build.product

DEVICE=ro.product.device

MANUFACTURER=ro.product.manufacturer

BRAND=ro.product.brand

MODEL=ro.product.model

FINGERPRINT=ro.build.fingerprint

To be checked in the module source code

And if logcat does not mention spoofing ro.build.version.security_patch, it should IMO mean to be the original as from getprop
[Magisk] pndwal:
Ah yes... Guess no easier way unless an app were designed for purpose...

... That's the other point... Eg there several model props etc.

Would be good to have the definitive labels added in source...

Does it mention spoofing?

... Yup.

Ta, PW 👍
[Magisk] CentraPlex:
I am still having issues using apps that have the API in them after installing the module. Is there any common solutions I should try?
[Magisk] osm0sis:
The thing is it seems that DroidGuard uses the field labels we have in pif.prop, which is why they're like that as it makes the parsing easier in the module code. I'm fine with that part now, we can just document the props to use on here (I scripted the multiple possible /system/build.prop prop names from over the years, and their /product/build.prop fallback prop names, even).
[Magisk] pndwal:
Ah... I shouldn't make assumptions! 😆

Do we know all the labels (for props value measurements) used by Droidguard? Can you say where you see that those are Droidguard labels?... Ta. PW
[Magisk] pndwal:
1) Check you have DEVICE_INTEGRITY (best to use Developer Options in Play Store, Check integrity option) passing.

2) Clear data in bank app...

👍 PW
[Magisk] osm0sis:
I based that notion on that EvoX commit, and reading the PIF module code for how it sends it.

As for what all available field labels are, I've asked if @chiteroman knows back here: https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/page-124#post-89172326
[Magisk] HippoMan:
I'm not asking for any help. I just want to report some things about the Uber rider app ... and to be clear, this is not about the Uber *driver* app, which I know has been discussed a number of times already here in this thread.

I'm running stock A13 on my Nothing 2 device with Magisk Alpha 26401, and now I'm running PIF 13.1 which indeed puts my device into BASIC INTEGRITY and DEVICE INTEGRITY mode.

Around the same time that the Googlefrinchians started "upgrading" their integrity checking recently, I noticed that the Uber rider app began to exhibit on-again/off-again problems. I say "on-again/off-again", because this seems to be timing dependent ... probably due to some kind of race condition. The following occurs maybe 75 percent of the time:

A few seconds after Uber starts and the main screen gets painted, I'd sometimes then get a white screen with a big "OOPS! ..." in the middle, with the following text at the top ...

We're having trouble with your device. You can still request a ride, but certain app features may be unavailable.

I could click the "Back" key to get past this screen, but certain features of the app were then indeed missing.

But interestingly, I figured out how to more or less work around the worst part of this.

I use Tasker, so I wrote a wrapper task around the invocation of the Uber app, as follows:

Launch App: Uber

Wait 1 second

Force Kill App: Uber

Wait 1 second

Clear cache of the Uber App

Launch App: Uber

When I do this, I can get past that "OOPS ..." screen and then use the app normally. But if I go to another app while the Uber app still runs in the background, this "We're having trouble with your device ..." message would again show up when I return to the Uber app and its main screen gets painted -- maybe 75 percent of the time -- and the app would again have the same missing features.

At this point, I could click the "Home" button to put the Uber app in the background, and then I could run that Tasker task, which once again would bring me back to a fully functioning Uber.

Also, I am running the "BootloaderSpoofer" module which seems to get at least some apps to believe that my bootloader is still locked, but that app doesn't help this Uber issue.

I'm sure that I would need STRONG INTEGRITY before Uber would run normally again.

What's interesting to me, however, is that Uber's handling of the lack of STRONG INTEGRITY seems to be dependent upon something that is subject to a race condition, and subject to some sort of info that gets written into the app's cache after its main screen first gets displayed.

And to be clear, I'm sure that this is just a characteristic of the way that the Uber rider app itself has been written.

I'm posting this here in case it might help anyone else who has noticed the same problem with the Uber rider app.

Now that this started happening, I avoid using Uber as much as I can, and I use Lyft whenever possible ... although for a few trips, I need to use Uber. In those cases, I can live with my workaround.
[Magisk] osm0sis:
Turns out PRODUCT field isn't ro.build.product like we thought, it's actually ro.product.name, just that most devices have these as the same thing along with ro.product.device. 😲

I've updated my script accordingly.
[Magisk] Fishawy:
Had the same Uber Rider & UberEats shenanigans when Google started "improving" their thing.

I gave up on cache, so cleared data on both, added them to DenyList, then started fresh. Haven't seen those splash screens since.
[Magisk] zgfg:
There are lot of duplicates - at least on my phone. I was yesterday guessing for a single most like candidate per each label

For my PRODUCT and DEVICE I have::

[ro.boot.hardware.sku]: [lisa]
[ro.boot.product.hardware.sku]: [lisa]
[ro.build.product]: [lisa]
[ro.product.board]: [lisa]
[ro.product.bootimage.device]: [lisa]
[ro.product.device]: [lisa]
[ro.product.name]: [lisa]
[ro.product.odm.device]: [lisa]
[ro.product.odm.name]: [lisa]
[ro.product.product.name]: [lisa]
[ro.product.vendor.device]: [lisa]
[ro.product.vendor.name]: [lisa]

For my MANUFACTURER and BRAND:

[ro.fota.oem]: [Xiaomi]
[ro.product.bootimage.brand]: [Xiaomi]
[ro.product.bootimage.manufacturer]: [Xiaomi]
[ro.product.brand]: [Xiaomi]
[ro.product.manufacturer]: [Xiaomi]
[ro.product.odm.brand]: [Xiaomi]
[ro.product.odm.manufacturer]: [Xiaomi]
[ro.product.product.brand]: [Xiaomi]
[ro.product.vendor.brand]: [Xiaomi]
[ro.product.vendor.manufacturer]: [Xiaomi]

For MODEL:

[ro.product.cert]: [2109119DG]
[ro.product.model]: [2109119DG]
[ro.product.odm.cert]: [2109119DG]
[ro.product.odm.model]: [2109119DG]
[ro.product.vendor.cert]: [2109119DG]
[ro.product.vendor.model]: [2109119DG]

And for FINGERPRINT:

[ro.bootimage.build.fingerprint]: [Xiaomi/lisa/lisa:13/RKQ1.211001.001/V14.0.12.0.TKOCNXM:user/release-keys]
[ro.build.fingerprint]: [Xiaomi/lisa/lisa:13/RKQ1.211001.001/V14.0.12.0.TKOCNXM:user/release-keys]
[ro.odm.build.fingerprint]: [Xiaomi/lisa/lisa:13/RKQ1.211001.001/V14.0.12.0.TKOCNXM:user/release-keys]
[ro.vendor.build.fingerprint]: [Xiaomi/lisa/lisa:13/RKQ1.211001.001/V14.0.12.0.TKOCNXM:user/release-keys]

I searched for by eg:

su

getprop | grep "\[lisa\]"

getprop | grep "\[Xiaomi\]"

etc
[Magisk] pndwal:
Ah, ok...

But I'm not sure about your remark:

For example I mentioned to @Displax way back when print prop enforcement came in, and we'd had module prop enforcement for a while, that my device needed neither, but that I wondered if Google was abandoning model prop enforcement for fingerprint based enforcement in devices where they used enforcement... He said he'd already tested and both were still needed...

I don't know which devices are blacklisted for BASIC-only using model, which using fingerprint, or if any actually require mismatches for both to bypass server end enforcement of HARDWARE-BACKED evaluationType, but we can't assume anything without testing all devices in the wild. 😬 🙃 PW
[Magisk] highdiver_2000:
Revolut app tested without root warning. Youtrip, UOB, POSB, OCBC tested ok

For me, Citibank and Trust app is not working.