Monday, 10 November 2014

Imaging drives protected with Apple FileVault2 encryption

Recognising FileVault2 encryption

Apple FileVault 2 facilitates full disk encryption and requires OS X Lion or later and OS X Recovery installed on the start up drive. It is easy to detect. In the screenshot in Figure 1 File Vault 2 is activated on the Macintosh HD volume. Note that Encase indicates that all clusters on this volume are unallocated. The other partitions visible are the EFI partition and the Recovery partition.

Figure 1

Any Mac using FileVault2 uses the GPT partitioning scheme. In GPT LBA0 contains a protective MBR, LBA1 contains the primary GPT header and LBA2 contains the first four partition entries. Each entry is 128 bytes long and contains a Partition Type GUID, a Partition Unique GUID, the starting LBA of the partition, the ending LBA of the partition and the Partition Name.
FileVault 2 partitions all have a Partition Type GUID as shown in Figure 2.

Figure 2

A quick examination of LBA2 (Physical Sector 2) of the Apple hard disk can establish if any of the first four partitions has FileVault2 enabled. LBA3 contains partition information for the next four partitions and so on (GPT allows up to 128 partitions). Figure 3 shows LBA2 viewed via disk view in Encase.

Figure 3

The second 128 byte partition entry is  highlighted in light blue.  The Partition Name Macintosh HD is visible from offset 56 within the partition entry.  The first 16 bytes highlighted in darker blue detail the Partition Type GUID but it is stored in an encoded form, therefore we can use the Decode tab to decode it as shown in Figure 4.

Figure 4

The extraction of each Partition Type GUID can also be achieved used the GPT Partition Parser Enscript. This Enscript outputs to the Console as shown in Figure 5. The FileVault2 volume entry is highlighted.

Figure 5

Imaging FileVault2 volumes

If the passphrase used to encrypt the volume is known, it is possible to prepare a decrypted image,  using the original image containing the encrypted FileVault2 volume as the source.

Firstly we need to convert the Encase evidence files containing the FileVault2 volume into a bitstream  raw image.  Guidance Software's Simon Key has written the Evidence File Converter enscript to do this.  This script allows you to choose the Mac DMG naming scheme for the image.  Store the resulting DMG files onto an external disk formatted with a file system that your Mac computer will recognise (as an aside I use the Paragon NTFS for Mac drivers so I use NTFS).

Next plug your external disk containing your DMG files into your Mac (mine is running the Yosemite OS) and launch Terminal.  Enter the command hdiutil attach -nomount path_to_your_dmg_files (tip -drag the first dmg file into the terminal window to auto populate the path).

Figure 6

We can see the FileVault2 volume detailed in Figure 6 at /dev/disk2s2 described as a Apple_CoreStorage partition.  Your Mac should ask you for the passphrase to unlock the disk as shown in Figure 7.

Figure 7

Once you have entered the passphrase, in the terminal enter the command diskutil list.  We can see in Figure 8 that the disk image is listed as /dev/disk2 and the unlocked encrypted volume is listed as /dev/disk3  (disk0 is my Macs hard disk and disk1 is the external disk containing the converted DMG files).

Figure 8

All that's left to do now is image the unlocked encrypted volume /dev/disk3.  In the terminal enter the command sudo dd bs=1m if=/dev/disk3 of=path to your output disk/output filename.dd

Once the dd image is completed you can add it into your case via the add raw image option.

Hope this helps someone.

Wednesday, 9 April 2014

Mac OS X "Set date and time automatically"

Just as I've found the time to write up a blog post along comes an appropriate time related subject.

Recently I examined an Apple iMac running Mountain Lion.  I was only given access to an image. This presented a problem because the matter under investigation relied on accurate time stamps and I had no system clock to check. I knew that by default Apple OS X (Snow Leopard through to Mavericks for certain and probably earlier versions) will Set date and time automatically whilst connected to the internet (to allow a connection to a network time server using Network Time Protocol [ntp] ) as shown in Figure 1.

Figure 1

The problem to overcome then was to establish where this setting was stored - I knew it would be in a plist somewhere - isn't everything Mac related stored in a plist?  :-)  So many plists so little time!  A little bit of research and testing allowed me to determine exactly where the setting was stored and as a result share this with you. Figure 2 shows the overrides.plist in the Finder at the path /private/var/db/launchd.db/

Figure 2

This plist is an xml plist so it can be read easily.  Figure 3 shows this plist viewed with the Xcode Property List Editor.

Figure 3

The key we are interested in is the org.ntp.ntpd key.  If the Disabled value is true Set date and time automatically is turned off.

Hope this helps someone.


Tuesday, 10 December 2013

Apple Safari update and fsCachedData

Recently I have had cause to look again at how the Apple Safari web browser stores cache. Surprisingly much of what I wrote concerning Safari back in 2010 still holds true.  The introduction of OSX Lion brought some changes in that a new table cfurl_cache_receiver_data was created within the SQLite cache.db database and used to store the cached item as a binary large object in the receiver_data field.   Previously this field was within the cfurl_cache_blob_data table.

I have now looked at Safari version 7 running in OSX Mavericks and found that not all cached data is now stored as binary large objects within cache.db.  In Figure 1 we can see a number of entries in the cfurl_cache_receiver_data table.  A number of them contain BLOBs as expected but in entry 18109 we can see that the new field isDataOnFS has a value of 1 and the receiver_data field has a value of ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E.

Figure 1

In Figure 2 we can see that the new fsCachedData folder contains the file ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E.

Figure 2

It appears that any file 4,096 bytes and larger is now cached externally in the fsCachedData folder.  I note that the files do not have file extensions so a file signature analysis will be required.  The file name is structured like a GUID. It does not appear to be a hash of the relevant URL.

The eagle eyed amongst my readers will have already spotted another type of entry within the receiver_data field in Figure 1.  Figure 3 shows more of them.

Figure 3


It can be seen that the data in the receiver_data field has the structure '474946.................................3B'. Seasoned forensicators will recognise this data as hex and that contained within it is the header and footer of a gif file. This data is stored within the Sqlite database as a BLOB however the SQLite utilty reading the BLOB has been configured to display BLOBs less than 50 bytes in size as a string.

Until next time.