Skip to content
This repository has been archived by the owner on Mar 3, 2024. It is now read-only.

About mass-blocking of public collections #10

Closed
StupidRepo opened this issue Jan 17, 2024 · 2 comments
Closed

About mass-blocking of public collections #10

StupidRepo opened this issue Jan 17, 2024 · 2 comments
Labels
question Further information is requested

Comments

@StupidRepo
Copy link

StupidRepo commented Jan 17, 2024

(original title: Brilliant, but...)

...what's stopping Google from finding these fingerprints, and just mass-blocking them? Also, surely people using devices with a stock ROM and a genuine fingerprint are going to get blocked too, right? Especially if they have an older phone.
(Like, when I first got my Xiaomi phone, my one was already blocked on latest MIUI)

@TheFreeman193
Copy link
Owner

Firstly, Google already knows all of these fingerprints. They know the device properties of every unique hardware/software configuration that's ever interacted with Play Services. If they wanted to mass-block, they wouldn't need this collection, nor any of the other public dumps of device profiles.

The point is that Play Integrity can still tell the difference between real, stock devices and those spoofing a small number of the many properties available to DeviceGuard (either in the property area or in the Java environment). That makes it easy to block device profiles that are being "abused" from passing with software-backed evaluation, forcing hardware key attestation which of course fails. Most importantly, this is possible without affecting real, stock devices presenting those properties.

Xiaomi/Huawei phones with certain ROMs are potentially a different issue, since some of these aren't able to pass even in their stock configurations and I suspect this may be related to some of the conflicts between the USA/China regarding cybersecurity.

Insiders at Google (like John Wu here) have in the past suggested that a lot of the folks there aren't averse to the modding community, but that malicious abuse of Play Services is a much higher priority and blocking one without the other is difficult.

The fact that spoofing a handful of properties with Play Integrity Fix permits a device to pass with software evaluation (MEETS_DEVICE_INTEGRITY) at all is testament to this. If they wanted to, those in charge of the Play Integrity software could prevent this across the board and we'd all be back to square one.

So, in answer to your question: No, this collection isn't more likely than any other (and there are many, as ROM images, extracted build.prop files, or parsed pif.json files) to cause a mass-blocking. It may increase the likelihood of individual device profiles/"fingerprints" being temporarily blocked for software evaluation if lots of people are spamming the Play Integrity servers with them, though.

As an added precaution to avoid overuse (or actual abuse), the ~2000 profiles in this collection are actually a subset of around 40,000 device profiles collected during my research. The idea behind this is that many modders are experienced enough to visit the various dumps, extract the necessary properties, and create their own PIF profiles. This collection has simplified that process by taking a random 5% subset and converting them into compatible PIF profiles, for use by those that don't have the time, experience, or patience to find and create their own. This means that plenty of the profiles in the collection are useless and won't pass DEVICE integrity on any phone. There are, however, many more that will work fine on various devices/ROMs and it's simply a matter of trying some until you find one that passes on your hardware/software configuration.

I still recommend to most that they try to learn the ropes and assemble their own PIF profile; modding is as much a learning opportunity as it is a utility. There are some excellent guides on how to do this, such as this one by osm0sis and another simplified/rewritten by simplepinoi177.

For everyone else, this collection exists so they can still revive old phones, stay secure after an OEM drops support for a device, or otherwise get more from their device without losing what is considered by many core functionality. I hope this information has been helpful!

@TheFreeman193 TheFreeman193 added the question Further information is requested label Jan 18, 2024
@StupidRepo
Copy link
Author

Wow! Thank you for the big response - I read every word! This absoloutely has been helpful and thank you (again!) for the added links at the bottom. Will be sure to check them out :)

@TheFreeman193 TheFreeman193 changed the title Brilliant, but... About mass-blocking of public collections Jan 25, 2024
@TheFreeman193 TheFreeman193 pinned this issue Jan 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants