yashsingh1/xdaforums huggingface dataset:
[Magisk] mike.s:
Google is already under pressure for "monopoly" control over Play store. That they allow side-loading and use of alternative app stores is probably their easiest and best defense.
[Magisk] mesiu84:
Yes I'm sure, I apply my fingerprint via adb to be sure it didn't change or something
[Magisk] ipilcher:
And then McDonald's, Starbucks, etc. will all follow suit, because most app developers are lazy and stupid.
[Magisk] ipilcher:
Great! Now publish the source code.
[Magisk] badabing2003:
If you're still adamant about updating to the latest, for the very least read the release notes, change log, there are such things as breaking changes, I told you what the issue is and you didn't even bother checking things out and wanted an answer on a platter.

Have you even bothered checking the template pif.json?
[Magisk] xcl1pse:
why?
[Magisk] trevtdogg:
i would suggest you try to use your custom FP with @osm0sis v5 PIF module instead then, as there has been a lot more work to make it 'future proof'.

plus @osm0sis seems to be more responsive in the forums here so if you have any issues, they may help you directly.
[Magisk] SoulsAssassins:
I tried Freeman's script again, about 70 pif and I only pass the basic device, yet I did disable magisk hide, I did clone the repository and copy to data/local/tmp still the same result, the Xiaomi eu script works fine but I can't get this one to work no matter how i don't know the v1 working great
[Magisk] V0latyle:
You'd have to ask people like @osm0sis about that, I'm not sure how those prints passed again, whether they possibly used different API levels to get them to pass, or if they're the same exact prints.

Some newer prints do work, oddly enough, but as a general rule, yes - prints must be FIRST_API >21 and <27

No...

Google does not control Android, although they are heavily invovled in the development thereof.

Play Store along with GMS is proprietary and Google gets to make their own rules regarding what apps they host. However, they CANNOT "lock" Android users to the GMS ecosystem. The ability to side load and use alternative app stores are not compromises but rather native Android functions.

Something must be wrong with your configuration. There's roughly a 25% chance of finding a working print so if you've gone through 70....

