Indeed, There is obviously something I don't understand here : googling "volatility+plugins" returns, as a first entry : http://www.forensicswiki.org/wiki/List_of_Volatility_Plugins Which lists both the plugins and links to their creator's blog's entry about the plugin, when applicable. What else would you need please ? BR 2010/1/2 Matthieu Suiche <msuiche(a)gmail.com>:

Hi Yuhang,   Welcome to the volatility community!! We have recently developed a new framework for memory analysis in the volatiltiy dev branch. I think this would be ideal to write cross platform code (e.g. linux and windows can use the same framework). The biggest problems I see with linux supprot are: -  No use of pool tags so scanning needs to be much more thorough. -  The structs are very variable - for example task_struct can have extra members depending on configuration options even for the same kernel version. This really throws out any analysis because your struct definitions need to be tweaked depending on configuration you dont know. The new framework attempts to address these concerns using profiles. A profile is a specific python class which tells the framework how to access specific structs. For example you can have a kernel 2.6.26 profile, a kernel 2.6.30 profile etc. Then the modules can simply ask for a task_struct and the profile does the specific versioning stuff. The idea is that a profile can run a number of tests on the image to figure out what is likely to be the correct struct layout. For example for task_struct, you can test for sanity of members after the optional members in the struct to figure out if these members are turned on. This means that the profile has some capability of adapting to the specific image - not just the kernel version. Of course this kind of stuff also lends itself to windows profiles such as the difference between sp2 and sp3 and even xp and vista - as versions change structs have different versions and the profile is adapted to these. The new scanning framework is also designed to address concern 1 above with very fast performance even with very thorough testing of structs. This should enable us to write scanners which dont depend on pool tags so much - a definite advantage for windows analysis as well since pool tags are easy to maliciously change. The best advice i have is to just come up with a simple task (like scan for task_structs) and then write a plugin to deal with it - you will learn how the new framework works. If you need some specific help, send an email, or just jump on irc - although I have not been on irc much lately :-( Michael. On Sun, Jan 3, 2010 at 8:09 PM, yuhang gao <rainman1919(a)gmail.com> wrote:

Hi Yuhang, Usually scanning for objects without pool tags means running many tests for sanity of various fields. For example, if a field can only take on one of several values you can eliminate positions which dont make sense. This typically takes a long time as you go from one offset, check it, eliminate it, and move over one byte etc. Our approach in volatility is to order the tests in such a way that we do the tests which are difficult to get randomly first. For example, say you have a certain struct with: struct list_head list; int flags; Suppose the flags is only ever 0 or 1 - so we have two tests to see if the struct makes sense: 1) Follow the flink on the list head and see if the blink of it points to our struct 2) check if flags is 0 or 1 For a number of reasons test 1 is more expensive - because it usually requires paging out and dereferencing pointers. We could do test 2 first and check if each byte is 0 or 1, and if not, move to the next byte and check it. If it is then we do the other test as well and if everything looks good we can guess this is the struct. A much better alternative though is to just run the tests over all bytes of 0 or 1 - so we can automatically skip all types which are not 0 or 1 without even having to check them.  This is much quicker than advancing by one byte each time and redoing the test. This is kind of the logic behind the new scanning system. Look at http://code.google.com/p/volatility/source/browse/branches/Volatility-1.4_b… for an example. Basically you define ScannerCheck classes which have different methods. The skip method allows a check to skip a number of bytes which are definitely not going to match. The check() method returns True if its possible there is a match here, False otherwise. Then a scanner is just a class which collects all these checks together, and this can be applied on the image. It will yield possible matches. Our framework calculates the offsets during run time, so its possible to tweak the profile at run time and reapply it and hopefully converge on something sensible. Definitely - the new volatility framework allows you to apply any number of checks on the scanner, and there is good support for command line options or configuration to allow the user to decide which checks should be used (e.g. fast, pedantic, loose matching etc). At the very least being able to do the same as windows - dump processes, find packets, tasks sockets etc. Yes it is used in a number of plugins. Its not difficult to learn - just look at some of the other plugins. As always documentation is a bit lacking at this point - but we try to make the code as readable as possible. We really would like to push forward the linux problem. It would be nice to have even a small set of plugins which work well on linux images - i think it would benefit pushing the portable side of volatility so we can support more targets. Many kernel structures are well documented, and lots have symbols too. Clearly a deeper understanding of undocumented structures would help, but there are many things we can do with documented stuff too. Have fun, Its always good to have contributions :-) Michael.