10:20 a.m.
Hi all,
I wrote a little tool to convert a KVM/libvirt dump to a raw memory
file (https://github.com/juergh/lqs2mem) Volatility seems to be able
to handle the resulting file just fine for small dumps but not so much
the larger they get. Specifically, things start to break when the
memory size of the VM approaches 4 GB. I double and triple checked my
code and can't find anything obviously wrong (like using a 32bit
variable for a 64bit address or pointer). I also don't think that
Volatility has a problem with larger dumps since it can handle a 8 GB
memory dump that I obtained using some other means. I'm just running
out of ideas and am looking for some help or suggestions on how to
debug this further.
In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs below):
1) imageinfo and pslist return the correct output for VMs with less than 3588 MB
2) pslist only returns a single task (System) for VMs larger than 3587 MB
3) imageinfo shows only 1 processor (when there are actually two) for
VMs larger than 3712 MB (give or take)
Any help is greatly appreciated.
Thanks
...Juerg
VM memory size: 3584 MB:
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3584.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800017fb0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff800017fcd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:24:50 UTC+0000
Image local date and time : 2013-07-16 12:24:50 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa8002a7cb30 System 4 0 70 396
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80030f09d0 smss.exe 220 4 4 31
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80034574d0 csrss.exe 300 292 9 339
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003465b30 wininit.exe 352 292 7 93
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003469b30 csrss.exe 368 344 8 76
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800349c280 winlogon.exe 412 344 5 83
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034a7160 services.exe 448 352 17 215
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b4b30 lsass.exe 464 352 9 458
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b64f0 lsm.exe 472 352 12 194
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800350cb30 svchost.exe 584 448 17 355
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003522060 svchost.exe 664 448 13 221
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003547060 svchost.exe 724 448 16 312
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003552b30 LogonUI.exe 744 412 8 157
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003572b30 svchost.exe 812 448 43 782
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003594b30 svchost.exe 856 448 14 234
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800359b9b0 svchost.exe 900 448 8 128
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035b3060 svchost.exe 940 448 19 361
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035fcb30 svchost.exe 372 448 16 259
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035f6b30 spoolsv.exe 1048 448 8 89
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003679650 blnsvr.exe 1076 448 7 100
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035e5450 svchost.exe 1116 448 4 50
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003732b30 WmiPrvSE.exe 1364 584 15 294
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003767250 svchost.exe 1484 448 12 241
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80037df620 WmiApSrv.exe 1684 448 7 112
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa80037a56c0 WmiPrvSE.exe 1716 584 7 105
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa8003763270 WmiPrvSE.exe 1764 584 7 175
0 0 2013-07-16 12:24:38 UTC+0000
VM memory size: 3588 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3588.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf8000180e0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff8000180fd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:50:59 UTC+0000
Image local date and time : 2013-07-16 12:50:59 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa800308d9e0 System 4 0 68 275
------ 0 2013-07-16 12:50:55 UTC+0000
VM memory size: 3840 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3840.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800018400a0
Number of Processors : 1
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff80001841d00L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:28:55 UTC+0000
Image local date and time : 2013-07-16 12:28:55 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa80033849e0 System 4 0 72 --------
------ 0 2013-07-16 12:28:47 UTC+0000
11:40 a.m.
Hi Juerg,
Are you taking into account the memory gaps that normally occur just
below the 4gb mark? Usually these need to be padded by zero in a raw
image but in many image file formats (which support sparse memory
ranges) they are not. So you usually need to identify the memory
ranges in the image format, and then pad the gaps with zeros to
maintain the raw offsets.
Michael.
On 7 August 2013 16:20, Juerg Haefliger <juergh(a)gmail.com> wrote:
Hi all,
I wrote a little tool to convert a KVM/libvirt dump to a raw memory
file (https://github.com/juergh/lqs2mem) Volatility seems to be able
to handle the resulting file just fine for small dumps but not so much
the larger they get. Specifically, things start to break when the
memory size of the VM approaches 4 GB. I double and triple checked my
code and can't find anything obviously wrong (like using a 32bit
variable for a 64bit address or pointer). I also don't think that
Volatility has a problem with larger dumps since it can handle a 8 GB
memory dump that I obtained using some other means. I'm just running
out of ideas and am looking for some help or suggestions on how to
debug this further.
In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs below):
1) imageinfo and pslist return the correct output for VMs with less than 3588 MB
2) pslist only returns a single task (System) for VMs larger than 3587 MB
3) imageinfo shows only 1 processor (when there are actually two) for
VMs larger than 3712 MB (give or take)
Any help is greatly appreciated.
Thanks
...Juerg
VM memory size: 3584 MB:
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3584.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800017fb0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff800017fcd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:24:50 UTC+0000
Image local date and time : 2013-07-16 12:24:50 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa8002a7cb30 System 4 0 70 396
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80030f09d0 smss.exe 220 4 4 31
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80034574d0 csrss.exe 300 292 9 339
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003465b30 wininit.exe 352 292 7 93
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003469b30 csrss.exe 368 344 8 76
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800349c280 winlogon.exe 412 344 5 83
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034a7160 services.exe 448 352 17 215
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b4b30 lsass.exe 464 352 9 458
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b64f0 lsm.exe 472 352 12 194
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800350cb30 svchost.exe 584 448 17 355
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003522060 svchost.exe 664 448 13 221
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003547060 svchost.exe 724 448 16 312
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003552b30 LogonUI.exe 744 412 8 157
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003572b30 svchost.exe 812 448 43 782
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003594b30 svchost.exe 856 448 14 234
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800359b9b0 svchost.exe 900 448 8 128
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035b3060 svchost.exe 940 448 19 361
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035fcb30 svchost.exe 372 448 16 259
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035f6b30 spoolsv.exe 1048 448 8 89
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003679650 blnsvr.exe 1076 448 7 100
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035e5450 svchost.exe 1116 448 4 50
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003732b30 WmiPrvSE.exe 1364 584 15 294
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003767250 svchost.exe 1484 448 12 241
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80037df620 WmiApSrv.exe 1684 448 7 112
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa80037a56c0 WmiPrvSE.exe 1716 584 7 105
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa8003763270 WmiPrvSE.exe 1764 584 7 175
0 0 2013-07-16 12:24:38 UTC+0000
VM memory size: 3588 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3588.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf8000180e0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff8000180fd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:50:59 UTC+0000
Image local date and time : 2013-07-16 12:50:59 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa800308d9e0 System 4 0 68 275
------ 0 2013-07-16 12:50:55 UTC+0000
VM memory size: 3840 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3840.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800018400a0
Number of Processors : 1
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff80001841d00L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:28:55 UTC+0000
Image local date and time : 2013-07-16 12:28:55 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa80033849e0 System 4 0 72 --------
------ 0 2013-07-16 12:28:47 UTC+0000
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
2:46 p.m.
Hi Michael,
Hi Juerg,
Are you taking into account the memory gaps that normally occur just
below the 4gb mark? Usually these need to be padded by zero in a raw
image but in many image file formats (which support sparse memory
ranges) they are not. So you usually need to identify the memory
ranges in the image format, and then pad the gaps with zeros to
maintain the raw offsets.
I'm not handling the memory gap below the 4GB in any special way.
Without going into much details, the KVM snapshot file contains
sections with page addresses and page data (or a single fill byte for
empty/unused pages). I'm using the page addresses to seek in the
output file and dump either the page data or a page full of fill
bytes. The fact that the resulting raw file has the correct size is an
indication that this is working correctly, or am I missing something?
I also checked the page addresses (aka seek offsets) to make sure I'm
not writing the same location multiple times.
...Juerg
Michael.
On 7 August 2013 16:20, Juerg Haefliger <juergh(a)gmail.com> wrote:
> Hi all,
>
> I wrote a little tool to convert a KVM/libvirt dump to a raw memory
> file (https://github.com/juergh/lqs2mem) Volatility seems to be able
> to handle the resulting file just fine for small dumps but not so much
> the larger they get. Specifically, things start to break when the
> memory size of the VM approaches 4 GB. I double and triple checked my
> code and can't find anything obviously wrong (like using a 32bit
> variable for a 64bit address or pointer). I also don't think that
> Volatility has a problem with larger dumps since it can handle a 8 GB
> memory dump that I obtained using some other means. I'm just running
> out of ideas and am looking for some help or suggestions on how to
> debug this further.
>
> In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs below):
>
> 1) imageinfo and pslist return the correct output for VMs with less than 3588 MB
> 2) pslist only returns a single task (System) for VMs larger than 3587 MB
> 3) imageinfo shows only 1 processor (when there are actually two) for
> VMs larger than 3712 MB (give or take)
>
> Any help is greatly appreciated.
>
> Thanks
> ...Juerg
>
>
>
>
> VM memory size: 3584 MB:
>
> Determining profile based on KDBG search...
>
> Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
> Win7SP0x64, Win2008R2SP1x64
> AS Layer1 : AMD64PagedMemory (Kernel AS)
> AS Layer2 : FileAddressSpace
> (/var/lib/libvirt/qemu/save/win-3584.ram)
> PAE type : PAE
> DTB : 0x187000L
> KDBG : 0xf800017fb0a0
> Number of Processors : 2
> Image Type (Service Pack) : 1
> KPCR for CPU 0 : 0xfffff800017fcd00L
> KPCR for CPU 1 : 0xfffff880009b8000L
> KUSER_SHARED_DATA : 0xfffff78000000000L
> Image date and time : 2013-07-16 12:24:50 UTC+0000
> Image local date and time : 2013-07-16 12:24:50 +0000
>
> Offset(V) Name PID PPID Thds Hnds
> Sess Wow64 Start Exit
> ------------------ -------------------- ------ ------ ------ --------
> ------ ------ ------------------------------
> ------------------------------
> 0xfffffa8002a7cb30 System 4 0 70 396
> ------ 0 2013-07-16 12:24:33 UTC+0000
> 0xfffffa80030f09d0 smss.exe 220 4 4 31
> ------ 0 2013-07-16 12:24:33 UTC+0000
> 0xfffffa80034574d0 csrss.exe 300 292 9 339
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa8003465b30 wininit.exe 352 292 7 93
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa8003469b30 csrss.exe 368 344 8 76
> 1 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa800349c280 winlogon.exe 412 344 5 83
> 1 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa80034a7160 services.exe 448 352 17 215
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa80034b4b30 lsass.exe 464 352 9 458
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa80034b64f0 lsm.exe 472 352 12 194
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa800350cb30 svchost.exe 584 448 17 355
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa8003522060 svchost.exe 664 448 13 221
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa8003547060 svchost.exe 724 448 16 312
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa8003552b30 LogonUI.exe 744 412 8 157
> 1 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa8003572b30 svchost.exe 812 448 43 782
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa8003594b30 svchost.exe 856 448 14 234
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa800359b9b0 svchost.exe 900 448 8 128
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa80035b3060 svchost.exe 940 448 19 361
> 0 0 2013-07-16 12:24:34 UTC+0000
> 0xfffffa80035fcb30 svchost.exe 372 448 16 259
> 0 0 2013-07-16 12:24:35 UTC+0000
> 0xfffffa80035f6b30 spoolsv.exe 1048 448 8 89
> 0 0 2013-07-16 12:24:35 UTC+0000
> 0xfffffa8003679650 blnsvr.exe 1076 448 7 100
> 0 0 2013-07-16 12:24:35 UTC+0000
> 0xfffffa80035e5450 svchost.exe 1116 448 4 50
> 0 0 2013-07-16 12:24:35 UTC+0000
> 0xfffffa8003732b30 WmiPrvSE.exe 1364 584 15 294
> 0 0 2013-07-16 12:24:35 UTC+0000
> 0xfffffa8003767250 svchost.exe 1484 448 12 241
> 0 0 2013-07-16 12:24:35 UTC+0000
> 0xfffffa80037df620 WmiApSrv.exe 1684 448 7 112
> 0 0 2013-07-16 12:24:36 UTC+0000
> 0xfffffa80037a56c0 WmiPrvSE.exe 1716 584 7 105
> 0 0 2013-07-16 12:24:36 UTC+0000
> 0xfffffa8003763270 WmiPrvSE.exe 1764 584 7 175
> 0 0 2013-07-16 12:24:38 UTC+0000
>
>
> VM memory size: 3588 MB
>
> Determining profile based on KDBG search...
>
> Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
> Win7SP0x64, Win2008R2SP1x64
> AS Layer1 : AMD64PagedMemory (Kernel AS)
> AS Layer2 : FileAddressSpace
> (/var/lib/libvirt/qemu/save/win-3588.ram)
> PAE type : PAE
> DTB : 0x187000L
> KDBG : 0xf8000180e0a0
> Number of Processors : 2
> Image Type (Service Pack) : 1
> KPCR for CPU 0 : 0xfffff8000180fd00L
> KPCR for CPU 1 : 0xfffff880009b8000L
> KUSER_SHARED_DATA : 0xfffff78000000000L
> Image date and time : 2013-07-16 12:50:59 UTC+0000
> Image local date and time : 2013-07-16 12:50:59 +0000
>
> Offset(V) Name PID PPID Thds Hnds
> Sess Wow64 Start Exit
> ------------------ -------------------- ------ ------ ------ --------
> ------ ------ ------------------------------
> ------------------------------
> 0xfffffa800308d9e0 System 4 0 68 275
> ------ 0 2013-07-16 12:50:55 UTC+0000
>
>
> VM memory size: 3840 MB
>
> Determining profile based on KDBG search...
>
> Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
> Win7SP0x64, Win2008R2SP1x64
> AS Layer1 : AMD64PagedMemory (Kernel AS)
> AS Layer2 : FileAddressSpace
> (/var/lib/libvirt/qemu/save/win-3840.ram)
> PAE type : PAE
> DTB : 0x187000L
> KDBG : 0xf800018400a0
> Number of Processors : 1
> Image Type (Service Pack) : 1
> KPCR for CPU 0 : 0xfffff80001841d00L
> KUSER_SHARED_DATA : 0xfffff78000000000L
> Image date and time : 2013-07-16 12:28:55 UTC+0000
> Image local date and time : 2013-07-16 12:28:55 +0000
>
> Offset(V) Name PID PPID Thds Hnds
> Sess Wow64 Start Exit
> ------------------ -------------------- ------ ------ ------ --------
> ------ ------ ------------------------------
> ------------------------------
> 0xfffffa80033849e0 System 4 0 72 --------
> ------ 0 2013-07-16 12:28:47 UTC+0000
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
12:01 p.m.
Hello Juerg,
Your issues seems to be similar to the one I had with VmWare Workstation.
To solve the problem, I have wrote a vmem address space that use vmss
metadata to pad the hardware range:
https://code.google.com/p/volatility/issues/detail?id=272#c17
Maybe you need to do something similar with KVM.
It depends on the hardware installed on your PC, but most of the time (on
my PCs), the range to pad was between 0xC0000000 - 0x100000000
Sebastien
On Wed, Aug 7, 2013 at 7:20 AM, Juerg Haefliger <juergh(a)gmail.com> wrote:
Hi all,
I wrote a little tool to convert a KVM/libvirt dump to a raw memory
file (https://github.com/juergh/lqs2mem) Volatility seems to be able
to handle the resulting file just fine for small dumps but not so much
the larger they get. Specifically, things start to break when the
memory size of the VM approaches 4 GB. I double and triple checked my
code and can't find anything obviously wrong (like using a 32bit
variable for a 64bit address or pointer). I also don't think that
Volatility has a problem with larger dumps since it can handle a 8 GB
memory dump that I obtained using some other means. I'm just running
out of ideas and am looking for some help or suggestions on how to
debug this further.
In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs
below):
1) imageinfo and pslist return the correct output for VMs with less than
3588 MB
2) pslist only returns a single task (System) for VMs larger than 3587 MB
3) imageinfo shows only 1 processor (when there are actually two) for
VMs larger than 3712 MB (give or take)
Any help is greatly appreciated.
Thanks
...Juerg
VM memory size: 3584 MB:
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3584.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800017fb0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff800017fcd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:24:50 UTC+0000
Image local date and time : 2013-07-16 12:24:50 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa8002a7cb30 System 4 0 70 396
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80030f09d0 smss.exe 220 4 4 31
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80034574d0 csrss.exe 300 292 9 339
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003465b30 wininit.exe 352 292 7 93
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003469b30 csrss.exe 368 344 8 76
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800349c280 winlogon.exe 412 344 5 83
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034a7160 services.exe 448 352 17 215
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b4b30 lsass.exe 464 352 9 458
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b64f0 lsm.exe 472 352 12 194
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800350cb30 svchost.exe 584 448 17 355
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003522060 svchost.exe 664 448 13 221
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003547060 svchost.exe 724 448 16 312
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003552b30 LogonUI.exe 744 412 8 157
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003572b30 svchost.exe 812 448 43 782
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003594b30 svchost.exe 856 448 14 234
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800359b9b0 svchost.exe 900 448 8 128
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035b3060 svchost.exe 940 448 19 361
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035fcb30 svchost.exe 372 448 16 259
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035f6b30 spoolsv.exe 1048 448 8 89
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003679650 blnsvr.exe 1076 448 7 100
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035e5450 svchost.exe 1116 448 4 50
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003732b30 WmiPrvSE.exe 1364 584 15 294
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003767250 svchost.exe 1484 448 12 241
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80037df620 WmiApSrv.exe 1684 448 7 112
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa80037a56c0 WmiPrvSE.exe 1716 584 7 105
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa8003763270 WmiPrvSE.exe 1764 584 7 175
0 0 2013-07-16 12:24:38 UTC+0000
VM memory size: 3588 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3588.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf8000180e0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff8000180fd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:50:59 UTC+0000
Image local date and time : 2013-07-16 12:50:59 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa800308d9e0 System 4 0 68 275
------ 0 2013-07-16 12:50:55 UTC+0000
VM memory size: 3840 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3840.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800018400a0
Number of Processors : 1
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff80001841d00L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:28:55 UTC+0000
Image local date and time : 2013-07-16 12:28:55 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa80033849e0 System 4 0 72 --------
------ 0 2013-07-16 12:28:47 UTC+0000
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
4 p.m.
Sébastien,
It depends on the hardware installed on your PC, but
most of the time
(on my PCs), the range to pad was between 0xC0000000 - 0x100000000 <
For real hardware the physical memory map is programmed into the memory
controller by the BIOS. It depends on the physical hardware, OEM design
choices and BIOS manufacturer. The operating system also may (usually
does) remove some pages from the physical memory map. The most notable
example is so-called "unmanaged" memory on x86 Windows systems with more
than 4 GiB of RAM. But virtually every PC has at least some reserved
pages.
With virtual environments it depends on how the emulated BIOS constructs
the virtual memory map. Hyper-V has a lot of synthetic device drivers
that do not require PCI physical address space. The reserved space just
below 4 GiB is greatly reduced.
Intel and AMD systems used to be fairly uniform in their memory map, but
that is no longer the case. We are encountering an increasing number of
systems that reclaim physical address space above 0xC0000000 or that
have multiple small memory holes between 0xB0000000 and 0xC0000000.
What is worse, in some cases the processor will generate a bugcheck if
you try to read from these memory "holes."
The long and the short of it is that physical memory acquisition is
becoming increasingly complex. There is no simple one-size-fits-all
solution.
Regards,
George.
4:51 p.m.
Thanks George,
*With virtual environments it depends on how the emulated BIOS constructs
the virtual memory map. *
On multiple PCs running Vmware workstation, my gap was always
between 0xC0000000 - 0x100000000.
Also, in vmware-tools for Linux (C:\Program Files (x86)\VMware\VMware
Workstation\linux.iso), the script vmware-tools-distrib\bin\
vmware-config-tools.pl contains these lines:
if (is64BitKernel()) {
$gSystem{'page_offset'} = '0000010000000000';
} else {
$gSystem{'page_offset'} = 'C0000000';
}
Maybe vmware emulated BIOS always reserve the range 0xC0000000 -
0x100000000?
Sebastien
On Wed, Aug 7, 2013 at 1:00 PM, George M. Garner Jr. <
ggarner_online(a)gmgsystemsinc.com> wrote:
Sébastien,
It depends on the hardware installed on your PC,
but most of the time
(on my PCs), the range to pad was between 0xC0000000 - 0x100000000 <
For real hardware the physical memory map is programmed into the memory
controller by the BIOS. It depends on the physical hardware, OEM design
choices and BIOS manufacturer. The operating system also may (usually
does) remove some pages from the physical memory map. The most notable
example is so-called "unmanaged" memory on x86 Windows systems with more
than 4 GiB of RAM. But virtually every PC has at least some reserved pages.
With virtual environments it depends on how the emulated BIOS constructs
the virtual memory map. Hyper-V has a lot of synthetic device drivers that
do not require PCI physical address space. The reserved space just below 4
GiB is greatly reduced.
Intel and AMD systems used to be fairly uniform in their memory map, but
that is no longer the case. We are encountering an increasing number of
systems that reclaim physical address space above 0xC0000000 or that have
multiple small memory holes between 0xB0000000 and 0xC0000000. What is
worse, in some cases the processor will generate a bugcheck if you try to
read from these memory "holes."
The long and the short of it is that physical memory acquisition is
becoming increasingly complex. There is no simple one-size-fits-all
solution.
Regards,
George.
______________________________**_________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilesystems.**com/mailman/listinfo/vol-users<http://lis…
5:38 p.m.
Sébastien,
Here is the physical memory block for an x64 Windows 7 SP1 Hyper-V VM
that is equipped with 4 GiB of memory:
1: kd> dq nt!MmPhysicalMemoryBlock L1
fffff800`0290d038 fffffa83`007bbfc0
1: kd> dq /c1 fffffa83`007bbfc0
fffffa83`007bbfc0 00000000`00000003 NumberOfRanges
fffffa83`007bbfc8 00000000`000fff8e NumberOfPages
fffffa83`007bbfd0 00000000`00000001 StartingPFN
fffffa83`007bbfd8 00000000`0000009e NumberOfPFNs
fffffa83`007bbfe0 00000000`00000100 StartingPFN
fffffa83`007bbfe8 00000000`000f7ef0 NumberOfPFNs
fffffa83`007bbff0 00000000`00100000 StartingPFN
fffffa83`007bbff8 00000000`00008000 NumberOfPFNs
As you can see, the reserved areas are as follows:
0x00000000 - 0x00001000
0x0009f000 - 0x00100000
0xf7ff0000 - 0x100000000
Further detail may be obtained using the !arbiter command the results of
which are displayed at the end of this mail. As you can see, only a
small area is reserved for the virtual PCI bus. There is nothing that
specifically requires that any space be reserved below 4 GiB. That has
been the convention, but PC makers and VM vendors are free to make their
own design decisions. And in some cases they do so, as can be seen.
Obviously, the only sound way to reconstruct a systems physical memory
space is if the metadata describing the space is stored along with the
data bits. If you are working with a specific VM or PC you can make
intelligent guesses, as you did with VMWare. However, generalizing
those assumptions to other VMs and PCs is probably not going to work.
Regards,
George.
1: kd> !arbiter 2
DEVNODE fffffa83028a5b80 (HTREE\ROOT\0)
Memory Arbiter "RootMemory" at fffff800028d89c0
Allocated ranges:
0000000000000000 - 000000000009ffff
0000000000000000 - 0000000000000fff C 00000000 <Not on bus>
0000000000000000 - 000000000009ffff CB fffffa83028d6bb0
00000000000a0000 - 00000000000bffff S fffffa8302962600 (pci)
00000000000c0000 - 00000000000dffff B fffffa83028d6bb0
00000000000e0000 - 00000000000fffff B fffffa83028d6bb0
0000000000100000 - 00000000f7ffffff B fffffa83028d6bb0
00000000f8000000 - 00000000fffbffff S fffffa8302962600 (pci)
00000000fffc0000 - 00000000ffffffff B fffffa83028d6bb0
0000000fe0000000 - 0000000fffefffff S fffffa8302962600 (pci)
0001000000000000 - ffffffffffffffff 00000000 <Not on bus>
Possible allocation:
< none >
DEVNODE fffffa83028db710 (ACPI\PNP0A03\0)
Memory Arbiter "PCI Memory (b=0)" at fffffa83028e0960
Allocated ranges:
0000000000000000 - 000000000009ffff 00000000 <Not on bus>
00000000000a0000 - 00000000000bffff S fffffa8303dc0480
00000000000c0000 - 00000000f7ffffff 00000000 <Not on bus>
00000000f8000000 - 00000000fbffffff fffffa83028e6a10
(s3cap)
00000000fec00000 - 00000000fec00fff
00000000fec00000 - 00000000fec003ff CB fffffa8302874e30
00000000fec00000 - 00000000fec00fff CBA fffffa83028ea060
00000000fee00000 - 00000000fee00fff
00000000fee00000 - 00000000fee003ff CB fffffa8302874e30
00000000fee00000 - 00000000fee00fff CBA fffffa83028ea060
00000000fffc0000 - 0000000fdfffffff 00000000 <Not on bus>
0000000fff700000 - 0000000fffefffff fffffa830293c6c0
(SynthVid)
0000000ffff00000 - ffffffffffffffff
0000000ffff00000 - ffffffffffffffff C 00000000 <Not
on bus>
0001000000000000 - ffffffffffffffff C 00000000 <Not
on bus>
Possible allocation:
< none >
2:08 a.m.
Thanks to all of you for your help.
I managed to get this going by simply adding a 512 MB 'hole' between
3.5 GB and 4 GB (per suggestion from the QEMU developers), i.e.,
moving all pages above 3.5 GB up by 512 MB. It's hard-coded and might
break in the future when KVM and/or its BIOS change but its good
enough for the moment.
...Juerg
On Wed, Aug 7, 2013 at 11:38 PM, George M. Garner Jr.
<ggarner_online(a)gmgsystemsinc.com> wrote:
Sébastien,
Here is the physical memory block for an x64 Windows 7 SP1 Hyper-V VM that
is equipped with 4 GiB of memory:
1: kd> dq nt!MmPhysicalMemoryBlock L1
fffff800`0290d038 fffffa83`007bbfc0
1: kd> dq /c1 fffffa83`007bbfc0
fffffa83`007bbfc0 00000000`00000003 NumberOfRanges
fffffa83`007bbfc8 00000000`000fff8e NumberOfPages
fffffa83`007bbfd0 00000000`00000001 StartingPFN
fffffa83`007bbfd8 00000000`0000009e NumberOfPFNs
fffffa83`007bbfe0 00000000`00000100 StartingPFN
fffffa83`007bbfe8 00000000`000f7ef0 NumberOfPFNs
fffffa83`007bbff0 00000000`00100000 StartingPFN
fffffa83`007bbff8 00000000`00008000 NumberOfPFNs
As you can see, the reserved areas are as follows:
0x00000000 - 0x00001000
0x0009f000 - 0x00100000
0xf7ff0000 - 0x100000000
Further detail may be obtained using the !arbiter command the results of
which are displayed at the end of this mail. As you can see, only a small
area is reserved for the virtual PCI bus. There is nothing that
specifically requires that any space be reserved below 4 GiB. That has been
the convention, but PC makers and VM vendors are free to make their own
design decisions. And in some cases they do so, as can be seen. Obviously,
the only sound way to reconstruct a systems physical memory space is if the
metadata describing the space is stored along with the data bits. If you
are working with a specific VM or PC you can make intelligent guesses, as
you did with VMWare. However, generalizing those assumptions to other VMs
and PCs is probably not going to work.
Regards,
George.
1: kd> !arbiter 2
DEVNODE fffffa83028a5b80 (HTREE\ROOT\0)
Memory Arbiter "RootMemory" at fffff800028d89c0
Allocated ranges:
0000000000000000 - 000000000009ffff
0000000000000000 - 0000000000000fff C 00000000 <Not on bus>
0000000000000000 - 000000000009ffff CB fffffa83028d6bb0
00000000000a0000 - 00000000000bffff S fffffa8302962600 (pci)
00000000000c0000 - 00000000000dffff B fffffa83028d6bb0
00000000000e0000 - 00000000000fffff B fffffa83028d6bb0
0000000000100000 - 00000000f7ffffff B fffffa83028d6bb0
00000000f8000000 - 00000000fffbffff S fffffa8302962600 (pci)
00000000fffc0000 - 00000000ffffffff B fffffa83028d6bb0
0000000fe0000000 - 0000000fffefffff S fffffa8302962600 (pci)
0001000000000000 - ffffffffffffffff 00000000 <Not on bus>
Possible allocation:
< none >
DEVNODE fffffa83028db710 (ACPI\PNP0A03\0)
Memory Arbiter "PCI Memory (b=0)" at fffffa83028e0960
Allocated ranges:
0000000000000000 - 000000000009ffff 00000000 <Not on bus>
00000000000a0000 - 00000000000bffff S fffffa8303dc0480
00000000000c0000 - 00000000f7ffffff 00000000 <Not on bus>
00000000f8000000 - 00000000fbffffff fffffa83028e6a10
(s3cap)
00000000fec00000 - 00000000fec00fff
00000000fec00000 - 00000000fec003ff CB fffffa8302874e30
00000000fec00000 - 00000000fec00fff CBA fffffa83028ea060
00000000fee00000 - 00000000fee00fff
00000000fee00000 - 00000000fee003ff CB fffffa8302874e30
00000000fee00000 - 00000000fee00fff CBA fffffa83028ea060
00000000fffc0000 - 0000000fdfffffff 00000000 <Not on bus>
0000000fff700000 - 0000000fffefffff fffffa830293c6c0
(SynthVid)
0000000ffff00000 - ffffffffffffffff
0000000ffff00000 - ffffffffffffffff C 00000000 <Not on
bus>
0001000000000000 - ffffffffffffffff C 00000000 <Not on
bus>
Possible allocation:
< none >
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
1 p.m.
Hi Juerg,
Welcome to the mailing list! One of the things I typically do when I'm
developing a new address space or conversion script is to capture a sample
in raw format from the machine before and after the debug/virtualization
dump. Then I can use those samples as points of reference for comparision
and to potentially find any unexpected shifting, etc. Was the 8GB sample
you mentioned collected from the same system?
AW
On Wed, 7 Aug 2013, Juerg Haefliger wrote:
Hi all,
I wrote a little tool to convert a KVM/libvirt dump to a raw memory
file (https://github.com/juergh/lqs2mem) Volatility seems to be able
to handle the resulting file just fine for small dumps but not so much
the larger they get. Specifically, things start to break when the
memory size of the VM approaches 4 GB. I double and triple checked my
code and can't find anything obviously wrong (like using a 32bit
variable for a 64bit address or pointer). I also don't think that
Volatility has a problem with larger dumps since it can handle a 8 GB
memory dump that I obtained using some other means. I'm just running
out of ideas and am looking for some help or suggestions on how to
debug this further.
In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs below):
1) imageinfo and pslist return the correct output for VMs with less than 3588 MB
2) pslist only returns a single task (System) for VMs larger than 3587 MB
3) imageinfo shows only 1 processor (when there are actually two) for
VMs larger than 3712 MB (give or take)
Any help is greatly appreciated.
Thanks
...Juerg
VM memory size: 3584 MB:
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3584.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800017fb0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff800017fcd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:24:50 UTC+0000
Image local date and time : 2013-07-16 12:24:50 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa8002a7cb30 System 4 0 70 396
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80030f09d0 smss.exe 220 4 4 31
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80034574d0 csrss.exe 300 292 9 339
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003465b30 wininit.exe 352 292 7 93
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003469b30 csrss.exe 368 344 8 76
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800349c280 winlogon.exe 412 344 5 83
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034a7160 services.exe 448 352 17 215
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b4b30 lsass.exe 464 352 9 458
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b64f0 lsm.exe 472 352 12 194
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800350cb30 svchost.exe 584 448 17 355
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003522060 svchost.exe 664 448 13 221
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003547060 svchost.exe 724 448 16 312
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003552b30 LogonUI.exe 744 412 8 157
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003572b30 svchost.exe 812 448 43 782
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003594b30 svchost.exe 856 448 14 234
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800359b9b0 svchost.exe 900 448 8 128
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035b3060 svchost.exe 940 448 19 361
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035fcb30 svchost.exe 372 448 16 259
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035f6b30 spoolsv.exe 1048 448 8 89
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003679650 blnsvr.exe 1076 448 7 100
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035e5450 svchost.exe 1116 448 4 50
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003732b30 WmiPrvSE.exe 1364 584 15 294
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003767250 svchost.exe 1484 448 12 241
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80037df620 WmiApSrv.exe 1684 448 7 112
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa80037a56c0 WmiPrvSE.exe 1716 584 7 105
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa8003763270 WmiPrvSE.exe 1764 584 7 175
0 0 2013-07-16 12:24:38 UTC+0000
VM memory size: 3588 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3588.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf8000180e0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff8000180fd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:50:59 UTC+0000
Image local date and time : 2013-07-16 12:50:59 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa800308d9e0 System 4 0 68 275
------ 0 2013-07-16 12:50:55 UTC+0000
VM memory size: 3840 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3840.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800018400a0
Number of Processors : 1
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff80001841d00L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:28:55 UTC+0000
Image local date and time : 2013-07-16 12:28:55 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa80033849e0 System 4 0 72 --------
------ 0 2013-07-16 12:28:47 UTC+0000
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
4108
days inactive
4117
days old
vol-users@lists.volatilityfoundation.org
8 comments
5 participants
participants (5)
-
AAron Walters -
George M. Garner Jr. -
Juerg Haefliger -
Michael Cohen -
Sebastien Bourdon-Richard