Upcoming version of volatility
by Michael Cohen
Hi All,
As you may be aware I have been working on the new upcoming version
of volatility. It has been a massive cleanup of the code base and a
rewrite of much of the underlying architecture. The main thrust of
this release is the development of a framework, which can easily be
integrated into other tools as a library. This mean removing all
globals, removing command line flags and removing any automated
magical stuff that happens behind the scenes. Redesign of the object
model so its more consistent with a library, and style cleanup of the
codebase to improve its quality.
The following is the summary of the main architectural changes:
- Domain specific profiles. The profiles are no longer associated with
the address spaces. You can have any number of profiles alive at the
same time (e.g. kernel space and user space). Profiles are simply
templates for instantiating CTypes on an address space. Therefore a
profile is not specifically tied into a particular address space in
any way. This also removes the obj_vm/native_vm confusion for
dereferencing across address spaces, as address space switching is now
done explicitly.
- Removal of VolatilityMagic - there are basically two use cases for
these - the first is just a profile specific constant, and the second
is the automated running of code to retrieve a value (e.g. kdbg scan).
Constants are now parts of the profile itself (for example in linux
the system map is stored as profile constants), and automated code
running is removed in favor of explicit plugin execution (which is
made easier now).
- The plugin architecture is updated - Previously it was very hard to
share code between plugins - this is now very simple. For example, any
plugin can call any other plugin. Plugins also export more intelligent
functions than calculate() - so they can be used as modules
themselves. Plugins are now also selectable according to the profile -
for example we have a linux "pslist" and a windows "pslist", so just
calling plugins.pslist() will get the right module depending on the
selected profile.
- The registry code is updated to remove automatic importation of
files. This allows for much simpler and more efficient packaging as
core modules are referenced directly. Loading of external plugins can
now be done via a Load() plugin. This architecture is better for use
in a framework.
- The main user interface is based on ipython. This makes the user
interface much easier to use - with command line completion helping
users throughout. Users can also run arbitrary code on the results and
we now can have light weight extension scripts - without needing to
write a proper plugin.
http://code.google.com/p/volatility/wiki/ScudettesBranch has some
information about the new interface, but I will post a screencast soon
that shows more.
- Style cleanups. This refactor cleans up the style. In particular
issues such as lines over 80 chars and legacy calls to base class
methods (i.e. not using super) are cleaned up.
- The new release includes memory acquisition tools as well as linux support.
What should we do about it?
The current version is a major rewrite of the current code base - it
is not a patch to the current codebase and retrofitting it would be
too difficult. We need to port the existing modules to the new code
base and clean up this code. All developers need to consider the
changes present in this version and how they apply to the next
volatility release. If people have general architectural
suggestions/disagreements etc we need to resolve these now. We then
need to create a new volatility 3.0 branch and complete the porting of
the modules to it.
I have made a spreadsheet to document what modules are converted to
the new framework and which are not done yet:
https://docs.google.com/spreadsheet/ccc?key=0Athc84IflFGbdHpGcmNjWFkycFN4Q0…
I am making slow progress on porting the code over to the new code
base. I am happy with the way things are looking, and the new code is
looking very nice. If people want to help, please let me know and I
will provide editing rights and you can put your name next to each
item to take ownership.
I suggest all major new development to go to this branch (such as new
modules etc).
I am looking to complete a release candidate in the next month or two,
as there is really not that much left to do. I will be running a
workshop at DFRWS about volatility and will want to have the new
release definitely out by then.
Thanks,
Michael.
13 years, 1 month
- 1
- 0
Memory analysis of a process
by Akash Kulkarni
Hi,
I want to do memory analysis for a single process running in the
memory. Is this possible with "Volatility" ?
I am calling this executable file from a perl script. Now when this
executable file will get loaded in the memory, I want to see how much
memory it consumes.
Furthermore, I want to plot a graph for this executable process
against memory consumed by the executable file (for it's entire life
cycle).
This is very important since I need to compare three different tools
against their memory requirement.
Thanks in advance.
Regards,
Akash.
13 years, 1 month
- 3
- 2