yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] Wolfcity:
I used your first script directly on my device with Mixplorer which worked well. The updated script throws out an error with the same build.props and vendor-build.props that are fine using your first one (screenshots attached).

If you need any logs let me know. And thanks for keeping your great work up!
[Android Software/Hacking General [Developers Only]] osm0sis:
It's the spaces in your subdirectory. The old one has the same behavior, you just never moved it. 😛
[Android Software/Hacking General [Developers Only]] Wolfcity:
Definitely! So little time, so much to learn.🙄

Working now,thanks.
[Android Software/Hacking General [Developers Only]] Wolfcity:
So it was good to ask here, found some new FP's (after removing the space in the subdirectory). Thanks for your continuing and friendly assistance.🤘
[Android Software/Hacking General [Developers Only]] tom1807:
getprop | sed 's%\[\(.*\)\]: \[\(.*\)\]%\1=\2%g' > build.prop

I found that I have an old Nokia 6.1 Plus, unrooted and to my knowledge you won't find a dump of the ROM.

So I thought, maybe a good candidate to get the build prop and was running the above command

Error message: "can't create build.prop: Read-only file system".

How can I adjust the above code, that the build.prop is written to a writable area in the mobile, like for example Download.

Or maybe better, pulled and written to my ADB folder.

Cheers

Tom
[Android Software/Hacking General [Developers Only]] osm0sis:
Change directory to /sdcard first. 😉

Or run it from your desktop using adb shell.
[Android Software/Hacking General [Developers Only]] tom1807:
Thanks, I was impatient and went the complicated way.

Got all the properties with "getprop", copied these into a text file, compared the required values from another build.prop, copied these into a new file, removed all the characters like [, ], and loaded into PF and it displayed a beautiful formatted PIF output, included an "FIRST_API_LEVEL": "27".

Edit: switched to /sdcard, run the code, copied the generated build.prop to my notebook; now it shows also "VNDK_VERSION": "29".

Good to go (I hope)

Cheers

Tom
[Android Software/Hacking General [Developers Only]] hassanhassan:
banking apps still detect jailbreak after this, is this normal?
[Android Software/Hacking General [Developers Only]] Wolfcity:
What do you mean with "after this"?

Found a working fingerprint?

Deleted cache/data?

Magisk version/Magisk hidden?

Some more information needed.
[Android Software/Hacking General [Developers Only]] hassanhassan:
Sure, I have found a fingerprint. Was able to add my cards onto the wallet. Deleted cache/data. magisk is v26.4. I had the banking app on the deny list and it worked before all this craziness with fingerprints. Magisk is also hidden.

EDIT: Apologies this was NOT the thread I intended to post this question on! I just realised haha.
[Android Software/Hacking General [Developers Only]] primazz:
Thanks @osm0sis for great guidance. Maybe i'm just lucky but second try to get working FP was succesful.

Now for noob question. Do i save existing/working pif.json and try to install next to find second working FP.

Or can i somehow check if FP is working without installing it ?
[Android Software/Hacking General [Developers Only]] tom1807:
And the hope died. :ROFLMAO:

Used Gpay with PIF v14.2 successful, right after the payment went through, I got the Wallet message, "Device doesn't meet the requirements".

Was waiting for this to have a reason to switch to the fork

Uninstalled PIF and installed the fork.

Well, seems my FP was not good.

Device meets only Basic Integrity. Search is on.

Edit: search was successful.

Cheers

Tom
[Android Software/Hacking General [Developers Only]] more_than_hater:
I wonder how is that possible, that after Google bans fingerprint, it still does work on non-rooted (original) device

Maybe, the main thing lies not in fingerprint itself?
[Android Software/Hacking General [Developers Only]] HippoMan:
It's because the Googlefrinchians almost certainly have ways to determine whether or not the supplied FP corresponds to one or more characteristics of the actual device on which it's being used.

There are people who are actively trying to figure out how the Googlefrinchians do this, so that perhaps we could eventually figure out how those efforts could be thwarted.
[Android Software/Hacking General [Developers Only]] more_than_hater:
so it's a race against time, where we may run out of still non banned fingerprints first :D
[Android Software/Hacking General [Developers Only]] HippoMan:
Exactly!
[Android Software/Hacking General [Developers Only]] shoey63:
It would seem they only block prints if the bootloader is unlocked.

