ISO9660 Implementation Notes

From SleuthKitWiki
Revision as of 10:36, 5 January 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 ISSO9660 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.

Inodes don't really exist in ISO9660 so the implementation is improvised based on anything thats extent is unique is a different file. The pseudo inode structure is stored in a linked list to make viewing an entire image faster.

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