yashsingh1/xdaforums huggingface dataset:
[Magisk] Captain_Throwback:
Well, if you want to have an unlocked bootloader, root, and also use Google Pay, then it absolutely affects what we can do with our phones (at the very least, it affects what we WANT to do with our phones), which is exactly why we're in this predicament.

I've always been the guy that wanted 'one device to rule them all', even back when people were using flip phones and iPods and GPS units in their cars, and I always had some Windows Mobile device where I could check email and play music and use navigation all in one. When Android Pay first came out, I was an early adopter and it would baffle people when I used my phone to pay, like it was the most magical thing they ever saw.

And now, it may get to the point that I can either keep that magic (much less magical now since Apple Pay exists), OR be able to block ads systemwide and use a custom kernel and whatever other mods I prefer. I just want to have it all; unfortunately the remaining time that is possible may be brief, so I'll have to enjoy it now for as long as it lasts. Ideally, if everyone sticks to using their own found fingerprints, it may last just a little bit longer...
[Magisk] wfred:
Sometimes it's just a matter of luck.

The first two I checked worked, probably another 15 or 20 before I found another. So far I've checked around 60 and have 6 working, but I haven't really been pushing it since the first one I found has been working since v13.3
[Magisk] ipilcher:
I'm a Fedora user. Looking at the PixelFlasher releases, I only see Ubuntu. I almost certainly could build it for Fedora, but it really isn't that hard to copy a JSON file with adb.

I checked the build.props from a lot of firmware dumps, with no luck. The manual process to find, download, and examine the various build.prop files in them is definitely a time suck.
[Magisk] BROKEN1981:
Because she works at a college, a student who is 17, ( smart kid! ) was talking to her about rooting , blocking trackers from big G to government. Basically the kid was selling her fear porn.

I get a call, root my phone and put Ad Away and anti blockers. I'm like WTF? She is a blue dog, the media sells her fear and she buys it. So yeah, I wish I could have kicked that kid where the sun don't shine. LoL
[Magisk] Nodens:
Actually yes they are. This is not about marketing a security API. This is about device lockdown in a model that violates user agency, and admittedly by Google engineers, treats the device owner as a potential threat actor:

(https://issuetracker.google.com/issues/151316418?pli=1). It violates the principles of fair use and device ownership.

It makes a lot of assumptions that have no merit whatsoever in the compsec field (eg Device owner having admin access is a security and privacy threat, when the opposite is actually true).

If you want to have a security solution you go the way of the Secure Boot implementation on UEFI where the user is allowed to sign anything they want with their own keys, import those keys in the trust chain/MOK and have a system that can authenticate bootloaders, kernels, binaries. And something similar IS present on android BUT it is yet again.. untrusted.

There is a big difference between authentication and authorization. The system should authenticate but not authorize. Authorization is the responsibility of the device owner and control of it should by all means remain solely with the device owner. Otherwise the principle of ownership and by extension security and privacy is compromized.

Safetynet, and by extension Play Integrity are designed to sandbox against the device owner and that is the most inappropriate design possible. It is Apple allover again and users have internalized this model, on arguments that are clear logical falacies. Would you accept being told what you can install, what OS or software you can run on your PC? No. Unless you don't own it and its an enterprise system locked down by IT. Yet people accept it on their mobile devices for some nonsensical reason.

There should be legislation protecting against these practices which really have one goal in mind. Establishing pseudomonopolies (the gray area by which you can evade anti-monopoly laws) and locking users in software and/or hardware ecosystems by preventing actual ownership/full control of the device.
[Magisk] nil?:
The bypassing PI with fingerprints of some old devices seems very unreliable. Can we use another approach?

Can we "premine" a lot of tokens for payments and then put the Wallet offline? Maybe for real usage it will be enough.

What about trying to spoof not a phone but a watch for example? Maybe wearable devices have a bit weaker security.
[Magisk] Umgak:
Almost definitely no. They likely have a timeout of no more than a few minutes before they're no good. This is common practice specifically to avoid this exact exploit.
[Magisk] sawdoctor:
The Ubuntu version should work on fedora it works on arch but it's in the aur now. The dev is extremely helpful and if you have any issues hit him up on GitHub and he'll help you build it on fedora
[Magisk] zgfg:
An interesting question. For the smart watch with no SIM card, connected by BT to the phone - whose Integrity matters, phone, watch or both

This article describes the need for "updated Play Services" on both sides:

Tap to pay with your smartwatch - Google Wallet Help

In certain countries or regions, you can use the Google Wallet app on your smartwatch to make contactless payments where Google Pay is accepted. Important: If you have issues with your Google Pixel W

support.google.com
[Magisk] HippoMan:
Yep. Totally agree.

The Googlefrinchians are Blessed Goodness Personified, and we device owners are all the Evil Enemy.

Banks take the same attitude towards us device owners, but only if the device runs Android. They're perfectly happy to let us access our money via unprotected debit cards and rooted Linux, MacOS, and Windows devices that we own.

This means that the policymakers at these banks are Stupidity Personified.
[Magisk] osm0sis:
Lots of talk today about how Google is "clamping down" and making us choose to lock again, etc.

But answer me this, why aren't all prints by default already on Google's spoof-blocked list? Why only ban one at a time? My only conclusion is that they don't want to stop us completely, just make it a little more difficult, and/or give the appearance of doing something to the corporations that care.
[Magisk] zgfg:
'Tokens' (let's call them like that) from Play Integrity cannot be reused.- among others, each has a unique nonce and timestamp uniquely determining the request

And both the original nonce and timestamp are responded in the verdict from G server, signed by the G side private key

Hence you cannot reuse the nonce from another PI verdict BCS they have different nonces and timestamps - app that asked for testing PI will compare the nonce and timestamp in the signed response

And you cannot pair another verdict with the new nonce and timestamp since the signature will not fi.

And you cannot spoof the signature since you don't have their private key
[Magisk] Umgak:
Not to mention that the requesting apk's package name is also part of the request, and it checks that the binary is unmodified. So any "mined" nonces wouldn't be generated from Pay, and wouldn't work. Just to add to the (many) reasons why you can't do this.
[Magisk] Cares:
After updating to 14.2 are there any specific additional steps I need to do? I never used a custom fingerprint. Google Wallet still says my device is not secure.
[Magisk] xSnowLeopardx:
Clear its cache + data, also for Play Store and GPS (not GSF, but really only GPS = Google Play Services).

Then reboot.

Only do this is if you are 100% sure you pass both integrities.
[Magisk] Fishawy:
My guess is similar to yours. If they're all blacklisted by default, then that's it for most - if not all - of the rooting community, who will be shifting elsewhere.

This is not a small community if you observe the numbers of something like XDA users (not to mention 4PDA and other forums). So it would be a loss in revenues nonetheless.

Again, just guessing.
[Magisk] Strephon Alkhalikoi:
The watch.

How do I know? I have an unrooted Galaxy Watch 4 without LTE on my wrist as I type this. I use Google Pay/Wallet on it without an issue.
[Magisk] Fishawy:
Or wait a few hours until the API is refreshed in the background.

Google Wallet is painful when it comes to re-adding bank cards and transport passes. So if it's not critical to do right now, I would suggest wiping only the cache and waiting (only if you're passing BASIC and DEVICE integrity as @xSnowLeopardx said).
[Magisk] Nergal di Cuthah:
If my term gives me this

130|:/ # logcat | grep PIF
12-05 17:11:26.049 12843 12872 D PIF/Java: DroidGuard detected!
12-05 17:11:26.066 12843 12872 D PIF/Java: DroidGuard detected!
12-05 17:11:26.314 12843 12872 D PIF/Native: [ro.vendor.api_level]: 31 -> 23
12-05 17:11:26.394 12843 12872 D PIF/Native: [ro.product.first_api_level]: 31 -> 23
12-05 17:13:05.991 12843 12872 D PIF/Java: DroidGuard detected!
12-05 17:13:06.200 12843 12872 D PIF/Native: [ro.vendor.api_level]: 31 -> 23
12-05 17:13:06.310 12843 12872 D PIF/Native: [ro.product.first_api_level]: 31 -> 23
12-05 17:13:06.351 12843 12872 D PIF/Java: DroidGuard detected!
12-05 17:13:14.304 12843 18023 D PIF/Native: [ro.vendor.api_level]: 31 -> 23
12-05 17:13:14.561 12843 18023 D PIF/Native: [ro.product.first_api_level]: 31 -> 23
^C
130|:/ #

But basic only does that mean i successfully made a pif.json (via pixelflasher) but it is a bad fingerprint

PIF 14.0
[Magisk] DougMG:
I totally agree with being more discreet about all of this. Just my opinion that what caught Google's attention in the first place was discovering that a Pixel 2 print would let everyone pass Strong Integrity and that was something they could not ignore.
[Magisk] HippoMan:
My conjecture is different.

It seems to me that they only show up on the blocked list after having been utilized a large number of times, and this could easily be noticed via a software-implemented algorithm, without any ad hoc human decision-making at all.

These tend to be the ones which have been published and utilized in widely used modules, thereby ensuring that they hit the Googlefrinshian servers frequently and in large quantities that will trigger this automated blocking.

Anyway, that's my own guess.
[Magisk] chiteroman:
Or they may have an algorithm that checks the requests coming to their servers and analyzes those requests and compares them with each other. The results will obviously be different because DroidGuard will send different results depending on each device. The algorithm only has to see that the fingerprint is being abused and after a certain number of "violations" the algorithm decides to ban the fingerprint.

Personally I think Google is playing with us knowing that one day we are going to run out of fingerprints XD.
[Magisk] chiteroman:
We thought the same thing lol 😂
[Magisk] Captain_Throwback:
A favor/arrangement with @topjohnwu, perhaps? 🤔
[Magisk] Fishawy:
Then why speed up the process?
[Magisk] Iridule:
Would be nice to have a dynamic fp that changes randomly once it is blocked and cycles through all known valid prints or generates a valid print that isn't tied to a real device somehow.
[Magisk] intel_core_i7:
It does help, but I could imagine it being quite insignificant since the # of users of PI Fix are way smaller than other custom ROM projects, the current xiaomi.eu project with the latest revision of its ROMs has around 32k downloads, and then you have several more doing the same thing. PI Fix TG group has around 6-8k and to account the users outside the group who root their phones and use this module the most optimistic figure I could give is twice or three times as much, around 20k at most. It is relevant, and there's a fact that # of people using custom ROMs without rooting always outweight # of people root their phones.

One thing I could agree on is that the current way is unsustainable, since it may take up to several hours to update to a newer fingerprint. You wouldn't want to be that unfortunate guy who got stuck in the checkout line because some maintainers living half the globe apart hasn't finished doing their promised job, and mr.G decided to f- everyone up. A better solution needs to be introduced, but the question is, When?
[Magisk] Captain_Throwback:
More important than "when" is "what"...
[Magisk] Nergal di Cuthah:
Because even if you put in the footwork as i have in the last 4 hours looking for and failing multiple fingerprints from known and unknown devices. Many don't fill out the pif standards. And because we are so worried about too many people using the same, no help is offered for us "lazy ignorant noobs" who are trying and failing. Btw I'm tired of being insulted (not by the quoted but by some of the more experienced users) just because i haven't found a fingerprint that works and want to pass.
[Magisk] beeshyams:
N

I haven't really understood the "write build prop dumps into Google....", care to explain please?
[Magisk] Fishawy:
Mate, you're not a lazy ignorant noob, and nobody should ever insult anybody on here or anywhere.

Please try looking for build.prop files inside online dumps, and utilise PixelFlasher to speed up pif.json configuration & test time dramatically.
[Magisk] Nergal di Cuthah:
Thank you for your kind words. All of those insult words come from this thread, from the time of displax's mod failing onward.

Did use a .dev site filled with dumps, and pixel flasher in my 4 hour disappointment
[Magisk] xSnowLeopardx:
Nothing to understand, really. Just do it and see what happened. Put your curious goggles on and see what you can find.
[Magisk] Iridule:
Will the new wallet update affect the pif situation?

"An upcoming change to Google Wallet on Android will see payment notifications originate directly from the app instead of Play services."
[Magisk] joefuf:
I hope not. No idea why, but not having Basic Integrity resulted in my Pixel 7 Pro losing the ability to send/receive RCS chats when rooted. Once I installed Play Integrity Fix 13.9, everything started working just fine.

Haven't updated anything, but I imagine that rebooting will result in RCS breaking again since 13.9 won't work anymore and we're playing this cat and mouse game.
[Magisk] DineshValor:
U mentioned unlimited photo backup!

could u explain it plz I also wanna know it, bcoz lack of backup storage I have been change gmail ids many time to get free storage each time.
[Magisk] Fishawy:
Please report any of those immediately.

This place is about helping people, and has strict rules when it comes to this. It's not a Telegram group where trolls and bullies florish.

Re the prints, try googling build.prop dumps, and explore different websites not just the one you mentioned.
[Magisk] arda99:
because there're usually multi build.prop in a rom dump, and /system/etc/build.prop has the lowest priority, probably not what you're looking for.

Anyway if you see "qtssi" "qssi" "generic" etc.. in any extracted pif field, that's definitely a wrong one.
[Magisk] V0latyle:
Explain to me how Play Integrity providing a more accurate attestation of device security is "locking down" the device?

This ONLY affects Google Mobile Services and apps that use it, specifically those apps that require PI labels.

It does not affect the ability to unlock the bootloader, run custom firmware, or even the ability to use GMS on the device.

They have a lot of merit. We are talking about a platform (environment actually) where apps handling sensitive information are running on a device. You'd use a web browser on your PC to access your bank, and you don't use your PC to perform contactless payments. A rooted device is compromised, because any app with root permissions can access any other app's private data (otherwise prevented by scoped storage) as well as access any other app's memory space.

The only difference between a rootkit and Magisk is that the former is a rogue exploit and the latter is intentional. Granted, Android security features like Verified Boot and DM-verity serve to prevent persistent rootkits, but how many third party app developers trouble themselves to know the difference, and if they do know, how many of those engineering types do you think can convince a bank's mobile software executive that intentionally rooted users are an unlikely threat axis?

Not completely but I get your point

How do you know if the authorization is valid?

Authentication serves to prove that the device is secure.

"Against"?

Play Integrity is not an extension, it is a replacement for SafetyNet. It serves only to provide a secure representation of device security state. As I mentioned previously, a rooted device is a compromised device because security features have been disabled and defeated.

No. Not even close. Apple operates on a walled garden model. Apple devices can only run iOS, and can only run Apple approved apps from the Apple Store.

Google supports Android heavily but does not dictate AOSP. The Android model was designed from the beginning to be open source and developer friendly. AOSP can be decompiled, examined, modified, and reverse engineered at will. Android devices don't even have to run Android, and apps can easily be sideloaded. Custom OS projects like Graphene and Calyx both have their own app stores, using Aurora and Fdroid if I remember correctly.

We aren't talking about the nature of Android though. We aren't talking about Google taking over and locking down Android, which I would agree would be inappropriate, but still isn't the case here. You are complaining that Google's proprietary software - GMS - doesn't cater to rooted users like you and me. You're complaining about being unable to use proprietary Google and third party financial applications in an environment that likely violates those apps' terms of use.
[Magisk] xSnowLeopardx:
Severely off topic, but quite serious: how many multi quote replies in one reply is your record?
[Magisk] Nodens:
Making an educated guess as an engineer who has designed somewhat similar measures before, there are 2 factors most likely involved:

1) The invalidation implementation has possible repercussions (possibility of false positives or other types of).

