All memory dumping tools are not the same

<DISCLAIMER: I am not an in-depth technical expert on memory analysis, and your results and analysis may vary>

A few days ago, Takahiro made a blog post regarding some issues that he discovered while processing a 16GB memory dump on a Windows 7 machine (if you have not read the post, you can find it here). Naturally the findings Takahiro described in his post were concerning since we, as first responders, are often required to gather memory (through a variety of methods) and if Microsoft is * encrypting portions of RAM that will ultimately hamper our analysis, the methods that we use to gather RAM should be adjusted accordingly.

*COMMENT: The volatility crew released a blog post yesterday that did confirm encoding (not encrypting) does occur in some 64 bit dumps, and the method that your tool of choice uses to create the memory dump will determine if the debug block will be decoded or not.

I had access to one Windows 7 machine with 16GB of RAM, but in order to cover as many bases as possible (as so many of us do), I relied on collaboration (in this case with Mari DeGrazia), who had access to Windows 7 devices with 16GB of memory as well. Mari acquired her memory dumps using the free version of DumpIt (v1.3.2.20110401), Belkasoft RAMCapture 64, and FTK Imager 3.1.4.6. I acquired my system with the paid version of Moonsols DumpIt (v2.0.0.20130823), the free version of DumpIt (v1.3.2.20110401), Belkasoft RAMCapture 64, and FTK Imager 3.1.4.6.

On all of the memory dumps, regardless of the tool that was used to create the dump, the "imageinfo" processed the dumps for a long period of time (I finally cancelled the processes after 2 hours, Mari had similar results). This is likely because of how volatility currently processes the  image information scan, which involves some initial kdbg (KdDebuggerDataBlock) searching, as the kdbgscan itself worked fairly quickly on all of the images except for the one created by the free DumpIt tool.

"imageinfo" running for over two hours, with no results = sad panda :(

On the Windows 7 machines, we found, when we used the appropriate profile (Win7SP1x64 in this case) that FTK Imager and RAMCapture64 created a memory dump that was processed with no issues using volatility 2.3, and my findings were that the paid version of the Moonsols tool produced a dump that was processed with no issues as well. However, the free Moonsols tool produced a memory dump that was unable to be processed with the default volatility settings, as well as being unable to be processed while giving volatility some of the more robust options as well. (COMMENT: Make sure if you are manually inputting the kdbg offset, you are using the "virtual" location(s), as the "physical" location will not provide good (if any) results)

The reason for this is likely that volatility, in its current state, attempts to find the kdbg and as soon as it finds a signature match, it uses that location to determine the profile type and other items within the memory dump. It also provides the operating system profile that is given by the examiner to volatility to extract information from the various volatility plugins. It is possible for volatility to detect the "wrong" profile as it currently searches for the kdbg information based on a signature search (in fact, this is currently being worked by the volatility team, and has been identified as a possible issue (one example is here)).

With the free DumpIt tool, even the in-depth options of manually specifying the kdbg location, volatility still did not produce any results from the memory dump. This may be because the free DumpIt reads the memory differently than other tools (that is likely, as all memory dumping tools are not the same) and aligns perfectly with the results that Takahiro, Mari, and I encountered. Below are the results of kdbgscan and pslist from the memory dumps created by each tool:

kdbgscan from free Moonsols DumpIt memory dump

kdbgscan from paid Moonsols DumpIt memory dump

kdbgscan from FTK Imager memory dump

kdbgscan from Belkasoft RAMCapture memory dump

pslist from paid Moonsols DumpIt memory dump

pslist from FTK Imager memory dump

pslist from Belkasoft RAMCapture memory dump

pslist: Free DumpIt, kdbg specified, no good results

netscan: Free DumpIt, kdbg specified, no good results

So, for now, the best recommendation that we can make is to know and understand your tools and their limitations. While you may not need to know the exact API and methodology that each tool uses, you should be aware that in some cases some tools produce better results than others. I personally like the Belkasoft RAMCapture tools, but always make sure that I have additional tools (Moonsols, FTK Imager, f-response, etc.) on hand if I encounter issues while creating a memory dump. As when it comes to imaging a hard drive, the "usual" way is good, but always make sure that you have some other options, just in case.

One more item of interest that I encountered is that, on a properly patched/updated Windows 7 system and later (including Windows 8), the OS now prevents writing to the Windows/System32 folder from a command line entry (even with administrative privileges) without other, external factors. So, for example, a batch scripted collection using DumpIt (free and paid version, although the free version does not work on Windows 8) will cause an error and the memory will not be collected. If you click on the icon for the DumpIt executable the operation works perfectly, but be aware if you are trying to use DumpIt with a batch script or running the program from the command-line.

Cannot find C:\Windows\system32\DumpIt.sys

This is likely an issue that will continue to pop up as the size of RAM increases and the tools that we currently to acquire memory, as well as analyze memory, continue to evolve. We are just scratching the surface on this topic and there are sure to be more posts on this subject in the future!