Thursday, December 31, 2009

Time Stamp Format

Figure 25 Extended FAT File System (exFAT) Timestamp Format

Time Stamp Format


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).

The DOS date/time format is a bitmask:

               24                16                 8                 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Y|Y|Y|Y|Y|Y|Y|M| |M|M|M|D|D|D|D|D| |h|h|h|h|h|m|m|m| |m|m|m|s|s|s|s|s|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
 \___________/\________/\_________/ \________/\____________/\_________/
    year        month       day      hour       minute        second

The year is stored as an offset from 1980. Seconds are stored in two-second increments. (So if the "second" value is 15, it actually represents 30 seconds.)

Source: http://blogs.msdn.com/oldnewthing/archive/2003/09/05/54806.aspx

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.

The VBR

Volume Boot Record (VBR)

Field Name

Offset (byte)

Size (byte)

Description/Value

Jump Boot

0

3

0xEB7690

File System Name

3

8

“EXFAT

Must Be Zero

11

53

Must be 0x00

Partition Offset

64

8

Sector Address

Volume Length

72

8

Size of total volume in sectors

FAT Offset

80

4

Sector address of 1st FAT

FAT Length

84

4

Size of FAT in Sectors

Cluster Heap offset

88

4

Sector address of the Data Region

Cluster Count

92

4

Number of clusters in the Cluster Heap

Root Directory First Cluster

96

4

Cluster address of the Root Directory

Volume Serial Number

100

4

Volume Serial Number

File System Revision

104

2

VV.MM (01.00 for this release)

Volume Flags

106

2

Field

Offset bits

Size bits

Description

Active FAT

0

1

0 – 1st

1 – 2nd

Volume Dirty

1

1

0 – Clean

1 - Dirty

Media Failure

2

1

0 – No Failures

1 – Failures Reported

Clear to Zero

3

1

No Meaning

Reserved

4

12

Bytes Per Sector

108

1

This is a power of 2. Range: min of 29 = 512 byte cluster size, and a max of 212 = 4096.

Sectors Per Cluster

109

1

This is a power of 2. Range: Min of 21=512. The maximum Cluster size is 32 MiB, so the Values in Bytes per Sector + Sectors Per Cluster cannot exceed 25.

Number of FATS

110

1

This number is either 1 or 2, and is only 2 if TexFAT is in use.

Drive Select

111

1

Used by INT 13

Percent In Use

112

1

Percentage of Heap in use

Reserved

113

7

Boot Code

120

390

The Boot Program

Boot Signature

510

2

0xAA55

Excess

512

If the sector is larger than 512 bytes, extra padding may exist beyond the signature

Comments: Volume size is minimum of 1MB and maximum size is 264-1 sectors

Table 3 Layout for Main and Backup Boot Sector Structure

The Volume Boot Record (VBR), as shown in Table 3, is the first critical file system collection of metadata needed by the forensics examiner. This collection of sectors defines the limits and locations of the exFAT regions, and has a pointer to the Root Directory.

The Main Boot Region of the VBR is composed of five sub-regions of a total of 12 sectors:

  • The Main Boot Sector (MBS)
  • The Main Extended Boot Sectors (MEBS)
  • The OEM Parameters
  • A reserved sector
  • The Checksum Sector

The Backup Boot Region is a repeat of the 12 sectors found in the Main Boot Region, and together, both regions total 24 sectors. Since the concept of the term cluster only applies to the contents of the Cluster Heap, the VBR will always be expressed as sectors.

The MBS does not differ conceptually from the partition Master Boot Sectors or Volume Boot Records of previous FAT file systems. It contains Boot Code, the BIOS Parameters Block (BPB), and a signature. The purpose of the BPB is to describe the physical layout of the file system volume. The common signature (as shown in Figure 14) used in this sector is 0xAA55.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............Uª

Figure 14 Winhex Display of VBR Signature

The Boot Code is located in the first 3 bytes of the MBS and also consumes 390 bytes at offset 120. The first 3 bytes is a Jump Boot sequence which bypasses the BPB and jumps to the Boot Code. Since any executable sequence of computer instruction may be stored in the boot code, this may be of interest to the forensics examiner should customized boot code be stored. It would be in this area of the sector that a Boot Sector Virus would modify and implant itself.

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 EB 76 90 45 58 46 41 54 20 20 20 00 00 00 00 00 ëvEXFAT .....

