yashsingh1/xdaforums huggingface dataset:
[Magisk] jabennett:
That would certainly be better than a simple Github repo or something, by at least "load-balancing" the fingerprints in use. But the simple fact is, the more people use this module, the bigger target it becomes. We've already reached "critical mass" this past week or so, with someone at Google now actively trying to stomp this out on a daily (or *more* frequent!) basis.

Honestly, culling whatever percentage of former users are no longer willing or able to deal with the new manual configuration, may be the best chance of long-term viability for those of us who are. We're dealing with a finite, dwindling resource here, and our usage has grown large enough to attract a lot of negative attention from the folks trying to shut it down.
[Magisk] TheRealModder:
The second point tho...

How are we supposed to pin point the good fp? I can't just download every firmware from the entire world just to use their props and test it one-by-one. Heck i even followed the osmosis guide of finding a good fp and the best i can do is BASIC_INTEGRITY.

And even then not everyone can extract a props from a firmware, i seen most of the people on the PlayIntegrityFix chat on telegram confused on how can they find a good fp and even that, they don't know how to place the json properly.
[Magisk] pndwal:
Generally can just check print device in GSM Arena for original value... First/launch OS = first API level... But other values will offer work in addition... PW
[Magisk] Immortalis:
Yeah, if something changes then I can definitely drop a message, since I do use GPay with NFC.

If Google declared war on YouTube adblockers and Android modders, then I'm going to fight.

They definitely dropped "don't" from their motto
[Magisk] dcarvil:
Where is First/launch OS in GSM Arena? I have not been able to find it on that site.

Thanks.
[Magisk] V0latyle:
The module itself isn't the issue. The prints are. So, by everyone finding their own, we're avoiding attracting attention to a few particular prints.

Read osm0sis guide again, he laid out the criteria that helps narrow down which ones to check
[Magisk] fossbin:
It really is a trial and error process, I was lucky enough to get it within 5 tries. Still everyone should look for their own prints, we're gonna run out of them and sooner if this is how it's gonna go.
[Magisk] jabennett:
Right. That was the point I was trying to make, if it wasn't clear. The module is simply a point of consolidation and amplification if it continues to try to provide fingerprints itself.
[Magisk] david003:
I'm just using LineageOS with MicroG, trying to get the old safetynet attestation/basic integrity & CTS profile match to work. I went back to

safetynet-fix-v2.4.0-MOD_1.3-microG and it still works.
[Magisk] Hisucchi:
Had an old device still lying around, only used for controlling the robot vacuum. Worked right away, phew... For how long though 🤷
[Magisk] jabennett:
Longer than if you or chiteroman shared it with a few thousand of your closest friends, for sure. 😁
[Magisk] beeshyams:
Call it a dumb question

On Pixel 6a, with stock, rooted

After failing the device integrity, I checked Play Store and and it says certified. All my banking apps work including those requiring finger print

1.Is this is a temporary thing till some app/Google server refresh takes place?

2. If this is a permanent feature, it's fine for me.. If banks start demanding device security, will use laptop instead.

Getting sick and tired of this game. Been rooting since 4.2 and now on 14.. Maybe time to quit?
[Magisk] V0latyle:
Yeah...

We don't really know if Google is monitoring this, because it does seem kinda far fetched for them to go to the trouble of looking through the source of a module or decompiling the module

But just in case...Best to remove the possibility because it does seem that since previous versions of the module stopped working for almost everyone at the same time, Google was targeting specific prints for mismatches

I don't doubt that they'll eventually reinforce Play Integrity to check for mismatch on EVERY device but until then we might as well make it as difficult as we can for them
[Magisk] HippoMan:
As for their erstwhile "Don't be evil" motto ...

Ever since I first heard that old motto of theirs, I've been stating that "evil" consists of things like raping and murdering children, genocide, etc. Saying that they aren't being evil is setting an extremely low bar, and it leaves them open to all sorts of other kinds of malfeasance.

And they've even abandoned that "Don't be evil motto"!

:)

