yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
As I've tried to explain, this isn't just about TEE, and there's a lot of other mechanisms in play here. Unless the bootloader is locked on OEM firmware, there simply is no continuous chain of trust. But, once again, @pndwal will be able to explain it better.

If it were as easy and straightforward as you suggest to reverse engineer everything and get a STRONG_INTEGRITY verdict on an unlocked or modified device, chances are someone would have done it already. I'd like to point out that thus far, the SafetyNet fixes did not result in HARDWARE_BACKED evaluation, as with this result:

The updated fixes that work with Play Integrity still don't result in a device passing STRONG integrity, but rather prevent the use of hardware authentication to validate the CTS profile and basic integrity.

But this is simply changing the device signature using MHPC. As described in the OP this is just one piece of the puzzle when it comes to security guarantees on Android devices. You can potentially spoof whatever fingerprint on whatever device you want - you could make an ASUS ROG look like a Samsung. All that means is that Android is running on a compatible device.

See first reply....
[Magisk] pndwal:
Based on initial model prop mismatch needed to bypass hardware verdict enforcement (we can simply append a space character after model, or just call it 'creamcheese', Google seems to be using a whitelist of hardware key compliant (working) devices rather than a blacklist for devices w/ broken keymaster... Incidentally while hardware keystore has been around from Android 6 (off top of head), keymaster 3 (from A8) is the prerequisite for strongIntegrity verdict...

John Wu made comments when SafetyNet began using Hardware evaluation type in March 2020:

www.twitter.com/topjohnwu/status/1237656705225248768

The same day Shawn Willden, Tech Lead for Android hardware-backed security subsystems, responded to John's further comments:

www.twitter.com/shawnwillden/status/1237703953309147136

Check the wiki article John linked also...

Below this is conjecture by Husson Pierre-Hugues (of SuperUser root and GSI/Treble ROM renown) and Mishaal Rahman (then chief editor for XDA, now Sr. Technical Editor for Esperdev + Co-host for android_bytes & androidshow) about the possibility of using exploitable keys for bypassing hardware keystore based attestation etc...

Shawn responds:

The exchange between Hudson and Willden continues for some 3 more posts before being shelved, then resumes in July with 20 more posts after a query from Hudson... Willden gives detail about the decision process for key revocation, why the model would make "attestation a nearly-unbreakable signal" and why "any vulnerabilities that allow working around it will be short-lived" involving patches to restore a usable root of trust, authentication, bootstrap provisioning, provisioning refusals, cryptographic proof of fixes, short-life attestation keys and key revocation, TGC DICE secrets, fuses, key pairs, bootloader hashing, DICE strategy, private keys, certificate and boot chains etc etc... Seems to address much of your conjecture too...

Nb. this qualified remark:

Nb. John published his own series of FAQ answers summarising SafetyNet changes implementing hardware key attestation very early on also:

www.twitter.com/topjohnwu/status/1237830555523149824

👀 PW
[Magisk] usernamejames:
Thanks for your comment and your details. As I noted before, google could easily patch everything so it would have to be a closed source solution. And in the case of Google strong obfuscation and only paid members would be need too. I don't doubt that a public release would be patched in seconds, but it was mostly thinking about the possibilty and if someone wrote it .

And indeed, Google would be very fast in fixing it, but If you manage to get your hardware key check working for a few seconds then I would guess that you could abuse caching results of apps checking it.

For example: App A succeed in checking hardware key checks. Now you corrupt the app preventing it from updating your hardware key checks and make sure that it continues working. If for example a app checks every 30 seconds based on device time if your hardware safetynet checks are successful, then you could spoof every 30 seconds your time for the safetynet checking part of the app

Shawn and other responds are pretty advanced and I will look into it more extensively. Pretty pessimistic now that this can be done without making it a full time job
[Magisk] usernamejames:
Never said that the dosis work for strong integrity, i was hoping that theoretically someone could be able to write it. Thanks for the explanation about the difference between spoofing using MHPC and the real complications safetynet is causing
[Magisk] usernamejames:
What if i would fake a whole TEE environment with for example modding the kernel? as that's checked at client side, I should be able to do so, but systemless root wouldn't be enough anymore i guess. At this point I think the other steps aren't that complicated anymote
[Magisk] usernamejames:
I don't believe the speed of there revokions of hardware integrity checks as that would mean a huge amount of users not able to use the checks anymore.

Edit: ignore the patching. The app developers are checking with their own servers too if you still pass it.

Only thing I know:

- Imitate a whole TEE implemtation modifying the kernel to give false info about keys and bootloader status and stuff( if it's the Tee telling the bootloader unlock status. I dont know). Can't be done systemless like magisk, but could work with supersu

- start spoofing Google Play Servers with using a custom DNS. This DNS is falsely giving a positive https resolut for my faked Google play server and this fake Google play server is giving positive results. This step has been used in the past by games using always online DRM

- Use (revoked) hardware keys of hardware check succeeding devices and use the fake google play server to pretend they still work, pretend that it's the same device as mine, and that i use older Android having less checks.
[Magisk] V0latyle:
I think you're still missing the whole "root of trust" thing...

The only way you'd be able to implement a fake TEE is through modified images, which wouldn't pass Android Verified Boot, which would require an unlocked bootloader, which flags the boot state as "untrusted". That's the issue here; TEE still works when bootloader is unlocked, and hardware keys can still be used, BUT everything is declared "untrusted" because the kernel and system images can not be verified as genuine.
[Magisk] V0latyle:
Well, I did more testing.

Updated Messages, intentionally broke my print, killed Droidguard, checked integrity verdicts: 0/3. Unable to use RCS.

Fixed print, killed Droidguard again, passed 2/3, RCS working again
[Magisk] supermansaga:
dumb question. Where do i place the custom.pif.json? where is this "module directory?" I saw "google/redfin/redfin:13/TQ3A.230901.001/2311.40000.5.0:user/release-keys." Does this mean my Windows Subsystem for Android is treated as a redfin? But Google Bard told me redfin is not an android phone model? How can I learn more about this WSA print and appropriate it for Play Integrity v6? I still fill like somehow I don't know how to fill out the print based on brands out there. Many thanks.
[Magisk] HippoMan:
When using PIFork, custom.pif.json actually goes into the modules/playintegrityfix directory, not simply the "modules" directory. That isn't clear in this thread's OP nor in the PIFork documentation linked in the OP.

Also, "redfin" is the name of the Pixel 5 device. I have that exact device, and "redfin" is indeed listed as its official name.

The fact that Bard got this wrong is not surprising, given how unreliable LLM ("Large Language Model") software is. I wouldn't trust Bard nor ChatGPT nor any other LLM software for any kind of information which is important to me.

As for the other thing you asked, you should read the entire OP here and go to all of the links mentioned in that OP. And you should read the "Top Linked Posts" section here to get more information.

Also, check the OP and the Top Linked Posts in this thread:

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/
[Magisk] V0latyle:
Please ask your questions in the Play Integrity Fix thread. This thread is not for support.
[Magisk] simplepinoi177:
basically there are scripts and tools that will "fill out the print" for you.....

you've been directed, & they've been referenced, already, so I'll keep from spamming repeated things....

but as my esteemed colleague @V0latyle already directed...

As per Forum Rule 15 & 5 (relevant excerpts quoted below), "15. Keep...posts on-topic" and "Always post in an existing thread if a topic already exists, before creating a new...". Also, as Forum Rule #1 states, "Use one of our search functions before posting...whether you have a question...it's very likely that someone has already asked that question".

It would be best if this (along with all of the Forum Rules) is kept in mind when posting in the future.

Your cooperation is appreciated,

simplepinoi177 FSM

XDA Forum Rules said​

15. Keep threads / posts on-topic​

​

Whilst a minor amount of off-topic posting may be overlooked, the general rule is that your posts / threads must be relevant to the Forum / thread in which you are posting​

​

5. ​

Always post in an existing thread if a topic already exists, before creating a new

1. Search before posting.​

Use one of our search functions before posting or creating a new thread. Whether you have a question or just something new to share, it's very likely that someone has already asked that question or shared that news.​
[Magisk] borisSweden:
Good to know, I hope we get a alternative to Google implementation and that RCS UP gets more popular with the carriers and Apple. Or if the RCS client demo get more mainstream, there is a experimental app.
[Magisk] V0latyle:
Well, I didn't test with a print that only passes BASIC, so I don't know.
[Magisk] dilligaf56:
Have been out of the loop for a few weeks - crazy busy, haven't had time to deal with this, so have been paying with physical cards.

Can someone point me to a thread or series of posts detailing the best way to deal with this now? I know that PixelFlasher now has a PIF feature for dealing with applying fingerprints, but I'm not sure how to find one or apply it. I do have an old LG V20 which runs Android 8.x (latest version provided for it), so if there's a way to extract its print, maybe I can use it. My Pixel 6 Pro is currently on the current rooted factory image, latest Magisk, and using chiteroman's v15.2, but only passing BASIC and GPay is a no-go. Tried installing osm0sis's module but I get an "unzip error".

Pardon the basic query but I have looked around and can't find a good set of up-to-date steps. Thanks in advance for any help.
[Magisk] badabing2003:
Have you checked OP?
[Magisk] V0latyle:
Literally 3 posts above yours:

Here's your answer

🔧 [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] dilligaf56:
Sorry everyone. My bad. Thanks for the pointer. Working on it.
[Magisk] Spartacus500:
Hello, today SafetyNet failed for me 🤷
[Magisk] V0latyle:
This is not a support thread.
[Magisk] MagicIllusion:
how can hacker TEE os , I want get some private key
[Magisk] V0latyle:
You can't. Any compromised private key will be revoked by Google and will therefore become useless.
[Magisk] MagicIllusion:
how to dubug in my android phone TEE
[Magisk] zgfg:
TEE is TRUSTED Execution Environment.

Separate hardware with an embedded OS.

Closed, you cannot debug

Trusty TEE | Android Open Source Project

source.android.com

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

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

developer.android.com
[Magisk] AnotherM1m:
Hello can someone help me?

Nothing Phone 1 with locked bootloader, can only meet basic integrity

previously the phone could pass all the attestations, but then it got bricked with a custom rom, restored with an edl tool which deleted the imei and serial number.

restored those seprately with a backup of persist and qcn done previously

but from then on play integrity api can no longer pass, does anyone have any suggestions?

from fastboot oem device-info it also returns bootloader unlocked history set to true while other devices which got unlocked and then locked again have this property set to false.
[Magisk] zgfg:
Are you back on the stock ROM?

Check with the Key attestation app, maybe something got wrong with the Key Store or so when restoring Persist

Also, what exactly returns PI - Passing Basic?

What exactly do you get when testing SN/YASNAC (Basic Yes, CTS Hardware failing or what)?

Give the screenshots and from the JSON response
[Magisk] AnotherM1m:
the phone is not mine, im looking into multiple users having similar issues on their phones.

stock rom, locked bootloader, key attestation demo returns from people who where able to restore their fingerprint through calibration or flashing a backup of persist:

Not supported by this device
This device does not support key attestation or the trusted environment on this device is broken.
Solution: Consult the device manufacturer whether the device supports key attestation function and the destruction conditions of the trusted environment, such as unlocking the bootloader.
Detailed messages:
java.security. Provider Exception: Failed to generate key pair. android.security. KeyStoreException: -10003 (internal Keystore code: -10003 message: system/security/keystore2/src/security_level.rs:622 Caused by: 0: system/security/keystore2/src/security_level.rs:620: While generating Key without explicit attestation key. 1: Error:: Km (-10003))

for people who did not restored their persist img

Not supported by this device
This device does not support key attestation or the trusted environment on this device is broken.
Solution: Consult the device manufacturer whether the device supports key attestation function and the destruction conditions of the trusted environment, such as unlocking the bootloader.
Detailed messages:
java.security. Provider Exception: Failed to generate key pair. android.security. KeyStoreException: -10003

For play integrity check returns only basic integrity.

With YASNAC yes to basic, no to CTS profile match, evaluation type: HARDWARE_BACKED

Spoiler content hidden.
[Magisk] zgfg:
No chance for warranty or official service?

Don't know if you could reflash the keys and everything again.

Only root and then PIF and Device Integrity
[Magisk] V0latyle:
This isn't a support or troubleshooting thread, this discussion needs to go elsewhere.
[Magisk] usernamejames:
Thanks. Didn't know that
[Magisk] V0latyle:
No problem. I had tried to explain this previously, such as here. I don't exactly know how the system or the Play Integrity API "knows" the bootloader is unlocked, images are unverified, and operations cannot be "trusted"...this seems to be both complicated and simple at the same time. Regardless, as was pointed out previously, the only way to get hardware backed STRONG attestation is on a locked device running pure OEM firmware, meaning this wouldn't work with a custom root of trust (yellow state bootloader). The obstacles preventing us from getting to that point may seem insignificant when their function is not fully appreciated. Is it completely impossible? No...almost everything is possible, given enough time, money, effort, brains, and computing power, but in this case it may as well be, because even if the whole system were somehow cracked, they would immediately revoke the keys involved. Meaning, if we did manage to crack it on a particular device, it wouldn't be long until they threw a wrench the size of a Buick into the thick of things, which would render every device of that type unable to use hardware attestation, regardless of whether it was locked or unlocked.

So we basically come back to square 1. As has been discussed ad nauseum, Google (and other app developers) always had the ability to enforce a hardware backed attestation requirement on SafetyNet - they just didn't do so. Play Integrity has the same ability; the question is whether anyone will use it. Some doubtlessly will, because at some point they won't care about supporting pre-Android 8 devices, at which point those apps will only function on unmodified locked devices.
[Magisk] usernamejames:
I get your point and sorry for my bad reading. Do you know which android verified boot(AVB) is required for hardware safetynet?
[Magisk] usernamejames:
Android verified boot AVB v2 is enforced from Android 8 and V1 is used before Android 8. Th end of Android 7 support was somewhere mid November 2021 and the hardware safetynet checks are launched around the same date so possibly you could enforce android verified boot(AVB) V1(.5) on a specific device and still be allowed for the strong checks. That would be very interesting, because there have been some security issues with V1.

Otherwise we will need a TEE vulnerability (worth 1,5 million. Won't become public) allowing root without bootloader unlock

I know that I'm exhausting and if you are tired of me, then you don't have to answer

Seems there is a direct correlation between safetynet strong from Android 8 and Android verified boot V2 from Android 8. But V2 works only for devices shipped with Android 8 at production. I sti have the small hope that Android verified boot V1 works for devices that got a upgrade from Android 7 to 8 from the default OEM, but i doubt it. V1 has some security issues that could help doing the impossible

I will start crying about the impossiblities
[Magisk] usernamejames:
I think we would have to downgrade google play service(or microg's spoofed play service version) in the future and to start modding apps checking for safetynet. As stated in https://github.com/1nikolas/play-integrity-checker-app:

I have seen too that many apps only do the check once or once in a montnh due to heavy server usage and safetynet his default quota limit of 10,000 the month. Making modding options even better
[Magisk] usernamejames:
GitHub - chenxiaolong/avbroot: Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot

Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot - chenxiaolong/avbroot

github.com
[Magisk] pndwal:
This still won't help with passing strongIntegrity even w/ relocked bootloader...

The assumption that a check for locked boot state is at the root of current attestation checks (CTS Profile match, deviceIntegrity, strongIntegrity) is really to generalise / put it too simply...

While it is generally true, for devices where re-locking using custom keys (yellow bootstate) is possible (Pixel, OnePlus, others?), VerifiedBootState = SelfSigned will still cause those attestations to fail. This is because a custom Root of Trust is used and that by design conveys that the device is booting a custom OS... VerifiedBootState = Verified (green bootstate) is needed for passing attestation...

In short, a locked device in Yellow bootstate (using custom signing keys) cannot pass either strongIntegrity or CTS Profile match / deviceIntegrity where hardware key attestation and enforcement of hardware-based verdicts are not bypassed. Here's how @kdrag0n put it:

www.reddit.com/r/Android/comments/l8pv70/comment/glf9b1l/

Relocking bootloader w/ custom keys can have attestation related advantages however. For example on some devices L1 Widevine CDM security level for DRM content is lost on unlocking. L1 can be restored w/ custom ROMs on some OnePlus devices this way (although there may be other fixes for this also).

But yellow state is fraught due to it making many OS combinations 'fatal' (LOCKED state means that verification errors are fatal whereas in UNLOCKED state they are not), ie device won't boot / is bricked.

Eg. ROMs / custom kernels requiring AVB flag stripping etc (--disable-verity --disable-verification in vbmeta.img) will always fail this way as AVB_SLOT_VERIFY_FLAGS_ALLOW_VERIFICATION_ERROR flag in avb_slot_verify is not passed and only AVB_SLOT_VERIFY_RESULT_OK is treated as non-fatal.

🤠 PW
[Magisk] pndwal:
This should help:

Google have given a pretty good overview here:

https://developer.android.com/training/safetynet/attestation

as well as in the new Play Integrity API doc pages and elsewhere, but they never mention the specific engine used as "The SafetyNet Attestation service" that "evaluates the runtime environment"...

Fortunately reverser engineers have added much detail... I put a summary of Security Engineer Romain Thomas' recent (May 2022) findings in the Magisk General Support/ Discussion thread that includes a

link to his whitepaper

(pdf).

Basically these efforts make the connection between com.google.android.gms.unstable[/CODE] process's [ICODE].droidguard.DroidGuardService service and "the.apk" found at /data/data/com.google.android.gms/app_dg_cache/<hash>/the.apk

which proves to be the "real" Droidguard implementation (a native module) that is itself the Attestation engine responsible for performing the devices integrity checks implementing a Virtual Machine who's bytecode downloaded from Google servers is unique for each attestation request. My summary touches on how the DroidGuard engine performs checks and communicates them securely:

... I also appended a link to another reverser's conversation with Google (posted on Imgur) after he discovered Google's hidden message inc. email address embedded in DroidGuard VM code... That's insightful in itself...

... at least since hardware keystore based attestation was added to SafetyNet API in March 2020 to leverage Keymaster 3.0 in Android 8.0+...

Of course SafetyNet was introduced in March 2015 (tempus fugit)... Before hardware backed attestation was on the table custom modders still needed Magisk or similar to hide root from GMS process(es), adjust sensitive props and sometimes to spoof a certified fingerprint aligned with security patch dates in order to pass SafetyNet... But HKA has been a logical extension of the original SafetyNet concept.

Quite. And for some pretty clear reasons!

Again that's the assumption, but there doesn't seem any way to dismiss it as anything but the logical conclusion already years in the making...

Interestingly, keymaster has evolved to v3.0 at which point it was mature enough to introduce HKA when paired with AVB 2.0...

The Future:

Now (with version 4.1) it seems keymaster is being phased out also in favour of a new KeyMint implementation, and we already have v2.0!

https://developer.android.com/train...-attestation#certificate_schema_securitylevel

This is to support a new third tier of key storage security. These have emerged as follows:

Strongbox / KeyMint / Remote Key Provisioning began being tested w/ Pixel 3 from 2018 w/ its new tamper-resistant hardware enclave called Titan M.

Google announced in March 2021 "the formation of the Android Ready S(ecure) E(lement) Alliance... SE vendors are joining hands with Google to create a set of open-source, validated, and ready-to-use SE Applets"

XDA has mentioned that Remote Key Provisioning (supported by KeyMint) will be mandated in Android 13:

https://www.xda-developers.com/google-remote-key-provisioning/

👀 PW
[Magisk] usernamejames:
Wow, that's a lot of effort. But to use this remote key provisioning you need hardware support right? So before google will drop Safetynet support for devices using TEE is probably after 10 years or more