yashsingh1/xdaforums huggingface dataset:
[Magisk] Umgak:
What phone are you using, and what phone were you trying to spoof? I see you've done a bit of Samsung dev work, so I worry that you're pulling your props from the same phone that you're using - that will NOT work, you have to spoof a different device - specifically an older one.

If the prop you've dumped is from a device that's too new (generally min API 33+ but there are exceptions that are lower), it's entirely possible that it already requires strong attestation server-side. If it's from an older device (first API levels ~23-27) it's possible the print in question has already been banned*. Try a different build (literally every single OTA and beta build for eligible phones might work) or a different phone.

The fact that the Acer fingerprint works is a good sign - it means that your issues are definitely not due to conflicting modules or incorrect configuration of something else other than the pif.json. Keep trying other prints. As mentioned, EVERY official released version for a phone has a decent chance to work.

Also, make sure your json formatting is correct as it's easy to miss a comma or quote somewhere and break the file.

*"Banned" isn't a good term, as the print actually still works for non-mismatch situations (ie on the original device, not spoofing) - it's more of a "strict enforcement" mode.
[Magisk] TheRomRooster:
Not all PIFs work for spoofing and since Samsung is a big name manufacturer, even if there were any, they are likely already banned. I'd say look for manufacturers you never heared of and and try anything from Android 6 API 23 to Android 8 API 28 and you'll get a hit. Plus with a obscure device you are likely to get banned way less frequently. Got my obscure one running for 5 weeks now without problems and even if it would get banned, I've got 12 more obscure ones. That's overdoing it but getting 3-4 obscure working PIFs should be good for the near future
[Magisk] sawdoctor:
Also remember the device doesn't need to be a phone just an android device that preferably got updated to android Oreo.

The bundled fingerprints from chiteroman have included an android camera and android TV box
[Magisk] omokas:
It's been 20 days since I found my fingerprint using the script and using osmosis fork on Xiaomi Redmi Note 9 Pro MIUI 13.0.4

All is working perfect till now keep up the good work! :)
[Magisk] mxz55:
Just want to mention that weeks ago, i installed a fork of this module, the fork is: https://github.com/daboynb/PlayIntegrityNEXT that does dynamic fingerprint loading, so you don't need to constantly update the module like in original from chiteroman. Since installing it, i haven't lost attestation once, so without need for maintenance by user, less of a hassle. It also seems safer than relying on the original module, because chiteroman's stance keeps shifting back and forth like "This is the final release if Google bans the fingerprint again" or "This is the end" - i totally get it, the cat and mouse game with Google is tiring and pulls you down, but you see that the technology used by that fork is of a more resilient design.

It seems even better if chiteroman adopts that design, so a fork is no longer needed? Are there any cons to it, like it's less secure?
[Magisk] osm0sis:
The print also hasn't needed updating in that time.

Mass used prints remain a bad idea, because it's the most likely mechanism by which they've been getting banned.
[Magisk] mkcs:
Any plan to support APatch? Simple patch like Magisk but similar to KernelSU

GitHub - bmax121/APatch: The patching of Android kernel and Android system

The patching of Android kernel and Android system. Contribute to bmax121/APatch development by creating an account on GitHub.

github.com
[Magisk] V0latyle:
Use this:

GitHub - Yervant7/ZygiskNext: Standalone implementation of Zygisk For APatch

Standalone implementation of Zygisk For APatch. Contribute to Yervant7/ZygiskNext development by creating an account on GitHub.

