HFS is a generic term used by TSK to refer to the HFS, HFS+, and HFSX file systems. They are commonly found on Apple systems and are supported by TSK (as of 3.1.0). As of TSK 4.0.0, HFS+ extended attributes, resource forks, and compressed files are also supported.
HFS+ is the native file system for all versions Mac OS X and was introduced in 1998 to replace HFS. On Macs, HFS+ is often referred to as "Mac OS Extended." HFS (without the +) is rarely seen any more, except as a compatibility wrapper around early HFS+ file systems (from before OS X 10.4).
HFSX is a version of HFS+ that optionally supports case-sensitive path names. It is commonly used on iOS devices (iPhones, etc.).
For more information, refer to:
- Apple Developer's Technical Note 1150 which describes the HFS+ format
- Forensics Wiki Entry
- Wikipedia HFS Entry
- Wikipedia HFS+ Entry
HFS in TSK
The SleuthKit supports HFS+ and HFSX. It also supports HFS, but only as a wrapper around an HFS+ file system.
Files in HFS+ can have two sets of data, called forks: a data fork and a resource fork. The data fork of most files contains what is conventionally considered to be the file's content. With the exception of compressed files, resource forks are not often used in modern versions of Mac OS X. As of TSK 4.0.0, a file's resource fork is visible in its istat output and can be retrieved via icat. In TSK, a file's resource fork is made available as a file attribute called RSRC, number 128-1, that can be passed to icat for examination. (The data fork is attribute 128-0, DATA, and is normally the default one used by icat.)
istat also parses the resource fork's contents (if present) and prints a list of the individual resource entries. For each resource, it shows the resource type (four ASCII characters), the numeric ID, the offset (in bytes) within the file's resource fork, the size (in bytes), and the name of the resource (which is optional).
HFS+ supports arbitrary named attributes, called extended attributes, on files and directories. Finder info and ACLs are two common uses for attributes in HFS+. Extended attributes are also used to mark compressed files.
As of TSK 4.0.0, istat shows all of a file's extended attributes. Each extended attribute is loaded as a TSK attribute, with type ExATTR (numerically, 224) and the name of the extended attribute as its TSK attribute name. There is one exception: an attribute that marks a file as compressed, as explained in the next section, will have type CMPF (numerically, 272).
HFS+ File Compression
In Mac OS X 10.6, Apple introduced file compression in HFS+. Compression is most often used for files installed as part of Mac OS X; user files are typically not compressed (but certainly can be!). Reading and writing compressed files is transparent as far as Apple's file system APIs.
Compressed files have an empty data fork. This means that forensic tools not aware of HFS+ file compression (including TSK before 4.0.0) will not see any data associated with a compressed file!
All compressed files have an extended attribute named com.apple.decmpfs which contains a compression header of 16 bytes. The actual data for compressed files is stored in one of three ways, depending on the size and compressibility of the file:
- The data is stored in the resource fork and compressed with zlib. (The resource fork will contain exactly one resource, of type cmpf. Apple's HFS+ implementation prevents compressed HFS+ files from having other resource fork data.) This compression strategy is used for large files.
- The data is stored in the com.apple.decmpfs extended attribute, compressed with zlib, immediately after the compression header. This compression strategy is used for mid-sized files (those that compress down to ~3800 bytes or less).
- The data is stored, uncompressed, in the com.apple.decmpfs extended attribute immediately after the compression header. This compression strategy is used for very small (or empty) files, effectively storing their data directly in the Attributes tree rather than reserving separate blocks on disk for it.
(The on-disk format allows for other compression strategies to be defined and used, but Mac OS X as of 10.7.4 only uses these three.)
In cases 2 and 3 (above), TSK will load the uncompressed data of the file into resident DATA attribute 128-0. In case 1, TSK will make the compressed data in the resource fork available as non-resident attribute 128-1, as usual. The uncompressed data will be available as a virtual DATA attribute, 128-0 (appearing as non-resident).
Thus, for any compressed file, icat of the default DATA attribute (128-0) will show the uncompressed content of the file. To read the raw, compressed data, point icat at the resource fork attribute (128-1) or at the com.apple.decmpfs attribute as appropriate.