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. Thank you for this post! Great information.

  2. Thanks, Yogesh! I wasn't able to get libfvde working properly in Arch, but using another Mac worked perfectly.

  3. I just did one such case. The acquired E01 image (encrypted) was from a MacBook with Yosemite (10.10) and the virtual machine i used under VMWare Workstation 10 on windows 7x64 (Yogesh method n. 2) was with Lion (10.7). The original image was mounted as physical disk with simulated write permission using Arsenal Image Mounter. The unlock of the encrypted volume inside the VM worked and now i've to acquire a readable image, i think to give FTK form Mac a try..

    1. At the time of writing this post, Arsenal Image mounter was not working for me, it has since improved into a vastly mature tool with most bugs ironed out. You can absolutely substitute encase PDE with Arsenal.

    2. Hi mr. Khatri, i'm facing a very strange situation. I had 2 apple computers that i acquired in target disk mode. One was encrypted for sure because as soon as the virtualized OSX Lion saw it asked for the password to unlock it. The second one is driving me mad because if i attach it to the OSX virtual machine (Arsenal and all the rest ..) i can browse its content with no problem but outside this environment no forensic tool is able to "understand" this second image. I tried X-Ways, Autopsy, OSForensic, various linux flavours but the result is always the same only EFI and Boot partition are correctly interpreted while the one that holds data (998gb out of 1tb) is seen as "raw". The password for this second computer is not the same as the other one (i tried booting both of them) and to be absolutely sure i used the keychain manager in the OSX virtual machine to delete the password that i had to use for the first computer but the result is always the same, inside OSX the drive is fully accessible but outside no tool i've acces to is able to read it. Have you ever seen something similar? Thanks

    3. I haven't encountered that situation yet. Perhaps you could elaborate on the OS version installed and file system used on the target (evidence) disk. I would run some of the commands shown in the blog post on your other Mac (with the target disk connected). Apple is rumored to be coming out with a new file system but that should be later next year. Newer versions of most commercial forensic tools (encase, IEF) should be able to decrypt filevault unless there is some non-standard configuration.