yashsingh1/xdaforums huggingface dataset:
[Magisk] TheFreeman193:
Interesting. You may have different versions of the DroidGuard VM (this is what executes the integrity checking code generated by the server when you make a Play Integrity request). There are several new DroidGuard APKs floating around as of the past few days. Would you mind running the the following in a root shell:

cd /data/data/com.google.android.gms/app_dg_cache;find -name the.apk -o -name t | xargs ls -l | sort

And posting the result for your two devices? It should show the modified time of some relevant DroidGuard files.
[Magisk] aliabda:
Oh and I checked on bluestack as well and fail again
[Magisk] GabbyWC:
Just so I'm clear, you're saying that your current custom.app_replace.list method would not be recommended in this case? The app info screen for this APK does not allow it to be disabled and X-plore File Manager does not show that any updates to it were installed.
[Magisk] esatch:
No changes for me.
[Magisk] simplepinoi177:
I think you might be mistaken....I was speaking to Play Integrity Next and the xiaomi.eu custom ROM fingerprints....

you don't "try until one works...3-4 attempt"; there's only one fingerprint at a time....that's why I'm thinking you might be mistaken thinking I was talking about PIFS and not the Play Integrity Next I was speaking to in the quote
[Magisk] osm0sis:
Current custom.app_replace.list only supports directories. The directory you were suggesting is an important ROM directory with probably lots of other overlays in it, so no, I absolutely do not recommend it in this case.

You could try Swift Backup for a UI way to disable as root, or you can try pm disable from command line.
[Magisk] d@z984:
Can anyone with microg pass the CST check?
[Magisk] aliabda:
anyone know how to pass play integrity on emulator?
[Magisk] GabbyWC:
X-plore File Manager shows just one other file (ApertureOverlay.apk) in that directory which appears to be related to the phone cameras based on what I can see in its resources.arsc file with QuickEdit. Your point still stands, though, that experimenting with the entire directory is risky and excessive. Editing the config.xml file may be an alternative method for now because it only references the co.aospa.android.certifiedprops.overlay package as shown in one of my earlier screenshots.
[Magisk] esatch:
Here you are:

pyxis:/ # cd /data/data/com.google.android.gms/app_dg_cache;find -name the.apk -o -name t | xargs ls -l | sort

-rw------- 1 u0_a421 u0_a421 0 2024-01-25 19:17 ./9BE10F83DFFDB00C88B68F60B209E79A20D1B3B5/t

-rw------- 1 u0_a421 u0_a421 0 2024-01-25 19:17 ./BB978A211C63297BDE4D1A9726C93232415A4CEF/t

-rw------- 1 u0_a421 u0_a421 0 2024-01-25 19:27 ./6D7C2BED07EDD194A1C659B6D25C19C2AC483B0A/t

-rw------- 1 u0_a421 u0_a421 410207 2024-01-25 19:17 ./9BE10F83DFFDB00C88B68F60B209E79A20D1B3B5/the.apk

-rw------- 1 u0_a421 u0_a421 410207 2024-01-25 19:17 ./BB978A211C63297BDE4D1A9726C93232415A4CEF/the.apk

-rw-r--r-- 1 u0_a421 u0_a421 426591 2024-01-25 19:16 ./6D7C2BED07EDD194A1C659B6D25C19C2AC483B0A/the.apk

sapphiren:/ # cd /data/data/com.google.android.gms/app_dg_cache;find -name the.apk -o -name t | xargs ls -l | sort

-rw------- 1 u0_a142 u0_a142 0 2024-01-25 11:44 ./37FC500541014CED511312DE94C04F404D04E00E/t

-rw------- 1 u0_a142 u0_a142 0 2024-01-25 19:29 ./6D7C2BED07EDD194A1C659B6D25C19C2AC483B0A/t

-rw------- 1 u0_a142 u0_a142 0 2024-01-25 19:29 ./9BE10F83DFFDB00C88B68F60B209E79A20D1B3B5/t

-rw------- 1 u0_a142 u0_a142 410207 2024-01-25 11:41 ./9BE10F83DFFDB00C88B68F60B209E79A20D1B3B5/the.apk

-rw------- 1 u0_a142 u0_a142 442975 2024-01-25 11:44 ./37FC500541014CED511312DE94C04F404D04E00E/the.apk

-rw-r--r-- 1 u0_a142 u0_a142 426591 2024-01-25 11:42 ./6D7C2BED07EDD194A1C659B6D25C19C2AC483B0A/the.apk
[Magisk] majorfigjam:
I'm running with a 6.0 print MRA58k build, and no problems on a Pixel 6 Pro - I don't have January Play System update yet.
[Magisk] chiteroman:
DroidGuard is able to detect if the boot.img has been modified, either by Magisk or by using a custom kernel.

