4:40 a.m.
Michael Cohen wrote:
Im not sure if you are aware of an effort I have
made some time ago
to update the plugin infrastructure and the entire object model.
I wasn't! That looks brilliant, I'll have a dig into it when I get a
chance (hopefully later this week)...
The intention is to also integrate the pyflag command
line option
processing code into volatility (which im yet to do) but that will
allow plugins to automatically declare any options they want which
will be picked up by the framework at runtime through the class
registry.
Ok, that sounds cool. I've heard of pyflag in passing but haven't ever
sat down and used it. If you have a pointer to a source code page
showing how they do the plugin option declaration bit, I can start
having a look through that too.
My main intention is to port all plugins to this new
framework - its
basically working ok now, but I have dropped the ball on it as new
priorities came up (I just need to find some time to finish it off).
That's the kind of thing I was interested in, are you intending to port
just the internal plugins, or were you wanting to try it on the whole
lot (Jesse's, Moyix's, Andreas', etc)?
Some of the main points of the new codebase:
...
forensics.commands.command is updated to a more flexible layout with
an execute() function which generate data to be consumed by
render_text(), render_html(), render_XXXX() methods to format the data
in an appropriate way.
That sounds useful, since I thought there might be times plugins might
want to make use of the output from other existing plugins...
Address spaces are plugins now so you can
automatically add one in -
Address spaces are layered through a voting system - (see
utils.load_as()) each AS is given an opportunity to instantiate on the
current AS - if it raises we move on, until one works. This allows the
automatic layering of AS's over one another.
I haven't looked at the code yet, but the layering system sounds like
it's automatic, rather than driven by the user, so I'm guessing it just
takes in a filename, and the address spaces are then prioritized over
which one can accept the file format? If that's how it works, it won't
accept other inputs (such as, for firewire, the bus/port and node
numbers you want to address) will it?
After we introduce the global config system this will
allows AS's to
test specific command line options and therefore choose to operate in
a specific way accordingly. This approach allows us to have flexible
command line options as well as automatic AS layering.
Doh! Looks like I spoke too soon! Again, I'll need to read up on the
current config system, but could you briefly explain the idea behind the
global config system?
I appreciate that my efforts may seem a bit neglected
lately, but I am
still keen to continue to develop them . In particular I am looking at
integrating AFF4 support into volatility to facilitate tool
interoperability.
Yeah, I'm happy to help out on this, particularly if it's got some
plugin address space support already there. Where you intending to use
afflib, or is there a pure python implementation for reading AFF
already? I can have a go at wrapping afflib for you, if that'd help
matters (using swig or cython or similar)? The only issue would be,
that I'm not sure how that would translate cross-platform...
If people want to write new code I would be interested
to see how they
feel about the new framework - does it simplify things? is there
something we missed? Ideally I want to port all the plugins to the new
framework and stabilize things a bit and then maybe promote it as a
blessed way to go if others feel its better than the current
architecture.
Yep, I'd be very interested too if existing plugin writers would be
happy with the new framework (to save me tinkering with the old one).
Would people mind porting their plugins to a new architecture, or would
everyone prefer some backwards compatibility when volatility changes
internally?
Mike 5:)