Difference between revisions of "ISO9660 Implementation Notes"

From SleuthKitWiki
Jump to: navigation, search
(Updated and corrected this page.)
(Revised based on recent changes.)
Line 11: Line 11:
 
possibility of finding more and alerts the user to this.
 
possibility of finding more and alerts the user to this.
  
When TSK loads the file system, it runs through the path tables and processes each directory listed in the path tableIt starts with the secondary volume descriptors and moves the primary ones. If an entry already exists for this file, then it is not addedThis is under the assumption that we are now processing a primary descriptor with a more basic name and we should instead use the secondary / unicode name.
+
When TSK loads the file system, it chooses a secondary volume descriptor, runs through its path table, and processes each directory listed in itEach file found during this process is saved in memory and assigned a metadata address.   
  
NOTE: The above design does not seem to work well because it is hard to detect duplicate files.  We have some images that have duplicate files that are different names, but that have the same starting block address (the current method for detecting duplicate files).
+
After the secondary volume descriptor is loaded, the other volume descriptors are processed in the same manor.  Now though, we check for an entry that duplicates an entry that was added by the previous process.  We skip entries for files that duplicate the starting block and size of an existing entry. If the file is unique, it is added to the internal list and given an address.  However, these files will be treated specially because they cannot be reached from the directory tree of the initially processed volume descriptor. They will be marked as being "unallocated" (because they can't be reached from the root directory) and will end up as orphan files in the $OrphanFiles directory.   
 
+
ISO9660 does not assign numeric addresses to each file.  TSK must therefore determine them. It does this by assigning an address to each file as it is loaded during the startup.  If it gets added to the list, it gets the next address.
+
 
+
The file name code in TSK processes each directory, but needs to figure out the metadata address.  Therefore, it searches the previously loaded data. It needs to match the loaded files with the current fileIt does this based on starting block, but we have found problems with this because multiple files can have the same starting block.
+
  
 +
The file name code in TSK processes each directory, but needs to figure out the metadata address.  Therefore, it searches the previously loaded data. It needs to match the loaded files with the current file.  It does this based on the byte offset of the directory entry.
  
 
= What TSK Cannot Currently Do =
 
= What TSK Cannot Currently Do =
Line 27: Line 24:
 
* High Sierra is not handled.
 
* High Sierra is not handled.
 
* Files that are stored with an interleave gap
 
* Files that are stored with an interleave gap
 
Original Version By: Wyatt Banks, Crucial Security
 

Revision as of 19:18, 20 February 2010

Introduction

The ISO9660 file system is used on many platforms and has many variations and extensions. At the most basic level of ISO9660 there are several differences than traditional file systems due to the type of media available.

This document describes how it was implemented. It assumes that you know the basics of the ISO9660 format.

General Notes

Due to many reports of mastering software errata, there are some issues that The Sleuth Kit handles that the specifications for ISO9660 say will never happen. The specs say that there is only one unique primary volume descriptor per volume. The Sleuth Kit handles the possibility of finding more and alerts the user to this.

When TSK loads the file system, it chooses a secondary volume descriptor, runs through its path table, and processes each directory listed in it. Each file found during this process is saved in memory and assigned a metadata address.

After the secondary volume descriptor is loaded, the other volume descriptors are processed in the same manor. Now though, we check for an entry that duplicates an entry that was added by the previous process. We skip entries for files that duplicate the starting block and size of an existing entry. If the file is unique, it is added to the internal list and given an address. However, these files will be treated specially because they cannot be reached from the directory tree of the initially processed volume descriptor. They will be marked as being "unallocated" (because they can't be reached from the root directory) and will end up as orphan files in the $OrphanFiles directory.

The file name code in TSK processes each directory, but needs to figure out the metadata address. Therefore, it searches the previously loaded data. It needs to match the loaded files with the current file. It does this based on the byte offset of the directory entry.

What TSK Cannot Currently Do

There are a few things that The Sleuth Kit is not yet able to do with ISO9660:

  • Multisessions CDs are not handled.
  • High Sierra is not handled.
  • Files that are stored with an interleave gap