No need to guess or experiment with different profiles, let Volatility figure that out for you. In testing, this worked with all formats that Volatility supports. If you were the one to do the memory dump or if the file was labeled OS information, this wouldn’t be a concern or a needed step. To let the magic happen, follow the below.

This analyzes the memory capture metadata and displays which profile is suggested to be used.

forensics@sift: vol.py -f /location/of/my/image.raw imageinfo

The output will be something similiar to this:

	Volatility Foundation Volatility Framework 2.3.1
	Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP0x64, Win7SP1x64, Win2008R2SP0x64, Win2008R2SP1x64
                     AS Layer1 : AMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/home/sansforensics/Desktop/WIN7-NO-PATCH-20150107-041118.raw)
                      PAE type : No PAE
                           DTB : 0x187000L
                          KDBG : 0xf80002a470a0
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0xfffff80002a48d00L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2015-01-07 04:11:26 UTC+0000
     Image local date and time : 2015-01-06 23:11:26 -0500

From the above example, you see it suggests four different ones to use. I always go with the first one and usually don’t have a problem. If there is no suggestion, it is because the profile doesn’t exist and may require you to build a profile based on the kernel of the system the memory capture came from.

Next, we will be using the following syntax to run the profile with the memory capture. At the end of the syntax, I used ‘info’ to display all the plugins and scanners that can be used.

forensics@sift: vol.py -f /location/of/my/image.raw --profile=Win7SP0x64 info