File Vault’s Dirty Little Secrets

File Vault is the encryption mechanism used to protect user accounts on Apple’s Mac OS X file system. While disabled by default, many people rely on file vault to protect their personal data. Many criminals, no doubt, also use file vault to encrypt content that would otherwise be incriminating. The security offered by an encrypted volume comes at a price – Apple’s closed source approach has left a significant amount of ambiguity about how the system actually works, and many erroneous assumptions have left holes for data to be recoverable. Among these misconceptions are the idea that raw data inside a vault cannot be accessed, and the erroneous belief that mechanisms such as Apple’s free space wipe will remove deleted data. This brief how-to shows you how to obtain a raw disk image from a file vault, and illustrates that deleted data can be recovered. It also shows that mechanisms like Disk Utility’s “Erase Free Space” option doesn’t affect the deleted contents inside a vault.

This how-to is not related to cracking File Vault encryption. There are a few papers on the subject already, and many existing techniques to recover a key. These include brute force crackers, such as vfcrack, cold boot attack, and cryptanalytic attacks. In addition to these methods, there are also keyboard loggers, surveillance techniques, and court orders which can be used to coerce passwords out of individuals. Instead of trying to come up with yet another method to obtain a vault key, this how-to provides instruction on what to do after the key is retrieved. It is a brief introduction to the proper imaging techniques of a vault – namely, how to recover the raw disk image for processing through forensic tools (such as FTK or EnCase), or data carving techniques to extract deleted data (such as Scalpel or Foremost).

The many papers I have seen to-date on this subject seem to have overcomplicated the imaging process, suggesting bizarre calls to low-level frameworks or using tools such as vfdecrypt to peel back layers of the volume. This is completely unnecessary. There is a very simple way to mount, decrypt, and obtain a raw image of a file vault. Mac OS X itself has all of the tools needed to mount a vault and associate it with a raw device suitable for copying with tools like disk copy.

We’ve created a test account, named “test” to illustrate some basic principles. Our test account has a File Vault encrypted home directory, which you’ll find on the suspect’s hard disk in /Users/. Presuming you’ve made a copy of the suspect’s drive, or are mounting it with a write blocker, you’ll be able to access this on a Mac once mounted:

$ sudo -s
# ls -l /Volumes/Suspect_Disk/Users
total 0
-rw-r--r--   1 root  wheel     0 Sep 23  2007 .localized
drwxrwxrwt   4 root  wheel   136 Oct  5 18:34 Shared
dr-x------   3 test  staff   102 Oct 10 13:11 test

A peek inside of the user directory shows another directory named test.sparsebundle. This contains the files that comprise the suspect’s file vault:

# ls -l test
total 0
drwx------@ 6 test  staff  204 Oct 10 12:58 test.sparsebundle

This is the part where some examiners would have you run a series of obscure tools to try and get at the data inside the bundle. Presuming you’ve deduced the key using vfcrack (or by some other means), Mac OS X’s hdid tool can provide you with all you need to get access to the raw image:

# hdid -readonly test.sparsebundle

After being prompted for the File Vault password, the hdid tool will give you a mapping to a series of raw devices for the image:

/dev/disk2          	Apple_partition_scheme
/dev/disk2s1        	Apple_partition_map
/dev/disk2s2        	Apple_HFS

The third device down, disk2s2, is the one you’re interested in; it contains the HFS file system containing the suspect’s home directory. You can copy off the enire file vault’s contents with a simple disk copy:

# dd if=/dev/rdisk2s2 of=/Volumes/Digital_Vault/rdisk2s2 bs=16384

Here’s the annoying part: because the vault is mapped onto the file system, you’re actually going to get a very large file containing a lot of padding; this could be several hundred gig in size depending on the virtual size of the file vault. You’ll need to make sure you have adequate disk space to contain this image.

Once you’ve got the image, it can be accessed much like any other HFS image. You can load it into FTK, or use a data carving tool like Scalpel to get data off of it. In addition to this, you can rename the image to have a .dmg extension and mount the decrypted file system right on your mac:

# mv /Volumes/Digital_Vault/rdisk2s2 /Volumes/Digital_Vault/rdisk2s2.dmg
# hdid -readonly /Volumes/Digital_Vault/rdisk2s2.dmg
/dev/disk3          	                               	/Volumes/test

Data Retained Beyond File Vault Compact Operation

