yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
Which is why everyone should find their own, and do NOT publicly post what works for you

Let's avoid attributing motive in the absence of clear indication thereof. Everyone is busy and has their own lives

besides @osm0sis could probably start releasing builds of his fork if he wanted?
[Magisk] TKruzze:
I wasn't attributing motive, just making an observation. I get your point, though.
[Magisk] heathrow1:
I have now tried about 20 different fingerprints which I found in dumps (followed @osm0sis guidelines and use his pif.json script). None of them passed both stages of safetynet.

If I use the pif.json from the latest safetynet module it passes and gpay is working.

Is there any more advice on finding and picking the right dumps?
[Magisk] rseiler:
Finding a fingerprint is not only extremely tedious but is like finding a needle in a haystack of needles. I have no idea how anyone has realistically done it if not drawing from their own device.
[Magisk] majorfigjam:
It's VERY tedious.

I managed it with a 5 year old phone, only after taking some time to fully restore it to stock by downloading an image from the manufacturer, and then relocking the bootloader, to get it "certified" in Play Store.

What I had discovered though was that simply using the props from the downloaded stock rom file did not work for me to pass both basic and device integrity, as the device had updated some properties after it was locked.

Using " adb shell getprop " commands on the locked device gave me the full props, out of which I picked out the necessary elements to create my pif.json to pass both basic and device.

I also had to use v13.9-osmod module, as none of the other versions worked for me.

Your experiences may vary, but thanks to Chiteroman and Osm0sis for their amazing work, and good luck to everyone in their efforts.
[Magisk] bakaekze:
Yes, @chiteroman has removed it
[Magisk] bakaekze:
Why don't you just make your own fork?
[Magisk] arda99:
There're usually multi build.prop files in the system(or a rom dump) and /system/etc/build.prop usually gets the lowest priority and the value is overwritten by other "build.prop".

Check:

https://android.googlesource.com/platform/system/core/+/master/init/property_service.cpp#1243
[Magisk] majorfigjam:
Yup. That's why I needed to have the props from a certified device, which in my case provided the usable values.

Picking values from a rom image is hit and miss, usually miss!
[Magisk] BunnyPig1:
Is the fingerprint based on a personal device or entire model? Let's say I have an old phone, is the fingerprint unique to that phone or is it just the model itself?

I've tried following the thread but I'm getting confused so sorry if this has been answered.

I know that this is a "cat and mouse" situation but if it's based on phone models it seems like time is not our friend.

There can't be that many fingerprints out there to sustain over a long period of time.

I do not mean to be rude in anyway, I'm just trying to catch up on the entire situation.

I am not anywhere near the capability to do something like this on my own so I am very grateful people like you all exist, huge props to you all!
[Magisk] bakaekze:
Neither. Well, it is unique to the phone, but it changes with every rom update. So one phone can have a lot of fingerprints if it had a lot of updates. Also if it had different updates for different regions, that makes even more to choose from.
[Magisk] BunnyPig1:
Hm, maybe it's time to dig out the old phones and check them. I just need to make sure they meet the requirements mentioned in the tutorial. Got some odd ones laying around. Thanks for the answer!
[Magisk] rseiler:
Not always, I guess, since I was checking one of mine earlier and it has had the same fingerprint over the years I've had it. It's the same major version of Android, so maybe it changes with ever major update? In any case, couldn't get even it to work with v2.1 or current, which makes me think I might be missing some detail.
[Magisk] bakaekze:
Not all the devices will work, it would be too easy otherwise. Also try PROPS ver. 2.0 or 2.1, people are reporting issues with the latest build, as in fingerprint worked on 2.1, but not working on 14.0
[Magisk] rseiler:
Yeah, I think the key line in the FAQ is: "Devices launching with Pie (Android 9) or later have a First API Level 28+ and don't seem to work."

That seems to rule out everything in modern times. The one I was trying began with 8.0 but currently has 9.0.
[Magisk] majorfigjam:
From what I've seen in my Oreo stock locked device, the fingerprint is linked to the model of handset, and the version of firmware being used. It's not individual device specific.

For me, the initial build.prop from the image had a "thumbprint" in it. The extracted props has a "fingerprint" which includes that thumbprint, preceded by a (generic) device identifier which is not present in the initial build.prop in an identical format.

Sorry, but if I give details, it may lead to my custom pif.json being blacklisted.
[Magisk] majorfigjam:
Make sure you get one that's passing certification before you bother pulling the props with adb, otherwise it's likely you're wasting your time.
[Magisk] ace2nutzer:
I confirm latest version works as expected with Android 9. (y)
[Magisk] pndwal:
Not sure why we're saying 'banned' people...

