Hibernation Slack: Unallocated Data from the Deep Past

Hi Folks,

I was recently doing some forensic research on a laptop which had been formatted and factory-reinstalled (using the preinstalled HPA partition it shipped with), and then used normally by another user for six months prior to collection. I wasn't really expecting to be able to recover much of anything from before the format, but it's always worth a look. My initial examination showed that even unallocated space had been largely overwritten during the six month post reinstall period. Even the fragments I was able to recover from file slack were largely useless. Then I got some very confusing keyword search hits from data in hiberfil.sys, the Windows hibernation file, and my Odyssey began.

The reason these hits were confusing was that they appeared to reference data from before the format, yet they occurred almost exactly in the middle of the 3GB+ hibernation file, and that file had been written to (which I at first assumed meant completely overwritten) only days before the image was acquired, six months after the factory reinstall. Even more surprising, when I recovered earlier versions of hiberfil.sys from 5 old Volume Shadow Copies, those files all contained the exact same hits in exactly the same place, even though the extracted memory images were completely different.

Adding further confusion were excerpts from "EnCase Computer Forensics — The Official EnCE: EnCase Certified Examiner Study Guide" which said, (WRT Win2K, XP, & Vista):

• "this file will be the size of your system's RAM memory"
• "If the computer has never been in hibernation mode, the file will still be the same size as your system RAM, but will be filled with 00h characters"

Both of the above points were manifestly untrue on the system I was investigating, and on several other Win7 systems I checked as well. This has apparently changed as of Windows 7, as I finally discovered here.

I also began a comprehensive examination of the subject system's hiberfil.sys, and was able to conclusively identify the actual end of the memory and state information populated into that file. Surprisingly, this offset was only 1.2GB into the 3.1GB file. Even more surprising, when I used Volatility to extract the complete memory dump, that dump was 5GB in size! Apparently, the user of this system had made relatively little use of his installed RAM, running very few applications at the same time, and this resulted in the memory image which was saved when the system went into hibernation being extremely compressible.

My methodology for determining the end of the actual hibernation data was based on perusal of the PacSec07 presentation "Enter Sandman" by Nicolas Ruff and Mattieu Suiche. I was able to find a bit more in the paper: "Forensic carving of network packets and associated data structures" by Robert Beverly, Simson Garfinkel, & Greg Cardwell. Specifically, the compressed memory image which makes up the bulk of hiberfil.sys consists of a series of encoded blocks, each of which begins with a magic value of "\x81\x81xpress", followed by a header with size & checksum information, and then the compressed data (64K before compression). The first 3 bytes of the header are a little-endian quantity, which when divided by 1024 and incremented once, gives the length of the block in bytes. Thus, by identifying the last occurrence of the magic value, calculating the size of that data block, and moving forward in the file to that offset, I was able to identify roughly the furthest into the hibernation file that actual memory image data had been written.

Note that this offset point isn't necessarily the end of the most recent memory image, just the largest one for which a complete last block remains. The end of the most recent memory image could be prior to this point. In addition, it's possible that a series of hibernation events with incrementally smaller compressed memory sizes could overwrite the magic values at the beginnings of the last few compressed memory blocks in the file, thus leaving an unexpectedly large amount of compressed memory data after the point at which one would expect it to end. As a check on this method, I also examined the data format visually at this offset in the file, and noted that shortly after this point, the appearance of the data altered substantially, becoming more characteristic of unallocated disk blocks than compressed or encrypted data.

In any case, the data following the last of the compressed memory, for which I've coined the term 'Hibernation Slack', seems to be a sizable remnant of unallocated space from before the creation of hiberfil.sys, which has been effectively fossilized. The system I analyzed happened to have quite a few IE cache files and other dynamic data within this approximately 1.9GB of preserved old data. It may be that this is a frequent occurrence, resulting from a Windows reinstall loading OS files onto the same space they originally occupied, and then, if the creation of hiberfil.sys isn't a part of the actual install process, when it finally does get created, it sweeps up a large chunk of space which was previously used for various dynamic data.

Given the larger memory that's being shipped on many recent laptop models and the commonality of default configurations, this seems likely to be a generally useful place to search, and from which to carve old files in any case involving OS reinstallation and subsequent usage.

Happy Forensicating!

John

As always, please feel free to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy.

John McCash, GCFA Silver #2816, is currently a Forensic Investigator - previously employed by a fortune 500 telecommunications equipment provider, and now making a foray into the world of consulting.