yashsingh1/xdaforums huggingface dataset:
[Magisk] TraderJack:
I've been following the thread along fairly closely, but I must have missed something and I don't want to have to go back however many pages and figure out what it was.

What is the problem with keeping the pif.json file in the normal stable release?

I understand that modifying the json file, perhaps without a full reboot, may not work 100%. But the file is still an easy and handy way to change the profile without having to update the entire version.

I'm unclear on what your stance is for a user who wants to use their own pif profile? Are we meant to use a release that you are stating is an unstable release? Or were meant to compile our own from source?

Can you explain the exact reasoning for now maintaining two separate releases and why it's necessary?

Thanks.
[Magisk] Vision:
I write some similar

View attachment 6036818View attachment 6036819
[Magisk] magaedy:
Please sir, Can you make a module to hide developer options from apps ???
[Magisk] bycolxxiv:
@chiteroman @osm0sis @TraderJack @Vision any ideas concerning my problem?
[Magisk] TraderJack:
Yes I pretty much agree with everything you have written there.

In fact, I can't believe that in principal @chiteroman doesn't also agree.

That being said, there has to be some programmatic reason he has chosen to break these out into two releases and is stating that using a custom .json is unstable.

I'd like his input on why this is, because without these reasonings is appears to be a hastily thought out decision. Maybe there was a sticking point that made it more economical to do this way for now and given time the feature can be merged back.

But that's my main question: Why can't pif.json just be part of standard release with the caveat that changing it without a reboot might cause unstable operations?
[Magisk] Vision:
Exactly, except from @chiteroman, maybe they know @osm0sis, @pndwal, @zgfg
[Magisk] xSnowLeopardx:
That is not what this thread is about...
[Magisk] dilligaf56:
Yep. Still on 13.0, GPay worked fine this morning. P6Pro, A14 Nov. '23, latest Magisk.
[Magisk] osm0sis:
Thank you for uploading the new source! Instead of adding it as a commit which you would have to revert every time you want to do another non-PROPS release, you should put it into a separate "props" branch (i.e. not "main"), then you can just commit fixes to both branches and keep the builds separate. :)

Commits · chiteroman/PlayIntegrityFix

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

github.com
[Magisk] HippoMan:
Actually, I understated that. The TG group is getting closer to 1,000 messages a day ... and it even contains cat videos.
[Magisk] Vision:
Don't listen @chiteroman, your module is for pif not all other request, you keep it simple, chiteroman he is not our Fairly OddParent and make our wishes come true, is try hard to make the best for us. Keep the good work
[Magisk] Jon8RFC:
Here's what I've been using for a few months:

https://github.com/Xposed-Modules-Repo/xyz.xfqlittlefan.notdeveloper

Please do not continue any discussion of that module in this thread, however.

If you have questions, concerns, etc, please create a new thread, perhaps here.
[Magisk] Vision:
In Displax safetynet module have add it separate version for MicroG user. Maybe need something like that View attachment 6036841
[Magisk] TraderJack:
Let's start with what version of PIF and a logcat and maybe someone has an idea. Probably a good idea to post that as an issue on GitHub so it can be tracked appropriately.
[Magisk] ace2nutzer:
Wow!

I can confirm that the latest version 13.7 works properly with latest Magisk v26.4.

It fixes "BASIC && DEVICE".

Good job devs!

Keep it up!!
[Magisk] digger16309:
Similar, except I'm on A13. I haven't moved off off v13 because it's still passing well for me.
[Magisk] chiteroman:
The choice to switch from prop to json is simple, there is a single header C++ library (nlohmann) that is very easy to implement. Also, I can pass the JSON as a String to Java and read it using the JsonReader class.

With JSON the typing is stricter and less error prone. Not to mention the hassle of making a C++ function to read a prop file... XD.

In my opinion I prefer JSON to prop.

This is the explanation why I decided to switch to JSON.

By the way, is the test version (v1.1) giving you crashes or other problems?

I think the problem with the crashes was my fault for not knowing how to use the Unix file descriptors correctly. 🤣
[Magisk] TraderJack:
I'm not sure if this was meant to address my question or not. I have no issue with JSON format, I'm wondering why the choice to use a custom prop.json needs to be broken out to a separate release that is considered unstable?

Can't there just be one release that honors a custom if there with the understanding that changing it without a reboot may be unstable?
[Magisk] revengineer:
It sounds like the answer is below, i.e., wait for the next magisk release or go with the alpha. I will wait for the release version.

Thanks for the heads-up. You helped me with my current setup combining magisk, shamiko and HMA, which worked great until now. I doubt that there is a user error, so it seems the Bonvoy app developers have outsmarted magisk... at least for now. Looking forward to the next magisk release.
[Magisk] Vision:
For that i write it inside in the pif file, the fingerprint i want and put it directly back in module zip and flash it and click the reboot in the Magisk
[Magisk] sawdoctor:
Tried every version of pif 13 to 13.7 and Google assistant settings is broken. Routines,news, calendar, accounts and more won't open. You get error can't connect to the internet. Tried cleaning cache from all Google related stuff
[Magisk] TraderJack:
That doesn't answer the question.

The following was released:

Release CUSTOM SPOOF · chiteroman/PlayIntegrityFix

DO NOT USE THIS BUILD IF YOU AREN'T A DEVELOPER, ALWAYS USE LATEST STABLE. THIS BUILD IS JUST FOR TESTING PURPOSES. Removed custom resetprop. Fix JSON parsing. Less libs size. Few code improvements.

github.com

which states:

This version has 'pif.json' file which you can edit to spoof in real-time the device to GMS unstable process.

DO NOT REMOVE THIS FILE!

THIS VERSION IS UNSTABLE, MAY CAUSE ISSUES OR CRASHES. IF YOU ARE A NORMAL USER, USE LATEST RELEASE!

That would leave me to believe that 13.7 (and future releases) will not support a pif.json file to customize your fingerprint, but rather you *have* to use the built-in fingerprint unless you want to compile from source.

My several posts above are trying to address this question. Am I wrong? Does 13.7 support a pif.json file for a custom fingerprint? Will it continue to be supported? If so, why not? Why is it not possible to have a single release which supports this file?
[Magisk] Vision:
Yeah, the one answer listen is broke many devices, i don't know why, I'm using 13.3 with pif.prop and work good, i write the pif file back again in module zip and flash it and reboot, and this with real-time the device to GMS unstable process. Maybe cause problems? Because if change it in real-time without reboot is tricky, lot users needed to clear and GMS data and play store to work
[Magisk] HippoMan:
Could it be that each of the two versions is a "test" version whose purpose is to see what works the best?

After all, we in this thread are more or less serving the purpose of beta testers. A version comes out, feedback is generated about its advantages and drawbacks, and then another version comes out which addresses some of the reported issues ... and it then generates similar kinds of feedback itself ... etc. And this process keeps repeating with more versions coming out.

Actually, I think something like this is necessary, because there are a large number of devices and device-specific stock OS's and OS versions and combinations of other utilties such as Magisk, LSPosed, etc. The only way to come up with a utility that is more or less universally useful is to give it a chance to be tested and enhanced among this large set of devices, OS's, utilities, etc.
[Magisk] Vision:
Yeah that's true, the confused is when a version work good for other users and for other not working good, and the owner of a module fix it and after broke and for those who worked before, and after the owner of module back from the beginning
[Magisk] TraderJack:
No, that doesn't really make much sense at all. The design should be (and was) flexible and extensible.

Ideally, the code should have either:

a) a built-in fingerprint

or

b) a supplied pip.json file with a default fingerprint

B is the preferable option as I have discussed since it allows the absence of a pif file to simply use your native fingerprint which is ideal for any type of testing (i.e. simply remove/rename the pif file instead of the entire module).

In both cases a "normal" user doesn't need to do anything except install and go.

However, as we have discussed multiple times already, it probably isn't good for Google to see 10,000 more Pixel 2XL devices suddenly getting through to their API servers. It is in everyone's best interest to be able to supply your own fingerprint if such is desired.

