yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] Sweefl:
I'd like to ask if this method is ineffective on the MediaTek platform. After patching the framework.jar according to the documentation, my device still shows as unlocked when booting up. I'm not sure if there's an issue, but theoretically, even without a valid keybox, it should at least show the BL status as locked. However, I'm encountering a problem on my device. Can anyone provide assistance? My device information is: MediaTek 8100, MIUI 14, Android 13.
[Android Software/Hacking General [Developers Only]] Vision:
Interesting, because according to this (if this method, use part of this method found by this user) the frameworkpatch, no need anymore Qualcomm CPU.

View attachment 6108526
[Android Software/Hacking General [Developers Only]] changhuapeng:
As mentioned, this module only does the decompiling, patching and recompiling of framework.jar. I cannot and will not provide a keybox.xml for this module.

It's also best to leave users to compile their own classes.dex, with their own key and fingerprint, as and whenever Google brings down the ban hammer.

I've uploaded a test version on Github issue. Please get it there and check back there if the fix is working or not.

It may be worth a try to clear dalvik-cache in your TWRP. My module does clean all boot-frameworks files at the end of the run so you won't need to do it on your own.

Just chipping in, you can look at this commit: https://github.com/chiteroman/FrameworkPatch/commit/a88e0c62725717da09721c5af8544e735ca9dd2a

where chiteroman briefly implemented the code to takes in 3 certificates.

The smali edits are simply rewriting the method calls in framework.jar to call the methods in Android class. So from my understanding, yes. The smali edits stay the same as long as any updates to the Android class keeps the same method names, parameters and return values.
[Android Software/Hacking General [Developers Only]] chiteroman:
Add Strings to Keybox.java and add them to List in Android.java

No, it's optional, but sometimes it generates a weird certificate chain
[Android Software/Hacking General [Developers Only]] chiteroman:
Never tried software certificates with original device fingerprint, it passes with custom one like sailfish.
[Android Software/Hacking General [Developers Only]] chiteroman:
Say thanks to Google, in the past you can pass Device with banned keybox, now it doesn't work.
[Android Software/Hacking General [Developers Only]] chiteroman:
Amazing job! But mounting a framework.jar may cause detections, that's why I prefer to extract system.img from super.img, make it read-write, and flash it in FastbootD.
[Android Software/Hacking General [Developers Only]] Vision:
Thanks for useful info.

Me can't pass even the basic, all red, A11.

With latest frameworkpatch with the inside keybox.xml
[Android Software/Hacking General [Developers Only]] chiteroman:
That's odd 😢
[Android Software/Hacking General [Developers Only]] Vision:
Yeah, I don't understand way.

Even though key attestation show me that.

View attachment 6108551

For test, I don't change anything, from inside frameworkpatch, all with inside FP and keybox.
[Android Software/Hacking General [Developers Only]] Claus….:
With this method, are we still depended on a fingerprint? Is it not possible to use the one in the device?
[Android Software/Hacking General [Developers Only]] Vision:
The same I wonder, still waiting for a answer.
[Android Software/Hacking General [Developers Only]] Claus….:
Thanks for getting back.

@chiteroman please describe the module a bit more, we are more people that wants to give it a try.

For me strong is not as important, as not being depended on these freaking finger prints that are constantly banned.
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
Pretty sure I did this correctly, but it results in a bootloop (at least using the Sailfish print). I'm going to try it with the fingerprint from my actual device, since it supports HARDWARE-BACKED Attestation, and see if that gets it booting. For the record these are the exact modifications I made:

Added these two lines:

New things :) · chiteroman/FrameworkPatch@a88e0c6

Modify framework.jar to build on system level a valid certificate chain - New things :) · chiteroman/FrameworkPatch@a88e0c6

github.com

New things :) · chiteroman/FrameworkPatch@a88e0c6

Modify framework.jar to build on system level a valid certificate chain - New things :) · chiteroman/FrameworkPatch@a88e0c6

github.com

And then I copied the CERTIFICATE_2 String definitions in Keybox.java, pasted them underneath and renamed to CERTIFICATE_3 to match the list in Android.java

Since it built successfully, I'm assuming it was done correctly.

