4 ms·

I took a skim of the source[1] -- I think that it's looking for an expanded set of round keys[2] using their expected layout in memory (accounting for endian fl

I took a skim of the source[1] -- I think that it's looking for an expanded set of round keys[2] using their expected layout in memory (accounting for endian flips, forward/reverse ordering, 128/192/256 bit variants, and enc/dec). If a matching region of memory is found, the first round key is the main key. [1]: https://github.com/MantechUser/aes-finder/blob/master/aes-finder.cpp https://github.com/MantechUser/aes-finder/blob/master/aes-fi... [2]: https://en.wikipedia.org/wiki/AES_key_schedule https://en.wikipedia.org/wiki/AES_key_schedule

makomk 6y ago
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 https://github.com/makomk/aeskeyfind Could just have used this instead if I'd known about it.
- dunham 6y ago
  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.
hinkley 6y ago
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?
- EE84M3i 6y ago
  What do you mean by "problem"? Are you talking about obfuscation?
  - hinkley 6y ago
    > 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.
    - EE84M3i 6y ago
      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.
      - panpanna 6y ago
        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.

makomk 6y ago

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 https://github.com/makomk/aeskeyfind Could just have used this instead if I'd known about it.

dunham 6y ago
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.

hinkley 6y ago

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?

EE84M3i 6y ago
What do you mean by "problem"? Are you talking about obfuscation?
- hinkley 6y ago
  > 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.
  - EE84M3i 6y ago
    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.
    - panpanna 6y ago
      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.