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.
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.
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:
Mac should automatically recognize the FileVault encrypted disks. Now list the File Vault encrypted volumes:
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
If the command successfully completes, you get a message indicating that. Now go ahead and list the volumes again.
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.
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 PASSKEYHere 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.
Thank you for this post! Great information.
ReplyDeleteThanks, Yogesh! I wasn't able to get libfvde working properly in Arch, but using another Mac worked perfectly.
ReplyDeleteI 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..
ReplyDeleteAt 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.
DeleteHi 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
DeleteI 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.
DeleteHi Yogesh. I have a question. We have the MAC VM running and created an emulated disk(encrypted image) in Encase which showed it was mounted on Physical Device X . When we tried to run the VM with the physical disk (encrypted), it shows the error "The operation on file "\\.\PhysicalDriveX" failed." When I continue to open the guest system and check using diskutil list, I can see the apple corestorage. But if I try the diskutil corestorage list, the physical volume status is failed and logical volume group shows initializing. Would you happen to know any solution for this? Thanks.
ReplyDeleteVMware isn't perfect. I would reboot (host and vm) and retry, its worked for me with that kind of problem. Also, make sure in encase you have the Disk cacheing turned ON.
Delete