Difference between revisions of "ISO9660 Implementation Notes"

From SleuthKitWiki
Jump to: navigation, search
(Cleaned up a bit.)
(Reverting to remove vandalism)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Note: This was copied from the skins_iso9660.txt file from [[TSK]]. It will need some help to integrate it into the Wiki.
 
 
 
 
=Introduction=
 
=Introduction=
The [[ISO9660]] file system is used on many platforms and has many
+
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.
variations and extensions.  At the most basic level of ISO9660 there
+
are several differences than traditional filesystems 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.  
 
This document describes how it was implemented.  It assumes that you know the basics of the [[ISO9660]] format.  
Line 17: 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 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. 
  
TSK gets is file metadata from the path table and ignores the data stored in the directory contents.  
+
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.
  
TSK uses the location of the file in the path table as its "meta data address". For example, the first entry is entry 1.  
+
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.  
 
+
TSK loads the path table when it loads the image and then searches through it for each file lookup.
+
 
+
ISO9660 stores many fields as both byte orderA 32 bit number
+
will take 8 bytes, the first 4 are little endian, the last 4 are
+
big endian.
+
  
 
= What TSK Cannot Currently Do =
 
= What TSK Cannot Currently Do =
Line 35: 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
 

Latest revision as of 06:53, 4 February 2013

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