Legal Technology News - E-Discovery and Compliance Blog

« The sine qua non for stuff: search | Main | Statistical Sampling's Rise to Fame »

March 21, 2009

Stubborn vs. Stupid

42-17123976 There are scads of famously data-savvy folks in the State of Washington, right?  I mean, Bill Gates is there, and Jeff Bezos and John Jessen!  Smart, smart folks. 

But all that drizzly weather apparently got water on the brains of counsel and the experts in State v. Dingman, 2009 WL 597208 (Wash. App. Mar. 10, 2009), leading to the reversal of a conviction for a promoter who apparently fleeced a lot of folks seeking sunrooms.  The State was stubborn.  The defense was clueless.  And both sides apparently got smacked with the stupid stick.  I shake my head in wonderment and despair at an unconscionable waste of scarce judicial resources, especially because this one should have been so easy to work out.

The moral of the story: As long as all the ones and zeros are present and in the right order, the format of a drive image doesn't much matter--at least not in the hands of someone who knows what the heck they're doing.

First, the disclaimer:  All I know of this case is gleaned solely from the court’s opinion, and all I write concerning the case is solely my own opinion. 

On average, Tacoma, WA gets even more annual rainfall than its soggy sister, Seattle; and the chronically gray skies are said to precipitate a condition called Seasonal Affective Disorder or (aptly) SAD.  So, it’s no wonder that many Pierce County residents ponied up hefty deposits to sunroom promoter, Robert Dingman.  Sadly, whether due to abysmal business acumen or plain ol’ perfidy, Mr. Dingman took their simoleans but failed to deliver solaria. 

On March 19, 2003, the Sheriff showed up at Dingman’s doorstep and seized nine computers, creating forensic images of their hard drives using Guidance Software’s EnCase application.

Before we go further, let’s focus on exactly what that means. 

Law enforcement seized the source digital evidence and locked it away from Dingman throughout the pendency of his prosecution.  To protect the integrity of the original evidence, the seized machines were never booted while in police custody.  Instead, just the hard drives from those machines were (presumably) connected to a hardware write blocking device capable of intercepting any alteration to the media and the entire contents of the drives—every bit, byte, sector and cluster--were sequentially copied (“bitstreamed”) using EnCase software into a series of self-authenticating files that would be used for archival and analysis.  These files, collectively called an “EnCase image,” can be read by software so as to faithfully reproduce the contents of the source drive.  Moreover, the image files hold information about the imaging process and—most importantly—a unique hash value that serves as a digital fingerprint to verify that the contents of the image are perfectly identical to the contents of the source drive.

To better appreciate the EnCase image structure, take a look at the conceptual illustration of an EnCase image file below (click on image to enlarge):

EnCase File Format_large2

The section of the file labeled “Header” holds information about the source evidence and imaging process, including, e.g., an evidence identifier and the time the data was acquired.  The content of the drive being imaged is (by default) copied in data “blocks” of 32KB, and each block is subjected to a Cyclical Redundancy Check or CRC which mathematically verifies the accuracy of the data in the block.  The CRC value for each block is stored after the block.  When all of the data is imaged, an MD5 hash value for the acquired data is appended to the file.

The important point here is that the content of the evidence drive being imaged is mirrored in all those black ones and zeros seen in the illustration.  If you take that data by itself and lay it out in a new file as a single continuous sequence, you’ll have all the same ones and zeros as exist on the evidence drive in exactly the same sequence.  In fact, that’s what occurs when a forensic examiner makes what’s called a “raw” or “dd” (“data dump”) image of a drive.  In a dd image, the content of the evidence media is bit streamed directly to a file without adding any header information or CRC and hash values.

Thus, a dd image of the same data seen in the illustration above would now look something like this (click on image to enlarge)::

Dd image

Note that the data is identical.  All we’ve surrendered are the bells and whistles that make the file more convenient, reliable and self-authenticating.  We could achieve essentially the same end by pairing the dd image file with a text file holding the header data and an MD5 value calculated on the data at the time of acquisition.  Many excellent forensic imaging tools do just that. 

The EnCase file format merely simplifies the forensic imaging process by embedding the header and authentication data in a single file or series of files.  The format of an EnCase file is well-documented, and it’s simple to convert from EnCase to another imaging format and vice-versa.  It’s easy and free to do--experienced computer forensic examiners do it all the time.  In fact, anyone can download software that will do the job splendidly.  Sorry, Werner Von Braun, but it’s not rocket science.

I emphasize the unmysterious format of the EnCase image file because a convicted criminal is back on the mean streets (and sun porches) of Tacoma thanks in large part to everyone’s failure to appreciate just what a big deal this is NOT.

