Digital Evidence and Computer Crime, Second Edition

11.2 File Systems

There are many different UNIX file systems including UFS (UNIX File System) and ext2 (Extended File System 2) that have similar structures. Although directories play a role in UNIX file systems, they are much simpler than their Windows counterparts, only containing a list of filenames and their associated inode (index node) numbers. Every file has an associated entry in the inode table, identified by the inode number, which contains all information about the file, apart from its name. As shown in Figure 11.2, the contents of an inode include date-time stamps, the number of bytes in the file, and which clusters (a.k.a. blocks) on the disk contain the data.

Figure 11.2: Conceptual representation of a directory and inode where the file types include regular, directory, symbolic link, and socket.

As shown in Figure 11.3, UNIX file systems break each partition into block groups, each with its own inodes and data blocks. Compartmentalizing data in this way prevents catastrophic file system damage because there is no single point of failure. If the disk area containing one block group is damaged, only the data in that group are impacted, leaving data in the other groups intact.^[1]

Figure 11.3: Overview of UNIX file systems.

In addition to containing data, each block group contains duplicates of critical file system components; that is, the superblock and group descriptors, to facilitate recovery if the primary copy is damaged. The superblock contains information about the file system such as block size, number of blocks per block group, the last time the file system was mounted, last time it was written to, and the sector of the root directory's inode.^[2]

As the name suggests, group descriptors contain the most important information for each block group including the location of the inode table (a list of inodes and their locations). Group descriptors for all of the block groups are duplicated in each block group in case of file system corruption. So, if the primary group descriptor in any block group is damaged, a backup copy of the group descriptor can be used to repair the damage. If the inode table itself is damaged, it becomes more difficult to reconstruct the files in that block group.

Applying the library card catalog analogy from Chapter 8 to UNIX file systems, imagine a library with several divisions, each with its own books and associated card catalog. If an absent minded librarian loses his list of the locations of each division's card catalog, he can obtain an identical list from any other division. However, if the card catalog in one division is damaged or destroyed, this information is not duplicated anywhere, making it more difficult to find books in that division. Fortunately, because of the compartmentalization, damage to one division's card catalog does not adversely effect other divisions.

To summarize, when a system is commanded to access a file such as "/etc/passwd," it first looks in the superblock for the sector of inode number 2 to find the root directory as shown in Figure 11.4. The system then reads the root directory until it finds the entry for "etc" with its associated inode number (inode 0x00038001 = 229377 in Figure 11.4), reads the data blocks referenced by inode 229377 until it finds the entry for "passwd," and accesses the associated inode to identify the data blocks occupied by the password file (Figure 11.5).

lde v2.6.0 : ext2 : /dev/hdd2 Inode: 2 (0x00000002) Block: 0 (0x00000000) 0x00000002: drwxr-xr-x 21 4096 . 0x00000002: drwxr-xr-x 21 4096 .. 0x0000000B: drwxr-xr-x 2 16384 lost+found 0x00008001: drwxr-xr-x 2 4096 boot 0x00010001: drwxr-xr-x 17 77824 dev 0x00020001: drwxr-xr-x 2 4096 proc 0x0000000C: -rw-r--r-- 1 0 .autofsck 0x00028001: drwxr-xr-x 17 4096 var 0x00034001: drwxrwxrwt 8 4096 tmp 0x00038001: drwxr-xr-x 49 4096 etc 0x00048001: drwxr-xr-x 15 4096 usr 0x00598003: drwxr-xr-x 2 4096 bin 0x00640003: drwxr-xr-x 3 4096 home 0x0064C003: drwxr-xr-x 2 4096 initrd 0x00650003: drwxr-xr-x 7 4096 lib 0x00660003: drwxr-xr-x 4 4096 mnt 0x0066C003: drwxr-xr-x 2 4096 opt 0x00670003: drwxr-x--- 7 4096 root 0x0067C003: drwxr-xr-x 2 4096 sbin 0x0044C04C: drwxr-xr-x 2 4096 misc 0x000E0021: drwxr-xr-x 4 4096 e1

lde v2.6.0 : ext2 : /dev/hdd2 Inode: 229505 (0x00038081) Block: 0 (0x00000000) -rw-r--r-- 1 root root 1186 Tue Sep 24 08:57:40 2002 TYPE: regular file LINKS: 1 DIRECT BLOCKS=0x000703F9 MODE: \0644 FLAGS: \10 UID: 00000(root) GID: 00000(root) SIZE: 1186 SIZE(BLKS): 8 ACCESS TIME: Tue Nov 26 11:10:18 2002 CREATION TIME: Tue Sep 24 08:57:40 2002 MODIFICATION TIME: Tue Sep 24 08:57:40 2002 DELETION TIME: Wed Dec 31 19:00:00 1969 INDIRECT BLOCK= 2x INDIRECT BLOCK= 3x INDIRECT BLOCK=

If a file contains more data than can be referenced by the direct blocks field in its inode, additional indirect blocks are used to store this information. In other words, the indirect blocks contain lists of data blocks that contain the file. Even larger files may require additional indirection, in which case indirect blocks will contain lists of more (secondary or 2x) indirect blocks that in turn contain lists of data blocks that contain the file. Some file systems even allow for a third level of indirection as noted in Figure 11.5.

As shown in Figure 11.5, Linux maintains a date-time stamp of when each file was deleted. In this instance, the file has not been deleted and the value is set to a default value. This is zero from a UNIX standpoint since it represents time in epoch time, the number of seconds since January 1, 1970 00:00:00 UTC.

When a file is deleted on a UNIX system, the file's directory entry is hidden from view and the system notes that the associated inode is available for reuse. The file's directory entry, inode, and data remain on the disk until they are overwritten. Some systems such Solaris, ext3, and newer versions of ext2 remove the inode number in the directory, thus breaking the link between directory entries and inodes, making it more difficult to recover deleted files. Also, some systems like HP-UX delete directory entries completely, making file recovery even more difficult. Furthermore, newer file systems also break the link between the inode and the sectors that contained the data, thus removing all file system references to the data.

UNIX ctime is not equivalent to NTFS creation time (NTFS record modified time is closer). File modifications do not change the ctime. The difference between a change (ctime) and a modification (mtime) in UNIX is the difference between altering the label of a package and altering its contents (Peek et al. 1997). A change alters a file's inode whereas a modification alters the contents of the file. For instance, when someone changes permissions on a file it is a change, whereas when someone adds to the contents of a file it is a modification.

The ext3 Linux file system is similar to ext2 but adds journaling capabilities to facilitate file system recovery and repair after a system crash. As with NTFS, there are currently no tools available for interpreting the journal file on ext3 to determine what changes were made. This is a potential rich source of information from a forensic standpoint that will certainly be exploited in the future.

^[1]Block groups are sometimes called cylinder groups because they are comprised of one or more consecutive disk cylinders.

^[2]The root directory is always associated with inode number 2 and is denoted by a "/". The first inode is generally used to keep track of bad blocks.