Hello,

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" [1]) which may help
you reconstruct some state, and Carl Pulley's stack backtrace plugin
[2] 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!
MHL


> _______________________________________________
> Vol-users mailing list
> Vol-users@volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>