1

I have been trying to use Volatility 2.6 to analyze memory dumps generated by DumpIt. I am experiencing an issue analyzing the memory dumps (all 4 GB in size) of two Windows 10 64 bit boxes (build numbers 18362.1 and 18362.476) and a Windows Server 2016 64 bit box (build number 14393). When running the below command to get the profile: 

volatility -f memory_dump.dmp imageinfo

I get the below output:

INFO    : volatility.debug    : Determining profile based on KDBG search...
WARNING : volatility.debug    : Alignment of WindowsCrashDumpSpace64 is too small, plugins will be extremely slow
WARNING : volatility.debug    : Alignment of WindowsCrashDumpSpace64 is too small, plugins will be extremely slow

The above lines continue and it just hangs for about an hour before it shows the profile info. Even after loading the profile info, if I try commands such as 'pslist' and 'pstree' it loads right away but there are no processes returned in the output.

I also tried using FTK Imager to generate the memory dumps but when trying to analyze it in Volatility it hangs at the below line:

INFO    : volatility.debug    : Determining profile based on KDBG search...

I have tried using both the Volatility 2.6 binary in Windows 10 and the latest vol.py in Ubuntu 18.04 but I am experiencing the same issue.

However, I do not experience any issues with Windows 7 (32 bit) and Server 2008 (32 bit) memory dumps (both 4 GB in size) and Volatility loads the profile info within a few seconds. Also, when running the 'pslist' and 'pstree' commands, the output returned contains processes. Volatility also does not output any alignment errors (which were displayed for the Windows 10 and Server 2016 memory dumps).

Is there a way to address the problem experienced when analyzing Windows 10 and Server 2016 memory dumps?

synthesis
  • 155
  • 1
  • 1
  • 15
  • Hmm, maybe there's a problem with the file itself. What's the output of `file memory_dump.dmp` ? – Sir Muffington Nov 17 '19 at 14:48
  • The output is: MS Windows 64bit crash dump, full dump, 1013425 pages – synthesis Nov 17 '19 at 17:15
  • Hm, what memory formats are the generated files? Try running `binwalk` on the image to get more info and post the output. Also check this out: http://wiki.yobi.be/wiki/RAM_analysis – Sir Muffington Nov 17 '19 at 18:51
  • P.S How long did you try waiting? It should take quite a wee bit of time – Sir Muffington Nov 17 '19 at 18:52
  • How do you determine the memory format? The binwalk output can be found here: https://drive.google.com/open?id=1VmsSIwfZd7cIG0hgWWHSjY-I2Qja58MM. I had to wait 1 hour before it loaded the profile info. However, for Windows Server 2008 (32 bit) it loads the profile info within a few seconds. – synthesis Nov 18 '19 at 11:24
  • Volatility code is trying to check that the memory ranges are aligned and for some weird reason it tries to make the tests assuming it deals with a 32-bit system. I think it's very similar or related to the aff4_map library bug. Try getting the fixed version of the aff4imager binary. – Overmind Nov 18 '19 at 12:54
  • @Overmind which version is the fixed version for Volatility? – synthesis Nov 18 '19 at 14:19
  • https://github.com/google/aff4/commit/d819e42989c8caa22b0efd624b4282b7d00e4ca7 Git clone it and install the py module (from aff4/pyaff4/) with py setup.py install. This will update the aff4 library to the fixed version. – Overmind Nov 19 '19 at 06:24

0 Answers0