Case Studies On File System Analysis

Case Studies on File System
Analysis
Part III. Advanced Techniques and Tools for Digital

Forensics
CSF: Forensics Cyber-Security

Fall 2018
Nuno Santos
Previously: File system interpretation
45 00 00 1d 7b bd 00 00
} File system interpretation c0 a8 01 37 23 82 23 83
examines data in a volume (i.e., a ...
partition or disk) and interprets

them as a file system
} Outcome results: listing files in

directories, recovering deleted
content, viewing the contents of a
sector, etc.
2 CSF - Nuno Santos 2017/18

Data categories
} Reasoning about data categories help guide our searches for
evidence in file system images

Featured tool: The Sleuth Kit (TSK)

Layout of ExtX file system
} Organized as sequence of logical blocks (akin to FAT’s clusters)

} The block size is defined upon disk formatting; 1, 2, 4 or 8KB are common
} Blocks are grouped into larger units called block groups
} All block groups have equal length possibly except the last one

Layout of a FAT file system
} Layout of FAT16 on a volume (two more variants FAT12, FAT32)

} “FAT” comes from the index table used to track directories and files: File
Allocation Table

Layout of NTFS file system
} Central paradigm: Everything is a file

} Each byte of an NTFS file system belongs to a file
} File system data and meta data are located in files, too
} Similarly to FAT FS, files are chunked into clusters
} Cluster 0 starts at the beginning of the file system
} At the beginning of cluster 0 is the boot sector

Class roadmap
} Case studies on file system analysis
} Recover deleted files
} Recover files from reformatted partitions
} Recover corrupted partition
} Investigate past file system operations (extra)

Recover deleted files

Case study: Recover deleted files from FAT16
} Goal: to recover deleted files from the USB storage device

} Follow the root directory and look up suspicious files

How the FAT handles file creation and deletion
} There is a specific data area for the root directory

} Subdirectories are stored in clusters like files are
Boot Sector
Data Area FAT
Root Directory Cluster 90 Cluster 200
Cluster with the

File1.txt 200 new content
that was just
dir1 90 created in the
directory
201
EOF
This is more
data that
couldn’t fit into
the first cluster

FAT: File deletion
} The FAT entries of the file’s clusters are set to null
} The file’s directory entry is unallocated
Boot Sector
Data Area FAT
Root Directory Cluster 90 Cluster 200
Cluster with the

_ile1.txt 200 new content
that was just
dir1 90 created in the
directory
0
0
To unallocate a directory This is more

data that
entry, the first byte is couldn’t fit into
overwritten with a special the first cluster
byte (0xE5)
Layout of the root directory
} Root directory keeps files’ names, first cluster, size, and other metadata
32 bytes
(fixed) FAT
00
# root directory entries
01 Format of a root directory entry

Offset Length Meaning
(defined in BPB)
02
03 0x00 8B File Name
04 0x08 3B Extension
05 0x0b 1B File Attribute
06 0x0c 10B Reserved

… 0x16 2B Time of last change
Root 0x18 2B Date of last change

Directory 0x1a 2B First cluster
0x1c 4B File size

File names and subdirectories
} Short file names (8.3) on FAT12 and FAT16
} Short File Name (SFN) format
foo.bar -> FOO BAR

FOO.BAR -> FOO BAR
Foo.Bar -> FOO BAR
foo -> FOO
foo. -> FOO
PICKLE.A -> PICKLE A
prettybg.big -> PRETTYBGBIG
} Note: case is not significant

} “.” between primary filename and extension is implied
} Everything is space-padded
} Subdirectories are special files that follow the same format as the root folder
} Each directory contains two special entries: “..” (refers the parent) and “.” (refers itself)

Long file names
} If a file has a name that is longer than eight
characters or if the name has special characters, a
Long File Name (LFN) type of directory entry is
added
} Example of how additional entries are added to

represent the file name “My Long File Name.rtf”

Long file name entries
Offset Length Meaning