If locked, they pass it because the device can't have been tampered with.

And they really can tell if a bootloader has been unlocked or not otherwise HARDWARE _BACKED integrity would be a piece of cake to spoof
[Android Software/Hacking General [Developers Only]] osm0sis:
That's my guess, but it'll be good to confirm. Just wondering, if that is the case, why they don't do that already for everything. Perhaps it's a more difficult check, or would break other devices if they did it everywhere. 🤔
[Android Software/Hacking General [Developers Only]] HippoMan:
They do indeed already check for an unlocked bootloader. They remove STRONG integrity in that case, but BASIC and DEVICE integrity remain with whatever values that have been determined.
[Android Software/Hacking General [Developers Only]] rodken:
My guess is Google does not rely solely on the bootloader lock status to determine whether or not to block prints. They may also have other mechanisms in place to detect unauthorized modifications, such as device verification which involves checking the unique identifier and comparing it to a list.

Maybe even, software integrity checks that involves verifying the cryptographic signatures of the device's software to ensure that said device has not been tampered with. Google might go as far as using anomaly detection where analyzing various data points from the device, e.g., log files and sensor data, to look for any suspicious behavior that might scream unauthorized modifications.
[Android Software/Hacking General [Developers Only]] Tonal4Nagual:
Hi ,

I have a problem with the execution of your updated script for generating pif.json. Namely, when I run it in FX explorer, it says that build.prop is not in the directory where the script is, but when I run an older version of the script, custom pif.json is created successfully.
[Android Software/Hacking General [Developers Only]] osm0sis:
Works for me. Download again from the attachment on my post?

FX File Explorer is what I wrote the script in, and it works here both from Unprivileged and Root Script Executor.
[Android Software/Hacking General [Developers Only]] Tonal4Nagual:
It seems that the problem exists for some reason only when both versions of the script are in the same directory where build.prop is. When I remove the old version of the script, everything is ok
[Android Software/Hacking General [Developers Only]] sawdoctor:
Currently running chiteroman PIF 14 with custom fingerprint (if it's not broken don't fix it). But i want to switch to your fork now, so if I switch I just flash your zip and move my json file from data/adb to data/adb/modules/playintegrityfix ?

For some reason Google is still seeing my device as a realme x2 pro(not using that fingerprint). In data/adb there was a file called pif.prop.old that contained the reame X2 pro fingerprint so I'm guessing i have a pif prop left over somewhere, any idea how to remove it/get Google to see me as a pixel fold again? Do i need to flash a prop reset zip
[Android Software/Hacking General [Developers Only]] osm0sis:
The script isn't allowed to be renamed. It uses its name to find its execution directory when sourced executed in a file explorer app like FX.

Easiest way to switch is to take the pif.json you want to use, rename it to /data/adb/modules/playintegrityfix/custom.pif.json and then flash my module. You'll see during the flash that it recognizes the custom.pif.json and is retaining it through the update.

As for why it thinks it's a Realme... That's weird, and suggests something got spoofed to more than DroidGuard at some point. 🤔

I haven't personally seen that behavior since switching from USNF.
[Android Software/Hacking General [Developers Only]] sawdoctor:
I did flash chiteroman updated/modded USNF a few weeks ago so probably related, no idea how to clear it without wiping?
[Android Software/Hacking General [Developers Only]] osm0sis:
That explains it then. Wiping Google Play Services data is probably required for that one.
[Android Software/Hacking General [Developers Only]] osm0sis:
It's been fun learning a bit of Java so far and basically future proofing this thing with the goal being never having to update it again. Still some work to do for that, but so far so good! ;)

Literally *any* *field* (including any Google may add in the future) is now currently supported instead of having to stick to only the set list from chiteroman's API, see the new example.pif.json for just a few of them. Plus I corrected his API's incorrect naming of things, but for now left things backwards compatible so people can update/install without worry and correct their files later, because I'm a people pleaser. :p

To migrate from chiteroman's 14.0/DEV branch module, simply move your pif.json to /data/adb/modules/playintegrityfix/custom.pif.json then flash my module zip. You'll see it detect the custom.pif.json during the flash, and retain it through the upgrade. Make sure your FIRST_API_LEVEL is present and correctly filled. (y)

I work on these projects in my limited time off, so if you like the progress I'm making, or enjoy anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thanks for your support!

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

Play Integrity Fork v4:

- very verbose logging (for now)

- allow spoofing literally any field from android.os.Build or android.os.Build.VERSION

- add BUILD_ID and VNDK_VERSION support to keep cross-fork API compatibility

- add exceptions for FIRST_API_VERSION (actually DEVICE_INITIAL_SDK_INT) and BUILD_ID (actually ID) for backwards API compatibility

- add empty example.pif.json with reference link

- fix GMS crashes if a null/bad value was read from json

Note in the example.pif.json that all my new fields correspond to things that can be easily derived from the fingerprint, and/or are the correct names for things we already use: https://raw.githubusercontent.com/osm0sis/PlayIntegrityFork/main/module/example.pif.json

References:

https://developer.android.com/reference/android/os/Build#fields

https://developer.android.com/reference/android/os/Build.VERSION#fields_1

core/java/android/os/Build.java - platform/frameworks/base - Git at Google

Happy hacking! :cowboy:
[Android Software/Hacking General [Developers Only]] osm0sis:
Updated my custom pif script!

- fix execution when spaces are in the directory name

- update for new default Fork v4 fields (corresponding to a full fingerprint), note not all of these are currently known to be necessary

- use correct android.os.Build field names (ID and DEVICE_INITIAL_SDK_INT instead of BUILD_ID and FIRST_API_LEVEL, respectively)

- still allow dumping for chiteroman DEV branch build fields including VNDK_VERSION using "deprecated" command line argument

- add "all" command line argument to force inclusion of sometimes optional fields like SECURITY_PATCH

Example output using my Pixel 8 Pro .prop files:

system build.prop to custom.pif.json/.prop creator
by osm0sis @ xda-developers

- Using format: json

- Parsing build.prop(s) ...
google/husky/husky:14/UD1A.231105.004/11010374:user/release-keys

- Parsing build UTC date ...
Thu Oct 26 20:03:21 UTC 2023

- Build date newer than March 2018, adding SECURITY_PATCH ...
2023-11-05

- Parsing build first API level ...
34

- First API level 33 or higher, resetting to 32 ...

- Writing new custom.pif.json ...
{
"MANUFACTURER": "Google",
"MODEL": "Pixel 8 Pro",
"FINGERPRINT": "google/husky/husky:14/UD1A.231105.004/11010374:user/release-keys",
"BRAND": "google",
"PRODUCT": "husky",
"DEVICE": "husky",
"RELEASE": "14",
"ID": "UD1A.231105.004",
"INCREMENTAL": "11010374",
"TYPE": "user",
"TAGS": "release-keys",
"SECURITY_PATCH": "2023-11-05",
"DEVICE_INITIAL_SDK_INT": "32"
}
[Android Software/Hacking General [Developers Only]] sawdoctor:
Just flashed latest version have a custom.pif.json in the right directory. This fingerprint/json was passing on chiteroman PIF14 but is no failing device. Any ideas? I can send you the json if you want to check
[Android Software/Hacking General [Developers Only]] osm0sis:
PM me with it and I can tell you what's wrong with it. It's almost certainly something to do with your FIRST_API_LEVEL or SECURITY_PATCH, since 14.0 had default fallbacks for those if empty/invalid. I've helped fix a few of those for people so far.
[Android Software/Hacking General [Developers Only]] sawdoctor:
I've tried a few fingerprints that i know we're working and everything i try fails on your latest release. I've even tried using pixelflasher to process the build prop again and still all fail. I'll pm you a json that i was using and working now. Thanks for your help
[Android Software/Hacking General [Developers Only]] rodken:
So far - so good on v.4 including populating of the additional fields.
[Android Software/Hacking General [Developers Only]] rseiler:
So you're saying it works with the classic 8 lines but also appropriate additional ones? Just trying to correlate your post with the preceding one.
[Android Software/Hacking General [Developers Only]] osm0sis:
I have it working on one device with only fingerprint, security patch, and device initial SDK int (formerly first API level). So rest assured, you can put as few or as many as you need for your fingerprint on your device to work.

(Though I would recommend the full set in case Google adds any cross-checks for the fingerprint values).
[Android Software/Hacking General [Developers Only]] rodken:
Affirmative. I was little apprehensive on whether using the additional fields would yield good results, but trust and believe that it pays to read and comprehend before diving in.

Remember to mind your coding manners so that you don't mistype to avoid screaming at the Fingerprint Gods as to why it's not working in your favor.
[Android Software/Hacking General [Developers Only]] UberNorse:
Can confirm v4 works for me. I just copied my custom.json from v3 and pasted into v4, re-zipped and flashed.

Pixel 7 Pro

14 Stable UQ1A

Magisk Canary 26403
[Android Software/Hacking General [Developers Only]] osm0sis:
Why do anything other than update through Magisk/KernelSU app? My script literally keeps the custom.pif.json installed for you.
[Android Software/Hacking General [Developers Only]] UberNorse:
Honestly didn't take the time to read that part. I've had an extremely rough two days so I winged it. Thank you for your work.
[Android Software/Hacking General [Developers Only]] GabbyWC:
Hey, osm0sis, thanks for the great work with your PIF fork and custom PIF script. The main custom JSON that I've been using passes basic and device integrity with v4 as it did with v3. A couple of days ago, I used your custom PIF script to create valid JSONs from four different device dumps and ROMs that pass basic and device integrity. In your opinion, is it worthwhile to download the build.prop files from those dumps or ROMs again to generate more detailed fingerprints or to see if the results are different now with other fingerprints that only passed basic but not device integrity with v3 and your older script?
[Android Software/Hacking General [Developers Only]] PatrickJK:
Upgraded from v3 to v4 through magisk and the fingerprint I was already using kept working, but switching to any other print would cause an integrity test to take ages before finally returning that nothing passed. A clean install of the module fixed the issue and the prints i've collected are working again.

So to anyone who may be having issues after upgrading, try uninstalling the pif fork, rebooting, installing, and rebooting again before trying to switch fingerprints.
[Android Software/Hacking General [Developers Only]] rseiler:
Yes, I just upgraded from v3 to 4 with my classic-style json (I've never experimented with or included any of the newer fields in order not to complicate things further), and it's A-OK, so thanks.
[Android Software/Hacking General [Developers Only]] osm0sis:
I only included ones that people can already cut and paste from the fingerprint so as not to freak anybody out, but also wanted to emphasize just how future proof this thing is becoming. 😛

Anything that passed with DEV branch and Fork v3 should still pass. Anything that failed will likely still fail, but with my new template we're at least ready for any potential cross-checks Google might add against the matching fingerprint elements. Plus it looks nicer. 😉

That shouldn't make a difference, since any Magisk module update is basically a clean install, so it was likely just the reboot or something. 🤔
[Android Software/Hacking General [Developers Only]] PatrickJK:
Weird. I did reboot after updating the module initially, but I probably should have tried another one. New to the whole rooting/magisk thing lol. Regardless, thanks for your work on this module. It's much appreciated.
[Android Software/Hacking General [Developers Only]] osm0sis:
I switch prints on-the-fly all the time with `killall com.google.android.gms.unstable` to thoroughly test my fork and immediately can see if the json passes or fails. Tested @sawdoctor's custom.pif.json on my Pixel 8 Pro just now and it passes for me even. 🤷‍♂️

I recall seeing something about QPR2 breaking things? Not sure if latest Magisk canary has that fully fixed for our purposes or not.
[Android Software/Hacking General [Developers Only]] edd080:
@osm0sis ,just upgraded from your V3 fork and everything is still working fine for me.

Thank you for your work 👍
[Android Software/Hacking General [Developers Only]] UberNorse:
So after updating to v4 and everything was fine, I had the bright idea to also update to QPR2 and among other issues non-related, it broke device integrity. Reverted back to my working v3 and it also failed. Am working through my other prints to find a valid one at the moment.
[Android Software/Hacking General [Developers Only]] osm0sis:
Check my post in the PIF thread.

🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com

It seems QPR2 will indeed break both my Fork and chit's latest v14.x and all DEV releases because the system property spoofing hook gets broken. Dobby apparently still works on it, so if you need to stay on QPR2 for some reason then you could try PIF v14.0 with your custom json until we figure out a fix for ShadowHook.
[Android Software/Hacking General [Developers Only]] UberNorse:
Will do and thank you @osm0sis.
[Android Software/Hacking General [Developers Only]] bombadier:
That's 14.3 fp burnt now so that's me on v4 of your fork @osmosis working fine with the fp I found the other day cheers🤙
[Android Software/Hacking General [Developers Only]] hhp_211:
Hey, wanted to pick your brain a minute.

the lead up::

I have a Gen 1 Moto G whopping 8 GB model,,,

'/data' partition is roughly 5.52 GB available space on a empty device,,, '/cache' partition is 662 MB

on android 5.1.x Roms ART dalvik cache partition, '/data/dalvik-cache' is running at about 1013 MB

the question(s)::

Is it even possible to use your script on this device since ART is 60% larger than the size of /cache partition?

wouldn't the optimization process fail during boot? or would it only store what it can in /cache and rest in original '/data/dalvik-cache' ?

also the '/data' partition is f2fs where as '/cache' is ext4, would there be any noticeable difference in speed?

As a second option I was thinking of maybe using the script to have TitaniumBackup use the '/cache' partition

I currently have is storing about 581 MB

If I go this route would I link it as '/sdcard/TitaniumBackup' or as '/storage/emulated/0/TitaniumBackup' ?

the rambling::

what I'm doing right now with /cache is storing a 2nd gapps package and a 2nd ROM as a safety net when flashing new ROMS

My '/data' normally runs @ 5 GB of it's generous 5.52 GB capacity with backups, apps to try, kernels, themes, etc, etc.

I have to get creative backing up things to cloud, otg or pc storage, especially with a full TWRP backup weighing in at 1.25GB thanks to ART optimizations I can't just go and have a quick restore lounging around on my device anymore.
[Android Software/Hacking General [Developers Only]] Wolfbreak:
[MENTION=4544860]osm0sis[/MENTION]

Keep up the good work this Thread has alot of helpful Informations for Modders/ROM Cookers and so on.

BTW: I sent you a PM
[Android Software/Hacking General [Developers Only]] osm0sis:
dalvik2cache is all or nothing, so it sounds like you wouldn't have enough room using ART. ext4 can be faster than f2fs depending on the mount options you're using on both, but you'll likely be fine with f2fs and dalvik-cache on data. Bind mounting Titanium is a good idea by the sounds of it, just make sure you mount it on the actual directory, probably in /data/media/0/, not the emulated/symlinked ones. Cheers. :)

Feel free! Always glad to see adoption on other devices. Let us know how it goes. :D
[Android Software/Hacking General [Developers Only]] hhp_211:
I knew there was a path I couldn't remember at the time

/data/media/0/TitaniumBackup/

Thanks for the advice!

I'll give it a whirl.

I'll just have to be careful with scripts that auto wipe cache partitions and keep a backup of that stored.
[Android Software/Hacking General [Developers Only]] preacher65:
Hi, firstly thanks for these great scripts. I've been making a lot of use of the ADBsync sdcard Backup script and it's a real time saver, so thanks to you and [MENTION=4474482]Renate NST[/MENTION] for your great work. I have a quick question about the best way to restore - can I just boot into recovery and use the following from a command prompt inside the relevant folder (same level as the batch file)?

adb push sdcard/0 /sdcard

followed by flashing the permissions fix? Or should I use

adb push sdcard/0 /data/media/0

Does that make any difference at all? Not sure how recovery and/or adb is handling the paths.

Or even

adb push sdcard /data/media

since the backup script also creates a folder called sdcard/obb alongside sdcard/0, but all it ever seems to have inside it is a .nomedia file. Not sure if I need to copy that or not.

I'm using it on mako, flounder and bacon, if that's relevant - all three have an internal sdcard.
[Android Software/Hacking General [Developers Only]] osm0sis:
Thanks! Third option is best if I recall correctly; I've heard that you're better using the direct location (/data/media) over the symlink/fuse mount (/sdcard) for improved speed. Then you're right, sdcard permissions fix should clean things up for boottime. :)

Most would want the whole sdcard restored since games store large files in obb.