option to allow dlllist to print init or mem modules

[GoogleCodeExporter]

right now dlllist is hard-coded to call EPROCESS.get_load_modules(). it may be 
useful to allow calling EPROCESS.get_init_modules() or get_mem_modules() with a 
command-line option. 

only problem is so many plugins inherit from dlllist and we'd then need to 
config.remove_option probably 10+ times just by adding this capability. not 
sure if anyone has solved that problem yet. maybe config.add_option can have a 
"private" tag where plugins that declare options can say they shouldn't be 
inherited?

Original issue reported on code.google.com by michael.hale@gmail.com on 20 Jan 2012 at 3:00

• Merged into: #234

[GoogleCodeExporter]

Hiya,

Could you give me a quick run through of the difference between init_modules, 
mem_modules and normal modules please?

Would the other plugins that make use of dlllist benefit from being able to 
traverse the other module lists instead (ie, no need to remove the option)?  
Would the two lists be better served by a separate plugin, one that inherits 
from dlllist itself?

I can't make a judgement call without knowing more about the differences 
between the lists I'm afraid, but I'm happy to go with whatever other people 
come up with for a solution...

Original comment by mike.auty@gmail.com on 20 Jan 2012 at 3:09

[GoogleCodeExporter]

Sure, The PEB has 3 different _LIST_ENTRY for DLLs:

* InLoadOrderModuleList: dlls listed in the order in which they were loaded 
into a process. This is considered the primary list and thus shown by our 
dlllist command.

* InMemoryOrderModuleList: dlls listed in the order in which they appear in 
memory (lowest to highest base address)

* InInitializationOrderModuleList: dlls listed in the order in which they were 
initialized (they're not always initialized at the same time they're loaded, 
and some aren't initialized at all so this actually contains different data 
than InLoadOrderModuleList)

My LdrModules plugin seeks to compare the DLLs in each list (not only with each 
other but with memory-mapped PE files found via VAD). See 
http://code.google.com/p/volatility/wiki/CommandReference#ldrmodules. 

> Would the other plugins that make use of dlllist benefit from being able to 
traverse the other module lists instead

I don't think so. All the plugins that inherit from Dlllist I think just do so 
for the other command-line arguments (-p, --offset, etc) and for the 
filter_tasks function. 

Not a big deal, we can look at this after x64 stuff, just wanted to log it 
before I forgot. 

Original comment by michael.hale@gmail.com on 20 Jan 2012 at 3:30

[GoogleCodeExporter]

If other plugins won't make use of it, it may make more sense to have two 
separate plugins for handling this?

Either that or add something into the framework that allows plugins to add 
private command line options, but that's too much machinery to think about at 
the moment.  Is this something you want for the 2.1 release?

Original comment by mike.auty@gmail.com on 12 Feb 2012 at 9:08

[GoogleCodeExporter]

Well the malware's ldrmodules pretty much takes care of this. So if we end up 
bringing some malware plugins into trunk, then it will close out this issue. 

Original comment by michael.hale@gmail.com on 12 Feb 2012 at 11:29

[GoogleCodeExporter]

I'm closing this and calling it a duplicate because the LdrModules plugin is 
attached to Issue #234 now, and it lets people distinguish between modules in 
the various lists. 

Original comment by michael.hale@gmail.com on 23 Mar 2012 at 6:23

• Changed state: Duplicate

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 24 Mar 2012 at 12:33