Thanks for the comments all.

Interestingly, the following didn't give any output at all:

$ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x64 kdbgscan

Given Jamie had said, "...see if there is more than one value", the fact that there wasn't even one made me... sad.

I had the gut feeling this wasn't going to be a Win7SP1x64 after all.

So I tried the 32-bit profile:

$ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x86 pslist

Whaddayaknow... sung like a 32-bit birdie!

The intel that it was a 64-bit host came from a colleague. I shall have to beat him with the learning stick tomorrow.

That said, looking again, I notice that the output from imageinfo did actually show 32-bit addresses:

KPCR for CPU 0 : 0x82d3bc00

KPCR for CPU 1 : 0x807c6000

KPCR for CPU 2 : 0x8d300000

KPCR for CPU 3 : 0x8d336000

KUSER_SHARED_DATA : 0xffdf0000

Thanks again all,

Adam

On 23 February 2015 at 20:06, Jared Greenhill <jared703@gmail.com> wrote:

Did you try the "hibinfo" command on the hiberfile?

On Mon, Feb 23, 2015 at 2:20 PM, Bridgey theGeek <bridgeythegeek@gmail.com> wrote:
Hi all,

Just trying to figure out where I'm going wrong.

I have a hiberfil.sys file from a Win7SP1x64 system.
The first 6 pages are full of 0x00 which I believe means the hiberfil was wiped as part of a resume.

Having read the AOMF, specifically p98, I expected Volatility to brute force the header and, voila, magic happens.

However, Volatility just reports that it wasn't able to find a matching address space:

$ python vol.py -f /tmp/hiberfil.sys imageinfo
Volatility Foundation Volatility Framework 2.4
Determining profile based on KDBG search...

Suggested Profile(s) : No suggestion (Instantiated with Win7SP1x86)
AS Layer1 : IA32PagedMemoryPae (Kernel AS)
AS Layer2 : WindowsHiberFileSpace32 (Unnamed AS)
AS Layer3 : FileAddressSpace (/tmp/hiberfil.sys)
PAE type : PAE
DTB : 0x185000L
KDBG : 0x82d3ac28
Number of Processors : 4
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0x82d3bc00
KPCR for CPU 1 : 0x807c6000
KPCR for CPU 2 : 0x8d300000
KPCR for CPU 3 : 0x8d336000
KUSER_SHARED_DATA : 0xffdf0000
Image date and time : 2014-05-09 15:26:28 UTC+0000
Image local date and time : 2014-05-09 17:26:28 +0200

$ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x64 pslist
Volatility Foundation Volatility Framework 2.4
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
...
...

If I try an imagecopy, the output file is identical to the original:

$ python vol.py -f /tmp/hiberfil.sys --profile=Win7SP1x64 imagecopy -O /tmp/hiberfil.bin
Volatility Foundation Volatility Framework 2.4
Writing data (5.00 MB chunks): |.................................................................................................................................................................................................................................................................................................................................................................................................................................................................|
bridgey@aspire:~/dev/volatility$ md5sum /tmp/hiberfil.*
fee8a1c6924b871477434a678adb4483 /tmp/hiberfil.bin
fee8a1c6924b871477434a678adb4483 /tmp/hiberfil.sys

And finally, I couldn't find a class for 64-bit hiberfil...

$ find -type f -name '*iber*' -exec grep -H ^class.WindowsHi {} \;
./volatility/plugins/addrspaces/hibernate.py:class WindowsHiberFileSpace32(addrspace.BaseAddressSpace):

Am I leaping to conclusions, or is a hiberfil from a 64-bit system simply not supported?

Would love any comments!

Thanks,
Adam

_______________________________________________
Vol-users mailing list
Vol-users@volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users