search

pi-2r / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

Early --cache option can cause user plugins to fail #399

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
Start by ensuring .cache/volatility/<image> is removed.
1. vol.py --cache --plugins=<dir with dummy plugin> -f <image> imageinfo
2. vol.py --cache --plugins=<dir with dummy plugin> -f <image> dummy
3. vol.py --plugins=<dir with dummy plugin> --cache -f <image> dummy

What is the expected output? What do you see instead?
1. here imageinfo works as one might expect and checking 
~/.cache/volatility/<image> we can see some caching effects (e.g. 
tests/kdbgscan is created)
2. here we fail with the error:
  ERROR   : __main__            : You must specify something to do (try -h)
3. here the dummy plugin works as expected (with --debug specified, we can see 
that caching has been enabled)

What version of the product are you using? On what operating system?
Python 2.7; Volatility r3202

Please provide any additional information below.
Code for dummy plugin is as follows:

import volatility.commands as commands

class Dummy(commands.Command):
  def calculate(self):
    return []

  def render_text(self, outfd, data):
    outfd.write("dummy plugin ran\n")

Original issue reported on code.google.com by carl.pulley on 2 Apr 2013 at 10:01

GoogleCodeExporter commented 9 years ago

Original comment by michael.hale@gmail.com on 2 Apr 2013 at 1:14

GoogleCodeExporter commented 9 years ago 
I believe that's not the --cache option that's causing the problem, but more 
likely the --plugins option not coming first.  Can you please try the following:

vol.py -f <image> --plugins=<dir with dummy plugin> dummy

I suspect you'll see a similar error message (either the same, or one about no 
image being provided).  At the moment, because of a legacy decision to allow 
plugin options to come in any order on the command line, we run multiple 
parsing runs over the command line.  Unfortunately, due to the way the plugin 
mechanisms works, once the plugins have been loaded (ie, after the first option 
parse) the plugins path is fixed and can't be changed.  As such, if --plugins 
wasn't already recognized, its settings won't be used.

I'm not sure if there's already a bug for this.  If this is the problem, it's 
unlikely to get fixed in 2.3.  The best recommendation is to either set 
--plugins in the environment, or in a configuration file which volatility will 
read automatically.

Original comment by mike.auty@gmail.com on 2 Apr 2013 at 2:46

GoogleCodeExporter commented 9 years ago 
I recall hitting the plugins issue previously, but it didn't dawn on me that 
its order relative to --cache would be the issue here (duh!).

Unless you want to use this issue as a reminder regarding the --plugin problem, 
I'm happy for this issue to be closed.

Original comment by carl.pulley on 2 Apr 2013 at 3:03

GoogleCodeExporter commented 9 years ago 
No, I think we're aware the current option parsing system has some issues.  
It's already on our radar to get sorted for the next big version.  Thanks for 
reporting it though...

Original comment by mike.auty@gmail.com on 2 Apr 2013 at 6:09