Google may 'ban' the use of prints for LV A8+ devices with confirmed working Keymaster implementations and good measurements/signals in keypair data etc... This assumes 'ban' means that print necessarily triggers HARDWARE_BACKED evaluationType enforcement... They simply won't won't 'ban' prints (ie use them for such enforcement) for devices launched with A7 or earlier Android, or for devices with bad Keymaster implementations ("broken TEE" 😬) which naturally fall back to BASIC-only on-device attestation due to errors/exceptions such as countless OnePlus models, as this would break DEVICE_INTEGRITY in stock devices...

Clearly Google is simply cross checking properties to prevent these prints from bypassing enforcement on other devices... Seems to me we just need to figure out which prop(s) are used to ascertain that we don't have say a Nexus 6 device because we must be missing this, and spoof those as well to use these "banned" props again...

Also, if BASIC_INTEGRITY isn't passing I doubt it's an issue with the print... Something else may be wrong with test configuration... Nb. BASIC_INTEGRITY can legitimately pass with an unlocked device and even with a custom ROM... It shouldn't legitimately pass with root however, but with that we can pass with spoofs...

Are you sure of this?... Guess you just haven't found others?...

Well, bypass HARDWARE_BACKED evaluationType enforcement anyway; we don't' "force BASIC" for evaluationType 😬...

And not in SafetyNet... ctsProfileMatch should be passing without that and S/N should show BASIC evaluationType as that API only ever considered model prop for enforcement purposes AFAIK... Nb. You can have BASIC_only evaluationType for S/N, but PI may still be enforcing HARDWARE_BACKED... (And we're talking server end enforcement here; nothing to do with attestation type device is sending; that has always fallen back to 'basic' (ie. basic attestations have been 'forced') if USNF/PIF is loaded/functioning, regardless of any props).

Yup, as I've mentioned, this would anticipate Google doing such easy cross-checks...

Nb. This could equally apply to Patch level and seems it does to other (un-established) props... Eg. For SafetyNet Google started cross-checking that patch level (date) value corresponded to fingerprint from March 2018 for ctsProfileMatch compliance meaning that later devices using later prints needed to comply, and while it's unlikely that this will change at all in deprecated S/N API, Google may well deem devices non-compliant with CTS/VTS for (current) PI API purposes if prints of any age fail to match values in Patch level or who-knows-what other props... Further, Google may be doing such cross-checks today, or add them tomorrow. (And they're unlikely to give us notice or ask our permission; it is, after all, their mobile OS!) 😉

PS, sorry if anyone's already covered any of the above... I'm still pages behind here as I'm pressed for time ATM... 🙃 PW
[Magisk] osm0sis:
I found like 25 within 3 days of there being a working props module available... 😉

And I found a lot that didn't work, by basically methodically bisecting monthly OTA build lists, but that's how I figured out my guidelines. 👍

People seem to be focused on the factory images, but should invest some time in my first suggestion which is using your favorite search engine to look for repos of ROM dumps and build props. Much less time consuming overall.

@pndwal, I'm literally only talking about using the device for fingerprint harvesting, so for that purpose those devices can be considered banned. I was trying to keep it as simple as possible for people. And I was just using the word banned since I was trying to avoid the word blacklist. 🤷‍♂️

I agree with your points but there's no room for that much nuance in a post of this type.
[Magisk] rseiler:
I just found something that has me a bit confused. I'm currently using v2.1 and was quite confident in the pif.json I derived from an old phone. Of course, it didn't work, but it's what TB Checker said that surprised me: it mentions the "Device build fingerprint" (which I'd never even noticed before in that app).

But it's NOT the fingerprint in my pif.json, which seems kinda important relative to my failure (I also threw in a custom.pif.json since I'm unclear on which v2.1 expects). Shouldn't the app show the signature in the file? Maybe it only does when it works? When it doesn't work...it's the phone's normal one? It's hard for me to know not ever having had any success in this.
[Magisk] BROKEN1981:
I don't understand much of how this works.

So if people used a Samsung Galaxy S4, Google would ban everyone who uses that device from Gpay?

Is this what people are doing? Picking a random Android model and hoping that particular model doesn't get mass banned? Because I'm pretty sure people used the OG Pixel and that stopped working. That means people with an OG Pixel can no longer use Gplay? If that is correct, how is Google allowed to get away with that? Some people use a device for 9 years .
[Magisk] majorfigjam:
First, thanks for all your work in refining the module - yours was the one that worked for me.

