9:26 p.m.
On Mon, Sep 14, 2009 at 6:13 AM, Mike Auty<mike.auty(a)gmail.com> wrote:
All of this, however, would require enhancing the
volatility plugin
interface to accept address spaces (and command line options) rather
than just command line options. It should help reduce a bit of the code
duplication that's going on, but it's quite an invasive change, and
might require plugin rewrites (unless we work in a plugin versioning
system, something like plugins based on forensics.commands.commandv2
maybe?). That'll start to get complicated over time though, and in
either situation the input interface will need to be designed carefully.
I'm still at too early a stage with the code to figure out what the
various plugins out there need/use and what they don't, so I can throw
out/mock up suggestions for how it might work, but it'll need someone
with a bit more knowledge of the system to let me know if I've missed
anything or if the interface isn't right for any reason.
Hi Mike and list,
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. You
can download the new_object branch off svn
http://code.google.com/p/volatility/source/browse/#svn/branches/new_object/…
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.
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).
Some of the main points of the new codebase:
All types are classes, which can be extended and so you can have
specialised methods for each struct (e.g. EPROCESS has list processes
- a method which iterates over the processes, all _LIST_ENTRY structs
have their own iterators as class methods etc).
The use of the NoneObject as a way to simplify writing code which is
more readable - for example in forensics/win32/tasks pslist():
PsActiveProcessHead = DebuggerDataList.dereference_as("_KDDEBUGGER_DATA64"
).PsActiveProcessHead \
or DebuggerDataList.dereference_as("_KDDEBUGGER_DATA32"
).PsActiveProcessHead \
or kpcr.KdVersionBlock.dereference_as("_KDDEBUGGER_DATA32"
).PsActiveProcessHead
To go through a bunch of alternatives for finding the EPROCESS head.
We still retain the automatic overlay for the types which we can
autogenerate from .h files.
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.
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.
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.
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.
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.
Michael.