Windows Hibernation files from a hibernated (or sometimes simply shutdown) machine can be a wealth of information in investigations, often containing a nearly complete memory image of what was running on the system prior to hibernation (shutdown). For years, many in the DFIR community have pillaged the hibernation file for a variety of artifacts, ranging from extraction of simple strings to the use of more specialized analysis tools like Mathieu Suiche’s Hibr2Bin and Volatility. However, since Windows 8, you may (or may not) have noticed that the number of artifacts extracted by the usual methods have at times ranged from substantially less to nearly nonexistent.

So, what gives? Does Microsoft simply no longer store (as many) artifacts in there anymore? I mean, if our trusted tools can’t identify/extract it, it’s surely not there, right? Well, while it would be easy to simply move on and accept the loss of artifacts, I’d like to take the time to dig a bit deeper and find out what is going on here.

Background

Windows hibernation files are compressed at shutdown. Starting in Windows XP, Microsoft began using the Xpress compression algorithm with a defined data structure of which many tools (including the aforementioned Hibr2Bin and Volatility) had down pat to properly decompress and extract/display the contained artifacts. However, beginning in Windows 8/Server 2012, Microsoft changed things up, namely adding a Huffman encoding variant and changing the data structures a bit. This, in turn, rendered existing decompression tools severely hindered without a rewrite to account for the changes. As of this writing, while it appears there is some work in progress to update both Hibr2Bin and Volatility to update the decompression methods, neither of these tools can successfully fully decompress Windows 8+ Hibernation files. Though, I believe the DFIR community eagerly awaits updates to these tools as they have both proven to be incredibly useful in their own respects.

== Sidebar ==

For those interested in the nitty gritty details of Windows hibernation files, refer to Joe T Sylve, Vico Marziale, and Golden G. Richard III’s excellent paper titled “Modern windows hibernation file analysis” that describes in great detail the various Windows hibernation file formats/structures, along with their testing methodology using Hibr2Bin to attempt to decompress each Windows version’s hibernation files. You will see the issue of the changed compression structure evident in their testing with Hibr2Bin in that they saw it only produced a subset of expected decompressed artifacts and “surmised that Hibr2Bin must only decompress the first restoration set of pages that are restored by the boot loader, ignoring the second set of kernel-restored pages.” We can assume the same and/or similar issue(s) of not yet being able to properly read and entirely parse the new data structures also apply to Volatility.

== /Sidebar ==

So, the information is still there, we just have to figure out a different way (or use a different tool) to get to it. But, before we go on, let’s recap a bit about our previous go-to Hibernation file decompression tools.

On September 20, 2016, Matthieu Suiche released (open sourced) his Hibr2bin (Hibernation file decompression) and DumpIt (memory image collection) utilities. However, as of this latest release, the Hibr2bin tool only supports comprehensive decompression of Hibernation files up through Windows 7. Though it states support for Windows 8 and 10 systems, it has been demonstrated to not fully decompress the file (of which Mathieu is currently aware). Though, the tool is open source now, so the community has full access to build these changes in themselves without relying on Mathieu to do it.

