yashsingh1/xdaforums huggingface dataset:
[Magisk] osm0sis:
Maybe Fold really wanted a working SECURITY_PATCH? 🤷‍♂️
[Magisk] osm0sis:
@chiteroman Omitting API_LEVEL from pif.prop seems to cause a Device Integrity fail on an API 30 device (triggers Hardware backed), so I think the fallback to regular existing prop is broken for that field at least.
[Magisk] pndwal:
Yeah, current device but with capped value of 32...

Yeah, well 26 is Android 8.0... this is where hardware key black attestation kicked in since Google mandated Keymaster 3 as the minimum spec.

That's interesting! (It won't be 'forcing BASIC' though, just not enforcing HARDWARE BACKED, or not blacklisting device for BASIC-only evaluationType verdicts with that prop value 😉)... So that may have worked instead of using mismatched model!... Bit late now however...

... Different props checked for enforcement of HARDWARE_BACKED evaluationType in PI API... @chiteroman said it breaks PI device_Integrity in combination with some prints... So even if @kdrag0n had used API_LEVEL to bypass enforcement of HARDWARE_BACKED evaluationType in S/N, when PI emerged model prop based bypass would have been better since it allows S/N pass without breaking PI...

🤠 PW
[Magisk] pndwal:
👍

By 'higher' do you mean eg 31 or 32 enforces HARDWARE_BACKED evaluationType?... Interesting!

My understanding is that device is always sending BASIC-only attestations if USNF core function is running, ie the fallback to Basic-only has occurred since fake keystore registration triggers exception that causes this... (It's not a prop based fallback of course.)

... If we're talking about 'forcing a basic' attestation (really BASIC-only evaluationType at server end), a low API_LEVEL doesn't 'force' this either...

Actually, HARDWARE_BACKED is what gets enforced and it simply isn't enforced in S/N API since props it checks, including such 'lower API numbers' don't trigger this and so ctsProfileMatch can pass. However, HARDWARE_BACKED is enforced in PI API since it checks different (additional) props including the 'lower API numbers' in API_LEVEL which trigger enforcement of HARDWARE_BACKED evaluationType, so DEVICE_INTEGRITY is disallowed and can't be 'met'...

... Anyway, it's interesting if both 33+ (known) and 'low numbers' (how low?) are causing HARDWARE_BACKED evaluationType enforcement in PI API where combined with certain prints. 👍

I appreciate the insight! 🙂 PW
[Magisk] pndwal:
😲

Works if just set to 30 in field?... PW
[Magisk] pndwal:
Needs API_LEVEL changed to 32 or lower since your device sets 33... Maybe test build wasn't doing that?... PW
[Magisk] pndwal:
Props for spoofing PI DEVICE_INTEGRITY incl API_LEVEL target GMS Droidguard/attestation process only... PW
[Magisk] osm0sis:
Yep, exactly. I'm wondering if there's some bug in the code which sets it to empty, 0 or Infinity instead of allowing fallback to the regular existing prop, causing @chiteroman's aforementioned high/low Hardware backed eval behavior.

Edit: 0 and 1 are actually fine weirdly, but "API_LEVEL= " (a space) and > 32 triggers hardware backed eval and fails. "API_LEVEL=poop" also amusingly worked fine, so I assume the invalid text triggers a proper fallback. 😄
[Magisk] yukkio:
Hi, I'm looking for the values for the pif.prop in case i have problems in the future with gpay. I found this for the poco x3 pro, it should pass with those values?

# begin sku build properties

# autogenerated by build/make/tools/buildinfo_sku.sh

ro.vendor.build.fingerprint=POCO/vayu_eea/vayu:11/RKQ1.200826.002/V12.5.1.0.RJUEUXM:user/release-keys

ro.product.vendor.brand=POCO

ro.product.vendor.device=vayu

ro.product.vendor.model=M2102J20SG

ro.product.vendor.name=vayu_eea

ro.product.vendor.marketname=POCO X3 Pro

# end sku build properties

ro.product.board=vayu

ro.bootimage.build.fingerprint=POCO/vayu_eea/vayu:11/RKQ1.200826.002/V12.5.1.0.RJUEUXM:user/release-keys
[Magisk] Vision:
@chiteroman a irrelevant question because you have Xiaomi Poco X3 Pro, i have Xiaomi Poco X3 NFC, my build.prop is right? Why say qti instead of POCO and qssi instead of surya_eea ? 🤔

View attachment 6035820
[Magisk] osm0sis:
Check your /product/build.prop instead. Might be like Google's generic /system/build.prop values on more recent devices.

Edit: Oh wow, I just looked at a few recent MIUI fingerprints and they are indeed a mess: qssi, missi, qti, miproduct, and conflicting fingerprints in system, product and vendor... 😬
[Magisk] Vision:
The same and the diffrend with other users, mine say "begin common build properties and other users begin sku build properties" i download my rom from here: https://xiaomifirmwareupdater.com/miui/ say is the official. The only aswner is this why say this to me

So the aswner is right and have the original?

View attachment 6035829View attachment 6035830
[Magisk] osm0sis:
Yeah your other ones look like a GSI to me, makes sense.
[Magisk] Vision:
Thanks for answer. Good to know, at least is original, only this i found here: https://xiaomifirmwareupdater.com/miui/surya/stable/V12.0.8.0.QJGEUXM/
[Magisk] awarexda:
Yesterday I flashed the 13.3 pre-release and for the first time ever I saw "meets requirements" in wallet. In the past, I could ONLY see Basic AND Device pass (as well as certified in Play Store).

Today, I decided to flash latest 13.3 - well after this I again got "doesn't meet requirements" in wallet. Still I could see Basic AND Device pass (as well as certified in Play Store).

Then I decided to re-flash the 13.3 pre-release but the "doesn't meet requirements" didn't go away...

What is wrong? (thanks in advance!)....
[Magisk] zgfg:
Did you try to put it to pif.prop and test does it work?

That would be the answer

However, look into the prop.pif and it's not fully clear how to fill the values with your sku - eg,nlike this or how?

PRODUCT=vayu_eea
DEVICE=vayu
MANUFACTURER=Xiaomi
BRAND=Xiaomi
MODEL=M2102J20SG
FINGERPRINT=POCO/vayu_eea/vayu:11/RKQ1.200826.002/V12.5.1.0.RJUEUXM:user/release-keys
SECURITY_PATCH=????-??-??
API_LEVEL=30

Maybe PRODUCT should be also vayu, should you set BRAND as Xiaomi or Poco or vayu

And you are definitely missing your SECURITY_PATCH

So install the module (if rooted) and run the logcat and find the PIF logs like:

11-22 17:13:37.000 25404 25404 D PIF/Java: [DEVICE]: lisa -> RMX1931L1
11-22 17:13:37.000 25404 25404 D PIF/Java: [MANUFACTURER]: Xiaomi -> Realme
11-22 17:13:37.000 25404 25404 D PIF/Java: [BRAND]: Xiaomi -> Realme
11-22 17:13:37.000 25404 25404 D PIF/Java: [MODEL]: 2109119DG -> RMX1931
11-22 17:13:37.001 25404 25404 D PIF/Java: [FINGERPRINT]: Xiaomi/lisa/lisa:13/RKQ1.211001.001/V14.0.12.0.TKOCNXM:user/release-keys -> realme/RMX1931EEA/RMX1931L1:10/QKQ1.191021.002/1590460856:user/release-keys
11-22 17:13:37.001 25404 25404 D PIF/Java: [SECURITY_PATCH]: 2023-08-01 -> 2020-06-05

From that you will see what should you put. Eg,

[SECURITY_PATCH]: 2023-08-01 -> 2020-06-05

means that my original SECURITY_PATCH (corresponding to my ROM) is 2023-08-01

From your log you will see what is yours and what you have to put for the corresponding SECURITY_PATCH

Similarly for the other labels

Alternatively, use

getprop | grep security_patch
getprop | grep fingerprint

to find your SECURITY_PATCH, FINGERPRINT, etc

Grep the other values from their prop names:

PRODUCT=ro.product.name
DEVICE=ro.product.device
MANUFACTURER=ro.product.manufacturer
BRAND=ro.product.brand
MODEL=ro.product.model
FINGERPRINT=ro.build.fingerprint
SECURITY_PATCH=ro.build.version.security_patch

For API_LEVEL try with 30 or 29

Then test and you will know

You can edit pif.prop directly in

/data/adb/modules/playintegrityfix

You don't need to restart, just execute:

killall com.google.android.gms.unstable && logcat -c && logcat | grep PIF > /sdcard/Download/PIF-logcat.log

Then do PI.API test, stop the logcat by CTRL C and read your log in Download folder, PIF-logcat.log file
[Magisk] osm0sis:
@chiteroman, replace the attached zipped 2 files in your module zip, then we all start naming our custom files custom.pif.prop, then the module update overwrite issue is fixed. 🐙🙌

I've already updated my build.prop to pif.prop generating script accordingly. 🤠

[ Attachment removed as it was added to v13.4 ]
[Magisk] c3k:
This module is not masking model prior to v13, right?

So if everything is working for my device is better to stay 12.3 to keep the things as simple as possible?
[Magisk] xSnowLeopardx:
I am on V13 because something before did not work anymore. So that's what I do: stay on something until it doesn't work, instead of updating immediately.
[Magisk] nadeemakhtar1994:
Tata Neu app suddenly stopped working and showing environment not safe. So its detecting root and can't bypass
[Magisk] Flr Power:
Did you try it in magisk Deny list?
[Magisk] Vision:
If anyone found a fingerprint and pass strong don't write it in public here, only in private message "The Watcher" he's watching us 👀
[Magisk] forum_dyskusyjne:
Hello there,

I have Mi 9 lite and problem with Magisk 26.X which not work on this model.

PlayIntegrity in version 13.2 not support Magisk 25.2 which work on this model.

Is it possible to keep next "PI" compatible with Magisk 25.2... Thanks.

V 13.1 works perfectly :-)
[Magisk] Vision:
Work with Magisk Delta v25.2 (25210 canary) try the 13.3 version
[Magisk] osm0sis:
Hmmm, probably shouldn't go back to including values in the source again... Feels like a step backwards from only having it in the pif.prop inside the module. 😲😕😛

