vmware worstation memory dump not processed by volatility

[melchorpeb]

memory dump copied to /home/cuckooconf/storage/analyses/xx/ is not getting analyzed with volatility. I am using vmware workstation 12 2.5.0 build-4352439. If I copy manually .vmsn file from the snapshot and rename it as memory.vmsn I can execute volatility manually and sucessfully. Is there any way to configure cuckoo to force this copy?. Address spaces detected differ if .vmsn file is not there and specifically VMWareMetaAddressSpace would be missing AS Layer1 : WindowsAMD64PagedMemory (Kernel AS) AS Layer2 : VMWareMetaAddressSpace (Unnamed AS) AS Layer3 : FileAddressSpace (/home/cuckoo/cuckooconf/storage/analyses/47/memory.dmp)

[jbremer]

Interesting! Could you please share the memory.dmp file, provided that we don't necessarily have VMWare setup locally. Thanks!

[melchorpeb]

Sorry for replying so late. I am copying the file manually (.vmsn) into the analyses folder and only then volatility does not complain about "understanding" the memory dump format

memory.dmp.zip truncated from full 4GB memory sample. Kindly let me know if you need the full one and how to upload it. Also the .vmsn file thanks

[doomedraven]

from my experience with vmware that should be vmem no? not vmsn

VMEM – A VMEM file is a backup of the virtual machine’s paging file. It will only appear if the virtual machine is running, or if it has crashed.

VMSN & VMSD files – these files are used for VMware snapshots. A VMSN file is used to store the exact state of the virtual machine when the snapshot was taken. Using this snapshot, you can then restore your machine to the same state as when the snapshot was taken. A VMSD file stores information about snapshots (metadata). You’ll notice that the names of these files match the names of the snapshots.

source

[melchorpeb]

Thanks for your prompt reply. I was following this excerpt from “the art of memory forensics”