It is also able to detect if you have modules mounted.

APatch is the only root method that DroidGuard cannot detect (at the moment), however, if you install some modules it will detect it.

This happens on some devices with a fingerprint whose Android version is higher than A9.

I know this thanks to my "hack" to pass Strong verdict... A lot of headaches it gave...
[Magisk] EuK_V:
The same situation with another phone samsung a70 running Los 20 with kernel from firmware - stopped passing device today: after I flashed custom kernel - passing device. PIF 14.9.

Both phones prints are not banned, after flashing custom kernels they are passing device with the same prints which were before. Went to the shop to test payments - were ok on both phones.

Flashing another kernel is the only workarond for me now.

But I hope devs will figure out how to get back to original kernel and pass device!
[Magisk] osm0sis:
This is a bit more complicated than I'd like, since only KernelSU/APatch support removing specific files. On Magisk I think we can get away with replacing the target file with an empty file or directory however. Just unclear if that'll cause any issues in itself.

Edit: Workarounds have been found, but only works on Delta/Kitsune I guess: https://huskydg.github.io/blog/delete-file-and-folder-by-magisk-module.html

I think replacing a target file with an empty directory is probably the simplest way to go, since hopefully no ROM process will mistake it for an actual working apk file that way.
[Magisk] justDave:
It was passing last night and failing this morning. I haven't updated LOS lately. I'll try rolling forward one build at a time - I don't want to go backward and have to wipe my wife's phone.

I did update PIFF from v4 to v7 but that didn't help. I reran the migrate script but it said there was nothing to do.
[Magisk] osm0sis:
Wiping Play Services data is the only other thing to try then, since you might be on a newer DroidGuard on the failing device.
[Magisk] GabbyWC:
On PixelOS, editing the associated config.xml file to change the CertifiedPropsOverlay enabled status from "true" to "false" allows custom fingerprint usage with your PI Fork module. I'm now seeing basic integrity with a custom fingerprint rather than no integrity. Deleting the custom.pif.json file still results in passing both basic and device integrity.

Update: I'm actually not seeing a difference between the true and false modes so my original comment can be disregarded. The "no integrity" status only happens to my device when Magisk is installed and PI Fork is not installed.
[Magisk] jons99:
I was passing too till this morning with the same fingerprint I found 2 months ago then this morning cts was failing I changed back to my roms default kernel and now I pass again with the same fingerprint
[Magisk] TheFreeman193:
9BE10F8 and 6D7C2BE seem to be the two most recent APKs, and are the ones I see recreated when clearing that directory at the moment. The fact those are both present on both devices suggests they're running the latest VM.

Are both devices the same architecture? What do you get on each if you run:

getprop | grep \.abi
[Magisk] esatch:
pyxis:/ # getprop | grep \.abi

[init.svc.vendor.capabilityconfigstore]: [running]

[init.svc_debug_pid.vendor.capabilityconfigstore]: [1102]

[persist.device_config.connectivity.ip_reachability_ignore_incompleted_ipv6_default_router_version]: [0]

[persist.device_config.connectivity.ip_reachability_ignore_incompleted_ipv6_dns_server_version]: [0]

[persist.device_config.connectivity.ip_reachability_mcast_resolicit_version]: [0]

[ro.boottime.vendor.capabilityconfigstore]: [9626456194]

[ro.odm.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.odm.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.odm.product.cpu.abilist64]: [arm64-v8a]

[ro.product.cpu.abi]: [arm64-v8a]

[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.product.cpu.abilist64]: [arm64-v8a]

[ro.system.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.system.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.system.product.cpu.abilist64]: [arm64-v8a]

[ro.vendor.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.vendor.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.vendor.product.cpu.abilist64]: [arm64-v8a]

sapphiren:/ # getprop | grep \.abi

[init.svc.vendor.capabilityconfigstore]: [running]

[init.svc_debug_pid.vendor.capabilityconfigstore]: [1156]

[ro.boottime.vendor.capabilityconfigstore]: [9384711297]

[ro.odm.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.odm.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.odm.product.cpu.abilist64]: [arm64-v8a]

[ro.product.cpu.abi]: [arm64-v8a]

[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.product.cpu.abilist64]: [arm64-v8a]

[ro.system.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.system.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.system.product.cpu.abilist64]: [arm64-v8a]

[ro.vendor.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]

