[Vol-users] Analyzing diasassembly with little information
olroy123 at yahoo.com
Tue Apr 10 20:43:45 CDT 2012
Thanks for the thorough replies! I should of known part of it got paged. That's probably a sign I need to finish reading Windows Internals. :)
This is the first piece of malware I'm analyzing and I loaded it into Olly today and could see it decrypting a PE file from the the resource section. Pretty freaking cool! I'll play around with Volatility again tomorrow...
Thanks again for setting me straight!
From: Michael Hale Ligh <michael.hale at gmail.com>
To: fd ksdf <olroy123 at yahoo.com>
Cc: "vol-users at volatilityfoundation.org" <vol-users at volatilityfoundation.org>
Sent: Monday, April 9, 2012 10:07 AM
Subject: Re: [Vol-users] Analyzing diasassembly with little information
The same thing anyone ever does with a disassembly ;-)
Malfind will locate private (i.e. not backed by a file, no DLL),
committed, executable memory, but interpretation of the instructions
is up to a human.
As Andrew said yesterday, your best bet is to find some code paths
that lead to the region in question. Thread registers at the time of
the memory dump may be available in _ETHREAD.Tcb.TrapFrame (see
"Investigating Windows Threads with Volatility" ) which may help
you reconstruct some state, and Carl Pulley's stack backtrace plugin
 can give you some guidance.
Regarding symbols, if the memory you're analyzing is part of a dll,
exe, sys, then extract the PE with dlldump, procexedump, or moddump
respectively and look at the debug section to get the PDB path which
will give you symbols (or just load the extracted PE in IDA Pro and
let it resolve the symbols for you). If the memory you're analyzing is
*not* part of a dll, exe, sys (for example shell code or a block of
injected functions) then you can't expect to have symbols anyway
(though it'd be cool if attackers supplied symbols with shell code
The memory unreadable error is because 0x806f000-0x806ffff is paged to
disk (i.e. not memory resident at the time the dump was acquired).
Luckily, most malicious code spans more than two pages (0x2000) so
don't be discouraged by one missing page. Instead, dump the whole vad
region (using the vaddump command) and analyze it as a whole. What you
see below is just the instructions at the start of the range
0x8070000, not the whole thing.
Also if this is injected code, there's a chance its been injected into
more than one process, so you might check if the missing page is
available in the memory of another process.
Hope it helps and good luck!
> Vol-users mailing list
> Vol-users at volatilityfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vol-users