yashsingh1/xdaforums huggingface dataset:
[Magisk] BrimoFan123:
This is the point why rotating few fingerprint doesn't make sense but on other hand: if it would be possible to select immediately another fingerprint if the one selected before doesn't work then the benefit here is that we are splitting amount of "known" spoofed fingerprints being seen by Google making the chance they would block "one" suspected fingerprint lower.

Anyway to me it looks like the idea of using own fingerprint is the best.

But I'm not developer or programmer so I have no idea how and from where to get that "working" fingerprint from.

If it would be a matter of taking them from current phone's build.prop like this:

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

API_LEVEL=ro.system.build.version.sdk

then it could be possible to script that into PIF easily, right?

But I see in the discussion here people writing it should be taken from "old" phone so my understanding is that those which are in "current" phone in build.prop are not "good"

As you can see I'm completely amateur :-(
[Magisk] HippoMan:
If indeed using the same print over and over wouldn't trigger any kind of alarm with the Googlefrinchians, then of course it wouldn't be necessary to use multiple randomized prints.

But if we discover anything new about how the Googlefrinchians' current integrity-testing protocols work, or if they change those protocols in the future, and if we then realize that multiple randomized prints could help us, no further coding changes would be necessary, and all I'd need to do is add more prints to my list.

But if indeed we already know everything that is necessary to know about their current protocols, and if we believe that they aren't going to make the kinds of changes that I speculated about, then yes, this will be nothing more than a coding exercise.
[Magisk] awarexda:
It's a funny situation as I see it.

We rely on a handful of people to write the new code in order to pass Device Integrity. If these guys stop, then what?...

Also it seems that the PIF is now used by probably max 1000 users (maybe less) over a zillion Android devices all over the world. Peanuts...

BUT if Google wants to "kill" each and every new PIF, they can just do it as soon as it is published on GitHub....
[Magisk] zgfg:
He uses JSON that he could use JSON utility to easily deserialize from a stream/file

To have a list [], JSON file should look much more complicated, see eg attached export from AdAway with a list of Host Sources and their properties.

And such Json, with a list of configurations will be much more complicated for users to edit in text editor, and prone to error.

You make a syntactical error and the module will fail to read

So better would be to have a round-robin scheme with a number of pif*.json files it will find.in the folder

But if it fails to pass PI, you would have to look to the logcat to find which JSON config was used and it failed (being eg blacklisted by Google in the meantime)

So better thar it reads the single Jsom file and you replace with the other if/when you see it fails - as is
[Magisk] chiteroman:
Well, this seems to me to be too complicated when writing code. But it's another way to do it. 😝
[Magisk] shoey63:
Working out of the box on ROG 3 Omnirom A13.

Can we just edit PIF.JSON to try out other fingerprints?
[Magisk] chiteroman:
Yes, but for the changes to take effect you have to kill the unstable process, you can do it using this command: killall com.google.android.gms.unstable (as root).
[Magisk] BrimoFan123:
I did the following mapping to populate values into pif.prop file from build.prop:

PRODUCT=ro.build.product

DEVICE=ro.product.system.device

MANUFACTURER=ro.product.system.manufacturer

BRAND=ro.product.system.brand

MODEL=ro.product.system.model

FINGERPRINT=ro.system.build.fingerprint

SECURITY_PATCH=ro.build.version.security_patch

FIRST_API_LEVEL=ro.system.build.version.sdk

It doesn't work.

Then I started to check around 20-30 combinations of these values in different fields of pif.prop.

Always getting DEVICE_INTEGRITY red.

Also tried fingerprint that is displayed in Momo which differ to this in ro.system.build.fingerprint. Also doesn't work.

I have no idea where do you guys taking values to used them in pif.prop and getting DEVICE INTEGRITTY green attestation.

Of course each time when I tried different values I ran killall com.google.android.gms.unstable.

All these testing I made in PIF 13.4
[Magisk] pndwal:
Yeah, we need mismatches with Google's prop-based lists...

If anyone wants a bit of clarity on basics of how USNF and forks (inc. PIF) work, please check this post:

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

I just edited it a bit to keep it current... 🤠 PW
[Magisk] chiteroman:
Wrong

PRODUCT -> ro.product.name

DEVICE -> ro.product.device

MANUFACTURER -> ro.product.manufacturer

BRAND -> ro.product.brand

MODEL -> ro.product.model