0x00 1B Entry order number
0x01 10B Characters 1-5 of name entry.
0x0b 1B File Attribute. MUST be 0F.
0x0c 1B Should be 00.
0x0d 1B Checksum of short file name.
0x0e 12B Characters 6-11 of name entry.
0x1a 2B MUST be 00 00 to be compatible.
0x1c 4B Characters 12-13 of name entry.

Example of file name entries
Entry Order Number Attribute

Resuming the case study: Locate the root dir
} After reverse engineering the BPB we locate it
} Try to recover all deleted files / directories by navigating

through the root directory
} Requirement: We need to understand:

} What’s the format of directories in FAT16
} How the OS updates directories when creating / deleting files
Step 1: Examine the root directory
} After reverse engineering the BPB
} Three entries
} Top: a short entry
} Then a long followed by the associated short entry

Step 1: Examine the 1st entry of root directory
} First Entry
} File attribute is 28 -> 0010 1000 b
} Volume marker is set
} Archive marker is set
} Volume Label
} Name is Lexar Media

Step 2: Examine next entries of root directory
} Next two entries: a deleted long and short record.

} File attribute 0F (long entry)
} File attribute 10 (directory)
} Leading byte 0xE5 (deleted)

Step 3: Examine next entries of root directory
} Long entry file name: .Trashes

} Short entry file name: TRASHE~1
} First cluster is 04 59 -> 0x 5904 -> 22788

} Size is 00 00 08 00 -> 0x 00 08 00 00 = 2048

Step 4: Navigate the deleted directory
} Go through the directory to find interesting entries

} At the end, a deleted directory called My Pictures
} Starts at cluster 0x0846

Step 5: Navigate the deleted subdirectory
} Go to this sector:
} Two deleted directories kittieporn and adultporn
} First directory starts at cluster 0x4708

Step 6: Proceed with subdirectory navigation
} Check the file at cluster 0x0849

} File is called “CA55.304438-1-t”
} Size is 0x07C1 = 1985, fits into 1 cluster
} Starts at cluster 0x849

Step 7: Inspect the deleted file
n Magic number JFIF tells us that this is a JPEG file

Step 7: Inspect the deleted file
n Save the file using a carving tool (more details later)

n See what we found!

File creation in NTFS
\dir1\file1.txt

File deletion in NTFS
\dir1\file1.txt

File creation in Ext3
Adding file: /dir1/file1.dat

File deletion in Ext3
Deleting file: /dir1/file1.dat

Recover files from reformatted
partitions

Case study: Stale files from reformatted NTFS
} During an investigation of a Windows system, we find that one of the

volumes was formatted a day before the disk was acquired
} We determine this based on temporal data associated with the FS metadata files
} The file system has no files or directories in the root directory, but we want to
recover some of the files from the previous file system
} Our approach
} When a FS is formatted, a new MFT is created with minimal number of MFT
entries
} Therefore, the MFT entries from the previous file system should still exist in the
unallocated clusters of the new file system
} If we find the entries, we can use them to recover their original attribute contents

The Master File Table and attributes
MFT entry Clusters
$STANDARD_INFORMATION
Master File Table resident
(MFT) Creation time: …,
33
… Modification time: …,
...
100
101 34
102 $DATA
non-resident
103
Clusters: 34-36
104 35
...
105
…
36
Attributes

MFT entry layout

MFT entry attributes
} Examples of pre-
defined attributes for
MFT entries
} All system attributes

are defined in system
file $AttrDef
} MFT entry 4

Look for stale MFT entries in unallocated space
} First, we extract the unallocated space of the FS so that we can search it using
dls from TSK
} Can skip this step if your search tool allows you to search only unallocated space
} Now we will search for the old MFT entries

} Each MFT entry starts with the ASCII signature "FILE.”
} We can do this ]with a normal text-searching tool like grep or we can use sigfind
} We use sigfind to limit hits at an offset of 0 bytes from the start of the sector
} We convert "FILE" in ASCII to hexadecimal and get 0x46494c45

Search results
} This produces several hits, including one in sector 412
} The contents of sector 412 are the following (the different parts of the
data structure have been broken up):
} This is the MFT entry header

} The flag in bytes 22 to 23 show that this entry was allocated (0x0001 in
little-endian ordering) before it was formatted
} Bytes 20 to 21 show that the first attribute starts at byte offset 56
(0x0038). The header of the first attribute is shown next

Header of the first attribute
} This first attribute is for the $STANDARD_INFORMATION attribute (0x0010)

} Its length is 96 bytes (0x0060)
} We could analyze this attribute for the temporal information it contains
} Next, we advance ahead 96 more bytes from byte 56 to byte 152
Standard attribute header (resident, no $STANDARD_INFORMATION attribute
name)

Header of the second attribute
} The second attribute is for the $FILE_NAME attribute (0x0030)

} Its length is 112 bytes (0x0070); the name of the file is given, and it is "letter1.txt”
} We also see that the parent directory of this file was MFT entry 5, which is the root directory
} Next, advance ahead 112 bytes from our starting location of byte 152 to byte 264
Standard attribute header (resident, no name) $FILE_NAME attribute

The last file attributes
} The third attribute is an $OBJECT_ID attribute (0x0040)

} Its length is 40 bytes (0x28)
} We advance to the next attribute at byte 304
} This last attribute is a $DATA attribute (0x0080)

} Its length is 456 bytes (0x01c8)
} The content of the attribute starts at byte 328 and starts with "Hello Mr. Jones.”
} The entire letter is in the MFT entry because it is in a resident attribute
} Had it been non-resident, we would have had to parse the run list and locate the clusters in the FS image

Layout of the recovered file’s MFT entry
} The layout of the MFT entry we found in unallocated space
} Note: There is an end marker of just four bytes: 0xFFFFFFFF.
} In this scenario, we looked for evidence of files prior to a volume being formatted
} We searched for "FILE" signature that exists for MFT entries and then parsed one by hand
} We could proceed by parsing the individual data structures for each attribute in more detail

Recover corrupted partition

Case study: Recover corrupted NTFS partition
} During an investigation, we encounter a disk and acquire it
} However, there are many bad sectors in it including the first sector
} The first sector is where the partition table is located
} Need to determine if a partition exists, determine its type and size

} The disk came from a Windows system, and we think it used NTFS
} Our disk image is a raw image, and 0s were written to the bad sectors.

The NTFS boot sector
} Useful to remember the layout of the NTFS boot sector
} http://www.ntfs.com/ntfs-partition-boot-sector.htm
} Our first search is for the end

of sector marker (0xAA55)
} We hope to find either the first
sector of NTFS or the sector
after the end of the file
system, which is where the
backup copy is located

Perform the search using a tool, e.g., sigfind
} Output of the search using sigfind:
} Sigfind searches for 0xAA55 in every block from offset 510
} In parenthesis provide the offset in blocks from the previous match
} See a series of hits very close

together, starting at sector 210,809
} This is not what we would expect from
because the boot code should follow
the boot sector, not more copies
} This is also not the expected layout
from partition tables, which have the
same signature
} We can look at one of the copies to

see if it is a false hit

Refining the search
} To reduce the false positives, search for the string "NTFS"
starting in byte 3 of a sector, which is part of the OEM field
} Then compare those search results with the previous hits to

narrow ones that could be from our file system.
} Note: the "NTFS" value is not an essential value in the NTFS boot sector, so
it might not be there
NTFS boot sector

Searching for “NTFS”
} "NTFS" in hexadecimal is 0x4e544653, and some tools
can find sectors that have both signatures in a sector.
} This produces fewer hits, and when the two results are
compared we find that some sectors occur in both results:
1 075 545, 1 075 561, 2 056 319
} Proceed by checking the contents of the blocks

Validate the blocks’
contents
} If it’s NTFS boot block, blocks’ contents

must reflect the NTFS boot block’s fields
} Pick one or more fields and validate

their values inside the blocks
} Contents of sector 1 075 545

} It looks valid, but its value for the total
number of sectors is 0
} Contents of sector 1 075 561

} Same situation, so these blocks are not
likely to be from a real file system The fields in the BPB and the
extended BPB on NTFS volumes

