yashsingh1/xdaforums huggingface dataset:
[Magisk] osm0sis:
You're on a OnePlus 12 and Android 14. You're saying you installed an official OTA for your device and PIF stopped working?

I do notice from your log a number of new (many oplus-specific) props DroidGuard is looking at on your device, though who knows if it's enforcing any of those; it's certainly possible that it knows you can't be a Motorola "griffin" if some of those are present.

PIF/Native: [persist.sys.oplus.region]: CN (unchanged)
PIF/Native: [ro.build.release_type]: true (unchanged)
PIF/Native: [ro.build.type]: user (unchanged)
PIF/Native: [ro.build.version.oplus.api]: 31 (unchanged)
PIF/Native: [ro.build.version.oplus.sub_api]: 23 (unchanged)
PIF/Native: [ro.build.version.oplusrom]: V14.0.1 (unchanged)
PIF/Native: [ro.build.version.oplusrom.confidential]: V14.0.1 (unchanged)
PIF/Native: [ro.build.version.ota]: PJD110_11.A.68_0680_202404191130 (unchanged)
PIF/Native: [ro.oplus.image.my_stock.type]: domestic_OnePlus (unchanged)
PIF/Native: [ro.separate.soft]: 22825 (unchanged)
PIF/Native: [ro.vendor.oplus.market.enname]: OnePlus 12 (unchanged)
PIF/Native: [ro.vendor.oplus.market.name]: 一加 12 (unchanged)
PIF/Native: [ro.vendor.oplus.regionmark]: CN (unchanged)
PIF/Native: [ro.version.confidential]: false (unchanged)

🤔
[Magisk] pndwal:
👍

Ah... Was thinking 8.0 required... So 8.1, same as LSPosed...

Variants of LG V20 are interesting... F800L/S/K (Korean) got A9.0 while others only got 8.0... GSM Arena's a bit misleading and incomplete here...

