[Tasker Tips & Tricks] Lord Sithek:
Hello Tasker users

If you have root access/unlocked bootloader and you want to use Google Wallet or other apps/services involved with Play Integrity, you are most probably well aware of the Play Integrity Fix module (and perhaps of it's fork as well). Now is the time for hunting fingerprints in order to fool Google as long as we can :ROFLMAO:

If you need more information on what are custom fingerprints and how to find them, please read this FAQ.

Because I like to automate things as much as I can, I created a Tasker project to help with fingerprint testing.

DOWNLOAD FROM TASKERNET

What is needed:

1) download and flash Play Integrity Fix module by @chiteroman or Play Integrity Fork module by @osm0sis in Magisk, KernelSU or APatch

2) download wonderful gen_pif_custom.sh script by @osm0sis to /sdcard/Download directory

3) download system build.prop and possibly vendor build.prop and product build.prop to the same directory

What are inside:

Five tasks:

- Select PIF Variant: launch task to select which PIF variant you use

- PIF Testing Flow: main task

- Build.props Checker: check and rename build.prop files

- (optionally) Replace DEVICE_INITIAL_SDK_INT: change DEVICE_INITIAL_SDK_INT value

- Kill com.google.android.gms.unstable: kill the process responsible for Play Integrity check

- (optionally) Check Play Integrity: attempts to automatically run Play Store PI Check (NOTE: Requires AutoInput plugin to be installed and Play Store Developer options to be enabled beforehand)

Optional tasks must be enabled manually in PIF Testing Flow task.

NOTE: Please remember to download build.prop files in the following order:

1) system build.prop

2) vendor build.prop (if needed)

3) product build.prop (if needed)

The correct sequence is crucial to the proper renaming and generating .json file.

How to use:

Just run PIF Testing Flow task.

- if no build.prop file is detected, the process aborts

- if single build.prop file is detected, a dummy vendor-build.prop is being created according to the instructions from the @osm0sis' script

- if two build.prop files are detected, they are renamed to system-build.prop and vendor-build.prop

- if three build.prop files are detected, they are renamed to system-build.prop, vendor-build.prop and product-build.prop

- if more than three build.prop files are detected, the process aborts

- next the gen_pif_custom.sh script is executed; if an error occurs, error.txt with the error's content is created in /sdcard/Download; if not, the script creates custom.pif.json file in /sdcard/Download

- [optionally] DEVICE_INITIAL_SDK_INT value in newly created custom.pif.json is checked; if it's higher than a specified threshold value, it is changed to a new specified value (they are both set to 25 by default, you can change them manually in Replace DEVICE_INITIAL_SDK_INT task)

- [optionally] a task is initiated which attempts to automatically run Play Store PI check

NOTE: Some fingerprints, even with DEVICE_INITIAL_SDK_INT value higher than 25, passes Play Integrity, while others may work only when DEVICE_INITIAL_SDK_INT is lowered. It seems there is no general rule in this case, you have to experiment. Checking DEVICE_INITIAL_SDK_INT is disabled by default, if you want to use it, enable the respective action in PIF Testing Flow task

- if %PIF variable is set to PIF (means that @chiteroman's PIF is expected), custom.pif.json is renamed to pif.json and moved to /data/adb directory

- if %PIF variable is set to PIFork (means that @osm0sis' fork is expected), custom.pif.json is moved to /data/adb/modules/playintegrityfix

- com.google.android.gms.unstable is killed if necessary

- all build.prop files are deleted

If the process finishes successfully, you can perform Play Integrity test. You can use third-party checkers like SPIC, Play Integrity API Checker or TB Checker, or use internal Google Play Store check

Feel free to share your ideas of improving the project or even modify it yourself and share with others, I don't mind :)