SANS Digital Forensics and Incident Response Blog

Trusting Your Tools

"A trusted tool is one that you understand what it does"- Chris Pogue

I recently heard Chris make that statement during his "Sniper Forensics" presentation at the 2010 SANS Forensics & Incident Response Summit. It was that statement that inspired me to put together this post. As digital forensic examiners, we rely on various applications/programs (tools) to aid us during our investigations. I want to take Chris' statement and flesh it out a bit?

"A trusted tool is one that you understand what it does, where it came from, what flaws it has and what results it gives you."

This post is aimed at those that are new to digital forensics, but will also help those that may not have been given a push in the right direction or those that are experienced who might have lost their way. So let's get started.

There may be a tool you are interested in using that you heard about somewhere. Let's face it, forensic examiners need tools to assist them with their ever expanding case loads and increasing backlogs on an everyday basis. The first tool that I hope everyone can rely on without question is, themselves. You should be able to trust your own eyes and ears. What I mean by this is do some research before you decide to use a particular application.


- Do a Google search for the tool. You may come across websites/blogs containing reviews about the tool in question that were written by other Forensicators.

- Check out the various digital forensics forums for mentions of the tool or create a post asking about other peoples experience with the tool and its developer.

- Use Social Networks (Twitter, LinkedIn, Facebook) to engage other digital forensics professionals. If you have not done so already, I would recommend that you join Twitter and start following the numerous Forensicators that use that service (HINT- Look here and here). It is a very strong community and you will be amazed at the support (as well as camaraderie) that you get there.

Now before you download the application you wish to use, make sure you take note the version number of the program and the MD5 hash value of the file, if it is available. Not all developers/vendors have the MD5 hash listed on their site. A suggestion would be contacting the developer and inquiring as to what the MD5 hash is for the file. Make sure to compare the MD5 listed on the developers/vendors site (or the one they emailed you) to the one for the file that you downloaded. If you are unfamiliar on how to check the MD5 hash of files, follow along below:

Note the MD5 value for FTK Imager Lite in the following screenshot:

FTK ImagerFTK Imager

To check the MD5 hash value of a file:


- Open a terminal

- Navigate to the directory where you downloaded the file

- Type the following: md5sum [Name of File]

- Press Enter

**Note- If you have a filename containing spaces that you wish to perform a checksum on, you either have to put quotes around the filename (after md5sum) or rename the file with underscores for Linux to recognize the entire file name. The same holds true for Mac, which is listed below**

md5sum of Imager Litemd5sum of Imager Lite

Mac- The "hard" way:

- Open a terminal

- Type the following: md5 [path to file]

- Press Enter

Mac- The "easy" way:

- Type the following: md5 with a single space after it

- Then drag the file you wish to check the MD5sum of into the terminal

- The path to the file will populate itself after "md5"

- Press Enter

md5 on OSXmd5 on OSX


Unlike Linux and Mac Operating Systems, the MD5sum utility is not installed by default. Fear not though, there are a few third-party utilities you can download to help you. Performing a Google search for "MD5 Checksum Windows" will yield many results.

I would really like to see more (read: all) forensic application developers/vendors listing the MD5 values for their applications on their website. I have found that there are a number of devs/vendors are not doing this. Having the MD5 is especially helpful if you need to download the application from a third-party site. How are you supposed to trust that file you just downloaded? If evidence integrity is key to a digital forensics examination, so too should be the integrity of our tools. We as a community should demand more in this regard, no?

I also mentioned to take note of the version number. I say that because it might come into question when a case is going to trial. Opposition counsel will want to have their own examiner/expert witness look over evidence files and he/she might want to recreate the same environment that you had to examine the evidence to see if they can obtain the same results as you. They will also attempt to uncover evidence that you might not have. They will also probably research what known issues there may be with the tool(s) in question and will try to use that against you in court, hoping that you do not know those facts.

Version Information for FTK ImagerVersion Information for FTK Imager

Now, once you have the software installed, you are going to want to run through it to get familiar with and test out its features. For example, EnCase by Guidance Software has a software write-blocker utility feature for USB, Firewire and SCSI devices built into it. For those that work in a shop that hasn't provided a hardware write-blocker or for those who cannot afford the personal out of pocket expense to obtain one, this utility will be valuable to you. Knowing that and knowing that being able to write to suspect media is a bad thing, you should grab a piece of test media (spare USB Thumb Drive, external Firewire drive, etc) and test this feature. Enable the built in write-blocker utility and attempt to write to your test media. If it writes to your test media, you know that it cannot be trusted to perform its function. I would do this every time you update from version to version of the program. Keep in mind that functions that may have worked in the previous version of a particular tool may have been broken in the next version.

