As with any growing service, issues that were not even on ones radar suddenly begin popping up in unpleasant ways. 

 

Computer hardware, like any machine, is going to fail or otherwise become compromised in terms of functionality.  Hard drives in storage, ones that worked perfectly well a year ago, decide to no longer even spin, even though stored in their laptop and it, in turn, stored in an antistatic bag with desiccants. On other occasions, laptops arrive, their drives imaged, and then fail to properly boot.  Perhaps some memory went bad en route or some evil digital gremlin decided to ruin an otherwise normal acquisition.

 

In some ways, this is a bit like the paradox of Schrödinger's Cat. Was the drive dead or alive; or, was it both in that it did successfully imaged, but then failed to boot once back in its resident computer.  An amusing thought on one hand, but dreadfully serious when the non-booting PC belongs to the opposing party.

 

The bottom line is that you, the third-party provider, may be looking at a situation that implicates some form of spoliation at worst – the destruction of data.  Less serious issues are the costs to bring a non-functioning device back on line (and seemingly always in a time-constrained fashion.)

One change we are implementing, when the opportunity exists, to ensure we are starting to work on an uncompromised piece of hardware, is to have the user boot the PC first.  Booting through to the login screen, not simply waiting for the splash screen, and then shutting down the machine is a needed confirmation.  Obviously, this is neither appropriate nor needed in a criminal case where the “People” take the assets and have few if any worries about necessarily returning a functioning system.  This is not the case with civil matters; if the “patient” dies in your lab, it is on your dime to bring that hardware back to a fully functioning state.  And, this is only right; a client simply wants their machine back and working.

 

Other options could include adding contract language to keep the monkey off your back, should something “go south” during an otherwise proper acquisition.  Or, perhaps receiving some type of affirmation from opposing counsel that the PC worked in their presence would add some comfort to the downside of receiving a DOA system.  This will be an evolving issue and, hopefully, one that does not show an increasing frequency of occurrence.

I have generally been a fan of Voom's products for making computer forensic copies. We use them regularly in the office. I purchased a HC II when they first came out. I have used it successfully in the field and the lab and was always impressed by its speed.
 
This changed during an on-site acquisition a couple of years ago.  I was imaging a tiny 10GB drive. About 3/4 of the way through, it hit some number of bad sectors.  The HC II went into "Error Recovery" mode for about 10 minutes and it showed no sign of making progress.  We waited over 30 minutes in total and still no progress appeared to being made.
 
We had to stop the process and we relaunched the acquisition with a laptop-based, write-protect device.
 
I had queried Tech Support about having an expedited error mode for their product, but it was not something high on their priority list, given the soon to be released HC 3.
 
Reading great things about the HC 3 and understanding that it had a better (i.e.faster) error recovery process, we decided to pick one up. 
 
This device has been great up until today. During a single drive acquisition, an 80GB Hitachi 2.5” sata drive built in Nov. 2007,the HC 3 went into Error Correction la-la land, just like its predecessor, theHC II.  Although it had started out at a speedy 3.5GB/ min, this all changed when it apparently hit some bad sectors in the11GB range.
 
The 20 or so minutes I waited for it to get beyond this bad patch was unacceptable, especially with the user waiting for their laptop to be returned to them.

So, I had to stop the process and I connected the drive to a laptop using a WiebeTech sata write-block (which I highly recommend) using FTK imager.
 
FTKimager's error handling is the way the HC should be setup.  It sped through the rough patches that ground the HC 3 to a essential halt. 
 
I will not buy another HC3 and would not recommend it for field use until the folks at Voom include an error correction process that is the equivalent of that on the Logicube, FTK imager, and the dd/dcfldd “conv=noerror,sync” methods.  It is unacceptable today to be left waiting for what should be a very expeditious process due to some über-rigorous error correction. 
 
I appreciate that the Voom folks have different types of clients to support.  No doubt certain segments will want every last bit taken from a drive, regardless of the time it takes to do so.  However, there is another segment who needs to get in and out from a client location in as little time as possible. If you add to this imaging in a "hostile" environment, this makes it even more imperative to not get bogged down, possibly to a very significant extent while your imaging efforts spin off into the ether as the HCs attempt to perform their error correction. 

Until Voom addresses this issue, I do not believe they have a product that can be used with confidence to complete an acquisition in a timely manner.

Welcome to my blog. Please check back soon for new entries.