yashsingh1/xdaforums huggingface dataset:
[Magisk] osm0sis:
You just have to create your own and place it manually. I do think it would be nice to have back again to avoid having the current print values be directly visible on GitHub's code. 🫤
[Magisk] Vision:
Yeah, I prefer (i think and other) the pif.prop inside like before, is more easy to we understand and write inside, i'm in v13.3 have it inside and is work
[Magisk] osm0sis:
Oh wait... Yeah it's fully gone now... 😕

Release v13.6 BETA · chiteroman/PlayIntegrityFix

Removed custom props spoof

github.com

I... Think I'm going to have to fork. 😑
[Magisk] pndwal:
Interesting... Back to angler print USNF used originally... Well. It was the second one adopted, just to go really low A7-->A6, as a jus-in-case measure... I think either you or Displax did that?...

Edit : I was wrong. 😬

"null" for first API just didn't work for A13+ Launch Version devices after Pixel 2 Google spoof was patched; it did work in 2.4.0 mod 2.0 while it lasted for all devices AFAIK... Probably still just interpreted as "null" (not set?) however, but it breaks PIF for A13+ LV devices, and while it does work for A12 and lower, I believe it may cause unknown issues... Expected (device) value works fine up to 32 AFAIK, so should generally be set to device value unless device value is 33+; set these to 32... So seems all users are best to set this manually ATM...

Looks like patch level date is changed from device value also... Not sure why... Doesn't need to match old angler print...

*Nb. looks like users should manually change both these props (in general): Patch level to system value while using angler/other old prints, and first API level to system value with a cap of 32 since "null" may break stuff...

However this:

may indicate that this was intended while maybe not fully thought through... Ie. we can leave/set no label for "null" if you really want it or don't care, but giving a value like "poop" or "na"(?) apparently gives device (/system) value. (Nb. I haven't tested this)...

Yeah, LV A11! 😜

... Your other concerns (re. dalvik, zygote and surfaceflinger) are above my paygrade ATM... 😬

@Gordietm

@Fishawy

@TotallyAnxious

@emontes

You A13+ LV device users will need to add pif.prop file and add FIRST_API_LEVEL=32 (or lower if you really want) per *Nb. above...

@Kingcool88 did you already have that since it works for you?

Did you guys have pif.prop file in modules/playintegrityfix directory? ... Maybe it can be preserved?... Mine from 13.4 went to /data/adb/pif.prop.old...

If so, you could try 13.5 again with it removed (to get defaults in 13.5) since values ported from earlier build may be the issue, and defaults are generally working in devices launched with A12 or less...

Sorry I couldn't post this earlier... 🤠pPW
[Magisk] Vision:
Yeah for that i say. Why? @chiteroman is best feature
[Magisk] osm0sis:
angler was just my custom pif.prop where I removed those lines but know it should pass without.

It should just not try to send any values at all if (null) so that the system ones are used.

All should have worked for those 13 LV users since his code still passes like 23 by default, so that's still confusing. Oh well...
[Magisk] TotallyAnxious:
Yep that fixes 13.5 from me
[Magisk] Kingcool88:
I haven't tweaked anything on the module.
[Magisk] pndwal:
Haha... I see I'm !ate to the party!... Party with not much to celebrate?...

Anyway, my post above may help users who want to keep custom props spoofing w/ 23.5, at least till you produce working fork... Rooting for you! 👍🥳 PW
[Magisk] osm0sis:
Interesting, I guess that just means the security and level prop defaults were broken in a regression in the 13.5 rewrite.
[Magisk] pndwal:
Wow... Maybe "null" only isn't accepted on LV A13 devices... I assumed it broke PIF in A13+... 🤔 PW
[Magisk] Wolfcity:
Would be great. You and @chiteroman cloud help each other. And beside, you're a well known and professional "Coder", as proof one should just take a look into your "Odds and Ends".(y)
[Magisk] emontes:
Added pif.prop and the first_api_level line was there already, no deal, it fails device integrity. Thanks, though :)
[Magisk] osm0sis:
You mean "professional" "coder" 😄

@zgfg Even 13.6 still has the logcat prop noise despite removing pif.prop support. Looks like it was a regression starting at 13.3, 13.2 logs are clean. Might start a fork back there and then methodically try to add some of the newer stuff like API level and the GMS cache file fix. 🤷‍♂️
[Magisk] Gordietm:
13.6 beta works for me on 8 pro with QPR2 Beta 1.1
[Magisk] Vision:
If @chiteroman remove all this, and @osm0sis create a fork, what is the best for module survive and improved like pif.prop feature is the best
[Magisk] pndwal:
Oh... Haha... I assumed...