Yes, I know that back then, Microsoft was being labeled as "evil", and so the original motto actually was just some marketing hogwash which meant something like, "We're not going to be as bad as Microsoft". But anyway, nowadays, I don't see much difference between them and Microsoft, w/r/t malfeasance.
[Magisk] V0latyle:
Yes, if you clear Play Store data you'll probably stop seeing Play certified

Or we will just have to accept that doing any sort of financial stuff on rooted devices is going to be less convenient than "secure" devices and we aren't going to have access to the same features
[Magisk] HippoMan:
That's why I suggested above that we start publishing lots and lots of deliberately non-functional prints here and pretend that we're testing them, approving of some of them, rejecting others, commenting on them, admonishing each other to please not publish valid prints like those, etc. ... just like we are doing here now.
[Magisk] V0latyle:
Seems like more work than it's worth
[Magisk] beeshyams:
Thanks for your clarification

I am not going to clear Play Store data, just to check.. If that gets refreshed, let's see.. They aren't likely to kill their own product (Gpay), which is immensely popular in a huge country like India. Practically all use it including push cart vendors... Or maybe it's my optimism talking

I guess I am ready to quit this rooting game or use alternative strategy of using PixelFlasher to flash unrooted stock on one slot, use boot control app to switch to that slot when I am traveling (which isn't much), come back home and use PixelFlasher to switch to rooted slot
[Magisk] TKruzze:
We're all kidding ourselves if you think that Google is monitoring the specifics of what we're doing here.

My guess is that they've algorithmicly programmed their servers to monitor print mismatches and when one reaches a certain level, it's bananaed.
[Magisk] miho171:
I lost the device integrity in my rooted stock rom today, just the basic passes, but cleared multiple times cache and data of g services, many rebooting and play store still certified, banks apps working as crypto wallets and exchanges, no issue with the fingerprint. The only annoying thing is g wallet.
[Magisk] pndwal:
It is actually important as these props remain quite usable for our purposes...

Critically, this means that the pool of usable props is NOT actually diminishing at all despite the common conclusion to the contrary based on the erroneous perception that these prints have been banned for BASIC-only evaluationType verdict purposes... It just isn't as simple as stating that a fingerptint prop is 'banned'...

Guess we could dumb down 'Google Introduced new measures to prevent prints being used in other devices for spoofing purposes' to 'Google have attempted to ban unauthorised use of these prints to achieve DEVICE_INTEGRITY'... (The prints were authored to certify specific compliant devices and configurations.)

Or 'attempted to reject, refuse, prevent, block, disallow'... Not 'depreciate'. 😬

... As Google certainly haven't banned use of the prints themselves (requisite CTS/VTS compliance has NOT been invalidated), we simply need to discover what additional device properties Google now is cross-checking when validating their use and spoof these in addition to be able to achieve DEVICE_INTEGRITY on our AVB Unverified (unlocked) or SelfSigned (locked with system signed with custom keys) devices.

This is certainly achievable (not a pipe dream) as there's NO strong (hardware keystore backed) attestations associated with prop combinations not employed for HARDWARE_BACKED evaluationType enforcement... The signals all effectively derive from userspace... We can potentially spoof anything required in userspace...

Google could and have banned any number of prints for BASIC-only evaluationType use; that's exactly what HARDWARE_BACKED evaluationType enforcement does!

But they've exempted other fingerprint props including those being describing here as banned on purpose! Nb. This assumes use with other props having expected values... We just need to discover what they're expecting...

🤠 PW
[Magisk] HippoMan:
Instead of the word "banned", I, for one, am in favor of using the term "banana-ed" here to mean exactly the same as "attempted to ban unauthorised use of these prints to achieve DEVICE_INTEGRITY", and it requires much less typing than the full phrase.
[Magisk] Nergal di Cuthah:
Fun as that sounds but will spawn thousands of "dont werk fer me" (sic) posts
[Magisk] HippoMan:
I know, and that would further gum up the works for the Googlefrinchians.

But yes, I guess it's really not workable.
[Magisk] pndwal:
Just killing GMS Droidguard attestation process will work instead of rebooting... Method was given by OP and others... PW
[Magisk] osm0sis:
My exact sentiments. Thank you.

Everyone finding their own doesn't produce any obvious red flags to trigger them to "banana" them. I'm still on my first print that I found back when the very first pif.prop build was released, and I bet I'll be on it for a very long while unless Google significantly ups the ante again.

BTW, my fork is live with CI, fixed a whole lot of badly set up repo and IDE issues, restored the older deleted commit history, and got a release out:

GitHub - osm0sis/PlayIntegrityFork: Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props

Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props - osm0sis/PlayIntegrityFork

github.com

A quick reminder:

And with that, I'll bid adieu to this garbage fire thread. :p
[Magisk] BROKEN1981:
I don't understand any of it. I've read the huge guide that said " here noobs" which was a complete turn off.....
[Magisk] locolyric:
what if they use the GPT to analyse and get what they want to know
[Magisk] BROKEN1981:
Of course you would like that.... It's their company and they can run it however they like, even if we don't like it.

{Mod edit: Political statements not accepted on XDA thus removed! Oswald Boelcke, Senior Moderator}
[Magisk] Nergal di Cuthah:
Can we cool down on rhetoric and stick to bananas?
[Magisk] pndwal:
No, but Shawn Wilden did make such a proposition to Luca Stefani of LineageOS way back... See:

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-88762227

..Shawn's suggestion was that "perhaps what we need to do is to find a way for third-party ROMs to get approved, after proving that they pass the compliance tests and don't subvert the security model..." and Luca's response that it may be "doable"?... The original post was here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-82011917

and the twitter link:

www.twitter.com/luca020400/status/1238159758319931392

Sad it didn't seem to get traction...

Luca pointed out "The bigger issues come from our devices being unlocked with verity disabled to allow users to flash "addons" (see gapps, we can't/won't ship them). Also the fact most of the devices we support can't be relocked using our own personal private keys it would be an hassle to bring security to them."

Of course with CTS/VTS and Google now assigning keys, devices could be locked with such certified LineageOS and GApps legitimately bundled, but if users want Magisk etc they'd need to unlock and spoof in order to pass DEVICE_INTEGRITY just like we're doing...

It's doubtful other custom projects will receive such an offer unless they can demonstrate a policy of/dedication to never manipulating expected signals (ie never spoofing these), especially security/integrity related ones, like LineageOS's...

Well even if a custom ROM were to obtain CTS/VTS compliant fingerprint props, the same difficulties would apply to using these on any AVB Unverified (unlocked) or SelfSigned device...

Most custom ROM/custom mod users run with Unverified boot state... Special considerations must be met to run SelfSigned (locked) systems... And I'm not sure why running SelfSigned might make a device 'not capable of hardware backed attestation'...

Anyway, hope this clears thing up a bit. 🙂 PW
[Magisk] mattburga1984:
Thank you very much for this.
[Magisk] miho171:
Maybe I'm too stupid to understand, but why I need a PC to edit the pif.json file in a rooted phone?
[Magisk] Umgak:
You don't. You can edit it with a terminal emulator, with an Android file explorer like Material Files or FX File Explorer, or push it via adb from your PC. All options work and are equally valid.
[Magisk] V0latyle:
Won't work, because bootloader is unlocked. Unrooted slot will fail all 3 PI verdicts.

Root isn't the problem. The bootloader is. PI uses hardware attestation by default so when the hardware says the bootloader is unlocked, PI fails all 3 labels

That does make sense, and still supports the idea that we should all find our own to use

I think I got a little ahead of myself.

My thinking was originally "Ok, they are finding the mismatches between the OEM prints we are spoofing, so what if we spoof a print that by design isn't going to match"

But

I'm an idiot because there would still be a mismatch unless we were actually running the firmware with that print

It just occurred to me that it might actually be easier for pre Android 8 users to pass PI right now because they don't have to spoof prints at all!!

You don't

Assuming you have the print values you need, you can just edit pif.json in a text editor. I used Root Explorer
[Magisk] HRSE:
Why is Google so bitter with GPay? We are not cheating anyone's money though? I thought the more users GPay have, the better GPay can compete with ApplePay and others?
[Magisk] sir_bazz:
Thank you for your continued sharing of tools and knowledge with the xda community man.
[Magisk] miho171:
thank you, to clarify, since I have a stock rom rooted, could be doable by inserting the /system/build.props values of the device itself?
[Magisk] Nergal di Cuthah:
Darn you google this is what you've reduced us toView attachment 6039215
[Magisk] Umgak:
If you use your own device's values, it will be forced to use HARDWARE_BACKED attestation type, which will fail. You will have to use an older device (roughly, one which launched with Android 7-8 but was upgradable to 9+) to prevent it from using HARDWARE_BACKED or you will fail.
[Magisk] BillGoss:
The same reason banks are so serious about counterfeiting paper money (so they make money difficult to copy) and banks are serious about credit card chip security (so they make the chip really secure and locked down) and banks and Google are serious about using a phone as a credit card replacement - the phone has to be just a secure as the chip in the card - so locked bootloader and TEE based encryption.

And then we unlock the bootloader and the phone can no longer be trusted to secure the payment transaction.

Personally, I think Google is totally correct in making it impossible to perform secure card transactions if the phone's security has been compromised.

I root my phone mainly because I want a decent backup of my apps using programs like Swift Backup and because I like to use custom ROMs.

I don't expect to be able to do card transactions if my phone isn't secure. The fact that we can make the phone pretend to be secure when it isn't is something Google needs to and should fix.

I wouldn't want someone to be able to spoof my credit card using an unlocked phone.
[Magisk] HRSE:
You mean I can cheat your money with my rooted phone?

Someone please PM me how to do that. For research purpose, of course.
[Magisk] HippoMan:
I wrote a couple of scripts to (1) create a new PIF installation zip file which contains a new pif.json that is either directly supplied, or which it will generate from a directly supplied file containing build props; and (2) to quickly install the new PIF zip file and start using it.

Please see this thread ...

https://xdaforums.com/t/two-scripts...ops-or-a-pif-json-input.4643880/post-89194328

... and PLEASE (!!!) read the ENTIRE (!!!) OP of that thread CAREFULLY before attempting to do anything at all with those scripts and before asking me any questions.

I hope these scripts might be useful.

I know that @badabing2003 has written the excellent PixelFlasher utility to supply functionality similar to what I have written in those scripts, plus a LOT (!!!!!!!!!) more.

My scripts are just "quick and dirty" command-line utilities to perform the functions I mentioned, and they are not intended to replace the PixelFlasher utility. I sometimes want to just quickly invoke cli-only runs.

These scripts also can possibly be incorporated into other software.
[Magisk] rockingondrums:
This is (or maybe was) a false narrative. Google Wallet (which was an NFC based mobile payment system) launched approx 6-7 years before Apple Pay. Google handled everything on the back end. It didn't require your financial institution to participate. I regularly dropped jaws of various employees of Walgreens, Petco, and Peet's Coffee.

As per usual, Apple ruined everything when they entered the game. Once they started doing it, everyone wanted to participate, but on their own fragmented terms. Then we got an era of waiting for our institutions to join, and the credit union I use to this day still requires I call in to a live person during business hours to verify mobile pay apps.

I am confident that <0.001% of any financial industry money has been lost or stolen due to a rooted or bootloader unlocked phone in the USA, where we're already a minuscule margin of an OS that has lagged in popularity behind iOS for a decade+.

It's also a bit ironic that the big banks dare to impose anything on the people anyway. THEY are the ones who illegally opened accounts (Wells Fargo fraud), lost a majority of the USA's credit info to hackers (then passed a bill shielding themselves from liability), wrongfully foreclosed homes (WF), ad nauseum.

Bank of America did something too, they literally all have.

/Endrant
[Magisk] HippoMan:
Yes, it's quite understandable that banks are so concerned about security in these areas.

Of course, these same banks issue us totally unprotected debit cards and credit cards to use in the same way as we use mobile-device contactless payment services, but they don't try to cripple the use of our wallets where these bank cards reside. And they also allow us to access their banking services from our rooted desktop machines without any crippling of the functionality of these desktop machines.
[Magisk] Nergal di Cuthah:
BoA works fine on my rooted passing basic only p6p
[Magisk] JpegXguy:
I don't understand why the service needs to care if the phone is rooted. All PCs are rooted since we have admin rights and we use banking services all the time.

Also root is unrelated to someone "spoofing" your card, they would always need to know the card details
[Magisk] BillGoss:
You don't actually use your PC itself as a credit card! You log in to the bank's web site using your browser and then ask them to pay for the purchase. And you can also do that on your phone.

But tap-and-pay is treating your phone like the actual credit card you carry with you.
[Magisk] HRSE:
so that's why Google crippled the tap-and-pay function on rooted phone, but allow scan-to-pay to pass on rooted phone.

Actually I realize GPay scan-to-pay is much slower to complete transaction compared with the local bank app. Maybe because GPay needs to do a round trip to the bank behind the scene.

For my next phone, probably NFC is not in my requirement list anymore.
[Magisk] HippoMan:
And there is no protection aside from a pin number needed to perform tap-and-pay with a debit card.

Criminals can steal my wallet with my ID cards and my set of bank cards as easily as they can steal my Android device.

However, on a modded Android device which potentially allows criminals to also access my personal information, we are unable to even perform tap-and-pay using most banks' services, irrespective of the fact that we would have to use a PIN number under Android in the same way we use it with a debit card.

In other words, why should tap and pay be more restricted on an unprotected, modded Android device than with normal, unprotected bank cards?

And PS: my banks all willingly and gladly issue me "VISA debit cards" which are true debit cards that behave like credit cards in that they don't even require PIN entry for tap and pay transactions. These cards are even more unprotected than modded Android devices.
[Magisk] HippoMan:
Yes, and most of these same banks offer mobile-phone apps which give us pretty much the same capbilities as we have via browser access. And even though we can have unrestricted browser access to these banks on our modded mobile devices, those banking apps are often restricted on modded devices and sometimes even rendered totally non-functional.

Why restrict apps on a modded mobile device which allow us to perform the same banking functions in an unrestricted manner via browsers on that same modded mobile device?
[Magisk] wyt18:
trying to use v14 with pif.json -

when using TB Checker, are the simulated fingerprints (in the pif.json file) supposed to appear in the top of the TB Checker app (model, fingerprint, etc.)? similarly when using Play Store Dev Options to check Play Integrity?

currently I only see the actual model name and fingerprint of my device, and not that of the simulated device. so I'm wondering if it's because the prints are banned, or that I'm not using the module and pif.json file correctly ...
[Magisk] Umgak:
Simulated props are only passed to DroidGuard. TB Checker and even Play Store dev options will report the true props.
[Magisk] prot-:
I put my credit card between my phone and the cover.

Issue solved lol
[Magisk] HRSE:
It's not advisable to "put all eggs in one basket". What happens if you lose your phone (and phone cover and everything between your phone and the cover)?
[Magisk] awarexda:
To find a working fingerprint is a hell of a trouble given that api level must be less than 28 and android version 8 or more
[Magisk] pndwal:
Actually any device launched with A7 (LV) or earlier even if running A14 (RV)...

Of course 'sensitive' props must still be spoofed to hide unlocked B/L, root etc, but MHPC, Shamiko and other solutions can do this in place of USNF/PIF.

And the point I've been harping on is that we should be able to use the same props allowing DEVICE_INTEGRITY in ANY of these devices to spoof in others with addition of USNF fake keystore based fallback to BASIC-only attestation on device, and of course 'these devices' include donors for recently "banned"* fingerprint props!... So again, it follows that we just need to know the extra properties Google is now validating from these devices and spoof 'em too!

*Sorry I can't spell bananananana... ; well I can but I just don't know when to stop!

😜 PW
[Magisk] Utini:
Since people only talk about this affecting google play/wallet:

It does also affect banking apps, 2 factor auth apps like duo mobile and more? They will all start detecting root now and block the usage of those apps on rooted devices?
[Magisk] zgfg:
Full phone specification

Platform, OS

Eg, from screenshot

A12, upgradeble to A13

means that 1st Api level was 31 (12) or 32 (12L)

Not good for pif.json, but as an example
[Magisk] phone_etix:
edit: deleted post - realised I didn't enable root in the explorer app 🙄