Migrate Encrypted OS to Another SSD Drive using VirtualBox

Finally, I got resolution on my encrypted drive migration problem using VirtualBox, and the best part is: it's done using only free, open source applications. In a nutshell, the steps are:

1. Import system to a virtual machine by cloning it
2. Decrypt virtual drive
3. Extend virtual drive
4. Copy virtual drive to a new physical SSD

WARNING: this is what I did, it worked for me, it might not work for you. If you blow your drive, or ANYTHING else negative happens, including, but not limited to rain, hail, earthquakes, FBI, do not come blaming me, I have nothing to do with it, all is completely your own responsibility.

Now that we are done with indemnification, here is what I did:

Make a raw copy of encrypted disk

I have temporarily created NTFS file system on a new disk, so that I could copy a raw image of encrypted disk into it.

I used Live CD to boot into Ubuntu and make a raw image of encrypted system disk. You could use disk utility to see which disk is mounted on what device. My encrypted disk has loaded as sda and target SSD loaded as sdc. I mounted NTFS partition , and created a raw copy of encrypted disk, by going into the terminal and executing following command:

# mount /dev/sdc1 /mnt
# dd bs=8M if=/dev/sda of=/mnt/original-disk.img 

Time used: ~1 hour.

Import drive into VirtualBox

I already had VirtualBox installed. Now I need to import a drive. Use following command to convert raw disk into a virtualbox disk:


> vboxmanage convertfromraw m:\original-disk.raw D:\Files\VM\Migrate\original.vmdk 


IMPORTANT!!! I will later on decrypt OS on this virtual disk, so it's important that drive D: is encrypted. Alternatively, if you don't have a second encrypted disk, you can just shred this file instead of delete, and/or clear the empty space. Needless to say, do not use non-encrypted SSD for this purpose.

Once this is over, I created a virtual machine and attached a system disk to it. I gave it maximum amount of processors and plenty of RAM, since it will be using CPUs to decrypt the system. Here's how it looks like:

It took me a lot of effort to ensure, that when I boot this image, I do not see this:

STOP 0x0000007B happens because by running OS in virtual environment, we are using different disk controller, than originally was on the system. Windows will crap out when there are no drivers pre-configured for new disk controller. This is very annoying, especially since it is perfectly capable of locating the drivers or using generic one, but it is what it is. I tried quite a few combinations, until I finally booted using this:

Time used: ~1 hour for conversion, many hours to figure out controller snafu.

Boot and Decrypt Source Disk

Now that my virtual machine is bootable, I could log on and decrypt the system drive. This operation will not expose sensitive data, since virtual disk image is located on encrypted drive.

As you see, takes awhile to decrypt. Unfortunately, VirtualBox is not too speedy. Good thing, you could use your computer while doing it. Lower down priority of virtualbox process, that would make computer more snappy.

Prepare a Copy of Target Disk

Open up target drive properties in Device Manager, and note how many megabytes exactly is on your target disk (Capacity):

I went to VirtualBox and created target disk with exactly that size:

Move Installation to New Drive Image

I added the new drive, this time using SATA controller, just so that Windows installs drivers for it, and verified that computer starts. I also added CDROM, so that I could start Ubuntu to copy drive.

I started the OS to make sure the drivers get installed. While working on that task, it becomes very clear how much of a speed boost was system on SSD.

Now I boot Ubuntu and copy disk to the new drive image. I am not moving it to SSD yet, because the image still needs to be encrypted

Then I reboot, and use gparted to expand the target disk:

Time to complete: a little over an hour.

Encrypt Target Drive

I am back to putting drive on IDE controller, somehow I'm getting BSOD otherwise

After chkdsk cycle, the OS will start, and I am going to encrypt it, business as usual, except it takes quite a bit of time:

Finally...

Convert VDI to raw bytes

Theoretically, it is possible to mount a physical disk directly on virtual machine, however I had problems writing to it after that. It is also (theoretically) possible to clone VDI to \\.\PhysicalDriveX using VBoxManage, but that also didn't work well for me.

