-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi folks,
There's one week left to register for the upcoming Reston class (April
13-17). If you're from Reston or will be there working during the
time, drop us a note and we'll include you in the "night out"
announcement so you can come have some drinks with other Volatility
users.
Same applies to the New York class during the week of May 11-15, UK
June 1-5 and Amsterdam August 31-September 4.
We hope to see some of guys there!
MHL
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iF4EAREKAAYFAlUb84YACgkQXnt9v1O0LIv08gEAlz1YdHOV2NfMQzOzDegIguFI
EkVTkFR6kFSDo2z1oRgBAJWc+SJyUJ+wP93ULd8pFw9d97QqCr8y+aQnEsKlVn3A
=W35+
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Perfect! Glad to hear all is good in the world ;-)
MHL
On 3/24/15 5:05 AM, Bridgey theGeek wrote:
> Awesome, thanks Michael.
>
> I generated a raw dump as follows, with the vmsn and vmem files in
> the same folder: $ python vol.py -f winxp.vmem
> --profile=WinXPSP2x86 imagecopy -O winxp.raw
>
> Then ran strings again (having generated a new input text file
> because of course the offsets will be different): $ python vol.py
> -f winxp.raw --profile=WinXPSP2x86 strings -s pk.txt
>
> I was then able to find the banner at the offsets reported by
> strings. And all was good in the world.
>
> Thank you very much for the support.
>
> Adam
>
> On 23 March 2015 at 19:39, Michael Ligh <michael.ligh(a)mnin.org
> <mailto:michael.ligh@mnin.org>> wrote:
>
> Hey Adam,
>
> A few things:
>
> * Yes, vmss2core creates a windows crash dump * You can use
> volatility on the original vmem/vmss by doing the following:
>
> * make sure both vmem and vmss files are in the same dir * make
> sure they have the same base name (i.e. test.vmem and test.vmss) *
> run your volatility plugins against the vmem
>
> In this case, it would also be required to generate a raw memory
> dump before running strings. So you would use imagecopy on the
> vmem.
>
> LMK if that helps! Michael
>
> On 3/23/15 10:51 AM, Bridgey theGeek wrote:
>> Hi Michael,
>
>> *sigh* When will I learn to check the origin of my samples?!
>
>> The guy who provided me with the sample tells me that he took a
>> snapshot of a VMWare machine and then used vss2core to convert
>> it. I BELIEVE that makes it into a Windows Memory Core Dump..?
>
>> I got hold of the original vmem and vmsn files. Trying to use
>> imagecopy on the vmsn just replicated the input file. I think
>> the header is not what Volatility would expect: $ xxd Windows\
>> XP\ Pro\ SP2\ \(32-bit\)-Snapshot49.vmsn |head 0000000: d2be d2be
>> 0800 0000 6300 0000 4368 6563 ........c...Chec 0000010: 6b70
>> 6f69 6e74 0000 0000 0000 0000 0000 kpoint.......... 0000020:
>> 0000 0000 0000 0000 0000 0000 0000 0000 ................
>> 0000030: 0000 0000 0000 0000 0000 0000 0000 0000
>> ................ 0000040: 0000 0000 0000 0000 0000 0000 fc1e 0000
>> ................ 0000050: 0000 0000 ab03 0000 0000 0000 4775 6573
>> ............Gues 0000060: 7456 6172 7300 0000 0000 0000 0000 0000
>> tVars........... 0000070: 0000 0000 0000 0000 0000 0000 0000 0000
>> ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000
>> ................ 0000090: 0000 0000 0000 0000 0000 0000 a722 0000
>> ............."..
>
>> Does that mean I can't use this with Volatility?
>
>> Thank you, Adam
>
>> On 23 March 2015 at 14:57, Michael Ligh <michael.ligh(a)mnin.org
>> <mailto:michael.ligh@mnin.org> <mailto:michael.ligh@mnin.org
>> <mailto:michael.ligh@mnin.org>>> wrote:
>
>> Hey Adam,
>
>> We forgot to ask if the sample was a raw memory dump. For
>> example:
>
>> $ xxd ~/Desktop/memory.dmp | less
>
>> 0000000: 5041 4745 4455 4d50 0f00 0000 280a 0000
>> PAGEDUMP....(... 0000010: 8001 6c07 00c0 e680 a031 5580 5892 5580
>> ..l......1U.X.U. 0000020: 4c01 0000 0100 0000 8000 0000 5444 4f00
>> L...........TDO. 0000030: 0000 0000 0000 0000 0000 0000 5041 4745
>> ............PAGE 0000040: 5041 4745 5041 4745 5041 4745 5041 4745
>> PAGEPAGEPAGEPAGE
>
>> If its something like a crash dump, hibernation, etc then the
>> file format headers throw off the offsets. You can convert those
>> special file types into a raw memory dump with the imagecopy
>> plugin and then your strings translations should be accurate.
>
>> Cheers! MHL
>
>> On 3/23/15 8:54 AM, Bridgey theGeek wrote:
>>> Hi Andrew,
>
>>> I was certain I was running the latest version, but just to be
>>> sure I grabbed the latest version. Same result, same offsets.
>
>>> I can make the sample available, but more than happy to do
>>> whatever debugging needs doing (if I can!)
>
>>> Adam
>
>>> On 23 March 2015 at 13:03, Andrew Case <atcuno(a)gmail.com
>>> <mailto:atcuno@gmail.com> <mailto:atcuno@gmail.com
>>> <mailto:atcuno@gmail.com>>
> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> wrote:
>
>>> Are you using the latest git checkout of Volatility or the 2.4
>>> release? Can you try the latest checkout and re-run Volatility
>>> strings (you can run it on just the offsets from PID 123 to
>>> make it faster).
>
>>> If you are already on the latest checkout then we will need to
>>> debug further.
>
>
>
>
>>> Thanks, Andrew (@attrc)
>
>>> On 03/23/2015 04:38 AM, Bridgey theGeek wrote:
>>>> Thanks Andrew:
>>>>
>>>> python vol.py --profile=WinXPSP2x86 -f memory.dmp volshell
>>>> -p 123 Volatility Foundation Volatility Framework 2.4
>>>> Current context: myapp.exe @ 0x822042f8, pid=123, ppid=392
>>> DTB=0x76c0040
>>>> Welcome to volshell! Current memory image is:
>>>> file:///home/memory.dmp To get help, type 'hh()'
>>>>>>> db(0x75b6b4d8)
>>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff 01 00 00 00 75 09 8d
>>>> .|...........u.. 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 9d
>>>> 00 ff ff ff 89 85 .....P..9....... 0x75b6b4f8 30 ff ff ff 74
>>>> 12 6a 0c 8d 85 c4 fe ff ff 50 6a 0...t.j.......Pj 0x75b6b508
>>>> 07 6a fe e8 ea 92 ff ff 83 bd 28 ff ff ff 0c 0f
>>>> .j........(..... 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff 90
>>>> 90 47 00 6c 00 ..Y.........G.l. 0x75b6b528 6f 00 62 00 61 00
>>>> 6c 00 5c 00 54 00 65 00 72 00 o.b.a.l.\.T.e.r. 0x75b6b538 6d
>>>> 00 53 00 72 00 76 00 52 00 65 00 61 00 64 00 m.S.r.v.R.e.a.d.
>>>> 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 74 00 00 00 90 90
>>>> y.E.v.e.n.t.....
>>>>
>>>> Nope, still no banner. But it is identical to what I find at
>>> 0x1a34d8 in
>>>> 123.dmp. (As you'd expect.) Double-checked that I was
>>>> searching Unicode and ASCII - still no luck.
>>>>
>>>> Hmmm.
>>>>
>>>> Adam
>>>>
>>>> On 23 March 2015 at 04:02, Andrew Case <atcuno(a)gmail.com
> <mailto:atcuno@gmail.com>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>
>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>
>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>
>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>
> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> wrote:
>>>>
>>>> Can do you:
>>>>
>>>> vol.py ... volshell -p 123
>>>>
>>>> Then in volshell do:
>>>>
>>>> db(0x75b6b4d8)
>>>>
>>>> And see if you get the banner printed at the beginning?
>>>>
>>>> Also, how are you searching 123.dmp? Did you search ascii &
>>> unicode
>>>> (most common error)
>>>>
>>>> Thanks, Andrew (@attrc)
>>>>
>>>> On 03/20/2015 03:59 PM, Bridgey theGeek wrote:
>>>>> Hi all,
>>>>>
>>>>> I can't quite see what's wrong with my logic here, but I
>>>>> must be
>>>> missing
>>>>> something. Hoping someone can help me out.
>>>>>
>>>>> I'm looking for a private key in a memory sample
>>>>> (WinXPSP2x86). Specifically, to find out which process/es
>>>>> is/are accessing it.
>>>>>
>>>>> I can find the key by searching the raw memory dump
>>> (memory.dmp).
>>>>> As you might expect it's between: -----BEGIN RSA PRIVATE
>>>>> KEY----- -----END RSA PRIVATE KEY-----
>>>>>
>>>>> I generated an offset:string file by using strings. Then,
>>>>> using the strings plugin I get this output: $ python
>>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 strings
>>> -s pk.txt
>>>>> Volatility Foundation Volatility Framework 2.4 188435934
>>>>> [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- 188435968
>>>>> [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- 317375704
>>>>> [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY-----
>>>>> 317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY-----
>>>>> 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY-----
>>>>> 417204287 [123:75b6b83f] -----END RSA PRIVATE KEY-----
>>>>> 419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY-----
>>>>> 419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY-----
>>>>>
>>>>> Lovely. So I now do a memdump of process 123: $ python
>>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 memdump
>>> --pid=123
>>>>> --dump-dir=123 Volatility Foundation Volatility Framework
>>>>> 2.4
>>>>>
>>>>
>
>
> ************************************************************************
>
>
>
>
>>>> Writing myapp.exe [ 123] to 123.dmp
>>>>>
>>>>> However, if I search 123.dmp neither the BEGIN or END
>>> strings are
>>>> present.
>>>>>
>>>>> So I thought I'd try and find it via the virtual address
>>>>> give,
>>>> 0x75b6b4d8:
>>>>> $ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap
>>> --pid=123
>>>>> Virtual Physical Size DumpFileOffset ----------
>>>>> ---------- ---------- -------------- --SNIP-- 0x75b6b000
>>>>> 0x18de0000 0x1000 0x1a3000 --SNIP--
>>>>>
>>>>> The text is indeed at 0x18de04d8 in memory.dmp, but not at
>>> 0x1a34d8 in
>>>>> 123.dmp. Again, it's no where to be found in 123.dmp.
>>>>>
>>>>> Any suggestions..??
>>>>>
>>>>> Many thanks, Adam
>>>>>
>>>>>
>>>>> _______________________________________________ Vol-users
>>>>> mailing list Vol-users(a)volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>
>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>>
>>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>
>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>>>
>>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>
>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>>
>>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>
>>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>>>>
>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>
>>>>
>>>>
>
>>>>>
>
>
>
>>> _______________________________________________ Vol-users
>>> mailing list Vol-users(a)volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>
>>> <mailto:Vol-users@volatilityfoundation.org
> <mailto:Vol-users@volatilityfoundation.org>>
>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iF4EAREKAAYFAlURazkACgkQXnt9v1O0LItfjAD/W7UeZMNiWVRMqeeJftNRaxG2
dpi/c755Qxc6X7PUKU8A/iREkToI9Ad0/GejtG32OpZMLjk0gjhj5XoMxAWuY69D
=JNEv
-----END PGP SIGNATURE-----
I built LiME from the tarball on the project site (not latest svn) and was able to dump memory successfully (type=lime). After many trials and tribulations I was able to get the Volatility profile built for CentOS 5.3x64 (had to remove pmem from the Makefile). I put the profile in the correct directory, and vol.py --info lists it as expected, however when I try to use the profile with the memory image I get an error.
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ vol.py --profile=LinuxCentOS_5_3x64 -f /fun/ir/geriatrix.lime linux_lsmod
Volatile Systems Volatility Framework 2.3_alpha
WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareSnapshotFile: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
JKIA32PagedMemoryPae: No base Address Space
AMD64PagedMemory: No base Address Space
JKIA32PagedMemory: No base Address Space
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
MachOAddressSpace: MachO Header signature invalid
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
VMWareSnapshotFile: Invalid VMware signature: 0xf000ff53
WindowsCrashDumpSpace32: Header signature invalid
JKIA32PagedMemoryPae: Incompatible profile LinuxCentOS_5_3x64 selected
AMD64PagedMemory: Failed valid Address Space check
JKIA32PagedMemory: Incompatible profile LinuxCentOS_5_3x64 selected
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Incompatible profile LinuxCentOS_5_3x64 selected
On a hunch I checked the directory I built the profile in (copied headers & source from the target system):
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ grep cpuinfo *
System.map-2.6.18-128.el5:ffffffff8006f328 t show_cpuinfo
System.map-2.6.18-128.el5:ffffffff80103251 t cpuinfo_open
System.map-2.6.18-128.el5:ffffffff8020eadb t show_cpuinfo_max_freq
System.map-2.6.18-128.el5:ffffffff8020eafa t show_cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff8020f759 t show_cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff802f0bc0 D cpuinfo_op
System.map-2.6.18-128.el5:ffffffff80308420 d proc_cpuinfo_operations
System.map-2.6.18-128.el5:ffffffff803319a0 d cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff80331b20 d cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff80331b60 d cpuinfo_max_freq
Platform running Volatility (2.3_alpha, latest from svn):
Linux hydra 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Source of memory image:
Linux geriatrix.smtps.net 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
What am I missing?
--
chort
I noticed there’s a special ifdef for 2.6.18 kernels, which this is. The alleged redefinitions also appear to be inside of a struct, in which case is that really an error? This compiler (gcc-4.1.2) evidently thinks it is.
make -C //lib/modules/2.6.18-308.4.1.el5.P1/build CONFIG_DEBUG_INFO=y M="/root/scratch/vol-linux" modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-308.4.1.el5.P1-x86_64'
CC [M] /root/scratch/vol-linux/module.o
/root/scratch/vol-linux/module.c:204: error: redefinition of ‘struct module_sect_attr’
/root/scratch/vol-linux/module.c:211: error: redefinition of ‘struct module_sect_attrs’
/root/scratch/vol-linux/module.c:353:5: warning: "STATS" is not defined
/root/scratch/vol-linux/module.c:369:5: warning: "DEBUG" is not defined
make[2]: *** [/root/scratch/vol-linux/module.o] Error 1
make[1]: *** [_module_/root/scratch/vol-linux] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.18-308.4.1.el5.P1-x86_64'
make: *** [dwarf] Error 2
--
bk
Hi all,
I can't quite see what's wrong with my logic here, but I must be missing
something.
Hoping someone can help me out.
I'm looking for a private key in a memory sample (WinXPSP2x86).
Specifically, to find out which process/es is/are accessing it.
I can find the key by searching the raw memory dump (memory.dmp).
As you might expect it's between:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
I generated an offset:string file by using strings.
Then, using the strings plugin I get this output:
$ python vol.py -f memory.dmp --profile=WinXPSP2x86 strings -s pk.txt
Volatility Foundation Volatility Framework 2.4
188435934 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY-----
188435968 [FREE MEMORY:-1] -----END RSA PRIVATE KEY-----
317375704 [kernel:d2ab24d8] -----BEGIN RSA PRIVATE KEY-----
317376575 [kernel:d2ab283f] -----END RSA PRIVATE KEY-----
417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE KEY-----
417204287 [123:75b6b83f] -----END RSA PRIVATE KEY-----
419888606 [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY-----
419888640 [FREE MEMORY:-1] -----END RSA PRIVATE KEY-----
Lovely. So I now do a memdump of process 123:
$ python vol.py -f memory.dmp --profile=WinXPSP2x86 memdump --pid=123
--dump-dir=123
Volatility Foundation Volatility Framework 2.4
************************************************************************
Writing myapp.exe [ 123] to 123.dmp
However, if I search 123.dmp neither the BEGIN or END strings are present.
So I thought I'd try and find it via the virtual address give, 0x75b6b4d8:
$ python vol.py -f memory.dmp --profile=WinXPSP2x86 memmap --pid=123
Virtual Physical Size DumpFileOffset
---------- ---------- ---------- --------------
--SNIP--
0x75b6b000 0x18de0000 0x1000 0x1a3000
--SNIP--
The text is indeed at 0x18de04d8 in memory.dmp, but not at 0x1a34d8 in
123.dmp.
Again, it's no where to be found in 123.dmp.
Any suggestions..??
Many thanks,
Adam
We are very excited to announce that the lineup for BSidesNOLA 2015 is out!
The day will start with a keynote presentation from Chris Rohlf of
Yahoo. It will then continue with three tracks of talks ranging from
application security to memory forensics to malware analysis. These
talks will be given by some of the best researchers in the forensics,
incident response, and security fields.
Full information on the conference can be found at the following page:
http://www.securitybsides.com/w/page/91550808/BSidesNOLA%202015
The cost to attend is $10, and you must register through the
EventBrite link (
https://www.eventbrite.com/e/bsides-nola-2015-tickets-9621601469 ).
Last year was our second year and we had over 150 people attend. We are
expecting closer to 200 this year. For those of you who attended last
year, you know that beyond just great talks and networking, we also
provide very good food and drinks. The close proximity to the French
Quarter (5-10 minute walk) also means that after the conference there
will be plenty of fun and interesting things to do for the rest of the
night.
We hope to see you there and if you have any questions please reply to
this thread or email bsidesnola [@@] gmail.com.
--
Thanks,
Andrew (@attrc)
Our public five day Windows memory forensic classes in Reston in April
and NYC in May are filling fast. If you are looking to take the course
in the US before winter then please contact us ASAP:
http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n
--
Thanks,
Andrew (@attrc)
(Argh, sorry if you just received a messed email. Darn keyboard shortcuts.
Anyway...)
Hi all,
CORPORATE BLOG WARNING!
In case you were dozing and missed it, I posted a blog entry today on using
Volatility in anger.
I used it to analyse a hiberfil.sys and identify a few things about a
keylogger that was running on a client's system.
I tried to make it as detailed as possible, specifically around the
Volatility commands I was using and why I chose them.
http://ctx.is/thank-malware-T
Andrew Case has already been kind enough to provide me with some feedback,
which I shall take the liberty of sharing below:
"When you ran dlldump to grab the WinInstall.dll you could have used '-b
0x000007fef5930000' to only get the DLL you wanted instead of all of
them. That address comes from dlllist output and its where the DLL is
loaded into memory."
"For finding the service you could have tried the 'svcscan' plugin and if
you do 'svcscan -v', it will list the path of the DLL or driver used to
start the service. That is easier than searching through the registry."
Thanks Andrew!
Regards,
Adam
Also,
Imageinfo correctly identified it as
IA32PagedMemoryPae, and suggested Win7SP1x86, but it's easy to miss, just
like everyone reading this thread (myself included). 5:)
Mike 5:)
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
