Test It Before Encrypt It

This is not about acquisition tools, but about understanding why we need to test our tools even if the tool was just updated.  The latest and greatest tool without testing can be a risk factor just like the old and worthless.
I remember how excited I was to test TIM (Tableau IMager) on a multi core system and see it outperform the competition.  It was just as much exciting as finding out about Access Data’s FTK Imager CLI.  It was not about the performance improvement ( since there was none ), but the OS support and the ability to encrypt images using a certificate.
It’s been working great, but in the latest version something has changed.  Using version 3.1.1 to acquire an image on Windows 7 Professional 32/64 bit worked as it was advertised.

C:\temp\ftkimager>ftkimager.exe \\.\physicaldrive1 c:\temp\usb --e01 --outcert C:\temp\pub.cer
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Creating image...
Image creation complete.

The image was opened in FTK Imager 3.0.1 using the private key and the given password and FTK Imager was happy to comply.  Of course, the question can come up to verify the image in the tool that created it.  Surprisingly, the newest version of the software gave an error message and refused to take the private key with the password that worked just fine in GUI.

C:\temp\ftkimager>ftkimager.exe c:\temp\usb.e01 --verify  --incert c:\temp\pri.pfx p@$$w0rd
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Error setting up decryption: DecryptWithPrivateKey: Cert encrypted and password failed: c:\temp\pri.pfx
** AD Decryption setup failed.

This seemed to be odd since new version of software supposed to fix problems and not break what was working just fine.  The natural thing was to think that it must have been the command line options I used, the spelling of words, or the spaces.  Then, the private key and password were blamed.  Then, in a final attempt, I wanted to see if the previous version was able to access the image and verify it.  It worked.  It felt grate to verify that I do know how to spell and remembered my password correctly.  The image was not lost and a lesson was learned about the value of tool testing.

C:\FTK ImagerCLI 2.9.0_Win32>ftkimager.exe c:\temp\usb.E01 --verify --incert c:\temp\pri.pfx p@$$w0rd
AccessData FTK Imager v2.9 CLI (May 11 2010)
Copyright 2006-2010 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Verifying image...
Image verification complete.
[MD5]
 Computed hash: 08d27c2233aee57c95ddecb0386e1e6f
 Image hash:    08d27c2233aee57c95ddecb0386e1e6f
 Report hash:   08d27c2233aee57c95ddecb0386e1e6f
 Verify result: Match
[SHA1]
 Computed hash: 38e1d87975594abd14608960e2236737619f08db
 Image hash:    38e1d87975594abd14608960e2236737619f08db
 Report hash:   38e1d87975594abd14608960e2236737619f08db
 Verify result: Match

Problems like this must be treated as a valuable lesson that no books and training classes can relay.  Know your tools and you should treat every update with caution.  Maybe there is a good reason for projects like NIST’s Computer Forensics Tool Testing (CFTT) Project.  It would have been an interesting feeling to find out that you couldn’t decrypt an encrypted evidence file.  There no substitute for risk management and methodological problem solving.  I do hope, that AccessData will remedy this issue and will not create another "teachable moment" in future releases. 

P.S. It still does not make sense why the User Manual PDF file does not show the -- ( double dashes ) that are required for the options to work.  It's been like that since the first release.