No. Not even close, sorry.
The Cellebrite article was an extremely weird flex, amounting to "it was hard, but we figured out how to decrypt a file having both the key and the source code". Congrats?
If you have an unlocked phone, of course you can read the messages.
Conversation
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Replying to
I think the app lock is more about "handed over unlocked phone to friend to look at pictures" than "defeat memory forensics on unlocked phone".
Relatedly, I don't really believe in wiping specific secrets from memory without (inexistent) language support.
1
3
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Replying to
Honestly, I don't think it works even with native languages. You might wipe the key, but won't wipe the AES key schedule, or the RSA CRT values, or other derived values.
The only thing that works today is having a separate process and nuking its address space, IMHO.
2
6
If the kernel is set up to clear freed pages immediately at least. The Linux kernel doesn't do that by default. It tries to avoid clearing them at all (most internal kernel usage). Pages mostly get cleared on allocation since it's required for making them available to userspace.
1
1
Doesn't mean that it's not useful to clear freed memory opportunistically though. Clearing pages on free in the kernel is just one example with major benefits.
Even in a shared address space, a thread going away deals with a lot of the harder aspects if stacks are freed/cleared.
1
1
github.com/mollyim/mollyi does exist. IIRC, it uses low-level runtime functionality to clear pages held by the GC. Haven't reviewed it beyond taking a quick look at it. It could be done properly and meaningfully reviewed for a specific runtime version but it's not trivial to do it.
1
3
In , we use zero-on-free in the kernel page allocator, kernel slab allocator and malloc in userspace.
It helps with use-after-free, uninitialized memory usage and gets rid of sensitive data sooner. It also helps that Bionic doesn't cache pthread stacks like glibc.
GC is more friendly to doing this than you might expect due to heap compaction. Android Runtime switches to a more aggressive compaction approach when an app goes into the background and triggers a full GC cycle. We're going to look into opportunistically clearing more data then.
2