🔧 [MODULE] Play Integrity Fix (SafetyNet fix) (2024)

If you haven't yet, read the PIF FAQ first!

Alright noobs, here you go.

How to create and use a custom.pif.json!
Note: for the purposes of keeping this post simple I'll be referring to devices as "banned", but more accurately it's only the specific build fingerprints, and they are only banned for spoofing purposes (i.e. the actual devices of course continue to work fine if locked).

1. Find stock ROM system build.prop *and/or* product build.prop *and* vendor build.prop dumps for the device you want to spoof. You have a few options for this:
- You may use your favorite search engine to look for these; there are a number of sites containing whole extracted ROM partition and build.prop dumps that can be used, I'm not going to list them to keep Google from just directly crawling them all and mass banning the fingerprints, but they're out there.
- If you know how to extract files from a Full OTA zip, ROM Factory Images or stock ROM dumps, you can do that instead. There are lots of how-to's for that depending on the format, so search for them, use the tools and you're good.
- You could also use `adb shell getprop` to dump all prop values from a stock ROM on another actual device, but some props may not be visible unless rooted, and this method of course requires you to physically have the device you want to spoof, which isn't necessary.

2. Some general patterns/trends/guidelines I've noticed to help you find a working build fingerprint:
- All older Nexus devices (Nexus 6/shamu and older) appear to be banned. Not even BASIC working.
- Final release ROM builds of all no-longer-supported remaining Nexus and Pixel devices are banned.
- The device must have at least been upgraded to Oreo (Android 8) to possibly work, which also means it should have received an ro.*.first_api_level in its system (8.0) or vendor (8.1+) build.prop; the earliest working devices I've seen have First API Level 21, which is Lollipop (Android 5). Note you can still use the pre-Oreo fingerprints from these devices however!
- Devices launching with Pie (Android 9) or later have a First API Level 28+ and seem less likely to work out of the box. The newest working devices I've seen have First API Level 34, which is Upside Down Cake (Android 14), but even later working fingerprints from these devices are possible.
- The DEVICE_INITIAL_SDK_INT/FIRST_API_LEVEL field should always be set to avoid the fallback to actual device value possibly triggering HARDWARE_BACKED evaluationType in SafetyNet depending on the fingerprint, and thus ensuring consistency of results across host devices. Start with it at the correct value for the fingerprint, but if the device's First API Level is 33+ you'll definitely need to lower it to 32 or less to keep BASIC evaluationType in SafetyNet, and note some fingerprints may also need it set to 25 or less to keep BASIC evaluationType in SafetyNet.
- Any build prior to March 16, 2018 does not require a matching SECURITY_PATCH field (note the date to compare is from ro.build.date in system build.prop, not the AOSP base date in the fingerprint), but it might still be good to know for those just in case that changes.
- You've got lots of options, especially e.g. on an OEM's stock ROM Factory Images site, so try to pick a device and then a ROM release both of which you don't think many people will choose. The less obvious statistical data Google receives indicating a particular fingerprint is being abused, the fewer fingerprints will get banned.

3. Depending on whether you're looking in system build.prop or product build.prop there could be different names for the props you need to take the values from, but here's how it works:
- When downloading your build.props, for some devices you may be looking at system-as-root dumps, in which case (since the partition is still called system) it'll be at /system/system/build.prop instead of /system/build.prop. product can be /product/build.prop and/or /product/etc/build.prop and vendor is /vendor/build.prop or sometimes /system/vendor/build.prop (if the device has no proper vendor partition but is pretending).
- In general they'll be ro.build.fingerprint + ro.product.* (older system build.prop), or, ro.system.build.fingerprint + ro.product.system.* (newer system build.prop), or, ro.product.build.fingerprint + ro.product.product.* or ro.vendor.product.* (product and vendor build.prop, respectively, only needed on devices where system build.prop contains "generic" values). From these you'll copy the 6 main values to between the quotes of the corresponding fields in the template custom.pif.json below: PRODUCT (ro.*.name), DEVICE (ro.*.device), MANUFACTURER (ro.*.manufacturer), BRAND (ro.*.brand), MODEL (ro.*.model), and FINGERPRINT (ro.*.fingerprint).
- Optionally add SECURITY_PATCH (ro.build.version.security_patch from system build.prop), noting my caveats for this field from Step 2. You may remove this line if you aren't using it.
- Definitely add DEVICE_INITIAL_SDK_INT/FIRST_API_LEVEL (ro.product.first_api_level or ro.board.first_api_level from vendor build.prop), falling back to API Level (ro.board.api_level) then Version SDK values if these are not present (ro.build.version.sdk or ro.system.build.version.sdk from system build.prop, ro.vendor.build.version.sdk from vendor build.prop, or, ro.product.build.version.sdk from product build.prop), noting my caveats for this field from Step 2.
- You may also simply use my gen_pif_custom.sh shell script to generate a custom.pif.json from your supplied build.prop files by running it on your phone using root in a Terminal emulator or without root in a file explorer app, starting with the system build.prop named as build.prop and following instructions: https://xdaforums.com/t/tools-zips-...ices-platforms.2239421/page-172#post-89173470

4. Copy your .json file to /data/adb/modules/playintegrityfix/custom.pif.json for my fork, or /data/adb/pif.json for chiteroman's, using root in a Terminal emulator or file explorer app, cross your fingers, then either `killall com.google.android.gms.unstable` from a root prompt in a Terminal emulator app, or reboot your device.

Happy hacking!

Edit: In the time since this guide was written Google has imposed several mass bans, resulting in only around ~1% remaining of the previous ~6517 known working fingerprints, with extremely few left in any of the big public dump and device spec sites, though there are still some to be found.