It seems that this patch was actually required on my device, as without it, the AOSP certificate included in the FrameworkPatch repo showed as invalid with "BAD SIGNATURE", but now, with the "optional" patch, it works fine.
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
Well, it seems after updating gradle to 8.4.0 and rebuilding the default FrameworkPatch setup, I am indeed now passing DEVICE Integrity with the included sailfish print and default AOSP keybox.

Patched using @changhuapeng's FrameworkPatcherGO (test2 build), and running KernelSU (latest CI build a/o today). Posting both Key Attestation screenshot and Play Integrity verdict for visual confirmation.

Now to try a different keybox again...
[Android Software/Hacking General [Developers Only]] Vision:
Finally, one made it with success.

Congratulations 🎉

I'm unlucky because it doesn't work on A11 😢

So this method only work on A13+ as l understand.
[Android Software/Hacking General [Developers Only]] changhuapeng:
I've just released build v0.2 @ https://github.com/changhuapeng/FrameworkPatcherGO/releases/tag/v0.2
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
One thing I forgot to mention with the previous version installations (and this one as well) is that I had to manually create a module folder in /data/adb/modules named "FrameworkPatcherGo" with a module.prop and "update" file in order for the module to actually install/work on the next boot. Otherwise, the modules_update.img just gets deleted and the module flash doesn't take.

I think the default installation scripts for both KernelSU and APatch do this automatically, but since you're using custom scripts, this doesn't happen. I assume Magisk doesn't need this because it doesn't use image files to store modules or module updates.

Sorry for not mentioning that before the new release...
[Android Software/Hacking General [Developers Only]] changhuapeng:
That's strange, I'm using APatch and haven't notice this issue during installation. Thanks for bringing this up, I will have to go play with KSU now. Anyway, you reminded me that I've forgotten to update the version in module.prop too.
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
You're right; I just tried this installation with APatch and it works fine. It seems that only KernelSU has this problem. Perhaps it's related to the 1TB sparse image they use for modules, but it's difficult to say for sure. Hopefully your testing reveals the cause.
[Android Software/Hacking General [Developers Only]] Vision:
So the first user, that will actually success this on A11 (all stock), and pass 2/3 or 3/3, even only basic.

Please write info here (of course without sensitive info).

Thanks in advance.
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
Well I just tried installing 0.2 on KernelSU and it's working there now too. So I suppose it's a false alarm, or the updated version solved the problem. So it seems it's good to go! Thanks again for making this patch so easy to use!
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
I was able to grab a logcat from my failed boot, and it appears the problem is that the current Android.java code expects a shorter string than the one that's in the keybox that I'm trying to use. I'm not sure if it can currently accommodate a larger string, so does anyone know if there's a way to increase the available size allocation for the certificate strings? Here's the error I'm getting, for reference. And I have confirmed that there are no invalid characters in the certificate strings.

Spoiler content hidden.

EDIT: Scratch all that, lol. I triple-checked and there was indeed a typo, which I have now fixed.

The cert shows as unknown (see attached screenshot), and with my target device's props, only results in BASIC Integrity, which makes it useless. Only if it could produce Strong would it actually be useful. I'll rebuild with the sailfish props and see if it at least passes Device that way.

EDIT 2: Confirmed passing DEVICE Integrity with the Unknown root cert and sailfish props. That seems to be the best we can do with any keybox now.
[Android Software/Hacking General [Developers Only]] changhuapeng:
That's good to know, since I'm struggling to find the cause on KSU. Now that I can sit back with all the known bugs fixed. I've since re-released v0.2 with updated version in the module.prop.
[Android Software/Hacking General [Developers Only]] Claus….:
Ok, does this mean you can pass device integrity with your device finger print? And do not need to search for a finger print that may be banned?
[Android Software/Hacking General [Developers Only]] changhuapeng:
Nothing has changed, he is still only passing DEVICE integrity by using the known and working fingerprint from Xiaomi.eu.
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
Seems the 0.2.1 update brought back the visual bug that you had fixed in 0.2.

Spoiler content hidden.
[Android Software/Hacking General [Developers Only]] changhuapeng:
Welp, that didn't take long for a bug to return. It's fixed and updated, thanks again!
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
Btw, I'm chatting with someone on TG that says the PMed you about the zip not working for them. Wanted to confirm you got that message, as it seems there are some framework.jar files that aren't getting patched correctly or successfully.

It's likely because these are custom ROMs that have other framework modifications, but I thought you should at least have a chance to take a look.
[Android Software/Hacking General [Developers Only]] changhuapeng:
Nope, haven't got any PM from anyone on TG regarding that. Maybe you can direct them to log an issue on Github?
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
I asked them to do that several times but they said they were waiting to hear back from you first. I thought they PMed you here on XDA, but now I'm thinking they didn't do it at all...
[Android Software/Hacking General [Developers Only]] Vision:
Maybe this framework.jar is something like that.

View attachment 6109025
[Android Software/Hacking General [Developers Only]] changhuapeng:
Oh well, you can lead a horse to water, but...

Anyway, I've opened a thread for this module: https://xdaforums.com/t/module-framework-patcher-go.4674536

it's kinda derailing this thread with all the chatter on my module.
[Android Software/Hacking General [Developers Only]] Unb0rn:
Hey, everyone! I'm not sure if this is the right place to ask about loosely-related topics so I'm sorry in advance for all the stupid questions. (Maybe there's some Matrix or Telegram group with the discussions?)

After reading through this thread I'm surprised to learn some vendors break TEE after unlocking the BL and that we're now able to reprogram TEE at least on qcom devices - long time no device upgrades =)

I'm not really interested in passing strong security or Widevine - this is more about security and learning

I thought that some things, like device locking (Gatekeeper), FDE (Encryption KDF is bound to the KeyMaster keys, that need a Gatekeeper to create the token) and AVB - all require TEE.

Some time ago an intriguing coincidence happened:

- Oppo merged the codebase with OnePlus which resulted in bootloader relocking with avb_custom_key (AVB Yellow State) nonfunctional - https://calyxos.org/news/2022/07/06/oneplus-android-12-relock-issue (Which, in turn, was the end for some OP devices support in ROMs like Calyx based on A12 and newer) avb_custom_key may be flashed but it changes nothing - the signed image does not boot

- OnePlus started breaking the TEE on unlocked BLs

So, basically the questions are:

- If the TEE is broken - how does everything work? Does the system revert to using some software-only implementations (outside TrustZone)

- According both to Reprogram-TEE-on-Qualcomm-devices and FrameworkPatch repos, the keybox holds two chains (EC and RSA) - 2-3 certificates each. Is it possible to reprogram the factory default AVB pubkey to the self-generated one - this should remove the reliance on avb_custom_key and promote the custom key as a default one (and yes, it will permanently break AVB on stock images). This may help some users to make their devices more secure by self-managing the keys

- Is it possible to make a binary dump (without decrypting anything, obviously) to restore everything on the same device in case of failure or is there some sort of replay-protect?
[Android Software/Hacking General [Developers Only]] bl锁:
你好 Can you help me compile a copy? OnePlus 11 Android 13
[Android Software/Hacking General [Developers Only]] Renate:
TEE data is stored in RPMB (Replay Protected Memory Block).

This is LUN 3 on eMMC or LUN 68 (0x44) or LUN 196 (0xc4) on UFS.

edl /m1 /r boot0
# boot0 is 4 MB, all zeroes
edl /m2 /r boot1
# boot1 is 4 MB, all zeroes
edl /m3 /r rpmb
# rpmb is 4 MB, a bit of buffer garbage and mostly zeroes
[Android Software/Hacking General [Developers Only]] Vision:
Here: https://github.com/changhuapeng/FrameworkPatcherGO

This module do all the job for you, is automatically, and all this from your device.

And here more info: https://xdaforums.com/t/module-framework-patcher-go.4674536/
[Android Software/Hacking General [Developers Only]] bl锁:
I have used it, but it doesn't work
[Android Software/Hacking General [Developers Only]] Vision:
What Rom?

And what say in Key attestation app?
[Android Software/Hacking General [Developers Only]] pndwal:
My understanding certainly not as technical as your deductions, but it is that TEE isn't actually broken on affected devices... The Keymaster implementation, largely residing within TEE but may also be external parts, is affected and may be more or less broken however... I guess less affected examples (maybe all?) still have lockscreen, FBE etc working (if they do depend on Keymaster)... I know many OnePlus devices have broken hardware key attestation even when locked, some have TEE functions affected only when unlocked, and some devices (like Asus Rog 3) seem to send passing basic attestation data off as hardware backed for STRONG verdicts even when unlocked (false pass/keys still haven't been revoked by Google if some older firmwares are installed)... The latter OEM mess may be due to bad DriodGuard or even AVB implementations instead of Keystore too I guess, but "broken TEE" result may still not be entirely accurate/misleading and DRM decoding, biometric scanners etc can continue work...

Widevine implementations also vary wildly between OEMs... Most (Pixel, Xiaomi etc) still have L1 security after unlocking, some others strangely require MEETS_DEVICE_INTEGRITY, some are restored only when B/L is relocked, some lose Widevine keys when unlocking and aren't restored by relocking... Nb. Keys can be lost after a buggy OTA is installed on locked devices too... Seems OnePlus and Realme (others?) sometimes send users a custom app to restore keys after obtaining some unique device info... Some MIUI devices have a facility in settings to regenerate keys (can't find it in my HyperOS update however)... Some devices need server centre support to restore... Some can never get keys back. 😬

Hope it helps. 🤠 PW
[Android Software/Hacking General [Developers Only]] adfree:
@Renate

You spent some time with Samsung devices and keybuster?

GitHub - shakevsky/keybuster

Contribute to shakevsky/keybuster development by creating an account on GitHub.

github.com

I have tiny problemS with RSA 2048... and as it seems AES 256 (maybe CTR)...

em_crypto_aes_256_ctr_encrypt
em_crypto_aes_256_ctr_decrypt

Or it is...

em_crypto_aes_256_gcm_encrypt
em_crypto_aes_256_gcm_decrypt

em_crypto_rsa_encrypt...

EngineeringMode.. EM Token related... aka steady.bin...

I have some funny "example" with some AES key and IV... but I am unable to solve the riddle...

Maybe i use the wrong Tool.. or I made mistakes from get byte exact data... as taken from screenshot...

Or maybe I fail by Big Endian... Little Endian...

If you or somebody else is interested to enlight my tiny brain...

More details I can give via Conversation...

Thanx in advance.

Best Regards
[Android Software/Hacking General [Developers Only]] Renate:
Nope, I know so very little about anything Samsung related.

I know a bit about AES encryption.

It's straight forward when you have the key and the IV.

Obviously your device knows how to create them.

If they are not individual to your device or server based there is somewhere in the code where they generate it.

They try to make this as obscure as possible doing silly things, hiding it in libs.

This is different from some unlocking based on a hash of serial number and your shoe size.
[Android Software/Hacking General [Developers Only]] Vision:
For latest news about this method, users have discussion some very useful info.

[MODULE] Framework Patcher GO

Framework Patcher GO Based on chiteroman's FrameworkPatch, this module modifies framework.jar directly on the phone, to build a valid system-level certificate chain. This module is compatible with Magisk, KernelSU, and APatch. For more details...

xdaforums.com
[Android Software/Hacking General [Developers Only]] Vision:
Finally.

So frameworkpatch guide after compile on Android Studio, apparently it was working from the start on A11.

Just need it the Scripts-only mode on PIFork (without zygisk) and GMS.unstable pass 2/3.

That was the missing piece.

Thanks you @chiteroman and of course @osm0sis for all the hard work and effort. We Appreciate.

We all know where to go for a donation.

View attachment 6114389View attachment 6114390
[Android Software/Hacking General [Developers Only]] Vision:
@Captain_Throwback @changhuapeng

So for us not working the part of the gms.unstable or better when the spoof info send it to DG, we need and the hide mode (MagiskHide or Denylist) and spoof and the sensitive props (PIF fork script-only-mode), to working full.

So this 2 must write it to frameworkpatch method with some way 🤔
[Android Software/Hacking General [Developers Only]] Claus….:
Ok, so you made it work? You can pass device without needing a fingerprint whenever it is banned?
[Android Software/Hacking General [Developers Only]] Vision:
This is the funny part, I don't know 😂🤣

I'm still confused about that.
[Android Software/Hacking General [Developers Only]] badabing2003:
No you can't pass when it is banned.