What version of Magisk are you using? Any other modules?
[Magisk] mesiu84:
Of course I downloaded and compared all pif.json between different releases starting from 14.2. I don't know about which changes are you talking about. I checked all pif.json in /data/adb and in /data/adb/modules/playintegrityfix but don't see anything there. I also checked release notes (available here https://github.com/chiteroman/PlayIntegrityFix/releases) but don't see anything there, please point me the thing you're talking about, as I don't see it.
[Magisk] SoulsAssassins:
Yes something is wrong but idk what I try everytime to resolve my problem myself by reading thread or searching but here idk I clean everytime play store, gms, wallet before testing for being sure

I have magisk kitsune 26.4 Pixel Launcher Extended, Play integrity fork v5, RVX YT, systemless host, zygisk lspoded, zygisk-detach android 13 lineage os 20 on redmi note 10 pro
[Magisk] Umgak:
The release notes are unfortunately missing several changes. Check the format of the bundled pif.json file here. Without the FORCE_BASIC_ATTESTATION flag set, much of the module is disabled. I'm disappointed to see this change missing from the changelog.
[Magisk] badabing2003:
Check again.

PlayIntegrityFix/module/pif.json at main · chiteroman/PlayIntegrityFix

Fix Play Integrity (and SafetyNet) verdicts. Contribute to chiteroman/PlayIntegrityFix development by creating an account on GitHub.

github.com
[Magisk] mesiu84:
Thank you, that was the one I was looking for and couldn't find. I remember it was something like that in release notes, but as you can see it yourself it's no longer there. Thank you again
[Magisk] mesiu84:
I checked that missing line and added it but now I don't pass the check with version 15.1, so I installed PlayIntegrityFork v5 and now I'm passing the check even without that FORCE_BASIC_ATTESTATION set to true. I'll play around with PlayIntegrityFix v15.1 and see if I can find what is wrong in my pif.json as now I use the one from example of PlayIntegrityFork.
[Magisk] shoey63:
Why not just stick with PlayIntegrityFork v5 if its working and 15.1 is causing issues?
[Magisk] mesiu84:
Because of my curiosity, I would like to know why 15.1 doesn't work while 14.6 still does. Funny thing, I have a second phone (Mi 10 pro) where 14.6 doesn't work and 15.1 with my custom pif.json does, that's why I'm curious what is wrong with my Mi9T Pro and what is the difference, since both use ROM from MIUIPolska (of course those are different phones and Mi9 is no longer supported, but still ...)
[Magisk] Umgak:
Fork doesn't care about FORCE_BASIC_ATTESTATION - the fork happened before that line was added to pif.json and their formats have diverged since. Fork format is as follows:

Spoiler content hidden.
[Magisk] mesiu84:
and I use exactly that one and it works. :-D
[Magisk] badabing2003:
Yeah, @chiteroman tends to do that, treat his releases more like dev builds than stable releases.

You might benefit with new features / aspects but also be at risk of breaking.

If you like to be on the latest, then you really have to check his commits (assuming that he does not wipe the commit history)

Like I previously said, you'd have to migrate your print to be compatible with 15.1

@osm0sis v5 migrated on install and you're passing.

I don't believe there is a migrate process in any of chiteroman versions.

I suggested you try the migration / conversion with PixelFlasher, if you don't make your print compatible with what 15.1 is expecting, you won't pass.

Some stuff are removed from the sample template, I don't know if it was removed intentionally or not.
[Magisk] Iridule:
I'm still thinking it's a numbers thing I've shared the exact same fingerprint a month ago with about 18 people and it still works I think once it reaches a certain amount of people it's flagged by some type of automated system.
[Magisk] SkyLK:
Just for information. I'm working on the DEV v2 version from chiteroman. I have my own pif.json (pif.json configuration valid at that time). And it still works beautifully.
[Magisk] beeshyams:
There's been talk of some apps by developers moving towards dropping support for devices before Pie, a few posts back, thus putting a lid on this pif spooking

Maybe I am being bordering paranoid but here's my thought.

1. I am not a developer but I guess a stripped down version of let's say TB checker is added a bank app

2. That app compares the output with actual device properties and when it sees a mismatch refuse to work.

3. Probably the same can be said of other methods too like I see on Tg channels (I don't understand them)

Is this a far-fetched or maybe just a realistic possibility in the game? This way they needn't drop support for pre-pie devices

Sorry, this is OT but had to ask wiser heads here
[Magisk] V0latyle:
Well, it would be naive to think the PI backend doesn't have some sort of abuse detection system, so my working theory on "how" prints get noticed is this:

Fix with embedded print is released

Everyone installs that fix

Everyone then checks Play Integrity

PI backend notices that there are literally thousands of PI requests coming from devices using that print

Anti-abuse mechanism triggers some sort of mismatch detection, so the print stops working for everyone who has a mismatch

To me, this makes more sense than Googlers trolling this and other threads looking for specific prints to flag. So, in that regard, I think a module that automatically picks a random working print when it's installed would be safe, because while the PI backend might notice a surge in traffic when everyone inevitably runs their PI check, we wouild all be lost in the clutter with all the other "legit" PI checks from apps.

Not really OT.

Magisk modules like USNF, USNF MOD, Play Integrity Fix, and Play Integrity Fork all work by spoofing device props for com.google.android.gms.unstable, aka Droidguard. This is the process that's GMS' built in root detection.

We aren't spoofing those props for any other apps - Play Store, Play Integrity API Checker, TB Checker, etc.

If you use a PI checker app (or the built in Play Store check), those apps will show your actual device props.

An app that polls Play Integerity is not "told" anything about device props. Yes, an app can "see" device props itself, but because nothing is being spoofed for that app, the app will not see a mismatch. The only thing PI does is answer the polling app's request for integrity labels.

So, if you open TB Checker or any other app, it sees your actual device props, and simply asks Play Integrity for a verdict. Play Integrity meanwhile sees the spoofed props, and (if everything is working correclty) returns BASIC and DEVICE verdicts because it thinks the device isn't capable of hardware attestation
[Magisk] arda99:
FORCE_BASIC_ATTESTATION is true by default, so it should work even it's missing in json.
[Magisk] dmenezes:
Yeah, November! Impressive! You must be the record holder among all of us here!
[Magisk] manjaroid:
I'm on the same print with your module for a month now, all the while trying to keep up with this thread and be ready for the day it stops working. The tampering side of me wouldn't mind trying something different but that probably means ye old 'Did you fork with it?' trouble shooting flowchart comes into play.
[Magisk] TheFreeman193:
A quick scrub through of the ARM64 lib in Ghidra appears to show it isn't utilising __system_property_read_callback like the PIF modules, but instead doing something weird with the __system_property_get function (deprecated and a non-global symbol since SDK 21) stubbed from libc. It reminds me a little bit of this though I'm not nearly experienced enough to understand how they're intercepting prop reads without actually modifying the property area.

I can't find any clear-air property names aside from ro.arch but it's obvious from Ghidra's version tracking correlation of v0.7.5 versus v1.0 that the latter has a LOT more obfuscation and possibly encryption. The included machikado.* files new in the latter also look suspiciously like 512-bit keys.

Here's a quick decompilation without external symbol resolution or relabelling for anyone interested.
[Magisk] V0latyle:
Pretty sure he is as he's more or less pioneered finding prints.

I'm still on a print I've been using since December 1st.
[Magisk] ArzZenic:
My FP from 5th December also still working :) On osm0sis fork v3.
[Magisk] Umgak:
Also still on first print I've found, 2023-12-01, initially on v3 and upgraded to v5. While I'm impressed at how long the Acer print has lasted on 15.1 (after being 'revived' from 14.6), I wouldn't be surprised if a chunk of that longevity is from the larger focus on distributing users across many prints, and I think that by far is still our best option going forward. I don't think Google is honestly looking too closely at this thread or project, or they'd have enabled mismatch enforcement on every single prop in @TheFreeman193's repo already.

This is by far the most likely scenario, imo. PI backend seeing thousands of attests from a 5+ year old device all at once is pretty blatant. Distributing users across many prints allows us to hide in statistical noise and makes the traffic seem far more plausible, in my opinion.
[Magisk] xSnowLeopardx:
Dec 2 found FP is still working amazingly. Still on v14.4.
[Magisk] xcl1pse:
Machikado is for integrity checking
[Magisk] SoulsAssassins:
Any idea anyone?
[Magisk] ArzZenic:
Use PixelFlasher and it does almost everything for you, excluding the FP :)
[Magisk] SoulsAssassins:
I will try thanks for the suggestion!
[Magisk] supermansaga:
Does KernelSu also have to use Play Integrity Fix to deal with passing device integrity?
[Magisk] EuK_V:
Did you do anything to hide

