yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
Clear Play Services cache

Force stop and clear Play Store cache (shouldn't affect Wallet but just in case)

Force stop and clear both Google Play and Wallet cache

Attempt to add cards again
[Magisk] BesoC:
Thanks a lot. That did a trick ;)(y)
[Magisk] awarexda:
Re-adding cards is a hassle for sure.

Maybe wallet can work although the popup error shows. Did you try?
[Magisk] aimless0079:
My god, 8 hours later I finally convinced Google wallet to play ball again and my card works again,I have no hair left.
[Magisk] Captain_Throwback:
It happened again.

EDIT: What's weird is this time it's staying that way :eek:

EDIT 2: I am so confused right now
[Magisk] V0latyle:
What do you mean "happened"?

Since this is an ASUS device I think you probably have a broken keystore? What's your configuration?
[Magisk] Captain_Throwback:
Broken keystore? That's never been a thing on this device that I'm aware of. This is a ZenFone 9, not an old ROG Phone. And prior to installing the latest APatch update and Zygisk Next 1.0-RC4, I was only passing BASIC and DEVICE. Those were the only updates I made, besides disabling Zygisk Qingyue.

I've only seen STRONG once before and that was just a blip. This is the first time it has persisted and is still displaying that way, since the old STRONG hack that was patched.

So I can't imagine my keystore just randomly broke out of nowhere when I haven't touched anything related to it.
[Magisk] V0latyle:
Oh, My bad.

I don't know enough about either of those modules. I assume you're using a custom print?
[Magisk] Captain_Throwback:
I'm using the same griffin print that everyone else is using with PIFork v8, which is why this makes absolutely no sense.

EDIT: I actually just checked the module folder, and my custom.pif.json is no longer there. So now I'm even more confused.
[Magisk] V0latyle:
O_o

Maybe search the entire /data/adb directory and subdirectories for jsons?

Anyway, it's clear that this is a really strange bug, you haven't actively tried to do anything to accomplish STRONG such as configuring your keystore or installing a custom key. Very interesting. I wish I had the expertise to ask you relevant questions about this so we can explore it further and try to determine why this is happening. Maybe talk to @osm0sis and @badabing2003?
[Magisk] Captain_Throwback:
Okay, so here's my full setup.

Device: ASUS ZenFone 9

ROM: Stock Android 14

Kernel: Stock

Root: APatch 10570, w/KPatch 0.10.4

Modules installed:

- ADB & Fastboot 1.0.41

- bindhosts 1.3.5

- Play Integrity Fork v8 (with no custom.pif.json installed)

- Zygisk Qingyue (disabled)

- update_payload_extractor (local homegrown module, unrelated to root)

- zygisk-detach 1.13.0

- Zygisk Next 1.0-RC4

I don't have anything special going on except that somehow my custom.pif.json got removed at some point (I don't know when) and now I'm suddenly passing all the integrities. All I know is that I'll never reboot my device again, lol.
[Magisk] Captain_Throwback:
No jsons anywhere. I posted my device details and setup, so maybe someone else with the same device (or a different device) can try and see if they get the same result. But whatever this bug is, I'm going to enjoy it while it lasts.
[Magisk] Sheist!:
I'll begin the odds. You will leave this casino more-broke. 🤓

Your setup seems overly complex to me.
[Magisk] asisandroid:
do apps requiring strong work? (a little double check because I havent ever seen this)
[Magisk] Captain_Throwback:
What's complex about it? It's a root solution and modules, same as everyone else's setup...
[Magisk] Captain_Throwback:
I don't have any apps that require STRONG, so I have no idea
[Magisk] zgfg:
Terninal emulator:

su killall com.google.android.gms.unstable

su -c logcat -c

Retest Play Integrity

and again from TE:

su -c logcat -d | grep PIF

And check what does tgat PIF logcat say about reading JSON and spoofing prints

If everything as you described, PIF logcat should show nothing and PIF is not instrumental for your Strong Integrity, but things cone from your APatch, your Zygisk alternative modules, your Zenfone and so
[Magisk] Vision:
Yeah good thought, @Captain_Throwback go to try some apps need Strong, like this with the app need strong with the filters that everyone says
[Magisk] asisandroid:
Try uber but im not sure if they still require strong or if I misread some old post but a lot said it requires strong
[Magisk] Captain_Throwback:
$ su -c logcat -d | grep PIF

03-18 15:19:16.034 9986 9986 D PIF/Native: Couldn't read json file

