mhmrdd
الذهاب إلى القناة على Telegram
6 404
المشتركون
+124 ساعات
+187 أيام
+20730 أيام
أرشيف المشاركات
6 405
I managed to internally use HeapSnitch (modified) vulnerability in QSEE to extract UDS
As you may know Google has previously revoked this, but they reincarnated it again, and during my experiments, i figured that BCC it had did NOT involve TME or CE, and was self signed, and placed directly for S-EL0 signing.
This is critical, we expected at least that it's a leaf derivation from TME.
I am sorry but MediaTek claims spot 2 now that NSW-EL0 can do this on QSEE.
.
This came as a challenge because I've been rumored that some managed to do the same and even for StrongBox.
6 405
Update:
-Adapted HeapSnitch to work on post-boot after vold CE storage decryption is completed.
Tradeoff:
- [IMPORTANT]: YOU temporarily lose access to your old blobs (symmetric/asymmetric) including RKP blobs hence the video.
6 405
upon checking, we can see 2 potential ways:
1- run at service.d but heap is unstable due to call swarm unlike post fs data which we can ensure proper run of HeapSnitch (3)
2- figure way to migrate keys between two slots or leak dec key of blobs & build MiniMint (OhMyKeymint like) to handle asym/sym ops with leaked key
3- figure how exp can prepare leaked known heap for post runtime to exec (note that after swapping, the apps & others won't be able to recognize old keys, causing temporarily loss of app creds & logins, teaching secondary slot on new data)
6 405
preview 🍖
exp was finished today, I am currently investigating an issue causing the change of locked status to swap slots which loses decryption of storage keys temporarily.
6 405
you don't have to worry about me, I was already looking to get rid of my device, but everything should be safe as I pushed all my changes already, in fact I uploaded copy of the rkp db weeks ago in favor of this incident if it happens and it did
