Yeah, it's a trick that's been around for a while. The thing that makes it a little fiddly is that the various ways to store a key schedule, especially for decryption - it could be in either order, and there's some optimization to do with whether InvMixColumn is pre-applied to the values that I can't remember the details of. I actually had a fork of the classic aeskeyfind that added some of these tricks, though apparently it's broken at higher compiler optimizations now and I probably need to look into that: https://github.com/makomk/aeskeyfind Could just have used this instead if I'd known about it.

Also sqlite3's encryption seems to be a byte swapped AES.

E.g. look for a byte swapped AES key schedule in dropbox process memory and you should find its sqlite3 encryption key.

Shouldn’t there be a way to relocate the bits so that the L1 and L2 caches are still happy but the data structures aren’t contiguous? Is the main problem that they are all malloced sequentially?

What do you mean by "problem"? Are you talking about obfuscation?

> looking for an expanded set of round keys[2] using their expected layout in memory

The problem is predictability of the layout, right? The layout is chosen for throughput, but CPU caches can cope well with some nonlinear layouts.

Keys having an expected layout in memory is not a problem, nor is being able to dump encryption keys from process memory if you have access to it. That's the security model these processes operate in.

Processes could conceivably put keys in memory in a non-standard way that is more difficult to write a tool to scan for, but the fact that they don't is not a problem, and even if they did it would not make it impossible to write a tool.

The point is that if we could move the pieces of key schedule around freely it would increase the complexity of the tool significantly since it will have to match each potential block against a number of other potential blocks.