yashsingh1/xdaforums huggingface dataset:
[Magisk] zgfg:
Already answered earlier today

Nobody can know for 100%, but if you have a collection with eg two hundredths of working JSON files and if you (automatically) retest them (eg, over night), then you can monitor how and if they get banned. So I did. Also if you monitor the related forums and threads to see when Google bans (usually on Mondays) and which users got affected at the given time and which module/injector app was re-released to replace the banned spoofs

Also, don't count on the posts asking like, "I switch from this fork to the other, from this module version to the other and my previous custom json does no more work".

Usually they don't examine logcat to find if their new module properly reads json from the new path they had to put the json file, how the module react and treat missing fields (forcing the hard-coded default values or staying with what you have on your phone/ROM), how it deals with some syntax errors in the JSON files (by reading the JSON or the part of that or by aborting to read and use the json - so how does it affect the final prints it will use or not). There are also problems with shadow-hook for Pixel users who upgraded to the latest A14 Beta

But these issues and artefacts are not really about are the certain prints 'banned' or not

---

Eg, prints/spoofs built-in to the PIF can be easily found. Yet, those from the last version are still not banned while on the other side, spoofs that Xiaomi.eu injector uses (source code is not available) got already banned two times in the same timeframe.

So what's the difference -Xiaomi.ue have more users and most of them switched from Magisk + PIF to the Xiaomi.eu injector, and many PIF users here have dispersed to use the custom json/spoofs. Hence the G attention has been temporarily switched to the side where the same spoofed prints are used with the more users
[Magisk] zgfg:
There is only a few percent statistical chances that by playing with your own FP (and testing the lower FIRST_API_LEVEL) that you will make a JSON to passing Basic and Device Integrity. Besides, instead of asking - make it and test it (guides and tools were posted in this thread)

