Chapter 12: Forensic Examination of Macintosh Systems

Apple Macintosh systems receive less attention than other systems as a source of digital evidence, probably because there are fewer of them and people are less familiar with them. However, these systems cannot be ignored since criminals use them and the user-friendly graphical user interface does not translate into a user-friendly digital examination. If anything, digital evidence examiners need to dedicate more attention to these systems. More of the newer, colorful, compact Macintosh desktop, and laptop systems are being sold worldwide and the emergence of UNIX-based MacOS X has attracted more technical users who appreciate the power of UNIX and the convenience of the Macintosh interface. There are only a few tools for examining digital evidence on a Macintosh. As a result this chapter provides a necessarily brief introduction to Macintosh systems.

12.1 File Systems

As with other systems, Macintosh stores its partition table in the first sector on disk. The first sector of each volume contains the boot sector and additional details about the volume are stored in the third sector. Like FAT16 and FAT32, the Macintosh HFS and HFS Plus (HFS+) file systems use 16 and 32 bits, respectively, to address clusters on a disk. HFS supports a maximum of 2¹⁶ (65536) clusters and HFS Plus has a maximum of 2³² clusters. The main files comprising HFS are the Catalog and Extents Overflow files. The Catalog file is comparable to a master file table, containing records for each file and folder on the system with attributes such as date-time stamps. HFS represent time as the number of seconds since midnight, January 1, 1904, GMT.

Records in the Catalog file are stored in a balanced tree (B-tree), which is a simple database that enables efficient searching. Each record in the Catalog file has a unique number called a catalog node ID (CNID). The Catalog file has four types of records: folders, files, folder threads, and file threads. Although the format of folder and file records varies between HFS and HFS Plus, they contain similar information. Folder records contain the following fields, in addition to some details used by the system.

• Record type: 0 0100

• Name: folder name

• Valence: number of files and folders directly contained by this folder

• CNID: unique catalog node ID

• Creation date: when this folder was created

• Modification date: when a file or folder was created or deleted inside this folder, or when a file or folder was moved in or out of this folder

• Access date: not maintained by HFS (always set to zero)

• Backup date: when this folder was last backed up

File records contain the following fields, in addition to some details used by the system.

• Record type: 0 0200

• Name: file name

• CNID: unique catalog node ID

• Creation date: when this file was created

• Modification date: when a file modified by extending, truncating, or writing either of the forks

• Access date: not maintained by HFS (always set to zero)

• Backup date: when this file was last backed up

• Data fork: information about the location and size of the data fork

• Resource fork: Information about the location and size of the resource fork

The attentive reader will notice that folder records do not contain lists of their contents, and files have two storage areas on disk (a.k.a. forks). HFS uses folder and file thread records in the Catalog file to link names with the associated file or folder records using the unique CNID. These file and folder thread records also contain references to parent folders that are used to construct the file system hierarchy and directory listings that most users are familiar with. Files on an HFS volume have two forks: a data fork that stores the contents of a file, and a resource fork with a special data structure for information such as icons and menu items. The first eight clusters of each fork (a.k.a. extents) are listed in each file's Catalog record. Any additional extents are stored in the Extents overflow file, which is also organized as a B-tree.

Figure 12.1 (a) and (b) shows a file record in a HFS Catalog file in interpreted form and hexadecimal form, respectively. This file is located under the Trash folder, indicating that it was deleted but the Trash had not been emptied.

Figure 12.1: (a) File record interpreted using Norton Disk Editor. (b) Same file record in hexadecimal form.

Notice that, rather than relying entirely on file extensions to determine the type of data in a file, HFS stores this information in Catalog records. However, this information can be altered and should not be relied on to classify files.

When a file is moved to the Trash on a Macintosh, it is actually moved to a Trash folder but is not marked as deleted. The file is only marked as deleted when the Trash is emptied but the data remains on disk until it is overwritten. A file is marked as deleted by setting the key length value within the associated Catalog database key to zero. Also, when a file is deleted, its Catalog entry may be deleted, removing all references to the data on disk. Because of the complexity of the Catalog file, it is difficult to recover deleted files manually. Fortunately, automated tools exist that scan the Catalog B-tree and find deleted entries.

One significant change in HFS Plus is that it stores file and folder names in Unicode format. As with NTFS, the use of Unicode can have an impact on text searches. Also, be aware that MacOS X is UNIX based and supports the UNIX File System (UFS). Although digital evidence examiners can use many of the lessons from Chapter 11 to examine UFS, there are slight nuances when MacOS X is involved. For instance, MacOS X uses hidden files (e.g. ._filename) to translate the concept of HFS resource forks to UFS. Also, a file named "/etc/.hidden" contains a list of files that MacOS X hides - generally this only references system files but any filename could be hidden in this way.