[ro.vendor.product.cpu.abilist32]: [armeabi-v7a,armeabi]

[ro.vendor.product.cpu.abilist64]: [arm64-v8a]
[Magisk] osm0sis:
You said you're on Magisk official right?

With the overlay properly enabled again in the config.xml, try:

mkdir -p /data/adb/modules/playintegrityfix/system/system_ext/overlay/CertifiedPropsOverlay.apk

then reboot.
[Magisk] GabbyWC:
Yes, I'm using official Magisk v26.4 but my I got ahead of myself with my previous post and so I have edited that post accordingly. I'll try your suggestion now since I have already changed the enabled status in the config.xml status back to true.
[Magisk] xSnowLeopardx:
I think I have missed a lot of convos but at the same time, everything still works with my 1st found FP from 2 Dec.

Did check the 24 hour top liked posts every day... so yeah, hopefully I did not miss ultra important things
[Magisk] Brutality.:
How do I pass CTS now ? I just reflashed my rom and patched the boot.img with kitsune , and now the the safetynet doesn't work. I'm not really understanding what's going on over here at the moment , please bear with me
[Magisk] badabing2003:
are you using custom rom / kernel
[Magisk] TheFreeman193:
Those ABI values match and seem to match the expected values for the board names from the shell prompts.

Is it just a single fingerprint that exhibits this behaviour and, if not, does the device that fails work with any fingerprints? Are you getting BASIC on the failing device, or NO_INTEGRITY (empty Labels field)?
[Magisk] esatch:
Pixys (mi 9 lite) Evolution X A13

Sapphire (redmi note 13 4g) Miui stock rooted
[Magisk] GabbyWC:
Can I use the Material Terminal app for this? When I copy and paste that in there as one line, it tells me "permission denied" but when I add su in front, it shows that superuser access was granted and does not show any error. After a restart, however, I'm not seeing anything different than before.
[Magisk] esatch:
I didn't tested a lot of FPs in both devices but, on pyxis, fingerprints are generally working apart from the one I took from my physical device.

I get Basic integrity
[Magisk] osm0sis:
You need to be at a root prompt first. Type su then enter. You'll see # meaning root. Then paste my command.

Note, to do a command to su, the correct syntax is su -c which is why that failed for you.

Edit: I'm going to PM you so we can iron out the best way to disable this overlay. (y)
[Magisk] HippoMan:
I think you should prepend with "su -c", not just "su".
[Magisk] simplepinoi177:
MOD ANNOUNCEMENT

​

As per Forum Rule 3 (quoted below), Please "Post using a clear and descriptive...message." with one "...that describes your problem and a message that

explains in detail, what your problem is and what you've done to try solving it

." as "You're most likely to receive a helpful answer to your question..." doing that.

We would like to keep & maintain the thread and site (XDA Developers Forum) to a higher standard (from certain other [paper airplane] apps & sites).

Your cooperation is appreciated,

simplepinoi177

Forum Specific Moderator

XDA Developers Forum Rules said​

3. Post using a clear and descriptive subject and message.​

​

You're most likely to receive a helpful answer to your question, if you use a short subject title that describes your problem and a message that explains in detail, what your problem is and what you've done to try solving it.​
[Magisk] TheFreeman193:
Nothing drastic from what I can tell. A few profiles/fingerprints that worked at the beginning of the month aren't working again, a bit like what we observed in December.

A few people are panicking because their long-held prints stopped working but it just looks like some requirements for passing DEVICE with software/basic evaluation have gotten tighter, or else some abuse detection system has gotten more sensitive. There are tonnes of prints working including many in public collections/dumps.
[Magisk] xSnowLeopardx:
Thanks mate. Good to know. I still have loads myself so in case something does happen with my main one, I will change and let y'all know.
[Magisk] TheFreeman193:
Just to clarify, I don't expect values collected from the stock ROM for a device to work on that specific device. You're aiming for mismatched values from a different device, but that correlate among themselves (i.e. fingerprint, model, brand correlate).

Is the print that's not working on one device from the stock ROM of that device?
[Magisk] osm0sis:
Some from the same device do work, but it's always from an older Android version ROM.
[Magisk] Brutality.:
which version of PIF do I use currently to fix the issue ?
[Magisk] osm0sis:
What issue?

PIF 15.3 is unstable in general, 15.2 has intermittent fails on custom ROMs with framework-level spoof, no PIF versions work on Xiaomi.eu with their spoof injector app.

