AES Finder – the utility to find AES keys in running process memory | Hacker News Reader

AES Finder – the utility to find AES keys in running process memory

github.com

159 pointsbased250 comments

I remember many years ago, as I was thinking about going into technology as a career, I was chatting with a family friend who worked in computer security. I was asking him what he did. He said "If I have physical access to a computer, it's almost certain I will be able to get whatever data is on it. Especially if it's still running and logged in." (or something to that effect).

Stuff like this always reminds me of that guy (haven't seen him in decades, sadly). Oh, you used AES encryption? That's lovely, but your computer knows the key and I can trick it into telling me it.

Truecrypt likely changed the game on some of the claims he made, but that conversations predated it's existence.

Today the angle of attack seems to be around OTP + Password with a timeout on the credentials generated. It narrows the window, but doesn't completely block it.

Truecrypt doesn't change that if the user has the volume open. When computers still had Firewire if they had a warrant for child porn they would use FW and DMA to pull a complete copy of the memory if it was on and get any encryption keys to the Truecrypt volume. They would actually announce that they were coming in on suspicion of child porn because people had a tendency to boot the computer and open Truecrypt to delete all their files.

I suspect similar techniques are still used today, like we see with this tool. If you can get a dump of the computer active memory you can ultimately get the decryption keys on consumer hardware.

>If you can get a dump of the computer active memory you can ultimately get the decryption keys on consumer hardware

What methods are available to get a memory dump if Firewire is disabled? Feds couldn't break my encryption after ~1.5 years but my devices were all off when they showed up. Ironically the one device they did get into was a cell phone powered on but it had little evidentiary value and in one funny way was partly exculpatory.

USB-C+Thunderbolt or eSATA with a vulnerable controller. I know modern OSes have protection against driveby-DMA, but don't know if they protect against memory dump if the "user" - or attacker who gained access to a logged in system - consents.

All these attacks target decryption keys in memory, so they don't work on devices which are turned off.

I'm assuming the computer is "locked" but online, and no users consent to logging in to run anything. Will any of these methods still work if Firewire drivers are disabled?

In that case USB-C/Thunderbolt won't work, in the default config you need to trust the device and cable before anything too interesting can happen. This can be turned off via bios setting though, so there's room for misconfiguration.

E-SATA or PCIe hotplug might still work. However the former is getting less common, and the latter is uncommon in consumer mainboards.

Thunderbolt in some cases: https://thunderspy.io/

You can freeze the computer, remove the DIMMs, and then pop them into a different machine to read them: https://electronics.stackexchange.com/questions/32189/freezi...

I thought that wasn't possible since DDR3 or 4?

Smaller capacitors will keep their charge less long, which makes this more difficult, but I understand that there are no fundamental mitigations.

There's (T)SME.

The fundamental mitigation is full memory encryption using a randomly generated key that changes each time the CPU boots. That exists for some CPUs.

Well, that's not part of the ddr3 or ddr4 spec :)

Where do you store the key?

CPU registers - much harder to pull off and reattach elsewhere.

You can do it via PCIe as well. [1]

1. https://github.com/ufrisk/pcileech

It's a DMA attack, not necessarily a FW attack. DMA is direct memory access, which is how the attacks worked.

There was a neat patch to store the AES key in debug registers and do round key setup for each block. It was even faster than the normal routine. https://www.usenix.org/event/sec11/tech/full_papers/Muller.p...

It seems unlikely that

(a) FBI understood truecrypt

(b) the target understood truecrypt

and (d) the FBI expected this and intentionally blew their cover, leaving the target a chance to destroy the drive.

It's likely though that they knew that AES keys are somewhere in the memory.

Why did having FireWire matter?

Because FireWire has direct memory access (DMA).

See https://en.wikipedia.org/wiki/DMA_attack

I had a brief moment of technological joy when I worked at a place that had strict rules about leaving your computer unlocked, which I always struggled with.

I had this new Symbian phone with Bluetooth (2?) and there was an app you could get for OS X that would lock your machine when it lost BT signal.

Sub in a larger battery (still one of my favorite mini hacks, removing a little plastic so the 30% bigger Ngage battery would fit) and I was good to go, until the app stopped working.

Big part of why I bought an Apple Watch (and then keep forgetting to set it up)

I worked in a place in 2006 where my username was a badge and my password was my fingerprint.

The badge had to be inserted into a reader for the computer to be unlocked. It was also attached (via a badge holder) to the RFID badge needed to open any locked doors. This meant that to get to and go to the washroom, I had to take my badge out, which locked the computer.

It was a very neat and secure system.

Can someone explain how this works? I thought AES keys were just random bytes, but obviously there must be more to them if this tool is able to detect them.

Looks to me like it's searching for expanded keys, i.e. the sequence of round keys, not just raw AES keys.

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-fi... [2]: https://en.wikipedia.org/wiki/AES_key_schedule

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.

The parent repository has a decent answer: https://github.com/mmozeiko/aes-finder/issues/12#issuecommen...

Thank you very much, that was exactly the information I was looking for.

The TRESOR[1] kernel patch was proposed to prevent these attacks.

It stores keys in privileged registers.

[1]https://en.wikipedia.org/wiki/TRESOR

Sort of feel like such posts should link directly to the original repo the repo was forked from, if any.

https://github.com/mmozeiko/aes-finder

Unless there’s some newsworthy aspect to the child repo being a special different fork.

The pull request https://github.com/mmozeiko/aes-finder/pull/11

Says "Improved cross platform capability, key dumping, memory dump search." but it's not even new code so nm comment on it.

The pull request https://github.com/mmozeiko/aes-finder/pull/11

Says "Improved cross platform capability, key dumping, memory dump search." but it's not even new code so nm to comment on it.

This fork has a "memdump" tool to dump the memory of a process and a "-f" option to search for keys in a file, which I assume is the dump from step 1.

This source file provides a better history for looking for AES keys. It looks like Sam Trenholme developed the technique originally but I know of it because of Jesse Kornblum’s subsequent work. Simson Garfinkel then embedded relevant code inside of bulk_extractor. The technique is over a decade old:

https://github.com/simsong/bulk_extractor/blob/master/src/sc...

It looks like this particular fork of this code has a few nice features that aren't in older versions, such as support for dumping memory and actually knowing about the other common formats of AES key schedule that are commonly found in the wild. It's really annoying to run a search over a dump that you suspect contains an AES key schedule and coming up with nothing because the encryption library used a slightly different way of storing it than the one expected by the tool.

Excellent and informative replies to parent here (the replies are peer comments to this one). Thank you!

There were also tools about 15 years ago to find the entry point to encryption routines by finding the SBox constants.

There's lots of those, and they're much easier to write, since you're literally just grepping memory for a fixed string.

https://www.reddit.com/r/netsec/comments/innmgn/a_utility_to...

Also see this from 2007: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87....

I believe I also saw that talk at a CCC camp back then.

Edit: ah yes, here it is: https://media.ccc.de/v/cccamp07-en-2002-Cryptographic_key_re...

https://github.com/susam/aes.vbs

Someone please run this on matlab...

Reply on news.ycombinator.com