10:30 a.m.
Hi,
today I had some time to explore my Virtualbox dumpvmcore problem a little bit deeper.
The result:
- Using Volatility from GitHub (git clone …) the described problem occurs, vol.py cannot
analyze the memory dump file. Error message see my old post below.
- Using the Volatility Source Code Archive Release 2.6, downloaded from the
volatilityfoundation.org/ <http://volatilityfoundation.org/> website, the memory
dump could successfully analyzed!
This does occur on my iMac (macOS 10.12.5) and on my test notebook running Debian 8 amd64
(kernel 3.16 and 4.9), using Virtualbox 5.1.22. Memory dump was created by using „debugvm
… dumpvmcore“.
Thomas
Am 05.06.2017 um 08:27 schrieb Thomas
<linux(a)linux4n6.ws>:
Hi,
using the current version from GitHub (-> git pull) I can’t analyze Virtualbox memory
dump files anymore. I’m using Virtualbox v5.1.22 (current release).
I’m using Cuckoo Sandbox (v2.0 and cuckoo-modified) and vol.py doesn’t recognize the
memory.dmp files anymore. Neither within Cuckoo processing nor manually from the command
line. My Virtual machine contains Windows 7 SP1 x86 Pro and the memory dumps could be
analyzed successfully in the past. This happens when using all Win7 profiles.
See some vol.py messages below. Taken from an older memory.dmp file which could be
successfully analyzed by vol.py with cuckoo-modified when it was created in 2016. If
needed I can share the memory dump (2,1 GB, zipped ~640 MB).
Thomas
1)
vol.py -f memory.dmp --profile=Win7SP1x86 pslist
Volatility Foundation Volatility Framework 2.6
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
VMWareMetaAddressSpace: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareAddressSpace: No base Address Space
QemuCoreDumpElf: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
Win10AMD64PagedMemory: No base Address Space
WindowsAMD64PagedMemory: No base Address Space
LinuxAMD64PagedMemory: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64BitMap: Header signature invalid
VMWareMetaAddressSpace: VMware metadata file is not available
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF error: did not find any PT_NOTE segment with VBCORE
VMWareAddressSpace: Invalid VMware signature: 0x464c457f
QemuCoreDumpElf: ELF error: did not find any PT_NOTE segment with CORE
WindowsCrashDumpSpace32: Header signature invalid
Win10AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
WindowsAMD64PagedMemory: Incompatible profile Win7SP1x86 selected
LinuxAMD64PagedMemory: Incompatible profile Win7SP1x86 selected
AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
OSXPmemELF: No PT_LOAD segments found
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Profile does not have valid Address Space check
2)
vol.py -f memory.dmp imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86 (Instantiated with
Win7SP1x86)
AS Layer1 : FileAddressSpace
(/daten/cuckoo-modified/storage/analyses/44/memory.dmp)
PAE type : No PAE
DTB : 0x185000L
KDBG : 0x293c504L
Number of Processors : 0
Image Type (Service Pack) : 0
KUSER_SHARED_DATA : 0xffdf0000L
3)
vol.py -f memory.dmp kdbgscan
Volatility Foundation Volatility Framework 2.6
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp
WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP1x86_23418
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp
WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP1x86
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
**************************************************
Instantiating KDBG using: /daten/cuckoo-modified/storage/analyses/44/memory.dmp
WinXPSP2x86 (5.1.0 32bit)
Offset (P) : 0x293c504
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win7SP0x86
Version64 : 0x293c4dc (Major: 15, Minor: 7601)
PsActiveProcessHead : 0x8294fcb0
PsLoadedModuleList : 0x82956b90
KernelBase : 0x82813000
4)
vol.py -f memory.dmp --profile=Win7SP1x86 vboxinfo
Volatility Foundation Volatility Framework 2.6
ERROR : volatility.debug : Memory Image could not be identified as
['VirtualBoxCoreDumpElf64']
5)
file memory.dmp
memory.dmp: ELF 64-bit LSB core file x86-64, version 1 (SYSV)
_______________________________________________
Vol-users mailing list
Vol-users(a)lists.volatilityfoundation.org
https://lists.volatilityfoundation.org/mailman/listinfo/vol-users
One-click Unsubscribe:
https://lists.volatilityfoundation.org/mailman/options/vol-users/linux%40li…