Two-and-one-half years after the computers were seized, Dingman--still accused-but-untried on theft and money laundering charges--sought direct access to his seized computer hard drives for the purpose of making images using Symantec’s Norton Ghost program.  Alternatively, Dingman demanded that the State furnish “mirror image copies of the drives created in a program used by the defense's computer expert” (apparently also Norton Ghost).  The trial court denied the request but ordered the State to furnish EnCase images.

Dingman complained that the defense couldn’t afford to purchase or use EnCase, proffering testimony that the program cost $3,607.00 and requisite training another $1,500.00.  The State declined to allow the evidence drives to be subjected to Ghosting, whether Dingman’s expert did the work or the State used its own licensed copies of Ghost.  Apparently, none of the giant brains working for the State remembered that EnCase can restore images to a clean hard drive, such that those restored hard drives could be handed over to the defense.  Neither did any of the State’s crack team seem to appreciate how easy it is to convert EnCase images to generic formats like dd (as much an industry standard as the EnCase format). Doh!

But let’s not forget the brain trust on the defense side (for whom ignorance is surely bliss since it got the defendant a new trial).  Their expert’s insistence on Ghost images fairly screams “amateur” in the face of free tools better suited to the task.  Using command line instructions, it is indeed feasible to create a forensically qualified clone of an evidence drive to a sterilized target drive using Ghost, but it’s a poor practice: slow, risky and cumbersome.  In most instances where I’ve seen Ghost misused for forensic preservation, it served as an unwitting antiforensic tool, stripping away the contents of unallocated clusters and file slack.  Further, one group of evidence drives constituted a RAID array.  Using Ghost against such an array would entail painstaking physical re-assembly of the array using cloned drives.  Using logical EnCase or dd images of the array is a whole lot easier.

Here again, the defense expert failed to understand (or leastwise failed to disclose to the court) how easy it is to convert EnCase images into other formats at no cost.

Another intriguing objection leveled by the defense expert against the EnCase program was that “it was created for use by law enforcement, and he expressed concern that its search function could contain inherent bias against the defense.”  Directing such a charge against standard GREP search tools like those in EnCase is a bit like arguing that German automobiles will deliver fewer miles-per-gallon to Jewish drivers--it's bad science based on ugly assumptions.  Doh! Doh!

In the final analysis, the fact that the images were made in the EnCase image format didn’t require anyone to use the EnCase program for analysis.  The EnCase image format is just a container.  Your mug doesn’t care if your beer comes from a bottle, can or tap.

So how should the parties have solved this and avoided a wasted trial?  There were at least three cheap, easy solutions:

First, the State could have restored its EnCase image files to hard drives.  The EnCase program has long supported this ability and, though it would have taken some time and entailed buying drives to hold the data, it’s largely a set-it-and-forget-it effort.  Further, there’s every indication in the opinion that the defense was willing to furnish drives.  Done right, the product would be virtually indistinguishable from gaining access to the source evidence, and the identicality of the clones could be easily and reliably established using hash values.

Second, either side could have converted the Encase images to generic formats (including dd) using, inter alia, the freely downloadable application FTK Imager (available at http://www.accessdata.com/downloads.html).  This superb little program is well-known and admired throughout the computer forensic community, and it would have made short work of the conversion.

Third, the State could have given Dingman’s computers back to him.  It wasn’t a child pornography case (such that contraband content couldn’t be returned).  The State had hash-authenticated images of the drives.  They really didn’t need to hang onto the hardware. I grant that there may be sound reasons to hold onto the machines, but were those reasons sufficient to justify a wasted trial and years tied up in appellate court?  Talk about a reversal on "technical" grounds! 

One last lesson from this case:  Though the defense artfully bamboozled the court of appeals with its focus on EnCase as a complicated, costly tool, the fundamental problem wasn’t that the defense couldn’t deal with EnCase images so much as the defense lacked the ability to deal with electronically stored information.  Whether they elect to purchase and learn to use EnCase or something else, parties must consider the need for some type of capable review platform for ESI. 

As defense counsel in the Dingman case learned the hard way, you can’t just mount evidence drives in your computer and expect that they will “substitute as an operating system that will actually run any of the associated programs required to open a specific file.”  If you’re coming into the pool, you’d best know how to swim.

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d8345280a669e201156e37eef8970c

Listed below are links to weblogs that reference Stubborn vs. Stupid:

Comments

The comments to this entry are closed.

Sign Up for the E-Discovery and Compliance Newsletter

An Affiliate of the Law.com Network

From the Law.com Newswire

Sign up to receive Legal Blog Watch by email
View a Sample



Contact EDD Update


Subscribe to this blog's feed



RSS Feed: LTN Podcast

Monica Bay's Law Technology Now Podcasts are also available as an RSS feed.

Go to RSS Subscribe page




March 2013

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Blog Directory - Blogged