2

Is there a way to prove a program doesn't leave keys in memory after it exists?

Some programs are designed to zeroize sensitive fields after they are used. If you knew the values of these fields you could scan for them in memory after the program exists if you could avoid causing a segmentation fault.

One approach I've imagined is hacking the OS so you controlled same memory the program used. Then just search the memory for the field values. Assuming the fields were long enough false positives would be like hitting the lottery.

If this is reinventing the wheel please tell me what this wheel is named or if I'm making this to complicated.

Sure you can't prove it will never leave keys but you could prove it didn't during a particular run. Just looking for a reasonable test developers can use to check.

2 Answers 2

1

In a development environment, you'd just need to attach a debugger, break right before exit, and search the memory.

I can't imagine a good reason to do this in production, so that's probably sufficient.

2
  • Sounds like a decent approach. No reason to do in production. Don't know any debugging tools that let you search the entire application memory though. Would I have to roll my own? Working in Java here. Commented Nov 17, 2016 at 3:49
  • I'm pretty sure Visual Studio has a debugger window for viewing (and searching) memory, but if I wanted a quick-n-dirty solution, I'd probably use Cheat Engine. Commented Nov 17, 2016 at 3:52
1

Any process you control, you can dump the memory from, then search for strings.

In *nix

There's a great question on ServerFault Dump a linux process's memory to file that mentions a number of tools you can use, for example, here's how to do it using gdb:

$ gdb --pid [pid]
(gdb) dump memory /root/output 0x00621000 0x00622000

You can then search the dump file using the strings tool.

In Windows

You can take a memory dump of any program from the Task Manager. There seems to be a number of ways to analyze a dump file; a quick google search found me the Windows Debugger (WinDbg): [1], [2]. It also looks like you can open a dump file in Visual Studio [3].

enter image description here

Beware: keys are sometimes obfuscated in memory

Also be aware that you may not be able to find keys in the dump file with a simple ctrl+f because clever application will obfuscate them by XORing them with a bitmask stored somewhere else in the process' memory, or similar tricks. To really prove tha a program doesn't leave keys in memory, you need to know that program quite well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .