"Defeating" Whole Disk Encryption, Part 3

In Part One, we reviewed obtaining the last 16 characters of the PGP password from a computer that was live. In Part Two, we reviewed how to set up your VMware box so you can boot the image. In this post we will review the options for imaging the computer, be forewarned, neither is a perfect solution.

Tools you may need:

1. The PGP recovery .iso. You will need the correct .iso for the version of PGP installed on the computer. You can find the files linked from this page.

2. You may also need the original media used to install the OS on the computer, or a version that is very close. In other words, if the computer is running XP Home, you will need an XP Home CD. It's usually better to have the one that was used to install the OS on your suspect's box, but I've had success without having it.

Now it's time for the choice we discussed in post two; do you need unallocated space? If you don't, you can jump down to the decryption option, but really, now would be a good time to back up your VMware files - you'll need them so you can go back to a good image, and to document your work. Let's call this back-up 1.

"LIVE" ACQUISITION OPTION:

Boot your drive, enter the PGP password and get through the windows boot sequence. If you have boot failures, use the OS CD to get the necessary files and continue to reboot until you can boot the computer. Once you have the drive booted, you can use a variety of tools to acquire the drive back to the share on your computer.

You may need to add another drive share if you do not have sufficient drive space - follow the steps you followed to add a shared folder if you do.

The advantage of this method is that you will be able to access unallocated space and file slack on the drive. The disadvantages include having to make multiple changes to the drive which includes adding files. The good news is that another examiner will have to follow the same steps (when using your computer). The files that you add won't be evidentiary in nature, but you are changing the evidence; however, there is no other option of which I'm aware so I think it's defensible.

DECRYPTION OPTION:


Edit your VMware session and change your CD ROM device from the physical device to the .iso image that you downloaded from PGP.



Save your settings and boot the VM ensuring that you are booting to the CD first.

The CD will ask for the PGP password and run through a decryption dialogue. I'm writing this from memory, so I won't try and outline the steps, but it's self explanatory. After you begin decryption, take the day off because you are going to have long wait. I've found that it takes 16-24 hours.

Once the drive is decrypted, take a snapshot with VMware and then save those files as backup 2.

Now you can boot the computer, or pull the decrypted VM into Encase for analysis. You won't see anything in unallocated space. Apparently, VMware only decrypts allocated files, but you should have all the active files available for analysis. Again, not perfect, but better than nothing right?

A couple of other thoughts:

I suspect that putting a new drive in the suspect's computer and installing a new OS with VMware etc. on your drive, then booting the suspect's drive as a VM would get past the compatability problems - if anyone has time to test this, I'd be really interested in knowing your results.

If you don't have the PGP password, AccessData's Password Recovery Toolkit and Distributed Network Attack can be used to brute force the partition. I haven't tried it, but they claim that this is possible.