All, Here's a follow-up on the hiberfil.sys decompression issue. I executed the test plan as it was previously posted to vol-users (see <http://lists.volatilityfoundation.org/pipermail/vol-users/2009-July/000115.html>). As Michael already reported on this list, Volatility and X-Ways Forensics produced identical decompressed images from the original hiberfil.sys. Each of the memory images (VMEM files and decompressed hiberfil.sys) contains 32739 pages. Hibernation is known to preserve only important parts of the system's memory (see <http://technet.microsoft.com/en-us/library/bb457057.aspx>). returned from hibernation mode (prehib.vmem vs posthib.vmem). The decompressed hibernation file matched 18566 pages (57%) of physmem prior to hibernation and 27929 pages (85%) of physmem post hibernation. process), 17998 (94%) are present in the decompressed hibernation file. Of those 3657 pages are filled with zeros. What about the remaining 6%? I suppose these pages are in use by the boot loader, HAL, or parts of the kernel. AAron suggested to analyze the process memory instead of physical memory. A quick stab (using Volatility's memdmp module) produced the following output for a command console: 44.322.816 bytes from prehib.vmem 46.036.628 bytes from hiberfil.sys 49.815.552 bytes from decompressed hiberfil.sys 39.624.704 bytes from posthib.vmem I ran nwdiff on the resulting images and all I can say is that the process environment is unchanged. Obviously, more work is needed to get a meaningful result. I suppose to focus on the user-land portion of the address space, calculate the pages's md5sum, and keep an eye on PTE flags as well. Please keep in mind that the figures above are based on a single execution of the test plan only. Multiple runs, with different memory loads and system memory sizes may yield different results. Cheers, Andreas