Hi,
I'm the writer of the VMSS file format.
I joined the mailing list since this conversation was posted there,
hopefully I could shad some light over the issue.
as far as i can tell installing the VMSS address space plugin should solve
this issue.
the VMSS format is a hybrid of text and binary encoding, but most of the
memory indeed remains intact (there's an option to compress/encrypt but i
have never seen it used)
the format holds memory regions raw, so it's pretty easy to extract them
directly from the file.
from the tests I've made(a bulk of vmss files from different
ESXi/workstation installations), if there's no *.vmem attached to the image
the memory is probably embedded inside the VMSS/VMSN files and should
be available using my code.
if this isn't the case I'd love to get the VMSS file (if possible) and
check what's wrong with it.
cheers,
- Nir.
On Wed, Jul 4, 2012 at 5:40 PM, Michael Hale Ligh <michael.hale(a)gmail.com>wrote:
Hey Jesse,
Coincidentally there was a code submission today that adds a vmss/vmsn
address space layer to volatility. If you have cycles to test with
your vmss, perhaps you could post some feedback on the issue?
https://code.google.com/p/volatility/issues/detail?id=288
If nothing else, this probably confirms that vmss are a slightly
different format than raw/vmem, thus your experiences with them in the
past is likely not specific to Server2008, its just a format thing
like AW suspected. But just to corroborate, can I ask a few questions:
* Have you tried analyzing a vmss from profiles other than Server2008?
If so, did any of the non-scanning plugins work?
* Have you tried acquiring memory from Server2008 using a method other
than suspending and copying out the vmss?
Thanks!
MHL
On Mon, Jul 2, 2012 at 1:44 PM, Jesse Bowling <jessebowling(a)gmail.com>
wrote:
Hi AAron,
On Mon, Jul 2, 2012 at 1:02 PM, AAron Walters <awalters(a)4tphi.net>
wrote:
1) Hardware Architecture (x86, x64)
x86_64
2) File Format (raw, dmp, etc)
3) How the sample was collected?
This was a VMWare 4.1 virtual machine that was paused, and the vmss file
copied out.
Much later I head referenced that pausing the virtual machine actually
causes a lot of information to be removed from memory due to the way
VMWare
prepares the OS to pause... :( (Can you or anyone
speak to the
truth-iness
of this?)
This line produces output:
vol.py --profile=Win2008R2SP1x64 --dtb=0x187000 -f myimage.vmss psscan
While others like pslist or imageinfo fail to produce output at all, and
appear to hang (or at least, run longer than my patience, several hours
at
one point):
# vol.py --profile=Win2008R2SP1x64 --dtb=0x187000 --verbose -d -f
myimage.vmss pslist
Volatile Systems Volatility Framework 2.1_alpha
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.JKIA32PagedMemory'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.JKIA32PagedMemoryPae'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.legacyintel.IA32PagedMemoryPae'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.legacyintel.IA32PagedMemory'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.standard.FileAddressSpace'>
DEBUG : volatility.obj : Applying modification from
BasicObjectClasses
DEBUG : volatility.obj : Applying modification from
Win7SP01x64Syscalls
DEBUG : volatility.obj : Applying modification from Win7x64Tcpip
DEBUG : volatility.obj : Applying modification from
WinSyscallsAttribute
DEBUG : volatility.obj : Applying modification from WindowsVTypes
DEBUG : volatility.obj : Applying modification from
HiberWin7SP01x64
DEBUG : volatility.obj : Applying
modification from
Win64SyscallVTypes
DEBUG : volatility.obj : Applying modification from WindowsOverlay
DEBUG : volatility.obj : Applying modification from
EThreadCreateTime
DEBUG : volatility.obj : Applying
modification from MalwarePspCid
DEBUG : volatility.obj : Applying modification from
UserAssistVTypes
DEBUG : volatility.obj : Applying
modification from VistaWin7KPCR
DEBUG : volatility.obj : Applying modification from Win7x64Hiber
DEBUG : volatility.obj : Applying modification from
WinPEObjectClasses
DEBUG : volatility.obj : Applying modification from WinPEVTypes
DEBUG : volatility.obj : Applying modification from
WindowsObjectClasses
DEBUG : volatility.obj : Applying modification from
CmdHistoryObjectClasses
DEBUG : volatility.obj : Applying modification from
CmdHistoryVTypesWin7x64
DEBUG : volatility.obj : Applying modification from ExFastRefx64
DEBUG : volatility.obj : Applying modification from MalwareDrivers
DEBUG : volatility.obj : Applying modification from
MalwareObjectClasesXP
DEBUG : volatility.obj : Applying modification from
MalwareSvcRecent
DEBUG : volatility.obj : Applying
modification from
MalwareSvcRecentVTypesx64
DEBUG : volatility.obj : Applying modification from
UserAssistWin7VTypes
DEBUG : volatility.obj : Applying modification from Win2003MMVad
DEBUG : volatility.obj : Applying modification from Win7KDBG
DEBUG : volatility.obj : Applying modification from
Win7ObjectClasses
DEBUG : volatility.obj : Applying
modification from WinPEx64VTypes
DEBUG : volatility.obj : Applying modification from
Windows64Overlay
DEBUG : volatility.obj : Applying
modification from VistaMMVAD
DEBUG : volatility.obj : Applying modification from Win7x64DTB
DEBUG : volatility.utils : Succeeded instantiating
<volatility.plugins.addrspaces.standard.FileAddressSpace object at
0x37dfa10>
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG : volatility.utils : Succeeded instantiating
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x3d86710>
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.JKIA32PagedMemory'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.JKIA32PagedMemoryPae'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.legacyintel.IA32PagedMemoryPae'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.legacyintel.IA32PagedMemory'>
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.standard.FileAddressSpace'>
Offset(V) Name PID PPID Thds Hnds Time
---------- -------------------- ------ ------ ------ ------
-------------------
<here I hit Ctrl-C>
>
> When the scan plugins are successful and the rest fail, it is generally
a
format
issue.
Thanks,
AW
I'm happy to try any advice to get this working; although this is an old
case, I'm sure I'll have more like this and would love to be able to
properly collect and analyze 2008R2 from a VMWare instance...All advice
welcome. :)
Cheers,
Jesse
PS. I still owe you a call ;(.
...Anytime. Once this damnable lack of power passes, I'd even offer to
exchange the call for beer-while-I-pick-your-brain. :)
>
>
> On Mon, 2 Jul 2012, Jesse Bowling wrote:
>
>> Perhaps it's an issue of plugins...I've only worked with a 2008R2
image,
>> but found than many of the plugins failed
to work properly. Some would
(I
>> believe it was the '*scan' ones),
but many did not. I would be
interested
> in
any tips or tricks for analyzing such images as well...
>
> Cheers,
>
> Jesse
>
> On Mon, Jul 2, 2012 at 10:31 AM, Michael Hale Ligh
> <michael.hale(a)gmail.com> wrote:
> Do you have a specific issue with Server 2008 (other than not
> knowing
> it was supported since 2.0)?
>
> On Mon, Jul 2, 2012 at 9:56 AM, Mike Lambert
> <dragonforen(a)hotmail.com> wrote:
> > I know we can't work on Windows Server 2008 with Volatility
> at this time.
> > What products are capable of examining Windows Server 2008?
> >
> > Thanks,
> > Mike
> >
> > _______________________________________________
> > Vol-users mailing list
> > Vol-users(a)volatilityfoundation.org
> >
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
>
>
>
> --
> Jesse Bowling
>
>
>
>
--
Jesse Bowling
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users