There has been a large wave of profiles/fingerprints being blocked for software-backed integrity since 28th February. We've tested ~8900 fingerprints that now fail DEVICE integrity.
This includes a majority of the ones in this collection and in dumps like tadiphone.
There are no working prints left for the most common ABI lists (arm64-v8a,armeabi-v7a,armeabi and arm64-v8a) in this collection.
I am therefore, regrettably, archiving the repository. There is no more I can do at the present time. I suggest taking the issue up directly with Google if you wish.
In the meantime, you could try using the latest profiles from the Xiaomi.EU app project. osm0sis has a useful script to automate this.
This repository contains JSON files compatible with the Play Integrity Fix module by chiteroman or PlayIntegrityFork made by osm0sis.
If you don't use a custom ROM and haven't rooted your Android device, you're in the wrong place!
These files aren't tested - they're just a sample of device profiles available online.
By default, the PIF module and some of its forks use a default set of build properties (hereafter called a profile) including a build fingerprint for Play Integrity attestation. With tens of thousands of users using the same profile, the Play Integrity servers inevitably block the associated fingerprint for software attestation.
The best solution in the meantime is for every user to choose a working profile (pif.json file) of their own.
Both the original PIF module and its major fork support this using a JSON file containing real properties from a working device.
NOTE: It's now recommended to download and run the script as below as this permits the interactive mode where you can mark profiles as working or not working. If you pipe the script directly from
curlorwget, the interactive mode is disabled and you'll need to manually mark the current profile using the commands shown when the script exits.
This repository includes pickaprint.sh which automates the random selection of a profile with the same ABI compatibility as your device.
It will download the PIFS repository, extract the JSON files, and pick one from the relevant directory at random.
First, enter a root shell and choose your desired download location (it must allow execution):
su # The script needs to be run as root in order to copy a profile to /data/adb
cd /data/local/tmp # Choose a place where execution is permittedThen, if you're using Magisk for root:
/data/adb/magisk/busybox wget -O pickaprint.sh "https://raw.githubusercontent.com/TheFreeman193/PIFS/main/pickaprint.sh"Or if you use KernelSU (KSU):
/data/adb/ksu/bin/busybox wget -O pickaprint.sh "https://raw.githubusercontent.com/TheFreeman193/PIFS/main/pickaprint.sh"Once downloaded, make the script executable and run it:
chmod 755 ./pickaprint.sh
./pickaprint.shNOTE: Please don't just run random scripts from the internet, especially as root. I strongly urge you to look at the script first and get a basic idea of what it does.
If you haven't run the script before, it will download this repository from GitHub and extract the JSON profiles.
Once a subdirectory called JSON exists, the script will search for JSON profiles there instead of downloading the repository all over again.
If the script version is newer than the version in the JSON directory, it will download the latest version.
Therefore, to update the collection, run the wget command above to get the latest pickaprint.sh script, and this will update the collection when next run.
Alternatively, you could download/clone the repository and run the pickaprint.sh script directly from the download location.
Please see below for all the arguments you can pass to pickaprint.sh.
NOTE: The JSON files in this collection are structured to be compatible with PlayIntegrityFork by osm0sis.
If you're using chiteroman's module, you'll need to remove some of the entries and rename others. Please see the format conversion section below for converting to the chiteroman format.
Please choose a random file from the relevant directory.
The complete compatibility matrix for profiles and Android device isn't yet known - the Android ecosystem is huge and diverse, so this is to be expected. It appears the list of ABIs your device supports needs to match the device the profile is from.
To test for this, enter the following in your favourite terminal emulator:
getprop | grep 'cpu\.abilist'Or with ADB:
adb shell "getprop | grep 'cpu\.abilist'"You should get a result that looks something like this:
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.system.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.system.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.system.product.cpu.abilist64]: [arm64-v8a]
[ro.vendor.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.vendor.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.vendor.product.cpu.abilist64]: [arm64-v8a]
In this instance, the value to note is arm64-v8a,armeabi-v7a,armeabi.
The repository is divided by common ABI list values, so please pick a random JSON file from the relevant directory.
In the example above the directory would be JSON/arm64-v8a,armeabi-v7a,armeabi.
The profile filenames are labelled with the build tags and build type.
user build types are more likely to work than userdebug ones, and release-keys tagged profiles are more likely to work than dev-keys or test-keys ones.
Assuming the ABI list you got was arm64-v8a,armeabi-v7a,armeabi, you should first look in:
JSON/arm64-v8a,armeabi-v7a,armeabi
for a JSON file that ends with:
_user_release-keys.json
and copy this to the correct location (see below).
If copying a file manually (Option 2) there are a couple of places the JSON might need to go.
For the Play Integrity Fix module by chiteroman you should copy the JSON file to:
/data/adb/pif.json
And then follow the format conversion section below.
For the osm0sis fork (PlayIntegrityFork):
/data/adb/modules/playintegrityfix/custom.pif.json
An example command in your terminal emulator, for an arm64-v8a,armeabi-v7a,armeabi device running the chiteroman module might be:
su -c cp /data/local/tmp/JSON/arm64-v8a,armeabi-v7a,armeabi/Xiaomi_polaris_polaris_9_PKQ1.180729.001_V10.3.3.0.PDGMIXM_user_release-keys.json /data/adb/pif.jsonOr with ADB in root mode:
adb push "C:\Users\<User>\Downloads\PIFS\JSON\arm64-v8a,armeabi-v7a,armeabi\Xiaomi_polaris_polaris_9_PKQ1.180729.001_V10.3.3.0.PDGMIXM_user_release-keys.json" /data/adb/pif.jsonWhen using these profiles manually with the chiteroman module, you must remove additional values that are only compatible with the osm0sis module. You can do this in your preferred text editor.
These are:
RELEASEINCREMENTALTYPETAGS*.build.id*.security_patch*api_level
Additionally, you should change DEVICE_INITIAL_SDK_INT to FIRST_API_LEVEL and ID to BUILD_ID.
As an example, the follow JSON file from the collection:
{
"MANUFACTURER": "Xiaomi",
"MODEL": "Mi MIX 2S",
"BRAND": "Xiaomi",
"PRODUCT": "polaris",
"DEVICE": "polaris",
"RELEASE": "9",
"ID": "PKQ1.180729.001",
"INCREMENTAL": "V10.3.3.0.PDGMIXM",
"TYPE": "user",
"TAGS": "release-keys",
"FINGERPRINT": "Xiaomi/polaris/polaris:9/PKQ1.180729.001/V10.3.3.0.PDGMIXM:user/release-keys",
"SECURITY_PATCH": "2019-05-01",
"DEVICE_INITIAL_SDK_INT": "26",
"*.build.id": "PKQ1.180729.001",
"*.security_patch": "2019-05-01",
"*api_level": "26"
}Would look like this:
{
"MANUFACTURER": "Xiaomi",
"MODEL": "Mi MIX 2S",
"BRAND": "Xiaomi",
"PRODUCT": "polaris",
"DEVICE": "polaris",
"BUILD_ID": "PKQ1.180729.001",
"FINGERPRINT": "Xiaomi/polaris/polaris:9/PKQ1.180729.001/V10.3.3.0.PDGMIXM:user/release-keys",
"SECURITY_PATCH": "2019-05-01",
"FIRST_API_LEVEL": "26"
}After conversion.
Note how the trailing comma , on the second-to-last (FIRST_API_LEVEL) line has been removed.
You must remove this comma or the module will fail to read the file.
This is expected. The profiles in this repository haven't been tested and, even if they had, it's possible each will only work for a subset of devices.
Depending on your device, you can expect ~7-24% of the profiles to work at the time of writing, based on my testing.
Keep trying random profiles from the relevant directory until one passes the integrity level you want.
Some newer arm64-v8a-only devices like the Pixel 7 don't appear to work with arm64-v8a profiles when using beta builds of Android 14.
In these cases, try using arm64-v8a,armeabi-v7a,armeabi profiles (see the wrong ABI list section.)
Ideally, you'll be able to use your tested profile going forward. If too many people choose the same one (we're talking thousands, which is less likely if everyone picks at random) it may get blocked for software attestations. In this case, choose another! There are plenty to go around.
There may be edge cases where you're unable to download the script using the methods described above.
If you're using Termux as your terminal emulator, you can run the following command (as root):
/data/data/com.termux/files/usr/bin/curl -o pickaprint.sh "https://raw.githubusercontent.com/TheFreeman193/PIFS/main/pickaprint.sh"Then proceed as discussed above.
If this occurs, you can override the directory the script chooses for fingerprints by setting $FORCEABI in the environment.
In your favourite terminal emulator:
su # Run as root
cd /data/local/tmp # Choose the location where you downloaded the script
export FORCEABI="arm64-v8a,armeabi-v7a,armeabi" # Force a different ABI list
./pickaprint.sh # Run the script againIf you find fingerprints from another directory work, you can make the $FORCEABI variable persistent in Termux.
For example:
echo 'export FORCEABI="arm64-v8a,armeabi-v7a,armeabi"' > /data/data/com.termux/files/home/.bashrcThis forces the script to always use arm64-v8a,armeabi-v7a,armeabi profiles.
To remove this override immediately, you can use:
unset FORCEABIIf added to your emulator's bashrc file, you'll need to remove that line.
For Termux, this file can be found at:
/data/data/com.termux/files/home/.bashrc
You can skip the first paragraph if you aren't interested in the technical explanation.
ABIs (application binary interfaces) are low-level interfaces that allow binary processes to interact independent of hardware architecture.
You can think of ABIs as the machine-code counterpart to APIs (application programming interfaces).
ABIs allow Android components and applications to run on a variety of architectures and instruction sets, like x86 and ARM.
Lists of supported ABIs are stored in build properties such as ro.product.cpu.abilist.
The ABI list is a device property, like the model or fingerpint, and appears to affect Play Integrity verdicts. Using a fingerprint/profile from a device with a different ABI list fails more often that it works in my testing. This is why the profiles in the repository are divided by supported ABIs - you're much more like to find a profile that works by using a fingerprint from right directory for your device.
The JSON directory now includes a VERSION file which documents the collection version.
The pickaprint.sh script checks for this and re-downloads the collection if an updated one is available.
If you don't want to receive updates, set the PIFSNOUPDATE environment variable:
export PIFSNOUPDATE=1 # Disable updates
unset PIFSNOUPDATE # Re-enable updatesMake this persistent by adding such a line to the bashrc script of your favourite emulator:
For example:
echo 'export PIFSNOUPDATE=1' > /data/data/com.termux/files/home/.bashrcUsage: ./pickaprint.sh [-x] [-i] [-c] [-a] [-s] [-r[r]] [-h|?]
-x Add existing pif.json/custom.pif.json profile to exclusions and pick a print
-xx Add existing pif.json/custom.pif.json profile to exclusions and exit
-i Add existing pif.json/custom.pif.json profile to confirmed and exit
-c Use only confirmed profiles from '/data/adb/pifs/confirmed'
-a Pick profile from entire JSON directory - overrides $FORCEABI
-s Add additional 'SDK_INT'/'*.build.version.sdk' props to profile
-r Reset - removes all settings/lists/collection (except confirmed directory)
-rr Completely remove - as Reset but also removes confirmed and script file
-h Display this help message
When you select no for a profile that doesn't pass integrity, the script adds it automatically to a list of exclusions, and moves it to /data/adb/pifs/failed/.
The script will not attempt to use this profile again.
To exclude the existing profile in the pif.json or custom.pif.json, run the script with the -x argument:
./pickaprint.sh -xThe exclusions list is stored at /data/adb/failedpifs.lst.
This list ensures you can update the collection without having to try all your previously failed profiles.
If a profile exists in the relevant module directory when you first run the script, and you don't pass the -x argument, it'll be backed up to /data/adb/pifs/backup/
When you select yes for a profile that passes integrity, the script copies it to /data/adb/pifs/confirmed/.
To use only profiles from this directory, run the script with the -c argument:
./pickaprint.sh -cYou can copy your own working profiles to the confirmed directory and the script will use them when run with -c.
You can mark the current profile (pif.json or custom.pif.json) as confirmed working using the -i argument:
./pickaprint.sh -iThe script will exit immediately after adding this profile to /data/adb/pifs/confirmed/.
Some devices need to spoof these additional values to pass DEVICE integrity.
If your working profile started failing with the v3 script, you can try using the -s argument:
./pickaprint.sh -sThe script will dynamically add the additional properties when copying profiles.
The internet is awash with Android builds and every ROM, whether complete or in source code, contains build properties. My specialty is in automation (please see the textbooks I've helped to write - 100% of profits go into scholarships). My tools, with the aid of the web crawlers from major search engines, have collected a large number of build profiles and extracted the necessary properties to generate compatible JSON files.
I don't intend to release the source code for the collection tools at the moment - many users hammering repository service APIs and individual websites for the same information isn't fair. I may publish raw build property files at a later date for sources from which I can obtain relevant permissions.
- Build profiles of the
usertype withrelease-keystags are more likely to work thanuserdebugandtest-keysordev-keysbuilds. - If you lost the
MEETS_BASIC_INTEGRITYverdict with all the profiles you try, you might be using profiles with the wrong ABI compatibility. Check your device's ABI list again or try profiles from another directory. - Fingerprints/properties with generic values such
generic,mainline, andAndroidare likely to fail and you should use the equivalent product or vendor values instead. - If you're intermittently passing and failing verdicts with the same profile, it may be that the Play Integrity system is detecting your rooted environment. Try using root detectors such as RootBeerFresh to check your environment and look at the logs for any Magisk/KernelSU modules you have installed.
- If you're getting timeouts or too many requests errors, the app you're using to check Play Integrity verdicts has hit its API limit. Use the checker within Google Play Store instead.
- If you make too many integrity requests, even in Play Store, you may see a
Retry with an exponential backoffresponse. In this case, stop testing for a couple of minutes and retry at a slower rate.
To check Play Integrity verdicts without a third party app, open Play Store and go to settings (click profile icon in top right -> Settings). In the About menu, tap Play Store version repeatedly until you get a notification toast saying "You are now a developer". Scroll up to the General menu, open it and click Developer options. In this submenu you can click Check integrity to run a Play Integrity check.
The verdicts you need for most apps are MEETS_BASIC_INTEGRITY and MEETS_DEVICE_INTEGRITY.