16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

64 3F 00 00 00 00 00 00 00 C1 F3 01 00 00 00 00 00 ?.......Áó......

80 80 00 00 00 80 00 00 00 00 01 00 00 58 3E 00 00 €...€.......X>..

96 05 00 00 00 EC 99 D1 C4 00 01 00 00 09 03 01 80 ....ì™ÑÄ.......€

112 5C 00 00 00 00 00 00 00 \.......

Figure 15 Winhex of the first 120 bytes of a MBS

The File System Name, also referred to as the OEM label, is an 8 byte ASCII field containing the name of the file system. This makes identification of the file system easier, and as shown in Figure 15 the name is “EXFAT” and is padded with training blanks. If this file system is created on a fixed hard drive in a partition, you cannot rely on the partition type within the MBR to determine the file system type because the partition code for exFAT is 0x07 and is shared with other file systems (see Table 20). The next field, Must Be Zero, defines 53 bytes of 0x00 in a location that the older FAT file systems used to define their BPB. This reduces the risk of the legacy FAT implementations of accidently mounting an exFAT volume by mistake.

The Volume Length is a count of the total number of sectors on the volume. This number needs to be larger than a 32 bit number, so it is defined as 264. Suppose for example the maximum sized Cluster Heap was defined, which is currently limited to 232-11 clusters. If the cluster ratio is set to 1 sector per cluster (1:1), then a 32 bit number is required to hold the volume length. If the sector to cluster ratio was 1:16, then a 36 bit number would be required. If the current maximum as per the specification were used, and assuming a sector size of 512 bytes, an additional 16 bits need to be added, requiring a 48 bit number. This is based on a 25 bit maximum (32MiB cluster size) and 9 of those bits are used to define 512 bytes for the sector size.

Four fields are used to describe the FAT. The FAT offset is used to define the sector offset of the FAT region and points to the 1st FAT. If the number of FATS is 2, then the 2nd FAT will immediately follow the 1st FAT, starting on a sector boundary. The number of FATS will always be 1 because TexFAT is not implemented and the 2nd FAT only exists in a TexFAT environment. If the implementation does not verify this value, then the file system could be modified to increase this number and imbed fake FATS in the volume in order to create additional slack space to hide data. The FAT length is the length of the FAT in sectors. In the Volume Flags there is a flag for the Active FAT. This only applies in a TexFAT environment, when number of FATS is equal to 2. This flag indicates which of the two FATS is active.

Figure 16 Chkdsk of an exFAT formatted disk

The final region, the Cluster Heap, is the data portion of the volume structure and holds the directories and files. The Cluster Heap is allocated in cluster units and the Cluster Count defines how many allocation units are defined. The Cluster Offset identifies the sector address of where the Cluster Heap begins. Once inside the Cluster Heap, the addressing units are in clusters. In Figure 16 the Cluster Count is shown as total allocation units on disk, and in this example shows 15,960.

In comparison, a FAT32 file system requires a minimum of 65,526 clusters making FAT32 unusable for small disks formats. exFAT does not have that restriction and smaller media may be used. In testing, a 32MB compact flash card was formatted as an exFAT file system.

A key value in this sector for the forensics examiner is the Root Directory First Cluster. The details of the Root Directory are described in section 6.1, and this value points to the first cluster of the Root Directory which resides in the Cluster Heap. The VBR defines the structure of the volume, but the Root Directory defines the contents within the Cluster Heap. All the metadata about files, subdirectories, the volume label, etc reside in this directory.

Two critical fields are the bytes per sector and sectors per cluster. One thing that is special about these fields is that the values contained are exponents. For example Figure 15 shows that the bytes per sector are 9 and the sectors per cluster are 8. This is 29 bytes per sector (512) and 23 sectors per cluster (8) resulting in a cluster size of 4096 bytes. The maximum aggregate sum of these two exponents is 25, for a maximum cluster size of 32MiB. The maximum value for the bytes per sector field is 12 (212 = 4096 bytes).

At offset location 104 is the file system revision number, which appears in Figure 15 and is 0x0100 and translates to version 01.00.

The boot signature of the MBS is always at offset location 510. If the sector size is defined as greater than 512 bytes, the signature will still be located at this location, and the remainder of the sector will be undefined and not used.

Field Name

Offset (byte)

Size (byte)

Description/Value

Extended Boot Code

