Issue importing classes from other plugins

[GoogleCodeExporter]

Hey guys, I ran into an issue importing some classes from other plugins. 

from volatility.plugins.filescan import FileScan, MutantScan,
DriverScan, PoolScanDriver
from volatility.plugins.psscan import ThrdScan, ThreadScan

I do this because some of my malware plugins (like driverirp) inherit from 
DriverScan etc. Yesterday on Windows, everything was OK:

C:\Volatility-1.4_rc1>python volatility.py -h
[...]
       driverirp    [MALWARE] Driver IRP hook detection
       mutantscandb [MALWARE] mutantscan extension for highlighting
suspicious mutexes

However, the same code (same plugin file and same Volatility revision) on OSX 
caused the following problem:

$ python volatility.py -h
Volatile Systems Volatility Framework 1.4_rc1
Traceback (most recent call last):
  File "volatility.py", line 128, in <module>
    main()
  File "volatility.py", line 90, in main
    MemoryRegistry.Init()
  File "/Users/user/Desktop/Volatility-1.4_rc1/volatility/registry.py",
line 372, in Init
    PLUGIN_COMMANDS = VolatilityCommandRegistry(commands.command, modules)
  File "/Users/user/Desktop/Volatility-1.4_rc1/volatility/registry.py",
line 286, in __init__
    raise Exception("Command {0} has already been defined by
{1}".format(command, self.commands[command]))
Exception: Command mutantscan has already been defined by <class
'volatility.plugins.filescan.MutantScan'>

This morning I updated to revision 483 on Windows and now I get the same 
problem on Windows as well. 

Original issue reported on code.google.com by michael.hale@gmail.com on 29 Sep 2010 at 1:33

[GoogleCodeExporter]

Ok, this is most likely caused because the ModuleRegistry will register any 
class present in a module once the module's been sourced.  This means that the 
line:

from volatility.plugins.filescan import FileScan, MutantScan,
DriverScan, PoolScanDriver

puts those classes directly into your module's namespace, causing them to be 
re-registered and causing the clash.

Could you please try the following instead:

import volatility.plugins.filescan as filescan

class DriverIRP(filescan.DriverScan):

and let us know whether that works?

Original comment by mike.auty@gmail.com on 29 Sep 2010 at 2:22

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 29 Sep 2010 at 2:22

• Changed state: Accepted

[GoogleCodeExporter]

Yep, that solves the problem - thanks. Another thing, which I can enter 
separately if you like (but I figure you might be aware of it) is that plugins 
in the contrib directory aren't registering. For example the 
contrib/plugins/verinfo.py doesn't show up for me using Rev 483. 

Original comment by michael.hale@gmail.com on 29 Sep 2010 at 2:37

[GoogleCodeExporter]

Ok, cool.  I think I might leave the bug open a little longer to discuss 
whether we should fix this, or whether we're happy telling people they can't 
use from...import lines.  Scudette, what's your take on this?

Also, would this go away if we changed the dynamic namespaces to path-based 
namespaces?  My guess is that it won't, in which case we still need to make 
this design decision.

Lastly, you're quite right, the contrib plugins won't register, that's by 
design.  If you want the (highly unsupported, since it's currently just my 
horrible verinfo) contrib plugins registered, you'll need to add them using 
either --plugins or setting it permanently in ~/.volatilityrc.

Original comment by mike.auty@gmail.com on 29 Sep 2010 at 2:46

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I dont expect the issue will go away if we change the import mechanism. This is 
a feature not a bug!

We could remove the restriction on registering the same module twice and that 
would make it go away.

Original comment by scude...@gmail.com on 29 Sep 2010 at 3:06

[GoogleCodeExporter]

No, I definitely don't want to remove that restriction.  We'd end up with 
duplicates, or worse, only let one of them win, and then we'd have to decide 
which one.  So it sounds like we're going to simply enforce that plugins 
authors cannot directly import into their plugins namespace.

I've updated the wiki page on Plugins, and am now marking this as WontFix.

Original comment by mike.auty@gmail.com on 29 Sep 2010 at 4:01

• Changed state: WontFix