--This is as certain as it can be, by occam's razor, otherwise the anti-spoofing method would have been applied universally and this would be over instantly until the mechanism is entirely understood.

2) The invalidation mechanism is unreliable so what is important is preventing mass exploitation of spoofing until the flaws in design can be rectified (if possible -- making another educated guess here, it is not. Unless these devices get obsoleted and hardware backed can be set as minimum requirement).

--Since validation can not use hardware attestation for these devices, the method of invalidating fps can be certainly bypassed. We have further proof of this because there are still banned fps in play validating as normal which means the invalidation mechanism is affected by host device environment and can be further exploited that way.

At the end of the day, a handful of technically adept users bypassing lockdown is not important (as much as it's not important for Apple convoluted jailbreaks either). Specially when the process is very convoluted and hard to follow for the average person.

Providing a mass plug and play solution that allows escaping device lockdown is, though. So any possible repercussions are justified.

PS I have a fp btw that validates on my device with 14.1 but not with the v3 of your fork (which I use). I was planning to explore why when I get some free time from work. Want me to pm it to you as well?
[Magisk] Nergal di Cuthah:
Easier to read imo, breaks down commentary to answerable chunks. Only my opinion
[Magisk] TKruzze:
Nowhere near as many as @pndwal could do. :LOL:
[Magisk] ticpu:
I wouldn't use my PC but I sure would use my dumb plastic card that doesn't require an unlock or NIP. This really is the part I don't understand about all this. Why does Google bother trying to make this as foolproof as possible when the physical device for contactless payment has close to no security. </rant>

I sadly found out 3 weeks ago I was also affected by this new wave of security tightening with Pixel Experience. I thought they would only be after rooted devices but alas...
[Magisk] V0latyle:
@pndwal is the king of walls of text, he's even worse than @Oswald Boelcke
[Magisk] osm0sis:
But then why not have all as spoof-blocked in the first place?

Okay, some plausible reasons finally! 😛

Yes, absolutely do PM, since mine is just PROPS-v2.1's backend at the moment, so should work for all properly formatted pif.json files.

With manjaroid the answer was changing his empty "" for FIRST_API to an actual value, and lower it to pass, since his system one wouldn't, and the correct one for his print wouldn't. 14.1 I think swaps in a default value of some kind if the field is empty/missing/too high, so that would account for the differences.

I'd argue the way mine behaves is correct however, i.e do nothing to allow system value. I'm going to test more now to make sure it's behaving as expected though. I am of the opinion now that FIRST_API should be a required field for the json however, since altering it is clearly important for passing on a lot of devices. 👍
[Magisk] makeyourself:
Not many places to shift to and they know it. iPhone? Don't fancy that lol. Which leaves the odd very rare device running Linux, which I know little about (the devices, not Linux) but I suspect cannot be used for contactless payments anyway. Plus in absolute terms the number of people running custom ROMs these days may be quite large. But in relative terms its a mere drop in the ocean to Google, must be less than 1% of all Android users. So does Google really care about less than 1% of its user base if they've got banks and multi-national corporations who want something done? I doubt it.
[Magisk] Fishawy:
An attempt for a consolidated Simplified Guide to obtain your own private fingerprint.

1. Google "build.prop dumps".

2. There will be many websites to explore. This is for you to try and test. Perhaps avoid downloading entrie ROMs - if not desparate - to save time and bandwidth.

3. On some websites, you'll see a list of devices, under each you may find build.prop files undr different paths (i.e, /system/build.prop, /vendor/build.prop, or /etc/build.prop). Start with /system and see if you can download the file. Eventually you'll end up saving build.prop on your computer.

4. It is advised to avoid fingerprints with names like 'generic' or 'testing'.

5. Obviously you will have the PlayIntegrityFork module installed (since the PlayIntegrityFix module doesn't support custom fingerprint now). You can get it from here.

6. Use the PixelFlasher tool for loading/testing purposes with 4 simple clicks to load the phone, and another 4 to load & test the print (screenshots with description here).

7. Most likely, your first attempt(s) won't be successful. You'll either get only BASIC integrity or none at all. Repeat until you find one that meets both BASIC and DEVICE integrity.

8. Once a good one is found, that file is automatically located under /data/adb/modules/playintegrityfix/, named custom.pif.json. Feel free to copy that elsewhere as a backup.

@badabing2003 @osm0sis Please correct me if I'm wrong about step 8, or add any other necessary amendments.

I'm not a dev or a PIF expert, just your average user practicing trial and error after some reading, and it works.

Hope this helps somebody.
[Magisk] BROKEN1981:
So you know all of this and yet make it easier for Google.

Literally can't make this up....it's clown world....