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.
This program dumps or copy any part of 4GB memory address space of your system.
For proper access to hardware registers, memory can be read with BYTE, WORD or
Double WORD granularity.
Syntax: MEMDUMP [/H|?]
[/D[B|W|D][:Address[,Length]]]
[/F:filename|none]
[/B:filename]
where: /H - Print this text
/D[B|W|D][:Address[,Length]]
- Dump <Length> number of memory bytes from specified
linear <Address> as bytes (DB), words (DW) or
double words (DD) correspondingly.
/F:filename - Output file for the dump (Default: console)
Use /F:none to completely suppress dump
/B:filename - Output file for the binary contents of memory
Notes: Both 'Address' and 'Length' can be expressed in hexadecimal format
with '0x' prefix. The 'Length' field can be also expressed in decimal
Examples:
MEMDUMP /DW:0x100000,0x100000 /F:2ndMB.dmp - dump second MB to file
MEMDUMP /DB:0x100000,128 - dump 128 Bytes to CON:
MEMDUMP /D:0,0x100 /F:none /B:IntTB.bin - copy INT table to file
If dump or binary file exists, MEMDUMP unconditionally overrides it.
If you are using WORD or DWORD access 'Length' parameter should be
multiple of 2 or 4 correspondingly.
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/
Usage: pmdump <pid> <filename>
- dumps the process memory contents to a file
pmdump -list
- 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.
userdump -p
Displays a list of running processes and process IDs.
userdump [-k] <ProcessSpec> [<TargetDumpFile>]
Dumps one process or processes that share an image binary file name.
-k optionally causes processes to be killed after being dumped.
<ProcessSpec> is a decimal or 0x-prefixed hex process ID, or the
base name and extension (no path) of the image file used to create
a process.
<TargetDumpFile> is a legal Win32 file specification. If not specified,
dump files are generated in the current directory using a name
based on the image file name.
userdump -m [-k] <ProcessSpec> [<ProcessSpec>...] [-d <TargetDumpPath>]
Same as above, except dumps multiple processes.
-d <TargetDumpPath> supplies the directory where the dumps will go.
The default is the current directory.
userdump -g [-k] [-d <TargetDumpPath>]
Similar to above, except dumps Win32 GUI apps that appear hang.
userdump -I [-d <TargetDumpPath>]
To change just in time debugger to UserDump.
This command will not actually start UserDump.
If you don't setup userdump, please copy userdump.exe to %windir%\system32.
-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.
No comments:
Post a Comment