yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
Interesting that last @kdragOn build can target DroidGuard process in microG services!.. I thought only the special @Displax build would do that... But don't expect any of those to pass PI DEVICE_INTEGRITY... The prints used are banned for spoofing that (some still pass ctsProfileMatch , some don't) and PIF is now needed for it's use of un-banned prints...

The @Displax 2.4.0 build was built to take advantage of Google's (deceitful?) fake STRONG_INTEGRITY pass for pixel 2 walleye (so we all had STRONG pass for a while; nb. there were PIF builds doing that too), and even after Google patched that 'vulnerability' (being polite here) once it became common knowledge, the 2.4.0-mod_2.0 build continued to work for DEVICE_INTEGRITY for some but even that was broken for devices launched with Android 13+ so those users generally fell back to @Displax 2.4.0-mod_1.3... Later, the specific walleye print used (and others ?) was also 'banned' for spoofing PI verdicts altogether (although some walleye print/prop sets were apparently spared), but most users were moving to @chiteroman's original USNF fork renamed PIF by then which was updated with non-'banned' print/prop/field sets.

Anyway, my assumption about changes needed for microG compatibility here:

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89532023

may not be correct since you clearly have a standard USNF build targeting spoofs to and hiding root from the DroidGuard process (com.google.android.gms.unstable) despite the process being in a differently named system app... But I see that package name is still com.google.android.gms so that would explain why USNF can see it...

This makes me think that PIF (with a currently working print/prop/field set) should basically just work also for PI DEVICE_INTEGRITY... In fact it probably does except that Google have made recent changes to the APIs requiring up-to-date Play Store in addition to Play Services (which may be why the microG team made changes too).

Both SN and PI now require Play Store (com.android.vending), but it makes sense that S/N only looks for it's existence (eg the 'microG Companion'/'FakeStore' placeholder suffices) as it's only a device integrity attestation API... PI expanded the concept, becoming a multi integrity attestation API including verdicts for device, applications, play account, and environment (App access risk, Play Protect), and actually makes calls to Play Store so a working implementation becomes essential. Eg the new Environment details field will now return empty responses when "The version of the Google Play Store on the device is outdated":

https://developer.android.com/google/play/integrity/setup#optional_environment_details

... That's because it's appAccessRiskVerdict appsDetected field requires a recent Play Store build for these interactions... And empty responses will result in unevaluated device integrity responses also...

So I guess you/microG may simply need a more complete com.android.vending package (and possibly more complete com.google.android.gms package?) to have working PIF...

Hope this is edifying... 🤠 PW
[Magisk] Dkpost3:
on Evo X (source code)

croot && git clone https://github.com/Evolution-XYZ/vendor_evolution-priv_keys-template vendor/evolution-priv/keys
cd vendor/evolution-priv/keys
./generate.sh

on Lineage (in generate.sh verify the path )

croot && git clone https://github.com/Evolution-XYZ/vendor_evolution-priv_keys-template vendor/lineage-priv/keys
cd vendor/lineage-priv/keys
./generate.sh

if there is a repeat, delete it
[Magisk] pndwal:
Same way as for standard Play services: Google updates DroidGuard VM iterations as needed and unique bitecode is loaded from servers with every attestation call...

They don't need to update DG if it already is capable of including those strings in attestation data sent to Google... The banning decision is made entirely server side.

Well it's true that a working Play Store is now required for PI verdict evaluations to succeed; a fake Play Store ('placeholder') won't cut the mustard... SN verdicts are different and apparently that API only checks for Play Store package existence... A 'Fake Store' can therefore work.

Please see my post above for details.

Pinging you too because it seems Play Store is now actually required and utilised (PI API has evolved recently) for new PI environment checks, and if these fail other PI verdicts are not evaluated... See post above. 👍 PW
[Magisk] joeyhuab:
Just a heads up to everyone planning to build Evo X, @AnierinB has posted a template to generating private keys.

GitHub - Evolution-XYZ/vendor_evolution-priv_keys-template: Generate keys used for inline build signing (Unofficial builders only)

Generate keys used for inline build signing (Unofficial builders only) - Evolution-XYZ/vendor_evolution-priv_keys-template

github.com

Hopefully it helps other unofficial builders here.

Also, just want to report. I've built both Evo 9.0 for POCO F5 and Redmi K20 Pro and they pass play integrity with our current inbuilt PIF setup.
[Magisk] Dkpost3:
Hello. Tell me what I'm doing wrong: the assembly undergoes verification during installation - either endless loading or cyclic reloading.

assemblies that failed verification (faled signature) load perfectly and even Google shows that it has been verified, but it doesn’t work normally.

example of a build where There are definitely problems with the keys, but Google says everything is fine, dude, don’t piss, I’ve done this a hundred times

https://disk.yandex.ru/d/jKKzGg99fwniNw

What am I doing:

-- In the tree: external/avb/test/data/test key_sa 2048.pem + SHA256_RSA2048

-- avbkey: (SRC_TARGET_DIR)/product/developer_gsi_keys.mk)

-- pif: tried to add and remove, to no avail

-- key generation - from manually using the LoS manual, to your script

PS: adding screenshot final build.

PPS: pixel integrity good, but key verification failed. Help pls.

View attachment 6107966View attachment 6108005View attachment 6108011View attachment 6108004View attachment 6108012
[Magisk] osm0sis:
Interesting!

Seems the PIF print still doesn't need to be spoofed for the Play Store like ROMs have been doing however. 🧐
[Magisk] BunnyPig1:
One question regarding PI and apps, I've tried searching all 800 pages and taken a look at the FAQ but couldn't find anything. This has probably been asked before but can't find anything related to it.

Since a lot of users are rooted, be it system-less or not, what is preventing us to just stop the communication between DG and apps, hooking in and telling apps that PI is reporting DEVICE or even possibly STRONG?

I know that PI is not being handled on our devices but apps has to be receiving the information from somewhere. Why isn't it possible to find a way to tell apps a false verdict?

This is probably a huge question so disregard if it's too hard or time consuming to answer.
[Magisk] pndwal:
Correct. GMS is still handling the attestations.

However, as we already knew, the deviceIntegrity field verdict can be affected by other integrity fields. Eg. If appIntegrity is unevaluated the device is deemed 'not trustworthy enough' for a device integrity evaluation... Further, it appears that while the basic appIntegrity field doesn't use Play Store data as part of it's appRecognitionVerdict process (this simply checks a specific app per requestDetails which contains the application package name that the attestation was requested for and seems it just checks that an app and certificate match the versions distributed by Google Play using server based data), the new environmentDetails field does... It's appAccessRiskVerdict (still in beta) appsDetected response leverages Store data to identify apps installed by Google Play. (This is a check of all apps that can be discovered to determine risks in apps having unknown source , capturing ability ie. permissions allowing screen viewing, controlling ability ie. permissions allowing control of the device, direct control of inputs into app or capturing of app inputs and outputs, or overlays ie. permissions allowing the display of overlays on apps.)

This means that if a working and up to date Play Store (com.android.vending) app is missing the response for this is blank (not evaluated) and the failure to meet necessary requirements renders the device 'not trustworthy enough' to evaluate other verdict fields including deviceIntegrity.

So this won't affect users with normal GMS suite (GApps) implementations at all for PIF purposes, but for microG users, while a fake (placeholder) Play Store implementation like FakeStore or microG Companion may fool the S/N API, PI verdicts will fail; A Play Store (com.android.vending) implementation capable of supplying the required appsDetected data for appAccessRiskVerdict will be needed at the very least.

🤠 PW
[Magisk] osm0sis:
Not banned, by the way! So your ROM's testkey signature is likely the only issue in your setup. (y)
[Magisk] pndwal:
BTW, which ROMs do that? 😅 PW
[Magisk] Zaxx32:
Sorry to distract. I recently lost RCS in messenger even tho it says 'connected' in settings...am running the latest play integrity fix, no luck tho. I am only on the March update of stock A14...could that be the cause (besides google being a PITA as usual)?
[Magisk] robbins:
I'm on my own (signed) build of AOSPA 14 on the OnePlus 7 Pro, with v15.9.9 of this module installed, but I'm still failing MEETS_DEVICE_INTEGRITY.

OnePlus7Pro:/ $ unzip -l /system/etc/security/otacerts.zip
Archive: /system/etc/security/otacerts.zip
Length Date Time Name
--------- ---------- ----- ----
1484 2009-01-01 00:00 ../.android-certs/releasekey.x509.pem
--------- -------
1484 1 file

and

OnePlus7Pro:/ $ uname -r
4.14.206-DragonHeart

I've cleared data of Play Store & Services, and have latest Magisk installed (stable 27.0) with Zygisk. Play Store shows my device as uncertified. I have "enforce denylist" disabled. I have no other modules installed except systemless hosts. It's a user build as well.

Not sure if this kernel string might also happen be banned, or if I missed something?
[Magisk] Nergal di Cuthah:
Do you have an orphaned pif.json that might be overriding the built in print (for instance if you use curl or next or maybe just had one laying there)
[Magisk] robbins:
No, clean-flashed my build today. Chiteroman's module was the only one I installed.
[Magisk] twu2:
check META/misc_info.txt in the zip file, if it not include avb_avbtool,

just extract it, add "avb_avbtool=avbtool" to the file, and repack it to the zip file.

then you can execute sign_target_files_apks and ota_from_target_files without issue. (make sure /tmp is big enough or set TMP to out/soong/.temp

or patch build/make/tools/releasetools/sign_target_files_apks.py to add default value for this:

diff -Nur build/make/tools/releasetools/sign_target_files_apks.orig.py build/make/tools/releasetools/sign_target_files_apks.py
--- build/make/tools/releasetools/sign_target_files_apks.orig.py 2024-05-30 12:30:17.806351781 +0800
+++ build/make/tools/releasetools/sign_target_files_apks.py 2024-05-30 12:27:25.678477154 +0800
@@ -1579,6 +1579,9 @@
"default_system_dev_certificate",
"build/make/target/product/security/testkey")

+ if "avb_avbtool" not in misc_info:
+ misc_info["avb_avbtool"] = "avbtool"
+
BuildKeyMap(misc_info, key_mapping_options)

apk_keys_info, compressed_extension = common.ReadApkCerts(input_zip)
[Magisk] Iridule:
Been off here for a hundred or so pages. I've kept up to date on the print and all is working. Was wondering would anything need to be done for Lineage OS to work for moto edge if I update? I had read about people having to sign on their own for some reason with custom roms? I was planning on

lineage-20.0-20240523-nightly-racer-signed.zip...would this work or would I need to sign myself?
[Magisk] Bonoboo:
If it's official LOS - it will pass check. Because official for sure use own, non-test keys.
[Magisk] zgfg:
Things like that have been snswered many times, with the official and unofficial documents and flowcharts with the communication from the requuestor app to gms.unstable, then to G server, then back, then from DroidGuard (the.apk) to server and then full back to the requestor app

For example, last week somebody asked why not to proxy (Strong) Verdict from another device, and I remember, I have answered about the protections by use of PKI

Everything is signed back and forth. That's why you cannot spoof a Verdict that was not obtained from G server, or the one from G server but that does not correspond to the requested attestation (from another device, old one or whatever)

Additionally, Strong Integrity (and that has really been mentioned tons of times) includes collecting data on the Trusted Execution Environment (hardware, google about) and being signed by the private vendor's key

Use TBChecker or SPIC snd open the Raw JSON response. You will see that the final verdict from G server repeats:

- timestamp of the original request (UTC, in milliseconds)

- package name of the original requestor app

- version of the requestor app

- nonce provided by the requestor app

ALL THAT together with the Verdict (what you MEET) is signed by the Google's private key

Hence the requestor app verifies (by using public G key) if that was really the Verdict for its own request. And you cannot spoof the Verdict itself bcs again, the signature would also no more correspond. And you cannot re-sign, since you don't have the private G keys

{
"accountDetails": {
"appLicensingVerdict": "LICENSED"
},
"appIntegrity": {
"appRecognitionVerdict": "PLAY_RECOGNIZED",
"certificateSha256Digest": [
"<Removed>"
],
"packageName": "com.henrikherzig.playintegritychecker",
"versionCode": "7"
},
"deviceIntegrity": {
"deviceRecognitionVerdict": [
"MEETS_BASIC_INTEGRITY",
"MEETS_DEVICE_INTEGRITY"
]
},
"requestDetails": {
"nonce": "<Removed>",
"requestPackageName": "com.henrikherzig.playintegritychecker",
"timestampMillis": <Removed>
}
}