github.com
[Magisk] simplepinoi177:
Yes, as mentioned in the post 3 above mine (#9,129), you've only that experience because Google has ceased banning (seemingly for the holidays and an extended vacation[?], maybe P.I.G. got laid off[?], department just needed end-of-the-year results[?]), but that's bound to be temporary. If you were an active user mid Nov. to mid Dec., it wouldn't be the case of "haven't lost attestation once" -- especially with PIF (with new fingerprints and updates up to 3 times a week) or PINext...

On top of the logical benefits of everyone spoofing their own custom fingerprints, PINext and the use of mass implemented fingerprint is that Google can/will ban it at any random time with no notice, so if you are in absolute need to be passing DEVICE and expect certain things to work at that specific time (Wallet or Play Store search results to name a few), then I'd call that a con as well. (With PINext you can just run the .apk to update the fingerprint, but as PINext pulls from xiaomi.eu custom ROM, there is still a minimal wait time before they publish theirs....)
[Magisk] HippoMan:
Given that this is a PIF thread, I'm guessing that the question about APatch probably relates to the use of PIF. Given that PIF is installed as a Magisk module, is there any way that PIF (or any other Magisk modules) can be used with APatch?

I don't see any discussion on the APatch github site about using it with Magisk modules.
[Magisk] rom-g:
Apatch is supported by this module, according to the wiki :
[Magisk] V0latyle:
Sounds like someone should have read the wiki!
[Magisk] mkcs:
LoL, I'm outdated😁 A quick installation with APatch, ZygiskNext and PI modules failed to pass the device integrity, leading me to think the PI module hasn't supported yet
[Magisk] HippoMan:
Aha!

From the PIF wiki ...
[Magisk] V0latyle:
Which PI module? If you're using Osm0sis fork, you have to use a custom fingerprint.
[Magisk] mkcs:
The problem should be solved by using the mod version of ZygiskNext which works with APatch. I'm going to try again.
[Magisk] V0latyle:
k, but....if you don't have a good print, or don't have a print at all, it won't work
[Magisk] HippoMan:
Concerning "resetprop":

I have been consistently getting a crippled Uber-rider (not driver) app, despite the fact that I have DEVICE integrity via osm0sis v5 with a reliable FP, and despite the fact that I'm using BootloaderSpoofer with Uber-rider as well as IAmNotADeveloper with Uber-rider. Oh, also, I'm using Magisk Alpha 26404, and I switch back and forth between Shamiko and just plain DenyList without any difference in Uber-rider behavior.

Someone told me the following, but didn't explain:

"I have Uber rider running with full UI - it was detecting resetprop usage and showing me this bare bones version of the app like you describe. Definitely not checking for Strong ..."

Because the person didn't explain, I don't know what might have been meant by "detecting resetprop usage". He did something to override this error and to get Uber-rider working properly with "full UI", so can anyone think of anything I could do in order to stop the system from "detecting resetprop usage"?

Thank you in advance for any thoughts and ideas.
[Magisk] xcl1pse:
Whats full ui mean? Im lazy to order but it seems normal

View attachment 6054943
[Magisk] HippoMan:
"Full UI" means that Uber-rider works as it is supposed to. It shows everything normally when running, and all its features are fully available to the rider.

The "Crippled UI" that I and others experience with Uber-rider only shows the minimal data necessary to request and schedule a single-stop ride, without extra features such as adding an additional stop, checking safety, altering the theme, altering most user settings, setting a tip in advance, etc.
[Magisk] xcl1pse:
Oh, it show full ui for me then
[Magisk] HippoMan:
What is your device and OS? And what level of integrity do you have? And are you running Magisk? If so, is it TJW version, Alpha version, or Kitsune? And are you running PIF? If so, what version?
[Magisk] xcl1pse:
I tested that on A40 DerpFest A13, pass device integrity, running magisk alpha and using PIF 15.1 with custom fp. I didn't test uber rider on my other phone
[Magisk] DanGLES3:
To my knowledge version 1.0.x of Shamiko should have included a fix for resetprop detection (and recently something similar was added into Kitsune)

If for whatever reason Shamiko's fix isn't work for you it's possible something could be interfering with it
[Magisk] HippoMan:
Possibly. I'm continuing to look into this issue. And to be clear, I'm running stock A13 with Magisk Alpha 26404 and with Shamiko 1.0.1, and with osm0sis PIF v5 ... and also with BootloaderSpoofer and IAmNotADeveloper.
[Magisk] WhoIsJohnGalt1979:
These inputs are solely based on two P8Ps (mine and my wife's) running Uber Rider and Uber eats successfully. I am on A14 QPR2 Beta 3, running the latest Magisk Alpha and Shamiko Shamiko-v1.0-290-release.zip. Please downgrade from 1.0.1 (all it has additional is Android 10 compatibility and for some reason has failed to hide root on a couple of apps while testing). Am using Osmo0sis's v5 fork with a custom fingerprint. Kindly remove BootloaderSpoofer and IamNotADeveloper, unless they actually help you specifically to access a particular app (other than detection apps). You should be good with Uber after that. Kindly remove Uber from Deny list, uninstall and reboot, before trying these steps. Post which, reinstall, add to deny list and reboot. Good luck.
[Magisk] HippoMan:
Oh ... OK! Thank you!!!!!!

Also, near the end of your paragraph when you say "uninstall" and then "reinstall", do you mean uninstall and then reinstall Uber? I just want to make sure I understand.

Oh, and what do you mean by "Post which" in your final sentence?

I'll try all of that and post my results. Probably tomorrow, because it's close to my bedtime now.
[Magisk] WhoIsJohnGalt1979:
Yes please, many might consider it to be a redundant step and can be accomplished with just a clearing of data and cache, but I prefer (read OCD) deleting cache and data and uninstalling the app, reboot followed by flashing whatever you have to and then reinstalling and adding it to deny list and rebooting again when adding a new app or re-adding an existing failing app.

Post which corresponds to: 1) Removing Bootloader Spoofer and IamNotADeveloper from lsposed. Please uncheck whatever apps you have enabled in lsposed for these modules along with disabling the modules themselves, delete cache and data followed by uninstallation of those two apps from Settings-Apps (enable Show system). Reboot phone 2) Flash Shamiko version that I suggested (have attached it to the post for your convenience). Before rebooting here, install Uber, add it to the deny list and reboot. So 3 reboots in all, the first one being when you uninstall Uber.
[Magisk] HippoMan:
I see. Thank you!

