[Magisk] m00n3:
Guys, this is pathetic. I've been lurking for quite a while, and much to my dismay, the community keeps chasing down what seems to be to be very obviously the wrong rabbit hole.

Google is NOT banning/burning fingerprints. That's not what they're doing at all, trying to spend time wondering how they're "banning FPs" and freaking out about "custom FP checkers" tipping them off is a useless exercise.

Safetynet, the percursor of Play Integrity, has been completely reversed. Romain Thomas has a paper that explains how the whole thing works and it's a great starting point. The gist of it is that Google's API will return code that runs on the VM that can basically do whatever to your device. It is safe to assume that Play Integrity is an evolution of the Safetynet mechanism. It most likely has the ability to call home or do other checks that Safetynet doesn't.

With that basic knowledge in mind, what is nearly 90% happening is:

Google has a big ass database of certified devices. There is a process OEMs have to undertake in order to get Play Certified and this will involve Google keeping information about the devices/builds OEMs are shipping. This is public info, guys.

PI checks a bunch of values. We know this because that's how spoofing works. In very simplistic terms, they check eg, system props values like ro.product.system.manufacturer, ro.product.system.device, etc.

Based on the checks they have in place and the Play Certification database, the fields they check must be consistent for what their knowledge of what a valid device is. Eg, if your device name is "Galaxy A12", then your manufacturer has to be "Samsung". So far we're all on the same page, this is how we've been able to get FP spoofing working. A lot of these checks are simple getprop, but they don't have to be limited to that. This we know already too.

Now, and here's the part that I believe people have been missing: PI clearly has the ability to perform extra checks at will, without updates to GMS. They have the ability to do an arbitrary number of extra checks that we don't know about – Safetynet literally downloads the bytecode that will perform all the checks Google wants on demand, PI will do that or a more powerful version of what SN did, for sure. Of course someone must have had to code those checks, so it's safe to assume that they're not going to add new checks all the time, just that they can do them. Bur crucially:

checking fields for a particular device that weren't being enforced before is trivial work for Google to do!

And now we're getting into speculation: it's my firm belief that Google has code in PI that sends telemetry to Google's servers with the values they're retrieving, even if the check passes.

Then, every week, a virgin loser at Google with nothing better to do and a vendetta, who is just lazying around while his stocks vests while hoping he doesn't get laid off wakes up (I say this because I find it hard to believe a Product Manager is prioritizing this work), looks at the telemetry and sees what's going on. They notice that suddenly there's now 50k more active CatS60 devices running Android 6.0.1. There used to be 100 active devices running this build. Those nasty root users are at it again!

They look at the telemetry more closely. The 100 active devices from last week all reported a ro.product.board of catcodename. The 50k that showed up today have completely random values.

Even if there's no telemetry, our soon-to-be-laid-off loser (that should be building new products and is obviously never going to be promoted doing this pathetic grunt work) can scour forums/Github/etc and see what FPs people are using, compare with the database/real device info that the OEM must have submitted as part of the certification process and see "Hah, these idiots are not spoofing the board prop! Gottem!"

The highly paid loser adds ro.product.board=catcodename to the Play Certification database. Hits submit.

PI starts performing the new checks. XDA freaks out that their FPs have been "burned".

This explains things like:

Q: How does the FP keep working in the original device? A: Because Google only tightnened the checks for that device, they didn't "ban" anything

Q: How do "burned" FPs work in some devices randomly? A: Because whatever extra check Google happens to resolve to the same thing in that person's device/ROM!

Q: Why doesn't Google just ban all the FPs? A: Because they're not banning anything, they're just tightening what they accept as "valid" devices. In their database, they have the data that, ie, Lenovo submitted to them. It may be very incomplete since maybe at the time they only required the OEM to submit a handful of fields and now PI can check a lot more, but no one is going to go through every single device that was certified since Play Certification started and figure out all the extra checks that can be done easily with the current PI framework.

Q: Why do "custom fingerprints" work so well? A: Easy, they fly under the radar. 1 or 5 or 10 more active "weird" devices are normal and even if they are pinging with some weird values, it's not worth checking. Better yet, it's not worth the risk of banning actual real devices.

Q: Ok, then how do mass bans work? A: "Mass bans" is just the loser going the extra mile and figuring stuff out like "all Lenovo devices should be reporting this value for this field, so let's start enforcing it". This will of course steamroll any custom FPs that match that fail that extra value check.

If the community hopes to get anywhere with this,

A talented reverse engineer like Romain does the same exercise that was done for Safetynet, but now for PI. This would show exactly what extra bits of info Google is grabbing. Of course, it's still a cat-and-mouse game, but instead of poking randomly like we're doing right now, we'd have an insight of exactly what extra information Google is gathering from our devices.

Failing that, a version of PIF that allows people to spoof any getprop. Then the community, instead of farming FPs like we're doing, could farm entire build prop files. The most useful research would be to take an existing "banned" build and mess around until the "banned" print starts working on another device. Properties are such low hanging fruit that I believe that the bulk of PI checks may very well just be restricted to those + kernel strings and whatnot – but I may be wrong, only reverse engineering the PI checks would be able to prove what they're doing.

In summary, the best thing one can do is to reverse PI like Romain reversed SN, otherwise we're blind. The next best thing is to have a fork of PI that can spoof a lot more than just a handful of props, ideally it'd be able to spoof ALL getprop properties. This shouldn't be hard at all. Then the community can take a "banned" device and play around with it until it works – that's how we'd know which extra checks Google is adding.