yashsingh1/xdaforums huggingface dataset:
[Magisk] simplepinoi177:
From a personal correspondence, but after permission opted to include it in this thread so that it might display to anyone not to hesitate and feel free/welcome to inquire here/to-me, might be helpful/supplemental here, and/or maybe even be clarified or made clearer by others...

I'm unsure how the more experienced experts go about it, but the way I went about it was looking at "SECURITY_PATCH" date (or observing other dates maybe; considering the context of the field) being after 2016 and preferably before late 2018 (or most likely lowering FIRST_API_LEVEL will be required). Oreo is 2018-ish...

You will not brick your phone. That's because, as you may have noticed, we modify a file called pif.json; and not a build.prop...! That's because PIF merely "spoofs" the values inserted in the pif.json, it doesn't actually change/modify your build.prop in any way (as it does in MHPC, if you know of that module). As such, there is no risk of bricking, because you're not actually modifying any real part of your device, just that you sort-of camouflage certain fields/values of your device to certain apps/services.

It is the same reason why Google banning a certain device fingerprint doesn't actually ban ALL of those devices that aren't being spoofed or have locked bootloaders -- because it can be figured that the device isn't changed at a core level.

There are now multiple methods working in various degrees. I wrote this guide when there was none but this manual way. I can really only speak to that and/or this guide is more meant for that than all the ever newly released & developed methods going around now. I know @zgfg wrote a script and does this practice, but I'm unsure if he ever published it; he may be willing to share it though. I might have read it on Telegram, but I can't recall exactly nor speak to it.
[Magisk] TPelangi:
thanks for tutorial guys, got fourteen working print in 2 hours 😉

I use v14 before, then i move my all print to fork v4 from osm0sis.

And yes all my print still working good 👍
[Magisk] endermaster139:
Just checking, once you have MEETS_BASIC_INTEGRITY, you only need a good pif.json (and restart gms) to get MEETS_DEVICE_INTEGRITY? I've been trying fingerprints all day and I'm worried I've got something wrong with e.g. Magisk DenyList.

Edit: I tried a different brand and the first pif.json I made worked when none of the 2017-2018 Motorola phones on API level 26 or 27 did.
[Magisk] HippoMan:
Magisk DenyList and Googlefrinchian integrity checking have nothing to do with each other.

There must be some other problem.
[Magisk] leAndroid91:
Hi guys,

since chiteroman released a last new version today with a working PIF i tried to create my own using an old S21 FE.

I reactivated the device, it's 100% stock and not rooted etc.

Google Pay is working.

So i ran adb shell getprop to collect the required keys.

I found everything except for FORCE_BASIC_ATTESTATION.

However, device integrity in TB checker is failing every time for all those PIF files:

{
"PRODUCT": "",
"DEVICE": "",
"MANUFACTURER": "",
"BRAND": "",
"MODEL": "",
"FINGERPRINT": ""
}

{
"PRODUCT": "",
"DEVICE": "",
"MANUFACTURER": "",
"BRAND": "",
"MODEL": "",
"FINGERPRINT": "",
"SECURITY_PATCH": ""
}

{
"PRODUCT": "",
"DEVICE": "",
"MANUFACTURER": "",
"BRAND": "",
"MODEL": "",
"FINGERPRINT": "",
"SECURITY_PATCH": "",
"FIRST_API_LEVEL": 30
}

{
"PRODUCT": "",
"DEVICE": "",
"MANUFACTURER": "",
"BRAND": "",
"MODEL": "",
"FINGERPRINT": "",
"SECURITY_PATCH": "",
"FIRST_API_LEVEL": 30,
"FORCE_BASIC_ATTESTATION": true
}

I removed the values for obvious reasons ;)

According to this guide i used

FINGERPRINT = ro.system.build.fingerprint

PRODUCT = ro.product.system.name

DEVICE = ro.product.system.device

MANUFACTURER = ro.product.system.manufacturer

BRAND = ro.product.system.brand

MODEL = ro.product.system.model

SECURITY_PATCH = ro.build.version.security_patch and ro.vendor.build.security_patch have the same value

FIRST_API_LEVEL = ro.board.first_api_level and ro.product.first_api_level have the same value

For ATTESTATION the only one i could find was ro.product.device_for_attestation

Do you have an idea what i'm doing wrong?
[Magisk] CZ.Kostra:
Take the test in the Yasnac app. Evaluation type is BASIC or HARDWARE_BACKED?
[Magisk] leAndroid91:
Did all tests again with YASNAC but the result is the same unfortunately.

Evaluation is basic.

Basic integrity: Pass
CTS profile match: Fail
Evaluation type: BASIC
[Magisk] CZ.Kostra:
Evaluation type BASIC is fine. FP is bad or banned. You have to find another one.
[Magisk] leAndroid91:
Are you sure the FP is banned?

On the device where I got it from GPay is working fine
[Magisk] DOUGHBOY126:
its ok u talk to much bro XD your body release dopamine when you talk about something you're passionate about. Dopamine is a neurotransmitter associated with pleasure and reward. When you engage in activities or discussions that bring you joy, excitement, or satisfaction ... and thanks for guidence its not really any structed ways of learning on the topic it was easier learning to write code for me
[Magisk] CZ.Kostra:
Google can detect if the device is modified or not. That's why everything works on an unmodified device (it has a locked Bootloader).
[Magisk] leAndroid91:
ah ok :( and i assume relocking the bootloader after unlocking it and rooting the phone doesn't help..?
[Magisk] CZ.Kostra:
Yes, but ATTENTION! You can only lock the Bootloader to stock ROM and the device will be wiped!
[Magisk] CZ.Kostra:
There are plenty of working FPs on the internet. Use Google search: Android ROM dumps
[Magisk] simplepinoi177:
I'm curious as osm0sis stated

so I can't help but wonder/think that there were/are some values that aren't included or incorrect because you're not rooted. But @leAndroid91 you seem pretty confident that you have retrieved all but the FORCE_BASIC_ATTESTATION.

In any case, it looks like the FORCE_BASIC_ATTESTATION is a new field that chiteroman is now suddenly (without much explanation it seems from the main PIF thread) inputting in the hopes of helping things pass -- so I don't believe it's something you'll see in a build.prop.

Also, like I mentioned in my own personal situation (I spoke about it in Section 3.1.1), when chiteroman suddenly included the inclusion of BUILD_ID & VNDK_VERSION for his DEV1 branch, my working fingerprint didn't pass any longer. But once I removed those fields from my pif.json and moved back to osm0sis' Play Integrity Fork, it passed. So you might want to consider cutting down to the 8 fields you listed before.

Also, you seem to be going very manual about it....if you are using Pixel Flasher or osm0sis' script, they should pull all of those values for you that you wouldn't need to manually search for it and/or pull it from the correct field when there seems to be two fields with the same keyword.

One recent thing I found out about Pixel Flasher is badabing2003 included the capability of including multiple/all the build.prop files in the ROM firmware image file so that his script will actually go through all the various build.prop values among all the different folder locations (vendor, system, product, etc.), in case as osm0sis mentioned certain fields lie in another build.prop.

The newest 15.1 version of PIF includes an embedded working fingerprint (actually, it's the old 14.6 fingerprint, it's just been unbanned after being just temporarily banned by Google). That is probably the reason why GPay is working fine -- under normal circumstances, the FP you were trying/testing probably wouldn't pass and succeed with the non-embedded versions of PIF and GPay wouldn't be working fine.

Also, I learned this along the way, but apparently when one leaves a field "null" or empty, it just defaults to whatever the device's value is and/or the default value of the PIF version -- which may be the reason why you could still pass even though certain fields are empty or not included, but if/when you try to test your own fingerprint on another version it doesn't pass/seems-banned; the default was taking care of making it seem as if it were passing...

Yes, it doesn't matter whether or not you get a fingerprint that is stock, unrooted, bootloader unlocked, or whatever -- if you look at the data/values in the fields we're pulling, nothing indicates whether the device is rooted or unlocked bootloader or anything like that. It literally is just identifying data for Google's servers to match up against; like a "fingerprint" (hence why it's being called that).
[Magisk] leAndroid91:
The response of adb shell getprop looks like that for me on my S21:

[ro.product.brand]: [samsung]

that's the reason why the process looks manual.

Since my S21 isn't rooted or anything i don't know if the pixel tool or the script will work but it might be worth testing (y)
[Magisk] badabing2003:
If by Pixel tool you mean PixelFlasher,

Check under Device menu

Also try playing with the Reprocess button in the Pif manager.

Tooltip on most widgets tell you what they do.
[Magisk] sawdoctor:
Does the s21 support fastboot? Didn't think it did and pixelflasher (if that's what your referring to) needs fastboot
[Magisk] leAndroid91:
Device Info, Pif print and Props as Json are not working on my stock S21, just nothing happening when clicking on them.

