Directory Entries

The FAT directory entry contains the name and metadata for a file or directory. One of these entries is allocated for every file and directory, and they are located in the clusters allocated to the file's parent directory. This data structure supports a name that has only 8 characters in the name and 3 characters in the extension. If the file has a more complex name, there will be a long file name directory entry in addition to a directory entry. The long file name version is discussed in the next section of this chapter. The basic directory entry structure has the fields given in Table 10.5.

The first byte of the data structure works as the allocation status, and if it is set to 0xe5 or 0x00, the directory entry is unallocated. Otherwise, the byte is used to store the first character of the file name. The name is typically in ASCII, but could also use one of the Microsoft code pages if the name uses non-ASCII symbols [Microsoft 2004]. If the file name has the value 0xe5 in that byte, 0x05 should be used instead. If the name does not have 8 characters in its name, unused bytes are typically filled in with the ASCII value for a space, which is 0x20.

The file size field is 4 bytes and, therefore, the maximum file size is 4GB. Directories will have a size of 0 and the FAT structure must be used to determine the number of clusters allocated to it. The attributes field can have one or more of the bits in Table 10.6 set.

The upper two bits of the attribute byte are reserved. Directory entries that have the long file name attribute set have a different structure because they are storing the long name for a file, and they will be described in the next section. Notice that the long file name attribute is a bit-wise combination of the first four attributes. Microsoft found that older OSes would ignore directory entries with all the bits set and would not complain about the different layout.

The date portion of each timestamp is a 16-bit value that has three parts, which are shown in Figure 10.2(A). The lower 5 bits are for the day of the month, and the valid values are 1 to 31. Bits 5 to 8 are for the month, and the valid values are 1 to 12. Bits 9 to 15 are for the year, and the value is added to 1980. The valid range is from 0 to 127, which gives a year range of 1980 to 2107. A conversion of the date April 1, 2005 to its hexadecimal format can be found in Figure 10.2(B).

Figure 10.2. Breakdown of the date value and the conversion of April 1, 2005 to its FAT date format.

The time value is also a 16-bit value and also has three parts. The lower 5 bits are for the second, and it uses two-second intervals. The valid range of this value is 0 to 29, which allows a second range of 0 to 58 in two-second intervals. The next 6 bits are for the minute and have a valid range of 0 to 59. The last 5 bits are for the hour and have a valid range of 0 to 23. This can be seen in Figure 10.3(A). An example of converting the time 10:31:44 a.m. to the FAT format can be found in Figure 10.3(B).

Figure 10.3. Breakdown of the time value and the conversion of 10:31:44 a.m. to its FAT time format.

Fortunately, there are many tools that will convert these values for you so that you do not have do always do it by hand.[1] Many hex editors will show the date if you highlight the value and have the correct options set. As we will see in the later chapters, this method of saving the time is much different from other file systems, which save the time as the number of seconds since a given time.

[1] An example is "Decode from Digital Detective" (https://www.digital-detective.co.uk).

Let's look at the raw contents of two directory entries from the root directory. The starting location of the root directory in a FAT32 file system is given in the boot sector.

# dcat f fat fat-4.dd 1632 | xxd 0000000: 4641 5420 4449 534b 2020 2008 0000 0000 FAT DISK ..... 0000016: 0000 0000 0000 874d 252b 0000 0000 0000 .......M%+...... 0000032: 5245 5355 4d45 2d31 5254 4620 00a3 347e RESUME-1RTF ..4~ 0000048: 4a30 8830 0000 4a33 7830 0900 f121 0000 .0.0.....0...!..

The first two lines show a directory entry with the attribute at byte 11 set to the binary value 0000 1000 (0x08), which is for a volume label. We can also see that the write time and date are set at bytes 22 to 25 on line 2. The write time on a volume label may contain the date when the file system was created. Note that the volume label in the boot sector was set to "NO NAME."

The third and fourth lines are for a second directory entry, and we see that the name of this file is "RESUME-1.RTF." The attribute value at byte 43 is 0000 0010 (0x20), which means that only the archive attribute bit is set. Byte 45 shows the tenths of a second for the create time, which is 163 (0xa3). Bytes 46 to 47 have the created time, 0x7e34, which is 15:49:40. The created day is in bytes 48 to 49 and has a value of 0x304a, which is February 10, 2004. The rest of the times are left as an exercise, if you are really bored.

We can see from bytes 52 to 53 and 58 to 59 that the starting cluster is 9 (0x0000 0009), and bytes 60 to 63 show that the file size is 8,689 (0x0000 21f1) bytes. To determine all the clusters in this file, we will need to refer to the FAT. Cluster 9 has a 36-byte offset into the FAT32 structure, and we previously calculated that the primary FAT structure starts in sector 38. Its contents are shown here:

# dcat f fat fat-4.dd 38 | xxd [REMOVED] 0000032: ffff ff0f 0a00 0000 0b00 0000 0c00 0000 ................ 0000048: 0d00 0000 0e00 0000 0f00 0000 1000 0000 ................ 0000064: 1100 0000 ffff ff0f 1300 0000 1400 0000 ................

The table entry for cluster 9 is located in bytes 36 to 39, and we see that the value is 10 (0x0000 000a), which means that cluster 10 is the next cluster in the chain. The table entry for cluster 10 is in bytes 40 to 43, and we see that the value is 11 (0x0000 000b). We can see that consecutive clusters were allocated to this file until we get to entry 17 at bytes 68 to 71, which has an end-of-file marker (0x0fff ffff). We can verify that we have the correct number of clusters by comparing the file size with the allocated space. The file has allocated 9 1,024-byte clusters, so there are 9,216 bytes of storage space for the 8,689-byte file.

We can now view some of this same data with TSK. Remember that TSK uses sector addresses instead of cluster addresses. To convert cluster 9 to its sector address, we need the sector address of cluster 2, which is 1,632:

(Cluster 9 Cluster 2) * 2 (Sectors per Cluster) + Sector 1,632 = Sector 1,646

The fsstat tool in TSK dumps the contents of the FAT structures. We previously saw part of the fsstat output when discussing the file system category of data, but the FAT contents were removed. Here is that output:

# fsstat f fat fat-4.dd [REMOVED] 1642-1645 (4) -> EOF 1646-1663 (18) -> EOF 1664-1681 (18) -> EOF [REMOVED]

Here the output shows us the cluster chain for RESUME-1.RTF from sectors 1646 to 1663 and the End of File. Each cluster was 2 sectors in size, so we can see in the parentheses that there are 18 sectors in the cluster chain.

The istat tool in TSK shows the details of a directory entry and its output for this entry is given next. Using the metadata-addressing scheme of TSK, the RESUME-1.RTF file is the second entry in the root directory, which means that it has an address of 4.

# istat -f fat fat-4.dd 4 Directory Entry: 4 Allocated File Attributes: File, Archive Size: 8689 Name: RESUME-1.RTF Directory Entry Times: Written: Wed Mar 24 06:26:20 2004 Accessed: Thu Apr 8 00:00:00 2004 Created: Tue Feb 10 15:49:40 2004 Sectors: 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663