Sunday, 17 March 2013

Decrypting Apple FileVault Full Volume Encryption

Scenario: You've imaged a Mac hard drive and later found out that the entire User Volume was encrypted. No forensic tool would directly work on it even when the password is known. Encase, FTK, etc. support a few popular types of encryption like Microsoft’s BitLocker but Apple FileVault is not one of them.



Apple's Full Disk encryption (actually volume only) is also referred to as FileVault2, as the same name was used earlier by Apple to perform User Home folder encryption. FileVault2 uses a new scheme with 128 bit AES encryption of the entire volume.

Decrypting the volume

NOTE: To proceed you need to know the password or recovery key to the volume, this post is NOT about cracking the File Vault password.


Method 1: Use Joachim Metz’s libfvde project

The libfvde project is currently experimental but works just fine. You will need to extract the Encrypted.WipeKey.plist file from the image’s Recovery partition and provide it to the tool on the command line along with the password / recovery key of the disk. You can extract the file using Encase or FTK imager easily.

This is the ideal approach as you only need to run one single command to do the decryption. The procedure is well documented at the libfvde wiki.

Method 2: Use another Mac (running at least OSX 10.6 Lion)

Sometimes having access to a Mac can be a pain as most lab setups are windows / linux. If you can’t get a Mac machine, VMware comes to the rescue. Mac OSX does not run on PC platform, but hacks (google for "Mac OSX Unlocker") are available to download. Use at your own discretion! Once you have your own mac (real or VM) up and running, simply attach the Encrypted disk to the machine and you are ready to decrypt. Yes, that means you have to restore the image to another drive first! If you are using a VM, you can skip the restore part and follow these steps instead.

An easy way to go about this is to use something like Encase’s Physical Disk Emulator. Make sure you turn ON the disk cacheing option here, because although the disk is going to be read-only, the method won’t work as some writes will be required. To fool the OS into believing our disk is a read-write one, the cache is there; all writes go to the cache and not to the emulated disk. It’s a real nifty feature.

Once the disk is emulated in windows, you can add it to the Mac VM via the ‘Edit VM settings’ option and adding a new Hard disk, then choosing the ‘Use Physical disk’ option. Select the disk from the drop down menu. (If you are unsure of the disk number, take a look at the hard disks available under ComputeràManageàDisk Management)

Now start your Mac, once booted, start the Terminal and use the following commands to ‘Unlock’ the encrypted volume.

First, check to see if your encrypted disk was even recognized. This is easily accomplished using the command:
diskutil list

Mac should automatically recognize the FileVault encrypted disks. Now list the File Vault encrypted volumes:
diskutil corestorage list

Find your encrypted volume's Logical Volume UUID in this output.

The next step is to unlock the volume so that we can access the decrypted data. The command for this is

diskutil corestorage unlockVolume VOLUUID -passphrase PASSKEY
Here you will substitute VOLUUID with the corresponding volume UUID and PASSKEY with the recovery key or the password.

If the command successfully completes, you get a message indicating that. Now go ahead and list the volumes again.
diskutil list

That lists the volumes, among them will be the virtual volume that represents the decrypted volume. At this point, you are free to use whatever tool you wish to image the decrypted volume, this could be either FTK imager for mac or just plain old ‘dd’. You can add another disk drive to your machine as the destination for your decrypted image. Or use a combination of dd and netcat to stream the data back to the host machine (if you are on VM).

TIP: If you use dd, you will need to specify the source disk as ‘/dev/rdiskxx’ instead of ‘/dev/diskxx’. This is a mac convention, you cannot access /dev/diskxx as it will always report as busy and fail.

1 comment: