Re: [Vol-dev] Re: Adding kernel version / distro generic Linux support to Volatility (long email & code)
24 Sep
2010
24 Sep
'10
6:17 p.m.
Hi Andrew,
On Fri, Sep 24, 2010 at 3:02 PM, Andrew Case <atcuno(a)gmail.com> wrote:
The problem is that in the current implementation, the
file of
structure offsets that is used to make the profiles/vtypes is only the
offsets that the LKM is coded to gather. This is a problem because
every time we need to access a new structure type for some new
functionality, the LKM would need to be run again on all the target
systems in order to get the offsets that the new code requires. This
isn't something we can really deal with and we need a better solution.
Yeah it would be hard to support all the kernel versions.
2) writing something that can scan the kernels files
(not just the
header files, but all files) for a particular kernel tree and all it
would need to do is get the name of every structure and all the
members. This would also be nice b/c then instead of having to run an
LKM to get offsets, you would just have to download a particular
kernel's source package (all distros supply these) and run the script
to get all the structure names and members list. The rest of the code
could then stay how it is and we can support any access to any
structure type.
So the issue is that depending on config defines the structs would
change. The real problem is how do we get the struct offsets for the
current kernel and that really depends on the config files. One way we
can do this is to generate a vtype definition through scanning the
header files and actually vary the struct offsets based on config
options.
This is a little difficult because not only do we need to know the
config options but also how the compiler rounds the offsets for
alignments etc.
Probably a better way is to write a program which:
1) Parses the header files from the kernel headers.
2) Generates the c code for the LKM, compiles and inserts it.
3) Grabs the offsets from the LKM and generates the vtypes
Then we could extract all the offsets of all the members from the header files.
The good news is that if 2) were implemented, every
other piece of the
code can handle addition of structures dynamically, and it would be
trivial to automate updating existing profiles to handle the new
structures. it would be a simple python script that updated every
*_vtype.py file in plugins/overlays/Linux with the new structure
information.
Probably what we need to do also when we parse the header files is
document which config options influence the particular struct. We then
need to characterise profiles not by kernel versions but by config
options. So if we need a new struct we can just add it to the same
profile which is actually affected by it.
So does anyone have a better idea than 2) or does
anyone know how we
can make 2) work well? I know there are a million C file parsers out
there already, so we would just need to be able to get one to output
structures & members in some reasonable way that we can then format
into how gen_vtypes.py expects.
I dont think 2 can work without at least compiling the code because it
depends on compiler alignments etc.
Michael.