Though Volatility’s imagecopy plugin will work to decompress/convert Windows XP through Windows 7Hibernation files to a raw memory dump for analysis, it does not currently support Windows 8/Server 2012+ Hibernation file decompression (https://github.com/volatilityfoundation/volatility/issues/25). That said, it is still able to properly parse and analyze a decompressed Hibernation files through the latest version(s) of Windows 10/Server 2016, should you be able to decompress the Hibernation file by some other means/tool.

So, where does this leave us if our go-to tools no longer work to fully decompress Hibernation files from Windows 8/Server 2012+ systems? Are we up Schitt’s Creek (HILARIOUS show BTW, please do check it out) without a paddle?

Enter Arsenal Recon.

The folks that brought you Registry Recon and Arsenal Image Mounter have since developed Hibernation Recon, which as of this post appears to be the only tool currently available that supports comprehensive decompression of Windows hibernation files through the latest Windows 10 releases.

I’ve extracted the below pertinent information from their web page:

Hibernation Recon has been developed to not only support memory reconstruction from Windows XP, Vista, 7, 8/8.1, and 10 hibernation files, but to properly identify and extract massive volumes of information from the multiple types (and levels) of slack space that often exist within them…

Features:
* Windows XP, Vista, 7, 8/8.1, and 10 hibernation file support
* Active memory reconstruction
* Identification and extraction of multiple levels of slack space
* Brute force decompression of partially overwritten slack
* Segregation of extracted slack based on particular hibernations
* Proper handling of legacy hibernation data found in modern hibernation files
* NTFS metadata recovery with human-friendly decoding
* Parallel processing of multiple hibernation files”

As of the March 7, 2017 release, the team currently offers both a paid and free version…

Hibernation Recon is priced at just $399 to ensure every digital forensics expert can properly arm themselves. If Hibernation Recon is run without a license, a “Free Mode” is provided which supports the extraction of active contents from both legacy and modern Windows hibernation files.

As a major bonus and rarity for the “Free” version of a tool, the “Free Mode” version is allowed for both personal AND commercial use. NOICE! Big kudos to these guys for allowing this!

Do note that the hibernation slack & NTFS metadata recovery functionality is only available within the professional version, which I would imagine could be very useful as well. However, for the sake of brevity, access, and initial focus of my testing (i.e., successful comprehensive decompression) I am simply testing the “Free Mode” version. Perhaps I can get my hands on the Pro version at some point to test those additional recovery features…

At any rate, I downloaded the tool from the website and got on my way to testing using the “Free Mode”.

Testing

For testing, I first enabled hibernation via the command line (> powercfg -h on) and then generated three different hibernation files by performing the following procedures on my Windows 10 Pro desktop system:

Booted

  1. Enable Hibernation
  2. Hibernate the machine via Right-click Windows button -> Hibernate
  3. Boot the machine
  4. Log into the system and copy the existing hiberfil.sys via FTK Imager

Hibernated

  1. Enable Hibernation
  2. Hibernate the machine via Right-click Windows button -> Hibernate
    1. This can also be done via “shutdown /h” on the command line
  3. Boot into live linux environment and copy the existing hiberfil.sys

Shutdown

  1. Enable Hibernation
  2. Shut down the system
  3. Boot into live linux environment and copy the existing hiberfil.sys

With the 3 resulting hibernation files generated by the above methods, I could now test and measure the following:

  1. If, and how well, Hibernation Recon decompresses each Hibernation file
  2. How much information, if any, each Hibernation file contains (i.e., which collection method yields the greatest amount of artifacts and information)

With the data and aforementioned goals in hand, I ran Hibernation Recon* against each Hibernation file so that I had both a native compressed file and (supposedly) fully decompressed file for performing comparison.

*Note: I did not test Hibr2bin against these images as Sylve, Marziale, and Richard III had already done so as outlined in their previously mentioned paper on the subject.

I then ran the following tools against both the native compressed and decompressed images for each collection method (booted, hibernated, and shutdown) to collect a relatively representative set of results for quantitative comparison*:

*I’m no data scientist, I just attempted a testing methodology that I considered to have the greatest layman’s ROI

  1. GNU Strings
    Not too much to explain here, I simply wanted to identify all occurrences of strings (both unicode and ASCII) within each image.
  2. Page_Brute
    This tool is designed to run Yara signatures against each block (4096 bytes) of a pagefile. However, I wanted to test it against the Hibernation file as it also uses 4096 byte pages and well… there’s really nothing to lose in testing it. I added signatures to the default_signatures.yar ruleset file to also identify IP addresses, Email addresses, and URL’s – all useful artifacts of which we’d expect to find in a memory image and thus I figured a good method for comparison.
  3. Bulk_Extractor
    Copied/pasted directly from the user manual, “bulk_extractor operates on disk images, files or a directory of files and extracts useful
    information without parsing the file system or file system structures. The input is split into pages and processed by one or more scanners.
    ” It is a beautiful thing in that it is EXTREMELY well threaded and as such will hog as much of your system’s resources as it is allowed. Though caution must be exercised here in light of that, letting it run full throttle on a dedicated machine yields some insanely fast (not to mention very intelligent) artifact parsing and extraction. The quantity of identified and extracted artifacts are a good measure of how much decompressed data (in terms of Hibernation file decompression, not decompression of standard files like zip, rar, etc. that is also built into the tool) is available within the image.
  4. Volatility 2.6
    Run Volatility’s imagecopy plugin against the native compressed image to attempt to decompress/convert it to a raw image. Then, run Volatility with the appropriate system profile against the Volatility decompressed/converted image and the Hibernation Recon decompressed image. Various plugin output can then be compared across images to see which produces the greatest amount of artifacts parsed from the memory image.

Results

== Legend ==
JPW10_hiberfil.sys = Hibernation file from Shutdown system
JPW10_hiberfil.sys_2 = Hibernation file from Hibernated system
JPW10_hiberfil.sys_3 = Hibernation file from Booted system
ActiveMemory.bin = Decompressed and reconstructed memory image via Hibernation Recon

Strings, Page_Brute, and Bulk_Extractor data:
Hibernation_Testing_Results

“Booted” System Results
See spreadsheet for Strings, Page_Brute, and Bulk_Extractor data.

As we can verify here, the contents of the Hibernation file are zeroed upon system boot, which is stated to be the case in Windows 8+ systems. Thus, as we’d expect, no results from using any of the tools and no reason to use Hibernation Recon against the Hibernation file (nothing there to decompress).

“Hibernated” System Results
See spreadsheet for Strings, Page_Brute, and Bulk_Extractor data.

Volatility
Attempt to convert/decompress native hibernation file to use with Volatility…
$ python ~/volatility/vol.py -f Hibernated/JPW10_hiberfil.sys_2 --profile=Win10x64_14393 imagecopy -O Hibernated/Output/JPW10_hiberfil.sys_2_conv

Run pslist plugin against resulting file…
$ python ~/volatility/vol.py -f Hibernated/Output/JPW10_hiberfil.sys_2_conv --profile=Win10x64_14393 pslist
Volatility Foundation Volatility Framework 2.6
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
...
IA32PagedMemory: Incompatible profile Win10x64 selected
OSXPmemELF: ELF Header signature invalid
FileAddressSpace: Must be first Address Space
ArmAddressSpace: No valid DTB found

As you can see, it was not successfully decompressed and is thus not usable.

Now, we will see what happens when we run plugins against the Hibernation Recon (HR) decompressed image…
$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win10x64_10586, Win10x64_14393, Win10x64, Win2016x64_14393
AS Layer1 : Win10AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace (/mnt/hgfs/G/Hibernation_Testing/Hibernated/Output/ActiveMemory.bin)
PAE type : No PAE
DTB : 0x1ab000L
KDBG : 0xf800a82f0500L
Number of Processors : 8
Image Type (Service Pack) : 0
KPCR for CPU 0 : 0xfffff800a8342000L
KPCR for CPU 1 : 0xffffda019e020000L
KPCR for CPU 2 : 0xffffda019e09b000L
KPCR for CPU 3 : 0xffffda019e116000L
KPCR for CPU 4 : 0xffffda019e193000L
KPCR for CPU 5 : 0xffffda019e1d2000L
KPCR for CPU 6 : 0xffffda019e291000L
KPCR for CPU 7 : 0xffffda019e310000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2017-03-08 02:12:21 UTC+0000
Image local date and time : 2017-03-07 18:12:21 -0800

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin kdbgscan
...
**************************************************
Instantiating KDBG using: Unnamed AS Win10x64_14393 (6.4.14393 64bit)
Offset (V) : 0xf800a82f0500
Offset (P) : 0x469cf0500
KdCopyDataBlock (V) : 0xf800a81d0e00
Block encoded : Yes
Wait never : 0xd6dc0c37f24a0453
Wait always : 0x940ac90a25873204
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win10x64_14393
Service Pack (CmNtCSDVersion) : 0
Build string (NtBuildLab) : 14393.693.amd64fre.rs1_release.1
PsActiveProcessHead : 0xfffff800a82ff3d0 (39 processes)
PsLoadedModuleList : 0xfffff800a8305060 (189 modules)
KernelBase : 0xfffff800a8000000 (Matches MZ: True)
Major (OptionalHeader) : 10
Minor (OptionalHeader) : 0
KPCR : 0xfffff800a8342000 (CPU 0)
KPCR : 0xffffda019e020000 (CPU 1)
KPCR : 0xffffda019e09b000 (CPU 2)
KPCR : 0xffffda019e116000 (CPU 3)
KPCR : 0xffffda019e193000 (CPU 4)
KPCR : 0xffffda019e1d2000 (CPU 5)
KPCR : 0xffffda019e291000 (CPU 6)
KPCR : 0xffffda019e310000 (CPU 7)
**************************************************
...

Great. We’ve successfully retrieved the kdbg/dtb addresses along with the profile from the image. Now, let’s try to run some plugins against it to see what we’ve got…

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --dtb=0x1ab000 --profile=Win10x64_14393 pslist
Volatility Foundation Volatility Framework 2.6
Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
0xffff9e04362eb6c0 System 4 0 209 0 ------ 0 2017-03-07 22:34:32 UTC+0000
0xffff9e043acbf800 smss.exe 372 4 4 0 ------ 0 2017-03-07 22:34:32 UTC+0000
0xffff9e043b4e9080 csrss.exe 540 528 13 -------- 0 0 2017-03-07 22:34:35 UTC+0000
0xffff9e043c439800 wininit.exe 628 528 4 0 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c4d8800 services.exe 708 628 33 -------- 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c540400 lsass.exe 752 628 11 -------- 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c4d4800 svchost.exe 872 708 54 0 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c4ce800 svchost.exe 936 708 16 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c472800 svchost.exe 348 708 104 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c626080 svchost.exe 388 708 54 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c683800 svchost.exe 1032 708 24 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c681800 svchost.exe 1096 708 32 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c67d800 svchost.exe 1212 708 38 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c67b800 svchost.exe 1236 708 34 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c66f800 nvvsvc.exe 1580 708 8 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c66b800 nvscpapisvr.ex 1588 708 7 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043637d080 svchost.exe 2000 708 8 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043ca1f800 svchost.exe 1292 708 12 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043ca8b800 spoolsv.exe 2056 708 32 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c042700 sched.exe 2168 708 17 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c036800 avguard.exe 2428 708 120 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c032800 armsvc.exe 2440 708 5 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c034800 Avira.ServiceH 2448 708 31 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c030800 OfficeClickToR 2476 708 29 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c02e800 IPROSetMonitor 2508 708 4 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c02c800 LogiRegistrySe 2516 708 6 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c02a800 svchost.exe 2524 708 16 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c028800 NvNetworkServi 2544 708 5 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c026800 NvStreamServic 2680 708 11 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c024800 dasHost.exe 2740 1096 26 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be64740 svchost.exe 2760 708 19 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be66800 svchost.exe 2768 708 19 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be75800 vmnetdhcp.exe 2776 708 3 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be70800 vmware-usbarbi 2792 708 5 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be72800 vmnat.exe 2808 708 6 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be74800 vmware-authd.e 2824 708 7 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be91800 MsMpEng.exe 2836 708 8 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be97800 ss_conn_servic 2844 708 6 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043beed040 MemCompression 2952 4 16 0 ------ 0 2017-03-07 22:34:38 UTC+0000

Excellent. Looks like many of the data structures are in tact to provide the types of information we’d expect from a full memory image!

So, let’s keep going…

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --dtb=0x1ab000 --profile=Win10x64_14393 hivelist
Volatility Foundation Volatility Framework 2.6
Virtual Physical Name ------------------ ------------------ ----
0xffff87063f057000 0x00000000059f3000 \REGISTRY\MACHINE\HARDWARE

Uh oh, that doesn’t look right. There should be more hives found than that.

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --dtb=0x1ab000 --profile=Win10x64_14393 userassist
Volatility Foundation Volatility Framework 2.6
The requested key could not be found in the hive(s) searched

No userassist (as it relies on the registry hives).

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --dtb=0x1ab000 --profile=Win10x64_14393 shellbags
Volatility Foundation Volatility Framework 2.6
Scanning for registries....
Gathering shellbag items and building path tree...

And, no shellbags (as it also relies on the registry hives). So, I guess the decompressed image doesn’t contain that.

Well, how about files?

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --dtb=0x1ab000 --profile=Win10x64_14393 filescan
Offset(P) #Ptr #Hnd Access Name ------------------ ------ ------ ------ ----
...
0x0000f000000f0820 3 0 RW-rwd \Device\HarddiskVolume2\$Extend\$RmMetadata\$Repair:$Corrupt:$DATA 0x0000f000000fe2d0 8 0 R--r-d \Device\HarddiskVolume6\Windows\System32\coreaudiopolicymanagerext.dll 0x0000f00000100420 12 0 R--r-d \Device\HarddiskVolume6\Windows\System32\Windows.UI.Xaml.Resources.dll 0x0000f00000100720 3 0 R--rwd \Device\HarddiskVolume6\Program Files\Microsoft Office\root\CLIPART\PUB60COR\NA02386_.WMF
0x0000f00000102ef0 15 0 R--r-d \Device\HarddiskVolume6\Windows\System32\dsreg.dll
0x0000f00000113080 32753 1 ------ \Device\DeviceApi\CMNotify
0x0000f000001132a0 15 0 R--rwd \Device\HarddiskVolume6\Windows\System32\vcruntime140.dll 0x0000f00000114cc0 15 0 R--r-d \Device\HarddiskVolume6\Windows\System32\microsoft-windows-kernel-power-events.dll
0x0000f0000011c370 32708 1 RW-r-- \Device\HarddiskVolume6\Windows\System32\winevt\Logs\Microsoft-Windows-AppXDeploymentServer%4Operational.evtx
0x0000f00000127ef0 16 0 R--r-d \Device\HarddiskVolume6\Windows\System32\DriverStore\FileRepository\iaahcic.inf_amd64_6c0fb3e072c6ec98\iaAHCIC.cat
0x0000f0000012e740 32768 1 ------ \Device\DeviceApi\CMNotify
0x0000f00000135a00 16 0 R--r-- \Device\HarddiskVolume6\Windows\INF\msgpiowin32.PNF
0x0000f00000140cd0 2 0 R--r-- \Device\HarddiskVolume6\Windows\WinSxS\Manifests\x86_microsoft.windows.i..utomation.proxystub_6595b64144ccf1df_1.0.14393.0_none_1e9c04c01886b354.manifest ...

Looks like that works, so mainly (in this short testing) we’re just missing registry hives.

While there are some anomalies here within strings (less identified ASCII and UNI strings in the decompressed hibernation file), we can see that not only does Hibernation Recon’s decompressed hibernation file yield substantially more artifacts across the board in both page_brute and Bulk_Extractor, but it also yields a memory image for use in/with Volatility. However, we can see that there are some pieces of missing information that would otherwise be resident in a memory image collected from a live system (namely registry hives as discovered in our testing, but there could be other missing items). Is Hibernation Recon missing resident information? Is Windows simply not storing that information in the hibernation file itself? I’m not certain, but would be very interested in finding out.

“Shutdown” System Results
See spreadsheet for Strings, Page_Brute, and Bulk_Extractor data.

Volatility
Attempt to convert/decompress native hibernation file to use with Volatility…
$ python ~/volatility/vol.py -f Shutdown/JPW10_hiberfil.sys --profile=Win10x64_14393 imagecopy -O Shutdown/Output/JPW10_hiberfil.sys_conv

Run pslist against the resulting file…
$ python ~/volatility/vol.py -f Shutdown/Output/JPW10_hiberfil.sys_conv --profile=Win10x64_14393 pslist

No results, showing the file wasn’t able to be successfully decompressed/parsed by Volatility.

So, let’s again move on to the HR decompressed file.

$ python ~/volatility/vol.py -f Shutdown/Output/ActiveMemory.bin imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win10x64_14393, Win2016x64_14393
AS Layer1 : Win10AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace (/mnt/hgfs/G/Hibernation_Testing/Shutdown/Output/ActiveMemory.bin)
PAE type : No PAE
DTB : 0x1ab000L
KDBG : 0xf800a82f0500L
Number of Processors : 8
Image Type (Service Pack) : 0
KPCR for CPU 0 : 0xfffff800a8342000L
KPCR for CPU 1 : 0xffffda019e020000L
KPCR for CPU 2 : 0xffffda019e09b000L
KPCR for CPU 3 : 0xffffda019e116000L
KPCR for CPU 4 : 0xffffda019e193000L
KPCR for CPU 5 : 0xffffda019e1d2000L
KPCR for CPU 6 : 0xffffda019e291000L
KPCR for CPU 7 : 0xffffda019e310000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2017-03-07 22:39:53 UTC+0000
Image local date and time : 2017-03-07 14:39:53 -0800

$ python ~/volatility/vol.py -f Shutdown/Output/ActiveMemory.bin kdbgscan
Volatility Foundation Volatility Framework 2.6
**************************************************
Instantiating KDBG using: /mnt/hgfs/G/Hibernation_Testing/Shutdown/Output/ActiveMemory.bin WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x3e0a9730
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win10x64_14393
PsActiveProcessHead : 0xa82ff3d0
PsLoadedModuleList : 0xa8305060
KernelBase : 0xfffff800a8000000
**************************************************
Instantiating KDBG using: /mnt/hgfs/G/Hibernation_Testing/Shutdown/Output/ActiveMemory.bin WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x3e0a9730
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win2016x64_14393
PsActiveProcessHead : 0xa82ff3d0
PsLoadedModuleList : 0xa8305060
KernelBase : 0xfffff800a8000000

Again, we are able to successfully parse the HR decompressed image to get the initial offsets and profile needed to use Volatility and its plugins for analysis. So, let’s get to them.

$ python ~/volatility/vol.py -f Shutdown/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --dtb=0x1ab000 --profile=Win10x64_14393 pslist
Volatility Foundation Volatility Framework 2.6
Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
0xffff9e04362eb6c0 System 4 0 206 0 ------ 0 2017-03-07 22:34:32 UTC+0000
0xffff9e043acbf800 smss.exe 372 4 4 0 ------ 0 2017-03-07 22:34:32 UTC+0000
0xffff9e043b4e9080 csrss.exe 540 528 14 -------- 0 0 2017-03-07 22:34:35 UTC+0000
0xffff9e043c439800 wininit.exe 628 528 7 0 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c4d8800 services.exe 708 628 33 -------- 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c540400 lsass.exe 752 628 9 -------- 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c4d4800 svchost.exe 872 708 46 0 0 0 2017-03-07 22:34:36 UTC+0000
0xffff9e043c4ce800 svchost.exe 936 708 14 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c472800 svchost.exe 348 708 96 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c626080 svchost.exe 388 708 53 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c683800 svchost.exe 1032 708 23 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c681800 svchost.exe 1096 708 24 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c67d800 svchost.exe 1212 708 31 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c67b800 svchost.exe 1236 708 30 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c66f800 nvvsvc.exe 1580 708 8 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c66b800 nvscpapisvr.ex 1588 708 7 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043637d080 svchost.exe 2000 708 8 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043ca1f800 svchost.exe 1292 708 12 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043ca8b800 spoolsv.exe 2056 708 30 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c042700 sched.exe 2168 708 17 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c036800 avguard.exe 2428 708 120 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c032800 armsvc.exe 2440 708 5 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c034800 Avira.ServiceH 2448 708 28 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c030800 OfficeClickToR 2476 708 23 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c02e800 IPROSetMonitor 2508 708 4 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c02c800 LogiRegistrySe 2516 708 6 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c02a800 svchost.exe 2524 708 12 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c028800 NvNetworkServi 2544 708 5 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c026800 NvStreamServic 2680 708 10 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043c024800 dasHost.exe 2740 1096 26 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be64740 svchost.exe 2760 708 17 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be66800 svchost.exe 2768 708 14 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be75800 vmnetdhcp.exe 2776 708 3 -------- 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be70800 vmware-usbarbi 2792 708 5 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be72800 vmnat.exe 2808 708 6 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be74800 vmware-authd.e 2824 708 7 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be91800 MsMpEng.exe 2836 708 8 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043be97800 ss_conn_servic 2844 708 6 0 0 0 2017-03-07 22:34:38 UTC+0000
0xffff9e043beed040 MemCompression 2952 4 4 0 ------ 0 2017-03-07 22:34:38 UTC+0000

Great. Again, looks like we have a memory image here that we can successfully use with Volatility.

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --profile=Win10x64_14393 hivelist
Volatility Foundation Volatility Framework 2.6
Virtual Physical Name ------------------ ------------------ ----
0xffff87063f057000 0x00000000059f3000 \REGISTRY\MACHINE\HARDWARE

Uh oh (again). It can’t seem to locate many of the registry hives in memory.

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --profile=Win10x64_14393 userassist
Volatility Foundation Volatility Framework 2.6
The requested key could not be found in the hive(s) searched

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --profile=Win10x64_14393 shellbags
Volatility Foundation Volatility Framework 2.6
Scanning for registries....
Gathering shellbag items and building path tree...

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --profile=Win10x64_14393 shimcache
Volatility Foundation Volatility Framework 2.6
WARNING : volatility.debug : No ShimCache data found

Again, can’t extract the info from these plugins because of the lack of registry hives found.

However, it seems that many other plugins complete successfully.

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --profile=Win10x64_14393 filescan
Volatility Foundation Volatility Framework 2.6
Offset(P) #Ptr #Hnd Access Name ------------------ ------ ------ ------ ----
...
0x0000f000000f0820 3 0 RW-rwd \Device\HarddiskVolume2\$Extend\$RmMetadata\$Repair:$Corrupt:$DATA 0x0000f000000fe2d0 8 0 R--r-d \Device\HarddiskVolume6\Windows\System32\coreaudiopolicymanagerext.dll 0x0000f00000100420 12 0 R--r-d \Device\HarddiskVolume6\Windows\System32\Windows.UI.Xaml.Resources.dll 0x0000f00000100720 3 0 R--rwd \Device\HarddiskVolume6\Program Files\Microsoft Office\root\CLIPART\PUB60COR\NA02386_.WMF
0x0000f00000102ef0 15 0 R--r-d \Device\HarddiskVolume6\Windows\System32\dsreg.dll
0x0000f00000113080 32753 1 ------ \Device\DeviceApi\CMNotify
0x0000f000001132a0 15 0 R--rwd \Device\HarddiskVolume6\Windows\System32\vcruntime140.dll 0x0000f00000114cc0 15 0 R--r-d \Device\HarddiskVolume6\Windows\System32\microsoft-windows-kernel-power-events.dll
0x0000f0000011c370 32708 1 RW-r-- \Device\HarddiskVolume6\Windows\System32\winevt\Logs\Microsoft-Windows-AppXDeploymentServer%4Operational.evtx
0x0000f00000127ef0 16 0 R--r-d \Device\HarddiskVolume6\Windows\System32\DriverStore\FileRepository\iaahcic.inf_amd64_6c0fb3e072c6ec98\iaAHCIC.cat
0x0000f0000012e740 32768 1 ------ \Device\DeviceApi\CMNotify
0x0000f00000135a00 16 0 R--r-- \Device\HarddiskVolume6\Windows\INF\msgpiowin32.PNF
0x0000f00000140cd0 2 0 R--r-- \Device\HarddiskVolume6\Windows\WinSxS\Manifests\x86_microsoft.windows.i..utomation.proxystub_6595b64144ccf1df_1.0.14393.0_none_1e9c04c01886b354.manifest
...

I also ran the mbrparser and mftparser plugins against the image to see if that data was resident.

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --profile=Win10x64_14393 mbrparser

Verified works.

$ python ~/volatility/vol.py -f Hibernated/Output/ActiveMemory.bin --kdbg=0xf800a81d0e00 --profile=Win10x64_14393 mftparser

Verified works.

So, we seem to witness the same anomaly in strings, however it appears that the decompressed hibernation file contains more identified Unicode strings as compared to the native file. Given that strings performs a relatively arbitrary function (i.e. identify things that might be strings of an alphabet/namespace), I am simply providing it as a data point. And, again, we see that the decompressed file yields a substantial amount of additional information that was otherwise obfuscated/hidden from discovery in its native form.

Conclusion

As you can see, Arsenal’s tool was able to successfully decompress and reconstruct the provided Hibernation files (sans the zeroed file from the Booted system obviously), thus restoring a substantial amount of otherwise obfuscated/encoded data and ultimately our capability to extract useful artifacts in our investigations! Given how long it’s been since I’ve been able to easily and comprehensively decompress a Windows 8/Server 2012+ Hibernation file, I would have been satisfied with simple decompression of all strings or chunks of data. Not only do we get that, but also the restored ability to use Volatility for more comprehensive analysis of the extracted memory image (sans a few missing memory artifacts as previously noted*).

For me, it looks like I now have a new go-to tool for decompressing Hibernation files from Windows 8/Server 2012+ systems.

*If anyone has any insight, I would love to find out why we can’t seem to locate the registry hives in the reconstructed memory image, along with what else may be missing (as I didn’t test every single plugin) and why.

/JP