Depending on the VMware product/version and how the memory dump was created, you might need to recover more than one file for memory analysis. In some cases, the VM’s memory is entirely contained in a single.vmem file (the raw schema). In other cases, instead of a .vmem, you’ll get a .vmsn (snapshots) or .vmss (saved state), which are proprietary file formats containing memory and metadata (the combined schema). Luckily, Nir Izraeli documented the format well enough to produce an address space for Volatility (see his initial work here: http://code.google.com/p/vmsnparser). To slightly complicate matters, Sebastian Bourne-Richard recently noticed that VMware products often create a .vmem and one of the structured metadata files (the split schema). An entirely new address space needed to be written for Volatility to support this schema, because the .vmem contains physical memory runs, but the metadata file indicates how to piece them back together to create an accurate representation of the guest’s memory. In other words, when acquiring memory from VMware systems, make sure to recover all files with .vmem, .vmsn, and .vmss extensions—because it is not easy to know beforehand which ones(s) contain the required evidence.

Michael Hale Ligh Andrew Case Jamie Levy AAron Walters published by WILEY

It is clear in my deployment that if I don’t copy the vmsn file, volatility cannot understand the underlying format.

Kindly let me know your assessment and a way ahead if possible.

Best regards

Bernardo

From: doomedraven [mailto:notifications@github.com] Sent: Tuesday, 30 January 2018 12:58 To: cuckoosandbox/cuckoo cuckoo@noreply.github.com Cc: MELCHOR PENA, Bernardo Santiago B.S.Melchor-Pena@iaea.org; Author author@noreply.github.com Subject: Re: [cuckoosandbox/cuckoo] vmware worstation memory dump not processed by volatility (#1842)

from my experience with vmware that should be vmem no? not vmsn

VMEM – A VMEM file is a backup of the virtual machine’s paging file. It will only appear if the virtual machine is running, or if it has crashed.

VMSN & VMSD files – these files are used for VMware snapshots. A VMSN file is used to store the exact state of the virtual machine when the snapshot was taken. Using this snapshot, you can then restore your machine to the same state as when the snapshot was taken. A VMSD file stores information about snapshots (metadata). You’ll notice that the names of these files match the names of the snapshots.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/cuckoosandbox/cuckoo/issues/1842#issuecomment-361571978, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AeeQMRBKg_rJ-WlDc2uE_fm0XXPkASPCks5tPwPHgaJpZM4PXQe2.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

[doomedraven]

execute vol imageinfo plugin on any of that unrecognized dump

[jbremer]

Can you analyze it manually with Volatility? That would indicate a bug in Cuckoo.

[melchorpeb]

Dear colleagues,

Thanks for giving me the chance to detail this issue. Yes, I can analyse it manually with volatility. I would even add that if I copy manually the .vmsn from the vm folder into the analysis folder (/home/cuckoo/cuckooconf/analyses/xx/ in my case) once this folder has been created and I rename it to memdump.vmsn, cuckoo is running volatility as per configuration and providing the results after finishing the analysis. That is the reason for my request to copy over this file (if exists) automatically if the machinery is vmware.

Kindly let me know how to upload the full memory .vmem and .vmsn if needed (4 Gb aprox.)

Regards

Bernardo

From: Jurriaan Bremer [mailto:notifications@github.com] Sent: Sunday, 04 February 2018 10:19 To: cuckoosandbox/cuckoo cuckoo@noreply.github.com Cc: MELCHOR PENA, Bernardo Santiago B.S.Melchor-Pena@iaea.org; Author author@noreply.github.com Subject: Re: [cuckoosandbox/cuckoo] vmware worstation memory dump not processed by volatility (#1842)

Can you analyze it manually with Volatility? That would indicate a bug in Cuckoo.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/cuckoosandbox/cuckoo/issues/1842#issuecomment-362892796, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AeeQMbaysOWmRna1PyOMPY5JWLpfs5dqks5tRXX-gaJpZM4PXQe2.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

[melchorpeb]

As requested

before copying the vmsn file into the analysis folder. Volatility fails.

cuckoo@forensic009:/opt/cuckoo/cuckooconf/storage/analyses/97$ vol.py imageinfo -f ./memory.dmp

Volatility Foundation Volatility Framework 2.5

INFO : volatility.debug : Determining profile based on KDBG search...

      Suggested Profile(s) : Win7SP1x64, Win2008R2SP1x64_632B36E0, Win2008R2SP0x64, Win7SP1x64_632B36E0, Win2008R2SP1x64, Win7SP0x64

                 AS Layer1 : WindowsAMD64PagedMemory (Kernel AS)

                 AS Layer2 : FileAddressSpace (/opt/cuckoo/cuckooconf/storage/analyses/97/memory.dmp)

                  PAE type : No PAE

                       DTB : 0x187000L

                      KDBG : 0xf80002c47110L

      Number of Processors : 1

 Image Type (Service Pack) : 1

            KPCR for CPU 0 : 0xfffff80002c48d00L

         KUSER_SHARED_DATA : 0xfffff78000000000L

       Image date and time : 2018-02-05 20:36:20 UTC+0000

 Image local date and time : 2018-02-05 21:36:20 +0100

after copying the vmsn file. Volatility works fine.

cuckoo@forensic009:/opt/cuckoo/cuckooconf/storage/analyses/97$ vol.py imageinfo -f ./memory.dmp

Volatility Foundation Volatility Framework 2.5

INFO : volatility.debug : Determining profile based on KDBG search...

      Suggested Profile(s) : Win7SP1x64, Win2008R2SP1x64_632B36E0, Win2008R2SP0x64, Win7SP1x64_632B36E0, Win2008R2SP1x64, Win7SP0x64

                 AS Layer1 : WindowsAMD64PagedMemory (Kernel AS)

                 AS Layer2 : VMWareMetaAddressSpace (Unnamed AS)

                 AS Layer3 : FileAddressSpace (/opt/cuckoo/cuckooconf/storage/analyses/97/memory.dmp)

                  PAE type : No PAE

                       DTB : 0x187000L

                      KDBG : 0xf80002c47110L

      Number of Processors : 2

 Image Type (Service Pack) : 1

            KPCR for CPU 0 : 0xfffff80002c48d00L

            KPCR for CPU 1 : 0xfffff880009f0000L

         KUSER_SHARED_DATA : 0xfffff78000000000L

       Image date and time : 2018-02-05 20:36:20 UTC+0000

 Image local date and time : 2018-02-05 21:36:20 +0100

--

From: MELCHOR PENA, Bernardo Santiago Sent: Monday, 05 February 2018 08:42 To: 'cuckoosandbox/cuckoo' reply@reply.github.com Subject: RE: [cuckoosandbox/cuckoo] vmware worstation memory dump not processed by volatility (#1842)

Dear colleagues,

Thanks for giving me the chance to detail this issue. Yes, I can analyse it manually with volatility. I would even add that if I copy manually the .vmsn from the vm folder into the analysis folder (/home/cuckoo/cuckooconf/analyses/xx/ in my case) once this folder has been created and I rename it to memdump.vmsn, cuckoo is running volatility as per configuration and providing the results after finishing the analysis. That is the reason for my request to copy over this file (if exists) automatically if the machinery is vmware.

Kindly let me know how to upload the full memory .vmem and .vmsn if needed (4 Gb aprox.)

Regards

Bernardo

From: Jurriaan Bremer [mailto:notifications@github.com] Sent: Sunday, 04 February 2018 10:19 To: cuckoosandbox/cuckoo cuckoo@noreply.github.com<mailto:cuckoo@noreply.github.com> Cc: MELCHOR PENA, Bernardo Santiago B.S.Melchor-Pena@iaea.org<mailto:B.S.Melchor-Pena@iaea.org>; Author author@noreply.github.com<mailto:author@noreply.github.com> Subject: Re: [cuckoosandbox/cuckoo] vmware worstation memory dump not processed by volatility (#1842)

Can you analyze it manually with Volatility? That would indicate a bug in Cuckoo.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/cuckoosandbox/cuckoo/issues/1842#issuecomment-362892796, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AeeQMbaysOWmRna1PyOMPY5JWLpfs5dqks5tRXX-gaJpZM4PXQe2.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

[melchorpeb]

Anything else needed from my side?.

[jbremer]

We haven't had the time to look into this yet, but if you could share the actual memory dump (through Google Drive, WeShare, or wherever you like), that'd greatly help. Thanks.

[hunt3vil]

I've experienced the same issue with ESXi 6.5.

I am unable to provide a memory image but I ran a few tests: 1) .vmem file alone - volatility fails to parse correctly 2) .vmem file + .vmsn file (same file name) - volatility correctly parses the memory image. All plugins I tested return correctly including raw2dmp to transform the vmem into a core dump. 3) rename .vmsn to .anything - volatility fails to parse the memory image 4) rename .vmem to .dmp but keep .vmsn - volatility correctly parses the memory image.

VMware provides a tool vmss2core to combine the two files but it is not open source therefore it cannot be distributed with Cuckoo.

So the simple hacky solution would be to download the .vmsn file from the data store, rename to memory.vmsn and drop it in the memory folder so you'd end up with both memory.dmp and memory.vmsn

I'm happy to put some code together if you agree with this approach.

[melchorpeb]

Thanks a lot for your reply I was using the hack you propose to get the job done. I will check the vmss2core tool but the idea would be to add to cuckoo code the copy of .vmsn file in case it exists.

Regards

Bernardo Santiago Melchor Pena IT Security Engineer Infrastructure Services Section Division of Information Technology Department of Management International Atomic Energy Agency T: (+43-1)2600-22924

From: Cristian Iankovszky [mailto:notifications@github.com] Sent: Wednesday, 27 June 2018 12:41 To: cuckoosandbox/cuckoo cuckoo@noreply.github.com Cc: MELCHOR PENA, Bernardo Santiago B.S.Melchor-Pena@iaea.org; Author author@noreply.github.com Subject: Re: [cuckoosandbox/cuckoo] vmware worstation memory dump not processed by volatility (#1842)

I've experienced the same issue with ESXi 6.5.

I am unable to provide a memory image but I ran a few tests:

1. .vmem file alone - volatility fails to parse correctly
2. .vmem file + .vmsn file (same file name) - volatility correctly parses the memory image. All plugins I tested return correctly including raw2dmp to transform the vmem into a core dump.
3. rename .vmsn to .anything - volatility fails to parse the memory image
4. rename .vmem to .dmp but keep .vmsn - volatility correctly parses the memory image.

VMware provides a tool vmss2core to combine the two files but it is not open source therefore it cannot be distributed with Cuckoo.

So the simple hacky solution would be to download the .vmsn file from the data store, rename to memory.vmsn and drop it in the memory folder so you'd end up with both memory.dmp and memory.vmsn

I'm happy to put some code together if you agree with this approach.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/cuckoosandbox/cuckoo/issues/1842#issuecomment-400627962, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AeeQMYDCh90XGI7iSD03kdgIs7ONqzAnks5uA2E4gaJpZM4PXQe2.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.