0

508-4092

Additional Boot Code

Extended Boot Signature

508-4092

4

0xAA550000

Comments: Signature actually stored as 0x000055AA

Table 4 Layout for Extended Boot Sector Structure

The Main Extended Boot Region takes up the next 8 sectors, even when not used. This allows a larger boot program by providing additional sectors for boot code. Unlike the MBS, the MEBS, when extended to larger than 512 bytes, allows usage of the entire sector for boot code and the record signature is moved to the last four bytes. If a sector size of 4096 bytes was used, the boot signature would be at offset 4092. If a MEBS sector is not in use, the boot code should all be 0x00, followed by the boot signature.

Field Name

Offset (byte)

Size (byte)

Description/Value

Parameters[0]

0

48

Parameters

Parameters[1]

48

48

Parameters

Parameters[2]

96

48

Parameters

Parameters[3]

244

48

Parameters

Parameters[4]

192

48

Parameters

Parameters[5]

240

48

Parameters

Parameters[6]

288

48

Parameters

Parameters[7]

336

48

Parameters

Parameters[8]

384

48

Parameters

Parameters[9]

432

48

Parameters

Reserved

480

32-3616

Rest of sector Reserved

Table 5 Layout for OEM Parameter Structure

The next sector in the VBR (sector 9) is the OEM parameters record. Since this record really doesn’t exist yet (it is all zeros in the file systems that were generated), there is little analysis that can be done at this time. The patent specifies this table as 10 fields of 48 bytes, the first 16 bytes of each field is the GUID and the remaining 32 bytes are the parameters, but no additional definition is provided.

The entries are not sorted, and it is possible that the first 9 are empty and the last has data, so the specification states that all 10 entries should be searched. This sector is filled out by the media manufacturer at the factory and a format operation is not supposed to erase this sector with the exception of a secure wipe of the media.

Examination of Microsoft MSDN AA914663 provides a definition of the 32 byte parameter field, as shown in Figure 17:

struct

{

GUID OemParameterType; //Value is OEM_FLASH_PARAMETER_GUID

UINT32 EraseBlockSize; //Erase block size in bytes

UINT32 PageSize;

UINT32 NumberOfSpareBlocks;

UINT32 tRandomAccess; //Random Access Time in nanoseconds

UINT32 tProgram; //Program time in nanoseconds

UINT32 tReadCycle; // Serial read cycle time in nanoseconds

UINT32 tWriteCycle; // Write Cycle time in nanoseconds

UCHAR Reserved[4];

}

FlashParameters;

Figure 17 OEM Parameters Type Definition

Sector 10 is reserved, and is not currently defined. Sector 11 is a checksum sector, where every 4 byte integer is a 32 bit repeating checksum value of the previous 11 sectors. If anyone wanted to tamper with the VBR by changing values in the BPB or the boot code, like a boot sector virus infecting the VBR, then the checksum would have to be recalculated and sector 11 would need to be updated. The last 3 sectors of this 12 sector VBR (sectors 9, 10 and 11) do not contain signatures, the signatures are only used for sectors containing boot code and are in the first 9 sectors.

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

5632 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 }.N)}.N)}.N)}.N)

5648 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 }.N)}.N)}.N)}.N)

Figure 18 Winhex dump of part of a VBR checksum sector

Figure 18 shows a partial dump of the checksum sector, the checksum is 0x294E0A7D and repeats in every 4 bytes of the entire sector. For a sector size of 512 bytes, it would repeat 128 times. Figure 19 shows the Microsoft Visual C function that was used to compute and verify the checksum value.

UINT32 VBRChecksum(const unsigned char octets[], long NumberOfBytes)

{

UINT32 Checksum = 0;

long Index;

for (Index = 0; Index <>

{

if (Index == 106 || Index == 107 || Index == 112)

{

continue;

}

Checksum = ((Checksum <<31)>> 1)) + (UINT32) octets[Index];

}

return Checksum;

Figure 19 Code snippet of VBR checksum calculation function in C

For comparison, the FAT32 VBR is within a reserved 32 sector region, with a primary VBR of 3 sectors at sectors 0, 1 and 2 and then a backup VBR located at sectors 6, 7 and 8. (Mueller, Scott (2003)) In a FAT32 VBR, executable boot code can reside in the 1st and 3rd sectors, where an exFAT VBR can have 9 sectors containing executable code.