Sunday, December 20, 2009

Linux Memory Forensics: task_struct

A while back, I started blogging about /dev/kcore and had gotten up to the task_struct structure, promising to continue talking about it. Well, it's been a while since, but I have not forgotten. This will take more than one post to finish it up, however. Today we will start with a brief introduction. Later posts will continue our exploration concluding with some small real demonstrations.

task_struct

So what is the task_struct structure? It's a structure that contains information about what a process is doing. It allows the kernel to keep track of processes that are running, the states they are in as well as other information needed by that process during execution.

States of the process are also defined in include/linux/sched.h and let the kernel know if the process is running (TASK_RUNNING), interruptible (TASK_INTERRUPTIBLE), uninterruptible (TASK_UNINTERRUPTIBLE), stopped (TASK_STOPPED), being traced by a debugger (TASK_TRACED), or exiting (EXIT_ZOMBIE, EXIT_DEAD).

The task_struct structure also contains identifying information such as the process PID, thread group leader ID. There are also pointers to the parent process' task_struct structure and real_parent task_struct structure for debugging purposes.

Also contained in the task_struct structure is information about other relationships the current process has such as children or siblings.

The executable name excluding the path is also stored in task_struct as well as current directory information and file descriptors.

The signal_struct structure contains information regarding signals for this process as well as tty associated with it.

Also contained in the task_struct is the mm_struct which contains pointers to vm_area_structs which are areas of virtual memory. We will discuss mm_struct and vm_area_struct next time.


References:
Bovet, D., M. Cesati (2000). Understanding the linux kernel. Cambridge: O'Reilly Media.

Rusling, D. Virtual Memory, The Linux Tutorial http://www.linux-tutorial.info/modules.php?name=MContent&pageid=322

Audience Participation Time

While catching up on some reading over at Harlan's blog I started thinking about all of the programming I've done in the past year or so. I really appreciate all of the hard work that goes into developing programs like RegRipper and countless others. It's cool when people are able to share tools they have developed to solve problems they have encountered in the field. It's also cool when people who are in the field are able to solve the problems themselves. I have been thinking about whether or not someone who is working in the field of digital forensics really needs to know a programming language or not. My thoughts are yes (which is influenced by what I see around me and may be biased, considering that I do a lot of programming), but I can see how some people may think differently. The reason why I bring this up is because this question has been in the back of my mind since my last discussion with someone from my alma mater, John Jay College.

John Jay's MS in Forensic Computing has been established since 2004 and it has been evolving ever since its conception. The courses of the program have roughly contained a lot of hands on labs as well as theory (algorithms, cryptography, network protocols etc) and programming (various scripting, C Linux OS) in addition to Criminal Justice courses on laws regarding digital evidence. The question has come up several times as to whether or not the theoretical and programming courses are needed in the background of someone who wants to be a forensic examiner.

When I was in attendance there, the general feeling from *some* (not all) of my colleagues was that they didn't need to learn programming and theory in order to work as a forensic examiner. They said they only needed to learn how to use tool XXX or YYY and get a certification in A, B, and/or C they would be set... Perhaps they were right in some way, as they went on to find jobs where that was enough for them. The debate continues about the direction of the program and whether or not theory and programming are needed and whether or not some kind of certification should be obtained instead.

Having been out in the "real world" for a little while, I see a lot of people who do not need any programming knowledge whatsoever to fulfill their jobs. There are plenty of tools that they are more than proficient in using and I'm not knocking their skills, because they are really quite knowledgeable at what they do. However, there are many times that tool XXX or tool YYY doesn't do whatever it should normally, or it cannot fulfill the job the way the client would like. Having a little programming knowledge helps out immensely in these cases. In addition to the EnScripts I have written at work, I have written a lot of Perl scripts, *nix scripts, Visual Basic programs, SQL queries etc. to get the job done. I have also taken someone else's code in language X, Y or Z and tweaked it to run the way I needed it to for a particular job. Now I concede that it's not every day that I need to write these customizations, but it happens enough that I'm glad I can do it.

I often hear from colleagues at work or elsewhere that they wish they knew how to program in X or Y so they could write their own tools to do something. I have suggested books or websites from which they could glean this wanted knowledge. This often comes with some "stern" advice that they must also practice programming if they want it to stick. Some have taken my advice, some probably just don't have the time for it...

So after much rambling on the subject, what do you think? How often do you wish/are you glad that you knew how to program? How often would it have helped you/does it help you on your job as a forensic examiner/incident responder?

Don't be afraid to comment. I only moderate to keep down on the spam (which I seem to get a lot of for some reason).

Saturday, December 19, 2009

More Misc Stuff

I recently came across a couple of tools that may be helpful to someone and I have created a repository for some of my stuff:

Maatkit

Maatkit has a lot of cool utilities that allow you greater control of MySQL. I recently found it very useful for restoring an extremely large MySQL dump by using the mk-parallel-restore. For information about its feature, either visit the website or you can check out this Linux Magazine article.

HTMLDOC

HTMLDOC allows you create PDF documents of html pages. You can convert pages one page at a time, or as a book. So you could use wget to download the pages of a website recursively, including the graphics and then pdf'ify it into one book with references... pretty useful.

Some of my stuff

Since I'm not sure how much longer I will have my academic website, I am starting to move some of the code that's been hosted there to another location. I have also added a few things that are not listed on the old code page or elsewhere on my academic site, such as a DC3 Image Assember script that worked with the last DC3 challenge (haven't looked at the current one) and a Virus Total hash checker that takes a list of hashes and posts them to Virus Total to build an html report. This last one needs some modification however, since if one is checking lots of files Virus Total starts to report errors... Hopefully I'll have some time to create a new version in the future...

Sunday, December 13, 2009

Misc Stuff

Droid Forensics

For those of you interested in Droid forensics, check out the viaForensics website. There you can find a presentation on Droid forensics (pdf) as well as a regularly updated blog.

New Volatility Plugins

MHL has been busy creating new Volatility plugins. He's modified the malfind plugin to use YARA which allows one to search the process memory for defined patterns (rules). He also has created a new plugin called ldr_modules.py that can detect unlinked LDR_MODULE entries. I suggest reading his blogpost in order to take it all in. You can get the updated plugins here (zip).

Also from his blogpost you'll see that AAron and Moyix rocked the Incident Detection Summit.

MDD will cease to exist

It seems that development and maintenance of the MDD tool will cease. For those of you who are dependent on that tool, windd is a great free alternative.

Into the Boxes

For those of you who might not be aware, there is a new quarterly digital forensic and incident response ezine that is about to come out next month called Into the Boxes. For more updates, check out their twitter feed. If you are interested in contributing to future publications, you can find the guidelines here.