Posté par: igor51 le août 09, 2019, 01:00:47
Deep Dive
Introduction
This blog post is the second in a three-part series covering our
Windows 10 memory forensics research and it coincides with our
USA 2019 presentation. In
One of the series, we covered the integration of the research in
both Volatily and
that forensic artifacts (including reflectively loaded malware) could
remain undiscovered without the FLARE research integration on Windows
10 (available on GitHub at
and win10_rekall).
In this post, we demonstrate how to retrieve a compressed page using
the structures and algorithms described in our
paper. We track down a compressed page in memory, beginning at its
virtual address within a known process. A
walkthrough, but a similar process could be followed from within a
memory snapshot or extraction using
Finding a Compressed Page
The operating system used in this demo is Windows
10.0.15063.0 (x64) and the structure definitions shown will
be applicable across any 1703 build. Note
that the two global offsets nt!SmGlobals and
nt!MmPagingFile will need to be located
for each revision. The process of retrieving these global offsets is
described further in our
To begin analysis, we create a marker page and flush it to the
Virtual Store. This can be done in several ways, the easiest of which
is allocating memory in a memory constrained virtual machine. A
simple utility (ram_eater.exe) was created
to perform this task. The ram_eater utility
allocates and writes a marker page, and then repeatedly allocates more
memory in user-specified page amounts. In a memory constrained virtual
machine (1 GB RAM), the marker page will become stale shortly and be
evicted to the virtual store. In Figure 1,
page at address 0x2a368480000. The marker
page we used (see Figure 2) was a string beginning with “
Figure 1: Allocating a marker page using ram_eater_x64.exe
We can verify the contents of our marker page by locating it in the
kernel debugger, viewing its Page Table Entry (PTE) and dumping its
corresponding physical memory (see Figure 2). We use the
structure and switch into the context of the
the correct process-specific page tables for the
(pfn) described by the hardware PTE, we
dump the physical memory to validate the contents of our marker page.
Page frame numbers do not include the low-order bits used to specify
an offset into a page, therefore they must be multiplied by
identify the actual address of the data.
Figure 2: Locating and viewing the marker
page from the kernel debugger
After allocating additional memory using
been sent to the virtual store. Each entry in the output of the
nt!MmPagingFile (see Figure 3).
Figure 3: PTE of a compressed page in the
virtual store an confirmation of virtual store’s PageFile index
In the PTE displayed in Figure 3, the PageFile index (
to the “No Name for Paging File” entry in the
we know that on a default Windows configuration, the last entry
corresponds to the virtual store. It is possible to configure systems
with more than a single PageFile on disk, so do not assume that
PageFile index 2 will always correlate to the virtual store.
A more thorough option to validate page file indices is to
disassemble nt!MmStoreCheckPagefiles. This
function contains references to two global variables, the number of
active PageFiles, as well as an array of pointers to each
the PageFile structure’s newly introduced
PageFile represents a virtual store.
Figure 4: Locating nt!MmPagingFile in
WinDbg and dumping system’s nt!_MMPAGING_FILE structures
Having confirmed that the marker page is in the virtual store, the
next step is to calculate the Store Manager Page Key (
locate the decompressed page. Our
paper details the process used to calculate the
not use the PTE’s swizzle bit in the page key calculations, since the
OS build is below 1803. To begin page retrieval, the pointer to the
Store Manager’s global structure or
straightforward process if symbols are available (see Figure 5).
Figure 5: Dumping nt!SmGlobals
The first thing to observe is that both
are located at offset 0x0, or directly at
nt!SmGlobals. Viewed as a memory dump,
nt!SmGlobals appears as an array of
pointers. Viewed as a two-dimensional array (32x32) of
array of pointers points to an array of 32
To locate our SM_PAGE_KEY’s corresponding
store, we need to find the store index associated with the page key
inside the SMKM_STORE_MGR.sGlobalTree B+tree
container. The store index is a compound value that yields both
indices needed to select the particular
SMKM_STORE_MGR’s global B+tree (Figure 6).
Recall that we are interested in a store manager page key value of
0x201a3061.
Figure 6: Traversing the global B+tree
Now that we have the store index (obtained from the
indices to select the correct
the result of dividing the retrieved store index by 32, while the
second one is the remainder of the division operation. In our case
both indices are 0 and they select the first of the 1024 stores on the
system, which is reserved for legacy applications. Universal Windows
Platform (UWP) applications, on the other hand, will be placed in
stores from 1 to 1023. Now, with the
SMKM_STORE structure, as shown in Figure 7.
Figure 7: Dumping the SMKM_STORE structure
Once we have our SMKM_STORE structure we
traverse another B+tree that associates our
with a chunk key. The chunk key is a compound value and once decoded
points to a specific page record inside
in Figure 8.
Figure 8: Traversing the local B+tree to
find the chunk key associated with the SM_PAGE_KEY
After the B+tree traversal is complete we found that our chunk key
is 4b02d. Since it’s a compound value we
need to decode it in order to retrieve the two indices into
offset within the located chunk. The decoding involves four additional
SHMP_CHUNK_METADATA fields –
Figure 9.
Figure 9: Retrieving the page record
associated with the chunk key
The decoding of the chunk key in Figure 9 allowed us to find all the
information to derive the virtual address of our compressed page. The
retrieved REGION_KEY (
that encodes the index within the
offset within the region of pages. To calculate this data, we parse
the region key with the help of two fields inside the
Figure 10.
Figure 10: Calculating the compressed
page’s virtual address
The virtual address 0x12f3970 calculated
in Figure 10 contains the compressed page of interest. We can retrieve
it from the MemCompression process space, as
shown in Figure 11. To confirm that the compressed memory is located
within MemCompression, check the
Figure 11: Retrieving the compressed page
from within MemCompression process space
The compressed page can be decompressed with a call to the
implementation that supports the XPRESS
compression algorithm.
Conclusion
In this blog post, we shared a walkthrough in which we forced a
known marker page into the compression store and manually retrieved it
by walking through memory dumps using known structure offsets from
Windows 10 1709 x64. The same techniques used here can be applied to
Windows 10 1607 and onwards assuming
correct structure offsets are known. In Part 3 of the series,
Undocumented Structure Extraction, we will look at how the
FLARE team leveraged emulation via flare-emu to automate the
extraction of the structures used in this walkthrough.
Resources
paper
Evil in Windows 10 Compressed Memory, Part One: Volatility and
Rekall Tools
Evil in Windows 10 Compressed Memory, Part Three: Automating
Undocumented Structure Extraction
FLARE Windows
10 Volatility Plugin
FLARE Windows 10
Rekall Plugin
Source: Finding Evil in Windows 10 Compressed Memory, Part Two: Virtual Store
Deep Dive (http://)