Check sector 2 056 319
} Sector 2 056 319 has more non-zero values than previous hits
} it has a cluster size of 1,024 bytes
} the number of sectors is 2,056,256
} the starting MFT cluster is 342,709
} If this boot sector is legitimate, there are two scenarios for it

1. One is that it is located in the first sector of the file system
2. Second, it is located in the sector following the end of the file system
sector # sector #
2 056 319 2 056 319
NTFS File System NTFS File System
Scenario 1 Scenario 2
Compare the sector sizes
} We notice that the reported number of sectors in the FS is 63 sectors

smaller than the address of where we found the boot sector
} Thus, this could be the backup boot sector for a FS that started in sector 63
sector #
63 sectors
2 056 319
NTFS File System
} Let’s check this theory by looking for the MFT

Looking for the MFT
} The boot sector reports that the starting
cluster for the MFT is cluster 342 709
} Which is sector 685 418 of the FS and
sector 685 481 of the disk
} Each MFT entry starts with the signature

string “FILE”
} So, let’s check if we see the signature:

Confirm that this is the first entry of the MFT
} We move back two sectors (because each MFT entry is 1,024 bytes) and show
that it does not start with "FILE":
} We are now convinced that there could have been an NTFS file system that
started in sector 63 and had a size of 2 056 256 sectors
} We make a copy of our disk image and copy the boot sector backup to sector 63
sector # 63 sector # 2 056 319
NTFS boot sector 2 056 256 sectors Backup of NTFS boot sector
NTFS File System
} To import the file system into our normal analysis tool

} We can either extract the 2,056,256 sectors of the file system from the disk image
} Or create a partition table in sector 0 of the image with a partition from 63 to 2,056,318
Extra: Investigate past file system
operations

Conclusions
} To analyze file system data, there are several general

techniques that can be applied based on the data category of
the file system
} On typical FS investigations we normally need to combine

multiple techniques that operate on each data category
} In addition to be able to master each technique, it is important

to understand the functional behavior of the OS when acting
upon the data structures of the FS

Case study: Journal investigation
} In this scenario, we are investigating a Linux system that has
been compromised
} It was imaged on the same day as the compromise, so there

could be information in the journal from the compromise
} As part of the investigation, we find a directory with various

attack tools and a deleted file named passwords.txt
} We want to recover the file by examining the journal

Overview of the Ext3 journal
} The Ext3 journal typically uses inode 8 although its location is
specified in the superblock
} The journal records what block updates will occur, and after the
update it identifies that the update is finished
} Can operate in two modes:

} Only metadata updates are recorded in the journal
} Or all updates, including data blocks, are recorded
} Journaling in Ext3 is done at a block level

} If one bit of one inode is updated, the entire file system block in which the
inode is located will be saved to the journal
} This is in comparison to a record level approach that would save only the
inode data and not the full block

Data structures of the Ext3 journal
} Managed like a circular buffer of block-sized records:
} The first block is for its superblock and contains general information
} The other blocks are used for the journal entries, and the journal wraps
around to the start when it reaches the end
} The size of a journal block should be the same size as a file system block

Updates to the Ext3 journal
} Updates are done in transactions (tx); each transaction has a sequence number (tx#)
} Blocks in the journal contain either tx administrative data or file system update data
} Each tx starts with a descriptor block with tx# and a list of what FS blocks are being updated
} Following the descriptor block are the updated blocks that were described in the descriptor
} When the updates have been written to disk, a commit block exists with the same sequence number
Transaction 839
Transaction 840

Inspecting the contents of the journal
} The jls tool in TSK will list the contents of a journal, e.g.:
} This output shows superblock, descriptor, and commit blocks

} Tx 295 starts in journal block 1 and ends in block 8
} We also see the FS blocks to which each journal block corresponds
} Can extract the journal blocks from the journal using jcat (TSK)
Returning to our case study
} We want to recover the file passwords.txt
} We know that the deleted file allocated inode 488 650
} This inode is located in block group 30
} The first inode in the block group is 488 641
} The inode table starts in block 983 044
} Each block is 4 096 bytes
} Hence, our inode of interest is entry 10 of the group’s inode table and is in
the first block of the table
first inode in group inode of file passwords.txt
# 488 641 # 488 650
Group’s Inode Table
1st block of the group’s inode table = 983 044 block