There's an number of options for sensitive props... You can try script-only mode PIF as suggested, but I'd be interested to know if configuration I gave with old MagiskHide Props Config module instead of Shamiko would work for you. (With it loaded and nothing configured it'll adjust sensitive/suspicious props by default)... Probably less chance than Shamiko, but used to be all that was needed...

Please report if you try... 👍 PW
[Magisk] chiteroman:
ih8sn/patches/0001-keystore-Block-key-attestation-for-Google-Play-Servi.patch at master · althafvly/ih8sn

ih8sn allows you to modify system properties at runtime. - althafvly/ih8sn

github.com

😯😯😯😯😯😯
[Magisk] Vision:
This is from last year, how did we not see it early?

This means, can block for GMS and pass 2/3 permanently or?
[Magisk] osm0sis:
It's just the original USNF fallback code... Isn't it?
[Magisk] Vision:
Yeah, I have read it before long ago.

For that ask if have some new.
[Magisk] pndwal:
ih8sn itself looks interesting... "allows you to modify system properties at runtime"...

The language in that commit is from @kdrag0ns older USNF builds/documentation, and before the Google mechanism was understood as well as we do now... (And prior to server side hardware backed evaluationType enforcement was implemented also)...

The fallback (to basic attestation) trigger used to be the "not implemented" error code, but he (Danny) changed to using fake keystore registration --> exception as the error code was though to be a bit obvious if Google checked...

Yup, yup... 👀 PW
[Magisk] Vision:
Yeah, the old good days.
[Magisk] osm0sis:
Yep, the original is still present in USNF's commit history, but obviously it moved away from that when switching from keystore library/binary replacement to use Riru/Zygisk.

safetynet-fix/patches at 502d10f8fe5905978afd4ddcbd714824b4e850f6 · Displax/safetynet-fix

SafetyNet & Play Integrity API workarounds for Magisk - Displax/safetynet-fix

github.com

Funny, I didn't realize that Lineage's ih8sn is based on the earliest USNF versions. @kdrag0n is responsible for basically all methods of SN/PI bypassing? 🤯
[Magisk] zgfg:
Yeah, but my point was about users with A8.1-A9 that (as currently being discussed and tested) may still need Scripts-Only Mode

However, they already have latest Magisk with Zygisk enabled, Shamiko,, maybe LSPosed-Zygisk.

Hence PIF loading its native code but not spoofing for DG should not make a harm

If they submit 'empty' JSON, your native code won't spoof any field - doesn't that already behave like in Scripts-Only Mode (by applying only the global spoofs from service.sh and post-fs-data.sh)?

If so, then those users could simply test the 'empty' JSON (brackets but no fields, optionally only the verbose logging control) to test if global spoofs only help them to pass PI

They would just use killall to re-read that 'empty' JSON, no need for re-installing the module with the Scripts-Only-Mode touch and rebooting

---

Unlike in the proper Scripts-Only-Mode, here your native part still parses the 'empty' JSON (no harm), spoofs MTP mode (should not cause a harm), prints logcat (no harm) and it would still call CustomKeyStoreSpi overrides -for that I was not sure, could that spoil the PI?

If so, then there was a proposal for an additional feature / that PIF might disable itself by use of a new, advanced field- but ok, you dismissed that feature request
[Magisk] osm0sis:
Yes, I don't think it's a good idea to implement basically the same thing twice unnecessarily, or overcomplicate what's already there by doing so.

My mtp/adbd spoofs are just there as a precaution, DroidGuard doesn't actually enforce them. Users in Scripts-Only Mode can just actually disable USB Debugging if they care to.

If you want to go the "kitchen sink" route, there's always @arda99's very cool YAPIF to play with: https://github.com/lucidusdev/YAPIF 😘
[Magisk] flobo09:
5 days on, still not passing device, google pay still works flawlessly every single day.

Not complaining but i'm totally confused about what is going on with my phone.
[Magisk] MrSteelX:
Have you tried uninstalling pif and reinstall pif to see if it helps?
[Magisk] pndwal:
Mmm... Searched this cos seemed strange Lineage would make a utility to do that available (knowing their anti-spoofing policy)...

I found that @althafvly does have extensive dev skills, eg did AOSP Developer Internship in 2021, now maintains at least a couple of ROMs officially for LineageOS (Motorola, Xiaomi/Poco?), has ported/developed countless others at XDA and has other projects such as Amlogic Kitchen here as well...

By 'Lineage's ih8sn', is that the method used by some unofficial LOS ROMs (eg @althafvly's)?... Doubt it'll be found in official LOS... (See ih8sn has 100+ forks, but none I saw seemed interesting.) 👀 PW
[Magisk] chiteroman:
*Native Detector joined the game*
[Magisk] majorfigjam:
Moving on from older Android versions to the very latest ...

The latest Google update (ap1a.240505.004) does not affect play integrity spoofing - at least on my Pixel 6 Pro with non-Griffin print, Kiri kernel and shamiko.
[Magisk] osm0sis:
It's developed by several of the major Lineage developers/maintainers, but of course never promoted or mentioned officially anywhere Lineage. That's very intentional.

Contributors to luk1337/ih8sn

Contribute to luk1337/ih8sn development by creating an account on GitHub.

github.com

Also, ah, I see from the histories that ih8sn is originally its own completely separate thing, and althafvly only added the old USNF stuff to his own fork last year: https://github.com/althafvly/ih8sn/commits/master/patches
[Magisk] Nergal di Cuthah:
Will try my griffin print no shamiko no custom kernel P6P later tonight or tomorrow thanks for Guinea pigging may firmware and root.
[Magisk] pndwal:
"Sad Minotaur" -25- 'Native Test'?...

Please say which new checks. Ta... 👍 PW
[Magisk] shuoyue:
I found the issue lies with the conflict between the "fcmfix" module in the LSPosed and PIF. If I uncheck GMS in LSPosed , PIF works fine.