"init.rc is modified" and "debugging mode is enabled"?

I'm running of LOS20 and have these.

View attachment 6051729
[Magisk] arda99:
Per my test, all props, except ro.boot.flash.locked can be moved inside pif.json, but as Safetynet(and PI?) uses `getSystemService("persistent_data_block").getFlashLockState()` to check BL status, which reads ro.boot.flash.locked, we still have to keep resetprop for that.
[Magisk] simplepinoi177:
My custom fingerprint has been good since Dec 8. -- on my P7P, my wife's, and our two Pixel Watch 2's....

I am wondering how much it has made a difference that I found mine by actually extracting from a ROM firmware file because even though I was simultaneously testing from the repo's, I just wasn't passing on those found there. I can't say the one I chose to extract is an unknown off-brand, it's akin to Asus or Acer, so I am a bit surprised about that....
[Magisk] V0latyle:
And there's TEE, too:

So while we can "hide" unlocked bootloader by spoofing props, TEE will always snitch on us
[Magisk] arda99:
there're other bank apps detecting resetprop while don't care about BL status, that's why it's still useful to avoid resetprop.
[Magisk] V0latyle:
Yeah...

Honestly it would be easier on us if all app developers started using Play Integrity. I'm sure some of them would thumb their nose at pre-8 users, but I suspect those are the ones employing expensive and elaborate root detection engines in the first place...
[Magisk] zrspong:
I have been trying a ton of the TheFreeman's PIF all day and I have had no luck getting Device integrity. Been playing for hours, try using both chiteroman and osm0sis versions of the module. I'm tempted to just go stock at this point so I can use apps that are checking. Sigh

Pixel 7 Pro, latest 14 update from this month
[Magisk] Nergal di Cuthah:
Are you being sure to kill gms.unstable after appying a fingerprint and what method are you applying (adb, pixelflasher, internally cli)?
[Magisk] zrspong:
Using both pixelflasher TheFreeman193 pickaprint.sh script. Which both auto kills it.
[Magisk] V0latyle:
Use Play Integrity Fork
[Magisk] zrspong:
Same issue still. Tried latest version, and older versions too. Just because I saw people posting today that they had luck with V3. I have been out of the whole modding game with Android for a while and recently got back into it. Maybe I'm just doing something wrong. :/ Google and Android must make everything a pain these days.
[Magisk] pndwal:
I believe Shamiko is hiding that.