Improve code · chiteroman/PlayIntegrityFix@78dde20

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

github.com
[Magisk] sawdoctor:
That is probably why Displax stopped updating his safety net too. Soon as he released one that passed strong Google blocked it. So if he had another he wasn't going to publish it
[Magisk] chiteroman:
v13.4 released!

Release v13.4 · chiteroman/PlayIntegrityFix

Custom resetprop utility! Thanks to @HuskyDG. Don't write in GMS folder, everything stored in memory. (Issue from @osm0sis :D) Downgrade to Zygisk API 2. Should fix crashes. This build includes 'p...

github.com

Thanks to @huskydg and @osm0sis for new things 🤗
[Magisk] osm0sis:
😍

You should mention in the release notes that it's called custom.pif.prop now for adding a custom one, and people just put that into the module folder once installed then reboot. 🎉🙌

Edit: And that API_LEVEL is renamed FIRST_API_LEVEL now. Updating my script now! 🤘

Edit 2: Also, sh*t, this fix (added line) is needed in customize.sh, my bad. 🤦‍♂️

if [ -f /data/adb/modules/playintegrityfix/custom.pif.prop ]; then
ui_print "- Restoring custom.pif.prop -> pif.prop"
cp -af /data/adb/modules/playintegrityfix/custom.pif.prop $MODPATH/pif.prop
cp -af /data/adb/modules/playintegrityfix/custom.pif.prop $MODPATH/custom.pif.prop
fi

Now it'll retain the custom.pif.prop at the original name too.
[Magisk] krkhaha:
V13 works for me really nice so I didn't update it.
[Magisk] crypt4dark0:
What should be the process to get a custom prop? extracting from official firmware?
[Magisk] wyt18:
I'm now getting a SE linux flag Enabled failure on v13.4. How do I fix this?

