yashsingh1/xdaforums huggingface dataset:
[Magisk] zgfg:
Interestingly, my logcat does not complain about SECURITY_PATCH:

:/ # getprop | grep PIF
11-21 08:08:57.963 22968 22968 D PIF/Native: GMS data dir: /data/user/0/com.google.android.gms
11-21 08:08:57.988 22968 22968 D PIF/Native: get system classloader
11-21 08:08:57.988 22968 22968 D PIF/Native: create buffer
11-21 08:08:57.988 22968 22968 D PIF/Native: create class loader
11-21 08:08:57.988 22968 22968 D PIF/Native: load class
11-21 08:08:57.988 22968 22968 D PIF/Native: call init
11-21 08:08:57.989 22968 22968 D PIF/Java: Loaded 6 properties!
11-21 08:08:57.990 22968 22968 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 08:08:57.990 22968 22968 D PIF/Java: [BRAND]: Xiaomi -> Google
11-21 08:08:57.990 22968 22968 D PIF/Java: [PRODUCT]: lisa -> bullhead
11-21 08:08:57.990 22968 22968 D PIF/Java: [MODEL]: 2109119DG -> Nexus 5X
11-21 08:08:57.990 22968 22968 D PIF/Java: [DEVICE]: lisa -> bullhead
11-21 08:08:57.990 22968 22968 D PIF/Java: [MANUFACTURER]: Xiaomi -> Google
11-21 08:08:57.990 22968 22968 D PIF/Java: Spoof KeyStoreSpi and Provider done!
11-21 08:08:57.990 22968 22968 D PIF/Native: Injected 6580 bytes to the process
11-21 08:08:59.224 22968 22982 D PIF/Java: DroidGuard detected!

Btw, I have

:/ # getprop | grep security_patch
[ro.build.version.security_patch]: [2023-08-01]
[ro.vendor.build.security_patch]: [2023-08-01]
[Magisk] osm0sis:
But do you have, e.g. SECURITY_PATCH=2018-03-05 in your pif.prop? The (currently) unsupported field name is what triggers the errors.
[Magisk] zgfg:
No, my pif.prop is original, from the zip I upgraded to v13.1:

PRODUCT=bullhead
DEVICE=bullhead
MANUFACTURER=Google
BRAND=Google
MODEL=Nexus 5X
FINGERPRINT=google/bullhead/bullhead:8.0.0/OPR6.170623.013/4283548:user/release-keys
[Magisk] osm0sis:
Exactly, that print of course doesn't require a security patch anyway. 👍
[Magisk] zgfg:
Also on my other A12 Xiaomi.eu, however with the older

:/ # getprop | grep security_patch
[ro.build.version.security_patch]: [2021-10-01]
[ro.vendor.build.security_patch]: [2021-10-01]

So, did you put yourself

SECURITY_PATCH=

to the pif.prop
[Magisk] jurluk:
Ok, thanks.

Does andbody (besides chiteroman ofcourse :)) know what device was used in v13 release? The same as in v13.1 pif.prop (Nexus 5X), or some other?

I'm asking because of this below said:

For me Play Store dev Integrity check shows Model: SM-S901B, which is actually the same as my actual device (Galaxy S22, relatively new device). Or is it just "showing" that info, but request payload actually has spoofed values?
[Magisk] Vision:
Oh 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. If have it already must delete if not need security patch
[Magisk] osm0sis:
Well yeah, I was testing whether it would work since I knew some prints required one, and knew that's what it was called in the EvoX commit, but discovered it's not a supported feature yet here, hence my requesting it.

Without it we're limited to only using prints from before March 2018.
[Magisk] xcl1pse:
On official chiteroman, yes still use Nexus 5X.