I just installed LOS fresh 3 days ago... Didn't have USB debugging (or even developer options) enabled yet... 😜 PW
[Magisk] intel_core_i7:
No it wouldn't.

The state of PI banning fingerprints very frequently will make nonroot custom ROM or unlocked bootloader users suffer. Many just want to have few more customization a new ROM would offer, or change the ROM region (Xiaomi CN v Global shenanigans) and does not want rooting at all. Making them have to root their phone and spend several hours to find a fp that might me banned in less than 24 hours doesn't sound like a great idea

I applaud apps not using SN/PI and using a custom root detection, because they actually make an effort to not mistakenly detect devices from people mentioned above. My brother's POCO F3 is running Evolution X ROM, although at a lower version where custom PI spoofing is not implemeted so DEVICE fails, but all banking & governmental apps work normally. Nothing has changed for him since the day of this whole dumpster fire happened.

Apps starting using PI would just make GMS or at least MicroG mandatory, which some also wouldn't like and probably make another antitrust
[Magisk] mike.s:
LOL. Don't be silly, of course they do. They own the copyrights to it. They could turn it closed source tomorrow if they wished (although existing forks could continue on their own way under the existing license(s)). There's a reason anyone contributing to Android has to:
[Magisk] simplepinoi177:
That's why in badabing2003's workflow/directions, he says to load up the xiaomi.pif first before trying PIFS(TheFreeman's)....to confirm the set up and everything is working as it should -- because if you're not passing with at least that fingerprint, which is confirmed to be working by supposedly thousands (at least until it's announced/posted the fingerprint got burned), then no amount of running the PIFS is gonna have you find passing DEVICE...
[Magisk] zrspong:
I can't seem to find his workflow. I was on chiteroman module for the longest time until it broke a few days ago, and then this update came. I started looking through the maze of the recent few pages and went straight to PIFS first, then tried pixelflasher.

Is there a solution, or? nah
[Magisk] V0latyle:
Hold up and try to be open minded, hoss.

Assuming my theory is correct - and so far it appears to be - getting "lost in the statistical noise" as @Umgak puts it appears to be pretty safe. We know how to [mostly] defeat Play Integrity. It's the devil we know. If all apps used the PI API, then we wouldn't have to deal with the guesswork of trying to defeat third party root detection.
[Magisk] xSnowLeopardx:
Severely off topic, but idc :cool:

Some big milestones are coming in this thread:

- when we hit 10k posts

- when we have 500 pages

Looking forward to them, lol
[Magisk] simplepinoi177:
That's why you shouldn't just skip around and take your time to do all the proper reading & research -- from "recent few pages" (looking at top liked posts would serve you better, you'll find the most notable are from weeks/dozens of pages ago), to "went straight to PIFS first, then tried pixelflasher" but didn't do the proper perquisite reading for each (PIFS, then PF)?

It's in the his post in this thread (3rd like post of All time for this thread) here that he's kept updated since he announced/displayed how PF can help, as well as the #4 post of the OP of his main PF development/support thread....

But it's step #1 in "UI Workflow for building/editing/testing pif.json from your PC" section and in "Additional notes" -- which I have highlighted orange for you for clarity...
[Magisk] intel_core_i7:
Then only rooted users benefit from this. My idea is nonroot users, which has a bigger proportion, will be affected by this.
[Magisk] V0latyle:
Why?

Non root users, assuming no modifications and locked bootloaders, will have zero issues.
[Magisk] HippoMan:
Yes! Let's have a 500 party and also a 10k party!
[Magisk] zrspong:
Obviously you're annoyed with users like me, don't worry mr staff I'll leave you alone now.
[Magisk] tom1807:
WTH, it fails to install because it needs Masgisk 26.404, I am staying so far on Magisk 26.400 (stable).

So, IMHO no need to update when everything is working incl. my FP from December 12 (was late to the game).

Cheers

Tom
[Magisk] V0latyle:
To be honest it's annoying to everyone when people don't bother reading the information that is readily available and instead ask questions that there are already easily found answers to. That's why Search Before Posting is Rule #1.
[Magisk] zrspong:
SORRY SIR, I GET IT IM SORRY SIR
[Magisk] intel_core_i7:
As I mentioned above, normal custom rom users who don't root and users who wants ROM region change will have issues.

Unlocking the bootloader doesn't mean an user wants to root their phone right away. We probably agree to disagree then.
[Magisk] BIGWORM:
I'll just leave a general, friendly reminder to give people time to answer questions, and to give it at least 24 hours before you bump a question. Thanks. =)
[Magisk] V0latyle:
I see your point now. Without root, custom ROMs couldn't use the fix.
[Magisk] EuK_V:
Shamiko? Hm.. I use Shamiko, but still have it, do you add some special process to Denylist to hide it?
[Magisk] shoey63:
Are you passing basic, or no integrity at all?
[Magisk] pndwal:
Nope... Only Momo... Unofficial LOS 18.1 on Mi Pad 4.... PW
[Magisk] osm0sis:
Could we just hook that as well?
[Magisk] arda99:
1. have everything setup inside pif.json(including ro.boot.flash.locked=1)

2. disable all resetprop entries in boot script.

3. run PI check, the ro.boot.flash.locked is properly hooked(in C++) but still fails

PI.

4. Without reboot, run "resetprop ro.boot.flash.locked 1" and will pass PI.

I think it has to be done inside java but anything under "com.android.server" is protected and inaccessible via reflection. No idea how to proceed...
[Magisk] osm0sis:
Someone emailed me recently about "hex patching" props instead of using resetprop... Where it's a simple 0 to 1 switch I wonder if that would be an actual reasonable option here. 🤔
[Magisk] arda99:
Yes, on a "clean" resetprop, the value is updated in place however the serial(?) is also updated. In Hex, it's like

clean boot:

ro.boot.flash.locked 00 00 00 00

resetprop to 1:

ro.boot.flash.locked 01 00 02 00

resetprop to 0 again

ro.boot.flash.locked 00 00 04 00

I haven't tried hex edit it yet...just some observations, don't know if it's the culprit for resetprop detection and, does a non-root app have access to that?
[Magisk] osm0sis:
Kinda looks like a counter. So I wonder if the first value could just be patched directly to 01 and avoid detection...

Yeah, it does seem some banking apps have started detecting tampered props somehow, not sure of the exact mechanism.

@huskydg may have some more clues: https://github.com/chiteroman/PlayIntegrityFix/issues/79
[Magisk] Stillhard:
This might interesting tho:

https://github.com/yxsra/MagiskResetPropMod
[Magisk] simplepinoi177:
I was just telling you how best to go about an issue (particularly in forum form) you made it a point to come here inquiring about -- to not just dive in head-first and be sure to do all available reading to best be prepared in what you are attempting; it's good advice in all aspects of life.

I mean, do you think if I was truly annoyed, I would've went through all that trouble of hyperlinking to you both resources/posts and even quoted it in the post for you to view the workflow (so you wouldn't even have to go to the actual posts yourself) and/or for you to now know a place to bring up any further Pixel Flasher issue you may come across?

...I really was just trying to be direct and helpful, both to answer your inquiry and to maybe prevent any annoyance or frustration you might receive if going about it in the same way in the future...
[Magisk] arda99:
This is the "clean" resetprop I'm using, the change is already in upstream magisk canary as well as his Magisk kitsune, but doesn't help the situation.

And hex editing DOES WORK, just resetting the increasing serial to 0.....now how to properly integrate it? or request it as a feature in magisk?
[Magisk] osm0sis:
Does resetprop -n still increase the serial?

I think official Magisk would be open to the feature request: https://github.com/topjohnwu/Magisk/issues
[Magisk] shoey63:
Magisk has a hexpatch function in ./magiskboot as per Official documentation

Usage: ./magiskboot <action> [args...]

hexpatch <file> <hexpattern1> <hexpattern2>
Search <hexpattern1> in <file>, and replace it with <hexpattern2>

Maybe it could be put in a startup script

@osm0sis ?
[Magisk] arda99:
yes, in fact, at least in the latest resetprop, "- n" is always applied when changing a "ro" property.

....made some progress
[Magisk] xcl1pse:
Something like this? I got this from people who also got that from PIF tg chat
[Magisk] vamteusz:
A13 (https://xdaforums.com/t/rom-13-official-pixelos-aosp-stable-06-07-2023.4402719/)

i don't know what to do, nothing helps
[Magisk] vamteusz:
if i flash clean custom rom then i have basic and device integrity. after flashing magisk integrities disappear. i'm using aosp rom based on android 13 (https://xdaforums.com/t/rom-13-official-pixelos-aosp-stable-06-07-2023.4402719/)

so i guess in this case is nothing more i can do?