Something else you will want to do is verify the results that you receive from one application with that of another. You will always hear a good examiner say, "VERIFY, VERIFY and VERIFY". I suggest that before using your tools on a piece of suspect media relating to a case, you find a test image or create your own to test your tool(s) on. That way you know what information should be on the image you are running your tool against. If the tool is not finding the known data, then there may be an issue with that application.

Let's say you decide to use Harlan Carvey's excellent tool, RegRipper to parse out the NTUSER.DAT Hive from a Windows box to see what the Typed URL's were. Well, RegRipper is a great tool but how do you know if the results that it gives you are valid? You don't unless you have something to compare its results to. In that case, after grabbing or creating a test image file to work with, you can use a tool like AccessData's Registry Viewer to do just that:

AccessData's Registry ViewerAccessData's Registry Viewer

To take it a step further, let's say that you will need to regularly obtain the list of USB devices that connected to a system as part of your Incident Response Team's Standard Operation Procedure. Again, using your test image, you could compare the results you received with RegRipper to that of AccessData's Registry Viewer against another program like ForensicUSBDeviceInfo by Woanware:

AccessData Registry Viewer and RegRipperAccessData Registry Viewer and RegRipperRegRipper & ForensicUSBDeviceInfoRegRipper & ForensicUSBDeviceInfo

Another good reason to test multiple tools is that there may be one application that works faster, better or leaves even less of a footprint in certain situations than others. Remember, not all incidents/examinations are the same and your use of tools will vary on a case to case basis.

Sites that have test images to work with:

- Digital Forensic Tool Testing: (

- NIST CFReDS Project page: (

- Forensics Contest: (

- SANS Digital Forensics & IR Challenge: (

- ForensicKB (Lance Mueller's site): (

Also, another thing to do is to make a dry run through your application to see how reports are generated. It is helpful to know what information is included in your tools default report and how that information is laid out. Some applications may allow you to customize your reports to add or remove information, change the layout or even add a Department/Company logo. If you cannot even understand your own report, what good is it to you?

After doing tests such as the ones I have listed above, you will become more confident in the use of the applications that you have decided to place into your "tool box". An examiner who testifies with confidence and knows his or her work inside out, will tend to hold more weight with a jury than an examiner who fumbles through his or her paperwork and looks nervous. Remember, it is your professionalism, experience and integrity that will help a jury reach their decision.

Joe Garcia is a Law Enforcement Officer with over 16 years of experience, the last 4 of which he has been assigned to conduct computer crime investigations and digital forensics. He holds the GIAC GSEC Gold, GCIH Silver and AccessData ACE certifications. You can follow Joe on Twitter at @jgarcia62. Joe is also the host of the Cyber Crime 101 podcast, which can be found at and @cybercrime101 on Twitter. This is his first post to the SANS Forensics Blog.


Posted July 29, 2010 at 5:42 PM | Permalink | Reply

Rob Lee

Great post. Very well written.

Posted July 30, 2010 at 4:58 PM | Permalink | Reply

Ken Pryor

Excellent post, Joe. This is good info that every examiner should know and put into practice.

Posted August 2, 2010 at 6:32 PM | Permalink | Reply


I might add a recommendation to check multiple websites for MD5 sums for tools, especially if they are not commercial. You can visit a "rogue" website hosting a modified version of the software with their MD5 posted rather than the official MD5.

Posted August 3, 2010 at 2:25 PM | Permalink | Reply

Karl Ajit

I hate to start this, but checking the MD5 hash of a file is a great way of making sure that the file you've downloaded is complete. Which these days, TCP/HTTP do a pretty good job of that, especially for small binaries.
What you don't get is much security. If I somehow broke into AccessData's FTK Imager host and replaced the application installer executable with a broken or malicious one, the very next thing I would do, or even have already done, would be to replace the checksum file as well.
If these were stored in separate places with different security measures, that would help.
And of course, checking multiple sites would help too.
But strong crypto signing is one way to actually bring real security to the trusted distribution of software.
If you use a Linux distribution, you somewhat have this, for all the Linux forensics tools.

Posted August 3, 2010 at 3:04 PM | Permalink | Reply

Joe Garcia

Darrell- I guess that would go with the "Verify, Verify and Verify" mentality :-)
Rob and Ken- Thank you for the kind words!

Posted August 13, 2010 at 4:39 PM | Permalink | Reply

James Green

Thanks for the excellent article. I'm an aspiring forensicator, currently doing IA work, trying to move to our forensics shop. This article maybe obvious to some, but it was awesome & gave me some homework to do.