Seems you're right - PIF isn't spoofing anything
[Magisk] V0latyle:
I don't think it would matter which app is requesting the labels. If TB Checker/SPIC/Play Store are getting STRONG from Droidguard, every other app that polls Play Integrity would too.
[Magisk] Sheist!:
Everyone does not use the same setup. I use chiteroman's solution with playcurl and stock Zygisk.
[Magisk] Captain_Throwback:
That is a root solution and modules, like I said. There's nothing overly complex about that, was my point.
[Magisk] Vision:
Yeah right, that is interesting, just i mentioned this app with filters if @Captain_Throwback not remember any with strong and want to try it
[Magisk] V0latyle:
It's similar enough though. I have Magisk, PIFork v8, and a bunch of other unrelated modules. The only difference is he's rooted with APatch so he doesn't have integrated Zygisk; hence the need for Zygisk-Next
[Magisk] badabing2003:
It doesn't add up.

Your bootloader is unlocked, and you're rooted.

You don't have bootloader spoofer running, and you're passing strong? with no pif print? As in 3/3?
[Magisk] Vision:
@Captain_Throwback from curious, the Key Attestation Demo what say inside ?
[Magisk] Moscha:
Updatet to 1.5.9.6 today: Everything works 👍👍👍

Thanks for all your work!!!
[Magisk] Captain_Throwback:
You've seen the tests. And I agree that it doesn't add up. And yet, here we are. 🤷‍♂️
[Magisk] Vision:
Τhat's what he said, very interesting and strange, how is possible this? some error from Google side ? or something broke in his device
[Magisk] Vision:
This is very interesting and strange.

Say KeyMint version not Keymaster, but maybe this is different in another device
[Magisk] Captain_Throwback:
It's not strange at all. I think you just don't have a current device.
[Magisk] Vision:
Yeah i have Xiaomi for that i say maybe this is different in another device.

But i mean the strange is pass 3/3 with unlocked and root without you have change anything else like you say
[Magisk] pndwal:
These devices may actually give us clues about how G is "banning" print/prop sets for hardware key attestation capable devices...

Please would you be good enough to give the native fingerprint prop value for your current ROM? (Apps like TB Checker, Momo etc will show this... PM it to me if you prefer.) 👍
[Magisk] Vision:
@chiteroman @osm0sis @zgfg @pndwal and the other Big Brain

@Captain_Throwback don't touch your device it's evidence for now, until the Big Brain see what happens and may be reproduced the issue pass 3/3 and the Key Att. say is locked
[Magisk] osm0sis:
Quick! Become an Uber driver! For science! 🤣

You're forgetting the module still does the global resetprops at boot time even with no json, which is generally bootloader lock status stuff, so could be some small part of why his device now actually thinks it's locked. 🤷‍♂️
[Magisk] zgfg:
This is something he can easily test by renaming service.sh andy/or post-fs-data.sh to bak and reboot

But I didn't 'forget'. I just simplified the statement - If those simple general props from service.sh/post-fs-data.sh scripts did the job for him, they would have to similarly do for others, at least to somebody so far

There must be something in his non-standatd setup (Zenfone if I remember, APatch instead of Magisk, his attennative Zygisk modules)

Maybe couple of those factors together, but as we see not the spoofing prints as was the purpuse of the test confirmed with logcat
[Magisk] osm0sis:
Obviously. I didn't suggest it was my scripts alone, but some combination of his root setup, possibly with the global resetprops helping.
[Magisk] pndwal:
He could!.. I think Uber Driver will surely work, BUT that doesn't mean it requires STRONG pass necessarily...

As key attestation demo (and Momo etc) shows, there are ways for apps to see (a number of) boot state signals, and these have apparently been spoofed (and Driver app has worked) even with DEVICE_INTEGRITY only. 👀 PW
[Magisk] badabing2003:
But he doesn't even have global reset props does he?
[Magisk] Captain_Throwback:
I have PIFork installed, so the scripts included there should be running, where the global resetprops are taking place. It's just the json spoofing that isn't happening since I don't have a json file installed.
[Magisk] Vision:
Before happen this with Strong, you have PIF fork V7 and after update to v8 ? Or even other root method like Magisk?
[Magisk] Captain_Throwback:
I've been on v8 since released, and I've been using APatch for several weeks. The only thing I did today was upgrade to the latest APatch, and install the new Zygisk Next. And I disabled Qingyue. I'm still not sure when the custom.pif.json got removed from my module folder, tbh.
[Magisk] Vision:
Maybe Google choose a device in random for test something about Strong, and this device it's yours @Captain_Throwback

😂🤣
[Magisk] wugga3:
Edit...
[Magisk] Captain_Throwback:
We have always spoofed bootloader status, that's not new.
[Magisk] wugga3:
Thank you for the response @Captain_Throwback
[Magisk] osm0sis:
What's interesting is Key Attestation Demo app usually still knows it's unlocked.
[Magisk] Captain_Throwback:
Does it? It's always showed as locked for me. Maybe because I'm using APatch?
[Magisk] BunnyPig1:
Would be interesting if anyone with the same phone could replicate this.

That could help determine if it's the software setup that's doing all this or if it's the hardware that breaks somehow.
[Magisk] osm0sis:
Yeah..!

And that's with Shamiko, PIFork, and Key Attestation Demo on the DenyList (unenforced for Shamiko). I'm on latest Magisk Canary. I don't see why APatch would have any bearing on that. 😯🤔
[Magisk] osm0sis:
Uber Rider works with DEVICE (though reportedly still somewhat neutered), but Uber Driver has repeatedly been discussed as one of the few apps requiring STRONG.
[Magisk] pndwal:
And I repeatedly responded to that till I gave up since the member who published the how-to (after the August changes) later (post September IIRC) failed to confirm it's still working on his two different modded devices... It is possible they made further changes since August updates and now require it, but given the degree of difficulty overcoming the August changes and since no-one else reported accomplishing that feat, I think the August hardening (not STRONG requirement) probably still accounts for that perception. PW
[Magisk] pndwal:
Can you confirm after update to 1.6.0?... vv and Rikka patched a few things... 👍 PW
[Magisk] HippoMan:
Maybe the special-purpose GIMP utility was used ... ?

:)
[Magisk] Captain_Throwback:
Isn't that the version I used?
[Magisk] Captain_Throwback:
If it was fake, I definitely would've made it obvious...

EDIT: Here's a video of my device, from APatch to Termux to kill DroidGuard and then to the Play Integrity check in Play Store. I'm tempted to reboot and see if it sticks, but I'm too scared to lose it...
[Magisk] pndwal:
Haha, yes... I'd read 1.5.0... must be blind, sorry!...

