Tuesday, 24 December 2013

Device LastRemovalDate & LastArrivalDate Behavior in Windows 8

Many people have asked me the conditions when the LastRemovalDate property gets populated and why its missing in some cases. I had run some test cases to determine the conditions and behavior of windows 8 with device insertions and removals earlier and am now documenting the results here. For those unaware of these timestamps, please read the post here first.

Device activity behavior

Whenever a device is plugged into a windows 8 machine, the LastArrivalDate timestamp gets set (to current date & time). At the same time, the LastRemovalDate gets deleted (if it was set earlier). Now whenever the device is removed from the system (when system is running!) that is the only time the LastRemovalDate will get set (to current date & time). Windows can detect both a clean eject as well as an unclean direct disconnect of the device, and in both cases the LastRemovalDate timestamp gets set.

If a device is attached to a system and then the system is shutdown subsequently with device still attached, then the LastRemovalDate will NOT get updated! So if you are seeing a missing value for LastRemovalDate, this is likely what happened, ie, the device was still plugged into the system when it was shut down. So the windows last shutdown timestamp for that session could be taken as the LastRemovalDate by an analyst.
Now on subsequent reboot(s), this device timestamp (LastRemovalDate) will not get updated and it will remain missing, until the device is seen by windows again and windows witnesses a removal of that device (as noted above).

However, also note that even if the device is NOT removed and re-plugged in, windows will still treat it that way when you reboot the system. So, reboots with a USB disk plugged in will update the LastArrivalDate as if it had been inserted immediately on boot.  This means that if you have a USB disk always connected to the system and never removed, windows will still update the LastArrivalDate each time on a reboot.

How this impacts an analysis?

The forensic analyst must be careful about interpretation here, the LastArrivalDate may not be the last time the device was physically connected by a user, it may have been there (connected) for a long time prior! One way to check is compare this with the system boot time. If they are quite close (within a few seconds or a minute), then its probably connected prior to boot, else it was indeed the last time device was physically connected.

Also because LastRemovalDate is deleted upon subsequent device arrivals, you should never ever see LastRemovalDate that is prior to a LastArrivalDate. If you do, then that probably means the clock on the machine has been altered between insertion and removal of the device!

The table below summarizes activity and behavior of these timestamps.

Activity / Action
Device Plugged in
Device Removed
 (Both Clean Eject & Direct Removal)
Machine Shutdown with device still plugged in
Machine Restarted with device still plugged in (device not removed and re-attached)
    The dash ( - ) indicates no changes occured, values remain what they were earlier.

Monday, 16 December 2013

Amcache.hve - Part 2

My last post about the Amcache.hve file only concentrated on the 'File' key since that's where all of the good stuff is! This post describes the remaining contents of the Amcache.hve file, the other files in the AppCompat folder (where Amcache.hve is located) and useful information contained therein.

As noted in the earlier post, there are 4 sub-Keys containing data - File, Generic, Orphan, Programs. There is also one value called Sync as shown below.

Contents of Amcache.hve/Root

The Sync value holds an 8 byte FILETIME timestamp. I believe this represents the last time this data was synced with the 'AEINV_CURRENT.xml' file also contained in the same folder as amcache.hve. However, not all information is synced. The synced information appears to be mostly about installed programs or installers run. Traces for standalone application (applications that are not installed) runs are never synced and only remain in the Amcache.hve file. Update (9 Jan 2014): Standalone applications runs are also seen here at times.

Programs Key

The 'Programs' key contains data about installed programs, the same information you can find in the Control Panel -> Programs & Features. This is somewhat similar to the data in the File key. Each subkey contains a ProgramID, which is an ID assigned to every MSI (installer) package when it is compiled. Each of these contain values as seen below. The interpretation of these values differ from the ones found under 'File'.

Here is the description for values that exist under Programs.

ValueDescriptionData Type
0Program NameUNICODE string
1Program VersionUNICODE string
2PublisherUNICODE string
3Language code (1033 for en-US)UNICODE string
4~ Not seen ~
5Unknown Flags (usually 256)DWORD
6Entry Type (usually AddRemoveProgram)UNICODE string
7Registry Uninstall KeyUNICODE string
8~ Not seen ~
9~ Not seen ~
aInstall DateQWORD (Lower 4 bytes is unix date)
bUnknown (always zero?)QWORD
c~ Not seen ~
dList of File PathsUNICODE strings (REG_MULTI_SZ)
fProduct Code (GUID)UNICODE string
10Package Code (GUID)UNICODE string
11MSI Product Code (GUID)UNICODE string
12MSI Package Code (GUID)UNICODE string
13Unknown (usually zero)QWORD
FilesList of  Files in this package (VolumeGuid@FileRefUNICODE strings (REG_MULTI_SZ)

In my analysis, most of the files (not all) referenced in the 'Files' list here could be found in the 'File' key.

Orphan and Generic Keys

The Orphan Key contains keys having the name in the format VolumeGuid@FileRef. A sample key looks like this:
where '44177282-4260-11e3-9713-806e6f6e6963' is the Volume GUID and '30000e61a' is the file reference number. Beneath this key is a single Value by name 'c' containing an unknown DWORD value which is either 0 or 1.

'Orphan' key in Amcache.hve Hive
See the below screenshot for a view of the Generic Key. Under the '0' subkey you find many keys which are either GUIDs or File IDs. These File IDs (as Microsoft calls them) are simply SHA1 hashes of the files they represent.  It is unknown what the GUIDs represent. Similar to the Orphan keys, here too each of these leaf node keys (GUID or File ID) has a value by name '0' containing an unknown DWORD which is either 0 or 1.
'Generic' key in Amcache.hve Hive
Cross referencing entries from the 'File' and 'Programs' keys to the files referenced by Generic and Orphan shows many matches, many missing as well as extra entries. So the relationship between these is not entirely clear.

Other files in this folder

Apart from the log/cache files associated with the Amcache.hve hive, there are some other files in the AppCompat folder:
The AEINV here stands for 'Application Experience Inventory'.
All of the above are XML files containing similar data about installed programs, files, application metadata and IE Addons (toolbars and plugins) information. The AEINV_AMI_WER_{MachineID-GUID}_DATE_TIME.xml file is related to Windows Error Reporting (WER). Here the MachineID-Guid is a value generated and used by WER only. This file existed in Windows 7 too with almost the same contents.

Device Information (new in Windows 8)

In Windows 8, this file also stores machine Device information containing among other things USBSTOR information although not in the detail found elsewhere in the registry. So you don't have device unique serial IDs or container IDs but you do get some descriptive strings like 'Seagate Backup+' or 'Sandisk Cruzer v3'. It does contain some Device GUIDs (although I am unable to match it to anything in the registry or setupapi log yet).

Snippet from AIENV_AMI_WER_xxxxxx xml file showing USBSTOR device info

AEINV_PREVIOUS.xml also existed in same format in Windows 7. AEINV_CURRENT.xml is a new addition in Windows 8, but contains similar data. By analyzing the timestamps and USNJRNL log, it is apparent that periodically the 'PREVIOUS' file gets deleted, then the 'CURRENT' file get renamed to 'PREVIOUS' and a new 'CURRENT' file is created and populated with data. (That was obvious from the file names but I just had to confirm!)

Snippet from the parsed NTFS $USNJRNL.$J file

Wednesday, 4 December 2013

Amcache.hve in Windows 8 - Goldmine for malware hunters

Corey Harell has uploaded an excellent writeup on the working of Windows Application Experience and Compatibility features. Here he explains how process entries/traces show up in locations such as the ShimCache and RecentFileCache.bcf. For forensic/malware analysts, this is a great place to search for recent processes that were run.

This post is a logical continuation of Corey's post. In Windows 8, the 'RecentFileCache.bcf' file has been replaced by a registry hive named 'Amcache.hve'. The location of this file is the same as its predecessor:

This file stores information about recently run applications/programs. Some of the information found here includes Executable full path, File timestamps (Last Modified & Created), File SHA1 hash, PE Linker Timestamp, some PE header data and File Version information (from Resource section) such as FileVersion, ProductName, CompanyName and Description.

The Hive

Amcache is a small hive. Below is a view of the hive loaded in encase. There are only 4 keys under a 'Root' key. (Folders in the registry are called keys). The data of interest to us is located in the 'File' key. Files are grouped by their volume GUIDs. These are the same Volume GUIDs that you can find in the SYSTEM hive under MountedDevices and also under NTUSER.DAT MountPoints2.

File References

Under each volume guid are File Reference keys each representing a single unique file. In case of an NTFS volume, this key name will look something like this: e0000430d. This is the NTFS File Id and sequence number. Here sequence number is 0e and file id is 0000430d. For FAT volumes it is unknown what this value represents. On a FAT volume, this File Reference is the byte offset of the Directory entry for that file, ie, the offset from the start of volume where this file's directory entry resides.

The Last Modified date on this key may be taken as the first time a particular application was run. I have not seen it change on subsequent runs. Under this key reside several values holding details about that file. Refer the illustration below. This is for a file on a FAT volume on external USB disk.

Value Names are in hexadecimal and range from 0 to 17 and then two extra entries for 100 and 101 are seen. Here are the descriptions I have been able to decipher so far.

ValueDescriptionData Type
0Product NameUNICODE string
1Company NameUNICODE string
2File version number onlyUNICODE string
3Language code (1033 for en-US)DWORD
5File VersionUNICODE string
6File Size (in bytes)DWORD
7PE Header field - SizeOfImageDWORD
8Hash of PE Header (unknown algorithm)UNICODE string
9PE Header field - ChecksumDWORD
cFile DescriptionUNICODE string
dUnknown, maybe Major & Minor OS versionDWORD
fLinker (Compile time) TimestampDWORD - Unix time
11Last Modified TimestampFILETIME
12Created TimestampFILETIME
15Full path to fileUNICODE string
17Last Modified Timestamp 2FILETIME
100Program IDUNICODE string
101SHA1 hash of fileUNICODE string

I've written an encase Enscript to parse out this information to the console. Download v6 enscript here or v7 enscript here. This is code, not an enpack, so anyone can easily translate to python or perl or another open platform.
It outputs Amcache information as shown below:

File Reference = 03f180
Volume GUID = {8e49b4d2-4d4a-11e3-9717-000c29775430}
First Run Timestamp (Last Modified on key) = 11/15/13 19:48:19
Modified Time 2 = 11/03/13 17:42:39
File path = E:\Fetch.exe
Language Code = 0
PE Header Hash = 01012bb2314b06e59d290d4effbab22e77d7f87ecbeb
File Size = 58880
PE Header SizeOfImage = 77824
PE Header CheckSum = 0x00014D67
PE Header Linker Timestamp = 0x4E8B796E = 10/05/11 02:53:58
Modified Time = 11/03/13 17:42:40
Created  Time = 10/04/11 23:23:58
SHA1 hash = 000005b6d3ebc6a5484a270f4f0e04738d1e5a53ee25

The Unexplained

There are two Last Modified timestamps (11 and 17). I have noticed that the timestamp in 17 is almost always 1 second behind the timestamp for 11. This is a bit of a mystery, it is probably due to conversion to a DOS timestamp and back.

The SHA1 hash is a vital bit of information that MS has added, as now we can track malware even if its deleted/wiped itself from the system. Also, since the hive stores data about volume guids and file references, it can also be added to the list of location to review to aid in tracking of USB devices. 

Friday, 22 November 2013

Event Log entries for Devices in Windows 8

This post is about entries created when devices (USB or other) are connected to a Windows 8 system. This post does not talk about Windows Event log basics, its format or parsers or where you can find them on a system. I assume you are here because you already know about that and simply want to know about USB artifacts in event logs on Windows 8.

Windows 8 has added many new Logs and Sources to its core Event Logging system. Entries for device connections (insertions) are seen in at least 5 logs:


Source Event IDs When it Occurs?
Ntfs 98, ?? Every time a storage device containing an NTFS volume is connected
DriverFrameworks-UserMode 10000 Device first connect only
UserPnp 20001, 20003 Device first connect only

Description snippets:
Ntfs (Event 98) - Volume E: (\Device\HarddiskVolume4) is healthy. No action is needed.

DriverFrameworks-UserMode (Event 10000) - A driver package which uses user-mode driver framework version 2.0.0 is being installed on device SWD\WPDBUSENUM\_??_USBSTOR#DISK&VEN_KINGSTON&PROD_DATATRAVELER_G3&REV_PMAP#000FEAFB7959BC7067D40086&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}.

UserPnp (Event 20001) - Driver Management concluded the process to install driver wpdfs.inf_x86_d67a8256c1147128\wpdfs.inf for Device Instance ID SWD\WPDBUSENUM\_??_USBSTOR#DISK&VEN_KINGSTON&PROD_DATATRAVELER_G3&REV_PMAP#000FEAFB7959BC7067D40086&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B} with the following status: 0x0

2. Microsoft-Windows-DeviceSetupManager/Admin

Source Event IDs When it Occurs?
DeviceSetupManager 112 Device first connect only or when connected to a different port

Description snippet:
DeviceSetupManager (Event 112) - Device 'HASP HL 3.25' ({95abe994-529a-11e3-971d-806e6f6e6963}) has been serviced, processed 5 tasks, wrote 42 properties, active worktime was 136063 milliseconds.

3. Microsoft-Windows-DeviceSetupManager/Operational

SourceEvent IDsWhen it Occurs?
DeviceSetupManager300, 301Device first connect only or when connected to a different port

Description snippet:
DeviceSetupManager (Event 300) - The device container '{D7FD8C4F-2F70-A826-D5FA-20A112B90D4E}' has entered the ready state

4. Microsoft-Windows-Kernel-PnP/Device Configuration

SourceEvent IDsWhen it Occurs?
Kernel-PnP400, 410, 420Device first connect only

Description snippet:
Kernel-PnP (Event 400)Device USBSTOR\Disk&Ven_Kingston&Prod_DataTraveler_G3&Rev_PMAP\000FEAFB7959BC7067D40086&0 was configured.

5. Microsoft-Windows-Kernel-PnPConfig/Configuration

SourceEvent IDsWhen it Occurs?
Kernel-PnP1, 2, 3, 4Device first connect only or when connected to a different port

6. Security

SourceEvent IDsWhen it Occurs?
Microsoft-Windows-Security-Auditing4663Each time device is connected to system

Comment: Chad Tilbury alerted me to this one. Chad notes that this entry is only seen if “Audit Removable Storage” auditing is configured within the Object Access category of the Advanced Audit Policy Configuration.

The comments on occurrence are based on my limited experimentation/research with a Windows 8.1 system over the last few days. Please let me if you are seeing any other activity or behavior or log entries.

Wednesday, 20 November 2013

Windows 8 New Registry Artifacts Part 1 - New Device Timestamps

Tracking USB device insertion times has never been an easy task given that there is no direct timestamp saved by windows for this activity, ie, until Windows 8 arrived! This was a real pain in Windows Vista and 7 as dates and times were obtained from many different Registry keys’ Last Modified timestamps. And while this was reasonably reliable, timestamps thus retrieved always had to be taken with a pinch of salt!

All that changes with Windows 8. After a bit of experimentation, I have found that Windows 8 has added 3 new timestamps to the registry for Device Last Insertion Date, Device Last Removal Date and Firmware Date. This is located alongside other device properties in the SYSTEM hive under CurrentControlSet\Enum\DeviceType\DeviceID\InstanceID\{GUID}\Properties\xxxx 

Example: \CurrentControlSet\Enum\USBSTOR\Disk&Ven_Kingston&Prod_DataTraveler_G3&Rev_PMAP\000FEAFB9197BC7067D500C8&0\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0066\(Default)

The picture below will make things clear.

All timestamps are in the standard windows 64 bit (FILETIME) format.

Windows 7 already had these three timestamps:

Name Property Path
Driver Assembly Date {a8b865dd-2e3d-4094-ad97-e593a70c75d6}\0002
Install Date {83da6326-97a6-4088-9453-a1923f573b29}\0064
First Install Date {83da6326-97a6-4088-9453-a1923f573b29}\0065

Edit for clarification: The property paths shown above are for Windows 8. In Windows 7, this would be under
"{GUID}\00xx\00000000\Data" instead of "{GUID}\00xx"

Comment- I have always seen Install Date and First Install Date to contain the same exact timestamp. My guess would be that it would only differ when a driver is re-installed or updated. Update- Harlan Carvey has discussed this issue and the above timestamps here.

Windows 8 adds 3 new timestamps:

Name Property Path
Last Arrival Date {83da6326-97a6-4088-9453-a1923f573b29}\0066
Last Removal Date {83da6326-97a6-4088-9453-a1923f573b29}\0067
Firmware Date {540b947e-8b40-45bc-a8a2-6a0b894cbda2}\0011

After some research, I was able to verify these details by looking into the Windows SDK.  These properties have been defined in the include file ‘devpkey.h’. The last timestamp 'Firmware Date' has only been introduced in Windows 8.1 and I have not yet seen it in the registry. The term 'Last Arrival' is the one used by Microsoft, I will prefer calling it 'Last Insertion'.

With this new information, we will have accurate timestamps and not need to jump through hoops for determining Last Insertion (arrival) and Last Removal times. There are a few other changes in the windows 8 registry which will be in subsequent parts of this series of posts on Win 8 Registry.

That’s not all that changes when devices are inserted into a windows 8 machine. In the next article I will walk through all the windows event log changes. In case you are wondering, yes, there are plenty of events in the event logs for device setups/insertions/removals.

Monday, 21 October 2013

Windows Prefetch (.PF) files

Thanks to Wayback machine (web.archive.org), I have been able to retrieve my old posts about Prefetch files from 42 LLC. You can find the original (slightly edited) post here now. It contains format information and the prefetch hash algorithm.

Windows 8 Prefetch files

Of late there has been some discussion about windows 8 prefetch files on forensicfocus.com and some mailing lists. Everybody seems to know about the change from recording a single Last Executed Time to the last 8 executed times. There is some confusion about the hashing algorithm. So I've revisited this artifact and here is what I found (for windows 8).

Windows 8 still uses the same prefetch hash calculation algorithm. A few offsets have changed but the structure of the pf file is still the same. The only change seems to be the addition of 7 new timestamps. This is because now the prefetch file stores the timestamp of the last 8 times the application was executed. My old enscript code has been updated to reflect this. Download here.

There is some extra data in the volume information block that still remains a mystery. Refer old post for the volume information block structure.

The new windows 8 prefetch file structure is as follows:
0x00 = 1A 00 00 00
0x04 = SCCA
0x08 = 11 00 00 00 
0x0C = 4 byte size of pf file itself
0x10 = 60 bytes of filename
0x4C = 4 bytes hash (same as in filename)
0x50-0x57 = unknown
0x58 = Number of Filepaths referenced
0x5C-0x63 = unknown
0x64 = Offset to Block containing Filepaths (DWORD)
0x68 = Length of Block containing Filepaths (DWORD)
0x6C = Offset to Volume Information Blocks (DWORD)
0x70 = Number of Volume Information Blocks present (DWORD)
0x74 = Size of all volume info blocks (DWORD)
0x78 = unknown
0x7C = unknown
0x80 = Program Last Execution Time (1) (FILETIME)
0x88 = Program Last Execution Time (2) (FILETIME)
0x90 = Program Last Execution Time (3) (FILETIME)
0x98 = Program Last Execution Time (4) (FILETIME)
0xA0 = Program Last Execution Time (5) (FILETIME)
0xA8 = Program Last Execution Time (6) (FILETIME)
0xB0 = Program Last Execution Time (7) (FILETIME)
0xB8 = Program Last Execution Time (8) (FILETIME)
0xC0-0xCF = unknown
0xD0 – Number of Executions (DWORD)

Thursday, 3 October 2013

Mounting Encase Images the easy way in Ubuntu13

This post continues from the earlier one (mounting DD images in Ubuntu13 with one click). Now we want to do the same for E01 images. We will use the mount_ewf python script from the libewf project to accomplish this. Follow the instructions given below:

1. Download and install libewf from Ubuntu Software Center.
2. Download mount_ewf-20090113.py from here.
Rename to mount_ewf.py and copy it to /usr/bin folder. Set 755 permissions on it so it can be read and executed by all users.

This python script requires a mount point location (folder) to be specified. For every image we want to mount, we will need to create a new mount point and then feed it to this script. We will create temporary mount points under /tmp. Each mount point will be named ewf_NAME.

To make this mount on 1 click and mimic the default image mount function, 3 things need to be done:
1. Create a mount point.
2. Run mount_ewf.py script to mount the image.
3. Mounted image folder should pop up in Files Explorer.

To automate this to 1 click, launch 'Nautilus-Actions Configuration Tool' and create a new item. Lets call it 'Mount E01 to DD'. In the 'Command' tab fill in the following details:

Path: /bin/sh
Parameters: -c "mkdir /tmp/ewf_%b";gksudo "mount_ewf.py -o allow_other %f /tmp/ewf_%b";nautilus /tmp/ewf_%b
Working directory: %d

(note: there are no line breaks in parameters, it is all in one line) Don't change anything in the parameters, especially the quotes. I've settled on this command line after many iterations of failed attempts. This one takes care of all spaces in file names (and file paths) and should be fine for everyone.

In the 'Basenames' tab, create 2 filters for filename as '*.E01' and '*.e01' so that the menu item only shows up for files with an E01 extension.

One more setting is required to make this work. In the 'Execution' tab, select 'Display Output' under Execution mode. This won't work otherwise.

Thats about it. You should now see a menu like the one shown below when you right click on an e01 file. Choose 'Mount E01 to DD' to mount it to a virtual DD image. The folder should popup upon operation completion. Now right-click on the DD image file and select 'Mount DD image' to mount the partitions.

Now for the unmount command. I've created a simple generic 'Unmount all' command that unmounts all E01 files that were previously mounted (using our one-click solution). Since we do not maintain any record or database of mounted files, we simply reply on file names to identify mounted folders under /tmp.

In 'Nautilus-Actions Configuration Tool' create a new item called 'Unmount ALL E01s'. Under 'Action' tab, check the 'Display item in location context menu' checkbox. This enables the option to show up even when there is no file selected and you right-click. In the 'Command' tab, fill in the following details:

Path: gksudo
Parameters: umount /tmp/ewf_*; rmdir /tmp/ewf_*
Working directory: %d

In the 'Execution' tab, select 'Display Output' under Execution mode.

Thats it! Do remember to unmount your virtual DD images in File Explorer before trying to unmount the E01.

Here is a video showing the entire concept implemented on my machine.

Sunday, 22 September 2013

udisks & mounting DD images in Ubuntu-13 with One Click

To mount a partition from a dd image earlier, you had to first run 'mmls' or 'fdisk -l' to determine the starting offset of the partition, then run the 'mount' command specifying the correct partition type, offset and mount point. But I've always wanted an easier way to do this, preferably a one click or single command that automatically figures out this info and mounts all partitions just as the system auto-mounts an inserted USB disk.

'udisks' is the utility ubuntu uses to determine disk geometry, partitions, offsets and auto-mount them when you insert a new disk (removable or fixed) into your system. udisks can do the same job when a DD image is supplied via the loopback option. The loopback functionality existed even before but it would not work with DD images in older versions.

So whats the command to do this?
udisksctl loop-setup -r -f MyImage.DD
The -r option makes it a read-only mount. No root privilege is required, and all partitions are auto-mounted (under /media/<user>/..) and appear in Files explorer.

Now for the automation part, how do we do this via a right-click menu on Nautilus?
This is easily accomplished with the 'Nautilus-Actions Configuration Tool'. This can be installed via the 'Ubuntu Software Center'. Launch it and create a new 'action' entry in the items list on the left.

Go to the command tab. For Path, type 'udisksctl'. For Paremeters, 'loop-setup -r -f %f' See screenshot below.

You can optionally define a Basename filter (under Basenames tab) so that the particular option only shown up on filenames that have the extension DD. However do note that many dd images do not have the DD extension.

Now, most evidence we use is not a DD image but an Encase E01 file. This would be really great if we could also automate mounting of partitions from Encase E01 files. In the next blog entry, we will see how you can do exactly that.

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