MEMORY FORENSICS

How Windows
Memory Forensics Tools Work
• Although tools exist for automatically extracting
useful information from memory dumps, it is
important for digital investigators to understand the
data and associated structures they are dealing with.
• Knowing how a tool obtains certain information can
help digital investigators verify that a tool
is providing accurate information, explain the
information, identify shortcomings, and locate the
information manually when a tool does not function
correctly.
 Virtual Memory Addresses
• A fundamental aspect of memory analysis is that the
locations of data used by the operating system are not the
same as the physical locations needed to locate data in a
memory dump.
• Because there is generally insufficient physical memory to
contain all running processes simultaneously, the
Windows operation system must simulate a larger
memory space.
• This is achieved by creating a virtual address space for
each process that is translated to physical storage
locations through a series of data structures.
• The main data structures are the page
directory and page table.
• Therefore, to locate data in a memory dump,
it is often necessary to translate virtual
addresses into physical addresses as follows:
• The procedure of locating and reading a Page
Directory Entry (PDE) to find the Page Table Entry
(PTE) of interest, is demonstrated here for the
Process Environment Block (PEB) of the “[Link]”
process in the FUTo rootkit scenario.
• The PEB for a process contains useful information,
such as the location of the associated executable
in memory and the process environment,
including command-line arguments and
associated DLLs.
• The EPROCESS structure for the “[Link]” process
conveniently provides the physical location in memory
where the page directory starts (0x0a039000).
• The virtual address of the PEB (0x7ffdf000) is also
contained in the EPROCESS structure. This
equates to 01111111111111011111000000000000 in binary.
the most significant 10 bits of this virtual address tell us that
the 511th entry in the page directory is associated with the
PEB.
• The next most significant 10 bits tell use that the 991st
entry in the page table is associated with the PEB.
• The fact that the DTB address is provided as a physical location, means
that we start the address translation process by simply going to that
location in the memory dump.
• Then we need to skip to the 511th entry. Because each entry in the page
directory is 4 bytes in length, the physical location in
• the memory dump of the 511th directory entry is 0x0a0397fc
(0x0a039000 + 0x1ff * 4).
• The 511th entry in the DTB contains the data 0x0a102067, the 4 most
significant bytes of which is the page table base address (0xa102). Because
each page table is 4096 bytes, the location of this page table is
0x0a102000 (0xa102 * 0x1000).
• Therefore, the physical location in the memory dump of the 991-page
table entry is 0x0a102f7c (0xa102 * 0x1000 + 0x3df * 4).
• The 991st entry in the page table contains the data 0x0a0eb067, the 4
most significant bytes of which is the physical location of the PEB
(0x0a0eb000).
 Processes and Threads
• Every process running on a Windows computer has an associated
EPROCESS structure in memory, that contains metadata about that
process, including the executable name, the PID, the start time, the exit
time, and pointers to associated data and related data structures in
memory.
• Each EPROCESS structure contains, among other things, a reference to
the previous and next running process.
• One approach to obtaining a list of running processes is to follow each
link in the process chain, starting with the System process.
• However, malware can break this chain by simply changing the
references in the EPROCESS structure to skip over certain processes in
the chain, thus hiding them from non-forensic tools. This concealment
method is called Direct Kernel Object Manipulation (DKOM), and is
commonly used by rootkits.
• For instance, the FUTo rootkit alters the linked list of
processes to skip over hidden processes.
• the physical location of their EPROCESS structure in the
memory dump, along with the location of the next and
previous EPROCESS structures they are linked with.
The first three processes listed below exhibit a normal linked
arrangement with “[Link]” linking forward to “[Link]”
and backward to “[Link].”
Conversely, the hidden processes “[Link]” and “[Link]”
have their forward and backward links reset to refer back to
themselves.
• Now let’s combine the information in Figure 3.6 and Table 3.3 to determine some of the process
details.
• on a Windows XP system with Service Pack 2, the creation time of the process is a 32-byte
FILETIME value at offset 0x70 (112 bytes).
• The PID is generally at offset 0x84(132 bytes), but has been zeroed out by the FUTo rootkit, as can
one line below the creation time.
• The parent PID, identified for the process that spawned the “[Link]” process,is located at offset
0x14c (332) and is 0x019c (412), which is the PID for “[Link],” as can be seen in the Volatility
psscan output earlier in this chapter.
• The name of the process is at offset 0x174(372 bytes.
• The virtual address of the PEB for the hidden process “[Link],” is located at offset 0x1b0, which is
on the last line of Figure 3.6, and has a value of 0x7ffdf000 (physical address 0x0a0eb000).
• The PEB contains a number of structures, some of which are depicted in Figures 3.7a and 3.7b,
that provide valuable information about the process, such as command-line parameters, associated
DLLs, and the location of the executable in memory (ImageBaseAddress).
 Recovering Executable Files
• In a malware incident, when a suspicious process has been
identified on a subject system, it is often desirable to extract the
associated executable code from a memory dump for further
analysis.
• it can be difficult to recover a complete executable file from a
memory dump.
• To begin with, an executable changes when it is running in memory,
so it is generally not possible to recover the executable file exactly
as it would exist on disk.
• Pages associated with an executable can also be swapped to disk, in
which case those pages will not be present in the memory dump.
• Furthermore,malware attempts to obfuscate itself, making it more
difficult to obtain information about its structure and contents.
 the most basic process of recovering an executable is as follow

• 1. Read PEB structure to determine the address

where the executable begins.
• 2. Go to the start of the executable and read the PE
header.
• 3. Interpret the PE header to determine the location
and size of the various sections of the
executable.
• 4. Extract the pages associated with each section
referenced in the PE header, and combine them into
a single file.
PEB OF SKL PROCESS
• Harlan Carvey developed a utility called
“[Link]” to interpret the PEB in Windows
2000 memory dumps.
• The output of “lspd_xpsp2.pl” for the hidden
process “[Link]” in the FUTo rootkit scenario is
provided here, including details from the PEB
such as the physical location of the executable in
memory is 0x0a198000
• Going to this physical location in the memory dump using a hex viewer,
reveals the PE header for the executable and what appears to be UPX
packing .
• The PE header generally specifies the location of the various sections of
the executable, which can be used to recover additional
• components of the executable.
• To interpret the PE header, it is necessary to extract the page that
contains the header, recalling that each memory page is usually 4096
bytes, and view its contents with a PE viewing tool.
• The following command skips the first 41368 memory pages (169443328
bytes/4096), and copies one page into a file named “skl-peheader.”
• # dd if=[Link] bs=4096 skip=41368 count=1 of=skl-
peheader