Thursday, September 5, 2013

Determining Windows Volume Letters on GUID Partition Table (GPT) partitioned Devices

When reporting data to a customer, whether that be a corporate customer, a law enforcement officer, or an attorney, I try to keep my geekiness in check.  One way of doing so is by reporting the location of data in a way that the customer is familiar.  I figure that if my children and my parents understand how to get to a file if I provide a full path, anyone can do it.

One popular forensic tool arbitrarily names partitions in the order they are encountered on a device, beginning with the Volume Letter C.  Sometimes it is right; sometimes it is wrong.  Determining these drive letters has been the same throughout my career -- Review the keys beginning with DosDevices under the \MountedDevices key within the SYSTEM Registry file and take the first four (4) bytes of the value as the disk signature and the last eight (8) as the bytes to the beginning of the partition.

Several Microsoft Windows operating systems are now able to boot to disks which have been partitioned using the GUID Partition Table (GPT) scheme.  According to Microsoft's DevCenter article: Using GPT Drives, the x64-based operating systems Windows Server 2003 SP1, Server 2008, Windows Vista, and Windows 8 can boot to devices which use GPT while older operating systems such as x64-based Windows XP and x32-based Windows Server 203 SP1 could use GPT devices for storage.

With more operating systems supporting GPT, the laboratory naturally is starting to see more pieces of evidence partitioned in this way.  A colleague recently received a Windows 8 based system for analysis, went to verify drive letter assignments and was surprised to see Figure 1.

Figure 1. \MountedDevices\DosDevices\C: within the SYSTEM Registry File

A quick review of Sector 1 of the device located the header for the Unified Extensible Firmware Interface (UEFI) boot firmware, 0x 45 46 49 20 50 41 52 54, or EFI PART in ASCII.  This is expected since a Windows system can not boot from a GPT partitioned device without the UEFI.  The EFI header can be seen in Figure 2.

Figure 2. UEFI Header: Sector 1, Offset 0, Length 8 bytes


The specification related to UEFI and GPT can be obtained from the Unified EFI Forum.  Of particular interest is the fact that the Disk Signature in the Protected Master Boot Record (MBR) located at Sector 0 at offset 440 for four (4) bytes is still generated by the operating system and that the entire disk also gets a GUID which is available in Sector 1 at offset 56 for 16 bytes.  While neither disk identifier was used during the current examination, their presence likely has some value that I will explore at another time (Feel free to add your experience with these identifiers in the comments!).  I unfortunately did not get a screen shot showing the MBR and the Disk Signature it contained.  The EFI header is shown again in Figure 3, this time with several bytes highlighted with different color boxes.

Figure 3. UEFI Header Identifying Disk GUID and General Information Relate to Partition Entries

The GREEN text, 16 bytes starting at offset 56 of Sector 1, contains the disk GUID: 0x14 4E CA B9 C1 7F 0F 43 A5 61 3D FF FD F2 B6 26.

The RED text, eight (8) bytes starting at offset 72 of Sector 1, contains the starting Logical Block Address (LBA) of the array containing the partition entries: 2 (Little Endian).

The ORANGE text, four (4) bytes starting at offset 80 of Sector 1, contains the number of partition entries within the array: 128 (Little Endian).

The YELLOW text, four (4) bytes starting at offset 84 of Sector 1, contains the number of bytes that make up a partition entry within the array: 128 bytes (Little Endian).

A little math can show us how many sectors the partition entries take up:

        ((number of entries) * (bytes per entry)) / (bytes per sector), 128*128/512 = 32.  

Therefore, the partition entries take up Sectors 2 through 33.  So, remember that 16 byte GUID associated with our volume?  If all goes well, we should see it within these 32 sectors.  Now before getting flustered over the 16 byte GUID being somewhere within 32 sectors, I do not anticipate seeing GPT devices which use all 128 entries any time soon.  Note that unused entries will contain 0x00.  Figure 4 shows the last used entries of the partition array as note by the 0x00 at the bottom of the data.  It also shows, highlighted in blue, the GUID noted as being associated with the C volume in our example.

Figure 4. Excerpt of Partition Array

