Testing acquisition tools

Lee was researching software acquisition tools and made some interesting findings. One of my first thoughts was “Why?” No, not why was he doing the sort of research that we all should be doing, but why was there such a big difference between FTK Imager and the other tools? System, Firewire, disks (source and target), compression, data on the disk combined with compression, ….? I don’t think I can test all the options, but I’d like to contribute some additional research.

Unfortunately, I do not have a Tableau eSATA writeblocker so I cannot include TIM in this research. (While I understand the benefits of tight integration between software and hardware, particularly in this case, it would be nice if  TIM had a “degraded mode” that worked with non-Tableau writeblockers.) So here’s my test environment:

Test components:

• System: Dell Precision 690, Dual 64 bit Xeon CPUs, 8GB RAM, 64 bit Windows 7, internal RAID 5
• Drives:Western Digital VelociRaptor 160GB drives, one wiped with “00” and one formatted and cloned with real world data.
• Writeblocker: WiebeTech UltraDock via eSATA interface to drive and to system
• Tools: FTK Imager 3.0.0.1443 and EnCase 6.17.0.90

To see what the various tools might do with different types of data on the test disks, I wiped two disks, one with a pattern of “00”,  and one with standard Windows formatting and then added real world data to it. These are listed as 00 and RW in the results.

All tests were conducted using a WiebeTech Ultradock connected via eSATA to both the drive and to the system.

All tests used 1500MB chunks, MD5 hashes,  and had verification turned off.

Imaging times:

Drive 00
Options	dd	E01 – no compression	E01 – full compression
Tool
FTK Imager	0:34:58	0:34:20	0:38:36
EnCase		0:31:05	0:32:18
Drive RW
FTK Imager	0:30:43	0:33:56	1:48:23
EnCase		0:31:04	1:18:12

Compression results (size of resulting images):

FTK, full E01 compression, ’00’ drive – 262MB
EnCase, full E01 compression, ’00’ drive – 524MB

FTK, full E01 compression, real world drive – 61.5GB
EnCase, full E01 compression, real world drive – 62.3GB

Conclusions:

Please bear in mind that this is a really limited data set, ok? As I write this, I’m imagining all the comments of the form “But if you did X, then ….” My suggestion to those people is “Why don’t you try doing X and let us know how it turns out?”

1. Using compression will add significantly to your imaging times
2. EnCase’s E01 compression is faster than FTK Imager’s.
3. Both tools do equally well on compression
4. The randomness of the data on the drive affects the time required to image the drive if compression is turned on.

Observations:

1. There are a lot of variables that affect imaging speed – drive, drive interface, write blocker, write blocker interface, system IO bus, CPU type and speed, and target drive to name the big ones. If you’re looking for performance, you can’t control the drive characteristics but you can invest in the other components. If you’re not using compression, the biggest bottleneck will be your IO bus so go with eSATA whenever possible.
2. If you’re imaging for archival purposes, compressing while imaging makes sense. Otherwise, consider leaving the image uncompressed until you want to archive it.

Further research:

1. If I had more time and hardware resources, I’d love to rerun these tests while adjusting each of the variables identified above.

Advertisement