yashsingh1/xdaforums huggingface dataset:
[Magisk] chiteroman:
Oh, I think I know where is the problem. Check Play Integrity from Play Store. Maybe this is the error you will get:View attachment 6011013

Fails Check · Issue #1 · chiteroman/PlayIntegrityFix

This error 17 has been haunting me attempting to get into the new Monster Hunter Now game release. Not sure what to do next to get past the integrity check...

github.com
[Magisk] novicecoder0:
Any solution for it?
[Magisk] pndwal:
You mean flashed from recovery?... Could well be the issue but can't be sure... If so factory reset likely won't fix, but dirty flashing same ROM should fix system issues if data hasn't been messed with too... PW
[Magisk] novicecoder0:
after formatting, I am able to pass the basic and device integrity tests, but not able to pass the strong integrity test. also can you plz tell me, what is that unmount function do on magisk delta canary. I used to use hide list to hide apps from detecticing root.
[Magisk] pndwal:
Well done... That's as good as it gets with unlocked bootloader. 😜

Better check Delta thread / ask current Delta users about evolution of SUlist etc... PW
[Magisk] bobo_15:
Hi, I'm using OP10 Pro with OOS with August patches

Latest version of the module, denylist on magisk enabled for Google Play services, Store Framework and Google Play Wallet

I'm able to pass just basic integrity but I'm not able to use Google Wallet to pay with a card

Could using Shamiko or Magisk Hide Props help me?
[Magisk] zgfg:
Better don't use the old MHCP

Did you try with Shamiko - don't expect a nuclear blast or so

If it won't work, try with Displax USNF instead of this PI Fix module

Test combinations, modules are systemless, once you disable/uninstall and reboot, it will like the module was never installed

And for different phones/ROMs, different combinations may work better or worse

Ofc, seek only for Device and Basic Integrity, and that is certainly enough for Wallet (btw, I pay every day by Google Wallet myself, with Device and Basic Integrity only)
[Magisk] chiteroman:
Follow this tutorial:

And send a screenshot of the result
[Magisk] pndwal:
Generally, having Google Play Services in denylist breaks Zygisk based USNF and forks if Denylist is active... This is because Denylist prevents/reverts Magisk modifications in listed processes and USNF and variants need to inject code to register fake keystore in GMS... The module should hide root from GMS natively in any case...

If that's your issue, rebooting should remove Play Services (GMS) from list automatically... And yes, disabling Denylist and using Shamiko will also work since proper root hiding doesn't deny Magisk modifications... You'd still be double-hiding root however which is redundant...

Generally you should have/only need Google Pay/Wallet in denylist and no other Google services/processes, so you should remove them.

🤠 PW
[Magisk] bobo_15:
I also have Systemless host module and magisk app Hide in the settings of magisk

I don't know if these two things are helpful or not
[Magisk] pndwal:
Those should be no issue for PI deviceIntegrity...

Just take all Google stuff out of denylist except GPay/Wallet and try again... 🙃 PW
[Magisk] mcreuter83:
Releases · chiteroman/PlayIntegrityFix

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

github.com

SAMSUNG A52S seems all good
[Magisk] zgfg:
Btw, if I didn't report yet, I tested v8.7 on my two devices and it's all good for me. Thx
[Magisk] quasyl:
That works perfectly well on Poco X5 pro 5g running Xiaomi.eu.
[Magisk] chiteroman:
Do you need it with Xiaomi.eu ? I think you just need to deny GMS main and unstable processes on Magisk and you can pass it without my module 👍
[Magisk] quasyl:
Yes, I did what you say and that works. Some time ago I passed in this way, without any magisk module but then, for some reason I had to use again the module, probably I messed zigisk deny list.
[Magisk] dmenezes:
OK, but given that Android is opensource, and we have root, what's impeding us to revert that patch, by overwriting the patched code with that previous one if need be?
[Magisk] zgfg:
Google fixes their part not in the ROM you have, not in your Security patch, not in the Google Play Services but on their servers that respond the final verdicts and in the bytecode that droidGuard on your phone obtains directly from Google server for each and every new attestation, and that collects and digitally signs data that will be sent to the Google's PI servers