The eight (8) bytes, boxed in GREEN, which immediately follow the 16 byte GUID of interest shown in Figure 4 provide the starting sector of the partition.  Converting the data into Little Endian decimal indicates that the volume using drive letter C starts at sector 1615872.

A quick review of the starting sectors of the partitions identified the 3rd partition, shown in Figure 5, as being the one mounted with drive letter C.

Figure 5. Excerpt of Forensic Tool Report Listing Starting Sector of Volume 3

Granted there was enough data that I could make an educated guess that this was the C volume, but again I try to rein in that inner geek when talking to the customers.  So rather than geeking out over why I believe this to be the C volume, I can definitively state, this IS the C volume.

As time permits, and assuming I do not get sidetracked, I plan to script the process to automatically make these correlations.  I would also like to further explore the use of the Disk Signature and the Disk GUID.

Sunday, May 6, 2012

Timestamps on the Mac


I find that temporal analysis is very important to my examinations.  By studying the timestamps related to an event we could gain insight into the investigation, whether that is who was responsible for the activity or, in some cases, what that activity even was.  Due to the importance of this type of analysis, it is helpful to understand how system behavior and user activity affects the timestamps we encounter.

This post was inspired by recent events at work in which time stamps, MAC times in particular, have become the topic of conversation.  A colleague posed the question, “What actions will trip the Last Accessed (A) date stamp on a Mac?”  In particular, she wanted to know about pressing the space bar to view a file (QuickLook).  The conversation resulted in another colleague indicating he had seen timestamps during a recent examination of a Mac that did not fit the behavior we all are accustomed to seeing during analysis of Windows based systems.  It seems that the topic of timestamps has popped up in the community recently with a nice tutorial on creating a timeline available on the Sploited blog (Part One and Two) and Harlan Carvey posting comments about recent activity from the Win4n6 Yahoo Group on his blog Windows IR.  With that, I decided to chart out the effects common activities would have on these timestamps.

I created three blank Microsoft Word documents and saved them.  The first document was left alone, the second was opened and then closed (no modifications and no saving), and the last was opened, edited, and saved.  To get a base line, I clicked File --> Get Info and was able to see the creation (b), last written (M), and accessed (A) timestamps.  As can be seen in Figure 1, there is nothing unusual here.

Figure 1.  Output from Get Info – baseline

Using these three files, I began taking actions that I expect the average user might perform.  In addition, I tried to think of alternative ways of accomplishing the same action, such as using the Terminal instead of Finder to copy and move files.  At this point I should mention that the file system involved here is HFS+ and I only performed these actions on a single volume.

File Behavior
Process
Method
Created (b)
Last Written (M)
Last Accessed (A)
COPY
Copy/paste (Finder)  also Option + Drag/Drop (Finder)
Orig
Maintained
Maintained
Maintained
Copy/paste (Finder)
also Option + Drag/Drop (Finder)
Copy
Maintained
Maintained
Maintained*
cp (Terminal) orig
Maintained
Maintained
Maintained
cp (Terminal) copy
Changed
Changed
Changed
MOVE
Drag/Drop
Maintained
Maintained
Maintained
mv (Terminal)
Maintained
Maintained
Maintained
Get Info

Maintained
Maintained
Maintained
Open
Double Click (Finder)
Maintained
Maintained
Changed
Starting App and opening file
Maintained
Maintained
Changed**
open (Terminal)
Maintained
Maintained
Changed
Open - Edited
Double Click (Finder), Edit, Saved
Maintained
Changed
Changed
List Directory Contents
Finder
Maintained
Maintained
Maintained
ls (Terminal)
Maintained
Maintained
Maintained
Preview
QuickLook
Maintained
Maintained
Maintained
AV Scan
Clam AV
Maintained
Maintained
Maintained
*If the file was accessed but not saved, the Last Access (A) time of the copy was reset to match the other time stamps upon copying.
** Opening a JPG with GIMP did not trip the last accessed date.
Table 1. File Behavior

