computer forensics, computer forensics expert, mobile phone forensics, expert witness

Digital Evidence Experts.

UPDATE: dd2vmdk has been shut down

When I wrote this post and created dd2vmdk, the theories underlying the techniques were poorly understood, and there were limited tools available for converting forensic images to virtual disks.

Since this service was created, other more capable solutions have appeared. If you require a P2V conversion tool that works with raw forensic images and VMWare, we now recommend using OpenLV.

dd2vmdk is an online tool for converting raw disk images to VMware virtual disk files.

  • -Browser based conversion - uses the output of sfdisk and ldminfo as source information
  • -Supports Windows Dynamic Disks by converting back to regular partitions
  • -Requires no installation of foreign executables - everything done through pasting UNIX shell script commands

You can convert a dd image to a vmware vmdk with this tool by clicking here. To test it paste in the tool output in the walk-through below.

Guided Example


Using a live cd, such as Helix or Knoppix, create a dd image of the hard drive or raid array to be virtualized. It is assumed that the reader has enough problem solving ability or UNIX experience to determine the hard drive device of the machine in question.

The following example assumes imaging a system with a COMPAQ SMART2 array controller as the primary disk array. Its device is /dev/c0d0.

  • -We first record the output of sfdisk primarily so that we have a record of the geometry of the drive.
  • -Then we use the dcfldd program to read from the device, to a file called c0d0.dd. The conv=noerror,sync option tells the program to pad output blocks when it strikes a read error from the source. The hashwindow=0 hashlog=c0d0.md5.txt instruct dcfldd to create a hash of the input bytes as it copies, then finally record the hash when it is done to the file c0d0.md5.txt
  • -We print the hash of the source device, /dev/c0d0 as generated by dcfldd.
  • -Finally, we hash the image file, and compare it with the hash of the source file. Note here that due to read errors on either the source drive, or the image file these may be not equal. In this case we have a corrupt image.

			root@foo:/root # sfdisk -luS | tee sfdisk.c0d0
			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         -          0   0  Empty

			root@foo:/root # dcfldd if=/dev/c0d0 of=c0d0.dd bs=512 conv=noerror,sync hashwindow=0 hashlog=c0d0.md5.txt

			root@foo:/root # cat c0d0.md5.txt
			Total (md5): 8842802a3578d146bb2cb58ff1bf22f3

			root@foo:/root # md5sum c0d0.dd
			8842802a3578d146bb2cb58ff1bf22f3  c0d0.dd

			root@foo:/root #

P2V - dd to vmdk

At this point we have an image of the source disk, and a copy of the output of sfdisk (which importantly, we ran using its sector based addressing mode). Visiting the online tool d2vmdk we enter the name of the imaged device ( /dev/c0d0 ) and the name of the file containing the image ( c0d0.dd ).

We next open up the file containing the output of sfdisk from earlier. The tool prompts us to paste in this output:

			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         -          0   0  Empty

At this point, the disk inspects the disk geometry and partition layout from the contents of what was just pasted. In this case, the tool notes that the geometry of the source disk is different to that of the target disk. Fixing up these geometry related differences is the tool's primary purpose.

In this case, the tool also notes that the disk likely contains Windows Logical Disk Manager (LDM) or Dynamic Disks ( The two "SFS" partitions are indicators of this). In order to extract out the LDM partitions correctly, the tool needs more information. In this case, it asks for the output of the ldminfo tool, which has been created as a part of the Linux-NTFS project. The LDM parts of this project are currently very beta, but the ldminfo tool provides enough information in this case. We run ldminfo against the image, and paste the output into the tool. (A binary of ldminfo, suitable for running in a live CD is linked in the resources section of the page)

			Device       | Offset Bytes    Sectors    MiB | Size   Bytes    Sectors    MiB
			c0d0.dd      |            0          0      0 |  36393861120   71081760  34707
			c0d0.dd1     |     37601280      73440     35 |  10486579200   20481600  10000
			c0d0.dd2     |  10524180480   20555040  10036 |   4718592000    9216000   4500
			c0d0.dd3     |  15242772480   29771040  14536 |  21149777920   41308160  20170

The new partition layout is presented in the next screen.

The main heavy lifting of the application is now performed. After comparing the two disk geometries, the tool creates a plan for creating a new virtual disk (or set of disks if there are more than 4 partitions). The new virtual disk(s) has the following properties:

  • Partitions are aligned on cylinder boundaries
  • Partitions are each contained in their own file
  • If the boot partition is NTFS, the NTFS Master Boot Sector is fixed up for the new geometry

The next screen presents a set of commands which may be pasted into a UNIX command line on the new virtual machine host. The commands copy the partitions into their own files, and generate blank gaps in between partitions to ensure cylinder alignment. A new blank partition table is created, then sfdisk is used to create a new partition table. Finally, the NTFS boot sector is fixed.

The next screen contains the contents of a VMware Virtual Disk definition file, which is to be copied and pasted into a file with a .vmdk extension. This disk definition contains all of the information necessary to create a virtual disk from the previous step.

Booting the disk at this point in a VM will result in a Blue Screen, of type INACCESSIBLE_BOOT_DEVICE, as the VMWare Virtual SCSI drivers are likely not loaded into the OS. At this point updating the drivers inside the VM is all that is needed to get the machine fully up and running. My choice was to use the free UltimateP2V method.