And I decided to stay awake a little longer tonight, and I did everything ... and sadly, it didn't work.

First of all, I'm not running A14. I'm on a Nothing 2 phone and they only offer A13 so far. I'm running their stock A13 "OS 2.0.3".

And as I mentioned above, but want to mention here again for the sake of completeness, I'm running Magisk Alpha 26404 and osm0sis PIFork v5 which reliably yields BASIC and INTEGRITY.

Here's what I did ...

(1) Remove BootloaderSpoofer and IAmNotADeveloper.

(2) Reboot

(3) Uninstall Shamiko 1.0.1 and remove Uber from DenyList.

(4) Reboot

(5) Uninstall Uber

(6) Reboot

(7) Install Shamiko-v1.0-290-release.zip.

(8) Reboot

(9) Reinstall Uber and add it back to DenyList

(10) Reboot

The first time I started Uber and initialized it, everything was OK. But if I go to the Home screen without killing Uber, and if I open another app, and then if I close that app and re-launch Uber, Uber comes up even more crippled than before:

It shows a plain white screen with the words "Oops, we screwed up" and they offer a "Retry" button. When clicking that "Retry" button, the crippled version of the Uber app then comes up.

I rebooted and tried again, after clearing Uber's cache. Same "Oops ..." screen under the same circumstances.

I tried reinstalling BootloaderSpoofer and IAmNotADeveloper and repointing each to Uber. Same problem after rebooting.

I tried replacing Shamiko-v1.0-290 with Shamiko-1.0.1. Again same problem after rebooting.

But then I uninstalled Uber and restored it from my recent (last night) SwiftBackup backup, and then I'm back to what I had before: no more "OOPS ..." screen, but still a crippled version under some circumstances.

There was no new Uber release between my latest SwiftBackup and today's reinstall from the PlayStore.

Maybe these issues are due to the fact that I'm not running A14 on a P8P ... ???

Anyway, I'm now back to what I had running a little earlier tonight.

I'll spend more time on this tomorrow.

Thank you again for all your time and all your help!

UPDATE: I forgot to mention that after each reboot, I cleared the cache of the installed Uber before starting it.
[Magisk] yazan.xda:
hi i was about to unlock the bootloader on my phone just before i learned about the play integrity problem..im a complete newbie when it comes to this topic so i was wondering if i factory reset my phone will everything go back to normal?
[Magisk] majorfigjam:
That depends on what you do after you unlock the bootloader.

At a minimum, locking or unlocking will cause all user data to be wiped. But, factory reset will not revert a custom rom to stock, and may not revert any kernel (or system level) changes made.
[Magisk] yazan.xda:
OMG thank you for the info i didnt know i would loose all my phone data if i unlock the bootloader
[Magisk] rodken:
Which is why copying and pasting is not recommended due to the high chance of human error.
[Magisk] Umgak:
Tabs and spaces are both fine by json spec, it's not a whitespaced format. Four spaces is recommended for consistency and readability, but you could use tabs, four spaces, two spaces, a new line, 600 tabs, etc. Any json parser worth using won't care.

Miss a quotation mark or a comma, on the other hand - or have an extra comma at the end... then it's all downhill.
[Magisk] badabing2003:
Yep unless you're using json5 parser which by the way PixelFlasher uses for input, but outputs as standard json to keep it compatible with different forks hence you get the benfit of making mistakes and get them automatically corrected.
[Magisk] ace2nutzer:
What's going on guys?!

WhatsApp now requires STRONG for log-in?

see here:

[CLOSED] Is there a way to bypass bootloader unlock for WhatsApp?

$:/ As you can see, WhatsApp cannot log in when the bootloader is unlocked, but if you lock the bootloader it can be done without problems. ?:/ My question, is there any super powerful module to remove bootloader state #:/ Previously I've used...

xdaforums.com
[Magisk] makeyourself:
The WhatsApp screenshot translates as "you need official WhatsApp to use... (whatever the rest of it says, can't see from the screenshot)". WhatsApp appears to be complaining that it's not the official version. Which would be nothing to do with Play Integrity or bootloader unlock state. I just logged into WhatsApp fine about 30 minutes ago, bootloader unlocked, rooted, custom rom and kernel. Didn't even get so much as any kind of warning from WhatsApp. Also WhatsApp doesn't care about PI and I don't think it even checks it.
[Magisk] eac5:
I also have no issues logging into WhatsApp on latest version, it only issued a warning that I was running a custom ROM, the app wasn't even on the DenyList, funnily enough putting it there actually caused some sort of login loop, removing it again promptly got things back to normal.

Not sure what sort of unofficial version issue that dude is having, the post says it's from the PlayStore. Possibly it does check for 'device certified' status, which unlocked bootloader screws with in some cases
[Magisk] ace2nutzer:
Hmm OK thx guys, lets forget then.
[Magisk] GuyWithRootedPhone:
hello.

my custom fingerprint that I used with my Xiaomi Mi 11 Ultra suddenly stopped working and I have not been able to fix it.

any advice?
[Magisk] majorfigjam:
Follow the all time most liked posts in this thread, and find a new custom fingerprint to use?

Before that though, track back - did you make any changes that would have affected play integrity? If so, unwind them and try again.

My custom print from early December is still alive.
[Magisk] GuyWithRootedPhone:
No changes, it just suddenly stopped working. I used the stock ROM for the fingerprint.
[Magisk] majorfigjam:
Which version of pif were you using? Ie was it using a default to override your custom?

If not, then it looks like Google woke up, and its time to use a new print.
[Magisk] HippoMan:
Just because a particular FP comes from an early-enough Android ROM version, that does not *guarantee* that it will work for spoofing.

The normal procedure is to keep trying FP's from different ROMs until one or more are found that will indeed work for spoofing.

Some people have to try FP's from 10 or more ROMs before a working FP is found.

This is the normal procedure that we all have to go through regarding the selection of FP's.
[Magisk] GuyWithRootedPhone:
it was 100% custom.
[Magisk] majorfigjam:
It's an unfortunate fact that not all device prints work. I have 2 Oreo Moto's, one works one doesn't.

You'll need to find a different print to replace the generic acer one.
[Magisk] majorfigjam:
Oh well, time to move on to another print.
[Magisk] ace2nutzer:
OK but I don't get the point.

What's the reason why it fails?

logcat | grep pif

may helps? How I can debug it?

If you may say that FP is banned, then if I flash that stock ROM with the same FP, then it would also not pass DEVICE / STRONG? - That's the point ... if this FP is banned, then it's even banned for stock ROM users? I think Google would not do that .. or else they get problems with Samsung.
[Magisk] V0latyle:
That's been one of the things we've been trying to figure out in testing fingerprints. Sometimes older fingerprints from the same device work while newer ones don't. We aren't sure exactly why, yet...the only thing I can suggest is try older fingerprints from that device, maybe start with the first ones since you said it launched with Android 7.
[Magisk] osm0sis:
And being banned has absolutely have no effect on the real devices. It's been said many, many times. Including in my guide, so please give it another read. 🙂
[Magisk] Nergal di Cuthah:
As has been discussed many times in this thread. Real devices don't get banned when a fingerprint is banned. All available evidence points to this. Are you fingerprinting the same device you're running, 7/10 times this has not worked for the user, by my wishy-washy recollection.
[Magisk] HippoMan:
FP's fail not only because they've been "banned". In the non-"banned" failure cases, it's because there is some sort of mismatch between the data in the FP and the properties of the devices upon which the FP is being applied on.

This is normal. Only a small percentage of potentially eligible non-"banned" FP's will work for spoofing.

The "DroidGuard" procedure that Google uses to decide what integrity values can be assigned is mostly a "black box" which uses logic that Google is not releasing to the public, and also which utilizes certain device-specific data that Google has access to but that we do not have access to.

All we've been able to do is to throw a number of potentially elegible FP's at our devices and see whether "DroidGuard" can be triggered to allow BASIC and DEVICE integrity for any of these FP's.

And again, it's usually only a small percentage of potentially eligible FP's which will work for spoofing BASIC and DEVICE integrity.
[Magisk] ace2nutzer:
What's a real device? - phone with original firmware?

I forgot to mention that I'm not using a custom ROM.

A few months ago I was even able to have DRM L1 with custom kernel + your Magisk!, while users with custom ROMs wasn't able, they get only L3.

I'm always trying to keep the ROM as stock as possible and that's why I get BASIC pass out of the box ... (without root).

Basically I understand that there are still some changes compared to the real stock ROM..

It's a lot, selinux properties removed, tima, knox and many more.

I think it fails because it detects a stock FP on a non original ROM.

If I would know what's exactly the problem then I would start to fake it in kernel ... OR else like always try-and-error .. that worked so far very well ... but it's quite time consuming.

Your guide is this? - I'll check it later.
[Magisk] simplepinoi177:
Most custom fingerprints are from their stock ROM's .prop files.

It seems something from Google has banana'd your custom fingerprint. As mentioned after these posts further in the thread, Google and DroidGuard have unknown mysterious combination of requisites and checks; you never know when they change or implement. You would hardly be the first or earliest where a user has had their custom fingerprints suddenly stop working -- i believe many had had theirs stop working 2 or 3 weeks after finding it; I recall it was about a week before Christmas and they had found it first week of Dec. Unless you changed/updated PIF module, it's more likely on Google/DroidGuard's side or servers than on your device or the PIF module.

It looks like it's just a fingerprint that doesn't work/won't-pass. Whether it's from an actual device you pulled from and/or is a proper official "stock ROM" makes no more or less difference or makes it special enough to guarantee it passing...

I believe @majorfigjam was asking if you were ensuring PIF was using your "100% custom" over the default -- "was it using a default to override your custom"; meaning were you making sure you were placing your custom one in the right folder and/or removing the default embedded one that comes with PIF...?

And, if so, it looks like yours simply got banana'd...

As already mentioned by other members, users using the actual device others are simply spoofing have nothing to worry about or fear. I always put it (or how I ended up putting it in my guide) is that if that was the case, we would definitely hear from all of these users on these devices suddenly complaining about services not working and no longer passing....

This can't be the case, because many users using PIF, PINext, PIFork, and the fact of custom ROMs (xiaomi.eu, in which PINext pulls its fingerprints from) all pass in this circumstance. And if you meant "non original ROM" as our actual devices vs. the devices being spoofed, then

all

users using PIF, PINext, PIFork and all the rest is able to pass under this circumstance; all 10's of thousands of us; so I doubt it failing because "it detects a stock FP" on your device (vs. the actual device) and it's more likely the fingerprint you are implementing simply doesn't pass/follows guidelines/requirements from Google -- wherever source you may have obtained or pulled the fingerprint from...
[Magisk] pndwal:
But ro.product.first_api_level is shipping level or first level tested AFAIK... So 24 looks correct...

You could try 23 or earlier... Often helps...

It's not really banned... There's some cross checking Google is doing to differentiate between locked/stock and spoofing devices... Please see this:

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89256076

and regarding why mismatches (rather than expected props for your device) are needed for spoofing, please see posts on how hardware-backed verdict enforcement and bypassing this is achieved (basics of how USNF and forks (inc. PIF) work) and more under 'a bit of history' I linked at end of this post:

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89240356

👀 PW
[Magisk] makeyourself:
What device-specific data would that be out of interest and how do we know about it?

I think that "banned" is not a good word for fingerprints that stop working, or that should work but don't, "restricted" would be more accurate.
[Magisk] Nergal di Cuthah:
That has been discussed before (it's why some say 'banana-d". Restricted isn't a bad one. I say 'gone bad' (meaning it won't work for our purposes).