yashsingh1/xdaforums huggingface dataset:
[Magisk] salamdiab:
i will at night

milion thanks
[Magisk] Clearlynotimportant:
I have tried over 30 props and no device pass on any.. what am I doing wrong??
[Magisk] sawdoctor:
What devices? 8.1 firmware are the best (Samsung seems to be the worst) and have you tried changing 1st API level on any of them?
[Magisk] flawless911:
Guys, I need help.. I finally updated to the recent build of Xiaomi.eu (that comes with an inbuilt play integrity fix) and I wish to disable it completely so that I can continue using my custom PIF (that has been working for 3 weeks now)

The inbuilt fix is affecting my custom PIF.. If anyone was able to use their own custom PIF on recent xiaomi.eu builds, kindly guide me through it

For reference I'm using Magisk Stable v26.4

I have tried PlayIntegrityFix Dev 2 and PlayIntegrityFix v14 (this version has been working for me for 3 weeks with my custom PIF before I updated to this Xiaomi.eu build with internal fix)
[Magisk] CZ.Kostra:
You have to downgrade the eu.xiaomi.module.inject application to version 1.
[Magisk] TheFreeman193:
I'm referring to devices where the OEM screwed up the Keymaster 3.x or 4.x HAL and thus enforcing hardware-backed attestations would also break dependent Play Services functionality for stock devices locked with OEM keys. As far as I understand it, most of those devices can still pass DEVICE_INTEGRITY verdicts with software-backed/basic attestation at present, but it would presumably be trivial to start enforcing hardware-backed attestations, either for specific device profiles or across the board.

I could have that wrong of course - I'm not experienced in the low-level stuff beyond ISO 14443 NFC technology so the whole TrustZone/Keymaster/DroidGuard stack is pretty foreign to me.
[Magisk] StrifE:
Guys I did it omg, I can't believe it works, now I can finally pay with my phone and I don't have to worry about fingerprints, device integrity etc. all taken care of, thanks a lot guys.
[Magisk] xXHenlolXx:
Thanks @HippoMan, @igormm and @xcl1pse. Hope we can find a solution for this bank app, bc im going crazy hahahaha. @igormm Have u tried removing magisk / xposed and everything thats modded to test if the app works again in that case?
[Magisk] Vision:
@chiteroman A little bug in version v14 (for anyone have this and use this method, i don't know if exist in latest version) with data/adb/pif.json when i create a pif.json and put it again in the module zip and flash it and reboot the pif.json file not replace it with the new i have write it, for that failed some FP i have try it, because read it the previous pif.json data/adb/pif.json with FP died and not replaced with the new from /data/adb/modules/playintegrityfix

Edit: Also when remove the module from Magisk inside after reboot success deleted from /data/adb/module but the pif.json still remain in the /data/adb
[Magisk] TheFreeman193:
This was a laugh I needed today!

The next phase is of course to clone the NFC chip in the card to a little mifare token that you can hide in your phone case 😉 (NB don't actually do this I'm sure it's at least a ToS violation if not against the law!)
[Magisk] sawdoctor:
I'm still using v14 with custom fingerprint. Pixelflasher will rewrite the pif json but i haven't tried flashing it as a zip
[Magisk] Vision:
Understand, i use this method with zip and today i figure out this
[Magisk] Brava27:
Samsung s23 user here. Seems like it's a pain in the ass for wallet to work for Samsung devices. Thanks for your work criterion.
[Magisk] flawless911:
I fixed it by following this guide:

Installing Magisk and Play Integrity Fix

As you are aware, new Stable releases (including rebuilds that are currently in the works) do not include our fix for passing SafetyNet/Play Integrity checks. There's the guide how to flash Magisk and relevant fix on these ROMs. NOTE: You have to repeat the process (at least installing Magisk)...

xiaomi.eu

Playstore shows Device not certified but checking with inbuilt checker shows me MEETS DEVICE INTEGRITY and also Netflix is visible on Playstore, so I guess that's a Win

Although sometimes it gives me an EMPTY response when I check integrity with Playstore as seen in the first screenshot.. Either way, everything is working fine

Custom PIF is still the best.. I've been using the exact same Custom PIF since December 2nd with PlayIntegrityFix v14.0
[Magisk] HippoMan:
Just out of curiosity ...

Is it against the law or otherwise prohibited to do the following? ...

(1) Write a program which runs under Android to scan a bank card via NFC and save the data in a file.

(2) Write another program which runs under Android which reads that file and transmits that saved bank-card data via NFC on request?

If this is possible, we could write our own "wallet" app to use for contactless payments.
[Magisk] Vision:
For quick test (if you have already installed this module) if FP working, send the new pif.json file to /data/adb and replaced the exist, go to setting/apps, found the Google Play Services and click force close (no need close the internet etc.) (i try it this with Total Commander) after do the test if pass 2/3
[Magisk] TheFreeman193:
The information that GPay stores is different from that stored in the NFC and chip&pin chips. To create a wallet app in that sense would require authorisation/communication with the provider/bank.

In terms of using the NFC radio on a phone to emulate the contactless chip of a card, this is certainly possible since both use 13.56 MHz HF radio conforming to ISO 14443-x but is almost certainly against any provider's ToS and perhaps even illegal in some jurisdictions. It would involve learning both keys for every sector of memory stored in the card's chip using brute force, MITM, or a nested-type attack based on weakly protected "spare" sectors, and storing that data for later emulation. Assuming the chip doesn't have a flawed PRNG or weak key/nonce exchange function that brute forcing will take a LONG time.

So yes, the latter is possible but absolutely not to be tried unless you're red teaming or working with a security company/provider to discover attack surfaces.
[Magisk] HippoMan:
I see. This explains why there aren't any alternative, third-party wallet apps available.

Thank you for explaining.
[Magisk] furdiburd11:
There is a new Plaintegrityfix fork that pulls the json from the web so you dont need to upsate the module when the fingerprint is banned you just need to click on an app and this fork pulls a new pif.json. you can use it if you dont want to update pif every time the fingerprint gets banned and if you trust this fork.

GitHub - daboynb/PlayIntegrityNEXT

Contribute to daboynb/PlayIntegrityNEXT development by creating an account on GitHub.

github.com
[Magisk] asisandroid:
The idea of having a big community which won't share fingerprints when it is quite easy to find many is just unrealistic.

All we can do is hope that someone finds a bypass before all fingerprints are gone.
[Magisk] osm0sis:
Straight up murdered the commit history, so seems to come from the same school as chiteroman. 😅🤦‍♂️
[Magisk] frasca61:
I think this will kill all the footprints in a short time.

Is it possible to re-bloc the bootloader without having to reinstall everything?

I have the Stock ROM and I can give up root privileges .....
[Magisk] hanschke:
I like it because it worked for me.
[Magisk] Umgak:
No. Relocking the bootloader will require a factory reset for security reasons.
[Magisk] pndwal:
Ah, so you mean the latter, those that do (happily) fall back to basic, allowing DEVICE_INTEGRITY to be met w/o hardware (key) attestations...

Yes, Google is certainly avoiding breaking DEVICE_INTEGRITY for these, but of course they cannot be enforcing HARDWARE_BACKED evaluationType verdicts (really blacklisting device for BASIC-only attested verdicts by invalidating that means) for any of the devices/prop sets/prints we use for spoofing as these prop sets all necessarily belong to non-Keymaster 3+ compliant devices; enforcement would thus break DEVICE_INTEGRITY for all associated devices with healthy Keymaster implementations also...

I doubt Google will ever view that as acceptable/trivial.

The whole point is that they are managing to "ban" prints for unlocked devices/spoofing purposes without enforcing HARDWARE_BACKED evaluationType verdicts, ie. without actually banning the prints for locked/stock devices in the wild whether the enforcement exempting we rely on is due to lack of hardware support (Keymaster version < 3, prints for older devices) or due to busted Keymaster 3+ (or uncertainty about the same) implementations (prints for Keymaster 3+ devices).

Also, it does seem clear that, while we're still missing the cross-check mechanism (extra props, other?) being employed here, Google could easily (presumably anyway) have implemented these across the board so that enforcing HARDWARE_BACKED evaluationType verdicts needn't enter into the equation... Such across the board enforcement would be akin to enforcing STRONG_INTEGRITY (the only difference between the two is that CTS/VTS profile matching etc MUST pass with HARDWARE_BACKED evaluationType anyway), something that Google surely has no intention of doing... I don't believe they ever wished to guarantee DEVICE_INTEGRITY was "strongly attested to"... Where the device integrity label is STRONG_INTEGRITY, this would be a different story however.

So, as I've said before, it seems we should really be testing/trying to understand the missing cross-check mechanism recently introduced as it seems that only some small mercy has prevented Google from blanket employment of that, and only this understanding (coupled with the fact that the attestations we're concerned with are all userspace/software only, and we can potentially spoof anything in userspace) will allow us to "un-ban" all print/prop sets for non-Keymaster 3+ compliant devices since they were never really banned in the first place...

🤠 PW
[Magisk] frasca61:
My footprint (I stopped after the first fishing) it works from 10 days, I made a shopping today
[Magisk] osm0sis:
Actually one thing that is cool about this fork is the autojson repo script which just extracts the latest fingerprint directly from Xiaomi.eu sources.
[Magisk] sawdoctor:
The fingerprints in the 2 xposed PIF forks I've been following have now been banned. So if the theory of number of users is correct then the threshold is much lower than you thought. One of the xposed had only updated 4 days ago and had Very few people using it
[Magisk] JpegXguy:
That's what was happening already and we were trying to avoid though. The point is everyone should have different fingerprint

If a big group suddenly has the same fingerprint, it's sus and will be removed. No one listens
[Magisk] pndwal:
Except that it's not that simple/possible...

You and I have discussed this before:

So actual 'bank-card data' is not used/transmitted during transactions...

Unfortunately Google seems to have replaced their original detailed information with a simple payment flow explanation now.

FWIW, the original ref. further clarified that online verification is done during the payment process by the terminal by activating a 'one-time-use password' to process transactions only if the card network can validate the sent cryptogram and is able to confirm a match between the stored token and the customer’s actual card number, stating:

👀 PW
[Magisk] osm0sis:
Ah, so unless they're using a print from somewhere else more prominent maybe they are monitoring forks and repos.
[Magisk] sawdoctor:
The prints in the 2 repos I'm following weren't/haven't been used in this thread although the one banned today was from a very similar device to one burnt here a few weeks ago
[Magisk] HippoMan:
Oh, yes. I forgot about that.

As I get older, my memory is the second thing I've lost.
[Magisk] stanley321:
Why the heck did they do that? They is just bad version control practice! 🤦‍♂️
[Magisk] pndwal:
It's the third thing for me...

But if there's any room for doubt there's a simple test: Do you grow hairs on the palm of your hands?... 😃 PW
[Magisk] HippoMan:
Actually, it goes like this:

As I get older, my memory is the second thing I lost.

Question: "What's the first thing?"

I forgot.

I fell for that joke years ago and asked, "What's the first thing?" when my uncle pulled that one on me and responded to my question with "I forgot."

Some time later, that same uncle and I were talking, and he said that he forgot something. I responded, "As we get older, our memory is the second thing we lose," because I thought he and I could share a laugh about the way I fell for that joke of his in the past.

But instead, he just replied, "What's the first thing?"

He forgot his own joke about losing memory!
[Magisk] Bxperiaz3:
My custom fingerprint just stopped working out of nowhere but it says neither basic or device integrity are met. Is this normal behavior? Im using the fork v4 zip at the moment. I installed 14.6 patch from telegram to test and that returns the same results.

Could someone shed some wisdom please? Looks like I'm back to hours of trawling through fingerprints.
[Magisk] pndwal:
... But I knew the first thing was your sanity... Since the first sign of madness is simply talking to yourself I just skipped to the second for confirmation, but I can always repeat the question if you forgot... PW
[Magisk] majorfigjam:
Have you changed anything else? If not, it may be Google refining their block algorithm? Clearly there is a range of possible valid responses for any given print, and they may have tightened them for your print.

The recommended first step is to change the api level downwards, but that doesn't work on every device. Try it before you start trawling again.

If you have to trawl, look for the same device with a different security patch first.
[Magisk] purgy:
When mine died the other day, it fell back to passing basic, but not device.
[Magisk] Bxperiaz3:
I gave the API trick a go but that didn't work. I find it very strange that the 14.6 patch doesn't work either , it only came out earlier today. (I realize that will be banned in no time) and I tried one or two other fps I have that worked and it won't pass regardless. Sad times
[Magisk] Bxperiaz3:
Yeah mine doesn't pass either which makes me think something is wrong. The last time mine failed it was only failing device. I did unhide and rehide magisk earlier, hardly an issue?
[Magisk] majorfigjam:
Try airplane mode, clearing playstore cache as well as play services then rebooting. You may have to do pay / wallet as well if you use it.

If it's cached an error for some reason, maybe clearing it will help.
[Magisk] Vision:
Is not about rooted phone, with force Strong effect older phone like my old phone is from 2015 stock not root and pass 2/3, if Google or other force to use Strong, losing customer because many people still have phones as primary from 2015 with android 7
[Magisk] Nergal di Cuthah:
Sounds like something else in your setup is breaking pi after fix is applied. What other modules do you have, have you tried removing all but pif and see if you pass. Something(s) is/are breaking basic and the test stops there (or some people would have device but not basic). This is at least my understanding of pi
[Magisk] Vision:
Look for misspelling in pif.json file and for comma etc maybe cause the problem
[Magisk] HippoMan:
Hmm ... but since the custom FP had been working as is, any commas and misspellings were in effect before it failed.
[Magisk] Vision:
Oh yeah, my mistake, i write it thinking maybe after looking in pif.json what wrong and something change like API and forgot something after :ROFLMAO:
[Magisk] chiteroman:
Uhhh, due to this new solutions I think it's time to stop providing fingerprints. What do you think ?
[Magisk] Vision:
Yeah many users (i suppose) now have learn how to find their own fingerprint, with all this guide. What new solutions ?🤔
[Magisk] HippoMan:
You'll get most people here agreeing with that course of action, although I think you'll get a lot of complaints in the TG group.
[Magisk] furdiburd11:
New solution? Maybe PlayintegrityNEXT can help. Seems like a good fork. Get its fingerprint from a web repo so the module dont need to be updated to use a new fingerprint

GitHub - daboynb/PlayIntegrityNEXT

Contribute to daboynb/PlayIntegrityNEXT development by creating an account on GitHub.

github.com
[Magisk] bleh815:
This is what I was trying to say few pages before. To me it seems the most obvious thing. I suspect no counters or threshold to be involved. Most probably it's simply the public availability that puts FPs in danger of ban.
[Magisk] Vision:
oh yeah, is new this, is like the one older version by @chiteroman with curl if i remember right, is with hardcore the fingerprint ? in the libs?
[Magisk] HippoMan:
I tend to agree. As I mentioned earlier, it would take one single Googlefrinchian employee maybe 5-10 minutes a week to check the PIF repo and to banana any new pif.json file(s) that it might be using.

And not much more time would be needed to periodically check any other FP repos that are publicly mentioned.

If the sole job of this one hypothetical employee was to check public FP sources that could be used for spoofing and feed what's found to some sort of Googlefrinchian banana-ing utility, they would probably have more than 39 hours of free time during each and every one of their 40-hour work weeks.
[Magisk] titomax82:
If you use the same fingerprint of xiaomi.eu devs, there's no need to to stop providing that fingerprint! It's like quitting smoking in a small room with 20 other people smoking, or it's like saying "I don't want to fall from the 100th floor of the skyscraper because I fear to die, so I fall from the 99th.... Sorry for my joking examples, but I think they can explain the problem.
[Magisk] majorfigjam:
And they haven't banned all of those publicly available prints (of which there are thousands) .... yet.

It's being done by exception, based on volume and extreme results. All those Holo360's suddenly appearing from nowhere, replacing Nvidia Shields. Ok, maybe they are tightening up the checking parameters, but not excessively.

It's just not sensible to assume they would do this manually, when they control the biggest web crawling search engine, and know exactly what they are looking for.
[Magisk] HippoMan:
I'm just pointing out that even *if* they do this manually, it would be very easy for them to accomplish with very little effort.

Given that they can do it all in an automated fashion means that it would be even quicker for them.

Yes, so far, they don't seem to be attacking the publicly known FP repos. But if they ever decide to do it, it would be trivally easy for them to accomplish.
[Magisk] bleh815:
By "public availability" I mean such FPs that are used for any kind of PIF. These are getting banned obviously.

And yes, this might even be done in an automated way.

But still, I don't agree in the theories that some counters, thresholds or so are involved.

If a FP is used to "fix" integrity checks and it's published in a way that is ready-made for anyone then this is the red line that must not be crossed.
[Magisk] majorfigjam:
Fair enough, but ATT happily publishes fingerprints and patch dates on its website in a readymade way, and so far those prints have not been banned.

Go figure.
[Magisk] Fishawy:
Saw this when I woke up and I was like "Ah **** here we go again".

Thank you for at least considering to stop. Yes the whole thing is doomed, but slowing the process and delaying the inevitable is better than nothing.
[Magisk] HippoMan:
There are "fingerprints" and then there are "fingerprints". Those which are not in the pif.json format require people to download them and do some work in order to convert them to something that can be installed via PIF and then tested for validity. Those are not very problematic, because people have to do some work to determine which ones are usable for PIF spoofing ... usually fewer than ten percent of them. As far as I know (and please correct me if I'm wrong), those ATT fingerprints are not in pif.json format and most are not valid for use as DEVICE integrity spoofers.

Those fingerprints which are already in the pif.json format *and* which have previously been tested and determined to be valid for DEVICE integrity are the ones that are more risky to publish, especially if they exist in publicly knowable and accessible repos containing many of them.
[Magisk] majorfigjam:
They aren't in pif.json or custom.pif.json format exactly on ATT's site, but all the fields are there, and yes they pass device integrity (as of today).

Bottom line is that Google can stop this today if they feel so inclined. I have an old locked Oreo that passes device integrity, but is too old to enforce strong. I tried the same print in my Pixel and it fails, even thought it meets the "Osm0sis criteria". Logcats etc for the devices show clearly different paths once gms.unstable is called in playstore, so the check for device validity limitations has happened already, before the pif checks are initiated. Maybe it's as simple as checking if the bootloader is locked.

Tracing that is a hobby for the Christmas holidays here.
[Magisk] purgy:
I found I think the reason my print got the chop, patch notes from 23/12/18 https://evolution-x.org/device/violet

"Rip Gionee"

it doesn't specify which model, but it seems like it's probably the same as I'd picked.

While I definitely "lost" the lottery there, it is a bit of a relief to find a possible answer.
[Magisk] chiteroman:
Play Integrity Fix

v15.9.9 released! https://github.com/chiteroman/PlayIntegrityFix/releases/tag/v15.9.9

t.me

The decision is made. Good luck to you all.

Google proceeds to ban all old fingerprints. 😂
[Magisk] HippoMan:
But just because these FP's pass DEVICE integrity on the hosts to which they apply doesn't mean that they will necessarily work for spoofing via PIF on any other hosts.

This is why we need to test many different working fingerprints to extract the small subset that are usable for spoofing hosts that are different from those to which these PF's are currently assigned.
[Magisk] Vision:
it was obvious after all, i mean the Fingerprint is dead
[Magisk] majorfigjam:
Maybe I wasn't clear, the ATT prints all pass Device on my Pixel, and I've had confirmation that they work for others too.

However, if google so decide, they will stop working shortly, and I'll have to set up my new smart watch (thanks Santa Claus!) to use Wallet.
[Magisk] HippoMan:
Oh ... I see what you mean now. I'm sorry that I misunderstood.
[Magisk] sawdoctor:
I don't think it's just volume as I've seen two xposed PIF mods get their print banned today and they weren't very well used. Think Google are watching GitHub as well as this thread
[Magisk] poulopoulosa:
I am sorry but I do not think that google would even waste resources to have a person manually watch the forums or github or anything else. I don't want to come across as cynical or negative but this is the truth.

Google has been in the forefront of developing smart algorithms to find a niddle in the haystack (the internet). I don't see why they can just develop a detection algorithm which detects suspected activity and then a human manually approves the banning of these fingerprints.

I dont know C++ or Java, neither know much about how Google authenticates stuff on Android. I am not knowledgeable, but I definitely know that Google might somehow be able to find out your real build.prop and might compare it with your recently send build.prop via Google Play API. Either way Google is able to cross-verify and detect what we do in a small and big scale.