yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] TraderJack:
Ok. I don't have many physical devices to test on (and this isn't something I've been tracking), so I trust your word on this.

But, the point I am trying to make is that there are, in various places online, dumps of ROM files.

In my searching through these dumps of files I often find ROMS which do not have anything other than /vendor/build.prop.

I'm not sure why this is because they look like complete dumps to me. I will note that often if there are multiple Android version dumps of the same device, there is a better chance a /product/build.prop file will exist in the earlier version, but not the later ones.

You might argue that these are bad dumps...and you may be right. However I am stating that I have been able to pull just the /vendor/build.prop from those ROMs where only that file exists and get working prints.

So, I am just letting you (and others searching for working prints) know that it is possible to to get working prints from just the vendor file and through using your version of the script to try and extract them you would miss out on all these prints.

I've modified your file to a form which seems to work for me based on the ideas I mentioned above. I understand that it is not *ideal* to trust only a vendor prop, but when the option is using only that, or having nothing at all to try from I'd prefer the former to get working prints.

I'm really not trying to be obstinate here - I really appreciate your script it has really helped me as a base to try to get what I need. But, my data set isn't perfect and I would rather try to extract prints from 1000 /vendor/build.prop files if that's all I can pull from public dumps then only try to pull from a few which might have all the proper .props files.

I'd rather not distribute any sources, but if you are interested go ahead and PM me and I'll share the dumps I'm talking about. Maybe you can shed light on why so many seem to just have vendor.prop.
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
Are you sure you're looking in the correct "system" folder for build.prop? It may be nested in another subfolder called "system".
[Android Software/Hacking General [Developers Only]] TraderJack:
thanks...I checked a couple of dumps and I think this may be the issue!
[Android Software/Hacking General [Developers Only]] osm0sis:
Yeah you may just be looking at system-as-root dumps, in which case (since the partition is still called system) on the dump sites it'll look like /system/system/build.prop. product can be /product/build.prop or /product/etc/build.prop and vendor is /vendor/build.prop or sometimes /system/vendor/build.prop (if no proper vendor partition but pretending).

Sorry, didn't realize I needed to spell out the entire directory structure of Android 😅
[Android Software/Hacking General [Developers Only]] TraderJack:
...yeah I don't do "on-device" development that often. Thanks for being patient :)

So just to confirm:

system build.prop should take first priority, followed by product, followed by vendor in most cases and only fallback to the next in line if we can't find the needed values?

Also do you know if one of the files exists in one location, it won't exist also in the other. For example if the product one is found in /product/build.prop it won't also exist in /product/etc/build.prop? And if it does, would the 2 files be identical and if not, should one be used over the other?
[Android Software/Hacking General [Developers Only]] osm0sis:
I have seen both and containing different values, but that's bad OEMs. Normally it should all be in one and in etc now.

All the important prop files locations in a list, btw, if anyone needs it:

AnyKernel3/META-INF/com/google/android/update-binary at master · osm0sis/AnyKernel3

AnyKernel, Evolved. Contribute to osm0sis/AnyKernel3 development by creating an account on GitHub.

github.com
[Android Software/Hacking General [Developers Only]] rodken:
The order of precedence for build.prop files is system, product, vendor. However, there may be some exceptions to this rule, and the vendor build.prop file may take precedence over the product build.prop file in some cases where the vendor build.prop file may contain settings for the device's baseband radio, which are more critical than the settings in the product build.prop file.

To sum up, vendor build.prop file might sometimes be the boss but not in most cases.
[Android Software/Hacking General [Developers Only]] HippoMan:
Is there some programmatic way to decide whether vendor build prop should be the boss in those cases?
[Android Software/Hacking General [Developers Only]] rodken:
Actually, there are programmatic ways to determine and/or decide:

-- Hardware Component Identification

-- Configuration Sensitivity Assessment

to name a few.

A more common approach is to utilize hardware abstraction layers not to mention a combination of other programming techniques, hardware-specific considerations, and dynamic decision-making mechanisms.

Maybe even employing device tree overlays (DTBOs) to modify device-specific configs.

If a setting in question is related to the hardware, then the vendor build.prop file is more likely to take precedence, e.g., the radio chip, the GPU, or the touchscreen, but user interface, the notifications, or the battery management, then the product build.prop file is more likely to take precedence. Keeping in mind that there always exceptions to the rule.

If I remembered correctly, vendor build.prop file is specifically designed for the hardware components while the product build.prop file is designed for the software.
[Android Software/Hacking General [Developers Only]] TraderJack:
Thanks. It sounds like for the specific settings we are interested in for this script:

PRODUCT, DEVICE, MANUFACTURER, BRAND, MODEL, FINGERPRINT, SECURITY PATCH, API

That these are not hardware components (even if some describe the main hardware) and it is most likely that the order of precedence you confirm will likely work.

FWIW, while I haven't manually reviewed the hundreds of props I'm processing, the ones I have done I have not yet seen a difference in the value of these settings between the 3 (apart from some being missing).
[Android Software/Hacking General [Developers Only]] osm0sis:
Obligatory cross-post!

My Play Integrity Fix fork is now live with CI, my intended custom.pif.json location and restore fix, fixed a whole lot of badly set up repo/IDE issues, restored the older deleted commit history, and got a release out:

GitHub - osm0sis/PlayIntegrityFork: Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props

Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props - osm0sis/PlayIntegrityFork

github.com

A quick reminder:

Happy hacking! 🤠

Edit

:

Newer release posts:

v4 - https://xdaforums.com/t/tools-zips-...ices-platforms.2239421/page-178#post-89216618

v5 - https://xdaforums.com/t/tools-zips-...ices-platforms.2239421/page-181#post-89242336

v6 - https://xdaforums.com/t/tools-zips-...ices-platforms.2239421/page-183#post-89282013

v7 - https://xdaforums.com/t/tools-zips-...ices-platforms.2239421/page-185#post-89295899

v8 - https://xdaforums.com/t/tools-zips-...ices-platforms.2239421/page-187#post-89390466

v9 - https://xdaforums.com/t/tools-zips-...ices-platforms.2239421/page-191#post-89560095
[Android Software/Hacking General [Developers Only]] immortalwon:
What can we expect from this release? Using our own prints like chiteros?
[Android Software/Hacking General [Developers Only]] osm0sis:
A cleaner run, properly constructed repo/project, only updating when it needs it, etc.

I forked it before he did the crazy ugly merge of his custom and main branches, so mine builds on the PROPS-v2.1 release, hence being v3, but has my intended versions of the fixes (which he effectively undid in his next release), plus I incorporated all the old commit history he'd deleted that I could find for posterity.

The things I mentioned already above are different, and you can view the README, changelog, and commit list for details:

Commits · osm0sis/PlayIntegrityFork

Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props - Commits · osm0sis/PlayIntegrityFork

github.com
[Android Software/Hacking General [Developers Only]] Wolfcity:
Thanks a lot @osm0sis , was waiting for this! I'm about to send you a PM but I'm sure you get enough of them. Maybe in a few days. RL is so precious

Good work!
[Android Software/Hacking General [Developers Only]] more_than_hater:
Spoiler content hidden.

Why am i getting this error when trying to execute pif generator script? Any ideas?

/Upd

Ah, not system-build.prop but build.prop

Nvm, me dumb
[Android Software/Hacking General [Developers Only]] bege10:
I used the TWRP retention module on an A/B device without recovery partition with /e/OS (LineageOS based).

Now I have a different A/B device and the /e/OS zip file contains a recovery.img and TWRP needs to be installed with fastboot flash recovery. So I guess TWRP will not be installed in the boot but the recovery partition. Is there still a way to restore TWRP without the need to flash it again after every OTA update?
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
You can still use the module
[Android Software/Hacking General [Developers Only]] InvisibleKiller:
Mate, i'm confused as to what to do with this. I have downloaded the system build.prop, product build.prop, and vendor build.prop from the stock ROM for my phone but i don't know what to do with them or with this script.

I'm desperate to get this working as i really need to be able to get Google wallet working again.
[Android Software/Hacking General [Developers Only]] sawdoctor:
Don't use your stock phone find an android 8 firmware online and use the build prop from that. Thats your best chance of finding a working fingerprint
[Android Software/Hacking General [Developers Only]] simplepinoi177:
based off of how he said

and going to that link/how-to-explainer...

You can't "...from the stock ROM for my phone" as that will most likely no longer work (especially if it is a mainstream flagship device).

