There are a good amount of computer forensic myths out there, many of them brought about and reinforced by shows like CSI, Law and Order, and especially 24.  Ryan Lerminiaux pointed out a number of these myths in an earlier post, "7 Myths about Computer Forensics."  I ran into a new one the other day.

I was talking with someone while they were sitting at their computer, and suddenly, the program they were using crashed.  The user cursed, hit the desk, and then said to me, "I bet this stuff never happens to you."  "Why do you say that?" I asked.  "Well, it's not like your forensic stuff crashes, right?"

MYTH: Computer forensic software is impervious to errors, glitches, and crashing.

FACT: Forensic software can be just as buggy as everything else.

A sizable part of our job as EDD and forensic consultants is troubleshooting items, pouring over log files, looking up error messages, finding software and hardware workarounds, and double-checking output.  TV makes it look like we're all working on 54 inch flat panels, utilizing 100% visual software and breaking decryption in seconds, but that's just not the reality.  Take this PDF troubleshooting document from AccessData, maker of one of the top forensic tools in the industry, Forensic ToolKit (FTK), for example.

The PDF shows how to "skip" processing on a certain file that repeatedly causes FTK to crash.  I've experienced frustrations with FTK crashing all too often, and know that, as they say in the PDF, "you will need to reprocess the case when FTK crashes or hangs on a particular file."  What this doesn't tell you is the amount of time it takes to "reprocess the case."  Processing cases, depending on what options you choose, can take between 2-12 hours for the average laptop drive.  So, if you had set up all the parameters, hit "start," and left for the night expecting to be able to work on a case in the morning, you just might be out of luck when you get to work.

But the difference lies in what happens after a program crashes.  The person who wished he worked with forensic software merely clicked "Don't Send" on the "Please tell Microsoft about this problem" dialogue box that popped up and then reopened the program.  But think about it; if Microsoft Office didn't recover your work (the tough reality with some forensic software), wouldn't you want to know what the issue was so it never happened again?  With the time we invest, and a need to ensure that everything has been collected / copied / processed / analyzed (lest the smoking gun is simply overlooked), our first instinct is to get to the bottom of the problem.  The best way to do that is often just to look at the log files that describe the crash, or at least describe the moments just before the crash.

Log files are like a real-time journal that a computer system writes in either time- or event-triggered intervals.  Even if you're not aware of it, there are a great number of things being logged right now, as you read this sentence; the pages you're viewing with your Web browser, how long you've been editing those open Word documents, files checked by your virus scanner, the model number of your thumb drive, and much, much more.  Next, we take action on what we find in that log file, whether it's patching a program, coming up with a workaround, or (depending on the software and the rarity of the problem) calling the developers and talking out the issue with them.

So, the next time a program of yours crashes, if the inconvenience warrants the time, do some investigating of your own and try checking out a log file and researching the error.  You might find others who had the same issue or advice on a patch or workaround so you can avoid the problem in the future.  Finding the problem won't be as awesome as TV makes it look, but if you're able to figure it out, you just might experience that sense of satisfaction that comes hand-in-hand with solving a problem.  And that's something even CSI's Gil Grissom gets right; that sense of satisfaction that comes with a case rightly closed.