Please take a look into the thread(s), there were links to the official Google documentation how the attestation works (from outside) and also the results from hackers investigation (trying to detect what's going inside the black-box), to see how the architecture looks like

The part we are talking about is not AOSP and not open source. AOSP will not pass PI. The point is that PI detects are you running the official ROM that vendor certified with Google

You're free to use AOSP but banking apps are free not to honor the AOSP custom ROMs😁
[Magisk] chiteroman:
You should understand how it works a hardware attestation.

Android Keystore system | App quality | Android Developers

developer.android.com

Verify hardware-backed key pairs with Key Attestation | App quality | Android Developers

A tool for verifying security properties of hardware-backed key pairs.

developer.android.com
[Magisk] Vision:
Thanks for answer, this is instructions, i see the TG is a mess 🤣 i waited to evolve the APatch, after maybe try it, now have Magisk Delta

Edit: Release apk

View attachment 6050182
[Magisk] Vision:
Maybe i missed something, with @osm0sis v5, just write values in the custom.pif.json and send it and replace the existing in the adb module folder, is not that easy? Like the example in the guide

View attachment 6050156
[Magisk] Lord Sithek:
@osm0sis I figured it out and indeed it was the ArrowOS source change. I reverted it and compiled Arrow again and now I'm able to pass DEVICE. The fingerprint included is burned for a long time but it seems that those fields are needed for PIF to be replaced. Or something like that
[Magisk] osm0sis:
That's the most likely answer I think! @vMAC if you'll check the logs with chit's to see if it's using yours or the included one that'll show what's up.
[Magisk] shoey63:
This works nicely 👍

I used termux and after entering su

Then

/data/data/com.termux/files/usr/bin/curl "https://raw.githubusercontent.com/ptewee/PIFS/main/pickaprint.sh" | sh

I got a working fingerprint on the first try!

But when I tried to find another one with ./pickaprint.sh , it reverted to the old format and didn't kill gms.unstable.

Also I couldn't find the works_for_me folder or the pickaworkingprint.sh script.

However, by continually entering

/data/data/com.termux/files/usr/bin/curl "https://raw.githubusercontent.com/ptewee/PIFS/main/pickaprint.sh" | sh I was quickly able to generate multiple working prints.

Edit: Using @osm0sis v5 fork
[Magisk] ptewee:
I think it could be due an issue with my code, which I fixed about 2 hours ago, that explains why your curl command was running perfectly fine (fresh from server), but not when running ./pickaprint.sh. You might want to try to download the scripts again.

For the works_for_me folder and pickaworkingprint.sh, you will need to manually create/download them and run them from Termux or ADB shell (my preference), I did not need to run them through curl so I omitted this part of the script.
[Magisk] ptewee:
Also to note, TheFreeman193 has an updated script, so my script is now outdated.
[Magisk] linuxares:
I had to ask the Apatch people what exactly what it was.

Apparently it's an alternative root method. Not sure how different it is compared to Magisk or KernelSU patching the image.

Time for poor @badabing2003 to update Pixelflasher again x3
[Magisk] osm0sis:
From what I understand so far APatch is sort of splitting the difference between Magisk and KernelSU.

Magisk does some kernel patching (not needed on all devices anymore) and hijacks the ramdisk to achieve root, KernelSU needs to either replace a whole GKI kernel or be built in from kernel source for pre-GKI, and APatch can actually fully patch itself into a pre-compiled arm64 kernel. Very cool.
[Magisk] HippoMan:
Does anyone know how APatch compares to Magisk and KSU w/r/t detectability?
[Magisk] badabing2003:
I'll do it when it becomes reliable and proper documentation is published.

The last thing I want is for me to become Apatch support technician :)
[Magisk] osm0sis:
He was referring to the PIFS/pickaprint update. 🙃

Very pleased to see my future-proofed custom.pif.json format become the default there. 😃
[Magisk] linuxares:
I meat the Freeman script been updated :) I understand that Apatch is still in very early stages and not stable yet :)
[Magisk] badabing2003:
Actually PixelFlasher does not run the script from @TheFreeman193 neither it does @osm0sis script :)

It has similar logic coded in Python, with some PixelFlasher smarts added to it to adapt to different module flavors / versions.

And you can load any json and the Smart Paste converts it to be compatible with the current module, filling in the blanks wherever it detects gaps.

