Thursday, October 2, 2008

pstree - a volatility plugin

I have been lurking on the volatility irc channel (#volatility @ and I overheard a challenge to make a pstree like plugin. I thought this would be a great way to learn more of the code base.

The volatility code base is very nice and well written. It can be improved however, and this plugin demonstrates what I propose to make the code more reusable. As can be seen producing the data and rendering it are separated into 2 methods. The calculate() method just produces a data structure, and the render method output the data to the screen. This architecture is better because other tools can then just over ride the render method to output the data in any format they see fit - e.g. XML, HTML etc.

Ed: After posting the initial version I had lots of discussions from the IRC channel. The next challenge was to recover the path and name of the binary for each task. There are lots of ways to do this and I was offered 3:

First off we can get the CommandLine from the PEB. This is what volatility already does in dlllist for example

Second we can get the ImagePathName from the PEB (as moyix and msuiche point out - thanks guys for the help). Note that for those two options we need to switch to process address space first.

Lastly aschuster pointer out that same information is also stored in the auditing subsystem SeAuditProcessCreationInfo (thanks aschuster).

So there are many ways to skin this cat. Here is a sample output. Hopefully all these agree with each other.

Wednesday, July 16, 2008

Digital Forensics Research Workshop Challenge

Every year the DFRWS guys put on a great forensic challenge and this year was no different. While last years challenge was very hard and not that realistic, this years challenge was designed to reflect what many people would experience in their work. The challenge was a simulated incident which involved network traffic, some file forensics and Linux memory forensics.

On the positive side it is quite easy to get something from the challenge. Pretty much anyone can have a go with this challenge and get something (You can probably even solve it using commercial tools !!). Thats a very good aspect of this years challenge - I'm sure it will be used for training for many years to come.

The negative side is that it becomes difficult to do something extra ordinary in order to win the challenge. Just getting the right answer is not going to cut it because many others can get the right answer. We needed to get the right answer in style... Our tools need to be better and look nicer and also be easier to use. Unless, of course, we missed something blatantly obvious....

This year I was lucky enough to be involved with the great team of David Collett and Aaron Walters. These guys are brilliant and each brings their own unique skills to the table. I believe this made our submission well rounded and certainly better than what each of us could have done on our own. Regardless of whether we are lucky enough to place first, I think we did great and certainly developed pyflag in new directions and added some very cool features - so it was well worth it.

We actually took guidance from the perp (now i sound like a real CSI) and decided to use google docs for collaborative editing. Thats a great product and works very well considering that we tried to collaborate on a 50 page document with many screen shots and images. As a bonus you can publish the document when you are finished:

Getting the paper in on time was a tremendous effort and well done to the team for foregoing sleep and time with their loved ones to make it happen....

It turned out to be a really cool document with a pyflag walkthrough of a realistic scenario. Hopefully people can read it and get a better idea of how to use pyflag from it.