Re. strong to be passing however, short of reprogramming tee with 'leaked' keys (which you haven't), that verdict has to be either based on a bad Keymaster implementation that shows up with your configuration and because G hasn't yet discovered it and revoked certificates for strong, or because it's a fake pass based on print/prop set polled akin to the Pixel 2 faux pas... Google may be fiddling with processing algorithms for DroidGuard signals, but I'd bet another Asus amateurish attempt to implement their Keymaster is the root cause (like Rog phone)... If you always saw Bootloader is Locked (even before gaining MEETS_STRONG verdict), that's another indicaton... 🤠 PW
[Magisk] pndwal:
I could say more about what I said above, but probably shouldn't, except that what's changed is that you're (unexpectedly) using the native print/prop set and not even using fallback to BASIC-only attestation it seems... @shoey63 may have advice for you... PW
[Magisk] Captain_Throwback:
It would be nice if someone else with my device could test the same setup, but I haven't seen any takers yet...
[Magisk] pndwal:
Gave (more) clues about how to test above... (Hide root, use Shamiko, probably don't need PIF at all, keep mum)... 😉 PW
[Magisk] Captain_Throwback:
Well I still need PIF to set those global resetprops; I just don't need it for spoofing. And since I'm using the Fork, there's no default json that sets anything, so it really is just the props that are being set, I believe.

I also did finally decide to reboot and I still pass Strong Integrity, so it seems to not just be a fluke like the first time I saw Strong back in December. If I had realized how I was passing Strong then, it's possible I could've been passing it this entire time...

P.S. I can't really use Shamiko since I use APatch. I don't believe the latest version is compatible. But either way I'm reluctant to adjust my setup since it really can't get any better than it is now.
[Magisk] pndwal:
Yeah, you need a solution for sensitive props (can even install MHPC module and not even configure it as sets these to expected values by default, Shamiko did that too...) and to hide DroidGuard process only I think... You were probably passing when you didn't use a PIF JSON previously also, or had fork or original configured wrong?... 🙃 PW
[Magisk] Captain_Throwback:
So I tested this theory, and it seems you're correct; I don't actually need PIF at all.

I tried MHPC, but only passed Basic.

With Shamiko, however, using the latest compatible version with APatch (0.7.4), I pass Strong Integrity, without any PIF module enabled.

I guess this is similar to the ASUS situation that also occurred on ROG 3, so I have no idea how long it'll last. In the meantime, I'll just enjoy it.
[Magisk] osm0sis:
Yeah, confirms you only need those global props set somehow. 👍
[Magisk] menuisier3:
Hello, again this morning, no more RCS chat.

Will there be a solution?

thanks again
[Magisk] Nergal di Cuthah:
Read for the solution it's been given over and over, hint get a working fingerprint and clear cattier services data.
[Magisk] pndwal:
Yeah, Ohhh Asus...

Anyway, guess there may be new sensitive props (for late devices?) added since MagiskHide went west... @Didgeridoohan just replicated MagiskHide props in MHPC... Good you can add Shamiko with APatch anyway as I guess it needs a proper hiding solution...

@osm0sis or others make know/say which props are in Shamiko and PIF resetprop scripts that are extra to old MagiskHide props... 👍 PW
[Magisk] Eclipse1991:
So I was using 15.9.4 PIF by chiteroman and then I updated it to 15.9.6 and now I cant even pass any integrity ? Im on latest xiaomi.eu Miui14 Stable with my POCOF4 and I use latest Magisk Alpha. Before updating to the new version I had PIF next by daboynb also installed. Any hints ?
[Magisk] pndwal:
It seems Asus is repeating the same mistakes in Keymaster implementation (like OnePlus did for years, but worse as it's giving Verified as boot state), so Asus users may want to check any devices using Key Attestation app... That was a big clue re. what's occurring with yours...

Re this:

Actually the answer is Yes... Bootloader status is only spoofed generally if Bootloader spoofer is used, TEE is reprogrammed etc, otherwise assume OEM messed up (very doubtful that big G will again!).

If users see Bootloader is locked when it's not, consider being circumspect about device details, even here... 🙃 PW
[Magisk] wyt18:
15.9.5 didn't work, 15.9.6 bricked my S9 stock A10 rom and now I have to reinstall the stock rom. Suggest those who aren't used to tinkering not try these versions until more users report no issues with them
[Magisk] Sheist!:
15.9.6 works for me like 15.9.4, v10 playcurl.
[Magisk] awarexda:
I don't understand why risk to update if the already installed version is working...

Just for the "NEW" feeling? These are anyway very risky moves and our phones are now so much important in all our functions (phone, social, navigation etc)
[Magisk] FrogMaster-:
I'm going to give your script a crack tomorrow against the build.prop files I retrieved from Tadi. I reprocessed the build.prop files with my python script, tested all 1021 JSON files that were generated, three separate times with different API levels (The initial, 25 and 23) so far, still only seeing prints that pass basic.

My script was able to process the Griffin build.prop perfectly into a working print passing device though; So not sure if Tadi is actually burned, or if my script is potentially incorrectly processing properties which is causing me to miss prints that would be valid for Device.
[Magisk] CZ.Kostra:
Check if the Xiaomi.eu injector is correctly removed. The 'eu.xiaomi.module.inject' app must be version '0' or not present at all.
[Magisk] Eclipse1991:
I could fix the issue by clearing data of Google Play Services , Play Store and Framework. Pfieu , I thought I needed to start from scratch.
[Magisk] zgfg:
I finally kicked my ass yesterday evening and started to test again, now through an archive that I downloaded long ago but did not explore from my side previously (at those times I haf few hundredths of working prints mined from other sources and there are always ovelapps, etc)

So, tested tonight 189 JSON files and FOUND again a 'private' working one - already switched to from the common Xiaomi.eu 'public' one

Attaching my original script, now expanded to easily switch testing PI by between SPIC or TBChecker - lines 152/153.

Liwering API is now also adapted to change all rhree prints (for various PI Fix/Fork versions)

Few comments regarding to the changes I've seen when you earlier pisted your modifications:

- You don't need to bother with API 23, if 25 doesn't help, move to the next json

- As you can see, I use also YASNAC to faster eliminate those that don't even pass SN Basic and to immediately lower API to 25 if SN passes Basic but not CTS

- Also, don't miss fixing of the orientation during the automated testing, lines 35-38, 215-216

Over the day I will improve that the script really checks if API was already 25 (thanks, I will share that from your adaptation), so that it doesn't waste time by 'changing' API to 25 and retesting PI again if it was already 25 and didn't pass Device Integrity

File on MEGA

mega.nz

---

PS: So far, found 81 'private' ones - all together, going better than expected :)

Google could have done their job better, even among their own phones

EDIT:

Script re-uploaded with changes and improvements:

- renamed to original pif-test.sh name

- it checks now the API level and does not waste time on 'lovering' and retesting if already on 25

- better logging to pif.txt

- pre-testing by Yasnac is disabled (it can be enabled by uncommenting the line 7, but currently I test JSON files that mostly pass SN CTS Basic and in that case PI must nevertheless test with original API level and pissibly lowered to 25, hence pre-testing by Yasnac is waste of time)

- enabled testing PI by TB-Checker instead of by SPIC (to switch, comment/uncommenti lines 146/147)
[Magisk] hanschke:
how to fix it manual?
[Magisk] shoey63:
In my experience, broken TEE which hasn't yet been blacklisted and a certified stock OEM rom only needs root hidden and suspicious props changed (verifiedbootstate etc) to pass STRONG_INTEGRITY.

Shamiko does this quite effectively.

My ROG 3 is problematic now for these sort of tests.

Key attestation shows locked bootloader but keys have been revoked, probably due to my injudicious flaunting of STRONG_INTEGRITY in these threads a while back.View attachment 6081880

But why is this anomaly occurring with certain ASUS devices?

My guess is their unlock tool doesn't properly unlock the bootloader as would be the case if it were done via fastboot.

This would explain why they have taken the tool down (Maybe ordered by Google to do so).

It would be interesting to see the key attestation results of other ASUS users who own different devices, and have used the ASUS unlock tool.
[Magisk] chiteroman:
Your device has the Keymaster's bug, it will always sign as verified the root of trust. Check Key Attestation Demo app.

APatch isn't detected by DroidGuard, if you use Magisk or KernelSU it will be detected. Also, if you install some modules in APatch it will trigger DroidGuard, but instead failing all, you will only pass BASIC.

This happen because Google has unknown checks to detect custom boot partition.

If you want, I can share you my PlayIntegrityFix-Strong module via PM, it has a "magic" fingerprint to bypass all this restrictions and pass Strong with any root solution.
[Magisk] bentree:
I have a zenfone 9 but it isn't unlocked and from what I have read it can't be unlocked, until ASUS fixes the unlock tool :( Otherwise I'd literally test this for you.

Cheers, Bentree
[Magisk] Vision:
If you have this, i want, i need it 😂🤣

if you read my story, then you will understand why I need it 😂🤣
[Magisk] pndwal:
But if DroidGuard detects Magisk (I know it does, but I presume you mean even when hidden by PIF or by alternatives like Shamiko), wouldn't DEVICE_INTEGRITY always fail for PIF users? 🤔 PW
[Magisk] chiteroman:
You need a device with a valid certificate chain with no revoked certs...
[Magisk] chiteroman:
DroidGuard has unknown checks...
[Magisk] Vision:
I have Xiaomi all Stock, with Kitsune Mask and only module PIF, no other modifications and before unlocked BL pass 3/3

You mean first must have following the guide FrameworkPatch and after this PlayIntegrityFix-Strong module ?

Because really i need it, i can't tell here why, but if anyone ask me i can tell via PM

P.S if send me this PlayIntegrityFix-Strong module, if you want i can sign a confidentiality agreement
[Magisk] pndwal:
Of course, but I think that device will likely pass strong with Magisk and GMS DroidGuard/attestation process hidden by Shamiko, just like other Asus devices can... 🙃 PW
[Magisk] Eclipse1991:
I dont know why but I was on 15.9.4 together with playcurl v10 and I instantly updated to 15.9.6 and then it broke somehow.I downgraded to 15.9.4 and then removed the playcurl module, deleted data of Play Store, Play services and Google Framework. After that I disabled the xiaomiinject.apk which was enabled somehow although I already disabled it in the past. Then I had Device Integrity again and could update to 15.9.6 without problems.
[Magisk] Captain_Throwback:
I have several modules installed in APatch (I listed them out in that post), and I'm passing STRONG fine. Are you referring to a specific module that would break stuff and result in only BASIC passing?
[Magisk] Captain_Throwback:
I had someone on TG test my setup on their ZF9 and they also pass Strong. So at least now I know my device isn't special; it's common to all ZenFone 9s.

I would try to check my wife's ZenFone 8 too, but I prefer to live.
[Magisk] markfm:
Question - Am I correct that the "pif-test-tbchecker.sh" tester is designed as a one-shot, to test a single properly named .json file, in the right directory location?

If I wanted to use it to test multiple I would then write a wrapper to run through a directory of json files, posting each to the right location in turn (with proper file name), testing, pull/rename the output results file, then go to the next candidate?

Thanks!