discrepencies between moddump, dlldump, and dumpfiles

I discovered these issues while working on the DFIRCon Memory Analysis 
Challenge (http://dfir.to/APT-MEMORY), but I suspect they're all generic. It 
could even be just me, but the tool's certainly not doing what I'd expect it 
to. These may even be considered three to five linked, but separate issues, two 
of which (adding -n options to dlldump and moddump) are really enhancement 
requests.

When dumping either kernel drivers via moddump, or DLLs via dlldump, I would 
expect there to be a way to readily identify the file path associated with a 
given saved DLL or driver, similar to the way that the -n option works for 
dumpfiles (I'm not sure why that's not the default, but that's a really minor 
quibble) But instead, you have to save the output, and then cross-reference the 
numbers against the dumped filenames to determine what each was supposed to be 
linked to.

Secondly, I would have expected all the files dumped by dlldump and moddump (or 
at least all those which map directly to an on-disk filename in the output of 
dlldump or moddump), to show up in the output directory of dumpfiles. Maybe I'm 
just being clueless here, but shouldn't there be some correspondence? It took 
me a few minutes, but I found one instance of what I would have thought should 
be the same file in the outputs from dlldump and dumpfiles: 
module.456.2361558.61b80000.dll, and file.456.0x81dda608.zlib1.dll.img (with 
reference to the memory image linked above). The two files are definitely not 
the same, however. I think they're identical up to a point, but they're not the 
same length: 75264 bytes vs. 77824 bytes. The difference appears to begin at 
about offset 0x12000, which is before the end of the smaller file. from that 
point, it's padded with nulls.

Should there be close correspondence here, or am I completely misinterpreting 
something? This may be two to three issues

1: Should files dumped via dumpfiles, and those which appear to correspond to 
them that are dumped by dlldump or modules, actually be identical?

2: Should there be an entry dumped by dumpfiles for every entry dumped by 
dlldump that corresponds to a file on disk?

3: Should dumpfiles dump out kernel drivers? (If so, should there be one dumped 
for each file dumped by moddump which corresponds to a file on disk?)

I'm using the 2.3 svn version 3581.

Thanks
John

Original issue reported on code.google.com by johnmcca...@gmail.com on 30 Jan 2014 at 7:00

John, 

1. No, dumpfiles is dumping files from the ntfs cache manager, which is the 
representation of the file as it was on disk. The other plugins dump files 
after they're loaded into memory (i.e. IAT is patched, global variables 
initialized, etc)

2. No, the two plugins are getting data from two entirely different sources. 
The cache manager doesn't cache everything, and it also expands/contracts based 
on cache size so files once in the cache can get pushed out over time (even if 
the corresponding DLL isn't unloaded from process memory) 

3. If the kernel drivers are cached by the cache manager, yes. But No to the 
second part of your question. 

Hope that clears things up for you.

Original comment by michael.hale@gmail.com on 1 Feb 2014 at 5:07

Changed state: Invalid

Dik1s / volatility

discrepencies between moddump, dlldump, and dumpfiles #473