Sensitive parts <Removed>
[Magisk] MonstaBug:
good explanation, thx! :)

here are some ideas about what could potentially be done

while we cannot fake a google-signed response, it might be possible to swap the public key for our own, and then sign a fake response. i dont know how google's public key is usually retrieved by apps, but if its done via a certain URL, file path, or API call, we might be able to hook into that and provide a different key.

if we are only talking about google pay, it might be worthwile to try and hack it so that the verdict interpretation always returns STRONG, no matter what the signed verdict actually says. since this check happens on our rooted devices, it should be possible to modify it. however i am not familiar with the usual techniques to achieve this on android, so no idea how feasible it actually is
[Magisk] BunnyPig1:
Very interesting, thanks for taking your time answering my question, very well explained.

I'm sure the great minds out there someday will be able to find some sort of workaround but for now it truly seems like the end of the line.

Thank you again for the great explanation.
[Magisk] zgfg:
If not familiar with Asymmetric PKI and Digital Signatures, please google about (then review your question😁)

What is a digital signature PKI? A detailed guide - Oneflow

Digital signature PKIs are the backbone of digital signatures. That's why we take a deep dive into them here.

oneflow.com

What is PKI (Public Key Infrastructure)? How does it work? | Encryption Consulting

Public Key Infrastructure is a solution created to protect your infrastructure, where signed certificates and hashes are used for identification and authentication

www.encryptionconsulting.com
[Magisk] osm0sis:
Any of the ones using PixelPropsUtils:

frameworks_base/core/java/com/android/internal/util/evolution/PixelPropsUtils.java at udc · Evolution-XYZ/frameworks_base

Contribute to Evolution-XYZ/frameworks_base development by creating an account on GitHub.

