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.
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.