Volatility2.3 does not work for mac os x lion10.7.vmem.

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  I use vmware to run mac os x lion10.7 and obtain profile for lion10.7
2.  use vmawre to take a snapshot
3.  put the profile of lion10.7 in volatility..../overlay/mac/
4.  use volatility mac_pslist to obtain processes from the snapshot .vmem or 
.vmsn from vmware

What is the expected output? What do you see instead?
I should see all the processes, but the result is like this:
WARNING : volatility.addrspace: Alignment of VMWareSnapshotFile is too small, 
plugins will be extremely slow
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
 AMD64PagedMemory: No base Address Space
 IA32PagedMemoryPae: No base Address Space
 IA32PagedMemory: No base Address Space
 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
 MachOAddressSpace: MachO Header signature invalid
 LimeAddressSpace: Invalid Lime header signature
 WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
 WindowsCrashDumpSpace64: Header signature invalid
 HPAKAddressSpace - EXCEPTION: Position - address != len(buff) (-1 != 0) in FileAddressSpace
 VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
 VMWareSnapshotFile: Invalid VMware signature: -
 WindowsCrashDumpSpace32: Header signature invalid
 AMD64PagedMemory: No valid DTB found
 IA32PagedMemoryPae: No valid DTB found
 IA32PagedMemory: No valid DTB found
 FileAddressSpace: Must be first Address Space
 ArmAddressSpace: No valid DTB found

What version of the product are you using? On what operating system?
I use volatilit2.3 and mac os x lion10.7

Please provide any additional information below.

Original issue reported on code.google.com by qianfeng...@gmail.com on 3 Oct 2013 at 10:18

[GoogleCodeExporter]

Could you should your full command-line when invoking volatility and also:

1) hexdump the first 512 bytes of the .vmem and .vmsn and paste the output 
2) run the vmwareinfo plugin on the .vmem and .vmsn files and paste the output 

Thanks!

Original comment by michael.hale@gmail.com on 7 Oct 2013 at 1:14

[GoogleCodeExporter]

I'm going to close this issue due to lack of detail/information required to 
investigate the bug. Feel free to re-open if you decide to pursue this further. 

Original comment by michael.hale@gmail.com on 25 Oct 2013 at 12:27

• Changed state: WontFix

[GoogleCodeExporter]

there are two formats of vmware snapshot file. one use vmsn to encapsulate the 
memory along with the meta data, the other format .vmsn only has the metadata 
and .vmem has the raw dump of vm memory. i think the current 
plugins/address/vmware.py can only handle the monolithic one. 

if you can convince volatility that vmem is a raw dump of memory, you might can 
get the desired result.

> python $VOL_BASE/vol.py --filename="Ubuntu13.10_64bit-Snapshot2.vmem"  
--profile=LinuxUbuntu1310_3_12_0-7-genericx64  --debug linux_banner
>
> DEBUG   : volatility.utils    : Succeeded instantiating 
<volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x10cf1f5d0>
> DEBUG   : volatility.utils    : Succeeded instantiating 
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0x10ca09f50>

but 
> python $VOL_BASE/vol.py --filename="Ubuntu13.10_64bit-Snapshot2.vmem"  
--debug volshell
>
> DEBUG   : volatility.utils    : Succeeded instantiating 
<volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x10bf96790>

can only recognize FileAddressSpace, so i believe it might has something to do 
with the profile.

Original comment by dyno.fu on 10 Jan 2014 at 7:55

[GoogleCodeExporter]

yes, dyno.fu, you must specify the correct profile in order to get Volatility 
to realize that it is a Linux memory sample and process it correctly.  The raw 
.vmem file can be processed by Volatility in this case without the vmware 
address space since it's just a 1:1 representation of RAM.

It's not entirely clear if qianfeng04161001 specified the profile in their 
commandline or not because they never wrote back with an answer to MHL's 
request.

Original comment by jamie.l...@gmail.com on 10 Jan 2014 at 8:01