You could try PIF 15.1 (if you're not on Xiaomi.eu). Or you could try PIFork v7 which is the latest from my fork, and has none of those issues. You need a working fingerprint though.
[Magisk] Brutality.:
I currently have a failed ctc profile match
[Magisk] osm0sis:
Too vague. See my updated response to you above. You'll need to supply some more information if you want more help.
[Magisk] justDave:
That didn't change anything.

I checked the play store versions and they're the same, Version: 39.3.33-29 [O] [PR] 599690833. Interestingly, the phone that's failing still says "Device is certified" even though I'm only passing basic. No Netflix though.

I wonder if Google's started checking for some property that LOS has.

I'll start rolling through the weeklies since Jan 4 now...
[Magisk] esatch:
Nope.

Print is from a different (older) device.

Anyway, it's not a big deal for me as far as it works on the second device.

I was just a bit confused as it worked on both till yesterday.

That's it.

And, as you stated:

"Nothing drastic from what I can tell. A few profiles/fingerprints that worked at the beginning of the month aren't working again, a bit like what we observed in December."

I trust you as far more expert than me.

Thanks.
[Magisk] sawdoctor:
It doesn't seem to be prints that are banned though. The same print is passing on some devices but failing on others. The Devices it's failing on can be fixed by changing kernel. Google may have changed something but the fact changing kernel can undo it (or so it seems) will hopefully help find out what has actually happened
[Magisk] Brutality.:
Im running a samsung with a rooted custom rom with PIF 15.2 . I have always just installed PIF and it would work without issues. I do not know what fingerprints are or how to use them. I'm pretty new to all this too tbh so sorry in advance .
[Magisk] osm0sis:
PIF doesn't come with a built-in fingerprint anymore. So if you just noticed it failing today that's surprising, since the last PIF print failed like a week or so ago. Lots of guides in here to read for you to figure things out and get your own working fingerprint json file set up.
[Magisk] simplepinoi177:
This post below might help for "what fingerprints are"

How to search & find your own fingerprints [noob friendly]: A Comprehensive Guide w/ tips & Discussion for Complete Noobs (from one)

It seems Google has banned more than 95% of custom fingerprints, so this thread/guide has kind been laid to the wayside. But it's still a great resource to understanding the foundations of fingerprints and all that... This is for any/all utterly...

xdaforums.com

And the 2nd All-Time Top Liked Post (if you scroll to the top and look to the right) explains how they're used.
[Magisk] Brutality.:
Which guides in particular do I use rn ?

I'm on a Samsung m31 with Twrp 3.5.2 , Running Project Elixir v3.12 (A13).

I rooted the rom with Kitsune Mask v26.4-kitsune-2 using the boot.img patching method since direct zip installations send me into a boot loop.

After booting up, the modules I've used are Iconify, Safetynet fix mod 2.0 , then the Play Integrity fix v15.2.

Kitsune is hidden and Zygisk and MagiskHide are both turned on.

All apps that could be affected are on the denylist including Play Services and the Checker Applications

also ty for the link simple
[Magisk] simplepinoi177:
I think using the PIF Manager component in the tool Pixel Flasher is easiest/best! (workflow guide/directions below)

📳🔥 PixelFlasher, a GUI tool for flashing / updating / rooting / managing Pixel phones.

DESCRIPTION As the name suggests this is an application to flash (update) Pixel™ phones (possibly all Google™ made phones/tablets, YMMV.) PixelFlasher at its core is a UI layer (with bells and whistles) on top of adb / fastboot commands, hence...

xdaforums.com
[Magisk] Brutality.:
How did you do that ?
[Magisk] V0latyle:
broken keystore probably or compromised key...either way it'll get banned by Google
[Magisk] chiteroman:
Spoiler content hidden.
[Magisk] dcarvil:
Please remove that extremely annoying GIF. It does nothing for the purpose of this thread, and this thread is too cluttered as it is.
[Magisk] V0latyle:
It's his thread, he can post what he wants.
[Magisk] chiteroman:
Done 😝
[Magisk] Nergal di Cuthah:
Why do you have safety net and pif. They do the same thing, get rid of safetynet fix as it may be causing your issue

And i dont think play services should be denied, this iirc causes issues
[Magisk] Brutality.:
Took me till this thread to realise it 😅
[Magisk] purgy:
Welp I'm back to 1/3 on my print,

Pixel 7a, Stock September patch (A13), and sultan kernel from 20th October.

PI Fork v7, the print was passing yesterday.

Still on November play services update.

I saw some mention of newer custom kernels triggering it somehow, but that can't be the case here. Is it worth going back to stock, or is this a different issue?
[Magisk] Nergal di Cuthah:
Try another print then deal with whether you need to change kernels, is how i would do it
[Magisk] Fishawy:
Keep your print and test another kernel (stock, or I think BluSpark is for 7a? Or any other kernel for your device really).

Please let us know if this fixes it.
[Magisk] Fishawy:
Just not to point fingers, I'm not saying this is a kernel dev's fault. It's most probably something different within those kernels that Google is now starting to exploit.
[Magisk] purgy:
Tbh it seems a bit weird that they'd be looking for custom kernels to detect root, as I imagine the vast majority of rooted users would be on stock kernel.

Edit bluspark seems to be A14 only, is there a build compatible with the Sept patch of A13 that you're aware of?
[Magisk] Fishawy:
Apologies, I have a P7P not P7a. Look for other compatible kernels, or perhaps try stock.
[Magisk] Nergal di Cuthah:
I don't know if they're looking at kernels but maybe something in kernel being used to identify the mismatch being suspect. Maybe something that's been added to the kernel that hasn't made it to mainstream android kernel (though I'll admit to being over my head with kernel level stuff)
[Magisk] majorfigjam:
I'm running Kirirasura kernel on Pixel 6 pro, and not seeing any issues at all, so not all custom kernels may be being treated equally.
[Magisk] osm0sis:
How recent is the kernel build?
[Magisk] majorfigjam:
7 December 2023. Dev @Freak07 reported no changes to Google kernel in Jan 24 release, so didn't update.
[Magisk] simplepinoi177:
isn't it ironic that Google went and did something that went on a banning spree....yet the one that 1000s of users are all using at the same time (the xiaomi.eu & PINext fp) isn't banned.......🤔😤
[Magisk] sawdoctor:
Google probably aren't looking at custom kernel it's more likely an unfortunate coincidence. They've updated something at thier end and this accidentally happened. If it was deliberate i think they would have targeted thier own stock kernel.

Until we do actually figure out what has changed everything is just a guess
[Magisk] Fishawy:
P7P Kernel A (released in January) fails integrity.

P7P Kernel B (based on December releases of kernel A) passes integrity.

Needle in a haystack, but you could be right. Google - unintentionally - might have modified something that affects recent kernel releases with certain changes.
[Magisk] purgy:
I'm having a bit of a seniors moment, is it enough to flash magisk patched init_boot, or does the kernel write to boot.img as well? Foolishly, I didn't make a backup of the stock boot.img
[Magisk] Fishawy:
I'm sorry, I don't know exactly how it works on P7a, but I would guess it's similar to P7P. Please check the dedicated P7a threads before flashing anything.
[Magisk] Brutality.:
What if you have both - the sdk and first api levels ?

Do you have to add the respective data in each slot of the format or do you just pick one and put it in both ?

Also I can just insert my custom data in the example pif and rename it to custom for the forked version right ?
[Magisk] Umgak:
Use first_api_level if it's available.

Don't know what you mean by "each slot of the format". If you're using PIFork, put the value in DEVICE_INITIAL_SDK_INT like so:

"DEVICE_INITIAL_SDK_INT": "25",. If you're on chiteroman's versions, this will be titled as FIRST_API_LEVEL instead. You don't need to fill the other version's fields.

Edit: just realized you're probably referring to the "*api_level" property at the bottom. Yes, put the same number there as well.

Yes, that will work fine.
[Magisk] Javiolini:
Alright, i can confirm changing kernel works. LOS 20 on Poco X3 Pro, 2 days ago it was working fine and now no print works, switched to Rectilia kernel and its passing with the same prints.

Things are getting weirder by the day.
[Magisk] osm0sis:
I actually discovered one of my devices start failing cts/DEVICE attestation today on a previously working (since November) print, which was from a notable Google tablet.

In fact all of the 8.1.0 prints from that tablet now fail on this device, but interestingly all still work fine on my other devices.

I was able to get it working again, using the same spoofed notable Google tablet even, by going back to an 8.0.0 print from it instead.

It'll be interesting to see if my other devices "catch up" and start failing on those 8.1.0 prints as well, or if Google is doing an A-B test on our devices, where some get banned for some and not for others... 🤔
[Magisk] Nergal di Cuthah:
Maybe the kernel issue is because they're probing for kernel su (though again i know little to nothing about kernels or kernelsu I'm just brainstorming).
[Magisk] osm0sis:
For the devices where kernel seems to be the issue it's almost certainly a bad patch from January, since December kernel works and a January one doesn't for the same device. They're all on custom kernels/ROMs. I doubt Google has much to do with it.

🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com

No point in brain storming. Hopefully the kernel developers can bisect the changes to systematically narrow it down.