NatsukiDec 16

@BednarTildeOne

Hello Michal,

I recently read your excellent write-up, ResourcePoison

I observed what seems like an unusual construction pattern in LoadedApk.java. Specifically, the Shellcode class appears to be constructed twice in the following locations within the file:

- https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;drc=50f34b45baed2ec3a256f1c65df4865d72452768;l=376

- https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;drc=50f34b45baed2ec3a256f1c65df4865d72452768;l=393

I am wondering if this double construction is a result of the Proof-of-Concept (PoC) leveraging an unusual execution flow, or if this behavior is an intentional design (or perhaps an unintentional error) within the Android Open Source Project (AOSP) code itself.

Show threadBEDNAR~1Dec 16

@natsuki Not sure what actual answer is, but updateApplicationInfo is not part of usual app startup, so it wasn't thoroughly tested

I guess PoC triggers unusual path of creating new ClassLoader during updateApplicationInfo, and it was intended to always update mAppComponentFactory, so factory is created twice in this (uncommon) path, but I think there's no harm in that, as AppComponentFactory is supposed to be stateless

So we've got

1. Call to method that may but usually doesn't create mAppComponentFactory
2. Explicit (intended) re-creation of mAppComponentFactory

Show threadNatsuki
@BednarTildeOne By the way，the cleanup skills are truly impressive.
Dec 17 at 6:18amWeb
Show threadBEDNAR~1Dec 17
@natsuki That being said, cleanUpAfterExploitation() doesn't actually fully clean, as if it were it'd be possible to run exploit multiple times without reboot, however it was good enough to submit to Google and published version is pretty much same as originally submitted
Show threadNatsukiDec 17

@BednarTildeOne Last week, I tried rewriting the PoC using only your writeup as a reference. Although I successfully triggered code execution, SystemUI kept crashing. After digging into your original source code, I finally found the 'treasure' that specific fix this.
I’m also the one who submitted the PR to `ThisSeemsWrong`; I hadn't realized at the time that the issue was due to a different writeTypedObject implementation.

I really enjoy your writeups, and personally I find digging into the PoCs even more fun.
Thanks for the great work!

Show threadBEDNAR~1Dec 17
@natsuki That's really cool, thank you