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.

Saturday, 19 January 2013

Volume Shadow Copy to Logical Evidence file (LEF)

Encase (or any other tool) does not offer any direct way of saving contents of a shadow copy to an Encase logical evidence file (L01). However this is easily accomplished by way of a script. If you have encase version 6, this script should do the job for you. Download it here.

This is a generic script that allows files from any folder on your local system to be added recursively (with subfolders) to an LEF. The folder you specify can also be the root of the partition (Eg: D:\) in which case it will add all files and folders of that drive into the LEF. Do remember that this is a logical recurse of files that are visible in explorer, do not expect it to grab streams and other artifacts (Recycle bin, etc..). 

One good use I have found for this is to copy out logical files from Volume Shadow Copies (VSC) inside evidence files.

Accessing VSC from evidence files (E01)

To get access to volume shadow copies stored on evidence, you need to mount your evidence disk into windows using Encase’s Physical Disk Emulator. This will mount the drive in a way that Windows sees it as a full disk device and its Shadow Copies are now visible. To get the exact path and other details of shadow copies, use the command ‘vssadmin list shadows’. You will need to run cmd.exe as Administrator for this.
Using the vssadmin tool to view Shadow Copies visible to Windows

The path highlighted above is the one that you give to the script. Do not forget to put a trailing backslash else the script won’t work. In this case it would be 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\

Saturday, 18 August 2012

Tracking USB First insertion in Event logs

The tracking of USB removable disks has been discussed and analyzed in detail with the usual methods of looking at the windows registry for plugged in devices (USBSTOR keys), registry shell bags, SetupApi logs, etc.

A while back researching something else I happened to hit upon an artifact not known for this purpose, the 'Windows Event Log'. The first time a USB device is inserted into your windows PC, it is logged in a little obscure log which is maintained for the 'ReadyBoost' functionality. This is only true for Windows Vista and above, as XP did not have ReadyBoost. For more information on ReadyBoost refer here

Whenever a new drive is connected to a windows system, windows will test that drive's read/write speed by creating a file on that drive and then deleting it. And this result is logged in the ReadyBoost log. From an investigator point to view, this does not give us too much information about the connected disk, but it does give some useful information, notably the name of the disk, sometimes the size (as shown in pic below) and the date/time when device was first connected to that system. This should correlate to the SetupApi log date/time. 

ReadyBoost Operational log under Windows Event Viewer

The messages are usually under EventID 1000-1023 with 1015 and 1016 being irrelevant (performance calculations for booting). It even logs the devices that are not disks such as 3G dongles and non-USB devices such as mounted VHD files with messages such as these:

This was for a partition on a mounted VHD file.
The date/time of log matches the date/time when partition was created.

When a new 3G dongle was plugged in..

When an IronKey was plugged in..

With this artifact, we have one more thing to confirm the date of first insertion of a device. This should be useful in cases where sometimes the registry keys make it difficult to confirm dates or device names/types.

The full path of this event log file on the system is
'C:\Windows\System32\winevt\Microsoft-Windows-ReadyBoost%4Operational.evtx'.

In the windows event viewer, you can view this log under
'Applications and service logs\Microsoft\Windows\ReadyBoost\Operational'. 

Saturday, 7 July 2012

vinetto and ubuntu

Vinetto is an open source software for viewing/extracting thumbnail information from Thumbs.db files. It is listed in the ubuntu repository and installing it from Ubuntu Software Centre is as easy as installing an application from the Apple App Store (or Google Play Store), meaning it requires no knowledge of linux! So far so good!

However out of the box, vinetto seems to have an issue running on certain types of Thumbs.db files (which it calls Type 1a files). For certain Thumbs.db files, you  may encounter an error that halts on line 338 of vinetto at im.split(). It seems to originate from the python imaging library (PIL) complaining about a null image object. This is using vinetto 0.07 and all the latest libraries, PIL 1.1.7 and Python 2.7 with ubuntu 11.04. The problem stems from a bug in PIL which does not load the image file on demand (as it should) when operation are performed on the image. The fix involves explicitly calling the load() function. We will need to edit vinetto's source and compile/install it. Since its a small python script, there isn't much of a compilation process (phew!). Download the vinetto source from here.

On line 338 (of file vinetto), you should see the im.split() function being called. You will need to insert an additional line here and add the line im.load(), so it looks like this:


This should fix the PIL error. Now re-install using the procedure mentioned in the vinetto INSTALL file.

This did solve the crash issue for the problematic Thumbs.db files, but for those files vinetto's extracted thumbnails were in the negative (inverted). Another few lines of code had to be added to fix this and the final edited file can be downloaded here.

I would be interested to know if anyone else has encountered similar issues. There is another unrelated issue, which has to do with Windows 7 generated Thumbs.db files. This I have documented in another post here.

Windows 7 generated Thumbs.db

Windows 7 does not use the Thumbs.db file for folder thumbnail caching. However when accessing remote or mapped drives, it does create a Thumbs.db file in the remote folder when it viewed in explorer.

A quick way to create this file would be to browse your own C drive using the path '\\localhost\c$' and see explorer drop Thumbs.db everywhere as you click around into folders. You may have to change the folder view to Icons or Large Icons for it to trigger.

The format is slightly different and no tool seems to handle it correctly as of now. The new format is still an OLE document, however microsoft have gotten rid of the 'Catalog' stream, and the names of other streams are strings which include the resolution (96, 256, ..) and a 64bit hex number. The stream contains a regular jpeg file, which usually begins at 0x18 (on xp this was 0x0c). The stream header also begins with 0x18, a likely indication of the beginning of data.


Regular carving for JPG files will work against it. The good news for investigators is that the behavior of this file is similar to xp Thumbs.db, ie, the thumbnails do not get deleted once the file (image) is moved/deleted from that folder. This is different from usual windows 7 behavior where deleted files are quickly removed from the Thumbcaches.

Friday, 15 June 2012

Windows 7 Thumbcache hash algorithm

What we know
Windows 7 (and vista) store thumbnails in a central database known as the thumbcache in the files thumbcache_32.db, thumbcache_96.db, thumbcache_256.db, thumbcache_1024.db, thumbcache_sr.db and thumbcache_idx.db. The format(s) for these files has been reverse engineered well enough to be able to read and extract the thumbnails.

What is yet unknown is the hashing algorithm used to generate the ThumbnailCacheId. I did some research of my own to fill this gap.

ThumbnailCacheId
To generate the ThumbnailCacheId windows uses the volume guid (that the file resides on), the fileId (for NTFS volumes), the extension of the file (.xxx) and the file last modified time (as a DOS GMT date). These are ‘blended’ and mangled using a hash function one by one. I believe the easiest way to describe this would be to simply show the code. Feel free to copy this code into your applications.

UInt64 CalculateHashKey (UInt64 seed, byte[] buffer, uint buffer_length)
{
  int count = 0;
  if (buffer_length) {
    do
    {
      seed ^= ( (seed >> 2) + (2080 * seed) + buffer[count++] );
    } while (count < buffer_length);
  }
  return seed;
}

UInt64 GetThumbnailCacheId (byte[] VolGUID, byte[] FileID, byte[] FileExtension, byte[] FileModTime)
{
  UInt64 hash = CalculateHashKey (0x95E729BA2C37FD21, VolGUID, 16);
  hash = CalculateHashKey (hash, FileID, 8);
  hash = CalculateHashKey (hash, FileExtension, FileExtension.GetLength() * 2);
  hash = CalculateHashKey (hash, FileModTime, 4);
  return hash;
}

Volume GUID can be found in the registry SYSTEM hive under ‘MountedDevices’. On a live machine, this is HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. If for example, your guid is ‘\\?\Volume\{ 234cf70e-a70c-11de-a48c-806e6f6e6963}’, then your buffer will have the value “0EF74C230CA7DE11A48C806E6f6E6963”.

FileID (or File Reference number) can be obtained from the MFT. Note: The FileID shown to you by tools such as Encase is simply the MFT Record number (without MFT Sequence number bytes). Read more about it here.

The extension buffer is Unicode text starting with the dot(.) as “2E006A0070006700" for “.jpg”. This is case sensitive.

For the DOS time, you can easily convert the file’s modified date from a FILETIME 64 bit value to the GMT DOS timestamp of 4 bytes.

Because this is a hashing scheme requiring so many inputs, it is not possible to reverse a ThumbnailCacheId back to a full path, which is what investigators would really love. Still, now you know how to validate your thumbnails against their respective existing files.

Thursday, 29 March 2012

Blackberry Date Formats


Timestamps within Blackberry IPD files follow 3 different date formats depending on which database they are stored in. At first it seems pretty odd, but then it’s probably the work of independent programmers/teams working on different databases and associated software for the device.

1. Call Log, Phone History and SMS Date

The date used in these databases is a Java date 8 bytes in size. Java dates are similar to unix timestamps, with only a multiplier and larger size (8 bytes instead of 4 for unix) for better precision.
Javadate = 1000 * UnixTimestamp
Hence to convert back, simply divide the 8 byte timestamp by 1000 and you get a unix timestamp.

2. Calendar Date

This date’s precision is only to the number of minutes. It is the number of minutes since 1 Jan 1900 0:0:0. Converting this date to standard unix timestamp (which starts at 1 Jan 1970) means we have to subtract the difference equivalent to the number of minutes between 1900 and 1970.
Taking into account the 17 leap years also between 1900 and 1970, we calculate the difference.
Difference = (Number of years * Minutes per year) + (Number of Leap Years * Minutes per day)
= (70 * 365 * 24 * 60) + (17 * 24 * 60)
=36816480 minutes
Our simple formula for conversion will be
UnixTimestamp = (CalendarDate – 36816480) * 60

3. Email Date

The dates used in email metadata (sent and received dates) are stored as 2 byte date value and 2 byte time value.

2 byte Date

The date is stored with upper 7 bits representing the year since 1996, ie, 1 = 1997, 2 = 1998 and so on. The next 4 bits represent the month (1-12) and the remaining 5 bites represent the day (0-31).
+----------------+----------------+
|      BYTE 1    |      BYTE 0    |
| 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 |
  \___________/ \_____/ \_______/
       year      month     day

2 byte Time

Time is stored with a precision of 2 seconds. That means that 14:05 will be represented as 14:04 and 14:06 as 14:06. The creators did not think that this level of fine precision would ever be required for an email’s metadata date. One reason for this is that you really need 17 bits to represent all possible values when hours, minutes and seconds are stored separately, 5 bits for hours (0-23), 6 bits for minutes (0-59) and 6 bits for seconds (0-59). But only 16 bits are available in 2 bytes, so the BB developers have dropped a bit from the seconds field, hence only 5 bits are used as shown below.
+----------------+----------------+
|      BYTE 1    |     BYTE 0     |
| 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 |
  \_______/ \_________/ \________/
     hour      minute       sec