Check android.java, it embeds Sailfish print, without it you won't pass, and if it gets banned you won't pass either.
[Android Software/Hacking General [Developers Only]] Vision:
Yeah, for that I'm confused, I thought with frameworkpatch method no need anymore this 🤔
[Android Software/Hacking General [Developers Only]] Claus….:
Ok, thanks. I thought that by doing this you will be able to use the phones fingerprint. Is that not possible? @badabing2003 @chiteroman
[Android Software/Hacking General [Developers Only]] Vision:
According to this.

This is from 23 May.

View attachment 6114657
[Android Software/Hacking General [Developers Only]] badabing2003:
Do you have an unbanned keybox?
[Android Software/Hacking General [Developers Only]] Vision:
Unfortunately No.

So if I had a valid keybox with strong, I could add in Android.java my device fingerprint and then work and pass 3/3 ?
[Android Software/Hacking General [Developers Only]] badabing2003:
keybox goes into Keybox.java and custom print goes to Android.java.

I don't have a non-revoked keybox to confirm if it passes without custom print (ie with device's print), but I'm sure @chiteroman can.
[Android Software/Hacking General [Developers Only]] Vision:
Yeah I know.

Me too the same.
[Android Software/Hacking General [Developers Only]] Claus….:
Exactly. this is why I am asking :)
[Android Software/Hacking General [Developers Only]] Claus….:
@chiteroman please confirm :)
[Android Software/Hacking General [Developers Only]] IoIam:
Hello, I am writing here hoping someone knowledgeable is able to help me.

I have a Xiaomi mi 9t pro, I think I broke my TEE back when I flashed my persist backup (I had lost my L1 attestation randomly and hoped to get it back).

At the moment L1 works (thanks to Xiaomi's L1 restore setting) but Key attestation demo shows this.

Considering I have a persist partition backup is it possible to restore a working TEE following this guide? (https://github.com/chiteroman/Reprogram-TEE-on-Qualcomm-devices)

If so, how do I extract my (now lost) TEE attestation keys?

Because if I understand correctly using the ones from this guide is useless since they are banned (if I'm mistaken please say so).

Alternatively I have access to an unlocked redmi note 7, is it possible to extract and use those keys, somehow?

View attachment 6115467
[Android Software/Hacking General [Developers Only]] Vision:
Unfortunately, until now can't extract TEE keys.

View attachment 6115470
[Android Software/Hacking General [Developers Only]] IoIam:
Ok thank you.

So am I hopless?

Would using the banned keys be better than nothing? (also would they work anyways for passing strong integrity with the new modules?)
[Android Software/Hacking General [Developers Only]] Vision:
Unfortunately only waiting, Google Fixed, No Strong anymore.

@chiteroman say this

View attachment 6115506
[Android Software/Hacking General [Developers Only]] IoIam:
great :/ thanks for your insight
[Android Software/Hacking General [Developers Only]] Vision:
So, with frameworkpatch method, we can use our device FP, only if have a Strong keybox.xml ? 🤔
[Android Software/Hacking General [Developers Only]] yjcbn:
How do we know that a keybox has not been COMPROMISED? The format in Google's banlist differs from that of the keybox XML.
[Android Software/Hacking General [Developers Only]] Vision:
With PixelFlasher (by @badabing2003), you can check if is still valid.

View attachment 6115659
[Android Software/Hacking General [Developers Only]] pr3dicament:
If you have OnePlus, you're screwred, right?
[Android Software/Hacking General [Developers Only]] Vision:
Not exactly.

Read the 2-3 last pages of PIF thread
[Android Software/Hacking General [Developers Only]] pr3dicament:
the LAST 2-3 pages? alright I"ll look.
[Android Software/Hacking General [Developers Only]] Vision:
Yeah, say about Oneplus and unlock BL.
[Android Software/Hacking General [Developers Only]] pr3dicament:
There's muiltiple pages added on and when i searched oneplus three were too many posts, all from february and march and then the late of may lol. God.

I was also told there's a dump stte with a lot of .. stufff. (i dont know if they're private or just for testing) and to try android 15 beta but I have no android 15 beta rom. Can you pm me a post number?
[Android Software/Hacking General [Developers Only]] Vision:
🔧 [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

and after that 889 say something about this, i think.

And from TG

View attachment 6116172
[Android Software/Hacking General [Developers Only]] pndwal:
It was largely for you from here anyway:

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

😜 PW