All posts tagged forensics

Converting dd image to vmdk for analysis


Astute readers will notice that the names for the images used in this part are not the same as in Part 1. Good for you, astute reader. I pulled a 16GB Quantum Fireball out of an old desktop that had not spun up in at least two years. When I last booted the system it was a fully functional Windows XP SP3 desktop.

I imaged this drive using the method in Part 1. Verified the image and copied it from the Kali Linux laptop that I dropped the initial image onto to an external USB drive. Why? Because in forensics you NEVER want to work with the initial image. The entire process was about 45 minutes for all three steps. The external drive is USB3 and that definitely made the copy phase faster.

Converting this dd image to a vmdk file and then booting it is obviously going to change the hash. Just booting a Windows system adds multiple entries to the event log which is more than enough for verification to fail. Not to mention that the OS is going to install drivers for all of the new devices that are used by VMWare. In summary, NEVER WORK OFF OF THE INITIAL IMAGE.

Before we get to the actual conversion there is no reason this conversion couldn’t be from dd to VHD or VDI. I have VMWare Workstation installed on my laptop and not VirtualBox or Virtual PC. I have used all of these and can’t say I have strong feelings for any one over the others.

The Good Stuff

Get the qemu utils apt-get install qemu-utils

Next we use the qemu-utils to convert to vmdk qemu-img convert -O cmdk /path/image.dd /path/output.vmdk

qemu-utils conversion

Qemu-utils conversion

Get yourself a drink and stretch your legs. Forensics is a time consuming process. The conversion of this ~16GB dd file to vmdk took about 90 minutes.

The next step was to attach the disk to an existing virtual machine to ensure it would spin up. I happened to have a Windows XP virtual machine that I keep around mostly to run old software. Depending on how you plan on testing this hard drive you can take a snapshot of the drive to allow any changes to be rolled back; I didn’t do this simply because I could always convert the copy of the dd file again if I made some catastrophic change. If you wanted to boot directly into the XP operating system it would probably be necessary to run a repair install off of either a disk or ISO image containing the installation files. The chances that the underlying physical hardware is the same as the virtual hardware are just about zero. That is why VMWare has a physical to virtual converter.

Attachedh to VM

Attached to VM

Here is where the pen testing part comes in. I spun the VM up and opened the drive in Windows Explorer to ensure that it worked. Oh look right at the root. The Tax Backup folder. If this wasn’t my own drive I’d probably start there.

Pen Test Gold

Pen Test Gold

What next? Well we have covered acquiring the image and converting it to a virtual disk format. The next article in this series will cover juicy places to look in both the file system and Windows registry. It will probably have a cheat sheet for different operating systems to find data that will help you look good during the report writing phase of penetration testing. You know that phase? The one that everyone hates doing? Might as well look good doing it.


dcfldd for disk imaging



If you don’t have a USB write blocker remount the drive to prevent unintentional changes to the drive. This is good forensics. dcfldd is a part of Kali Linux but if you want to add it from source it is available here.

Find the installed drives on the system:

ls –l /dev | grep sd

grep image

/Dev output from grep

If you need more information about the drives to determine which is the source and which is the destination for the image:

fdisk –l

fdisk output

Output from fdisk

Change the drive permissions to read-only:

chmod 440 /dev/sdb

The drive is now set to read-only for both root and owner; it is time to start the image. This is a time consuming process dd takes a significant amount of time to copy the disk to image.

An astute commenter mentioned that changing the block size to 4096 bytes dramatically increases the speed of the image which is true. The default value is 512bytes. Leaving the default at 512 bytes is a belt and suspenders approach, if a block is bad dcfldd writes 0’s into the image. Using the smaller and slower default option minimizes the potential data lose. On a known good drive increasing the block size may be appropriate depending on the circumstances. Where forensics are concerned, especially if the image may be used in a disciplinary or legal setting, it is best to err on the side of caution.

The hashwindow option allows the image to be split into multiple smaller image files that individually hashed. This has the benefit of allowing a failed hash to only invalidate only a portion of the total image. The option takes an input value in bytes; to use this option set the hashwindow=1G. 

dcfldd if=/dev/sdb hash=sha1,md5 md5log=/image/md5.txt sha1log=/image/sha1.txt of=/image/toshiba.dd

Now you’re imaging.

One of the advantages of dcfldd is the built in hashing function. When the image is completed we can verify that the image is sound by checking the hash log and a separately generated hash.

Check the hash values created during the imaging process:

cat /image/md5.txt

cat /image/sha1.txt

To generate a separate hash for verification run the following and compare the outputs:

md5sum /dev/sdb

sha1sum /dev/sdb

Verify that the image file is good and that data hasn’t changed. You can use md5sum or sha1sum but they take forever to run. Dcfldd has a built in verification function.

dcfldd if=/dev/sdb vf=/image/toshiba.dd verifylog=/image/verifytoshiba.txt

This is what the whole process looks like.

Complete Image Process

Complete Image Process

If the verification fails you will get a message similar to this:

Verification Fail

Verification Fail



This article was edited on 7/20 to include great feed back that was received from reddit users as well as direct comments. The comment was published because of the email address used. If you want recognition please feel free to contact us and I’ll update it again. Thanks to F. Erensics and HackThe______ for providing insight.