FINGERPRINT ->
private static String deriveFingerprint() {
String finger = SystemProperties.get("ro.build.fingerprint");
if (TextUtils.isEmpty(finger)) {
finger = getString("ro.product.brand") + '/' +
getString("ro.product.name") + '/' +
getString("ro.product.device") + ':' +
getString("ro.build.version.release") + '/' +
getString("ro.build.id") + '/' +
getString("ro.build.version.incremental") + ':' +
getString("ro.build.type") + '/' +
getString("ro.build.tags");
}
return finger;
}

SECURITY_PATCH -> ro.build.version.security_patch

FIRST_API_LEVEL -> ro.product.first_api_level
[Magisk] pndwal:
Please see both @chiteroman's and my post above... This comment may help too:

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

👀 PW
[Magisk] bycolxxiv:
Sooo I'm using PIF v13.7, LSPosed v1.9.2 and Magisk 26.4.

I will upload a logcat file, but sadly logcat | grep PIF doesn't give any results. So I'm unsure whether the process has actually started correctly...

I'm gonna open an issue later on, maybe it's an easy fix and I'm (once again) just using the tools incorrectly (:
[Magisk] chiteroman:
Using microG ?
[Magisk] bycolxxiv:
Yess, installed the latest release from MicroG systemlessly from https://github.com/FriendlyNeighborhoodShane/MinMicroG_releases/releases

That's MicroG versioon 0.2.28.231657
[Magisk] bycolxxiv:
I know that's not the latest version. I tried it using the MicroG Installer Revived as well. That one delivers MicroG 0.3.0 but still it crashes using PIF.
[Magisk] zgfg:
You have to put real values, not to map labels to the props names

Besides, as mentioned several times over the last weeks, there is no use of putting the same values as in your ROM, unless you can already pass Basic and Device with them.

And if you can pass with those values from your ROM - then what for you need this module
[Magisk] BrimoFan123:
Of course I took the real values. Above was just to show what fields in build.prop I used for getting the values from.

And yes, indeed it doesn't make sense to get the values from my ROM while I'm already rooted and do not pass Device attestation.

But then: how to get these values from not rooted ROM while they are in build.prop file which is not accessible when device is not rooted? Or maybe I'm wrong here? Again: I'm amateur :)
[Magisk] pndwal:
Aside from some code likely needing adjusting in PIF to accommodate microG (or not?), you may need to enable Shamiko in Magisk and configure denylist to hide root from 'microG Services Core', also enable 'Device Registration' and 'Google SafetyNet' in microG settings...

I'm not a microG user, but I understand that these were recent requirements...

👀 PW
[Magisk] badabing2003:
To get a clarification, there were some talk about API_LEVEL (when that was being used in the module) matching the current device's FIRST_API_LEVEL instead of the source (old) device's API_LEVEL

Now that we're setting FIRST_API_LEVEL, we pick the source (what we're spoofing to) or we still pick the target's

Also in the absence of ro.product.name (older devices) it would be ro.build.product right?
[Magisk] zgfg:
adb shell getprop

will read without root, you just need ADB installed on the PC, Developer options and USB ADB debugging enabled on your 'old' phone, and Authorize the PC for ADB for that phone when you connect and execute adb first time
[Magisk] pndwal:
Any value of 32 of less should work... Traditionally we used device value with a cap of 32 (ie. change only for A13+ LV devices...

But setting to match donor prints device shipping level should be fine to... It shouldn't matter much unless Google cross-checks that prop values match, but there is now actually anecdotal evidence that this is occurring...

The rationale behind using device value (except for P7, P8 etc) was that @Displax had it as global spoof originally... Now it's targeted, so I'm guessing any working value may be safe...

FWIW, I like/favour @chiteroman's moves to match all props to donor (mismatched) print as it anticipates cross-checks.

👀 PW
[Magisk] bycolxxiv:
Thanks for the advice!

I've changed the settings and tried once more. Problem is, now I don't even need to enable PIF to cause a microG crash. I think because I installed microG systemlessly as a magisk module shamiko is hiding mandatory resources from microG and that causes microG crashing all over the place...
[Magisk] bycolxxiv:
Another question... What GMS packages are you all using?

I've read about a solution using MagiskGApps Core module, the now dead MagiskHideProps module, Shamiko and PIF. This combination is supposed to work properly with my phone.

That's gonna be my last solution however, I'd rather use microG. But if I install GMS Core sytemlessly can I then hide root from it? Shouldn't it be crashing as well then?
[Magisk] pndwal:
Yeah, you may need to check if anyone with systemless microG has working PI DEVICE_INTEGRITY spoof... I've had no practical experience... I do know that @Displax produced a special build for microG... I don't know much more... All best! PW
[Magisk] pndwal:
As I said, "I'm not a microG user"... Sorry mate! PW
[Magisk] bycolxxiv:
Yeahh I know, I was just curious hat your setup is? I guess youre using magisk and PIF. But are you using official google services or any other custom package like NikGapps? Doesn't have to be microG (:

Don't worry, thanks a lot!
[Magisk] Vision:
In Displax safetynet module have add it separate version for MicroG user. Maybe need something like that

View attachment 6037091
[Magisk] bycolxxiv:
Yeah I tried using it as well, but the behaviour was exactly the same as PIF is showing. MicroG crashes as well...

I'm probably just going to try Magisk Gapps Core and PIF...
[Magisk] Vision:
Oh understand, try it, hope working
[Magisk] bycolxxiv:
Thanks for the support!
[Magisk] osm0sis:
Current device, except when current device > 32, in which case use 32.

I think SN/PI is only supported on devices that were at least updated to have first_api_level (in Oreo, I think?), so should all have ro.product.name.

Check out my script for all possible corresponding prop names you can pull from:

[TOOLS][ZIPS][SCRIPTS] osm0sis' Odds and Ends [Multiple Devices/Platforms]

osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc. General Information In a nutshell, I just wanted a single thread to gather links to some of my other, larger projects, but also serve as a spot I could put some smaller...

xdaforums.com
[Magisk] badabing2003:
Thanks,

I've been using your script, and it was also my understanding that it was current device's First API level, that is why I wanted a clarification if things changed.

And @pndwal hinted here that it was?

In any case, in my tests, whether I used first api of the current device or the donor device, the results are the same. (my current device's first api is 30)

Same with including / not including seculrity patch for devices older than March 2018

It makes no difference, so I'm leaving it there (included)

PS: you might want to generate pif.json instead of pif.prop :)
[Magisk] Vision:
@chiteroman I still use v13.3 on my Xiaomi Poco X3 NFC, not have GMS crash until now. what caused may i wait (i read something about crashes) ?
[Magisk] osm0sis:
Maybe. Undecided about json because it's awful via shell script. We'll see what happens with me poking around the source. Also I'm still not seeing proper support for missing or empty fields now that it's json, which I thought was the whole point. :confused:
[Magisk] Shira129:
Hi! I hope someone can help me please. I just rooted with KernelSU and tried the this fix but it doesn't seem to work for me.. Can I get some help please? I don't really know what to do. Thank You.View attachment 6037130
[Magisk] Vision:
This resetprop in v13.8 beta is good? Because the HuskyDG say revert in latest Kitsune

View attachment 6037136
[Magisk] chiteroman:
[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] chiteroman:
"FIRST_API_LEVEL": null

"FIRST_API_LEVEL": ""

It's not the same, if you check the code, the first will return a nullptr, and the second will return an empty string: https://github.com/chiteroman/PlayI...474e433501cb20/app/src/main/cpp/main.cpp#L170

And: https://github.com/chiteroman/PlayI...8474e433501cb20/app/src/main/cpp/main.cpp#L30
[Magisk] Vision:
Thanks for info, i have Android 10
[Magisk] dosbuddy:
I am also a bit worried about, that many people are using the same fingerprint now.

So I googled some fingerprints and tested them. Finallly I found a Pixel 2 fingerprint (code name walleye) which was working.

Still on PIF 13.3 with pif.prop.

@chiteroman: thank you for the killall-hint (killall com.google.android.gms.unstable) to be executed after each fingerprint modification.
[Magisk] zgfg:
Change one prop with that resetprop and test how it affects on TB Checker, SCheck and similar

See my posts few days ago, it triggered several SU found and similar in 3 or 4 checkers I tested, where otherwise I had everything fully green

Perhaps is ok for Magisk Delta
[Magisk] Vision:
The same v13.3, i write about with same fingerprint

View attachment 6037139
[Magisk] badabing2003:
I understand the reasoning behind using json, it is code friendly (not human), except perhaps when using shell script (unless you use jq).

I just released an update to PixelFlasher that adds additional features around pif.json (changelog).
[Magisk] BrimoFan123:
So this is the story: I locked bootloader in my old phone :)

