2.6 Win Profiles
Clone this wiki locally
TL;DR / Quick Start
When analyzing memory from Windows 7 or later, use the following guidelines for selecting the proper profile:
- If you know the target machine's build number (obtained from a live machine or metadata preserved by memory collection tools), see the
Buildcolumn of the table below to choose the proper profile name.
- Otherwise, try to determine the time period when the memory was collected and whether you think the target system was receiving Microsoft updates. Look up that date in the table below to help choose relevant profiles to try.
- If all else fails, run kdbgscan to obtain profile suggestions, and consider those in conjunction with other information the plugin outputs, such as major/minor build numbers, the build string, and the number of processes/modules.
Long-time Volatility users will notice a difference regarding Windows profile names in the 2.6 release. In particular, we've added a new set of profiles that incorporate a Windows OS build number in the name, such as
10.0.14393.0. The addition of these profiles aims to support the growing frequency at which Microsoft changes critical data structures for bug fixes, security updates, and feature enhancements. This mainly applies to Windows 7 and later. If you've been keeping up with our code base, in the recent months leading up to the release, you may have seen profiles named according to the PDB GUID from certain versions of the Windows kernel file (i.e.
Win10x64_1AC738FB). We've decided to drop the PDB naming convention in favor of the aforementioned build number format. The following sections cover what you need to know regarding these new profiles, including when to use them and how to choose them.
In most cases, operating system patches only change a few data structures at a time. Thus, a majority of Volatility plugins may continue operating just fine when you run them against a memory sample collected from a recently patched system. However, the select few that rely on the changed structures will report incomplete in incorrect results. Here's a list of common indications of using the wrong profile.
- pslist succeeds in enumerating processes, but the process names appear mangled. You may see part of the legitimate process name near the end, for example
- psscan doesn't locate any processes
- filescan doesn't locate any files
- hivelist doesn't locate any registry hives
- vadinfo output appears mangled
Albiet rare, some patches will break Volatility's ability to identify a DTB address (required for virtual address translation) and no plugins will work at all. If you experience any of these issues, consult the table below to identity the proper profile.
This table summarizes the new profiles added in Volatility 2.6. For example, if you have a 64-bit Windows 10 memory sample and the standard
Win10x64 profile exhibits symptoms referenced above, you may need to use one of the new ones. Although there are only a few possibilities per major OS release, and trying them all in sequence wouldn't take terribly long, you can expedite the process if you know the target system's build number or have a rough estimate of when it was last fully patched. This information is readily available if you can access the running machine. Otherwise, some memory acquisition tools, such as Volexity Surge Collect Pro, record the necessary metadata along with the memory capture, thus preserving it for you.
The build numbers and dates in the table do not indicate that the corresponding profiles /only/ work with that single build of Windows. For example,
Win10x64_10586 will likely work for all builds between 10.0.10586 from 2016-04-23 and 10.0.14393 from 2016-07-16.
|2008 R2 SP1 x64||6.1.7601.23418||2016-04-09||632B36E0||Win2008R2SP1x64_23418|
|2008 R2 x64||6.3.9600.18340||2016-05-13||54B5A1C6||Win2012R2x64_18340|
|7 SP1 x64||6.1.7601.23418||2016-04-09||632B36E0||Win7SP1x64_23418|
|7 SP1 x86||6.1.7601.23418||2016-04-09||BBA98F40||Win7SP1x86_23418|
If you're still unable to process memory images with Volatility 2.6 after reading these instructions, feel free to get in touch via the Vol-Users mailing list or the GitHub issue tracker. Please have as much of the following information as possible ready:
- The tool used to collect memory
- As much information on the target machine's version as possible (Windows version, 32 vs 64 bit, size of memory)
- What you've tried so far (command line options used and example output, if any)
Please note that using these new profiles is not a remedy for corrupt or incomplete memory captures.