yashsingh1/xdaforums huggingface dataset:
[Magisk] zgfg:
It was discussed yesterday so please start with that

However, you cannot use any phone - it must be a phone for whom Strong Integrity (with locked BL and official firmware) is not supported.

So that Google accepts backing up to Software attestation, ie to only Basic and Device Integrity

So that PIF can trick Google to avoid forcing Strong Attestation when spoofing with the props 'stolen' from that phone

Hence most of (new) phones are not applicable to 'steal' props from them.

All together, not trivial - IMO, better enjoy with the props provided with this module

Btw, take a closer look and you will see that last three versions of the module were released with props from three different phones. If they all worked for you, just backup their pif.prop files and with no effort you will have your own collection of the spare, valid props for bad days when they cone

You will just need to slightly adapt your older backed-up files due to the small changes in the format
[Magisk] pndwal:
But you still didn't un-enforce DenyList, so Shamiko shill can't work!...

Nb. This won't fix G Pay/Wallet anyway...

You first need to be check you have Play Integrity MEETS_DEVICE_INTEGRITY... SafetyNet is s deprecated and Pay/Wallet was the first to stop using it!... So YASNAC won't cut the mustard!... PW
[Magisk] corumuk:
FYI

One Plus 5T here with stock rom rooted.

Latest magisk

Play Integrity Fix 13.4

No other modules

Google chrome crashing on launch consistently

Magisk hanging when launched

Rebooted but the same

Uninstalled magisk then everything back to normal

Re-installed magisk all ok

Re-installed play integrity fix and same issues as above
[Magisk] BillGoss:
[

Please read https://xdaforums.com/t/xda-developers-forum-rules.4200559/

4. Use the English language
[Magisk] chiteroman:
v13.5 BETA version: https://github.com/chiteroman/PlayIntegrityFix/releases/tag/v13.5

Should fix pass problems and crash errors.
[Magisk] xSnowLeopardx:
Feels so weird seeing so many updates and me chilling with base version 13 lol.
[Magisk] Wolfcity:
Until Google blacklists something....than a lot of users here will want to know how to change the pif.prop of 13.x and up.

Don't get me wrong, I've been on 13 until today too but one should know how to change a fingerprint,where to find it,how to insert it.

No need to change a running system but be on the watch.
[Magisk] Homeboy76:
English, please
[Magisk] Gordietm:
Not passing device integrity on 8 pro. 13.4 works fine.
[Magisk] Kingcool88:
Passes device Integrity fine here on same phone with 1.3.5 beta.
[Magisk] BillGoss:
I thought that the advantage of using pif.prop was that one could change the device information used.

But I've discovered that changing pif.prop (in 13.3) ALWAYS results in not passing device integrity (basic is ok).

Not even when using a pif.prop file from a previous version (13.2) of PIF!

What am I missing here?
[Magisk] badabing2003:
Hmm,

No pif.prop in the package?
[Magisk] osm0sis:
It's the omitted API_LEVEL/FIRST_API_LEVEL bug that I've been mentioning. Until it's fixed you'll have to specify one in your pif.conf to get it passing.
[Magisk] osm0sis:
Back to putting it in the open source code side of things again for some reason...

🤔
[Magisk] TraderJack:
Wasn't loud enough the first time?

🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX A Zygisk module which fix "ctsProfileMatch" of SafetyNet and "MEETS_DEVICE_INTEGRITY" of Play Integrity. To use this module you must have one of this: - Magisk with Zygisk enabled. - KernelSU with ZygiskNext module...

xdaforums.com
[Magisk] pndwal:
Yeah, you really need to keep up with a lot to get DEVICE_INTEGRITY now...

Passing (old) ctsProfileMatch is a good clue re valid prints (matched SECURITY_PATCH date etc, nb. S/N API never required fingerprint prop mismatch although requirement for model prop mismatch was adopted before migration to PI), but you also need to achieve the correct mismatch with Google's blacklisted prints introduced with PI (ie. ones that invalidate/prohibit BASIC-only evaluationType verdicts, ie enforce HARDWARE_BABKED evaluationType) to discover prints working for DEVICE_INTEGRITY.

Broken FIRST_API_LEVEL for devices <33 is one thing (basically everyone must specify a value ATM; should be required only for 33+ devices by rights), but there's less working (unblocked) print combinations now also... Easiest to experiment with pre- Marck 2018 prints... If later you'll need to get SECURITY_PATCH date matching fingerprint from whatever ROM/source you used for the print...

Also, as FIRST_API_LEVEL is not set properly ATM when blank, I don't know if blank SECURITY_PATCH sets original device date properly/consistently either... You may need to set it manually too regardless of prop date if device setting is broken... @osm0sis may have tested enough to be able to confirm if blank generally works here with old prints or not... 👍 PW
[Magisk] xSnowLeopardx:
Very off-topic, but, why the PW endings all the time? And is that automatically done or do you just end every post with it because the answer you'd give to my first question.?
[Magisk] bakaekze:
No one cares. This thread is about passing Play Integrity tests. Banking apps have their own detection tests, each app their own, that have nothing to do with Play Integrity Fix module. It makes no sense to post here about other banking apps.

You can:

a. Find your own way around detection;

b. Not use them;

c. Return to stock rom and lock bootloader.
[Magisk] zgfg:
Yes. And the problem is caused by the new service.sh and its companion binary resetprop utility from Husky

I suggest you:

- Unpack service sh and system.prop

files from v13.3 or earlier earlier versions of this module and copy over to:

/data/adb/modules/playintegrityfix

(you must overwrite the service sh from v13.4)

- From that same folder delete this new resetprop binary (sorry Husky, I'm pretty sure it cause troubles)

- Reboot and test again

- If it won't help (something is really fishy here?!), re-flash Shamiko module

Below are screenshots from TBChecker, S Check, RootBeer and Momo

Everything that is red instead of green (and that I didn't cross out) was caused for me by using this new PIF v13.4 - with all previous versions of this module I had all those check marks always green

I already spent today several hours flashing this version, that version, making changes in service sh, etc, and checking with those root checkers, so I'm pretty sure to what I said above (actually I would have to say much more but I'm more interested into continue of debugging this)

So in short, if this new service.sh, finds a single property that it wants to change and/or the property that is non-existent and it wants to create it (maybe the culprit is in that second case), then it calls this new Husky's binary resetprop to do so and aftervthat I have all those red flags

What is even more bothering me that eg renaming service sh to service bak or commenting out the change of prop that caused the problem in service sh, and rebooting (yes,I always reboot) does not help - to get green checks again I even had to re-flash Shamiko module (did I go berserk or what - but it happened to me twice)
[Magisk] zgfg:
The above post was also the answer to @TeaderJack

And if you have time, I'd ask savvy and knowledgeable ppll here to test this more, like @osm0sis and ofc @chiteroman and @huskydg

If you have Shamiko module installed, you can compare and find then in about 90% of props checking and changing the service.sh of Shamiko module and service.sh script of PIF module coincide

Hence it's really no need to have scripts from both modules to care about the same props

Besides, if you eg don't have Samsung, you for sure don't have those Samsung specific warranty_bit props and you don't need to create them to be set to 0

So that is something that module could check and don't force creating of those props to 0 values. Similarly for few more props specific to Realne and OP

Specially now when this new resetprop binary supplied by Husky IMO really causes troubles when it creates those non-existing props

So, some hints for testing. Compare the service sh from PIF and Shamiko, and add what is missing from Shamiko script to PIF script.

And then (or just without comparing) rename service sh in Shamiko to service bak to disable it and reboot

Seems that Magisk always executes first Shamiko script, and after that PIF script (generally it seems that it executes the scripts from the modules in the reverse alphabetic order of the corresponding module names)

So disable that service.sh script from Shamiko, and those props will not be already redefined by Shaniko script - hence PIF service sh script will have to create or redefine them.

And that would trigger the red-narks in the root checkers

Edit: I have Magisk v26402 and Shamiko v0.7 4 - maybe there are no problems with this new resetprop binary if using Magisk Delta or Alpha and/or maybe if using ZygiskNew.

IDK but I think most here have this 'official' setup like me and something gets really wrong (then)
[Magisk] TraderJack:
Definitely device specific. I was on 13.3, but just upgraded to test your results. Rootbeer comes up 100% clear and MoMo only shows bootloader and debug messages for me on A11.
[Magisk] TraderJack:
FYI if anyone is interested, this is what he's referring to:

[Discussion] Magisk - The Age of Zygisk.

This is a discussion and help thread for the newer versions of Magisk. The main goal of this thread is to help users migrate to Magisk v24+ SafetyNet Basic integrity Pass CTS profile match Pass Play Protect certification Device is certified...

xdaforums.com
[Magisk] Wolfcity:
Did you try the build by @osm0sis ? I think he fixed these issues in some kind of pre-release.

It's working for me without problems.

(Edit: This answer is related to your post above the quoted one )
[Magisk] Vision:
Yeah is very complicated, all this with bank apps (don't have bank app in a rooted phone 😂), only want this module to show me apps in Google play store which must be certified and work again. And this module by @chiteroman is work perfectly. So simple
[Magisk] MonteXMat:
Apologies, was just trying to help out my Polish brother 😊
[Magisk] zgfg:
I'm not referring to the labels and managing of pif.prop files and it's labels- that's totally irrelevant to what I'm talking about

I'm talking about the redefinition of props that are executed by service.sh script - those spoofs are not targetted to GMS but executed/changed generally. Moreover, those props are mostly totally irrelevant for Play Integrity!!!!

Eg, with all those now red marks that I have in TB Checker and so - I still perfectly pass Device and Basic Integrity (and Walker perfectly works)

But the same way as TB Checker fails, many banking apps that similarly use their own detection techniques would also fail

Btw, comment to @TraderJack - I absolutely never had a single problem with the official Sgamiko and and I never had any of those red-narks like on the screenshots

And I even didn't need service sh and system prop from PIF - because all those props from them I already had with the proper values (either by my Xiaomi.eu ROM or being spoofed by Shamikos service sh).

So I usually installed PIF and right away deleted its service sh and system prop - by keeping only what is really essential for Play Integrity, ie its Zygisk subfolder, classes.dex and pif prop (and ofc module prop)

But even if I did not remove the service sh (previously it also had system prop) I still did not have problems

But now, with v13.4 and it's new custom resetprop binary utility I do have those problems.

Of course, if I remove that service sh/resetprop binary or simply replace them with the old service sh that was using official resetprop from Magisk, not that binary from Husky, then there are no problems
[Magisk] TraderJack:
Yeah...I'm just stating my experience with my device. I have not seen any differences with any of the versions over the past couple of weeks. In all cases, including 13.4 MoMo and RB (only ones I have on right now) are reporting as would be expected.

I agree that I would like to see a more thorough reasoning for all the props being reset. Especially for those of us that haven't been following every thread for the past 2 years it would help to know what the purpose of each of those lines for. IMHO if they aren't related to passing PI they should be moved out to another module. I suspect they are helping some people and just like they seem to not effect my device, perhaps it is possible that some people do need them to pass PI?
[Magisk] zgfg:
There are three different versions of RootBeer - I'm referring to the one from GitHub, not the two from Playstore

For Momo I cut-off/hid on the screenshot everything that standardly fails to me (so what I'm not interested in, like Unlocked BL, USB Debugging)

I suggest to test with TB Checker - with a proper setup EVERYTHING must/can be made passing there.

However not now with this new service sh/resetprop binary

And the problem will be triggered only when service sh encounters at least one prop that it would create (or just redefine?) by calling that new resetprop custom binary

If PIF's v13 4 service.sh does not encounter any prop that it needs to redefine, the problem will not be triggered and red-checks will not be showing

That's whyI coomnted in the previous post how to play with the service sh (like by removing service.sh from Shamikos to prevent that it executes earlier and thus that it already redefines the same props then the PIF service sh would want to change but would skip - since they will be already redefined)

However, on some phone/ROM the PIF's service.sh will still fnd one or two props with the wrong values that are not covered by service sh from Shamiko and it will go to redefine them by calling now the new, custom resetprop bibary...
[Magisk] TraderJack:
Maybe the problem is that you are not an LSposed user? With LSposed and HMA there isn't s single app I need that I can't run. I'm sure they there are some that won't work, but I think most people have better success running HMA.

As far as PIF causing an issue, backrev to a version without the prop scripts as has just been mentioned.

If I were you I would try your apps with HMA, I've had very good results.
[Magisk] TraderJack:
Did you compile RB from source? I can't find any compiled assets on GH. Can you link?

My TB comes back completely clean with 13.4 once I configure it properly in HMA.
[Magisk] zgfg:
Simple test for Terminal emulator with su

Assuming that prior to the test, Run Root Check from TB Checker does not fail

1) Execute:

resetprop test.prop.one 1

and retest with TB Checker.

Reboot and retest with TB Checker

2) Assuming that you have PIF v13.4 installed - ie, its custom resetprop binary in its folder (path below)

Execute:

/data/adb/modules/playintegrityfix/resetprop -n test.prop.two 2

and then retest with TB Checker.

Reboot and retest with TB Checker, Run Root Check

To clean-off the red flags in TB Checker (you should have now, at least in my shoes), reinstall Shamiko (?!?)

And then inspect the PIF v13 4 service.sh to understand why the above test is relevant to what I was commenting/complaining earlier

And see how/where from that custom resetprop bnary come to PIF:

[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] zgfg:
No I didn't

There was a post/short discussion in one of the threads why the RootBeer 'detects' SELinux Permissive

I retested (with the version from Playstore) and didn't have that problem. Then I was told to test instead with that particular release from GitHub - so I installed and tested

It turned out that the app wrongly reads SE Linux status

So I hid on my screenshot itts wrong detection of Permissive mode (it's not relevant) but left it's relevant detections off su binary, etc

Unfortunately, I couldn't dice in now to search through the dozen of candidate XDA threads, where was that post with the link to GitHub

But stick with TB Checker (available on Playstore), one of the best checkers
[Magisk] TraderJack:
Ok...not trying to dispute what you are seeing, just letting you know that TB comes back completely clean for me even after upgrading to 13.4. I am using LSposed and HMA however, as I think it's useless to try and pass without that configuration (in my case).
[Magisk] highdiver_2000:
Follow my screenshots.

🔧 [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] highdiver_2000:
Anyone got Citibank app to work?
[Magisk] TraderJack:
Works fine for me. I get a root warning for it saying some things might not work, but don't know what they are. If I configure it in HMA and reset the app data and login it works with no warnings. Biometrics enrolled all seem fine.
[Magisk] Fishawy:
v13.5 fails SafetyNet on P7P stock. Reverted to 13.4, all good.

Many thanks for your endless efforts.
[Magisk] MonteXMat:
Awesome, works fine for me on the Poco F2 Pro
[Magisk] osm0sis:
Did you try with the beta or the final? Final went up like an hour ago.
[Magisk] TotallyAnxious:
Same here on my P7P. 13.4 works. 13.5 fails CTS.
[Magisk] TotallyAnxious:
I used whichever was pushed through magisk app. I'm assuming final.
[Magisk] highdiver_2000:
You used HMA with Magisk? Google search returns not to be used together.
[Magisk] pndwal:
Actually @chiteroman does care about detections and so do others... He's taken pains to use known methods to hide reset.prop, hooking traces etc, and this seem to be subject to ongoing experiments... Issues and solutions may also be device specific also...

You are fundamentally correct that USNF and forks are not about hiding root traces, but they shouldn't contribute to those unnecessarily either...

Right or wrong, was there any need for such a response?... People are trying to help mate, but they're not perfect... PW
[Magisk] osm0sis:
Are you using a pif.prop? The new defaults are built into the code again. Not sure what this means for the FIRST_API_LEVEL bug... Might fall back to the default coded instead of to the system one? Which would technically work, just still isn't ideal. Hopefully @chiteroman can explain.

Edit: Nope, bug still fully present, triggers hardware backed, etc. FIRST_API_LEVEL=poop still works around it even. 🤷‍♂️
[Magisk] TotallyAnxious:
Nope. Whatever it does on its own.
[Magisk] osm0sis:
Interesting. The coded defaults in v13.5 pass for me on my OnePlus 9 Pro. 😕
[Magisk] HippoMan:
Thank you, Googlefrinchians, for continuing to make our lives increasingly more difficult and complicated!

I know you're doing it to motivate us modders to work harder, simply because you care about us so much, and that's why I'm so grateful.
[Magisk] Fishawy:
Same, also with both beta & final. So yeah, sticking to 13.4 for now.
[Magisk] TraderJack:
Don't know what to tell you, been using them together for years and all the apps I need run.

I don't know how you could use it without Magisk, It is an Lsposed/XPosed module and in order to run Lsposed/Xposed you need Magisk. RTM:

GitHub - mModule/guide_hma: This is a quick guide to hopefully make it a little easier for people new to Hide My Applist.

This is a quick guide to hopefully make it a little easier for people new to Hide My Applist. - mModule/guide_hma

github.com
[Magisk] osm0sis:
Out of curiosity, can you try 13.5 with the 13.3 service.sh and system.prop?
[Magisk] Fishawy:
As in replacing components and repacking the module?

I might be able to do that later in the evening, out and about now.
[Magisk] osm0sis:
No need to repack, just install 13.5, reboot, then extract the 2 files I mentioned from 13.3's zip and move them into /data/adb/modules/playintegrityfix (overwrite the one existing one), then reboot again.
[Magisk] Fishawy:
Just did. Unfortunately it still fails.
[Magisk] osm0sis:
Thanks for trying, must be something from the latest code rewrite. It was another big one though, switching back to Shadowhook and such yet again, so it's difficult to narrow it down. Hopefully chiteroman will have some ideas.
[Magisk] intel_core_i7:
Reading all of the "prop" thing that I couldn't understand a bit just made my head dizzy, I would probably pull my actual physical card out of my wallet instead if card payments were a must instead of updating the module few times a week and dealing with new problems from banking app's own root detection (if I somehow wanted to return to Android modding again)

Banking apps here not using PI at all is a blessing. And main method of cashless payments in Vietnam is via bank's QR codes, so it's livable without PI
[Magisk] fbirraque:
Which RootBeer do you refer?

This one... https://github.com/KimChangYoun/rootbeerFresh
[Magisk] fbirraque:
Magisk + HMA works flawlessly together
[Magisk] Nergal di Cuthah:
For the first time (13.5) i didn't pass device. untouched pif props :( rolled back (13.3) because i don't know enough to write the pifprops...yet.

Pixel 6 pro november 23 security, magisk canary. No lsposed or other modules (except systemless hosts)
[Magisk] amk316:
11-24 09:42:17.257 17465 17465 D PIF/Native: File pif.prop doesn't exist, using default values

:unsure:
[Magisk] zgfg:
I have posted similar log and asked the same thing back then with an earlier v13.x (last week) but it went under the hood

Good that you open now the same
[Magisk] zgfg:
Good to see that in v13.5 that problematic custom resetprop binary is removed, and service sh uses again the official Magisk resetprop

So problems I was talking about yesterday evening do no more apply to v13.5

---

Also, now the Zygisk folder does no more contain x86 libraries, but only the ARM V8 and V7 libs

In fact, by checking with $ABI, customize.sh installation.sctipt could go even deeper and detect which of the two is really needed for the particular phone's ARM architecture

---

UNFORTUNATELY, the customizable pif.prop/pif.json is now gone(?)😘
[Magisk] zgfg:
Yes, it was that one
[Magisk] Gilg@mesh:
13.5 won't pass device integrity P8P.
[Magisk] BrimoFan123:
Strange thing: after PIF 13.5 installation MEETS_DEVICE_INTEGRITY red but half an hour later when tested again green.

Wallet works, bank apps works.

[EDIT] Again MEETS_DEVICE_INTEGRITY is red. Going back to 13.4
[Magisk] esatch:
Mi9 lite, EvolutionX android 13, 13.5 won't pass device.

Revert to 13.4, passing. Thanks for your hard work.
[Magisk] Homeboy76:
@MonteXMat

I can appreciate you assisting your "Polish Brother".

However, we need you to translate the Polish to English in post # 2,793.

How?

Put the english translation beneath what

michasssxdd said

and Put the english translation beneath your reply.

Why?

So other XDA Members that do not speak Polish can benefit from the

question asked and the reply

. :)
[Magisk] osm0sis:
The weird thing is I can't even find anything in the published code that would make it touch those specific props.
[Magisk] emontes:
Interesting. I am using 13.4 (13.5 does not work for me) but with both I have some banking apps that just stopped working after the update to the latest Android 14 (AP11.231020.016.A1) on a Google Pixel 7 Pro.

Running TB Checker, all is well but RootberFresh fails on SE linux flag is enabled.

Edit: TB Checker also has a "SE Linux flag is enabled" and it shows ok but RootbeerFresh shows it red.
[Magisk] Bec de Xorbin:
I don't understand anything what's happening on this thread, but thank you for version v13. It just works.
[Magisk] esatch:
Same here, on 13.4, btw
[Magisk] Vision:
I'm little confused, in the recent version the pif.prop feature is removed ? or now must we created manually inside in the module folder ? because is good feature