Then I installed latest available stock Android 10 ROM, logged to my Google account and checked all 3 attestations are green in Play Integrity API Checker.

Then I ran adb shell getprop > props.txt and made pif.prop on my rooted phone with the values taken from props.txt from "old" stock ROM for corresponding properties, among of which there is ro.product.first_api_level with the value 26 so the last line in pif.prop is: FIRST_API_LEVEL=26

Phone rebooted and... DEVICE_INTEGRITY red :-(

I think it is too complicated for me and I won't be able to build my own pif.prop file :-(((
[Magisk] osm0sis:
I'll try again with 13.8 and report back. 🤞

Managed to relatively cleanly restore your old commit history back to pre v10 by the way, for posterity: https://github.com/osm0sis/PlayIntegrityFork/commits/upstream :)
[Magisk] dosbuddy:
@rafal.polska.b

As far as I have understood:

If your bootloader is unlocked, you need a fingerprint which google tolerates.

If you want you own fingerprint (which mustn't be similar to the real device), do it as I did:

This - let's say fake - fingerprint is only visible in the attestation process (com.google.android.gsm.unstable). All other processes get the physical device fingerprint.
[Magisk] Vision:
Sweet, @osm0sis you say try 13.8, (I'm still in v13.3 until @osm0sis, @pndwal, @zgfg say what version work better)
[Magisk] HippoMan:
Is there a version of jq that runs from within Android? I couldn't find it in toybox or busybox, but perhaps I'm missing something.
[Magisk] HippoMan:
PS: oh, never mind. I was able to install jq within termux.
[Magisk] BrimoFan123:
If your bootloader is unlocked, you need a fingerprint which google tolerates - Yes, of course. My daily driver phone is rooted and therefore has bootloader unlocked. My understanding was that I need a fingerprint from another ROM which is stock ROM on the phone with locked bootloader and on which all 3 attestations are green. So I reflashed my old phone with stock Android 10 system and took fingerprint from it but it doesn't work (Device Integrity is red) on my daily driver rooted phone.

From what you have written my understanding that this is expected result. "Working" / tolerated fingerprint on one device will not "work" on another device.

You are also writing you have found some Pixel 2 fingerprint.

1. How did you search it?

2. How Pixel 2 working fingerprint is related to the previous you statement that fingerprint must not be similar to the real device. Isn't Pixel 2 a real device?
[Magisk] HippoMan:
Oh wow! It's great that we now can include executable java code within our json file!!!

:):)

(Just joking. I wanted to inject a bit of humor into this discussion. Well, at least *I* got a much needed laugh out of it. Apologies to the rest of you.)

But seriously, this way of illustrating how to construct the fingerprint is actually quite helpful.
[Magisk] dosbuddy:
@rafal.polska.b

> 1. How did you search it?

just searched the term "release-keys"

> 2. How Pixel 2 working fingerprint is related to the previous you statement that fingerprint must not be similar to the real device. Isn't Pixel 2 a real device?

I meant: not your real device

My device is for example a Xiaomi Poco X3 NFC, and I am now successfull using a Pixel 2 fingerprint here.
[Magisk] Qnorsten:
What is the correct setup to compile the source code for this module? Wanted to look into modifying it myself (even though I might wait until I see what osmosis does with his fork instead).

I appreciate all the work chiteroman has put in, but I like to understand the code myself and this module seem to have one of the most rapid development I have ever seen. The source code I looked into a few days ago seem to have gone through a lot of changes/iterations already.
[Magisk] HippoMan:
I understand how to work with PIF and the json file under Android. However, I find doing actual "data processing" within Android to be rather inconvenient. The keyboard on my device is small for my finger size and I make lots of typing errors when trying to edit text files, run CLI programs inside of Terminal, etc. And I do prefer working with CLI programs and not jumping around from app to app.

Because of this, in my not very ample spare time, I plan to write something in Python that I can run via the command line on my desktop box which, when given a downloaded PIF installation zip file and build prop data stored in another file, will convert the build prop data into a PIF-compliant json file and then install it into a copy of the original PIF installation zip file. Then, I can "adb push" this new zip file to my device and simply install it from within Magisk.

This small utility would provide a subset of the functionality which is already offered in the latest release of PixelFlasher, but it would work on any target device, not just a Pixel.

Once I finish writing this utility, it will take me less than 5 minutes each time I might want to install new build prop data to try with PIF.

Don't hold your breath while waiting for me to have enough time to finish this, but once I do, I will post the python code here.
[Magisk] Vision:
@chiteroman someone looking for you

View attachment 6037173
[Magisk] badabing2003:
Although the name bears Pixel in it, PixelFlasher can be used with any device, it's just a layer of UI over common adb / fastboot commands.

For pif features, connect your device, hit the Magisk button to open the Magisk / modules UI and there you have it, the editing features for pif.

There are few more options under Device menu.
[Magisk] HippoMan:
Oh, that's great to know!

If you're able to get PixelFlasher running on your desktop machine (it turned out to require some back-and-forth between badabing2003 and myself before it was working for me under Ubuntu 20.0.4) this will avoid a lot of the confusion I see here about the actual mechanics of getting the proper build props installed via the json file under PIF.

I might write my own small utility, anyway, but I do recommend PixelFlasher.
[Magisk] zgfg:
For me all those versions worked fine except that I definitely didn't like resetprop in v3.4 (I think it was there)

But I don't need general spoofs as in system.prop/service.sh, so I remove them (together with that resetprop)

Since v3.7 is not configurable and since I deleted the downloaded v3.6 before I even tried it, I'm now on v3.5 (works with pif.prop)
[Magisk] Nergal di Cuthah:
I have 13.6 downloaded. do you want, is it ok for, me to attach it to the thread?
[Magisk] zgfg:
Since the developer usually deletes all but the latest, I think you can upload and give a link or so

Btw, does v3.6 support pif.json
[Magisk] Nergal di Cuthah:
Here you go (btw it's 13 not 3) <3

Idk if it supports pif.json
[Magisk] Vision:
Oh i see, thanks for answer and advice
[Magisk] Lobod:
Behavior of the new beta is quite interesting :D View attachment 6037194
[Magisk] osm0sis:
Tried both. "FIRST_API_LEVEL": "" still triggers hardware backed, and "FIRST_API_LEVEL": null causes crashes. Something I'm missing here? 🤷‍♂️

So do we want to use the API level from the fingerprint device now? I was worried that could have some bad side effects even though it's only spoofed to GMS. Like I know Google Backup has gotten its info messed up from the SN/PI spoofs before.

Plus there are some devices with working prints from Android 7.0, but there was no first API prop on that release (only added later with 8 I believe), and no security prop needed. So what do you advise?

Really glad to see all the random prop log noise fixed at least. 🎉
[Magisk] BillGoss:
What?!

All the builds from 13 on are available to download from his GitHub site.
[Magisk] Nergal di Cuthah:
@zgfg bill's right

Releases · chiteroman/PlayIntegrityFix

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

github.com
[Magisk] osm0sis:
The pre-releases keep getting removed, but yeah, agreed, he hasn't wiped the final releases in a while which is great. 🙂
[Magisk] zgfg:
JSON was first time in Beta v13.3 I think, but then in Stables v13.3 was prop again

API_LEVEL was introduced around that time and later renamed to FIRST_API_LEVEL

So be careful if testing with older versions to adapt the input file
[Magisk] Vision:
Yeah exactly, i have this version with pif.prop

View attachment 6037235
[Magisk] chiteroman:
Should be fixed in latest beta: https://github.com/chiteroman/PlayIntegrityFix/releases/tag/v13.8
[Magisk] rom-g:
Just installed version 13.8 beta with my custom datas inside the Json file.

The data comes from the system.img/build.prop of a stock Android 7.1.1 firmware.

All this works perfectly on my old BQ Aquaris X PRO (Android 8.1) as well as on my more recent moto g54 (running Android 13).

For the moment, I'll stick to this and i hope that the Googlefrinchians will stay well behaved.

:)
[Magisk] arda99:
PI will enforce HARDWARE test on most A8+ fingerprints. think it as a blacklist, any phone with fingerprint in that list must pass with HARDWARE test, so even PIF tricks the phone to do a BASIC test it will still fail. And that's your case.

However some special fingerprints are "tolerated" and pass PI with BASIC, i.e., not in the blacklist. It's either

1. phone has no TEE for hardware test, as many old models before A8.

2. Google forgets to add the fingerprints.