SANS Digital Forensics and Incident Response Blog: Author - Hal Pomeranz

A Quick Idiom for Pretty-Printing /proc Data

This is just a short note about a useful little idiom that a lot of people I run into seem to have never seen before. You're all aware that the /proc file system contains a great deal of information about processes that's useful in an incident response situation. However, when you start looking at this data it can sometimes be difficult to read:

$ cd /proc/self
$ cat environ

Yuck! All of the environment variables are jammed together in an unreadable mess.

The reason the output appears this way is that the various strings in the /proc structures use nulls (ASCII zero) instead of newlines as terminal characters (just like strings in C). You don't usually see the nulls because they're non-printable characters.

But with a little help from the "tr" command you can convert the nulls to newlines and make everything much

... Continue reading A Quick Idiom for Pretty-Printing /proc Data

Understanding Indirect Blocks in Unix File Systems

When I'm covering Linux Digital Forensics on the last day of Sec506 (that's my SANS Linux/Unix Security track for those sluggards out there that haven't memorized the SANS course numbering scheme), questions always come up about the function of indirect blocks in standard Unix file systems (meaning ext2/ext3 on Linux, UFS on Solaris, FFS on BSD, and others derived, directly or indirectly, from Kirk McKusick's original Fast File System from 4.2BSD). Generally these questions always arise in one of two contexts:

  • What's that extra information at the end of my istat output?
  • Why do I always need the -d option when using foremost on Unix file system images?

It turns out that even people who've been using Unix for a long time are a little fuzzy on the subject of indirect blocks,


Mounting Images Using Alternate Superblocks

[Editor's note: Due to changes in the Linux file system drivers, Hal has posted an update to this post at]

Mounting Unix file system images is a common investigative technique, because it allows examiners to use standard file system tools (e.g., find, grep) to look for evidence. However, sometimes you run into difficulties:

# mount -o loop,ro dev_sda2.dd /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

So what's going on here? Well, let's try the dmesg command suggested in the above error message:

# dmesg