The table shows several interesting items.

  • A copy of the original file, performed within Finder, maintained the creation timestamp (b) (created (b), last written (M), and accessed (A) timestamps actually – except as described later).  This is different than the behavior most of us have seen in the Windows environment where we would have seen a new creation (b) timestamp, a last accessed (A) time stamp that matched the new creation (b) timestamp, and the same last written (M) time as the original file.
  • The Last Accessed (A) timestamp on the copied file was reset to the last written (M) timestamp of the original. 
  • Not every application will update the Last Accessed (A) timestamp of the file when the application is opened first and then directed to open the file.  This was noted using GIMP to open a JPG file.

It is obvious that the rules related to timestamps and how they are updated are not the same as used on Windows based systems.  Putting together a timeline using this information based on the rules we know from Windows could prove difficult if not just downright inaccurate.  This serves as yet another reminder that as a Forensic examiner, we must be aware of what the data w are presenting means and how to properly interpret it.

Although Table 1 did provide good information and helped show that what we were seeing during an examination was normal system behavior, it is only part of the information.

I mentioned that a colleague was particularly interested in the QuickLook feature on the Mac and its effect on the timestamps.  From Table 1 it can be seen that it had no effect on time stamps.  Does this mean that file access couldn’t be proven at all if the QuickLook was used?  Thinking about my own habits, I use the QuickLook feature almost exclusively to review files, unless I plan to edit the content.  Does this mean there is no record of these files being accessed?

In order to look into this further, I decided to utilize the stat command from within the Terminal and repeat the above actions.  The results are shown in Table 2.

inode Behavior
Process
Method
Created 
(b)
Last Written (M)
Last Accessed (A)
Entry Modified(C)
COPY
Copy/paste (Finder)  also Option + Drag/Drop (Finder)
Orig
Maintained
Maintained
Changed
Maintained
Copy/paste (Finder)
also Option + Drag/Drop (Finder)
Copy
Maintained
Maintained
Changed
Changed
cp (Terminal) Orig
Maintained
Maintained
Changed
Maintained
cp (Terminal) Copy
Changed
Changed
Changed
Changed
MOVE
Drag/Drop
Maintained
Maintained
Changed
Maintained
mv (Terminal)
Maintained
Maintained
Changed
Maintained
Get Info

Maintained
Maintained
Changed
Maintained
Open
Double Click (Finder)
Maintained
Maintained
Changed
Maintained
Starting App and opening File
Maintained
Maintained
Changed
Maintained
open (Terminal)
Maintained
Maintained
Changed
Maintained
Open - Edited
Double Click (Finder), Edit, Saved
Maintained
Changed
Changed
Changed
List Directory Contents
Finder
Maintained
Maintained
Maintained *
Maintained
ls (Terminal)
Maintained
Maintained
Maintained
Maintained
Preview
QuickLook
Maintained
Maintained
Changed**
Maintained
AV Scan
Clam AV
Maintained
Maintained
Changed
Maintained
* Depending on the view in Finder, the last accessed (A) time may trip.  For example, in Column format, clicking a file. Changing Finder views also triggers Last Accessed.
** Last Accessed (A) did not trip when action performed on a text file.
Table 2. inode Behavior

It can be seen that the last accessed (A) timestamp reported by the stat command was changed with almost every action.  Unfortunately this is not concrete enough to help my colleague indicate a file was accessed using the QuickLook feature; however, it may help to establish that a user had knowledge that the file was present on the system.

While the data presented here is a start, as I previously indicated, I like tables and charts.  As time permits, I intend to redo this experiment but performing the actions across different volumes formatted with popular file systems.

************************************************************************************************************
UPDATE
May 8, 2012

A colleague introduced me to the -x switch for the stat command.  This switch made the output a bit more manageable by labeling the time stamps.  The Created (b) timestamp is not given with this switch.  Running this test again resulted in identifying an instance of the Last Written (M) time being switched with the Entry Modified (C) time.

Inconsistencies in the way the MACb times were referenced were corrected.

Further discussion with colleagues resulted in identifying the inode behavior was dependent on the file type.  Text files, for example, did not update the last accessed (A) information of the inode when opened via QuickLook.  Pictures and documents did.