Dump Screen XML is working.
[Magisk] badabing2003:
If you submit a support file I'll take a look.
[Magisk] badabing2003:
Actually PixelFlasher works in both modes to get device properties, needles to say, different props are exposed in different modes.

But right Samsung does not support fastboot.
[Magisk] simplepinoi177:
my question is can PF do all that adb required stuff on an unrooted device?
[Magisk] badabing2003:
Of course it can.

It does what is achievable without root if the device is not rooted.

And getting props codes not require root.
[Magisk] Nergal di Cuthah:
I renew calls to make this sticky
[Magisk] andrewff2:
Can someone help, i generated my custom PIF but even so when i go in the playstore and do an integrity test, it shows de "original" PIF, even after i clean the data/cache (folowing osmosis PlayIntegrityFork)

Clear Google Wallet cache

Clear Google Play Store cache and data

Clear Google Play Services (com.google.android.gms) cache and data (Optionally skip clearing data and wait some time, ~24h, for it to resolve on its own)

Is there something more that i should do?
[Magisk] simplepinoi177:
I would delete the pif.json file, reboot, check integrity and confirm you aren't using/passing the "original PIF" by only passing "MEETS_BASIC_INTEGRITY" or none of the 3; i.e. 0/3 (if you are not and still passing "original PIF", manually go to /data/adb/modules/playintegrityfix/ and manually delete the custom.pif.json file and/or any other pif.json [there shouldn't be any other, but the main branch of PIF has 2]), then create/implement a custom.pif.json (if you are following my guide, the best method is through Pixel Flasher).

Or, on second read, you might be mistaken and meant your original device's build.prop instead when saying "original PIF"...? Just to clarify, when most users say PIF or custom PIF, they mean the pif.json that holds the custom fingerprint from a "donor build.prop" they've found & searched (through script or otherwise) and mistakenly attribute it as their build.prop -- so it's understandable that that could easily be miscontrued....
[Magisk] andrewff2:
Yeah that's right i'm using the Pixelflasher generated a custom PIF and when i try to test the integrity in the playstore (after i put it in developer mode) it shows my "original phone" it's fingerpring and so on and on.. but not the spoofed one (i think this is better way of telling what is going on)

When i use the "Play Integrity API Checker" it passes device and basic but not strong.... (should i go and look for another build.prop??)

And this is the logcat...

01-02 14:37:18.736 7394 25003 D PIF/Java: DroidGuard call certificate chain! Throw exception.

01-02 14:37:18.844 7394 25003 D PIF/Native: [ro.surface_flinger.has_wide_color_display] -> true

01-02 14:37:18.844 7394 25003 D PIF/Native: [ro.surface_flinger.has_HDR_display] -> true

01-02 14:37:18.853 7394 25003 D PIF/Native: [ro.boot.flash.locked] -> 1

01-02 14:37:18.853 7394 25003 D PIF/Native: [ro.boot.vbmeta.device_state] -> locked

01-02 14:37:18.854 7394 25003 D PIF/Native: [ro.secure] -> 1

01-02 14:37:18.854 7394 25003 D PIF/Native: [ro.debuggable] -> 0

01-02 14:37:18.854 7394 25003 D PIF/Native: [sys.usb.state] -> none

01-02 14:37:18.877 7394 25003 D PIF/Java: DroidGuard call certificate chain! Throw exception.

01-02 14:37:18.882 7394 25003 D PIF/Native: [ro.board.first_api_level] -> 24

01-02 14:37:18.882 7394 25003 D PIF/Native: [ro.vendor.api_level] -> 24

01-02 14:37:18.952 7394 25003 D PIF/Native: [ro.boot.hardware.revision] -> 15.19.0

01-02 14:37:18.987 7394 25003 D PIF/Native: [ro.boot.verifiedbootstate] -> green

01-02 14:37:18.988 7394 25003 D PIF/Native: [ro.zygote] -> zygote64
[Magisk] simplepinoi177:
This is normal. Mine shows my device & device fingerprint, not the spoofed one.