Mmm... I'm getting "a null value represents a reference that points, generally intentionally, to a nonexistent or invalid object or address" and "The C NULL is a special reserved pointer value that does not point to any valid data object." (while"The C NUL is a single character that compares equal to 0")...

Anyway, as I said the last time null setting worked for A33(+?) devices was with the Pixel 2 spoof for STRONG_INTEGRITY... Nb. A setting of 33+ also worked then (32 didn't for STRONG)... (@Displax's comment: https://xdaforums.com/t/info-play-integrity-api-replacement-for-safetynet.4479337/post-88777079 )... And, of course even it does mean system values are actually sent, for 13 LV users the system sends 33 which, of course, enforces HARDWARE_BACKED evaluationType.... So whichever way you look at it, "null" won't cut it for 13 LV users... 😬PW
[Magisk] pndwal:
Line was there, but did you set value to 32? Tried with all other lines removed?(And using 13.5?... And which directory is it in?)... PW
[Magisk] osm0sis:
I'm surprised Google doesn't just block based on receiving nulls, since I'm sure that would never happen in real unrooted devices.
[Magisk] pndwal:
I'm getting confused... I thought you said system value was sent... I'd originally assumed null value was sent... But assuming it is, it appears that Google may in fact be blocking that for 33 (A13) devices... I'd have said 33+ if it weren't for this:

(Working with P8 Pro apparently)... 🙃 PW
[Magisk] osm0sis:
I've said the entire time the problem is system values aren't being sent, then showed the log showing the nulls which confirms. Nulls would either be interpreted as 0 or infinity, but passing 0 weirdly passes (like "poop" does) and we know 33+ does not, so my assumption is GMS reads null like infinity.
[Magisk] pndwal:
I meant this:

If system values are used, I thought they must be sent!... Or are you meaning Google might check for system values using a means other than PI API when it returns null, and happen to see the global system values here instead?... Or am I missing something else? 😬 PW
[Magisk] osm0sis:
You're missing that the quoted post is just me saying what PIF should be fixed to do.

Anyway, I think I'll unsubscribe from this chaos and go see what I can figure out. 🧐
[Magisk] emontes:
It was 32 already but i didn't try with only the API line in, though and yes, it was 13.5 and directory was /data/adb/modules/playintegrityfix.

13.6 pre-release works for me, though!
[Magisk] pndwal:
Oh... So if "null" the module shouldn't spoof a "null" value but default to system values?... I'll admit to being confused still... cos it looked to me like Google sees a null value, not system value, in this case...

Anyway, as I pointed out to other users, null doesn't work with first first API level 33 devices... For whatever reason... 😬 PW
[Magisk] cridus:
I've updated to 13.5 and the phone works normally unlike with 13.4. but despite meeting device integrity and basic integrity, google wallet still tells me my phone doesn't meet the security requirements.

I have:

- OnePlus 7 with android 9

- magisk 26.4 with zygisk

- SELinux is enforced

- shamiko v0.7.4, "enforce denylist" is off

in the denylist I have:

- my banking app. never had problems with it in the past when "safetynet fix" still was the solution

- google play services: only the "com.google.android.gms" and "com.google.android.gms.unstable" packages (are these packages or what)

- google play store: all packages except the "(isolated) com.android.vending" one

- google wallet: all packages

what am I doing wrong?
[Magisk] insanemytouch4g:
Does someone know if you can run integrity check via CLI in a shell? or via adb? Would love to be able to do that instead of opening an app.
[Magisk] BrimoFan123:
Google Play Store nor Google Play Services should be in deny list when using PIF.
[Magisk] revengineer:
Following the report of others that since the recent many iterations root is now being detected by several apps. In my case it is the Marriott Bonvoy app that is now detecting root and no longer runs. I went through the dance of deleting data from app, play store, and play services multiple times without better outcome.

I know this app is only for play integrity and that still checks. But it does not seems coincidence since this magisk module is the only thing that changed in my phone recently.

I did install RootBeerFresh and this app did detect root, reporting SE linux flag is enabled, despite being included in the shamiko hide list and hidden by HMA.

EDIT: I did just see that this app has an update dated 11/16/23, so now I cannot disentangle the app update from effects of the module changes.
[Magisk] dosbuddy:
I agree, to much confusion here.

Anyway thank you all for you efforts.

All v13 PIF versions (up to 13.5) are working for me. 13.4 untested (too big, bc. of proprietary resetprop code).

Poco X3 NFC on latest 14.0.2 xiaomi.eu ROM with Android 12.

Magisk 26.4, Denylist forced, no Shamiko.

Most sensitive app here: eezy.nrw (koeln.kvb.ticket.vrseezy)
[Magisk] HippoMan:
One benefit of all this confusion and chaos is that it's just as difficult for the lurking Googlefrinchians to figure out what's actually going on here as it is for most of the rest of us.
[Magisk] badabing2003:
If Google wanted to block us, they could without necessarily lurking here.

All we're spoofing is for GMS, it wouldn't be difficult to fetch the true device props through other means.
[Magisk] cridus:
I removed them, cleared their cache and rebooted, still not meeting the requirements.

do I need to clear their whole storage, by chance? or at least the one of google play services?
[Magisk] BrimoFan123:
Clear storage for both while in airplane mode -> reboot -> again clear while in airplane mode -> reboot -> airplane mode off, WiFi on, wait couple of minutes and check. At least that worked for me.

And in your case I would also delete data for Google wallet as well.
[Magisk] HippoMan:
Could they actually do that without getting

manufacturers to change the structure of devices that can be approved?
[Magisk] cridus:
okay now I'm meeting the requirements, hopefully it stays like this. I'll probably find out on monday.
[Magisk] TraderJack:
This is due to a bug in how they check SE Linux.

To see if SE Linux is enforcing, type the following in terminal:

crosshatch:/ $ getenforce
Enforcing

The problem is explained here and in related posts.

Basically it is checking for the following setting to determine SELinux Enforcing status, which is not a reliable method:

ro.build.selinux

There are two versions of RootBeer (As discussed). The original and RootBeerFresh.

The latter is checking for a value of 1 in the above variable (which, if using the variable at all was a good idea, would be the right value). However the original is doing an incorrect inverted check.

You can test this by doing the following:

crosshatch:/ # getprop ro.build.selinux
0
crosshatch:/ # resetprop ro.build.selinux 1
crosshatch:/ # getprop ro.build.selinux
1

When set to "0" the original RootBeer will pass SELinux, but RootBeerFresh will fail.

If you set it to 1 the reverse is true.

In short:

IGNORE SELINUX TESTING BY BOTH APPS BECAUSE THEY DO IT WRONG.
[Magisk] zgfg:
AFAIK you cannot call directly PI API from GMS - we know about the quota issues with PI API Checker, hence the app that wants to check must register with G to obtain quota for verdicts from the G server

So I investigated like ten days ago if I could sonehiws call the Check activity from the PI API Checker app but it didn't work.

Actually I asked here but nobody followed up😁

Yeah, I'd look like to automate testing PIF prop configurations with eg v13.3
[Magisk] sawdoctor:
If you think this thread is chaos don't go anywhere near the telegram thread. It's descended into "my app detects root" nothing related to PIF anymore
[Magisk] badabing2003:
Can't you try similar approach with Play Store?
[Magisk] Nergal di Cuthah:
I don't think so as I've not editted one yet. What is the full path and I'll check

Ok i have both a pif.prop in modules and an old in same as you. You want me to delete both and reinstall 13.5?
[Magisk] HippoMan:
Agreed. I check the TG group once or twice a day, and there are usually more than 100 new messages there every time I go there.
[Magisk] Clasimodo:
I had to clear data of Wallet and play services
[Magisk] zgfg:
Came home from work and I see that enigma with SELinux red flag in the given RootbeerFresh from GirHub was already answered

Just to add the following:

So, if the following commands from Terminal Emulator return as below, you are ok, your SELinux shows that it's enforcing:

:/ # su
:/ # getenforce
> Enforcing

:/ # getprop ro.boot.selinux
>

The second means that you have

ro.boot.selinux = <empty>

ie, not defined

but the RootbeerFresh app (that version from GitHub) wrongly 'understands' that and shows the red flag for:

SELinux flag is Enabled

---

Now, if you really want to have a clean, green sheet in that RootbeerFresh app version, redefine

ro.boot.selinux = 1:

:/ # resetprop -n ro.boot.selinux 1

:/ # getprop ro.boot.selinux
> 1

See the screenshot

Seems that it works both with 0 or 1

But TB Checker would fail then for the same SELinux flag - see the screenshot

IMO, TB Checker checks correctly, not that RootbeerFresh version, so do not pay attention to what RBF says (and don't be 'pernissive' towards the RBF app

---

To delete the ro.boot.selinux prop back, run:

:/ # resetprop --delete ro.boot.selinux

:/ # getprop ro.boot.selinux
>
[Magisk] Vision:
I just noticed the v13.6 BETA has gone
[Magisk] Usama-CW:
Source

Reason :
[Magisk] osm0sis:
That was the reason he removed pif.prop actually. But there's a new commit 30 minutes ago that adds it all back again and switches back to Dobby. 🤪
[Magisk] TraderJack:
Add @chiteroman

Just want to let you know of an issue I'm seeing. Had some time today and was testing all versions from 13 (including the 13.3 json beta) with custom pif.prop values I have.

I have several custom pif.props, for obvious reasons I am not going to disclose the details. I'll say that the two I've tested are A9 and A11 fingerprints. This is what I notice:

13.1 - Logcat shows values being used from custom pif.prop. However PI only passes BASIC.

13.2 - Logcat shows values being used from custom pif.prop. However PI only passes BASIC.

13.3 - Logcat shows values being used from custom pif.prop. A9 and A11 prop file passes BASIC AND DEVICE

13.4/13.5- Logcat shows values being used from custom pif.prop. A9 profile only passes BASIC, A11 prop file passes BASIC AND DEVICE

13.5 - Logcat shows values being used from custom pif.prop. However PI only passes BASIC.

13.6 - Doesn't seem to honor my pip.props in Logcat, so can't test

In other words...strange results and a warning for anyone testing their own props that different versions appear to show different results. I can't necessarily say why the results are as they are, but I've tested comprehensively so perhaps it is worth digging into.

Let me know if you need more info.

As for me, I will be sticking with the official 13.3 for now until we can get this worked out. It appears to provide positive PI results for the largest variety of prints.
[Magisk] osm0sis:
It's because your print requires a matching security patch prop, and the older versions don't support that.
[Magisk] chiteroman:
Check latest v13.6 (uses JSON) 🤗
[Magisk] Nergal di Cuthah:
@pndwal in case you missed it i edited my reply to you above.

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

Edit: or should i just clean install 13.6?
[Magisk] TraderJack:
So 13.6 (non-beta) seems to work with all my prints (after updating the API line to 'FIRST_API_LEVEL').

However, I'm not sure your comments address all my results.

For instance, why would 13.3 work perfect, but 13.4/13.5 work with one, but not the other.

And then why 13.5 doesn't work at all.

If you guys are sure that your comments address all of it, then that's good for me. There have been too many regressions and issues that I can't keep up as I am not reviewing the code to the same level. I just wanted to share what I found in case any other regressions might be good to have it comprehensively documented here.

I'm sticking with 13.6 for now as it appears to work with all my prints.

thanks
[Magisk] rom-g:
Hello @chiteroman

I'm sorry to inform you that my old Android 8.1 phone can't boot with Play Integrity Fix v13.6

When reverting back to 13.5, it boots up normally.

My phone is BQ Aquaris X PRO running Android 8.1 Stock Rom with latest Magisk Stable (26.4).
[Magisk] rseiler:
For those who've had experience updating this module (I've just started with 13.5), beyond rebooting do you need to do anything else again, such as cache/data clearing?
[Magisk] Gilg@mesh:
13.6 works fine with P8P.
[Magisk] Nergal di Cuthah:
Default fingerprint? Or custom?
[Magisk] Gilg@mesh:
the one that comes with the zip, haven't changed anything, so default one.
[Magisk] TraderJack:
13.6 works find for me on P3XL A11 using the built-in settings or using a custom pif.json (with data from the previous versions or several of my own prints).

If 13.6 isn't working for you, I would revert to 13.3. Don't be trying anything in-between.
[Magisk] Usama-CW:
i think he needs to post two variants (pif-prop.zip , pif.zip) in one release every single time when he bring new update, one with custom resetprop and one without it. This may fix all devices. People will have two choices to choose from, one of them will surely work.
[Magisk] Vision:
@chiteroman And now for understand, create a pif.json and put it here like this? /data/adb/modules/playintegrityfix/pif.json, because with 13.3 i just writing in pif.prop and put it again in the zip and flash it without go to /data/adb (i like the one with in zip inside)
[Magisk] badabing2003:
You can still do it with the zip, the method does not matter, you just need pif.json file instead of pif.prop file.
[Magisk] Nergal di Cuthah:
Clean install of 13.6. Passing both again thanks, and thanks @chiteroman
[Magisk] TraderJack:
Yeah mine crashed using the old JSON format introduced in the 13.3 beta where FIRST_API_LEVEL was just called API_LEVEL. The code should simply use the settings it finds which match, discard the rest, and use the built-in for anything missing.

On that note, I'm interested why your stance on the values? I think the way it is now is probably the best. I think you need a built-in set of values for people that just want to install it and it work OOB. Now, I could go either way - either a built-in set of values, or a default pif.json that comes installed with no additional work. If you don't include one of these options, too many people are going to install it and complain of issues.

I actually think the latter is best, simply use the pif.json that is in the modules (current is Pixel 2 and it does work). Include that with the main install (not as a separate download). If someone wants a different they can replace it with their own. If it is removed entirely (i.e. no pif.json) then the system should go back to using its own values.

As far as missing or malformed data in pif.json, it could behave in one of two ways. Either discard the entire file if not all settings are there (i.e. use the system settings), or use what's there and take anything missing from the system. The latter sounds like the better option - especially if you say the API and Security don't always need to be present. I assume if they aren't present in the json you think they should just use whatever the system's defaults are? If so, then yeah -the latter is the way to go.
[Magisk] osm0sis:
Your assumptions are correct!

Yeah it should fallback to system values for anything missing, especially important for FIRST_API_LEVEL.

And yes I think there should be a default pif.prop included but it's hidden on GitHub using .gitignore, then the module should use another filename for custom, e.g. custom.pif.prop, and read it instead if it exists.

That way things aren't as blatantly visible on GitHub, custom are easily backed up and restored during updates, and it's easy to go back to the default by deleting custom.pif.prop.
[Magisk] Fishawy:
Thanks @pndwal , I won't bother editing v13.5 since v13.6 beta works fine on P7P.
[Magisk] dimm0k:
fsck, here to report the a$$hats at Bonvoy have detected Magisk as well
[Magisk] HippoMan:
More and more app developers are going down that road (to hell). Even if we finally figure out how to permanently protect ourselves against the the Googlefrinchians' integrity checks, we will continue to get trashed by an increasing number of go-getter app developers.

Android keeps deteriorating.
[Magisk] TraderJack:
You mean .json right :)