And you can also go backwards, ie start with v5 json and load it for @chiteroman modules (probably not all, because it's hard to keep track of flip flops between each version) .

@linuxares ^^^
[Magisk] frasca61:
I am using my first fingerprint from December 12th, it still works. Today I tried to fish with Pixelflasher from Thefreeman193, I tried 10 times and found 5 working fingerprints that I keep as a reserve. I'm using Chiteroman Dev2, Magisk 26.4, Moto G42 with stock rom.

Special thanks to @badabing2003, @osm0sis, @chiteroman.

Thank you all !!

Happy 2024
[Magisk] linuxares:
ooooh! So you adapted his script basically? Neat :D
[Magisk] :
We must focus our efforts on this
[Magisk] osm0sis:
There are very large bug bounties for such things (for a reason), don't expect that any time soon.
[Magisk] Vision:
Definitely us 🤣 (A last, Before 2023 Ends)

View attachment 6050307
[Magisk] sahilkhurana:
Hi, pardon my lack of knowledge (and lack of familiarity with magisk), but I was trying to implement the play integrity fix using @osm0sis ‘s v5 release from https://github.com/osm0sis/PlayIntegrityFork. Here are the steps that I followed

1. Downloaded .zip file( v5 release) , extracted it to a folder.

2. created custom.pif.json by using a device build.prop that I want to sp oof And replaced example json with this.

3. Re-zipped folder and tried to add this via Magisk -> Modules -> Add module from storage and pointed to this zip file

4. Magisk didn’t install and errored out (some zip file error)

can someone pls enlighten my noob mind and let me know what am i doing wrong. TIA
[Magisk] majorfigjam:
You're overcomplicating things.

Just install the v5 module in Magisk, and copy the json file into data/adb/modules/playintegrity fix.

Go to airplane mode, stop and clear caches of Play Store and Play Services, and then come out of airplane mode.

IF your json is valid, it will work - unless you use QPR2 Beta in Pixel.
[Magisk] Umgak:
No reason to do any of that. Flash the module from github, then just copy over the custom.pif.json and su -c killall com.google.android.gms.unstable.
[Magisk] simplepinoi177:
on top of what everyone else has been advising....

if i'm reading this correctly and taking it literally (no presumption on what you meant instead), you can't just simply take a "donor build.prop" from a device you "want to spoof" and place it where the custom pif.json is -- if that's what happened here.

If that is what happened here, you have to copy the fields/values as seen in osmosis' guidelines (3rd section; Click to Show Content button), format them properly, and save it as a pif.json, THEN place it in the proper folder....
[Magisk] xSnowLeopardx:
Let Google fail in 2024 so we can all enjoy our FPs in peace.
[Magisk] FrogMaster-:
Do not unzip the module, just flash the ZIP package that you downloaded.

If you have a build.prop file, you'll also need process that build.prop file by one of the following methods

Manually extracting the correct fields from the build.prop and filling the example.pif.json @osm0sis has an overview on this here

Processing the build.prop with @osm0sis' gen_pif script

Processing the build.prop with @badabing2003's PixelFlasher

Since you're using @osm0sis' fork you'll move the custom.pif.json to /data/adb/modules/playintegrityfix/custom.pif.json (PixelFlasher will do this for you automatically when you update your PIF.)

Kill GMS su -c killall com.google.android.gms.unstable (PixelFlasher will do this for you automatically when you update your PIF if you have the appropriate checkbox selected.)

Test if you pass Basic / Device integrity with whatever method you're most comfortable with SPIC, TBChecker, PlayStore, YASNAC, ETC...
[Magisk] Fry-kun:
Is play integrity checking really slow today or is it just me?
[Magisk] Nergal di Cuthah:
What're you using to check? Maybe too many people checking right now (depending on what you use)

Edit: Just checked with play integrity checker and went normal speed for me.
[Magisk] pndwal:
Since my phone (Redmi Note 8T) is dead for the time being, Ive been playing with PIF on my tablet (Mi Pad 4 running LineageOS 18.1, unofficial)...

While having no problem with @osmosis' fork, I couldn't get @chiteroman latest to work at all...

I consistently get basic integrity only for both S/N and PI... S/N ctsProfileMatch fails despite BASIC-only evaluationType, so it isn't because S/N is enforcing HARDWARE_BACKED evaluated verdict use... Won't work with his current Acer print/prop set with no changes, or with any working custom json files...

Maybe some devices actually require Shadow Hook builds to work?... Other reasons anyone?... 🤔 PW
[Magisk] arda99:
What's the logcat? does dobby find the necessary function?
[Magisk] pndwal:
Thanks... I'll try to get that later. PW
[Magisk] sahilkhurana:
H

Hi, thanks for the suggestion. I have followed very well written guide and have extracted the required fields only from build.prop
[Magisk] sahilkhurana:
Thanks for your reply.

1. Noted. This is what I was doing wrong.

2. Have done it already and manually populated example.pif.json fields from the spoofed device's build.prop

3, 4, 5 - Yes, will follow this.
[Magisk] sethieplayz:
Not working for me at all at the moment, on playstore or TB checker
[Magisk] weskerty:
He estado buscando soluciones a esto porque WhatsApp ahora está intentando bloquear con sistemas que tienen el gestor de arranque desbloqueado...

Mod translation: I've been looking for solutions to this because WhatsApp is now trying to crash with systems that have the bootloader unlocked...
[Magisk] majorfigjam:
Ok, so you may be in the right place. Read this post, https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/page-177#post-89189572 which will start you on the path to regaining play integrity, and maybe making WhatsApp work properly.
[Magisk] HippoMan:
Resulta que hay un módulo que se llama "BootloaderSpoofer" que puede fingir que el gestor de arranque esté bloqueado cuando no está así en realidad ("It turns out that there's a module called 'BootloaderSpoofer' which spoofs a locked bootloader when it's actually unlocked").

Vale la pena investigar el "BootloaderSpoofer" ("it's worthwhile checking out 'BootloaderSpoofer' ").

También, una regla para este foro es que comuniquemos en inglés. Puede usar un servicio como el Google Translate ("also, a rule for this forum is that we communicate in English. You could use a service like Google Translate").
[Magisk] vMAC:
This is what it showed:

C:\android\platform-tools>adb shell "logcat | grep PIF"
01-01 00:28:00.537 28803 4394 D PIF/Java: DroidGuard call certificate chain! Throw exception.
01-01 00:28:00.540 28803 4394 D PIF/Native: [ro.zygote] -> zygote64
01-01 00:28:00.540 28803 4394 D PIF/Native: [ro.product.first_api_level] -> 24
01-01 00:28:00.540 28803 4394 D PIF/Native: [ro.boot.verifiedbootstate] -> green
01-01 00:28:00.540 28803 4394 D PIF/Native: [ro.boot.vbmeta.digest] -> ff3ae088da1fc98aa0f4a86593d43c5c6d4fa1005ce003666fb2c922fdb3f0e9
01-01 00:28:00.545 28803 4394 D PIF/Java: DroidGuard call certificate chain! Throw exception.
01-01 00:28:00.594 28803 4394 D PIF/Native: [ro.surface_flinger.has_wide_color_display] -> true
01-01 00:28:00.594 28803 4394 D PIF/Native: [ro.surface_flinger.has_HDR_display] -> true
01-01 00:28:00.712 28803 4394 D PIF/Native: [ro.secure] -> 1
01-01 00:28:00.712 28803 4394 D PIF/Native: [ro.debuggable] -> 0
01-01 00:28:00.741 28803 4394 D PIF/Native: [ro.boot.hardware.revision] -> MP1.0
01-01 00:28:00.741 28803 4394 D PIF/Native: [ro.vendor.api_level] -> 24
01-01 00:28:00.791 28803 4394 D PIF/Native: [ro.build.version.security_patch] -> 2018-04-01
01-01 00:28:00.792 28803 4394 D PIF/Native: [ro.boot.flash.locked] -> 1
01-01 00:28:00.792 28803 4394 D PIF/Native: [ro.boot.vbmeta.device_state] -> locked

I don't think that has the print in it. If there is a different debug level I need to use let me know. When I run getprop grep fingerprint it shows my original husky fp. Checking the thread I find that this is as intended, but I can't find a way to see what DroidGuard is actually seeing.......
[Magisk] gllark:
Coming from the dev2-version from chiteroman with a working fingerprint since 3 weeks now converting to @osm0sis fork v5 worked like a charm. Thanks to the devs, fantastic work!
[Magisk] chiteroman:
GitHub - chiteroman/Reprogram-TEE-on-Qualcomm-devices: Guide to reprogram the TEE on Qualcomm devices to fix lost attestation keys

Guide to reprogram the TEE on Qualcomm devices to fix lost attestation keys - chiteroman/Reprogram-TEE-on-Qualcomm-devices

github.com

Will write a mini guide :D
[Magisk] Vision:
Happy New Year to Everyone! 🥳
[Magisk] osm0sis:
That's from 15.1 by the looks of it so there are no log levels, you just need to run the log earlier, directly after a reboot to catch it all cleanly.
[Magisk] Vision:
For Anyone who don't want involved with adb command or similar

Maybe the same work with @osm0sis module (not test this part yet)

For quick and easy test (if you have already installed this module, test it only with v14) if FP working, send the new pif.json file to /data/adb and replaced the existing, 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 the replace) after do the test if pass 2/3
[Magisk] pndwal:
Spoiler content hidden.

