[Magisk] osm0sis:
PIF FAQ

Abbreviations

DG = DroidGuard (SafetyNet/Play Integrity)

GMS = Google Mobile Services (Google Play Services)

PIF = Play Integrity Fix

Frequently Asked Questions

Q: What is a fingerprint and where does it come from?

A: A fingerprint is an Android system/build property made up of information about your ROM, and is used to identify that specific build/compile of the ROM.

It is NOT unique to your device, nor your physical unit, it is only about the build of the device's ROM you're on, e.g. every Pixel 8 Pro on the December OTA ROM build has the December OTA ROM's build fingerprint.

People commonly now just refer to the entirety of what gets spoofed via PIF modules as the "fingerprint" or "print", though the fingerprint is only actually one piece of what gets spoofed.

Q: What does a fingerprint being banned mean and does it affect the real device?

A: The exact mechanism isn't known, but when a fingerprint gets banned it just means that Google has made it so that this specific ROM build fingerprint can no longer be used for spoofing purposes, but any actual real devices that are on the corresponding ROM build will of course continue to work fine if locked.

If someone refers to a whole device as being banned, more accurately it's that there just aren't now or were never any known fingerprints working for spoofing purposes that came from a ROM on that device.

Q: Why should I look for my own private fingerprint when other modules/ROMs include one?

A: If you find your own, it is less likely to get banned, whereas these mass used ones frequently get banned and need to be replaced in those modules/ROMs.

I was on my first one, which I found Nov. 19, 2023 when PIF v13.1 first added pif.prop support, until Feb. 29, 2024 when it was lost in the mass ban of ~95% of all known working fingerprints.

The less obvious statistical data Google receives indicating a particular fingerprint is being abused, the fewer fingerprints will get banned.

Q: Why doesn't the fingerprint I found work?

A: We're not entirely sure why, but not all devices or ROM builds are suitable fingerprint "donors", and also not all working fingerprints work on all phones (see below).

Q: Why does a fingerprint I found work on some of my devices, but not others?

A: It could be DG enforcement differences depending on some underlying ROM values, DG enforcement changes in different stages of rollout, or Google testing some DG changes on some devices and different DG changes on others (this is known as "A-B testing").

Q: I pass BASIC and DEVICE integrity, but can I also pass STRONG?

A: No. On a normally functioning unlocked device this isn't currently possible. The goal of PIF modules is to pass BASIC and DEVICE.

Q: Fields and properties get mentioned a lot, what's the difference and how does that work?

A: android.os.Build is a Java class for apps to use to get ROM information. It has fields which only get globally populated once by the ROM using system properties at early boot time, so then for PIF modules we only need to spoof the fields to different values specifically for DG using a Java method called reflection when the DG process (com.google.android.gms.unstable) first starts.

System properties, or "props", are what you see when you type `getprop` into a command prompt on Android, and come from build.prop files throughout the ROM. For PIF modules we spoof them to different values at boot time in the module scripts for those safe to be changed globally (e.g. ones for locked bootloader status), and also specifically for DG using libc hooks at each DG attestation for those that aren't safe globally (e.g. ones specific to the fingerprint or that could affect the device's function).

Q: Is GMS version related to DG enforcement changes?

A: Probably not, since DG gets downloaded into GMS app data (/data/data/com.google.android.gms/app_dg_cache) independently, and can update any time, plus a lot of DG is server-side.

Q: Why do DG checkers still show my actual device information?

A: PIF modules only spoof specifically to the GMS DG process, everything* else sees your actual device.

*The known exception to this seems to be Find My Device/Device Activity, but this can be fixed by making sure that you first log in to GMS on your device unspoofed, then set up a PIF module to spoof afterwards.

Q: Why do DG checker apps show an error about tokens sometimes and what does it mean?

A: This has nothing to do with your fingerprint, it's just a limitation of 10,000 checks per day Google put on public Play Integrity apps.

There is a checker built in to the Play Store itself if you go into Play Store Settings, repeatedly tap the version number under About, then go to the added Developer Options menu under General.

Q: How does Play Store Certified status relate to DG?

A: This check is DG based but seems quite infrequently done by the app, so once you have a passing fingerprint this can take a long time to show the change. Since there's no big loss to it, wiping Play Store app data and cache is the common solution to hurry things along.

Due to some kind of result caching, note multiple wipes of the Play Store may be required, and/or wiping Play Protect Service app data and cache if present. Generally you're good once the area that usually shows certification is blank, then it fills in with "Device is certified" later, but also checking to see if you're able to download (i.e. no "not compatible" message) Netflix or Leo's Fortune is a good indicator you've got it properly wiped and working in the meantime.

Q: How do Google Wallet Security Requirements relate to DG?

A: This check is also DG based, but it is a cached result and therefore lags behind when your device is otherwise failing DG checks. Some people report up to 48 hours before payments start failing, even if Wallet is already showing it "does not meet security requirements".

Similarly, if you just wait up to 24 hours once your fingerprint is passing, Wallet will clear its cached failure status. Some people hurry this along by clearing GMS app data and cache, but note this means you'll have to set up your Google account on your device again and reset any paired WearOS devices.

Q: How does RCS relate to DG?

A: Starting with an apparent test Mar. 29-Apr. 1, 2024 and then rollout May 29, 2024 onwards, the Google Messages support for RCS seems to rely on DG verdicts and the actual DG fingerprint information, and specifically ban the mass publicly-used fingerprints from PIF/Xiaomi.eu of the time, even though they remain otherwise passing for DEVICE verdict. RCS will initially fail silently, then after a period of time show that you're falling back to MMS/SMS. This is another reason (see above) to find a private fingerprint which, though rare, appear to remain unaffected by this targeted RCS ban.

Q: What is AOSP testkey ROM signing and why is it separate from release-keys tags?

A: ROMs can have test-keys or release-keys tags but this is not necessarily due to the key they are signed with, e.g. a ROM may be release-keys tagged but still be signed with the AOSP testkey. Only the AOSP testkey is known banned for use in DG currently, and many custom ROMs have already started using their own private keys to sign in response.

Now that we've covered the basics, please see the README of my more futureproof, methodically developed Play Integrity Fork for more information, instructions, and resources for using a PIF module and finding/creating your own PIF module private fingerprint .json file!