Matthieu Suiche, 13th February 2009
matt[0x40]msuiche[0x2E]net
http://www.msuiche.net
Physical Memory (also known as RAM) contains various types of volatile information. Each time an application is launched a copy of it is loaded into the physical memory; this includes the physical application as provided on the hard drive and also temporary memory buffers used by the application during its execution. Physical memory analysis is very valuable for incident response analysis because investigators are able to collect information they won’t be able to collect on hard drive during an analysis on a “dead” system. Live system analysis has several notable advantages compared to classical hard drive analysis. Moreover, investigators who proceed to an analysis of a physical memory snapshot can use several external tools that do not modify the contents of the physical memory state unlike launching tools on an running Operating System.
Win32dd is an open-source tool to provide an efficient way to acquire physical memory in two different formats. The first format is the most common, output file is a raw format and contains the exact content of the physical memory; the second format is the one used by Microsoft to generate a crash dump file. This feature aims at providing users a compliant format used by Microsoft debugging and troubleshooting tools like Windows Debugger (WinDbg).
Raw memory dumps
Raw physical memory snapshots are widely used in the forensics industry and also by memory acquisition tools even if they are not the most powerful to proceed to an efficient analysis regarding common things like process listing, modules listing, drivers listing and so on. As the name suggests this is a raw dump of the full physical memory usually called \Device\PhysicalMemory by Windows section objects.
From a developer point of view, it is very important to notice that classical (user-mode) memory imaging tools cannot proceed to a physical memory snapshot because Microsoft decided to block access to the \Device\PhysicalMemory object from user-land applications for security reasons as we can read on the Microsoft Developer Network website[2].
“In Windows Server 2003 SP1, user-mode access to the \Device\PhysicalMemory object is not permitted. All forms of access (read, write) are refused when the \Device\PhysicalMemory object is accessed from a user-mode application. Access to the \Device\PhysicalMemory object is refused regardless of the user context (Administrators, Users, Local System, etc.) the application is running in.”
This part explains why additional privileges are required from investigators to access to the Windows physical memory under an operating system version higher to Windows Server 2003 because of the need to load a kernel-land module to access to this specific object section.
Pros This dump file type contains the exact physical memory content; physical offset aligned on file offset.
Cons Lack of additional information like processor state control registers that are mandatory to emulate Windows memory management, especially virtual to physical address translation[3].
Microsoft crash dump file
Physical memory acquisition is used for post-mortem debugging purposes, security purposes (e.g. rootkit analysis, information extraction and so on.). It is mainly known because of the Microsoft feature called “Blue Screen of the Death” (BSOD) that generates a crash dump file. There are three different types of crash dump files: small memory dump, kernel memory dump and complete memory dump.
This article only covers complete memory dumps.
Complete memory dump is the most useful memory snapshot for advanced analysis because it contains the full physical memory including both user-land and kernel-land space. It can be easily used, for example, to unpack code for both user-land and kernel-land applications.
Pros This is a full memory snapshot of pages used by Windows Memory Manager this includes both user-land and kernel-land. It means both malwares and rootkits analysis can be done.
Cons This option might not be available on computers that are running a 32-bit operating system and that have 2 gigabytes (GB) or more of RAM according to Microsoft KB 274598[4].
Here is Microsoft crash dump header in a 32-bit format:
typedef struct _DUMP_HEADER32 {
/* 0x000 */ ULONG Signature;
/* 0x004 */ ULONG ValidDump;
/* 0x008 */ ULONG MajorVersion;
/* 0x00C */ ULONG MinorVersion;
/* 0x010 */ ULONG DirectoryTableBase;
/* 0x014 */ ULONG PfnDataBase;
/* 0x018 */ PLIST_ENTRY PsLoadedModuleList;
/* 0x01C */ PLIST_ENTRY PsActiveProcessHead;
/* 0x020 */ ULONG MachineImageType;
/* 0x024 */ ULONG NumberOfProcessors;
/* 0x028 */ ULONG BugCheckCode;
/* 0x02C */ ULONG BugCheckParameter1;
/* 0x030 */ ULONG BugCheckParameter2;
/* 0x034 */ ULONG BugCheckParameter3;
/* 0x038 */ ULONG BugCheckParameter4;
/* 0x03C */ UCHAR VersionUser[32];
/* 0x05C */ UCHAR PaeEnabled;
/* 0x05d */ UCHAR KdSecondaryVersion;
/* 0x05e */ UCHAR Spare3[2];
/* 0x060 */ PKDDEBUGGER_DATA64
KdDebuggerDataBlock;
union {
/* 0x064 */ PHYSICAL_MEMORY_DESCRIPTOR32
PhysicalMemoryBlock;
/* 0x064 */ UCHAR
PhysicalMemoryBlockBuffer[700];
}
union {
/* 0x320 */ CONTEXT Context;
/* 0x320 */ UCHAR ContextRecord[120];
}
/* 0x7d0 */ EXCEPTION_RECORD32 Exception;
/* 0x820 */ UCHAR Comment[128];
/* 0x8a0 */ UCHAR _reserved0[1768];
/* 0xf88 */ ULONG DumpType;
/* 0xf8c */ ULONG MiniDumpFields;
/* 0xf90 */ ULONG SecondaryDataState;
/* 0xf94 */ ULONG ProductType;
/* 0xf98 */ ULONG SuiteMask;
/* 0xf9c */ ULONG WriterStatus;
/* 0xfa0 */ LARGE_INTEGER RequiredDumpSpace;
/* 0xfa8 */ UCHAR _reserved2[16];
/* 0xfb8 */ LARGE_INTEGER SystemUpTime;
/* 0xfc0 */ LARGE_INTEGER SystemTime;
/* 0xfc8 */ UCHAR _reserved3[56];
} DUMP_HEADER32, *PDUMP_HEADER32;
Win32dd
We need to have both win32dd.exe and win32dd.sys in the same directory. Moreover, we also need administrator rights and enough permission to load the driver.
Here is the output of the help option:
