Which forensic imager is the fastest?

We all face the problem of growing amounts of evidence on a regular basis. Improving raw acquisition speed is one way to limit the impact of this, and Evimetry has been consistently delivering the fastest acquisition speeds bar none since we launched two years ago.

Yet we aren’t the only solution claiming to be the “fastest” or have “unparalleled” speeds.

Led by a practitioner and forensic scientist, it is in Evimetry’s DNA to value substantiation. Our results are backed up by scientifically peer-reviewed publications and documented in our blog posts and workshops.

The following graph shows the acquisition rate of a 1TB Samsung 960 Pro NVMe drive. We used Evimetry to undertake linear acquisitions to 4x Samsung 512 GB 860 Pro SSD’s as striped images, using a 6-core Xeon-D CPU. The variable is drive allocation: we started with an empty (TRIM’ed) drive, then filled it with a Windows 10 OS install and a corpus of common corporate documents and video. These figures don’t account for verification time.

We can acquire an empty 1TB NVMe drive in 4 minutes 52s. That’s a rate of 200 GB/m, or 12 TB/h. No other product comes close to these speeds.

In the real world, suspect drives contain data rather than empty runs of 0×00, and Evimetry’s acquisition speeds depend on how much actual data is stored on the suspect drive. For a drive that is 40% utilized it takes us 7m48s (still faster than anyone else’s claim) and at 95% utilized it takes us 12m57s.

In absence of substantiation from other quarters we remain confident that we offer the fastest acquisition solution available today. We encourage you to do your own validation of both our results, and the claims of other tools.


Simple Deadboot provisioning and acquisition with Evimetry

We have just shipped two releases of Evimetry: v3.0.7 (in our stable stream) & v3.1.5 (in our pre-release stream). Recent releases bring native Deadboot media creation, and introduce an improved Deadboot Imager UI.

Native Deadboot Media Creation.

We can now create Evimetry Deadboot USB’s directly from the Controller, and for larger drives, use the additional space for evidence storage. With a single hard drive serving both as an Evimetry Deadboot and Evidence Repository, scarce USB ports are freed up on target devices, workflow is simplified, and the number of devices to manage limited.

Creation of a Deadboot USB flash drive in the Controller.
Creation of a Deadboot USB flash drive in the Controller.

Small USB flash drives are setup solely as a Deadboot, just like our former workflow.

Read more about this feature here.

Improved Deadboot Imager UI.

For a while now the Deadboot agent has included a simple ASCII console-based Imager application. This is useful for acquiring single computers, when it is either inconvenient or unfeasable to use the Controller and a network.

While we love the retro feel and simplicity of an ASCII/curses interface, the world is no longer friendly to text-mode UI’s, with high-DPI monitors and text-mode free UEFI implementations meaning that text-mode no longer works everywhere. A graphical window based UI is now necessary.

Acquisition almost completed using Evimetry Imager
Acquisition almost completed using the new Deadboot Imager UI.

In the v3.1.3 pre-release we launched a *graphical* Imager application, and in today’s prerelease (v3.1.5) the layout of the Imager UI has been refined.

Pulling it all together.

The following video demonstrates the workflow of preparing a Deadboot USB and then subsequent acquisition of a 500G NVMe drive in under 6 minutes.

More information.

Full release notes are available via the releases page. The software may be downloaded from the portal.


Macintosh Forensic Acquisition

Recently the Mac OS X Forensics site has been amassing a wealth of information on acquiring and analysing Macintosh OS X computers. Additionally, the “Inside the Core” podcast has made a strong start at presenting similar and related content as a podcast. Both teams deserve congratulations and encouragement for their contributions.

One problem that I have observed with acquiring Macs is a particular problem with some Apple keyboards that have a brushed aluminium appearance. They will not reliably allow one to boot to CD or target mode using option keys, due to (purportedly) a firmware bug. The result of this can be an unplanned booting of the hard disk in the computer, and resulting modification of the state of the disk.

I haven’t observed this problem with any other Apple keyboards. Forensic practitioners may want to consider making it a part of your practice to ensure that you are booting with a non aluminium keyboard.


Paper on new evidence container format accepted for presentation at DFRWS2009

Michael Cohen, Simson Garfinkel and I have been collaborating recently on the development of a new digital evidence storage container format. Today we have had notification that a paper detailing the research behind this development has been accepted at the 2009 Digital Forensics Research Workshop, to be held in Montreal Canada. The title of the paper is “Extending the Advanced Forensic Format to accommodate Multiple Data Sources, Logical Evidence, Arbitrary Information and Forensic
Workflow”.

A new evidence container is sorely needed by the computer forensics community, due to the large amount of manual work currently required in managing evidence and the closed nature of the current generation of forensic containers and tools. With this new forensic container, we provide an open and extensible container standard which promotes forensic tool interoperability and simplifies evidence sharing and management.

Technically, this new container achieves these things by enabling:

  • efficient random access storage of multiple streams of digital evidence within a single container;
  • storage of arbitrary information such as case relevant information or tool derived analysis results;
  • composition of evidence containers into a larger corpus of related evidence through an inter container referencing scheme;
  • decomposition of evidence containers into sets of smaller containers to support filesystem limitations;
  • definition of virtual evidence streams as maps of existing evidence streams.

The new format is slated to replace the current generation of Simson’s Advanced Forensic Format (AFF) and will be known as AFF4. Michael has been providing some documentation on the format over at the forensicswiki, and he has a beta quality implementation in the C language. Plans are in place for a JAVA based parallel implementation.

The abstract follows:

Forensic analysis requires the acquisition and management of many different types of evidence, including individual disk drives, RAID sets, network packets, memory images, and extracted files. Often the same evidence is reviewed by several different tools or examiners in different locations. We propose a backwards-compatible evolutionary redesign of the Advanced Forensic Format—an open, extensible file format for storing and sharing of evidence, arbitrary case related information and analysis results among different tools. The new specification was designed to be simple to implement, allowing the use of the well
supported Zip File format specifications for bit level file access.

UPDATE: The paper is now published on the DFRWS 2009 website.


dd2vmdk relocated into the cloud

A while ago I wrote a tool to convert flat disk images (which we commonly call dd images) to VMWare .vmdk disk images (the original blog post on the tool, called dd2vmdk is posted here). I have in the mean time ceased development of it, but despite its relatively archaic nature, some still find it of use.

Today I relocated hosting of it to Google’s new cloud web application service, Google App Engine. My motivations to do this were to reduce adminitrative burden, to eliminate server costs, and to increase long term availability (the Java App Engine is Beta, so there might be some short term availability issues).

The relocation took roughly one hour of my time, was dead simple, and required no code modification, just the simple addition of a new text configuration file.

dd2vmdk is still available via my personal website.


New tool – CERT/CMU Live View

I am in Lafayette, Indiana this week at DFRWS2006. A gent from CERT was present and demonstrating an excellet tool called “Live View” which, from first impressions to be a p2v GUI that automates running dd images in vmware. It appears that the features of it are far beyond what dd2vmdk does in some respects: you appear to point it at an image upon which it:
* generates a vmware vmdk
* generates a corresponding virtual machine definition
* fixes up the driver boot problem
* optionally lets one set the time to a different value.
* automatically boots up the image in vmware

On the downside, it doesnt appear to handle disk images, just partition images. This introduces further complications such as having to specify the OS used, and remapping of drive letters, which they do however handle. I am not convinced that their insistence of replacing the MBR is necessary either.

When I get back from DFRWS I will be testing if it does handle disk images, and if it does, how it copes with geometry problems and LDM.


tool – pasco2

I am off to the DFRWS 2006 conference in a week or so to present my paper “A correlation method for establishing provenance of timestamps in digital evidence”. In this paper I describe some research I have performed in characterising where the behaviour of computer clocks differs from the ideal.

A second theme of the paper is the identification of methods of correlating commonly found evidence to establish provenance of timestamps. In this case, I have been correlating Internet Explorer Cache and History files with Squid cache logs.

As a part of my work I reimplemented and extended a parsing tool for the IE cache and history index.dat files. This was due to finding bugs in the initial pasco tool (which was missing some error conditions from the read() system call). That and I am more productive using java.

The tool, which I have named pasco2 in honour of Keith Jones’ earlier IE parser, pasco , can be found here: pasco2.


dd2vmdk – dd Image to VMWare Virtual Disk converter

While performing the last set of investigations, I have produced a simple web based application for automating the conversion of dd images into VMWare Virtual Disks. I have called this tool dd2vmdkxn--it is accessable at http://www.bschatz.org/2006/p2v/index.html

Currently the tool carves up the image into a virtual disk composed of a number of files, where partitions are contained individual files. The next version of the tool will support directly modifying the partition table and NTFS boot record in-situ within the image file.


P2V – Will the 2K MBR boot up a non cylinder aligned partition?

I left my last post unsure whether of not a PC can boot into a partition that is not aligned with the beginning of a cylinder boundary. I devised a quick test, employing the same image that I have been using for the last two posts.

In this case, I left the partition table unmodified, but went into the NTFS boot record and adjusted its conception of the hard drive to reflect the Virtual Drive’s geometry. I got this:

Error Loading Opertating System.

If the bootable partition was the first on the hard drive, there may have been a chance for it to work, but since it is 73440 sectors in, the CHS values will be all wrong.

Recalling the original partition table as taken from fdisk is:

Disk /dev/ida/c0d0: 8711 cylinders, 255 heads, 32 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/ida/c0d0p1 32 73439 73408 12 Compaq diagnostics
/dev/ida/c0d0p2 * 73440 20555039 20481600 42 SFS
/dev/ida/c0d0p3 20555040 71081759 50526720 42 SFS
/dev/ida/c0d0p4 0 xn-- 0 0 Empty

We regenerate the new partition table with sfdisk, setting the correct CHS values for the new virtual disk. (sfdisk recalculates the right CHS values for the start and end of the partitions based on geometry specified on the command line, and the sector offsets and sizes):

sfdisk -uS -C 4436 -H 255 -S 63 -f c0d0.dd << EOF
32,73408,12
73440,20481600,42,*
20555040,50526720,42
EOF

The image now boots correctly.

So, to answer my initial question. Yes, the MBR boot code WILL boot up a non cylinder aligned partition. Inside the OS the dynamic disk shows up as healthy and exactly as it was in the original physical machine.


P2V – hard drive geometry problems

I have been trying to convert a physical Windows 2000 server running on SCSI RAID to run inside a virtual machine. Given my interest in digital evidence, I was interested in achieving the conversion (which is popuarly referred to as Physical To Virtual or P2V conversion) from first principles.

A while ago I came across the Windows Dynamic Disk partitioning scheme (also called Dynamic Disk or LDM). It’s support under linux is slowly gaining momentum, but still remains a bugbear for manipulating disks. So just to complicate things, I decided to convert the physical host’s drive to using Dynamic Disks.

My proposed methodology was as follows:
1. Use a live CD (helix) to acquire the source drive to a external SATA drive. This included recording the partition and disk geometry using the sfdisk program, recording the LDM partition information using the ldminfo tool from the Linux NTFS project, and imaging the drive using dcfldd.
2. Load the image onto the Linux host running VMWare Server.
3. Generate a VMWare Virtual Disk file which works with the image.
4. Create and configure a VM using the new virtual disk.
5. Fixup the drivers inside the VM using the Ultimate P2V method.

In practise this didn’t work as planned. What I was presented with was the following:

A blank screen with a non flashing cursor on boot.

Looking into the problem in more detail it appeared that the boot problem was due to a difference in disk geometry between the SMART2 RAID controller present in the the physical host and VMWare’s emulated SCSI hard drives. As it turns out VMWARE will only emulate a disk with 63 sectors per track, and 255 heads (the number of cylinders from this perspective is irrelevant). My RAID controller however presented a disk with 32 sectors per track, and the 255 heads. Fdisk showed me this:

Disk /dev/ida/c0d0: 8711 cylinders, 255 heads, 32 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/ida/c0d0p1 32 73439 73408 12 Compaq diagnostics
/dev/ida/c0d0p2 * 73440 20555039 20481600 42 SFS
/dev/ida/c0d0p3 20555040 71081759 50526720 42 SFS
/dev/ida/c0d0p4 0 xn-- 0 0 Empty

Running sfdisk inside the virtual machine with this image resulted with a number of warnings about partitions not being aligned on cylinder boundaries.

It appeared that this problem was related to the differences in geometry between the two drives. On boot, the boot code in the MBR of the hard drive is looking inside the image at the wrong point. It appears that the Boot code can only boot partitions that are aligned on cylinder boundaries, ie. the start address of partitions must be fully divisible by heads*sectors. The differences between these means that the boot code is looking in the wrong place inside my image.

[Update: I am not sure about this after researching this some more... it appears that some old versions of DOS required that partitions be cylinder aligned, but the MBR boot code appears like it is independent of cylinder alignment.]