1. Computer Forensics COEN 252

2.  File systems can be extent-based ◦ E.g. NTFS ◦ Storage space is allocated in extents, large sets of contiguous blocks ◦ Metadata often located in a single, central database such as the MFT in NTFS  Or, file systems can be inode-based ◦ UNIX and derivatives ◦ More flexible, but more overhead  Unix file systems usually come in two layers:  Disk layout  Veneer layer ◦ Allows splitting kernel into file-system dependent and non-file system dependent part

3.  Allocation of disk space to files is done with blocks.  Choice of block size is fundamental ◦ Block size small: Needs to store much location information ◦ Block size large: Disk capacity wasted in partially used blocks (at the end of file)  Typical Unix block sizes are 4KB and 8KB

4.  Inodes are fixed sized metadata describing the layout of a file  Inode structure: ◦ i_mode (directory IFDIR, block special file (IFBLK), character special file (IFCHR), or regular file (IFREG) ◦ i_nlink ◦ i_uid (user id) ◦ i_gid (group id) ◦ i_size (file size in bytes) ◦ i_addr (an array that holds addresses of blocks) ◦ i_mtime (modification time & date) ◦ i_atime (access time & date)

5.  Metadata in Inode is space-limited ◦ Number of block addresses in a single inode only suffices for small files ◦ Use (single and double) indirect inodes to find space for all blocks in a file

8.  Unix File Systems use inode numbers to refer internally to files. ◦ Classical Unix used a file table to mediate between users and their open files. ◦ File table have references to the inodes of open files.  General design ◦ Need to find free blocks: e.g. block bitmap ◦ Need to find free inodes: e.g. inode bitmap ◦ Inodes are located often in a designated area of the disk partition. (Inode Table) ◦ Data blocks often located in a designated area of the disk partition. ◦ Since this can create long actuator movements between metadata lookup and data block lookup, use Block Groups in EXT2  Divide partition in groups, where each group has this structure

9.  On-Disk Layout.  Superblock contains data on the file system.

11.  Disk Layout not uniform.  Ext2 (Linux) file system layout.

12.  Overview

13.  Ext superblock: ◦ Located 1024 B from start of the file system. ◦ Backups of superblock are usually stored in the first block of each block group. ◦ Contains basic information:  Block size  Total number of blocks  Number of reserved blocks

14. ByteDescription 0-3BNumber of inodes in file system 4-7BNumber of blocks in file system 8-11BNumber of blocks reserved to prevent file system from filling up 12-15BNumber of unallocated blocks. 16-19BNumber of unallocated inodes. 20-23BBlock where block group 0 starts 24-27BBlock size. (Saved as the number of places to shift 1,024 to the left). 28-31BFragment size. (Saved as the number of places to shift 1,024 to the left). 32-35BNumber of blocks in each group. 36-39BNumber of fragments in each block group 40-43BNumber of inodes in each block group. 44-47BLast mount time. 48-51BLast written time. 52-53BCurrent mount time. 54-55BMaximum mount count

15. ByteDescription 56-57BSignature 0xef53 58-59BFile system state 60-61BError handling method 62-63BMinor Version 64-67BLast consistency check time. 68-71BInterval between forced consistency checks 72-75BCreator OS 76-79BMajor version 80-81BUID that can use reserved blocks. 82-83BGID that can use reserved blocks. 84-87BFirst non-reserved inode in file system 88-89BSize of each inode structure 90-91BBlock group that this superblock is part of (if this is the backup copy) 92-95BCompatibility feature flags 96-99BIncompatibile feature flags

16. ByteDescription 100-103Read only feature flags 104-119File system ID 120-135Volume name 136-199Path were last mounted on 200-203Algorithm usage bitmap 204Number of blocks to preallocate for files. 205Number of blocks to preallocate for directories 208-223Journal ID 224-227Journal Inode 228-231Journal device 232-235Head of orphan inode list 236- 1023 Unused

17.  Group Descriptor Table ◦ In the block following superblock ◦ Describes all block groups in the system

18.  Group Descriptor Table Entries ◦ 0-3 starting block address of block bitmap ◦ 4-7 starting block address of inode bitmap ◦ 8-11 starting block address of inode table ◦ 12-13 number of unallocated blocks in group ◦ 14-15 number of unallocated inodes in group ◦ 16-17 number of directories in group

19.  Total number of blocks includes Reserved area and all groups.  Blocks per group determines size of group.

20.  Block Group Descriptor Table ◦ Located in block following the superblock ◦ Basic layout of a block group: ◦ Block bitmap takes exactly one block. ◦ Inode bitmap manages allocation status of inodes.

21.  Number of blocks = bits in bitmap = bits in a block (namely the bitmap block). ◦ Size of block determines number of blocks in a block group!  Inode bitmap starting address contained in block descriptor table.  Size of Inode bitmap given by #inodes per group divided by 8.  Block group descriptor table gives starting block for inode table.  Size of inode table = 128B * number of inodes.

22.  Boot Code ◦ If exists, will be in the 1024B before the superblock.  Many Linux systems have a boot loader in the MBR. ◦ In this case, there will be no additional boot code.

23.  Data stored in blocks. ◦ Typical block sizes are 1,024B; 2048B; or 4096B  Allocation status of a block determined by the group’s block bitmap

24.  Analyzing content: ◦ Locate any block ◦ Read its contents ◦ Determine its allocation status  First block starts in the first sector of the file system. Block size is given by superblock.

25.  Determining allocation status: ◦ Determine the block group to which the block belongs. ◦ Locate the groups entry in the group descriptor table to find out where the block bitmap is stored. ◦ Process the block bitmap to find out whether this block is allocated or not.

26.  To find all unallocated blocks: ◦ Systematically go through the block bitmap and look for 0 bit entries. ◦ Status of reserved sectors at the beginning is less clear since there are no bitmap entries for them.

27.  Metadata is stored in the inode data structure.  All inodes have the same size specified in the superblock.  Inodes have addresses starting with 1.  Inodes in each group are in a table with address given by the group descriptor. group = (inode – 1) / INODES_PER_GROUP

28.  Inodes 1 – 10 are typically reserved.  Superblock has the value of the first non- reserved inode. ◦ Inode 1 keeps track of bad blocks. ◦ Inode 2 contains the root directory ◦ Journal uses Inode 8 ◦ First user file in Inode 11, typically for lost+found

29.  Inode can store the address of the first 12 data blocks of a file.  For larger files, we use double indirect and triple indirect block pointers

30.  Allocation Algorithms ◦ Block group:  Non-directories are allocated in the same block group as parent directory, if possible.  Directory entries are put into underutilized groups. ◦ Contents of allocated inode are cleared and MAC times set to the current system time. ◦ Deleted files have their inode link value decremented.  If the link value is zero, then it is unallocated.  If a process still has the file open, it becomes an orphan file and is linked to the superblock.

31.  Inode Structure ◦ 0-1 File Mode (type and permissions) ◦ 2-3 Lower 16 bits of user ID ◦ 4-7 Lower 32 bits of size in bytes ◦ 8-11 Access Time ◦ 12-15 Change Time ◦ 16-19 Modification Time ◦ 20-23 Deletion Time

32.  Inode Structure ◦ 24-25 Lower 16 bits of group ID ◦ 26-27 Link count ◦ 28-31 Sector count ◦ 32-35 Flags ◦ 36-39 Unused ◦ 40 – 87 12 direct block pointers ◦ 88-91 1 single indirect block pointer ◦ 92-95 1 double indirect block pointer

33.  Inode Structure ◦ 96-99 1 indirect block pointer ◦ 100 – 103 Generation number (NFS) ◦ 104 – 107 Extended attribute block ◦ 108 – 111 Upper 32 bits of size / Directory ACL ◦ 112 – 115 Block address of fragment ◦ 116 Fragment index in block

34.  Inode Structure ◦ 117 Fragment Size ◦ 118 – 119 Unused ◦ 120 – 121 Upper 16 bits of user ID ◦ 122 – 123 Upper 16 bits of group ID ◦ 124 – 127 Ununsed

35.  Inode Structure ◦ Permission flags of the file mode field  0x001 Other – execute permission  0x002 Other – write permission  0x004 Other – read permission  0x008 Group – execute permission  0x010 Group – write permission  0x020 Group – read permission  0x040 User – execute permission  0x080 User – write permission  0x100 User – read permission

36.  Inode Structure ◦ Flags for bits 9 – 11 of the file mode field  0x200 Sticky bit (save text image)  0x400 Set Group ID  0x800 Set User ID

37.  Inode Structure ◦ File mode field  These are values not flags  0x1000 FIFO  0x2000 Character device  0x4000 Directory  0x6000 Block device  0x8000 Regular file  0xA000 Symbolic link  0xC000 Unix socket

38.  Time Values ◦ Are stored as seconds since January 1, 1970, Universal Standard Time ◦ Get ready for the Year 2038 problem.

39.  Linux updates (in general) ◦ A-time, when the content of file / directory is read.  For a file:  If a process reads the file.  When the file is copied.  When the file is moved to a new volume.  But not if the file is moved within a volume.  For a directory  When a directory listing is done.  When a file or subdirectory is opened.

40.  Linux updates (in general) ◦ M-time, when the content of file / directory is modified.  For a file:  If file contents change.  For a directory  When a file is created or deleted inside the directory.  When a file is copied, the M-time is not changed.  However, when a file is copied to a network drive, the network server might consider it a new file and reset the M- time to the current time.

41.  Linux updates (in general) ◦ C-time corresponds to the last inode change.  When file / directory is created.  When permissions change.  When contents change. ◦ D-time is set only if a file is deleted.  When a file is created, then D-time is set to 0.

42.  Unallocated inodes contain temporary data. ◦ M-, C-, D-time values might show when the file was deleted.  Users can change A- and M-time with the touch command.

43.  Linux fills slack space (unused bytes of block) with zeroes.  Data from deleted files will only exist in unallocated blocks.  File size and allocated blocks will probably be wiped from unallocated inode entries.

44.  Linux file hiding technique: ◦ Have a process open a file for reading or writing. ◦ Delete the file name. ◦ Link count for the inode is zero, but inode is not unallocated. ◦ The file system should add the orphan inode to a list in the superblock.

45.  Directory Structure ◦ A directory entry consists of  A variable length name.  The inode number with the metadata of the entry. ◦ The original byte allocation is as follows:  0-3 Inode value  4-5 Length of entry  6-7 Length of name  8- Name in ASCII

46.  Directory Structure ◦ The improved byte allocation is as follows:  0-3 Inode value  4-5 Length of entry  6 Length of name (up to 255 now)  7 File type  0 unknown  1 regular file  2 directory  3 character device  4 block device  5 FIFO  6 Unix Socket  7 Symbolic link  8- Name in ASCII

47.  The record entry length allows the file system to find the next entry in a directory.  If a directory entry is deleted, then the previous entries length is increased.

48.  When FS is created, a Linux user can decide to use hash trees instead. ◦ Directory entries are no longer in an unsorted list. ◦ A directory using a hash tree contains multiple blocks, the nodes in the tree.  First block contains the “.” and “..” directory entries.

49.  Links ◦ Hard link: an additional file/directory name.  Implemented by another directory entry pointing to the same inode.  Link count in inode is incremented.  Directory link count is  2 + number of subdirectories  File system cannot distinguish between the first and the second name of file.

50.  Links ◦ Soft link: an additional file/directory name.  Implemented by a directory entry pointing to another inode.  Inode points to a file, that contains the path to the original file.

51.  Mount Point Example ◦ FS1 has directory /dir1. ◦ If FS2 is mounted on /dir1 and a user changed into /dir1, then only FS2 is shown.

52.  EXT hiding technique uses a directory (containing the files to be hidden) as a mount point.  Forensics tools tend to not give mount points. ◦ Consequentially, this hiding technique falls flat for forensics tools.

53.  EXT3 journal located at inode 8 (typically)  Journal records transactions ◦ Block updates about to occur. ◦ Log of update after the fact.  Two modes: ◦ Only metadata blocks are journaled. ◦ Metadata and data blocks are journaled.

54.  Ext3 Journal gives additional information about recent events.

55.  http://www.nondot.org/sabre/os/files/FileSy stems/ext2fs/ http://www.nondot.org/sabre/os/files/FileSy stems/ext2fs/  http://www.nongnu.org/ext2-doc/ http://www.nongnu.org/ext2-doc/

56.  Maintaining consistency in file systems after a crash is difficult ◦ 1970s: Possible to read complete file system metadata and piece it together  Log Structured File System (Osterhoot, Mendelbaum, 1990) ◦ Maintain all data, including metadata in a single log ◦ Only write to the end of the log ◦ Currently not used, but idea appears always attractive  Journaling File System ◦ Maintain a log of all metadata changes. ◦ After a crash, find point in journal where the file system was consistent, then roll forward from there  Forensic potential of journaling file systems has not yet been realized

57.  The Coroner’s Toolkit (TCT) ◦ http://www.porcupine.org/forensics/tct.html http://www.porcupine.org/forensics/tct.html  grave-robber  pcat, ils, icat, file  unrm and lazarus  Mactime  TCTUtils (Brian Carrier) ◦ http://www.digital-evidence.org/index.html http://www.digital-evidence.org/index.html  Sleuth Kit (Brian Carrier) ◦ http://www.sleuthkit.org/sleuthkit/desc.php  Autopsy Forensics Browser ◦ GUI for TCT and TCTUtils ◦ http://www.sleuthkit.org/autopsy/desc.php http://www.sleuthkit.org/autopsy/desc.php  Commercial tools (Encase, FTK, … )