Spoiler content hidden.

Results after running Play Integrity API Checker once in each case... Is Java code just not running in @chiteroman PIF? 👍 PW
[Magisk] pndwal:
In 10), what is 'json file form Downloads'?... Guessing it's a custom print set (not from PIF .zip archive)?

Also, in later steps you don't appear to have removed pif.json from /data/adb/modules/playintegrityfix... I suspect that this bundled json (with Acer prop set) may be in use, not your custom one...

I note that the last instructions on this (in release notes for 14.4) say:

Also, when you run logcat, try leaving it running, run Play Integrity API Checker once and come back to it... The entries for the attestation call should then populate...

FWIW, I run logcat | grep 'PIF' from a terminal emulator on device...

🤠 PW
[Magisk] osm0sis:
Neither of those are early enough, you'll know that you've got it right when it shows the lines about loading the json and dex files.
[Magisk] Nekromantik:
Which script haa logic to choose correct force abi versions for pixel devices? Or is it still manual and you have to set it first?
[Magisk] badabing2003:
If I'm not mistaken @TheFreeman193 script keeps it flexible and leaves it to the user to set the abilist as wide or as narrow the user wants.

PixelFlasher sets it to arm64-v8a,armeabi-v7a,armeabi when it detects a newer device.

Less flexible but automatic.
[Magisk] Nekromantik:
on the auto check play integrity, the app does not wait long enough for the result and then says result not found