I have no problem with this pif file being JSON and having to have X number of fields. I have no problem with saying modifying this file in real-time may cause issues without a reboot. What I can't understand is why @chiteroman himself agreed this was a good idea, implemented it in for 5-6 versions and then just decided to remove it?

Seems like the perfect solution and I'm just wondering why it is now gone and why it is preferable to have everyone hitting Google with the same fingerprint instead of the alternative of having to compile our own code from source if we want to use a custom pif file.

It's really a simple question and is only awaiting an answer from the one person that can provide it.
[Magisk] Vision:
Exactly this is i write before about is the perfect feature and not all have the same device in the request API serversView attachment 6036904
[Magisk] arda99:
I would suggest to use static builtin prop, with ability to load external .prop file, so anything wrong with external prop it will fallback to default prop as backup. Current versions solely rely on external pif file.

Also I'm not a fan of json as there is no comment in json so we can't do:

# PRODUCT=phone1

# PRODUCT=phone2

PRODUCT=phone
[Magisk] TraderJack:
No, this would be incorrect. According to the documentation on GH, the current version relies SOLELY on built-in props.

This is the problem.
[Magisk] arda99:
I mean all the other 13.x versions with external .prop/.json support. There is no fallback just external pif.

I'm OK with current 13.7 static version as I was able to compile one with my own prop but obviously not for everyone and I don't like this myself.
[Magisk] TraderJack:
As a developer, I would prefer if I released a new version, that all my users went to that new version so that I didn't need to continue to support older ones.

