File System Analysis
Metadata Category
FILE SYSTEM ANALYSIS
• File System, File System Category, Content
Category, Metadata Category, File Name
Category, Application Category, Application-level
Search Techniques, Specific File Systems, FAT
Concepts and Analysis: Introduction, File System
Category, Content Category, Metadata Category,
File Name Category, The Big Picture, Other Topics.
FAT Data Structures: Boot Sector, FAT32 FSINFO,
FAT, Directory Entries, Long File Name Directory
Entries.
Metadata category
• The metadata category is where the descriptive data reside.
• For example, the last accessed time and the addresses of the data units
that a file has allocated.
• Few tools explicitly identify metadata analysis; instead, it is typically
merged with file name category analysis.
• Many metadata structures are stored in a fixed or dynamic-length table,
and each entry has an address.
• When a file is deleted, the metadata entry is set to the unallocated state,
and the OS may wipe some of the values in the entry.
• Analysis is conducted in the metadata category to determine more details
about a specific file or to search for a file that meets certain requirements.
• This category tends to have more nonessential data than other categories.
• For example, the last accessed or written times may not be accurate or
the OS may not have enforced the access control settings on a file;
therefore, an investigator cannot conclude that a user did or did not have
read access to a file.
Logical file address
• A data unit that is allocated to a file also has a logical file
address.
• A data unit's logical file address is relative to the start of
the file to which it is allocated.
• For example, if a file allocated two data units, the first data
unit would have a logical file address of 0, and the second
would have a logical file address of 1.
• The name or metadata address for the file is needed to
make a unique logical file address.
• Example below shows two files that have allocated five
data units.
• Note that logical file system address 1 is not allocated;
therefore, it does not have a logical file address.
Slack space
• Slack space occurs when the size of a file is not
a multiple of a data unit size.
• A file must allocate a full data unit, even if it
needs only a small part of it, and the unused
bytes in the last data unit are called slack
space.
• For example, if a file is 100 bytes, it needs to
allocate a full 2,048-byte data unit, and the
final 1,948 bytes would be slack space.
• Slack space is interesting because computers are lazy. Some
of them do not wipe the unused bytes, so the slack space
contains data from previous files or from memory.
• By the design of most computers, there are two interesting
areas of slack space.
• The first area is located in between the end of the file and
the end of the sector in which the file ends.
• The second area is located in the sectors that contain no
file content.
• There are two distinct areas because hard disks are block-
based and can be written to in only 512-byte sector-sized
chunks.
• In the previous example, the OS cannot write only 100
bytes to the disk, it must write 512 bytes.
• Therefore, it needs to pad the 100 bytes with 412 bytes of
data.
• The first area of slack space is interesting because the
OS determines what to pad the file content with.
• The obvious method is to fill in the sector with zeros,
and that is what most OSes do.
• This is like filling a box with white packing paper.
• Some older OSes, namely DOS and early Windows, fill
the remainder of the sector with data from memory.
• This is similar to filling a box with copies of your
financial statements.
• This area of slack space was called RAM slack, and it is
now typically filled with zeros.
• RAM slack from memory could reveal passwords and
other data that was not supposed to be written to disk.
• The second area of slack space is the remaining unused sectors in the data unit.
• This area is interesting because some OSes wipe the sectors and others ignore
them.
• If ignored, the sectors will contain data from the file that previously allocated
them.
• Consider an NTFS file system with a 2048-byte cluster and 512-byte sectors.
• Our file is 612 bytes, so it uses the entire first sector and 100 bytes of the second
sector in the cluster.
• The remaining 412 bytes of the second sector are padded with data of the OSes
choice.
• The third and fourth sectors may be wiped with zeros by the OS, or they might not
be touched and might keep the data from a deleted file.
• We can see this in Figure below, where the grayed areas are the file content and
the white space is the slack space.
• All file systems have slack space because all file
systems allocate data in multiple-byte chunks
instead of in individual bytes.
• Slack space is interesting because of the OS and
what it writes, not because of the file system. It is
important to note that slack space is considered
allocated data.
• It may contain data from a previously deleted file,
but it is currently allocated to a file.
• If we extract the unallocated data from a file
system, it should not include the slack space of a
file.
Metadata based file recovery
• In some cases, you might want to search for
evidence in deleted files.
• There are two major methods for recovering
deleted files:
– metadata-based file recovery
– application-based file recovery
• Metadata-based recovery works when metadata from
the deleted file still exists.
• If the metadata was wiped or if the metadata structure
was reallocated to a new file, we will need to rely on
application-based techniques.
• After you find the metadata structure for the file,
recovery is easy.
• It is no different from reading the contents of an
allocated file.
• For example, Figure-A below shows an example where
the unallocated metadata entry still has its data unit
addresses, and we can easily read the contents.
• On the other hand, Figure-B shows an example where
the OS has cleared the addresses when the file was
deleted.