# Extraction of Creation-Time for Recovered Files on Windows FAT32 File System
## 3 Proposed Method to Extract Creation-Time Bound  
### Working Mechanism of Proposed Method  
In this subsection, we explain how to derive the creation-time bound of a recovered file. If the meta information of a recovered file remains in one of the directory entries, we can easily recover its exact creation-time by matching the cluster offset of a recovered file with the location-related meta information of directory entries. In the directory entries of deleted files, the first byte of the file name field is set with the deletion mark '0 xE5'. Figure 5 shows an example, where the data area is composed of a single directory entry cluster and 30 content clusters (for the sake of simplicity, only a part of meta information in directory entries is depicted and a directory entry cluster is omitted. Also, a few content clusters are given although the number of content clusters in practical storage devices is very large.). In this example, at first file A, file B and file C are allocated sequentially. Next, file B is deleted. At last file D and file E are allocated sequentially. When a partial contents of file B are recovered using the existing forensic tools [16; 17], all meta information of file B can be reconstructed by matching the cluster offset of the recovered file and the location-related meta information of directory entries. Because the start offset of deleted file B is 4 and the number of allocated clusters is 4, the cluster offsets allocated to file B are 4, 5, 6 and 7. Hence the contents recovered from the cluster offset 7 are corresponding to file B. If there are two or more directory entries matched with the cluster offset of the recovered file, the directory entry with the latest creation-time is selected. The meta information in the matched directory entry contains the exact creation-time of the recovered file. When the directory entries of deleted files are eliminated by recording the meta information of new files, the reconstruction of creation-time becomes complex. Figure 6 shows an example where the directory entries of deleted files are eliminated. There are two directory entry clusters, each of which consists of six directory entries as shown in Figure 6a and whose depictions are omitted in Figure 6b for the sake of simplicity. In this example, at first file A, file B, file C, file D, file E, and file F are allocated sequentially. Next file D is deleted and file G is allocated. Next file B, file G and File F are deleted. At last file H, file I, file J and file K are allocated sequentially. The directory entries of deleted files B, D, G and F are eliminated by recording the directory entries of other files. Figure 6a shows directory entries that are established according to the wrap-around next available algorithm. In this figure, \(\rightarrow\) means the overwriting replacement of metadata. Figure 6b shows content clusters in the data area that are established according to the Deletion-backward Next Fit algorithm. In this figure, a box filled with light gray denotes a cluster containing a non-deleted file, a box filled with dark gray denotes a cluster containing a deleted file, and a box filled with white denotes a cluster never allocated. Names of deleted files in dark gray boxes are depicted for the sake of readability, although they disappeared when their corresponding directory entries are overwritten. The proposed method traces the file creation event sequence using both the stored pattern of directory entries and the file allocation pattern of content clusters, explained in Sections 2.1 and 2.2, respectively. First, the proposed method retrieves the file creation event sequence from the stored pattern of directory entries with some hidden marks for deleted events. Table 1 shows notations used to formally describe our trace analysis in this paper. The notation? denotes a single hidden event of a deleted file, and the notation \(*\) denotes uncertain number (none, single, or multiple) of continuous hidden events of deleted files.