2:20 p.m.
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
2:57 p.m.
Hi Adam,
You are correct about your assumption where the first pages are nulled
out. Win7SP1x64 hibernation file support does work (I actually
implemented and tested that support), the name "WindowsHiberFileSpace32"
is really just a misnomer and works for both x86 and x64. Perhaps I'll
change that name to just "WindowsHiberFileSpace" instead...
That being said, sometimes things break due to corrupt hibernation files
(stale partially overwritten data for example), which causes the address
space to fail. It could also be that there is more than one kdbg value.
Try a couple of things to help troubleshoot:
1) use `kdbgscan` with the `--profile=Win7SP1x64` flag and see if there
is more than one value.
2) try to use `psscan` or `modscan` with the correct profile and see if
you get anything back.
In the worst case, are you able to share the hibernation file so that we
may troubleshoot it?
All the best,
-Jamie
On 2/23/15 2:20 PM, Bridgey theGeek 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(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
--
Jamie Levy (@gleeda)
Blog: http://volatility-labs.blogspot.com/
GPG: http://pgp.mit.edu/pks/lookup?op=get&search=0x196B2AB527A4AC92
Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
3:06 p.m.
Did you try the "hibinfo" command on the hiberfile?
On Mon, Feb 23, 2015 at 2:20 PM, Bridgey theGeek <bridgeythegeek(a)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(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
4:02 p.m.
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(a)gmail.com> wrote:
Did you try the "hibinfo" command on the
hiberfile?
On Mon, Feb 23, 2015 at 2:20 PM, Bridgey theGeek <bridgeythegeek(a)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(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
3552
days inactive
3552
days old
vol-users@lists.volatilityfoundation.org
3 comments
3 participants
participants (3)
-
Bridgey theGeek -
Jamie Levy -
Jared Greenhill