I too found like 50 fingerprint and prop dumps from a quick search, thanks Reddit, but figured that if I could do it, so could Google techs. So I figured that since my Oreo model wasn't in that list, I should invest time in getting it certified, and using it for my json.
[Magisk] Reza12MQ:
the "device build fingerprint" on that app show actual device fp, not the fp from module/pif.json
[Magisk] arda99:
I don't know what happens when devices are really too old to compatible with hardware backed test, otherwise, by "banning" I assume that google doesn't simply fail it, instead, now it must pass strong integrity test, so there is no effect to real BL locked unrooted devices.
[Magisk] zgfg:
TB Checker is (package name):

krypton.tbsafetychecker

pif.json spoofs only for DroidGuard:

com.google.android.gms.unstable

ALL apps, when attesting Play Integrity test through the DroidGuard. Hence the apps themselves see 'real' fingerprints, only DroidGuard sees spoofed fingerprints

It was similarly asked&answered for Playatore. Playstore also sees real fingerprints (although it also attests through the DroidGuard)

Otherwise, imagine, you spoof now your Samsung A13 to some Asus A10 and Playstore will not allow you to install apps developed for A12 and higher
[Magisk] osm0sis:
Yep, chiteroman just enabled Actions builds, so I'm going to just bring that over to my fork, then we'll have things as I had intended. 👍

My fork will only be updated on a works-for-me™ basis, and that'll be my answer to anyone experiencing issues.

Oh, and I don't give a sh*t about anyone's random banking apps so don't ask. 😉
[Magisk] zgfg:
Yeah, exclude resetprops, maybe completely servise.sh

And add checking $ABI to customize.sh to keep only the single/relevant zygisk so
[Magisk] osm0sis:
Your device that short on space? 😛
[Magisk] zgfg:
No but it's practically a duplicate of service.sh in Shamiko module (with a little different coding style)

And TJW Magisk first loads Shamiko, then PIF (reverse alphabetic order for module IDs), hence it global spoofs from Shamiko service.sh are already applied when it comes to PIF service.sh

Delta, I think, has the same global spoofs built-in

Though, N/A to ppl with no Delta and no Shamiko
[Magisk] majorfigjam:
Just discovered that my 10 year old JB device, now running a custom N rom with unlocked BL can also pass certification!

May have to dig out my Nexus 7 as well.
[Magisk] osm0sis:
Hahaha oh man you're right. That's hilarious, my updates to what HuskyDG provided actually made it even closer to Shamiko's. Great minds, I guess!

I do still want to keep mine in line with what Displax had, for those who don't want to use both Shamiko and PIF, but I'll take a look.
[Magisk] osm0sis:
Feel free to provide actual wording changes I can apply. I'm not seeing any good options in the book above, but yeah, let's wiki my sh*t and we can make it more clear and accurate while keeping it short, simple and understandable.

Better yet, you should also make a companion FAQ.
[Magisk] Cakelicious:
Thank you devs for the super quick responses to Google's changes. They seem to be more aggressive with trying to clamp down these last few weeks. Really appreciate how quick your updates are!!
[Magisk] matrix200200:
I have tried a few pif.jsons on another phone in my posession (an old Xperia XZ1 compact) and the play integrity checker always returns with basic only.

Tried with module version 14.

The device is running Magisk 24.3 with zygisk on LOS 19.1 (Android 12).

The thing is, it also fails with the original json file shipped with the module!

Does it mean, the module is non functional on the device?
[Magisk] frank93:
i’m still trying to keep myself educated about this -- but i’m still confused about the module version that’s considered "best practice" now: 14.0 beta? or one of the osm0sis-builds? 14.0-beta-resetprop? for fooling around with found fingerprints i mean.

or to phrase it differently, what’s the suggested/latest module to use with our current tactics?

(thanks in advance, guys. learning a lot here. i hope.)
[Magisk] pndwal:
Might when I've more time...

🤷‍♂️ I shouldn't try so hard.

Sorry... PW
[Magisk] maxmax0:
Well, time to hit the local small ads, and get an old beaten Android phone for a few bucks, just to have it's prints pulled... 😅
[Magisk] Lu5ck:
The latest KSU implemented unmount for older kernel. However, I am unsure about systemless host as people use that for systemless host too.
[Magisk] zgfg:
Btw, the good, old MHPC module from our old friend Didgeridoohan can help for fishing.

No need to install MHPC (PIF will disable it anyway), just unzip and look into the prints.sh

It's old but we're not talking about the new phones :)

You can find a number of ROMs and read 4 values for our new pif.json: Product, Manufacturer, Fingerprint and Patch.

Fifth, API level can be guessed and experimented with 23-29

It could be tricky to properly fill the remainig three as required for pif.json: Device, Brand and Model (similar to but not exactly the same as Product and Manufacturer, variations apply and you may need to include the phone's codename from Fingerprint)

However, in those times, MHPC spoofed (globally) only the corresponding props for the first four, and that was enough to pass CTS, Basic Profile (predecessor for what we need now, PI Basic and Device).

API level was later added to the equation by Google

Hence I doubt, how important are Device, Brand and Model - could the module ignore/not send them if not defined in pif.json?
[Magisk] Lu5ck:
Is there a non-zygisk solution for play intergrity fix?

I am currently using KSU and I have apps that are unhappy with ZygiskNext + Shamiko.
[Magisk] arda99:
fairly important. MHPC has all these included though.
[Magisk] zgfg:
Displax USNF but not up-to-date.

Chiteroman had but his private updated version
[Magisk] zgfg:
I will need to use lens😁 Or to sit by the PC for this fishing (instead of working with MiX editor on the phone)
[Magisk] Lu5ck:
Pretty sure Displax uses Zygisk as well.
[Magisk] zgfg:
Chiteroman had a (private) version based on the last USNF but with no Zygisk, all spoofs applying globally through service.sh and he mentioned that he used that on his phone with no Zygisk

Appropriate props must be spoofed - reversed mapping than when decoding PIF.json from getprops/build.props
[Magisk] mates21:
I tried to do my fix, but I only have the Basic pass. :( I downloaded the global rom, opened the build.prop file from the system.img file, turned it into pif.json and failed. I understand that the rom must be from a phone that has Android below version 9 by default, and updates to version 8? It may be just the first global rom from a phone with Android 8? I didn't see the API in the build.prop file, but product.sdk = 28. Leave the API and security fields by default? Remove them completely or enter the data from build.prop?
[Magisk] chiteroman:
New beta version released !

Release v14.0 · chiteroman/PlayIntegrityFix

Outdated.

github.com
[Magisk] osm0sis:
You can't target DroidGuard without Zygisk. Lsposed uses Zygisk.
[Magisk] zgfg:
On TG channel they still release LSPosed for Riru - latest V1.9.2-7.0.4.3 yesterday
[Magisk] Vision:
That is good, I don't want Zygisk neither Riru, only want it MagiskHide
[Magisk] matrix200200:
Nevermind

Apparently play integrity tester and the google wallet aren't necessarily using the same stuff.

So, to my greatest surprise an old device I have actually passed google wallet tests with flying colors:)

Oh well.

Perhaps I should let the test device run for a few days and see if the integrity verdict doesn't change in wallet.
[Magisk] pndwal:
And he hinted at the particular devices it was good for... Say-no-more, say-no-more... PW
[Magisk] zgfg:
Btw, use the old MHPC as just mentioned above. It will apply spoofs globally

You just need to take that option from the menu to spoof a particular ROM, and then try various ROMs

Don't ask me further, I used MHPC last time.2+ years ago, but it does contain the spoofs we are talking here

You may need to combine with PIF - remove all else and keep only service.sh and module.prop (you will need resetprops if using that version but I prefer Magisk built-in resetprops instead)

Play yourself, good luck
[Magisk] pndwal:
Integrity check in wallet?... Guess you mean Pay contactless security requirements notice...

That will generally come right after possibly several days if you have DEVICE_INTEGRITY, instantly if you clear data, but it accounts for other security settings as well, eg Pay contactless will be blocked if you've removed lockscreen... PW
[Magisk] matrix200200:
Well, it lasted only half an hour.

Now it says "phone doesn't meet security requirements".

On to search for more fingerprints I guess
[Magisk] LuisNara28:
Should I just install it or do I have to do something else?
[Magisk] xcl1pse:
Just use this if you want PIF but without zygisk, flash in recovery. It will be the same like using MPHC. Need edit .conf to your fps tho
[Magisk] osm0sis:
Nice, I totally forgot about that project. 🤩

It's basically Lineage's in-house solution. Not sure if it only targets DroidGuard however.
[Magisk] Wolfcity:
Seems that this release has an empty PIF.json, so it won't work until you fill in a working fingerprint (you'll have to find on your own)
[Magisk] niko26:
Thx. There is so much information in this thread. Hard to keep up.

So... if we use a fingerprint of one of the devices which are popular and have a big number of users - do you think Google will really ban that fingerprint risking to lock out the genuine users of those devices?
[Magisk] osm0sis:
No, they don't. They just block us from using it on a different device. That's all this is, there's no risk to users of the actual locked devices of losing Play Integrity.
[Magisk] V0latyle:
As @pndwal pointed out before, this is unlikely. What they are most likely doing is banning mismatched prints, possibly using other props. For example if your device is currently running Android 13, it should support hardware backed attestation, so if PI sees a print that triggers basic fallback, that's a mismatch.

We don't actually know what Google is doing under the hood. What we do know is that prints that we used previously don't work anymore for our purposes. It's a cat and mouse game...
[Magisk] niko26:
Ahhh! Thanks for clearing that up.
[Magisk] xcl1pse:
It replace entire props like using MPHC, just without magisk 😂 Tried on Lineage 20 and it still works
[Magisk] wilsonhlacerda:
This is an updated fork, with a good readme and lots of FP already:

https://github.com/althafvly/ih8sn

As far as I know it spoofs system wide, not droidguard only.

@osm0sis @pndwal @chiteroman also may like to take a look on it.
[Magisk] niko26:
Thx, I just found the post from @pndwal .

I guess I will change to paying with my Fitbit Charge 5 watch. Less hassle. :(
[Magisk] osm0sis:
Interesting... They recently added Build ID, I wonder if that is part of what Google's checking against on fingerprints that get blocked for spoofed use.
[Magisk] xcl1pse:
Chiteroman maybe already using it...
[Magisk] V0latyle:
Yeah, without knowing exactly how they're defeating previous spoofs it's a "wait and see" game. I'm still good on 13.9 but I'm not going to publicly state what device I'm using it on
[Magisk] HippoMan:
If avoiding the term "banned" here is actually important, can we at least agree on another term containing fewer words than the quoted phrase above that we could use here as an alternative to that phrase?

"rejects"

"refuses"?

"prevents"?

"blocks"?

"disallows"?

"has deprecated"?
[Magisk] V0latyle:
Maybe "defeated spoof" like I said?
[Magisk] osm0sis:
spoof-proof? 😆
[Magisk] chiteroman:
Banned v13.9 fingerprint :(
[Magisk] awarexda:
Dead again - time to carry money and credit card on me.... :cry:
[Magisk] V0latyle:
Yep
[Magisk] awarexda:
So the quest now is to find a working fingerprint (which is time consuming since we must reboot every single time) and keep it secret! Then fingers crossed Google won't ban it. OMG this seems the end of this magical era.
[Magisk] Gilg@mesh:
yup 13.9 banned...

btw, **** YOU! Google 🤬
[Magisk] HippoMan:
IMO that is the better approach by far.

I personally avoid mobile device banking and payment apps like the plague.

Using the phone as a contactless payment method is *supposed* to be a convenience. However, given how much craziness we have to go through to try to enable that on modded devices, it is hugely less convenient than simply using a wallet containing money and bank cards.
[Magisk] xcl1pse:
No, it only applied on > 5.9. You need manually patch the kernel itself if your kernel version is lower
[Magisk] dosbuddy:
I am now on PIF v13.8 beta with my custom pif.json fingerprint.

Still working.

@Vision: before I was for a long time on 13.3. But logcat says here first_api_level ist not set.
[Magisk] chiteroman:
v14.0 released ! Good luck...

Release v14.0 · chiteroman/PlayIntegrityFix

Outdated.

github.com
[Magisk] Homeboy76:
You don't have to to fix anything, Google fixed the

Strong Integrity

bug exploit. So, you will only pass Meets_Device_Integrity and Meets_Basic_Integrity.
[Magisk] strayh_:
I still have an app that doesn't work yet, when I enter it it exits immediately
[Magisk] zgfg:
It maybe looks for Strong Integrity but MAYBE NOT but for various other signs of rooting/modding that are not related to Play Integrity and thus not to this module

Search for your particular app how the others fixed

App must be in DenyList (MagiskHide, Unmount modules - depending on your fork of Magisk)

Remove or rename TWRP folder, hide Magisk app, search for HMA instructions and try with that, try with USB debugging disabled, etc

Between the tests, wipe Data for that app - some apps remember that they previously found root

There are tons of similar posts around in this and other related threads