GitHub - kooritea/fcmfix: [xposed]让fcm唤醒已完全停止的应用

[xposed]让fcm唤醒已完全停止的应用. Contribute to kooritea/fcmfix development by creating an account on GitHub.

github.com
[Magisk] zgfg:
As a rule of thumb, do not enable LSPosed modules for GMS - that usually triggers the troubles.

Btw, I don't use that module but per my understanding, it has to be enabled for the third party apps that have to be woken up to receive notifications (like WA or so), not to the Google Play Services (GSM should always receive but it has to dispatch to the potentially sleeping app)

Also, I have Xiaomi.eu but MIUI 14 and I have no troubles with notifications - are you maybe on HyperOS and you don't properly receive push notifications for some apps?
[Magisk] CZ.Kostra:
FP XEU Checker v1.7 - edited link to 'autopif.sh'.
[Magisk] zgfg:
Btw, this is an interesting and highly configurable Yet Another PIF, but on EOL.

Eg, its update.json:

https://github.com/lucidusdev/YAPIF/raw/release/update.json

points to the v2.0 changegog:

https://raw.githubusercontent.com/lucidusdev/YAPIF/release/changelog.md

but the corresponding zipUrl points to the not-found Releases/download:

https://github.com/lucidusdev/YAPIF/releases/download/v2.0/YAPIF_release.zip

Latest commits are 4 mos old and indeed seems that Releases (v2.0 = Initial release) have been removed from GitHub
[Magisk] osm0sis:
An initial release was never posted actually. Not sure why. It's easily buildable however.

If you ever get your GitHub login figured out again we've got it forked with CI enabled in the private org you're part of.
[Magisk] zgfg:
I've downloaded the attachment apk and installed, gave permissions (little bit tricky on MIUI) and eventually ran and tested. It successfully downloaded the latest XiaomiEUModule_2024.02.29.apk, extracted the Griffin prints, migrated and installed to my PI Fork module (later I replaced back my 'private' custom prints). It also checked Wallet database, all looks ok

Just few questions:

- Is it possible (without the Tasker) to configure your app to periodically check XEU Module (I know, two+ months have passed and Google did not attack the Griffin, but who knows; besides I have 'private' custom prints), I'm just curious...

- Btw, runlog.txt still points to XDA for autopif.sh (I guess it is just echoing or so):

Checker.Link to 'autopif.sh' Address of the post with the script: 'https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89233630']https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89233630

but tasker.txt correctly points to the latest version on GitHub:

Variables: 10.18.04#b#Variables: doreplresult: |%apifurl| -> |https://raw.githubusercontent.com/osm0sis/PlayIntegrityFork/main/module/autopif.sh|

and I checked in /storage/FP_XEU_Checker and it's indeed the latest Osm0sis autopif.sh

- autopif.sh calls at the end the existing:

/data/adb/modules/playintegrityfix/migrate.sh

although Osm0sis has also a newer version of the migration script:

https://raw.githubusercontent.com/osm0sis/PlayIntegrityFork/main/module/migrate.sh

It works one way or the other but Checker app could maybe also download and use the latest migrate.sh (sorry for bothering...)

At the end, GPay Checker checks the GMS/Wallet database:

/data/data/com.google.android.gms/databases/android_pay

are there active cards (PaymentBundles, bundle_state) and if the latest attestation failed (Wallets, fails_attestation)

You do killall com.google.android.gms.unstable but I don't really see a new attestation with the freshly installed XEU prints, hence (if I'm not wrong) it could still happen that:

- new, working XEU prints were successfully installed by FP_XEU_Checker

- but fails_attestation in Wallet db continues to show 1 due to the previous failed attestation in Wallet (?)

I had a similar case:

- I was testing prints and Wallet caught me when I didn't have valid prints

- I put back the working prints and tested(several times) by PIC, SPIC, TB Checker, even Playstore/Dev options

- but Wallet was then showing me for almost two weeks

"Your device does not meet security..."