Better find the repo with the ready JSON files or with the build props and make yourself the JSON files (guides and tools are published in this thread), install the tools you need to test and start testing. Once you test 30-50 of them, you will for sure find your own custom JSON file that will work
[Magisk] FIERA03:
I argued the same thing in Telegram, but that opinion was accused of me being self-centered against the backdrop of beginner et al(I think they're noob, but critics may not have liked those words.).

Of course, chiteroman did not join in this accusation, but I am sure he has given up on the most fundamental treatment.
[Magisk] zgfg:
IDK, it can be specific to the phone/ROM (that's why it is always important to provide the info in the first place) and Magisk, maybe some other module...

Try with the uninstalled/disabled PIF - if it continues to fail, then it's not caused by PIF
[Magisk] FIERA03:
I won't describe here what to edit, but I will report that there are several smartphone's props (released last year or this year) where the DEVICE pass with just a few modifications.
[Magisk] mike.s:
And yet, those fingerprints are easily discovered, as the posts here saying xiaomi.eu and chiteroman are using the same ones proves.

Correlation is not causation. You haven't said anything to prove banning is caused by use by lots of people.
[Magisk] V0latyle:
Google can only implement this requirement for their own apps. Sure, they could change Play Integrity to where it will only pass when hardware backed attestation is available, but as we've discussed before, this would leave everyone running older Android versions (pre 8.0) unable to use any apps that use the API. So, it's very unlikely, as Google has been pretty adamant about maintaining legacy support.

As stated above, they won't do this.

They're not angry and they don't have it out for us. A few members in this forum have talked to Google employees on the PI team, who said in no uncertain terms that they aren't trying to screw us. They just want us to be more creative.

I personally doubt they're going to these lengths. It's my opinion that all detection and countermeasures are done from their end.

Or...The fact that a lot of people are using the same prints.

As I described previously it would be easy to filter PI verdict requests to a few particular known apps (such as Play Integrity API Checker) and simply look for a common print.

We don't know either way. But, I personally find it more likely that they monitor things from their own side, instead of paying people to infiltrate forums like this and decompile third party modules to trigger mismatch detection on particular prints.

You're not wrong. People are selfish and entitled. I don't particularly care who this offends; if the shoe fits, wear it.

And there's nothing to prove the other way, either. Don't be confrontational. We are all speculating here, and trying to attack someone's speculative argument when the alternative is also conjecture serves no purpose.
[Magisk] zgfg:
And you haven't proved to the contrary. So pointless arguing (II will no more follow up)
[Magisk] mike.s:
I have nothing to prove. My only claim was that we don't know that bans are based on use.
[Magisk] V0latyle:
We don't know the bans are not based on use, either.

Personally I think it's the most likely possibility.
[Magisk] HippoMan:
Agreed that they're not out to get us. But also, on the whole, the Googlefrinchians just don't care much about us modders, one way or the other.

There are something like two billion Android-based devices in the world, and we modders' devices make up something like 0.01 percent or less of that total. The Googlefrinchians are pursuing their corporate goals and priorities, and we are like a few tiny crumbs on their path. If we happen to be in their way, they'll just walk all over us while barely noticing our existence.

Their recent integrity-checking changes that are causing us so much grief are just another example of this.
[Magisk] HippoMan:
Yes, we don't have conclusive evidence of this, one way or the other. However, I would be willing to bet that FP use is indeed a significant factor within their banana-ing strategies.

Also, it would take one Googlefrinchian employee only something like 5 or 10 minutes a week to periodically check the latest releases of PIF and see which FP's are currently being mass-propagated in any of these PIF releases, and then to add these FP's to the official banana-ing list.

I would also be willing to bet that this is another part of their strategy.
[Magisk] xSnowLeopardx:
Bought something with GWallet today. All good. :cool:
[Magisk] majorfigjam:
I guess they'd be looking closely at how Nvidia may have managed to sell thousands of old Android televisions across the world so quickly, and wondering whether that might adversely affect Chromecast sales in future.
[Magisk] sawdoctor:
There's an xposed mod you can try if you can't get a working fingerprint. Hit me up if you can't find it
[Magisk] husharon:
I can use fingerprint, but I can't use Google pay.
[Magisk] HippoMan:
If I'm not mistaken, they have ways to go beyond Droidguard, which itself only checks the supplied fingerprint that is being sent by PIF. I'm pretty sure they also can check whether the FP being sent corresponds to the same device (or maybe at least type of device) that is actually running. If so, they could tell, for example, whether or not a given submitted FP is actually coming from an Android TV.
[Magisk] Nergal di Cuthah:
Not that fingerprint (not fingerprint reader) a "fingerprint" in this usage means details of a android rom that trick Play integrity into a software based assessment.
[Magisk] Shadowscape:
If Google actually cared to check, we'd be blown out of the water by a simple verification against the device hardware. How hard do you think it is to figure out a manufacturer based on the collection of components in the phone (modem, cpu, memory, display, storage etc.) and then impose a fingerprint match?

There are two use cases for rooted phones IMHO. The first one is the enthusiasts - that would be us - we do it because we want that extra degree of control of our hardware. When the extra hoops show up, we'll grumble, look around and figure out the extra jumps, then we'll go about our day.

The second one is compromised hardware, where root is being used for actual security breaches, surveillance etc. Breaking root methods with updates actually makes a lot of sense if you want to catch those. As much as I hate to admit it, a ban on published methods of bypassing integrity checks is actually good security practice. So don't expect those to disappear anytime soon.

We should enjoy the freedom while we can. At some point, through sheer attrition, all those devices without the necessary hardware for security assessment will fall out of support, and the jig will be up. Until then, happy fingerprinting ;)
[Magisk] husharon:
Ok, can u send me this mod?
[Magisk] sawdoctor:
I'll send it you now but you need xposed obviously and no idea how long the print will last
[Magisk] Clasimodo:
What mod are we talking about, please? I'm interested.
[Magisk] Nergal di Cuthah:
Can i send you what mod? I'm only trying to clarify the difference between your misunderstanding of our chosen word fingerprint, i think some languages would say footprint instead, making confusion less obtainable.

Edit: it's all good i saw the above answers to you.
[Magisk] HippoMan:
Agreed. However, as far as I know, there is no evidence of any fraud having ever been committed through the use of any facilities that go along with rooted or modded Android devices.

Banks are therefore completely overreacting about blocking transactions on devices that the Googlefrinchian software reports as being rooted or modded.

These same banks gladly issue us plastic debit and credit cards which can be easily used for contactless transactions without any extra security measures. But these banks prohibit those same debit and credit cards from being used for contactless transactions via Wallet and GPay on modded Android devices.

And indeed there is some documented fraud via the use of plastic debit and credit cards which, again, have no special security measures associated with them. Something like 0.01 percent of Android devices are rooted or modded, and so these banks are going all out to prevent fraud that so far has never occurred within this tiny fraction of their client base, while doing nothing whatsoever to try to prevent fraud in the same way via the millions, if not billions, of plastic debit and credit cards that they readily issue.

In my opinion, this is a combination of stupidity and laziness on the part of these banks.

Rooted/modded Android devices are low-hanging fruit, because it's relatively inexpensive in terms of money and also employee-hours for the banks to use some cheap software to target this miniscule group of devices. Then, bank management can go to the stockholders and investors and say something like, "See! We are really, really serious about security, because we are making huge, massive, gargantuan efforts to block contactless transactions with our bank via rooted and modded Android devices!"

If anyone confronts these bank executives with the argument that I made above about how the billions of plastic versions these same bank cards are regularly being used for contactless payments without any of the kind of security that they are trying to enforce via Android, I wouldn't be a bit surprised if these executives start weaseling with BS that might go something like the following: "Uh ... oh ... well ... um ... uh, that's ... um ... that's different ... yes ... it's different ... and ... Oh! I just remembered that I have a meeting right now! Get in touch with my assistant to get on my calendar in the future, so we can discuss this more later."
[Magisk] majorfigjam:
I'm sure they do, as compromised prints still work on truly matching devices, so they must go to "stage 2 triage" to be blocked. My guess is a simple filter - if print is flagged for high use, then check a bit more, else let it go for now.

Best way to avoid that filter for now is to use a different print to the masses.

Eventually though they will bring in stage 2 for everyone, and then we'll have to find a new way round the blocks.
[Magisk] HippoMan:
Agreed.
[Magisk] DoReMeFa:
Too right.

I have no problems accessing my bank on my computer pin which I have admin (rooted if you will) rights. My banks website works fine on my rooted phone, and their stupid app has a hissy when used on the same rooted phone.

That makes zero sense to me.
[Magisk] HippoMan:
And what makes even less than zero sense is that these same banks allow us to access their services via web interfaces on our Android devices in the same way that we can access their services via web interfaces on our desktop machines, but they also issue us Android apps which offer the same features as the web interfaces, but which are crippled when run on Android devices that are rooted or modded.

In the rare cases where I need to access my bank's services via my rooted Android device, I just do it without any restrictions via an Android web browser.
[Magisk] pndwal:
Can't see how/why they could/would do that... DEVICE_INTEGRITY label needs to work on BASIC-only (userspace based) attestation devices after all...

As I've said before, we can potentially spoof anything in userspace, and Google knows this too...

Of course we still need to discover what cross-checks allow Google to distinguish between stock unlocked and modded devices that spoof (which frankly have no business passing DEVICE_INTEGRITY, read CTS/VTS matched profiles, anyway) since Google could at least quite easily apply these checks (which clearly don't impact locked/stock devices using the same print props in the wild) across the board AFAICS...

Apart from understanding this and potentially having all "banned" (but still CTS/VTS certified) prints available for spoofing again which seems to be a more important priority than the current print 'mining' efforts, it also baffles me that Google have (out of kindness to this community?) not applied the same cross-checks to all prints as it certainly seems there's no issue "banning" any when abuse is noted... It also seems like more work this way, but maybe they really don't want to stop us completely?... Are they just giving us wriggle room while we discover the new cross-check algorithm(s)?... Because I can't see why that's even necessary if not on purpose... 🤔

Anyway, Thanks Google! 🙃 PW
[Magisk] HippoMan:
In my opinion, it has nothing to do with kindness. We modders represent probably less than 0.01 percent of Android users, and we just don't matter one way or the other to the Googlefrinchian powers that be, and they generally are just ignoring us. We're like a small group of tiny insects on the path they are trodding on regarding their corporation's goals and policies, and they generally don't even see us, and they often just end up blindly walking all over us in the pursuit of these goals and policies.

Yes, there are no doubt individuals who happen to be on the Googlefrinchian payroll who are aware of us and who perhaps offer some personal expressions of understanding and sympathy to us. However, these people are just small cogs in the big, corporate Googlefrinchian wheel which just keeps rumbling along without giving any notice to the way that these corporate policies might affect such a minuscule group of Android users like us.
[Magisk] zgfg:
Yeah. That's the most intriguing me

1) How they distinguish genuine attestation request/prints from the 'banned' phone & ROM vs. the attestation request from the phone spoofing those banned prints - so that they can pass the first and ban the second

2) Why they still need several days to ban the new spoofs from the newly released PIF module