From the link, you need to find those .prop files from a ROM under the tips/considerations/guidelines of section 2 in that link/how-to-explainer.

Basically, there is no longer any simple way of passing Play Integrity (simply installing a module) and, as you are "desperate to get this working" (as I am), you will have to learn some things and/or it will take some time to figure things out & search for the right device to spoof. So be prepared for that (being desperate and all, it can only be assumed you want this figured out quick).

The script he gives (that you quoted) helps automate finding the necessary fields from the .prop files from the stock ROM image of the device you decide to spoof off of (and I believe creates a custom .json file that you will end up using).

Also, it seems badabing2003 has put in automation in his PixelFlasher to supposedly make things much easier to implement.

But I'm just starting to look into all of this so I can't speak much to PixelFlasher and/or the rest of this. I know it will take some time to learn and search, and I can't commit to that much time for a couple of days so....
[Android Software/Hacking General [Developers Only]] Fishawy:
I tried it, and I confirm it's a massive win on two fronts: Time saving, and effort saving.

Instead of running commands, killing processes, reboots, etc, it's only a couple of clicks. I would say it reduced the necessary work to about 25% of what it would've taken otherwise.
[Android Software/Hacking General [Developers Only]] mmbaknnba:
@osm0sis, @badabing2003

Is it possible for you guys to make a SH script to check the Play Integrity (and SafetyNet; I know it's near EOL), then probably merge to the PF? Maybe the issue is with the API's tokens? Or is it really hard to work with it?

I really appreciate any explanation for it because you guys are really capable of lots of things.

Of course, I know about the Play Store built-in checker and other apps; it is just my preference not to install any apps.
[Android Software/Hacking General [Developers Only]] osm0sis:
Yeah possible if someone wrote a jar that polls the PI API, but ultimately the same issue as apps, since Google only offers like 10,000 tokens per day to average apps.
[Android Software/Hacking General [Developers Only]] InsaneNutter:
Out of curiosity are only newer devices affected by recent Play Integrity updates?

My device is pretty old at this point, a OnePlus 5T running Android 13 / LineageOS 20.

However with the old Universal Safteynet Fix plugin, which apparently does not work anymore and a fingerprint of a Pixel device I've used for a few years now I can still pass the MEETS_DEVICE_INTEGRITY / MEETS_BASIC_INTEGRITY checks and use Google Pay.
[Android Software/Hacking General [Developers Only]] osm0sis:
Guess your fingerprint is good. Keep it secret, keep it safe. 😛
[Android Software/Hacking General [Developers Only]] jabennett:
Thanks for this script, definitely a big timesaver. I've discovered a couple of edge cases that might interest you, though:

1. Running it under tsu (vs. su) in Termux slightly mangles the JSON output (no curly braces at beginning and end):

gen_pif_custom.sh: 111: [: json: unexpected operator

gen_pif_custom.sh: 118: [: json: unexpected operator

(This probably isn't even your issue, but I figured you'd like a heads-up in case other users start complaining.)

2. I've found a couple of build.prop files that get parsed incorrectly, if you'd like me to PM them to you to examine. In one case, there's an extra ro.product.model= value, and your script seems to be grabbing the (subjectively) "wrong" one. In both cases, they contain a ro.product.first_api_level= value that goes unrecognized, and no separate vendor build.prop file.

One of those files wasn't actually even called build.prop at all, but prop.default (extracted from an old .img file I had, with Android Image Kitchen). Despite that, it actually contained all the necessary values, but failed to parse as well.

Thanks again!
[Android Software/Hacking General [Developers Only]] osm0sis:
Anything you're extracting with AIK doesn't count since that means it's default.prop/prop.default, boot.img or recovery.img ramdisk, not system build.prop.

Yeah definitely PM me the others though.
[Android Software/Hacking General [Developers Only]] jabennett:
Yeah, before I knew any better, I was able to manually cobble together my own pif.json last week from the values in an AIK-extracted prop.default file, which actually passed PI on my first try and still works. Dumb luck, I guess. 🍀

Okay, there's only one other I've found on a dump site so far, but that exhibited both issues I mentioned (wrong/duplicate model, and unparsed first API value). I'll send that one your way.
[Android Software/Hacking General [Developers Only]] HippoMan:
I went to the OP of this thread to look for the download link for the @osm0sis PlayIntegrityFork, but I couldn't find it there.

I know that I could probably find it via a search through the PIF thread, but I'm wondering: perhaps might the OP of this thread be a good home for the PlayIntegrityFork download link？
[Android Software/Hacking General [Developers Only]] Fishawy:
Last line here and here, but yeah an OP link would be easier.
[Android Software/Hacking General [Developers Only]] HippoMan:
Thank you for the links!
[Android Software/Hacking General [Developers Only]] edd080:
@osm0sis ; sorry for asking maybe the same question; I am also getting this error when trying to save a custom pif;

gen_pif_custom.sh: 118: [: json: unexpected operator

I am trying your script on a Ubuntu machine using Terminal; am I doing something wrong or am I using the wrong build and vendor-build props maybe?

Thanks for your help 👍
[Android Software/Hacking General [Developers Only]] Lord Sithek:
I had the same problem, perhaps the file got broken when copied. Try to re-download
[Android Software/Hacking General [Developers Only]] edd080:
That is what I am doing however it seems any props I try are giving me the same identical error.
[Android Software/Hacking General [Developers Only]] osm0sis:
Of course, it's just too new, so I haven't gotten to it yet.

I didn't really intend it for desktop use... But let me see if I can make it more portable.
[Android Software/Hacking General [Developers Only]] Usama-CW:
GitHub - juleast/GeneratePIF: A simple bash script to generate fingerprints to use with the Play Integrity Fix module.

A simple bash script to generate fingerprints to use with the Play Integrity Fix module. - juleast/GeneratePIF

github.com
[Android Software/Hacking General [Developers Only]] real_milux:
I believe there is a syntax error in lines 111 and 118 where

[ "$FORMAT" == "json" ]

is bash syntax and should be

[ "$FORMAT" = "json" ]

which AFAIK is POSIX syntax, right? ;)

Wondering how the Android shell is not complaining about this.

Anyway, very helpful work @osm0sis, thank you!

Any plans to add "BUILD_ID" and "VNDK_VERSION" to your helper script? The former is kind of obvious, whereas I didn't find the latter on my device at all...
[Android Software/Hacking General [Developers Only]] HippoMan:
I just now tested in bash, and the following both work identically ...

[ "$FORMAT" == "json" ]

[ "$FORMAT" = "json" ]
[Android Software/Hacking General [Developers Only]] osm0sis:
Yeah, Android shells like mksh and ash like ==, but bash, zsh and others generally don't.

I'll fix that and the shebang for more portability, as I was saying. Testing some prints right now though, so I'll get to it later.
[Android Software/Hacking General [Developers Only]] real_milux:
I know. But only the latter is going to work on POSIX shells and is therefore a good choice for portability.

Modifying the shebang to /bin/bash or similar is another possibility to fix it.
[Android Software/Hacking General [Developers Only]] real_milux:
@osm0sis Besides, I have a device that doesn't have a vendor build.prop, but everything typically found there is in the /system/build.prop, it seems.

Therefore, your script exits with error "No first API level found, add vendor-build.prop" on line 88. However, if I just copy that same file and name it vendor-build.prop, it works, since ro.build.version.sdk is found there. 🤷‍♂️

Maybe you want to relax this somehow as well? How about just searching through all available files at all times, for instance?
[Android Software/Hacking General [Developers Only]] osm0sis:
Yep, also in the to-do to accept those values from system build.prop if they exist, which is extremely rare/incorrect, but evidently possible! 😛
[Android Software/Hacking General [Developers Only]] HippoMan:
I'm sorry, but that is incorrect. I've use zsh and bash all over the place for years, and both have no problem with ==. I have bash and zsh shell scripts that are utilized in heavily used production environments that are successfully using == .

It's actually somewhat the opposite. Older, more traditional shells like sh don't know about ==.
[Android Software/Hacking General [Developers Only]] osm0sis:
Ahh, so it's because of the shebang then, or because it was run with sh. Either way, same fix.
[Android Software/Hacking General [Developers Only]] HippoMan:
That indeed seems like it could be the case.
[Android Software/Hacking General [Developers Only]] dcarvil:
It works fine for me on fedora 38 if I run it with "sh gen_pif_custom.sh" instead of "./gen_pif_custom.sh".

Thanks for all your work.
[Android Software/Hacking General [Developers Only]] real_milux:
I actually changed the shebang to "/bin/sh", which on Ubuntu seems to be some sort of POSIX shell, hence the error.

I think basically every shell has implemented the == operator for string comparison, except POSIX shells, because it's not POSIX standard, AFAIK...

Say whaaat? 🤣 Seems your "sh" is actually something other than a classical POSIX shell.
[Android Software/Hacking General [Developers Only]] Lord Sithek:
@osm0sis When I run your script on my phone with only system build.prop file in the directory, I always get the error like in the screenshot attached, even when the first api level is definitely specified in the file. This is the case for example with bullhead build.prop. Am I doing something wrong or it's a different case?
[Android Software/Hacking General [Developers Only]] real_milux:
We have just discussed that, read back a few posts. ;)
[Android Software/Hacking General [Developers Only]] Lord Sithek:
Omg yes, you may not believe but I read messages from last half an hour just after I pushed "Send" button :ROFLMAO:
[Android Software/Hacking General [Developers Only]] osm0sis:
The current instructions say to make an empty vendor-build.prop if the ROM doesn't actually contain one. Pretty sure bullhead does actually have one though.

Edit: Ahah! I think that's the trick! First API Level was added in Android 8, but in 8.0.0 it was in system build.prop, then in 8.1.0 they moved it to vendor build.prop. I'll fix the script likely later today.
[Android Software/Hacking General [Developers Only]] HippoMan:
Question about the code for PlayIntegrityFork:

app/src/main.cpp contains the following code:

14 #define JSON_FILE_PATH "/data/adb/modules/playintegrityfix/pif.json"
15 #define CUSTOM_JSON_FILE_PATH "/data/adb/modules/playintegrityfix/custom.pif.json"
[ ... ]
252 struct stat tmpbuf;
253 if (stat(CUSTOM_JSON_FILE_PATH, &tmpbuf) == 0) {
254 FILE *json = fopen(CUSTOM_JSON_FILE_PATH, "r");
255 else {
256 FILE *json = fopen(JSON_FILE_PATH, "r");
257 }

From this, we can see that if /data/adb/modules/playintegrityfix/custom.pif.json doesn't exist, then the contents of /data/adb/modules/playintegrityfix/pif.json will be used. Does this mean that we can copy our generated json to /data/adb/modules/playintegrityfix/pif.json, and it will still work, as long as no custom.pif.json has been copied to that same directory?

Or is /data/adb/modules/playintegrityfix/pif.json not a reliable place for us to copy our generated json, for some reason?
[Android Software/Hacking General [Developers Only]] osm0sis:
I left that there in case we ever felt like sneaking a print into the zip again, which is also why I have pif.json in the .gitignore and want to leave custom.pif.json as currently named to survive module updates. 😛

Most of my actions are kinda like "what chit should have done", and will be future proofing for as little maintenance as possible; I properly set up libcxx and ShadowHook as submodules, and added proper credit for the module scripts by linking to Displax's USNF commit history for them, for example.
[Android Software/Hacking General [Developers Only]] HippoMan:
I see.

So, in the case of /data/adb/modules/playintegrityfix/pif.json, we could copy our generated json to there if we want, instead of to custom.pif.json in the same directory, correct? ... or to play it extra safe, even to both pif.json and custom.pif.json in that directory.
[Android Software/Hacking General [Developers Only]] osm0sis:
You could, but shouldn't, because it won't survive a module update. custom.pif.json is the correct name for that feature.
[Android Software/Hacking General [Developers Only]] HippoMan:
OK. Got it!
[Android Software/Hacking General [Developers Only]] osm0sis:
Updated my custom pif script!

- make more portable by changing shebang to #!/bin/sh and using = instead of ==

- check in system build.prop for first_api_level first since it was briefly kept there in Android 8.0 before being moved to vendor build.prop in Android 8.1

- take first hit instead of last to work around some bad HTC system build.prop files that contain duplicate model entries but the first is correct

- add instructions to error message for adding vendor-build.prop

It works well in my WSL2 Ubuntu installation now, so hopefully good across other Linux distros.

I'm still mulling over doing a rewrite to require all files up front so the user has to create something for each, empty or not, but I agree it could be an efficient way do do things, since all could be grepped at once.

Edit: And Play Integrity Fork is now added under Other in my OPs here. (y)