Also, is TBchecker still the best app to check PI and root hide status? Noticed a lot more ads recently
[Magisk] badabing2003:
For the interested, PixelFlasher's latest release (see in my sig) can Install / Update The module, and GUI edit pif.prop from your PC.
[Magisk] Nergal di Cuthah:
I might just switch from google's flasher over gui pif
[Magisk] osm0sis:
Something malfunctioning/missing with the updated resetprop/service.sh perhaps. CC: @chiteroman

Edit: Yep, this is missing now:

# Hiding SELinux | Permissive status
resetprop --delete ro.build.selinux

# Hiding SELinux | Use toybox to protect *stat* access time reading
if [[ "$(toybox cat /sys/fs/selinux/enforce)" == "0" ]]; then
chmod 640 /sys/fs/selinux/enforce
chmod 440 /sys/fs/selinux/policy
fi

@wyt18 You can try the service.sh + system.prop from 13.3 (which are the final versions of those from Displax's MOD) instead to see if it fixes that for you.

v13.4 causes fails x3 on my Nexus 7 2013, but reverting those 2 files got it passing with my custom prop again.

Edit 2: Omitting FIRST_API_LEVEL is also still bugged and triggers HARDWARE_BACKED eval fails on devices where it shouldn't (first_api < 33).

Original report here:

🔧 [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

These are the only issues I see now though, so we're getting close to solid! 🤞🤠
[Magisk] osm0sis:
For those struggling with the regressions right now, but still want to enjoy the new update. 👍

- reverted to v13.3 service.sh + system.prop until I can regression test them

- fixed custom.pif.prop restore to custom.pif.prop on update

- clean up gms data/cache pif.prop copies during update before Google notices now that that issue is fixed 🥳

Edit: Reupload with the cleanup script added to customize.sh
[Magisk] fbirraque:
Works flawlessly on Poco F3 (Alioth) with MIUI.EU 14.0.8.0 (rebuild v2), Magisk 26.4 (26401), Play Integrity Fix 13.4
[Magisk] mac796:
This works good for me. p8p.

Thanks
[Magisk] huskydg:
Still the issue with banking apps:

[Wontfix] Solution to bypass property modified detection of some banking apps · Issue #79 · chiteroman/PlayIntegrityFix

More and more apps detect property modified which is caused by Magisk resetprop. Not many banking apps need to pass Play Integrity. We want to use these apps and also GPay (or any other apps that r...

github.com
[Magisk] MonteXMat:
Awesome, thanks for this!

Kept failing on v13.4.
[Magisk] ZdenekReich:
Worked with Xiaomi 10T with custom ROM MIUI 13 Android 12, magisk 25.2, Thank you
[Magisk] chiteroman:
Mini update to v13.4 just to fix scripts problems: https://github.com/chiteroman/PlayIntegrityFix/releases/tag/v13.4
[Magisk] osm0sis:
It doesn't restore a custom pif.prop anymore. You removed my way, and have it backup pif.prop to /data/adb regardless of whether it's custom or not, and then it never does anything with that. 🫤
[Magisk] HippoMan:
I'm very grateful for all of the *excellent* work that's been done on PIF!

13, 13.1, and 13.4 all have been working very well and consistently providing BASIC and DEVICE integrity on my Nothing 2 OS 2.0.3 (A13) with Magisk Alpha 26401 and LSPosed-Zygisk 1.9.2 (I've been too busy to try 13.2 and 13.3).

And a tiny number of quick and not very in-depth banking-app tests seemed to work fine, as well.

I didn't do more banking-app testing because I don't use my devices for banking nor for contactless payments.

I would have to use screen locking in order for the devices to work for contactless transactions, and I hate dealing with screen locking. I wish there was also a PIF-like module which could spoof screen locking.

But anyway, thank you for a *great* module!
[Magisk] osm0sis:
Trying to troubleshoot on my ancient Nexus 7 is tedious agony but I'll see if I can experiment in the next couple days and fix it with your versions... Lineage was complaining that the ROM was on public keys, so I think it's more than just the SELinux status.
[Magisk] Vision:
I agree with screen locking, i don't want it 😂 but many apps need it unfortunately, if anyone can make a module which could spoof screen locking, it would be perfect
[Magisk] Flr Power:
You don't need anything else. It's part of a12 to a14...
[Magisk] michasssxdd:
View attachment 6036143View attachment 6036144View attachment 6036145

View attachment 6036146The phone does not meet security requirements. No NFC payments possible. Oneplus 6t. Android 13. Modules that I have installed. Anyone know how to fix this?
[Magisk] zgfg:
Ok, indeed Impression reports the warning you had👍

But the company is FaceApp Technology LTD from Cyprus, I really don't understand what's to be addressed to Google if that Cyprus company does not let you use their filters on the modded phones

Btw, did you pass Strong Integrity last week - did Impression really worked last week that we could at least be sure that it checks for Strong Integrity?
[Magisk] westruk:
It's a shame you don't realize what a liability Google has in this situation. They have developed and are promoting PI.
[Magisk] zgfg:
It's a shame you don't realize that it's app owners/developers who chose the policy and detections

And I asked you - you didn't answer, did it work with the Strong Integrity spoof that you could claim they check for Strong Integrity?

Have you ever used 'root' checkers like Momo, TB Checkers and so. They don't require Strong Integrity but they look for tons of other traces of the modded phone (eg, TB Checker let's you pass PI with Basic and Device but it finds traces of Zygisk, LSPosed etc, that must be then spoofed the other ways)

Have you used Native Detector - did you ever pass it (like last week with the Strong Integrity spoof)?

It doesn't say a word about Pin but it reports 'injections'

Momo - the same, etc
[Magisk] westruk:
I'm not tested before

Maybe maybe
[Magisk] pndwal:
Playing with this a little more, if I disable USNF, I get the 'certification/security' error with many (all

?) of the effects offered for free, and after a failed security message (strangely) all the offered (free) effects are labelled 'Pro' version (unavailable).

However, with deviceIntegrity restored, Impression --> Hollywood 2 is (or seems to be) the only effect that results in this... Skin --> Freckles and others are now applied without issue as expected...

I'd be surprised if a different attestation label or detection is really used just for the Impression --> Hollywood effect, so it now appears that this anomaly may simply be a bug in the app's implementation of the PI API deviceIntegrity verdict rather than a strongIntegrity requirement.

👀 🙃 PW
[Magisk] Displax:
Yep, there is 3 security levels in this app
[Magisk] pndwal:
Wow... A first?...

So

- opens w/ no PI label required,

- Most photo effects require deviceIntegrity, and

- Impression --> Hollywood effect (others?) requires strongIntegrity

then?...

If using strongIntegrity I guess Impression --> Hollywood effect cannot work on a stock (locked) Android 7 launch version or older device! 🙄

Thanks for analysis... 👍 PW
[Magisk] Spartacus500:
This 🤔

is migrated to unsecured prefs V2 = true
[Magisk] shaunoleary:
I can confirm latest version of module is working on LOS 13 on Pixel 3 (Blueline) for GPay.

The last week or so, I have been unable to log in to my Uber Driver app; seems the issue is similar to this - the Uber app seems to be detecting if the phone is rooted, or has unlocked bootloader. The app asks me to "go online with a different device". I've tried the app on my wife's (unmodded) phone, and it works fine.

Does anyone have any idea of a way to fix this? I've tried hiding the app in Magisk,

Please accept my apologies, and ignore this comment, if it's not appropriate to the thread. I greatly appreciate the hard work you guys do.
[Magisk] OhSnapItzMe:
Even after installing this module, all 3 still fails.
[Magisk] chiteroman:
Disable all Magisk modules except mine and check again. Maybe DroidGuard is detecting Xposed.
[Magisk] OhSnapItzMe:
Even Systemless Host and Shamiko?
[Magisk] Doom Slayer:
Not really a fix, but you may try running apps that detect root inside VMOS virtual machine
[Magisk] Doom Slayer:
Installing SafetyNet sensitive props module helped to pass 2/3 alongside with play integrity fix.

Zygisk enabled + shamiko
[Magisk] OhSnapItzMe:
Was able to pinpoint the problem. It's from the Play Intergrity Bypass Lsposed module. When I uninstalled that module, I was able to pass 2/3 integrity.
[Magisk] ruthl3ss_:
Ok for some reason today I can't pass strong identity. Weird, it worked all of this days and now it's not?
[Magisk] OhSnapItzMe:
Has been patched by Google
[Magisk] intel_core_i7:
I may have known someone who claims to be in one of those private community/development teams (yet to be verified, only screenshots given), and I was "offered" to use, but of course I couldn't disclose any details so I declined since I didn't want to spend way too much time into Android rooting/modding anymore. And if I'm currently in a group like that, I don't think it is beneficial to any of you guys in XDA or in any other public communities. But you could tell that bypassing/spoofing STRONG_INTEGRITY is still possible for now and in the future, there might be one or more exploits that Google hasn't patched yet
[Magisk] intel_core_i7:
Well you guys have discussed about the implications of forcing apps to use STRONG, one of those being leaving out all of the outdated devices and those which have broken hardware attestation. FaceApp did that, Android 8+ required to work
[Magisk] pndwal:
Well, sort of... Seems the app works fine and most photo effects offered work with deviceIntegrity... Only Impression --> Hollywood 2 requires strongIntegrity in free version... Guess newer effects in Pro version need strongIntegrity though(?)...

At least it's not a bank ostracising customers (yet)... 🙂 PW
[Magisk] labbala:
is there an example to what is a good data and how to change the 'pif.prop' if one need to do that ? and how do i know i need to change the file and not update to a new version ?
[Magisk] Vision:
I have Android 10 😂
[Magisk] whewdroid:
Have you disabled "enforce denylist" for Shamiko ? Might help
[Magisk] michasssxdd:
Where do I turn it off?
[Magisk] cridus:
I updated from version 12.2 to 13.4 and while it seemed to have fixed me being unable to use google wallet to pay with the phone, it also made my camera stop working. also, once, even magisk's app wouldn't start (I tried rebooting several times). eventually I could open magisk and disable the plugin, and after rebooting everything was back to normal.

I'm on a OnePlus 7 and I have android 9. magisk v26.4, zygisk is enabled, I have shamiko with "enforce denylist" disabled, my SELinux is enforced and I added to the denylist the proper apps.
[Magisk] DanGLES3:
Magisk's settings
[Magisk] michasssxdd:
View attachment 6036157

Still unchanged :( the banking application detects root
[Magisk] makeyourself:
If you're talking about Google Wallet/Pay then you're passing Play Integrity so clear Play Services data or wait for it to fix itself. Edit: YASNAC only checks SafetyNet. It's likely the same result but you should also check Play Integrity status to make sure.
[Magisk] michasssxdd:
Jak sprawdzić ? Dane usunięte z portfela, aplikacji bankowej, Sklepu Play itp. Nadal to samo...View attachment 6036159
[Magisk] shoey63:
Thanks for the update 👍

Maybe you could fork the repo and do some pull requests?
[Magisk] MonteXMat:
Musisz odinstalowac aktualizacje sklepu play, google play services i przeinstalowac portfel na samym koncu.

Bedzie kazalo Ci zalogowac sie jeszcze raz do konta google i dodac karty od nowa.

You need to uninstall the updates of the play store, google play services and reinstall the wallet at the very end.

It will ask you to log in to your Google account again and add the cards once more.
[Magisk] osm0sis:
The scripts and Magisk module bits aren't on the GitHub repo, unfortunately, so here's the only way currently. Would be good if @chiteroman would add the module files to GitHub how kdrag0n/Displax had it, and just have pif.prop in the .gitignore, then I'd be happy to open PRs instead. 🙂
[Magisk] HippoMan:
Oh, thank you! I'll investigate further. I know this is OT for this thread.