3) Why they don't apply the same algorithm to generally distinguish genuine request and prints from the spoofed ones. In that case they will no more need to ban one by one FINGERPRINT, they will ban all at once

Regarding (3), it seems that there are still too many imperfections and uncertainties in that algorithm (due to the differences in Android versions and the corresponding requirements, and their vendor implementation on the other side), with the risk for false positive 'detection' of cheaters, that could result that genuine users would receive failed verdicts

That could then also explain the (2), they maybe do simulations for each new particular ROM/Fingerprint before they turn the algorithm on for those newly released spoofs

They were already embarrassed with that episode with the spoofed Strong Integrity passes

Now, they must avoid by all costs the embarrassment from the other side, the case that genuine users (with the not-modded phones) start complaining that they could no more using Wallet and other services/apps as being false positive banned

Hence I'm also curious what if PIF module would not use spoofs from the Google's phones but from some eg Japanese only brands. Google would have much harder times to polish the algorithm for (1), thus prolonging the count-down days from (2)
[Magisk] purgy:
It would be so trivial to lock us all out, that it's either deliberate, or unbelievably lazy lol.
[Magisk] Iridule:
Randomly from dump site or from a ROM you had with a device?
[Magisk] HippoMan:
Start the bidding war!
[Magisk] Shadowscape:
I'm with you guys. Easiest fix in the world would be to get one dialog on startup - every startup, I don't care - where I can confirm that I rooted my phone and I won't hold anyone liable for the consequences. That's the true meaning of root: full access, no holds barred.

