Closed GoogleCodeExporter closed 9 years ago
Hello,
Processes with 0 threads (0 in the Thds column) and invalid handle table (----
in the Hnds column) have terminated and their address space is destroyed. Thus
you won't be able to dump the exe using procmemdump or procexedump.
You can try to see if the kernel has a cached copy of the 56[1].mp3 file from
disk. To do this, either supply the name as a regex to dumpfiles or find the
offset of the file object. For example:
1) dumpfiles --regex="mp3" --dump-dir=OUTPUT
or
2a) filescan | grep mp3
2b) dumpfiles -Q OFFSET_FROM_FILESCAN --dump-dir=OUTPUT
If there's no cached copy of the disk and the process is no longer running, I'm
afraid you won't be able to get it from the memory dump.
Original comment by michael.hale@gmail.com
on 30 Mar 2014 at 8:21
Dumpfiles and filescan are I guess plugins for volatility.. am I correct?
Original comment by mr.darsh...@gmail.com
on 30 Mar 2014 at 10:04
Yes. They are:
http://code.google.com/p/volatility/wiki/CommandReference23#filescan
http://code.google.com/p/volatility/wiki/CommandReference23#dumpfiles
Original comment by jamie.l...@gmail.com
on 31 Mar 2014 at 1:50
[deleted comment]
Sorry, sent prematurely.
Actually in this case, the regex option may not work (though you can try). The
reason why it might not work is because the process is no longer running (so it
can't get it from the process' own VAD). If it is accessed by another process
(like as a handle opened another process), then you might get lucky and get it
from that process' VAD, but it then again you might not. Try the filescan
option first since it seems more likely to obtain the exe that way.
Original comment by jamie.l...@gmail.com
on 31 Mar 2014 at 1:58
I suspect if it will work, as that mp3 file itself is getting executed.
Original comment by mr.darsh...@gmail.com
on 1 Apr 2014 at 10:27
Original comment by michael.hale@gmail.com
on 25 May 2014 at 5:36
Original issue reported on code.google.com by
mr.darsh...@gmail.com
on 29 Mar 2014 at 1:56Attachments: