Computer Forensics: Armor For Your Feet

As forensic professionals we take a great deal of care when acquiring and analyzing evidence. Write blockers, checksumming, working copies- these are part of everybody's standard policies and help to prevent corruption of our digital evidence. However, beyond spoiling your original evidence, there are still various mistakes that you can make that won't ruin your case but will cost you time and increase your frustration level. In this article I'm going to demo a couple of different ways you can shoot yourself in the foot when doing forensics on the Unix command-line (e.g., in the SIFT workstation) and some easy ways to prevent these mistakes.

Output Redirection is Your Friend... Until It Isn't

Let's say you want to extract both the ASCII and Unicode strings from a disk image. You might enter the following two commands:

$ strings -a -t d disk.img >strings.asc
$ strings -a -t d -e l disk.img >strings.asc

Did you spot the mistake? We accidentally sent the output of the second command to the "strings.asc" file that we created with our first command. This is an easy mistake to make if you're using bash's command-line editing features or cut'n'pasting commands into a terminal window. The problem is that the first command might have taken several hours to complete if our disk image was large and we've just wasted all that effort because the second command just trashed our file.

Happily, the shell has an option you can set to protect you from exactly this kind of error. If you put "set -o noclobber" in your .bashrc (or just enter it on the command-line), you'll see this if you make the mistake shown above:

$ strings -a -t d disk.img >strings.asc
$ strings -a -t d -e l disk.img >strings.asc
bash: strings.asc: cannot overwrite existing file

When "noclobber" is set, our shell simply refuses to let us truncate an existing file using output redirection. However, we are still allowed to append data to files- ">>", but not ">". Thank you bash, for saving us from ourselves!

Other Ways To Clobber Files

Here's another way to get yourself into trouble- I see For508 students making this mistake over and over again:

$ dd if=disk.img bs=512 skip=63 count=112392 of=disk.img

See the problem? We're carving a partition out of the file disk.img, but we accidentally set "of=disk.img", which clobbers our original image. Unfortunately, "noclobber" doesn't help us here because we're not doing output redirection in the shell. Oh well, back to our best evidence to make another copy of the disk image, right? Darn, that could take hours!

That's why I recommend you get friendly with the immutable bit in Linux. The root user is allowed to set immutable on a file with "chattr +i <filename>". This makes it impossible for any user, including root, to delete, overwrite, modify, rename, or otherwise molest the immutable file. Consider our example above with the addition of chattr:

# chattr +i disk.img
# dd if=disk.img bs=512 skip=63 count=112392 of=disk.img
dd: opening `disk.img': Permission denied
# dd if=disk.img bs=512 skip=63 count=112392 of=part1.img
112392+0 records in
112392+0 records out
57544704 bytes (58 MB) copied, 1.5832 s, 36.3 MB/s

The immutable bit prevents us from clobbering our original image. We realize our mistake, correct the output file name, and presto we're in business!

But what about when we're done with the disk image and want to get rid of it? Just "chattr -i disk.img; rm disk.img" (as root) and you're all set.

Conclusion

As somebody who does a lot of forensicating in Linux and Unix, these little tricks have saved me hours of pain and suffering. I hope you'll find them a useful addition to your forensic procedures. Let's be careful out there!

Hal Pomeranz is an Independent IT/Security Consultant, a SANS Institute Faculty Fellow, and a GCFA. Every time somebody inadvertently overwrites a file they shouldn't, Hal is forced to kill a kitten. Remember, think of the kittens!