When an investigator or forensics analyst wants to develop a timeline of activity on a system, one of the most useful pieces of information is the file times. (Carvey, Harlan (2005)). This process is called a MAC time analysis. Understanding the 3 main timestamps and their behavior when used for file creation, access, and modification is important to achieve this goal. The analysis of these timestamps can provide valuable insight into the history of the file and the extent of the user’s knowledge of the files existence and contents (Casey, Eoghan (2002)). Section 6.8 will show where the timestamps are located and how to extract them. This section will explain the underlying format in order to help the forensics examiner understand how to convert the timestamp to a human readable date and time.
Carrier, Brian (2005) on page 263 gives a good breakdown of the file system timestamp format. Another example is provided in Figure 25. MSDN provides a mapping and calls this the DOS date/time format (Figure 26).
Figure 26 The DOS Date/Time format
The DOS date/time format has not changed in exFAT, and is the same as used in earlier FAT file systems. The exFAT file system provides support for UTC timestamps which has an advantage when data is collected from different time zones, and can be important when the forensics examiner has to correlate data and logs taken from several different systems that may have been located in different time zones. This analysis hasn’t established if there is a special single UTC timestamp format, but it was determined that the exFAT file system actually uses the aggregate of three different fields to make up what can be called the UTC timestamp. These fields are not stored together as one single set of fields for each type of date/time timestamp. This is different than the NTFS UTC timestamps that use a 64-bit number in 100 nanosecond intervals with an epoch of January 1, 1601 (UTC).
The first field is the DOS date/time value. This is actually 2 separate fields by itself since the date is in one 16 bit word and the time is in the other 16 bits. Since both of these components are stored together, this will be treated as one 32 bit (4 bytes) date/time stamp. Microsoft has also specified this as a 4 byte single field, and not as two separate fields.
The next field is a one byte field for 10ms units, and ranges from 0-199. This actually provides the “odd” seconds. Since in the DOS timestamp format the seconds are really “double seconds” the seconds will always be even. When the 10ms portion is then factored in, between 0-1990 ms, or between 0-1.99 seconds is being added. So when the contents of this field are 100 or more, the seconds will become odd when combined. This field only exists for the Create and Last Modified timestamps, and it appears that Windows XP maintains both these fields while Server 2008 only maintain the create 10ms field. This appears to be an inconsistency in the cross platform implementation, and requires more black box behavioral analysis to map the different scenarios.
The third field which appears for all three components (create, modify, access) is the time zone offset, and is one byte. These fields contain non-zero values when UTC support is present. Windows XP with exFAT support installed has UTC support, but Vista SP1 and Server 2008 SP1 did not. Examination of these fields will provide information on whether the operating system that created or updated the corresponding date/time timestamp field had UTC support, and will provide insight into the timestamp contents. Initial tests using Server 2008 SP1 did not produce these dates. After applying SP2 to the Server 2008 system the time zone offsets began to appear.
A search to find any documentation on the format of the time zone offsets did not produce any results. Trial and error was used by changing the clock settings on the Windows XP machine and then observing changes in these fields to see how they were affected. Table 23 was generated based on those observations and with some extrapolation provides a translation of these offsets. They appear to be in the range of 128-255 in 15 minute increments that appear to provide a range of ± 16 hours. A formula was developed (by Jeff Hamm) that shows the time zone offset to be a 7 bit signed integer. The purpose of the high order bit has not been determined.
The location of these fields also conflict with the layout as appearing in the specification released in the Patent. The create time zone offset overlays the field defined for last access 10ms, and the other two time zone offset values overlay 2 bytes of a reserved area. The File Directory Entry layout in Table 15 has been modified to reflect what was observed based on the implementations behavior and does not match the layout provided in the specification.
The DOS Timestamp will always be written with the local machine time. It could have been implemented in one of two ways, where the UTC time could have been entered into the DOS Timestamp, but Microsoft apparently didn’t go that route. So regardless of whether the host system has UTC support or not, the same date/time information is recorded, it is the local time. Then, with UTC support, the time zone offset is recorded for the corresponding timestamp.