Search the block in the journal
} Run jls on the journal and look for an entry for FS block 983
044
} There are several references to block 983 044

} In the reference above, we see the inode table being updated, as well as
the superblock, group descriptors, parent directory, and block bitmap

Inspect the inode
} We extract the inode table from journal block 2297 and use
dd to skip ahead to the tenth inode in the table:
} This is the data that was once inode 488,650

} Its size is given in bytes 4 to 7, and it is 7 940 bytes (0x1f04)
} The two direct block pointers are given in bytes 40 to 43 and 44 to 47
} We see that it allocated blocks 983,569 and 983,570
} When we view the contents of those blocks, we find a list of passwords for
various systems that our attacker had compromised

In this scenario
} The journal allowed us to find a previous copy of an

inode
} The file was recently created, and its inode was still in
the journal
} We are not 100% sure that the inode in the journal is

the last valid data for the file
} But the contents included a list of passwords

References
} Primary bibliography
} Bryan Carrier, File System Analysis, 2005, Chapter 8

Next class
} III.9 Introduction to Cloud Forensics and Conclusion

Case Studies On File System Analysis

Uploaded by

Copyright:

Available Formats

Case Studies On File System Analysis

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Case Studies On File System Analysis

Uploaded by

Copyright:

Available Formats

Case Studies on File System

Part III. Advanced Techniques and Tools for Digital

CSF: Forensics Cyber-Security

partition or disk) and interprets

} Outcome results: listing files in

2 CSF - Nuno Santos 2017/18

3 CSF - Nuno Santos 2018/19

4 CSF - Nuno Santos 2018/19

} Organized as sequence of logical blocks (akin to FAT’s clusters)

5 CSF - Nuno Santos 2018/19

} Layout of FAT16 on a volume (two more variants FAT12, FAT32)

6 CSF - Nuno Santos 2018/19

} Central paradigm: Everything is a file

7 CSF - Nuno Santos 2018/19

} Case studies on file system analysis

} Recover deleted files

} Recover files from reformatted partitions

} Recover corrupted partition

} Investigate past file system operations (extra)

8 CSF - Nuno Santos 2018/19

9 CSF - Nuno Santos 2018/19

} Goal: to recover deleted files from the USB storage device

10 CSF - Nuno Santos 2018/19

} There is a specific data area for the root directory

Root Directory Cluster 90 Cluster 200

Cluster with the

11 CSF - Nuno Santos 2018/19

Root Directory Cluster 90 Cluster 200

Cluster with the

To unallocate a directory This is more

01 Format of a root directory entry

06 0x0c 10B Reserved

Root 0x18 2B Date of last change

14 CSF - Nuno Santos 2018/19

foo.bar -> FOO BAR

} Note: case is not significant

15 CSF - Nuno Santos 2018/19

} Example of how additional entries are added to

16 CSF - Nuno Santos 2018/19

Offset Length Meaning

17 CSF - Nuno Santos 2018/19

Entry Order Number Attribute

} Try to recover all deleted files / directories by navigating

} Requirement: We need to understand:

20 CSF - Nuno Santos 2018/19

21 CSF - Nuno Santos 2018/19

} Next two entries: a deleted long and short record.

22 CSF - Nuno Santos 2018/19

} Long entry file name: .Trashes

} First cluster is 04 59 -> 0x 5904 -> 22788

24 CSF - Nuno Santos 2018/19

} Go through the directory to find interesting entries

25 CSF - Nuno Santos 2018/19

26 CSF - Nuno Santos 2018/19

} Check the file at cluster 0x0849

27 CSF - Nuno Santos 2018/19

n Magic number JFIF tells us that this is a JPEG file

28 CSF - Nuno Santos 2018/19