At least on Pixels I'm spared that whole Knox nonsense. Google did do a remarcable job opening up the bootloader, so they're not exactly opposed to the root idea. I just wish they didn't stop half way.
[Magisk] ArzZenic:
Yeah, this would be awesome, unfortunately this will never be done, even through EU consumer laws.

I'd like to be 6ft blonde girl with 6pack, but you know, as the great philosopher Jagger once said.. "you (we) can't always get, what you (we) want" :D
[Magisk] xcl1pse:
1 month already passed and my first own fps still working and not getting banned. Heck I even still using PIF 13.1 :)
[Magisk] Fishawy:
Pixel 7 Pro, and I saw another post below mine stating a Xiaomi device. Most reports on Reddit were Pixels. It's across the board.

Managed to resolve mine with a factory reset anyway, since Safe Mode and uninstalling updates didn't work.
[Magisk] chiteroman:
Don't share nonce (testId), Google can track the request and ban your fp.
[Magisk] xcl1pse:
No problem, since I use that fp for testing and based on my daily activity seem like I dont care again about device integrity
[Magisk] pndwal:
For keystore/AVB chain of trust busted device only, or works for others? PW
[Magisk] pndwal:
That's where I believe you're quite wrong...

Google has long been in the game of supporting unlocking, custom ROMs/kernels/mods, Unverified/SelfSigned boot states, even an official whitelist to allow use of proprietary GApps (GMS suite) with custom ROMs on uncertified (eg Chinese region) devices!...

This is intentionally and organisationally, clearly in line with corporate policy, and not just the whim of individual Googlers.