am using tbchecker
[Magisk] droidman1992:
Wow, play integrity next is working for so long, our lovely guy at Google must be on Holiday leave. He will probably clock in tomorrow and do what he does best, burn fingerprints, how he earns his salary and public enemy number one.
[Magisk] pndwal:
So I guess I'll need to use PC/ADB for that, not a TE as I was doing... (Or is there a way?) 👍 PW
[Magisk] Umgak:
Logcat saves some history, so if you're quick after booting it might still be in the log, depending on how much your OS, sensors, and installed apps manage to dump into the buffer before you open Termux and type the command. I just tested, and the first run I did was able to collect the log, but another run about 30 seconds later was empty of PIF. May want to just use adb wait-for-device to avoid the guesswork.
[Magisk] BROKEN1981:
All 5 of my custom prints have been banned. I deleted all of them out of my Google drive folder. I came to ask a dumb question.

Since Google does scan drive looking for illegal content, could it be possible that I got myself caught? Where does everyone else store their custom prints?

Since I need to look for more, having 20+ prints no longer seems like overkill.
[Magisk] Umgak:
As far as I know, zero of my 39 prints have been banned. They're all just on my PC, sitting in a couple of folders. Did you get your prints from public dumps online or did you dump system ROMs? Mine aren't from public dumps.
[Magisk] majorfigjam:
You're obviously very unlucky, or something else has changed with your setup. As far as I know, all 20+ of mine still return 2/3.

Have you migrated to Osm0sis v5 (in which case the script might have corrupted your print) or are you still using Chiteroman in which case it may be overwriting your custom print? Does logcat show that you are sending your custom print(s)?

FWIW I store my prints on a pc folder, with copies on my phone in case I ever need to make a quick change - which hasn't happened in a month so far.

.
[Magisk] BROKEN1981:
Still using 14.0
[Magisk] simplepinoi177:
Question....I have a personal theory I'm working on....

Where did you get your prints? The scripts?

Also, what kind of Android devices were they; Shield TV, Android Auto's, Tablets, Camera's (I've seen some people, maybe jokingly, talking about using these)? Or was every single one of them a smartphone, specifically?

If gotten from repos, I read somewhere (I wish I remember or wrote it down where) how it seems getting props not from those repos seem to have better longevity than from repos...I'm curious/wondering how true this seems...

Because I personally was only able to find one that wasn't in a repo (because the ones I was manually getting from a repo just so happened to not be passing; but I know a lot more things better now and tools are better now and most likely it wasn't implemented properly). So mine is still going from finding it on the 8th, and I'm wondering how strongly it is simply because it wasn't from a repo...

Thanks in advanced for satisfying my curiousity!
[Magisk] majorfigjam:
Which was the one that allowed custom prints, if I recall. No other config changes, modules or anything like that going on?

Picking up on the other point, are you using non-phone prints? All of mine are phones. I'm happy to share one with you (Osm0sis format now) if you want to test a known working print. I guess you could reformat the details if that's easier.
[Magisk] Umgak:
Anecdotal, but the device my print is from had only a few dumps I could find online. Every single one of the prints in those dumps was already banned. I wrote a script to automatically dump props for that phone from zips into pif-formatted jsons and got a ton of working props, 71% of which came from Open Beta builds. About 60% of builds overall were working.

Edit: oh, and all of mine are from an actual phone that's actually sitting on my desk.
[Magisk] msi68:
Has anyone tested this on OP phone?
[Magisk] TheRomRooster:
had my 13 PIFs in GDrive for a week now, none of them got banned