So I took a longer, but safer route - make a raw image of a target drive, then copy it in Ubuntu. For that, I used a spare drive. Since the image is already encrypted, I don't need another layer of encryption on the drive.

> VBoxManage clonehd D:\Files\VM\Migrate\Migrate.vdi I:\target.raw --format RAW

Copy Drive Image to SSD

For this task, I physically connected the target drive and the one that has an image, and booted my physical box Ubuntu.

unmount SSD (Ubuntu mounted all volumes automatically), and dd image to a device:

# umount /dev/sda1
# dd bs=8M if=target.raw of=/dev/sda

Time to complete: less than 1 hour. That did it, and now my new SSD is bootable.

Some observations

There is probably an easier way to migrate the data. One way is to grab image of system drive using disk2vhd utility, which will allow to skip decryption step. Comment with experiences and happy migrations!

Failed Migrations

In my attempts to migrate encrypted drive, I tried so far following methodologies, unsuccessfully:

Failed: Clone using Acronis

Pre-install OS on a target disk. Encrypt OS. Boot original disk, and mount target disk using truecrypt. Perform Acronis image migration.

Result: fail because Acronis does not see TrueCrypt-mapped target disk as a valid device, so won't migrate to it.

Failed: Try cloning via Ubuntu:

- Boot Ubuntu.
- Copy sector-by-sector source to target (really, all I care at this time is MBR and partition table).
- delete system partition on target and recreate it in order to resize. Truecrypt will still accept that partition.
- Install TrueCrypt. Mount both drives to /dev/mapper/truecrypt1 and 2.
- Use ntfsclone to clone from 1 to 2.
- Use ntfsresize to make ntfs partition fill the space

Result: NTFS looks fine, disk looks fine. chkdsk finds no problems. Boot prompts for all the right stuff. System won't boot.

I think the reason why I'm failing is that TrueCrypt pre-boot code still thinks, that the drive is smaller than it actually is. If this is the case, a hybrid approach of 1) and 2) might work:

- Partition target disk to match source disk scheme
- Install OS to target, encrypt it.
- Boot Ubuntu, mount both source and target partitions.
- Clone NTFS using ntfsclone, and then resize using ntfsresize.

How To Migrate Encrypted Drive

Problem

I recently got a new 240Gb SSD to replace my older one. The old one was encrypted by a TrueCrypt, which makes it harder to make a clean migration.

The usual advice you will get when migrating to a new hard drive is to decrypt the data on the old one, migrate, then re-encrypt the new one. It could have been a good advice, except there is no way to guarantee that all the existing data was overwritten:

The security risk associated with SSDs is that sensitive data cannot be reliably erased due to the delayed erasure of deleted blocks and the operation of the SSD wear-leveling mechanism. The solution is to encrypt the SSD as soon as you take possession of it and before you write any sensitive data to it in plaintext. 
Thus, it's not a system encryption issue or a TrueCrypt issue. The issue is that you can't reliably sanitize an SSD. If you've already written sensitive data to an SSD as plaintext then it's too late for you to achieve 100% data privacy. 

Why is it important? The data, that could be left on the drive could contain, among other sensitive data, portions of swap file, which contains raw memory dump with all the keys and passwords in non-encrypted form. With SSD wear-leveling mechanism, you could pretty much guarantee, that sectors of swap file would be all over the place. Therefore, it is crucial, that the drive is encrypted before migration.

Plan

Here's what I'm planning to do here. In order to successfully boot with SSD, you must have a) properly set up mater boot record; b) correct copy of a drive.

Here is the process I will follow:

1. Replace an existing disk with a new one
2. Install operating system from scratch, ensure it has no page file.
3. Convert system partition to TrueCrypt
4. Put back an old drive, and boot from it. Have a new drive attached.
5. Mount both drives. Using Acronis, make a sector-by-sector copy.

Stay tuned, I will make another post once I get a drive.