12:22 p.m.
Hello,
With quite a bit of help & patience from ikelos, I have created a
skeleton for generic Linux support for Vol. In order to show the
complete process of how it currently works, I am going to demonstrate
the process from start to finish (a simple process listing of a memory
image). The main reason I am sending this email is because I hope
that the volatility developers can review what I have so far, comment,
and ultimately we can finalize a skeleton that can then be rapidly
added on to develop tens of useful plugins for Linux memory analysis.
I already have code for quite a bit of kernel analysis, so my whole
goal of this is to fit it inside the framework and ultimately get it
accepted into Volatility stable.
So the process of my system currently works like this (will be
illustrated with code and examples after):
1) Gather all of the structure offsets from a kernel through an LKM
2) Feed the LKM's output to a python script that generates a vtype /
profile automatically based on structure definitions kept in another
file
3) Make a profile python file for these types
4) Now we have a profile for the specific type and plugins can use it as normal
after this point we can run plugins, so now to illustrate all of this:
1) Gathering of offsets is facilitated in this LKM. (I added a simple
license & author header to each file due to ikelos's advice to do so)
http://gist.github.com/595600
This module works by gathering the offset of members from every
structure necessary to do analysis. It also adds the size of each
structure into the output file in order to have correct profile
information. Note that this code is kernel version aware and will be
able to get offsets from any 2.6.x version. Also, it only gathers a
small number of structures & members now b/c that is all that is
needed in order to list processes. Once the code is reviewed by devs,
other structures can be quickly added.
2) Feed this 1) to a python script
So at this step we need to generate the profile and we also need to
set the DTB. Even though it may seem odd, its not possible in a 2.6.x
generic way to get the cr3/dtb of the init process in order to
automatically acquite the dtb, even inside the kernel module. This is
because the DTB we want (swapper_pg_dir) is not exported and the mm
structure that references it (init_mm) stopped being exported in
2.6.26. Also, you can't get a reference to init_mm through init_task,
because after initialize init_task->mm is set to NULL. Because of all
this, we have to accept the DTB value on the commandline to this
script, but this is easily obtained by grepping for 'swapper_pg_dir'
in the corresponding System.map file for the kernel.
Here is the python script to generate the output, note that the
linux_kernel_types file will take work as well to support all
structures & members needed for full analysis, but that it will be
stable for all of 2.6.x once set:
http://gist.github.com/595589
http://gist.github.com/595598
Here is using it on the test kernel:
http://gist.github.com/595594
as you can see it has all the kernel structures and uses
volatility_magic to store the DTB. This means the users never have to
deal with DTB and it will still with the profile forever and will auto
load on vol initialization
now that we have this:
3) make a simple python profile
With the help of ikelos, I have made the profile system very easy to
add support for new kernel versions. To support this there is an
abstract Linux Profile that does everything but set the
abstract_types:
http://gist.github.com/595604
and the simple profile needed to support the debian test image:
http://gist.github.com/595606
4) time to write a plugin!
this is the simple plugin I came up with to list processes & it uses
profile just generated:
http://gist.github.com/595607
note that the system map parsing stuff will go into a utility file
once devs approve of the current way of doing things or we change
stuff around. its very quick to parse so its not an issue to parse it
on every load or eventually have the system map hash table pickled in
the cache
With that, we have distro / version generic Linux support. We also
have an easy method to generate profiles for any Linux System.
Please send any comments / suggestions, as once its approved I would
like to quickly add support for a large number of more plugins &
kernels