Also, as far as those logging issues. The line in code responsible has to be this one:

PlayIntegrityFix/app/src/main/cpp/main.cpp at bed9055fd3a950fd75855b163f82bcdc239f3c34 · chiteroman/PlayIntegrityFix

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

github.com

My best guess (but this is far from my forte), is maybe something with the Dobby framework? Perhaps these are values that are somehow tagged per system (mine don't all look the same as yours) that Dobby somehow enumerates based on how each system has tagged them. Based on the PIF code PIF definitely isn't deliberately looking at these values, they must be getting enumerated from another call.

I don't think they are being modified at all, this log code looks like it is just reporting on the values, not translating them to something else. It might not be possible to stop the code from doing this if it is from Dobby or similar, but I think the debug level could probably be turned off, or another filter put on to filter out all values except those we are interested in seeing them. I'm not sure this logging line is necessary at all with the exception of some deep debugging.
[Magisk] digger16309:
Not having that problem on P6P A13 doing all the things one does to hide root.
[Magisk] revengineer:
After some further digging, I read that they are also misidentifying magisk on phones that are not even rooted. I have played a lot with this today without success but with the conclusion that this may be off-topic for this thread as the issue coincides but is not caused by PIF. I apologize that I brought this up and we should revive one of the Bonvoy threads for this.
[Magisk] rseiler:
Let's say you started on 13.5. Then what? After trying 13.6 and being unable to get it to pass device integrity (13.5 didn't have that problem), I reverted to 13.5.
[Magisk] dosbuddy:
As I said, too much confusion here, I like it as simple as possible.

So I reverted back to PIF 13.3.

In /data/adb/modules/playintegrityfix I did the following changes:

renamed system.prop to system_prop.sav (I don't need the settings there)

reduced service.sh

to:

# Late props which must be set after boot_completed
{
until [[ "$(getprop sys.boot_completed)" == "1" ]]; do
sleep 1
done

resetprop ro.boot.flash.locked 1
resetprop ro.boot.verifiedbootstate green
}&

pif.prop is untouched.

That seems to be all what I need for my Poco X3 NFC with xiaomi.eu ROM.
[Magisk] chiteroman:
v13.7 out with new fingerprint

The old one started to random fail DEVICE verdict 🤔

Are Google touching something?