I got a message from a buddy of mine last night asking me about imaging physical memory (RAM) on Windows systems. The "how" of this is pretty simple...just jump on over to George Garner's site and grab a copy of dd.exe. The command you use to image RAM is even listed on George's site.
Okay, so you have a copy of RAM...what next? This is the kicker, IMHO. Say you have 512MB of RAM...you'll get an image file around that size. So what do you do with it? Well, you could run strings on it, but what would that give you? How would you associate information you find with tools such as strings, with specific processes? Consider that the memory used by processes is fragmented across both RAM and the swap file...so imaging RAM is only going to give you a partial view of what's going on on the system.
In the absence of adequate tools to parse an image of RAM, another approach is to use tools such as pmdump.exe to dump the contents of process memory, both RAM and swap file. At least in this manner, you can associate anything you find with a specific process, even though more comprehensive tools for parsing this information don't seem to be available.
Thoughts?
4 comments:
Not to start a holy war about tools, but have you tried the Coreutils for Windows set?
Can Cygwin's dd access Physical Memory?
Jesse,
Yes, I've looked at those, as well as the Unix Utils over on SourceForge.
Can you give me an example of how you'd use these tools?
Regarding your second question, I have no idea...I find George's version of dd.exe to be quite sufficient so far. If it does, it might be interesting to have a run-off...
Hey Harlan,
You can use things like ProcDump or the OllyDump plugin for OllyDbg. Those will let you dump a full process image out of memory. This is something I do from time to time when analysing packed or encrypted malware.
One could Google for honeynet SotM 32, and read the solutions for full instructions, including fixing the PE headers manually so you can then unpack the binary or open it in IDA or whatever.
Otherwise, once you have a dump you can just sort through the thing with any debugger to look at the call stack etc, which might be enough, depending on why you wanted to dump the memory in the first place.
Cheers,
ben
To answer my own question ("Can Cygwin's dd access Physical Memory?"), the answer is no. Cygwin is a great toolkit, but the filename for physical memory gets munged along the way. Here's a sample (retyped from memory, not a cut and paste):
$ dd if=\\.\PhysicalMemory of=foo
dd: \\.Physical Memory: No such file or directory
Notice that the trailing slash in the filename has been stripped out of the error message.
I had to hardcode the entries for PhysicalMemory, logical drives and physical devices into the Windows versions of md5deep et al. I wonder if we need to do the same thing for dd under Cygwin?
Post a Comment