Therefore, the fact that 13.6 still works ok (and it seems to, I'm using it) is sort of irrelevant to the larger question.

I would like to move to 13.7 and 13.8, etc when they are released, but I would also like to use my own fingerprint file.

I'm not sure why we are continuing to debate this when @chiteroman can easily reply in probably 3 sentences why this change was made.
[Magisk] chiteroman:
The problem with previous versions is that it did not handle the data received and sent from the file descriptor correctly, so this led to strange behaviour on some devices. For example, in my test phone sometimes it worked perfectly but when I restarted, the GMS process exploded and did not load the data correctly in the process.

All previous versions, except the pre-release build, have this problem and can be buggy.

The v13 is practically the same as v13.7, the difference is that the latter reads a classes.dex file and v13 has it embedded in the code of the Zygisk libraries.

I'll leave the versions there in the GitHub until Google decides to surprise us (again) and I guess I will delete them and leaves only the good ones.

Oh and about commenting code in JSON, the good thing about nlohmann is that it supports this but I don't have it enabled so it will crash GMS if you comment something in the code, but I can add it in a next update, more info: https://json.nlohmann.me/features/comments/

If I see that the props version works fine and doesn't crash, maybe I'll release it to production.
[Magisk] zgfg:
Commenting with // might work when deserializing, depending on what lib he uses for Json
[Magisk] zgfg:
I tested and couldn't make v3.7 to read the pif.json file. It always uses the built-in spoofs with sailfish

I tested even with syntactically wrong JSON (hunting to see an exception or warning) but didn't find anything about in the logcat, just the built-in sailfish spoofs
[Magisk] TraderJack:
Thanks for that. It could be however you were doing something wrong with the file descriptors as you mentioned earlier?

Far from me to judge your coding ability - just seems like simply reading values from a file should be fairly straightforward. If the issue has anything to do with the ability to read it real-time to constantly refresh on demand, I for one would be happy requiring a reboot to change the values...I just want to be able to specify my own without having to build from source!

So it sounds like the best thing for me to do is run the PROPS version and let you know after a while if it has been stable for me?
[Magisk] TraderJack:
that's right - the 3.7 doesn't support it. Only the PROPS version.

I'll be switching to that and report back if it causes issues.
[Magisk] rodken:
[Off-topic] Isn't that common practice in software development? I suppose that it's not especially important for utilities that are designed to work on a wide variety of devices and operating systems.

I always thought that the process of testing and improvement is essential for developing software that is reliable and user-friendly.

By the same token, I would agree that it may seem like the developers are constantly releasing new versions of said product that are not quite ready for production, this is actually a good thing. It means that he or she is committed to developing a high-quality product that meets the needs of the casual user or newbie.
[Magisk] zgfg:
Of course that the developer cannot test on various platforms and under different conditions himself.

Besides, we must be grateful for what he gives to the community and we should at least test and provide the feedback from our side

But if three versions are released in less than 48 hours then you cannot expect to have reliable feedback from users (each one with a different platform: phone, ROM, Magisk version, configuration of other modules and reporting about detection of root from a zillion of apps around the globe that actually have nothing with the Play Integrity as in the name of the module)

Moreover, nothing cannot be systematically tested when constantly switching back and forth between pif.prop and pif.json, between FIST_API_LEVEL and API_LEVEN, dobby or not, with and without custom resetprop utiluty, etc

In that rushomon, how do you know who is reporting about what, whose issues are related to what, etc

So that is not really a practice in software testing, specially it cannot be when replying on amateur testers
[Magisk] zgfg:
Btw, I downloaded but didn't have time to install v3.6

When I wanted, there was already v3.7. Before I realized that customizable pif.* file was gone, I deleted the downloaded v3.6

So I returned back to v3.5 and just retested to make sure that it works with pif.prop and with which exact version of that file (since of the variations we had)

Now, that is good for me - for my banking app and other apps I use that look for the root and for my G Payments, hence I will stick with that for some time

Plus, I have plans to try to extract a reserve pif.prop configuration(s) from getprop results from a couple of older Huawei phones that I asked a 'retired' XDA fellow to send me
[Magisk] fbirraque:
Just a "feedback"... This module never worked for me with MIUI.eu or even EvolutionX, Magisk 26.4; lsposed 1.9.2

Note: I'm NOT starting a new discussion
[Magisk] fbirraque:
I confirm same on Poco F3 (Alioth); MIUI.eu 14.0.8.0 (REBUILD v2), Magisk 26401, lsposed 1.9.2, Play Integrity 13.7

EDITED: @chiteroman

I would like to thank you very much.

The current PI v13.7 rocks!

Even two Banks apps (PicPay and PagBank) that NEVER worked when rooted now runs flawlessly on Poco F3 (above) and also on Redmi Note 8T (Willow); EvolutionX (Android 13), Magisk Delta 26401, lsposed 1.9.2
[Magisk] TraderJack:
Well it doesn't appear to work at all...

Just flashed it with my custom pif.json which didn't work, so went back to the default pif.json that it comes with.

11-25 20:04:25.240 12700 12700 D PIF/Native: Couldn't load pif.json file in memory
11-25 20:04:25.240 12700 12700 D PIF/Native: Received 'classes.dex' file from socket: 7298 bytes
11-25 20:04:25.240 12700 12700 D PIF/Native: Received 'pif.json' file from socket: 0 bytes
11-25 20:04:25.304 12700 12700 D PIF/Native: get system classloader
11-25 20:04:25.304 12700 12700 D PIF/Native: create class loader
11-25 20:04:25.306 12700 12700 D PIF/Native: load class
11-25 20:04:25.306 12700 12700 D PIF/Native: read json

And it just hangs there while the Play Store PI checker gives me an error.

Has anyone else tested the PROPS version and used it successfully with either the built-in 2XL props or their own?

(and I did reboot just to be sure)
[Magisk] pndwal:
No... I just tried 1.0 and 1.1 on phone this morning (have looked at file contents on tablet only earlier) and have same as you (although 13.7 is fine):

View attachment 6036933

and

View attachment 6036947

... Thanks for reporting/logs... 👍 PW
[Magisk] badabing2003:
Props version 1.1 crashes Google Play Services for me with the bundled json.
[Magisk] arda99:
Tried to fix the PROP-1.1.

Looks like the problem is from r/w the companion pipe multi times? I don't quite understand the zygisk module thing, but to keep it simple, my solution is to pack all data together and read/write only once.

I upload my built and source cpp, either replace the .so inside the prop-v1.1.zip and reflash, or replace it in phone's /data/adb/modules/playintegrityfix/zygisk...or just wait @chiteroman next release.
[Magisk] TraderJack:
Appears to work with my pif.json file. Logcat shows the values being translated and I pass tests.
[Magisk] amk316:
hay @chiteroman

can i make a suggesting , add multiple finger prints to pif.json and chose form them in random or manual matter.
[Magisk] Nergal di Cuthah:
<opinion>Might take longer than the check expects (it takes time (minscule to us but significant to software) to choose random)</opinion>
[Magisk] TraderJack:
This isn't the worst idea, but I do think it is unnecessary and complicates the code.

The idea of using multiple prints is seemingly only beneficial among the entire user base.

By this I mean if there are 10K users you ideally wouldn't want them all using the same print because that might look suspicious to the powers that be. TBH honest we don't entirely know if that's a problem, but it's a working theory.

So the idea is, if you have your own fingerprint to use, then use it. That way you aren't contributing to the 10k users AND if theirs gets blocked, hopefully your personal one continues to work.

There is really no need for an individual user to have to rotate between 2+ working prints. One verified is enough.

The one advantage your idea might have is if the built in prints rotated between several...or chose one of a few at random. This way, with say 3 prints, only 3,333 requests go out for each instead of 10K for one.

I'm not sure that would make a difference as I'm sure even a fraction of the requests are trackable and noticable. I think it might be better to use one main print though and wait until it's blocked before moving to another....try to eke out what we can :)
[Magisk] HippoMan:
Yes, but in this case, what's important is the total clock time (the time "to us"). Using up some extra CPU cycles (the time "to software") for the random number calculation won't affect the over-all performance of the device in any significant way.

And in any case, the random test could be very quick and efficient in terms of CPU time. Just take the millisecond, microsecond, or nanosecond clock time and do a "mod" function on it, where the base of the mod is the number of items to choose from in the list, and then use the result as the index into the list. That would hardly take up more than a relatively small number of CPU cycles.
[Magisk] HippoMan:
That's a good point, and I mostly agree.

However, the random choosing isn't very complicated, as I described above, and if there is only one print in a user's list, that described algorithm would automatically choose it. If anyone wants to stick a few more prints into their list for some reason, the same described algorithm would make a random choice without any code change and without any extra CPU time being expended.
[Magisk] arda99:
If you have your own private prop, there is no need to worry about google blocking so no need for random prop. For a public release with same fingerprint(s) then it makes no difference if it's random or not.
[Magisk] TraderJack:
I'm not concerned with CPU cycles, the added computational power is irrelevant.

I just don't see a reason for this feature as explained above. It adds more room for issues in the code base. It rather a dev focuses on getting the code functions solid before worrying about pieces like this which sound beneficial, but really don't seem to have any major advantage.

And, even when @chiteroman works out all the kinks here I'd rather see him spend time on another necessary tool then just adding feature bloat.

Ultimately it isn't my decision, and I'm open to contradictory views as to why this feature is actually needed (i.e. what problem does it really solve for you as a user). In any event the right place for this is probably a feature request in GitHub.
[Magisk] HippoMan:
I understand.

If the final, released code is open-source, I would probably take a local copy and add that small amount of quite uncomplicated logic to it, so that I personally would have the option of deciding how many prints to randomly choose ... including only one.

The consensus might end up being that such a randomized selection is not worthwhile for general release. If so, I at least would still be able to make use of that logic myself, without my choice affecting anyone else.
[Magisk] TraderJack:
Ofc. But what purpose would it serve? I'm genuinely asking because you are trying to solve a problem that isn't there IMHO.

If you have a prop that works, you only need one. If one of your props doesn't work you wouldn't want it to be selected in a random list.

So how does rotating between more than one working prop benefit you other than an exercise in coding? If their is a scenario I'm not thinking of where this would serve a purpose I'd like to be enlightened. :)