volatile memory on windows

Thomas,

Reading through some of your comments, as well as reading through the man pages for Wietse's memdump, it would appear that there was a huge disconnect when you replied to the original post, particuarly with regards to the "for windows" part of it.

> You can use 'dd' for some memory, but not all

You gave no clarification as to what types of memory you're referring to, but the 'dd' that I provided a link for has been used quite successfully by myself and others to dump the contents of \\.\PhysicalMemory. If you read George Garner's page, you'll see quite clearly that that's what it's designed to do. As you said, it's written for that purpose.

The man page for memdump (from Wietse's site) states that too large values for various switches will cause holes or parts of memory to be missed on various *nix-like and *BSD systems. However, there is no direct correlation to this on Windows.

> I have used memdump compiled for Windows as well (DOS version) in
> addition to a proprietary dumper, one page at a time.

Two questions for comparison sake, what was the "proprietary dumper", and how do you know that the dumping was performed one page at a time?

Thanks,

Harlan

Does it have to be the entire memory or Open Source? If neither are necessarily required, then here is a not-quite-complete-cause-I-can't-remember-them-all list.

Everyone already knows about dd for Windows from George M. Garner so I won't discuss it any further. Until, the tools like those developed in the 2005 DFRWS memory forensic challenge are released, dd memory images are only as useful as the strings you pull out of them.

There is some promising research from Mariusz Burdach who just spoke at BlackHat Federal 2006 on "Finding Digital Evidence in Physical Memory." His website is located at http//forensic.seccure.net/ but his documentation memory forensics is more up-to-date on the BlackHat Media Archives page. The tools/docs archive even has the Windows version of wmft.exe which isn't on his webpage yet (just the linux version of wmft is there).

Memdump was mentioned but there are at least two different versions for Windows that I know of. The one mentioned previously by APsoft and another from the Metasploit project.

APsoft's memdump will do any or all of memory.

MEMDUMP/386 for DOS Version 2.00 - Release 15-Jun-2005
(C) Copyright 1993-2005 by APSoft (http//www.tssc.de)
All rights reserved. Disassembly or decompilation prohibited.

Please remember that if the memory manager (such as EMM386.EXE) is
loaded, MEMDUMP will read linear address rather as physical address.
There is almost no help for the Metasploit memdump. It dumps specific processes by giving it a PID and creates quite a few files that are to be analyzed with msfpescan. The file names looks to be based on the section of memory it is pulled from. Msfpescan is crashing on my Mac OS X box right now so can't show you the output but here is the syntax and sample of memdump running.


C\>y\memdump.exe
Usage y\memdump.exe pid [dump directory]

C\>y\memdump.exe 2796
[*] Creating dump directory...2796
[*] Attaching to 2796...
[*] Dumping segments...
[*] Dump completed successfully, 49 segments.

Then, there is pmdump that also dumps processes.


pmdump 1.2 - (c) 2002, Arne Vidstrom (arne.vidstrom@ntsecurity.nu)
- http//ntsecurity.nu/toolbox/pmdump/

- lists all running processes and their PID's

Microsoft has several versions of userdump but I think the latest is version 8.0 and is less than a month old. As with Metasploits memdump, there is another tool that can read the dumped output. Dumpcheck is that tool and is part of the debugging tools package. For it to be most useful, you need the symbols, also.


User Mode Process Dumper (Version 8.0.2826.0)
Copyright (c) 1999-2005 Microsoft Corp. All rights reserved.

-d <TargetDumpPath> supplies the directory where the dumps will go.
The default is a current directory of the target process.

That's it that I can think of for now. I will probably remember the other one or two tonight. Hope all that helps give you some direction and a realization that there is no specific way to analyze memory, but quite a few people are interested and several smart people are doing some excellent research into the area.

X-ways Capture http//www.x-ways.net/capture/index-m.html is another option for live system data.

The original request was for Open Source software to image RAM. The list I provided may not have all been Open Source but they were all free. X-Ways Capture is neither, and for an imager, it is a little pricey (EUR 249.90 / USD 313).

Sorry, didn't read the question!

Mariusz Burdach has recently released a public version of Windows Memory Forensic Toolkit (WMFT), currently only available from Rootkit.com.

Make sure you read his paper and BlackHat presentation linked in my earlier post.

Have you tried using the WMFT yet?

Harlan

Yes, unfortunately, I can't go into detail right now as I am on an afternoon break at a SANS conference. Hopefully, tonight, I will have time to give you more details.

On a related note, I just saw TRUMAN, from LURHQ and Joe Stewart, in action. I had been playing with the pmodump.pl tool (it is part of the project) that works along the same lines as wmft but does not get stuck processing the BLINK/FLINK that can be fudged by the FU rootkit.

TRUMAN is a pretty darn cool framework for creating sandnets for malware analysis. I highly recommend checking it out so you don't run into the pitfalls of malware recognizing you are running inside a virtual machine.

BTW, if any of you have not heard of Joe Stewart, he is by far one of the best malware analyst out there.