ISO9660 Implementation Notes

From SleuthKitWiki
Revision as of 20:16, 15 February 2010 by Carrier (Talk | contribs)

Jump to: navigation, search

Note: This was copied from the skins_iso9660.txt file from TSK. It will need some help to integrate it into the Wiki.


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 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.

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.


TSK gets is file metadata from the path table and ignores the data stored in the directory contents.

TSK uses the location of the file in the path table as its "meta data address". For example, the first entry is entry 1.

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 order. A 32 bit number will take 8 bytes, the first 4 are little endian, the last 4 are big endian.

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

Original Version By: Wyatt Banks, Crucial Security