move find_module from ssdt to win32/tasks.py

[GoogleCodeExporter]

Ikelos and I discussed the possibility of moving the find_module function in 
plugins/ssdt.py to win32/tasks.py. This is for a similar reason why we moved 
find_space to win32/tasks.py a while ago (because its not specific to ssdt and 
will be used by other plugins in the future). 

Everyone OK with this? Ikelos, if you want, we can add something like this in 
ssdt.py:

# for backward compatibility,  remove after 2.2 
find_module = tasks.find_module

Original issue reported on code.google.com by michael.hale@gmail.com on 24 Jan 2012 at 7:16

Attachments:

• move_find_module.patch

[GoogleCodeExporter]

Makes sense to me :-)

Original comment by jamie.l...@gmail.com on 24 Jan 2012 at 3:41

[GoogleCodeExporter]

This might be ok in the short term. In the long term we should remove
all functions in volatility/win32/ into plugins.  The problem right
now is that plugins are not very flexible and are a real PITA to use
because we cant share code between them. Alternatively we can do:

from volatility.plugin.windows import find_module

This forces us to have a certain directory structure which might
change - but thats probably acceptable.

Ultimately we should have a mechanism to be able to invoke a plugin
for doing even a small task - for example have a plugin called
"find_module", and use it from anything else.

IMHO having specialized functions in win32/ is the wrong way to go
because we do not have the ability to tailor these per profile. We
should simply have command plugins, with the ability to provide
different implementations for different operating systems and versions
(think pslist for example).

Michael.

Original comment by scude...@gmail.com on 24 Jan 2012 at 6:41

[GoogleCodeExporter]

Alright, I'm gonna go ahead and move it for the short term, and then take your 
comments Scudette and open a new issue for a more comprehensive restructure in 
the future. 

Original comment by michael.hale@gmail.com on 25 Jan 2012 at 4:47

[GoogleCodeExporter]

This issue was closed by revision r1307.

Original comment by michael.hale@gmail.com on 25 Jan 2012 at 4:47

• Changed state: Fixed