Archives For Linux Forensics

Like many of you, I have been watching the development of memory forensics over the last two years with a sense of awe.  It is amazing how far the field has come since the day Chris Betz, George Garner and Robert-Jan Moral won the 2005 DFRWS forensics challenge.   Of course, similar to other forensic niches, the majority of progress has been made on Windows memory forensics.  There is good reason for this.  Memory can be extremely fickle, with layouts and structures changing on a whim.   As an example, the symbols file for Windows 7 SP1x86 is 330MB, largely due to it needing to support major changes that can occur in every service pack and patch.  The fact that we have free tools such as Volatile Systems Volatility and Mandiant Redline supporting memory images of arbitrary size from (nearly) every modern version of Windows is nothing short of miraculous.

Nowhere is it more obvious how far the memory analysis field has come than looking at the recent innovations in Mac and Linux memory forensics.  Examiners of these less popular platforms have had to sit patiently for years as Windows memory forensics moved from being feasible for OS internals experts to being approachable for the masses.  Against all odds, Linux memory analysis has recently seen rapid innovations.  If support for the various Windows versions came slowly, imagine the complexity posed by the myriad flavors of Linux and the long list of possible kernel versions.  It turns out that the Volatility framework is particularly well suited to tackle this Hydra with its abstraction layers facilitating everything from different image formats to swappable OS profiles to rapid plugin development.

Continue Reading…

Excellent paper on recovering network packets from free space. Interesting implications for geolocation | #DFIR
Chad Tilbury

While doing some research on Linux forensics, I stumbled upon an excellent paper written by Gregorio Narvaez.  The paper is titled, “Taking Advantage of  EXT3 Journaling File System in a Forensic Investigation”.  Those of you who have performed linux forensics before know that the EXT3 filesystem dealt our field a serious blow with regard to file recovery.  When a file was deleted in EXT2, the pointer to the file inode within the directory entry was removed.  This severed the link between the file name layer and the meta-data layer, but all of the block pointers within the inode were maintained.  Thus, we could fully recover deleted files, but could not tie them back to their original filenames.  When EXT3 emerged, things took a nastier turn.  Now, instead of removing the pointer to the inode when a file is deleted in EXT3, all of the block pointers within the inode are deleted.  This makes data recovery in EXT3 much, much more difficult.  Luckily, the developers threw us a bone:  the EXT3 journal keeps copies of recently modified inodes, including complete copies of previously deleted block pointers!

Continue Reading…