SANS Digital Forensics and Incident Response Blog: Tag - proc

Recovering Open But Unlinked File Data

By Hal Pomeranz, Deer Run Associates

If you've ever been a Unix system administrator, you may have encountered "open but unlinked" files in the course of your normal duties. The typical scenario is a user who's launched a process that creates an unexpectedly large output file which consumes all of the free space in the partition. In a panic, the user deletes the output file but leaves the process running. Unfortunately, the operating system is not allowed to reclaim the space until the last process that has the output file open actually exits. So until the user kills their process, the space is still in use and the file system is full. But when you as the system administrator logs in to free some space in the partition, you're unable to find the massive file that's consuming all of the space with your normal file system

...


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
GNOME_KEYRING_SOCKET=/tmp/keyring-r8yNJT/socketLOGNAME=halGDMSESSION=default...

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