Further, after backtracking on their historical cease and desist order to Steve Kondik, they fairly bent over backwards to make amends, clarifying that they were actually quite happy for modders to run GApps on their (non CTS compliant) devices with custom ROMs just as long as the end user installs (sideloads) these and they are not bundled with CM or other such ROMs... That's why Steve didn't quit (seems he almost did), the CyanogenMod project continued --> LOS and so many other ROMs/forks/ports, and also why Google have happily allowed projects like OpenGApps to exist... It's also part of Android's mod-rich history, Google knows it and has even implemented many innovations from custom mods in official AOSP...

Regarding intentionally manipulating expected (security) signals to spoof certified devices, Google will never admit to sanctioning this, but there's just too many indications that they are less than wholehearted in preventing at least userspace spoofing of these same signals (I/others can see many ways they could have shut this thing down years ago if that was their intention/aim) to ignore... In other words, I really believe they never intended to make DEVICE_INTEGRITY meet requirements for a strongly attested verdict which is essentially what many are scared of...

Once the banks begin implementing that big white elephant that is PI STRONG_INTEGRITY however, all bets will be off. 😆

🤠 PW
[Magisk] thatsupnow:
Hey guys I switched up to a pixel 8 it's rooted and I had everything setup the same as my pixel 7 but for whatever reason my 8 gets a cts profile mismatch. I'm using the latest PIF module 14.5, is this a known issue? I didn't check my 7 before wiping it but last I knew it passed safetynet checks and device was certified.

Thanks for the help guys
[Magisk] sawdoctor:
Are you running android beta by any chance? If so try with PIF 14
[Magisk] simplepinoi177:
If the fingerprint hasn't been burned, initially after finding my own working fingerprint, Wallet would still not allow Tap to Pay and/or add a card or anything, I had to clear data on the 4 Play services (Protect, Store, Services, Google Framework) and I am now able to Tap to Pay, but I had to re-add my cards once again though (as clearing Services does that...)

That may be, but it can reasonably and logically assumed with the biggest and most primary difference between the Xiaomi ROMs/chiteroman's fingerprint and the ones that are personally mined is that it's "use by lots of people"...
[Magisk] woody4165:
Ok thanks, just a quick question, should I clear data of 4 play services every time I upgrade this magisk module?

I don't find any protect app in the app list,also showing system apps. What do you mean by clearing Protect?

Thanks
[Magisk] simplepinoi177:
You should really only clear data on those if you're having issues with Google Wallet or other Google services...

If you show system apps, they should be under Play Store, Play Protect, Google Play Services, and Google Framework. The last 2 are probably what's most needed/necessary, the other 2 are just for good measure....

this will remove cards from Wallet, just be warned...
[Magisk] Clarnc:
14.5 rip
[Magisk] frank93:
okay, after reading this term here in this thread for weeks, i HAVE to ask: what’s a "frinchian"? is that a pun or something? is it a play on .. another word? english is only me second language, sorry, but - what am i missing? is it that kind of humor like "mickeysoft" instead of "microsoft", as we used to do it in the 1990s? somebody please enlighten me. honest question.
[Magisk] blu.italia:
Yes. True.

But can someone explain the technical process why Google Wallet need some time to realize that we lost the integrity and we can use it now anymore for a few hours or days to pay our shopping bill?
[Magisk] Clarnc:
Maybe it checks the integrity after each nfc transaction, i've not payed for several days after blocking current fp, and was able to do just one transaction before it gets blocked
[Magisk] Vision:
Not joking this time? If not good work 👍

View attachment 6046032View attachment 6046033
[Magisk] Imnoa:
Another one bites the dust

Another print bites the dust

And another one gone, and another one gone

Another print bites the dust

Hey, We're gonna run out soon

Another print bites the dust
[Magisk] Joly0:
Hey guys, i installed PIF and configured everything correctly. I cleared data of play store, services, framework and wallet and wallet is still not working. It says, i do not meet the security standards. Google play store also says "Play Protect certification: Device is not certified".

I checked with SafetyNet Test and i pass everything. Also yasnac shows all passed. So whats going on?