As long as you are passing DEVICE & BASIC, you are set, and I don't believe there's anything you need to worry about (I mean, I think that's the whole point of this all -- once set and properly passing, to not worry about things not working anymore)....

No device with an unlocked bootloader is going to pass STRONG -- but there is an infinitesimal amount of apps that require that to be passed to work; there is too many devices that wouldn't even on a locked bootloader (because they are old devices).

Finding another fingerprint will never yield you passing STRONG.

I think you are good & set!
[Magisk] Hybrid Divide:
Hoooo man, this is lot to take in.

Thanks for compiling all this information, but I'm still kinda overwhelmed.

And I'm not new to this stuff! lol

I'll figure it all out in time, I think!
[Magisk] simplepinoi177:
I know exactly what you mean...hence my line "i'm proficient, but even this went over my head". I mean, that's exactly how I felt when reading up on osm0sis' post and starting out from the very bottom; so I vowed to myself if I figure it out, I would try to help others who are/were in my frame of mind.

Sorry it is a lot to take in -- that's why i kinda cheated and put everything in spoilers (as to not initially overwhelm and immediately turn off), but to speak on everything in a plain non-Android-technical way makes it not-concise, and with just the way I go about speaking makes it even worse. My apologies. Hopefully I at least explain it plain/understandably enough. But if you have any question or in need of any guidance, big or small, don't hesitate to feel free to bring it here.
[Magisk] Hybrid Divide:
Just one question, really. And I admit I haven't read everything yet. (Can't right now, anyway. I'm at work).

Are we able to actually make our own unique fingerprints? Or are we just stuck searching for ones out there?

I'm using a OnePlus Nord N30 5G with a rooted stock rom, but would that answer be any different if I was running LineageOS or something? Thanks.
[Magisk] Nergal di Cuthah:
You have to farm the print from old device. the print needs to be a real device, because google has all devices in its database, a wholey made-up device would not be in their records.

The print should represent a started oreo device though some have had luck with newer
[Magisk] Hybrid Divide:
It has to have shipped with Oreo, though? So like an old LG V20 that shipped with Nougat would be too old?
[Magisk] Nergal di Cuthah:
You can try Nougat i think it just has to be one that had an oreo rom at some point (i think)

Edit: yes my fingerprint started its life as Nougat so that may work
[Magisk] Hybrid Divide:
Awesome. I have an old V20 floating around. So I'll try working with that. Thank you.
[Magisk] simplepinoi177:
@Nergal di Cuthah is correct on both counts.

But to directly answer the last question, as I understand it, no, it wouldn't be any different running a custom ROM (but then again, thinking about it, the BUILD_ID and SECURITY_PATCH might be different on a custom ROM, so maybe? but I haven't heard of such thing)
[Magisk] simplepinoi177:
No problem! That's actually covered in Section 1.1.3 (if it helpful for you to know directly where)...
[Magisk] Hybrid Divide:
Now, I think the V20 is running a modified stock rom. Is THAT a problem for getting the fingerprint?
[Magisk] simplepinoi177:
I'm not sure....I don't run custom/modified ROMs so I wouldn't personally know, but I haven't come across anyone stating an issue. I mean, at worse, it doesn't work 🤷‍♂️ and you move on. And/or, if you are willing, you flash it back to stock and retrieve it at that point...
[Magisk] Hybrid Divide:
Good point. Thanks!
[Magisk] trevtdogg:
I don't think there's any huge advantage in using the build.prop file from a device you have physical access to, versus finding build.prop files online.

there's no guarantee that any particular model will work, so it's all trial and error anyway.

I think it's easiest to just search online
[Magisk] V0latyle:
Yeah. Even better if you do your research. Working prints tend to be in a very specific range: devices that launched with Android 5/API 21 to Android 7.1/API 25, provided they were updated to at least Android 8.0
[Magisk] simplepinoi177:
All true, but that got me curious to look at the specs, and @Hybrid Divide 's LG V20 does seem to be in the right date range, I imagine it's Android 6 so the FIRST_API_LEVEL should actually fall in that specific range...
[Magisk] trevtdogg:
the main advantage would be if you can find a passing build.prop file for a device locally that has not yet been shared online.

that way, you can be pretty confident that it is unlikely for many other people to be using the same print as you.

but i'd suggest people do that after they have found a working print online, at least that way they know they are doing it correctly before they spend the extra time involved in extracting the build.prop from a device locally (that may not even pass).
[Magisk] simplepinoi177:
great advice! Goes in line with what badabing2003 directs as first loading up the xiaomi.eu fingerprint first to confirm the setup is set up.

and I think the only reason why mine hasn't been banana'd yet is because i found mine extracted that wasn't in a repo (and I was just very lucky) -- there are reports of members having their banana'd when they've found theirs weeks after mine...!

But god is it just so much more tedious -- the downloading time, then the disk space because most of firmware images are like 3GB (so extracted is a double of that and a bit more), and if it is parsed and needs to be combined then another 1GB. But it just seems so promising!
[Magisk] Umgak:
I ended up downloading 100GB of ROM builds (58 total) for a candidate phone and just writing a script to dump them all quickly so I could do other things. Unfortunately any such script ends up necessarily being format-specific since they can be in system.new.dat format, .img format, or payload.bin format, etc. But looking through tons of different ROM versions gives you a very wide net - keep in mind the 'banana' is per-fingerprint, meaning it's per-ROM version.

Perhaps the extra tedium could be an extra barrier to others jumping on the same print.
[Magisk] simplepinoi177:
I wonder if that's why....but then again, I have the same fingerprint on my wife's Pixel 7 Pro and our two Pixel Watch 2's...so it's on at least 4 different devices...dunno if that means anything or not...

But I doubt/it doesn't seem that my device's fingerprint is one that other users are even close to considering, that coupled with the fact that it's not in any repos....

Yes. This is something good to keep in mind. I think I'll modify the OP to emphasize it -- that one fingerprint could be banned, but the same device on the same AndroidOS version might/could still pass as long as it's not the same exact ROM version.
[Magisk] Umgak:
Exactly. I have two sequentially-released builds in all of those dumps. One of them was released in December 2018, and works perfectly fine. The next one, released January 2019, fails DEVICE for seemingly no reason. It's worth checking EVERY build that was released for a phone - including pre-Oreo builds, stable builds, beta builds, everything. I didn't notice any major correlations between dates, android versions, or anything really for which ones get strict enforcement (and thus fail DEVICE) and which ones are usable.

EDIT: There was, actually, one major correlation I did see.

If the device you're spoofing has Open Beta builds, they're probably a goldmine, as they had only a 3.4% banrate from what I've tested (anecdotal, low sample size, grain of salt, yadda yadda).
[Magisk] simplepinoi177:
Yeah....that's why, if time permitted, I really wanted to look into OTA's as well -- as those could be particularly interesting in the data value sets it might hold and it(the fingerprint) might be fairly unique enough to really go under Google's radar...
[Magisk] badabing2003:
I think OTA and factory for the same release would produce the same results.

The details are the same, just the packaging is different.
[Magisk] simplepinoi177:
Thank you for info! That satisfies my curiosity on the subject....

So now I know I'll only go to the OTA if I can't find a factory firmware image -- though it seems getting .prop files are a different thing for OTA images (rightly so, it's just updating existing aspects).
[Magisk] badabing2003:
Getting them out of OTA is a little harder that from factory image

From factory image, 7zip or similar tool should suffice, but for OTA you would also need payload dumper.

So if you're hunting use factory, it's easier.

On the other hand you might have more OTA files already downloaded and handy to process.
[Magisk] Umgak:
Also when searching around XDA I wasn't able to find very many OTAs whereas full system zips were pretty common for the devices I was looking at. Might depend on device, I dunno. OnePlus has always provided full system zips for most versions.

Factory images may also require additional processing - even some full system builds still have everything in payload.bin (requiring payload-dumper) or system.new.dat (sdat2img). Then once you've extracted the system.img from those binary formats, you have to extract it again in 7-zip to get the prop files.
[Magisk] simplepinoi177:
So, I've followed your advice on getting the init_boot.img from a Google Pixel factory image using payload dumper (I even speak about it in OP), but the one other OTA I was able to get my hands on didn't seem that payload dumper may apply (I think it was all in a .dat file or something; I wasn't really looking into unless I got desperate and luckily I found a fingerprint before it got to that point). Do you know if payload dumper will work on most other OTA's from other OEMs?

Thanks for this supplemental info -- it's good to keep in mind; especially the sdat2img (I think I got stuck at this point, as mentioned above). It does seem almost intuitive that you keep "digging"/processing until you get down layers and see a system.img.
[Magisk] simplepinoi177:
Sorry to hear your V20 fingerprint didn't end up working....

VNDK_VERSION will automatically be included if it's found in any .prop files, but as I understand it, it's fairly rare when present.

you should manually change that 30 to 25; that might help. Just wanted to confirm your steps/method, how did you retrieve your V20 build.prop values?
[Magisk] Hybrid Divide:
I get it in System/build.prop via the root file explorer mode of FX. (My file manager of choice)