github.com
[Magisk] beardedwonder:
I tried to mine my own print (before the print armageddon I had about 15 working prints) , got ~115 build.prop files and not a single working print :(

Is anyone still able to mine their own?
[Magisk] zgfg:
Yes, but they are extremly rare.Do ten times more and maybe you find one
[Magisk] osm0sis:
We found 3 new ones recently, in addition to the 74 from several sources we still could confirm working after the last wave of bans, so there are 77 known working prints right now.

There are almost none left in tadi if people are still trying to use that as a source. Only 4 are left from our dump of all tadi's prop files from December. I suppose new working ones could have been added to tadi since then but I wouldn't bet on it.
[Magisk] manjaroid:
I haven't looked lately and time is running out. Still have one good print out of 13 that passed a few months ago. Consistent with...

...my last good props didn't come from a dump site. Between it and the latest public print I'm betting on which gets banned first with a two-headed coin.
[Magisk] Dkpost3:
Hi all. I have test server - 60 cores (2* intel gold 6338) and 200gb RAM + 2tb u3 raid0. vmware 8.02, 200mb/s - out ethernet . If this helps to solve this and similar problems, write and I’ll share.
[Magisk] Nergal di Cuthah:
I'm not sure what this means, how would a powerful server help?
[Magisk] Dkpost3:
compile test build + 20 tb share for working with the image directly from the storage system (adb, fastboot and others) (build a14 ~30-40min)
[Magisk] JoeRifle:
Hey guys. I have a Atom L + Kitsune (SUEnforce) + PIF (latest) running on Android 11. This used to work on/off for a day or two and then again back to either crashing the test app or throwing an error: "not allowed to bind to android.vending.com".

Resetting whatever data/cache does not seem to help.

Are the days of PIF coming to an end, or am I incapable of sth ;)
[Magisk] osm0sis:
DragonHeart isn't banned, so I can tell you it's not that, at least. 👍
[Magisk] Dkpost3:
🔧 [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
[Magisk] robbins:
Thanks, that's unfortunate as it would've been a simple fix :(. Might try your module with the same pif.json - I doubt the verbose option lends any information towards why its failing since it's all done on Google's servers?
[Magisk] osm0sis:
@Dkpost3, his description is not how the kernel string ban presents.. a kernel ban shows as DEVICE or ctsProfile failing.

Correct. You can see if it also fails in YASNAC, since that can sometimes give a clue, e.g. whether it shows HARDWARE_BACKED, or how it used to not have the kernel bans (though it does now), and currently, interestingly, how old banned prints won't fail SN due to testkeys while unbanned prints do. 🤷‍♂️
[Magisk] JoeRifle:
You are right. It is not a kernel ban since I am on stock fw + a lil debloating I did. Seems more like they continue to update **** in the background, and we are getting screwed over by it.

I noticed a playservices update. But it worked after that (maybe a cache thing?)...now it does not anymore. It errors with either a crash or a bind failure to the playstore.

SN passes fine.

PS Only things I debloated as to Google stuff: OneTimeInit, MarketFeedback, LocationHistory, SampleScreen, PrintServiceRecommendations and GoogleRestore. It is not that though, I guess.
[Magisk] robbins:
Thanks, that's useful info, yeah I'm failing SafetyNet (CTS profile match failed) and it's showing as HARDWARE_BACKED. So if not kernel localversion, the props might not be all correct to force basic attestation, so maybe PA has some code that interferes with this. It doesn't have PixelPropUtils but a quick search on Gerrit shows https://gerrit.aospa.co/c/AOSPA/android_bionic/+/37595 which does apply to com.google.android.gms.unstable which is where DroidGuard is, right? Guess I'll try reverting this?
[Magisk] Dkpost3:
your build signin?
[Magisk] osm0sis:
HARDWARE_BACKED usually means the json isn't in place or has a too high DEVICE_INITIAL_SDK_INT.

Edit

:

Seeming probable that it's interference from that PIH (PropImitationHooks) AOSPA feature. It's part of Bionic libc from the commit you linked, so it isn't as easy as disabling an APK like on other ROMs, but can you see any way in the Settings for you to disable it or adjust the values? Or you might have to un/reset the props introduced by the commit: persist.sys.pihooks.security_patch and persist.sys.pihooks.first_api_level.

PM me and I'll see what we can figure out.
[Magisk] robbins:
Thanks, actually I just got it to work!

I checked with getprop and these props weren't set to a value for whatever reason. I set them to the matching values in the pif.json, and I'm now passing DEVICE. Not sure why they weren't set, but they're persist props too so they stick around after a reboot even after being manually set it seems, so looks like we're all good :). I appreciate the help looking into this.
[Magisk] osm0sis:
Hmmm, did the props exist but had no value, or were they fully not set at all? Either way them breaking attestation in the default state sounds like a bug in their code...

Edit: Just for everyone's knowledge, from our PM it seems like this is only an issue with homemade/unofficial AOSPA builds. Official builds set config_certifiedBuildProperties to pass PI and their PropImitationHooks is very similar to PixelPropsUtils now:

android_frameworks_base/core/java/com/android/internal/util/PropImitationHooks.java at uvite · AOSPA/android_frameworks_base

Contribute to AOSPA/android_frameworks_base development by creating an account on GitHub.

github.com

And it's that which is supposed to then set the persist props.
[Magisk] pndwal:
I'm no code reader; please explain why it means the PIF print is spoofed for the Play Store here...

To me, just looks like after 'Check stack for SafetyNet or Play Integrity', when calls are made key attestation is simply blocked at runtime by 'throw new UnsupportedOperationException'... That exception just causes DroidGuard itself to fall back to basic-only attestation rather than 'spoofing' for GMS (or for Play Store) no?

Re. Finsky, is it some kind of condition? 🤔 Seems that's the package name for old Android Market (from Honeycomb?)... Seems 'finsky' may still be used for some Play Store (Vending) related permissions however(?) Ta, PW
[Magisk] TestaMic:
I dm'd you. Hope you can help me
[Magisk] osm0sis:
Finsky = Play Store. That's its APK/code name in factory images from the Android Market days.

Edit: Google being Google, they like to forever do puns on puns down the line, so in a lot of places it's now called Phonesky, but it's still got the original name Finsky all over it.