Eventually I fixed the Wallet by wiping its Cache

Maybe, you could consider adding (if fails_attestation was 1):

- to wipe Wallet Cache

- and to force close (just in case) and open Wallet activity to force Wallet to retest and to show to the user that Wallet is now ok and ready for paying
[Magisk] CZ.Kostra:
In current version, it is not possible to configure application in any way or to start it automatically. But I want to extend it with an external configuration file so it can be used similarly to a task in Tasker. (It's a challenge for me. :))

XDA link is only in variable comment to find informations about 'autopif.sh'.

In 'autopif.sh' 'migrate.sh' is cleverly called from installed module. I think this is the best solution for compatibility reasons. If the user updates PIFork module, the new version of 'migrate.sh' will also be used. I don't want to interfere with thes things.

You're right. GWallet testing is not ideal. I'm still trying to figure out how and why it works/doesn't work. I greatly appreciate your suggestions and will try to implement them.

Thank you.
[Magisk] zgfg:
Thanks

Btw, killing Wallet shall be (from the shell, with root):

am force-stop com.google.android.apps.walletnfcrel

Deleting Wallet Cache.(but please test/compare what exactly Settings/Apps, Wallet, Wipe Cache deletes):

rm -rf /data/data/com.google.android.apps.walletnfcrel/cache/*

And re-opening the Wallet: (tested, it works)

am start -n com.google.android.apps.walletnfcrel/com.google.android.apps.wallet.main.WalletActivity

Btw, I was also thinking about possible compatibility issues if enforcing the latest migrate.sh vs using the existing one installed by the user's PIFork version... agree that it could cause trouble.

But if migrate.sh is missing in the PI Fork folder, you could download and execute from your folder FP_XEU_Checker
[Magisk] CZ.Kostra:
Perfect. This me very help. Thanks you.
[Magisk] craigacgomez:
@chiteroman, just curious, but what was the reason for selecting Asus ZenPhone Max as the attestation device?
[Magisk] xp0sed_relay:
Only google play store and bank apps has to be in denylist?
[Magisk] chiteroman:
It's the first version I tried, literally I did the module in 1 attempt, it took me 5 minutes to fix everything XD.
[Magisk] mac796:
Thanks for all your hard work. I donated. 👍👍
[Magisk] chiteroman:
Don't add to denylist any Google app. Only main and unstable GMS process check for root. When you have my module installed, it will unmount root for them, just don't touch Google apps.

Also, if you add it to denylist, next time you reboot the device, the module will auto remove it.

Bank apps should be added in deny list if they check for root.
[Magisk] xp0sed_relay:
Thank you so much :D
[Magisk] Stillhard:
@chiteroman

at first i was a bit worried when i saw you've added back service.sh file to v12...

but waddayaknow... still works with it included, i saw the changes, it's brilliant (y)

thank you
[Magisk] jesvi:
Works like charm 👌
[Magisk] phone_etix:
Many thanks @chiteroman for saving us all, was caught out at the register today and very much going through the "ah **** here we go again" mood haha. Wallet and banking apps working again, device integrity is pass again in TB checker. Didn't need to clear data from apps.

Although, fwiw, I've left my previous denylist settings on - including wallet - and it works anyway. Fingers crossed this latest fix holds for a while
[Magisk] pndwal:
It's very old (Lollipop) so fingerprint will definitely provide the mismatch required for bypassing server end hardware-backed verdict enforcement on some devices while still passing ctsProfileMatch without needing to align with security patch prop (ro.build.version.security_patch) date value to match the fingerprint prop value used (which requirement was introduced in March 2018)...

Looks like Google found a way to prevent DEVICE_INTEGRITY from passing using angler (Huawei made Google Nexus 6P), Marlin (Google Pixel XL), walleye (Google Pixel 2) and other(?) fingerprint props on other/mismatched devices... (Guess that could be as simple as check shipping level or other props)... 👀 PW
[Magisk] pndwal:
OP says:

Just saw it... Hope it helps. PW
[Magisk] phone_etix:
At this rate... Any bets for how long it'll take for them to finally announce that say pre-2018 devices will no longer be supported?

I have a feeling by this time next year people like me on older phones will be forced to upgrade. Unless some kind and generous soul wouldn't mind compiling the relevant kernel to use kernelsu on oneplus 5 (cheeseburger)...
[Magisk] mkcs:
Something weird regarding to my Mi Pad 5 Pro 5G. Anyone knows why running play integrity check gives the following message?

View attachment 6030621
[Magisk] BenParz:
Excuse me @chiteroman but what do you mean by "unstable processes?"
[Magisk] thesingular:
Or just manually set the date to a week or so in the future, force stop(or just reboot if you wish) the complaining Google app(s) (and maybe also the Google Play Services) and try again. (If it fails, set the date a bit further into the future.)

Google apps tend to check for Play Integrity in certain periods, like a day for the Wallet or a few days for the Play Store. This will trick those apps into thinking they need to check for Play Integrity again.

Just remember to change the date back after it's fixed.

For everyone else:

Whichever method you try(clearing data or setting the date) take the phone into

airplane mode

before you try it to ensure that it works flawlessly. Keep it off until you've rebooted or force stopped the apps, turn it back on only after that.
[Magisk] Nergal di Cuthah:
Lol

View attachment 6030634
[Magisk] thesingular:
Use Play Store's own attestation. Assuming you have the latest Play Store installed on your phone.

Here's how:

1. Open Google Play Store.

2. Click on your Google account picture(or initials if you don't have a picture) to open the menu and click on Settings there.

3. Expand the About section. Skip to step 5 instead if you have already enabled the developer features.

4. Click on Play Store version a few times (but avoid the "Update Play Store" button just below) until a prompt appears asking if you want to enable developer features(don't remember the exact words), then select yes.

5. Expand the General section now without leaving the screen, it's at the top.

6. At the bottom of that section, there will be Developer options now, open that.

7. You'll see "Play Integrity" option and a "Check integrity" button there. Click on that.

8. Google Play will check for Play Integrity in a pop-up.

It's not as pretty as the Play Integrity API Checker app but it'll get the job done. Here's a screenshot from it:

View attachment 6030647
[Magisk] Nergal di Cuthah:
I know just thought it was funny, i didn't need to check. Joke is that EVERYBODY is using the app today -- frequently if they're anything like me, being paranoid that google will change something again.
[Magisk] thesingular:
Me too 😂
[Magisk] pndwal:
For DEVICE_INTEGRITY?... Doubtful since it's just the new ctsProfileMatch for both Keymaster 3 compliant and non compliant devices...

I does occur to me that they may still double down further on server end enforcement of hardware-backed verdicts for devices that have no business using basic-only attestation for Droidguard however... Current fingerprint and other props may not last long, but as long as the basic USNF function (of which PIF is a fork), ie. the fake keystore registration (or other means that have been tried) trigger for the exception that causes on-device fallback to basic-only Droidguard attestation, still works it should be possible to keep coming up with userspace spoofs (for devices or properties Google exempts from using hardware-backed evaluationType attestation) to effectively bypass such enforcement...

Really Google has done us (modders) a favour with device integrity API design, and nothing really changed with PI... If interested parties start moving to independently verified "Key and ID Attestation" for which Google has also supplied a model for some time, all bets will be off... But stupid is as stupid does...

Thanks Google for the bypassable PI DEVICE_INTEGRITY API distraction!... 🙄 😋

Who knows? We're on borrowed time as it is! 😜 PW
[Magisk] bou1l3m:
where can we find unbanned keyboxe ?
[Magisk] BunnyPig1:
By exploring the internet.
[Magisk] bou1l3m:
what is the point of your answer?
[Magisk] Vision:
Please, Do Not Fight 🚫 🤕
[Magisk] Nergal di Cuthah:
That this isn't the thread to ask that in

Try

TEE hacking

Post about hacking TEE on Android devices. I will post here some useful resources: https://github.com/chiteroman/Reprogram-TEE-on-Qualcomm-devices https://github.com/chiteroman/FrameworkPatch And leaked keyboxes...

xdaforums.com
[Magisk] osm0sis:
And that keyboxes are leaked from OEMs so technically not a legal thing for you to have and thus finding them shouldn't be discussed on XDA at all.
[Magisk] bou1l3m:
you can answer me privately
[Magisk] osm0sis:
Sure, but not much else to tell you. Explore the Internet as you were accurately told. 🤷‍♂️
[Magisk] xSnowLeopardx:
From checking this forum every 3-5 hours per day, to checking in once in a while. Glad things are still working (:
[Magisk] trevtdogg:
because that is the correct answer to your question?

sounds like you were really asking "can someone spoon feed me" which for this, is probably not going to happen.
[Magisk] chiteroman:
37°25′19.4″ N, 122°5′4″ W
[Magisk] Nergal di Cuthah:
Deaddrop just outside HQ lol, on the downlow.
[Magisk] bou1l3m:
It's good I found it, thank you lol
[Magisk] Nergal di Cuthah:
Umm add explanation to contextualize this I'm not downloading some unknown xml
[Magisk] bou1l3m:
I found a hundred if interested
[Magisk] bou1l3m:
to avoid the ban I deleted
[Magisk] Nergal di Cuthah:
Are you posting keyboxes after being told that a) wrong thread and b) possibly against xda rules?
[Magisk] chiteroman:
c) https://android.googleapis.com/attestation/status
[Magisk] Couchy:
Google Wallet dropping support for old Android & Wear OS versions

Starting next month, Google is increasing the minimum OS version for Wallet on Android phones and Wear OS with security cited as the reason.

9to5google.com

This is probably the end for Google Wallet - now requires Android 9 and likely mandatory hardware attestation.
[Magisk] osm0sis:
Well, so much for scripts-only-mode for the oldest stock ROMs (Android 7-8) I guess.. but still could be useful for some on Android 9 at least. 🤷‍♂️
[Magisk] zgfg:
Probably a month or two later

That can explain why G lost interest in chasing/banning prints after the end of February
[Magisk] osm0sis:
Also why some report the griffin print stopped working on older ROMs again too; they've been A-B testing the upcoming change perhaps.
[Magisk] sawdoctor:
Maybe they've just trimmed the fat and there's so few of us rooted now were not making as much noise so they'll leave us alone? 🤞 🤞 🤞
[Magisk] chiteroman:
It doesn't say anything about Google forcing Strong verdict, so don't start getting uptight.... Just chill.
[Magisk] chiteroman:
It would not be unreasonable to think that all this has been a deterrent move by Google, that is, if they really wanted to screw us, they would have done it a long time ago, for example, by preventing bootloaders from being unlocked.

Maybe what they want, is that people who have root are people who know what they are doing, it's not the first time I see kids on a Telegram channel for my vayu (Poco X3 Pro) flashing modules that promise to give +200 fps in Free Fire and surprise! There's a loop that flashes /dev/zero in all /dev/block partitions... (You are left with a nice paperweight).

Honestly, if Google continues on this path and doesn't touch more things, I don't think it's bad what they are doing.
[Magisk] Androiduser2390:
They are trying to kill bootloader unlock on production devices by not stopping it, but making people who want to extend the life of their phone buy a new phone by forcing hardware attestation (Maybe someday with Quantum Computers gaining the power to break encryption, the signing keys of the OEM rom could be cracked so custom ROMs could be flashed without unlock.
[Magisk] chiteroman:
That will not be possible for many years, and even if it were, neither you nor I would have access to it.

Moreover, in the hypothetical case that we have access to a quantum computer with an implementation of functional Shor's algorithm and can obtain the private keys from the public keys, all the certificate serials would end up here