I was interested to know to what extent deleted data was retained in the file vault, so decided to log into the test account and create a bunch of large files, which I subsequently deleted. In addition to this, I opened up Safari and browsed a few sites to generate some additional noise.

$ perl -e 'for(1..10000000) { print "BADCODED\n"; }' > badcoded

I did this ten times into ten different files, browsed a bit, then logged out. All of the data was easily recovered through the raw disk image:

# cat /dev/rdisk2s2 | strings | grep BADCODED | wc -l
 100247702

If the machine is plugged in, Mac OS X will attempt to compact the vault to reclaim free space when the user logs out, if it believes that a significant amount of cleanup is necessary. This process releases some of the bands from the vault’s file system, which causes some loss of deleted data. Even after the compact function occurs, however, some of the deleted data is still present in the raw image.

# cat /dev/rdisk2s2|strings | grep BADCODED | wc -l
 4030907

Not as much as we’d have liked, but still plenty. Any time a “pocket” is created in a band, it appears that the data from that band is preserved. This suggests that the more activity a user engages in, the more data will be retained beyond a compact, as more of these pockets will be created. Given that this was a single iteration of data, consider too that prolongued use could result in an even higher abundance of deleted content. The mere presence of some deleted data definitively establishes that the image we copied was in fact a raw disk-type of image, and not a mere copy of the live file system. It also shows that File Vault does not adequately flush all of the deleted data from a user account when it compacts free space, as many erroneously believe it does.

The data that did get destroyed was the result of the free space recovery mechanism, but this feature only engages at certain times. If the suspect keeps their machine powered on most of the time, this free space recovery isn’t likely to occur very often. It only engages when the user powers down or logs out, and even then, only if it believes that garbage collection is necessary. In addition to this, a device that was seized while powered on can be forcefully powered down by holding down the power button or removing its power source, preventing free space recovery from occurring. Finally, if the device is a notebook, disconnecting the A/C power will skip this recovery on logout.

Due to the ambiguity of File Vault, many users are likely to make the false assumption that their deleted data is purged from the file vault. This is clearly not the case, and in fact, deleted data can survive a cleanup.

Data Retained Beyond Free Space Wipe

One of the biggest misconceptions about File Vault is that a free space wipe can clean out old data, like it does on the rest of the volume. Mac OS X includes a Disk Utility, which contains an “Erase Free Space” mechanism. Many rely on this mechanism to purge deleted data from the system by overwriting it with zeros. Again, due to the ambiguity of File Vault, many make the false assumption that this process overwrites files deleted within a file vault.

The retention experiment below determines whether the Disk Utility’s “Erase Free Space” option affects a file vault volume. I recreated the same set of ten files on disk, deleted them, and then ran a free space wipe using Mac OS’s Disk Utility program. The entire process took about a half hour to complete. I then tested agan for existence of the deleted files. The result was that all of the contents of all ten files were recovered intact, even after the free space wipe. To understand why, you must understand how the wipe process functions:

Apple’s “Erase Free Space” mechanism works by writing a very large file full of zeros. The process copies the contents of /dev/zero (a continuous source of zeros) to a file in /var/folders, until the volume becomes full, at which point it is deleted. The inherent flaw in this is that the user’s file vault is viewed as a separate mount point than the root file system of the disk, and of course files created on one mount point won’t affect another. The result is that the root file system becomes full, but the deleted data on the user’s file system (within their file vault) remains untouched. This effect is the same as filling up a partition on a Unix system, where the space on other partitions (such as /usr or /home) would not be affected.

If the suspect attempted to destroy evidence by using the Disk Utility’s “Erase Free Space” mechanism, this attempt would fail to erase anything but the free space on the root file system, leaving the erased file vault data carefully preserved.

# cat /dev/rdisk2s2 | strings | grep BADCODED | wc -l
 100247722

Conclusion

It’s much easier than many think to get the raw data from a File Vault encrypted volume, provided the key has been deduced, captured, or provided under court order. Encrypted volumes preserve much of the data that is deleted from the volume. Because a file vault is treated as a separate file system, a free space wipe does virtually nothing to destroy deleted data stored inside a vault. Due to Apple’s policy of “security by obscurity”, many false assumptions have been made about the File Vault encryption mechanism, potentially exposing sensitive data to someone with the right tools. Users should be aware of File Vault’s caveats and limitations before relying on it as a means of securing data.