This module uses Zygisk to inject code into some Play Services process and register as Nexus 5X that overrides the real one (Samsung S22). When Play Services attempts to use key attestation, it throws an exception and pretends that the device is Nexus 5X. Since fp in use Nexus 5X can't have STRONG_INTEGRITY causes Play Integrity to think that device request key attestation is Nexus 5X and from the server side sending answer that your devices is Nexus 5X and pass Basic and Device requirements, even your real device is S22. As a result, other attestation-based features, like Wallet and banking apps continue to work. The one shows in Play Store is real props from your build.prop, where this module only replace on play store process when request key attestation.

But from my side, I'm not using Nexus 5X. I'm using other props that still pass 2/3 test tho 😏
[Magisk] NAKOLS:
Exactly, I wanted to warn you about that, the fingerprint I'm using has ro.product.name different from ro.build.product, and using ro.product.name works as expected
[Magisk] Vision:
Deleted
[Magisk] shoey63:
Plenty of fingerprints to test <redacted>
[Magisk] pndwal:
As I said, there should be a way to use 1) PIF defaults, 2) device values and 3) custom values for all props...

Currently we need to find our device values and manually enter them if want no change because a blank field gives 'null' value (and if we wanted that we could enter it ourselves)...

In case of Security patch level, @chiteroman just realised that he can't enter a default value in the field because if users want to use default (old, pre March 2018) print (or if for devices not requiring fingerprint mismatch users want to use device print) the value should be left as device value which varies... Ie. the PIF default should be the device value in this case... Leaving blank is the obvious option, but won't work ATM...

This is particularly an issue for Security patch prop, but showed up the general bug he mentioned, ie that blank value = 'null' is a wasted option really; It could be used to disable PIF targeted changes to each prop (ie. use device value) which would be useful (solve the problem) for Security patch level prop, but also useful for other props too...

In short, you showed up a 'bug' that prevents simply adding the Security patch level prop field; A rework of how this functions is needed first...

Hope it's more clear. 🙂 PW
[Magisk] osm0sis:
I was, uh, trying to avoid pointing to that directly in this thread, since there may be someone from Google watching who might also find the list very handy for their work.... 😛
[Magisk] shoey63:
Well change your quote then😉
[Magisk] Vision:
Yeah exactly, thanks for answer and clarified
[Magisk] osm0sis:
Already had by the time you replied 😘
[Magisk] emontes:
Greetings!

Just wondering what I am doing wrong, if anything. Got a Pixel 7 Pro, installed 13.1 with default pif.prop but I can't see the device passing device integrity, I did run the steps to clear storage on gms, wallet, etc.

Wallet works fine, though (for now).

Anything I missed? :)

Thanks!
[Magisk] jurluk:
For some of them my device actually has slightly different names, .system is included, (far right):

PRODUCT=ro.build.product

DEVICE=ro.product.device <<= ro.product.system.device

MANUFACTURER=ro.product.manufacturer <<= ro.product.system.manufacturer

BRAND=ro.product.brand <<= ro.product.system.brand

MODEL=ro.product.model <<= ro.product.system.model

FINGERPRINT=ro.build.fingerprint

How so?

Ok, makes sense. Although there is slight missmatch in what Play Store is showing and what is actually in my original build.prop. The same values are removed, only different are shown:

Build fingerprint:

build.prop: <redacted>/r0sxeea/r0s:13/<redacted>

Play Store: <redacted>/r0sxxx/essi:13/<redacted>

Device:

build.prop: r0s

Play Store: essi

Why is that so?
[Magisk] HippoMan:
Thank you very much!!

I recently switched to Magisk Alpha and wasn't properly using DenyList. Now that I have set up DenyList correctly, put Uber into DenyList, and cleared data for that app, the problem has now indeed disappeared.
[Magisk] xcl1pse:
I also have S22 but it show r0s instead essi. Does your S22 is qcom devices? coz mine is exynos one
[Magisk] jurluk:
Mine is also exynos 🤷‍♂️
[Magisk] zgfg:
Kj

See post #2561 about duplicates (and variations)

Also, PIF module reads from the pif.prop file and uses/sends to G with the label names (eg PRODUCT), not with their full prop names
[Magisk] 에어 론 리:
it's just ONE from MANY cases of Google Certification issues, denying normal work of apps
[Magisk] ma2006rw:
Bro i hope make new update of play integrity fix for android 10+ because i flash the latest module and can't pass meets strong integrity
[Magisk] immortalwon:
Not going to happen anytime soon again. This module was like telling the police officer how to break into the bank and now they finally fixed the secret entrance
[Magisk] Arcline:
I bet Google devs are actively checking out this forum and fixing exploits like these. The only way to have a long-term solution to strong integrity is if someone keeps the exploit a secret and use it for himself. Oh well.
[Magisk] immortalwon:
100% or creates a private community with paid access.
[Magisk] pndwal:
Why do you think strongIntegrity is used?... I have only basicIntegrity and deviceIntegrity, but:

View attachment 5965247 🙃 PW
[Magisk] immortalwon:
As we move toward Google and the National spying agencies NEW WORLD ORDER of a digital totalitarian regime, strong integrity will be enforced if you want to use google apps and high security bank apps, all in the name for "security". It almost seems like a pre-determined simulation like the matrix or Brave New World, a dystopian novel by English author Aldous Huxley,
[Magisk] westruk:
Try "impression" tab
[Magisk] zgfg:
Btw, I tried to play with the older DroidGuard versions. Folder:

/data/data/com.google.android.gms/app_dg_cache/

contains subfolders with a number of versions of DroidGuard (they don't delete when new one is installed), ie "the.apk" applications

Subfolder names correspond to the SHA1 hashes of their the.apk files

I deleted all subfolders newer than Jul 21 (and later deleted all except the one from Jul 21, eventually deleted also the whole folder to test) - btw, I found three or four versions from Jul 27 and Jul 28 when they fixed the Strong Integrity glitch

Then I ran PI API Checker (Basic and Device Ok, Strong NOk), and it recreated the subfolder with the latest DroidGuard version:

1F4F438C33E9E11CCA0C19FD15F4093C2B3CCC0B

I deleted then the subfolder again and changed chmod from 771 to 551 (only read.and execute, write not permitted) for the whole folder:

app_dg_cache

Then API Checker couldn't install the latest DroidGuard and gave all three red, JSon saying it was Unavaluated

I gave it again permissions to write, so it recreated the subfolder with the latest DroidGuard.

Then I mounted an older subfolder (with its older DroidGuard the.apk version) over the latest subfolder 1F4F438C33E9E11CCA0C19FD15F4093C2B3CCC0B

and ran again PI Checker, but all three were red again with JSon saying Unavaluated (as practically expected since mounted the.apk DroidGuard had a different hash from the mounted subfolder name)

---

Similarly, the folder

data/data/com.android.vending/app_dg_cache/

contains subfolders with the DroidGuard versions as installed when you test PI API from Playstore/Settings/General/About/Developer options

----

And thesame with folders

/data/user/999/com.google.android.gms/app_dg_cache/

and

data/user/999/com.android.vending/app_dg_cache/

They correspond to the user 999 (Second or Work space, Dual apps) - while /data/data = /data/user/0 serves to the 'standard' user 0

---

Hence no chance to submit the older DruidGuard version from the last week when Strong Integrity was successfully spoofed

But again, I doubt how many apps really require Strong Integrity.

Actually, during the last week when Strong Integrity spoof worked for us - how many really found the more 'banking" apps working than before and now without Strong Integrity, on their same phones?

The apps usually detect something else, but ppl wrongly think it's about Strong Integrity since the apps of course work on the phones that were not modded (Bootloader locked, Stock certified ROM, no SELinux Permissive, no Zygisk, no XPrivacyLua, no Magisk app, etc) - of course those phones coincidentally also pass Strong Integrity but the 'banking' apps can exploit other ways to find the mentioned mods

Btw, Momo founds the mods without using and depending on SafelyNet/Play Integrity.

And Momo did not work any better with the Strong Integrity spoof
[Magisk] pndwal:
Yup, that gives the 'certification security' error... Good to know...

Not convinced it's polling strongIntegrity however... Would be interesting to know if it can work on a stock (!ocked) Android 7 launch version or older device... PW
[Magisk] Arcline:
I wonder what needs to be secure in photo editing apps. That's why I'm only using Foss apps now.
[Magisk] zgfg:
Impression speaks about certification

Do you pass Device is certified and Play Protect in Playstore?

They dont require Strong Integrity but even if passing Basic and Device, Playstore may show Not certified - then it's necessary to delete Data for Playstore and give it a time to certify

EDIT: I see now it's an app from Face Technology LTD, not from Google Inc, hence I don't understand how Google devs are 'guilty' for that
[Magisk] zgfg:
Sorry but typical misconception about Strong Integrity (and Google's 'guilt')

My phone of course fails Strong Integrity (Bootloader unlocked, custom ROM, Magysk with Zygisk, LSPosed modules) but I just installed your app, put it to DenyList and HMA (and to Bootloader Spoofer but probably unnecessary), rebooted and opened the FaceApp with no problem
[Magisk] westruk:
Try "impression" tab in app. My devicenpassing Basic and Device, Playstore show Certified
[Magisk] zgfg:
I don't plan to buy subscription and without it doesn't let me further - this is actually more annoying for me that some anonymous trial is not allowed

Anyway, Google provides the framework for PI API, how particular app owners (not developers) choose or not to use it it's their business

Google apps themselves do not require Strong Integrity. Notable example is Wallet (most critical app for the secure environment)
[Magisk] ipdev:
The "X" in the upper left corner of that screen will let you continue to use the "Free" version of the app.

Cheers. :cowboy:
[Magisk] Spartacus500:
Same for me... Strong integrity ❌
[Magisk] zgfg:
Ok, so I choose free version and it let me to edit the 'selfie' it found on the phone
[Magisk] westruk:
Try to use some filters for some photos in "impression" tab
[Magisk] HippoMan:
OOPS! I spoke too soon. I went back to the Uber app, and most of the problem returned. I don't see their own "OOPS" splash screen any more, but now I'm still getting their message about fewer features, and the features are indeed abbreviated after that message shows up.

Oh well (sigh) ...
[Magisk] xcl1pse:
Classic Samsung 😂 on my props, it does show essi (custom vendor for exynos) but fp is r0s
[Magisk] Pheggas:
I just updated to latest 13.1 and it was enough to wipe cache on wallet and Google play and reboot again.
[Magisk] jurluk:
Ok. I was saying that more because of gen_pif_prop.sh script, because in this case it won't work correctly, right?

Did you try hiding magisk app? And after that again clear app data..

Because some apps look for other apps with specific names, and if they find "magisk" they assume device is rooted and disable app usage.

🤦‍♂️😅
[Magisk] Vision:
My old device have this in build.prop

View attachment 6035375View attachment 6035376
[Magisk] Paz9:
im new to this PIF/FP spoofing

but why cant we use our own device props in the pif.prop file? is our fp/device listed as unlocked once its setup?

and how does google know / revert once we lock the bootloader again?
[Magisk] Yeedatoy:
Any insight on what this may be? I'm looking at flags in wallet.
[Magisk] Vision:
What is this? I read it in a forum

View attachment 6035381View attachment 6035382
[Magisk] chiteroman:
New update! v13.2

By popular request I have added support for modifying the "SECURITY_PATCH" field, and fixed a bug when modifying fields.

I have also created a Telegram group so we can share our knowledge and be aware if Google blocks the current fingerprint:

Play Integrity Fix

https://www.paypal.com/paypalme/chiteroman	https://github.com/chiteroman/PlayIntegrityFix	https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/

t.me

You can check the latest build here:

Release v16.5 · chiteroman/PlayIntegrityFix

Update hook framework: Dobby Fix Device not passing in few devices Improve code Reduce Zygisk libs size

github.com
[Magisk] chiteroman:
That's a nasty code I did some time ago to implement at the system level (a very crazy user did it at the kernel level) to spoof a locked bootloader.

There are better ways to do it, of course.
[Magisk] HippoMan:
Yes, Magisk app has been hidden ever since it was installed, and the Magisk app was already hidden when I cleared cache and data today and reinitialized the Uber app.

It looks like the Uber developers are doing the same kind of extra root/modding checking that many banks are doing.

I'm not going to make my Android use even more painful than it already is by temporarily freezing other apps just to be able to use Uber without their nonsense.

And because of this nonsense, Uber will now lose a lot of business that they previously got from me, but I'm sure they don't care.
[Magisk] Vision:
Oh understand, thanks for answer. Better ways to do it theoretically or practically ?
[Magisk] chiteroman:
Practically. But you must decompile framework.jar of the ROM and implement Pine.
[Magisk] Vision:
Very useful, but i don't think i have the knowledge about that 😂
[Magisk] chiteroman:
Uhhh, in modern devices like latest Google Pixel seems to be not working the modules with custom props.
[Magisk] Flr Power:
Don't give up 🙏 I am sure you will find a way
[Magisk] Vision:
Sounds silly, but maybe Google have another check for these, because not only is android but is Google phone, this is important for Google
[Magisk] awarexda:
The last posts are really a pain to understand, all these pif.prop etc tuning is something that would be better if we had some sort of manual on how to do the necessary steps.

In any case, many thanks to all for the lifesavers....
[Magisk] sawdoctor:
Can confirm on pixel fold running 13.1
[Magisk] Vision:
GitHub - chiteroman/PlayIntegrityFix: Fix Play Integrity (and SafetyNet) verdicts.

Fix Play Integrity (and SafetyNet) verdicts. Contribute to chiteroman/PlayIntegrityFix development by creating an account on GitHub.

github.com

View attachment 6035431
[Magisk] awarexda:
Thanks for the reply. I just noticed 13.2 is out there, should I patch it if everything seems working? I am afraid!....
[Magisk] Vision:
This add it in the v13.2, if you need security patch View attachment 6035432
[Magisk] pndwal:
Yeah, not just for you... shown values are not those sent with attestation data... Your quoted post is correct, these are showing globally set values.

... Zachary...

👍

Good start!... But not quite right...

The exception causes on device fallback to BASIC-only attestation measurements for sending to the PI or S/N APIs... This has been needed for all devices with working Keymaster 3+ because where working, HARDWARE_BACKED attestation is used/sent to servers by default...

However Google later started enforcing HARDWARE_BACKED evaluationType verdicts (ie. blacklisting devices for BASIC-only attestation) at the server end by means of prop identifiers for some (NOT all) devices with working Keymaster 3+...

First was model prop, and while any value Google didn't include in blacklist would bypass the enforcement (eg "cream cheese") would work, we ended up getting just a space chr appended to original model prop value to create the required mismatch (with Google's list of props) in USNF.

Second, Google (more recently) began using fingerprint props, so mismatched prints were also needed for many (generally those with A11+ stock ROMs) devices... Nb. Only a mismatch with Google's listed props (for enforcement) is needed; nothing to do with 'f(inger)p(rint) in use can't have STRONG_INTEGRITY' triggering an enforcement bypasses... Actually many Android 8, 9 and 10 prints (ie. for Keymaster 3+ devices) will work which is why we now have Security patch level prop field in latest PIF pif.prop added; a date matching fingerprint selected must be added here if you want to discover working fingerprints dated after March 2018 or CTS/VTS certification requirements are not met and DEVICE_INTEGRITY will fail.

Third (and last) we have Shipping level (first API) based enforcement for all devices launched with A13+ (API level 33)... Generally, a setting of 32 is used for those devices to bypass HARDWARE_BACKED evaluationType enforcement.

Well not Play Store process... Google Play Services (GMS), specifically the Droidguard/attestation process, com.google.android.gms.unstable... Clearly the Play Integrity check inbuilt in Play Store is sourcing globally set props for displayed fingerprint etc, but the attestations themselves derive from those this module sets to target GMS Droidguard/attestation process...

You are correct that since USNF 2.4.0 part time spoofing is implemented; the changed values only occur at runtime (ie when a call for a PI verdict is made).

👍 PW
[Magisk] xcl1pse:
I basically simplified what I already simplified lol
[Magisk] V0latyle:
Just to be clear, the only changes to 13.1 and 13.2 are the custom prop fixes? Not necessary if we are on stock ROM and already passing 2/3?
[Magisk] pndwal:
Leave Security patch empty/untouched?... Why set 2018-01-01 with bullhead?...

Or was that broken in 13.1 also?

🤔 PW
[Magisk] Vision:
This add it in the v13.2, if you need security patchView attachment 6035441
[Magisk] xcl1pse:
Nothin' to see here...
[Magisk] Vision:
What? I'm confused now, because the security patch is supposed need it for some device need it but still pass 2/3, you pass and 3?
[Magisk] pndwal:
Wow... Say settings then delete quick!... 👍 😜

... What checker?

PW
[Magisk] Vision:
Yeah exactly. I'm confused now, because the security patch is supposed need it for some device need it but still pass 2/3
[Magisk] chiteroman:
No way 😂
[Magisk] Vision:
Yeah exactly. I'm confused now, because the security patch is supposed need it for some device need it but still pass 2/3. How pass and 3 ?
[Magisk] chiteroman:
Maybe he found another fingerprint with Strong pass.
[Magisk] V0latyle:
Or....Just PM each other lol

Hey there's a thought. Use PM threads for everyone who wants to see this stuff without public visibility. Generally we like to discourage such things in the interest of the greater good, but until (if ever) we reach the point where we can defeat PI in such a way that it cannot be patched, it's probably best we don't publicly discuss the "how" because the Internet has eyes and ears

I'm still not clear on the purpose of the security patch?
[Magisk] Vision:
Is that possible, because have ask you, if you found a fingerprint with broken TEE and put it it pass and 3? and you say is in the device not only in fingerprint something like thatView attachment 6035462
[Magisk] chiteroman:
Few fingerprints need it to spoof a valid Device verdict, by the moment isn't necessary.
[Magisk] chiteroman:
View attachment 6035461

Trying new things 👀👀👀👀
[Magisk] chiteroman:
Yes, that is the theory. It's another thing to put it into practice. 😂
[Magisk] pndwal:
Just changed my mind about modern Samsung device security anyway...

This:

👀 PW
[Magisk] maxmax0:
Great question, and since the answers have been of very limited value so far, I would like to follow up on this:

13.1, stock A14, Pixel 8 Pro, everything working at the moment, passing 2/3. Do I need to update to preempt a Google "fix" that is incoming, or can I stay on 13.1 safely for now?
[Magisk] Vision:
This add it in the v13.2, if you need security patch

View attachment 6035466
[Magisk] maxmax0:
Yes, this has been posted before, and of course I read the changelog. But this does not answer the question.
[Magisk] Vision:
Maybe this

View attachment 6035471
[Magisk] pndwal:
... Actually, maybe this:

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

? PW
[Magisk] FIERA03:
This post is for KernelSU users, and ZygiskNext 0.8.1 often causes a forced stop on reboot(& 2/3 can't pass) that can only be fixed by reinstalling.

A modified build by 5ec1cff would fix this problem.

https://github.com/5ec1cff/ZygiskNext/suites/18119452689/artifacts/1044552394
[Magisk] V0latyle:
So...if you're already passing DEVICE, there's no reason to use custom PIF?
[Magisk] Vision:
Yeah i think for now, and when google block that fingerprint then use the custom pif.prop to edit another fingerprint to pass again