Mac OS X Systems and Artifacts
Information in this Chapter
Introduction
The first version of Mac OS X was released 10 years ago, and in the subsequent 10 years Apple has seen its fortune rise considerably. While not nearly as prevalent as Windows desktops and laptops, it is important that an examiner be prepared to deal with an OS X system if necessary. This chapter introduces the file system used by OS X, explains the layout of files and directories on the file system, and analyzes artifacts related to user and system activity.
OS X File System Artifacts
The file system used by OS X is called HFS Plus or Mac OS Extended. HFS+ is the successor to the Hierarchical File System (HFS) used on pre-OS X Mac operating systems. There are currently two variant HFS+ formats used to support journaling (HFSJ) and case-sensitive file names (HFSX). Beyond these extended capabilities, because these variants don’t alter the function or artifacts available to the examiner, we will treat them all as “HFS+” throughout this chapter. The best source of information available about HFS+ is an Apple technical document entitled “Technical Note TN1150: HFS Plus Volume Format [1].”
HFS+ Structures
The volume header is one of the core structures of an HFS+ volume. It stores data about the file system, including the allocation blocks size, the volume creation time stamp, and the location of the special files required for HFS+ operation, discussed later in the chapter. The volume header is always located 1024 bytes from the start of the volume, with a backup copy located 1024 bytes before the end of the volume.
HFS+ uses allocation blocks as data units. The size of a single allocation block is defined in the volume header, but 4K bytes is a common value. Allocation blocks can be further grouped into clumps, which are somewhat similar to the block allocation groups found in Ext file systems under Linux. A file’s data are addressed in terms of extents. An HFS+ extent is simply a 4-byte pointer to a starting allocation block and a 4-byte value indicating the length of the extent.
HFS+ files may have any number of data streams called forks associated with it. The two primary forks are the data fork and the resource fork. Generally the data fork holds the actual file content, while the resource fork will be empty or contain nonessential supporting information about the file. Additional forks may be created for a file for application specific purposes.
We can use the fsstat command from the Sleuth Kit to read information about the file system from the volume header. We will use the nps-2009-hfsjtest1/img.gen1.dmg file from the Digital Corpora as our test image while examining basic file system data.
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: HFS+
File System Version: HFS+
Volume Name: image
Volume Identifier: 9bee54da586b82f5
Last Mounted By: Mac OS X, Journaled
Volume Unmounted Properly
Mount Count: 11
Creation Date: Thu Jan 29 09:33:30 2009
Last Written Date: Thu Jan 29 09:33:42 2009
Last Backup Date: Wed Dec 31 16:00:00 1969
Last Checked Date: Thu Jan 29 09:33:30 2009
Journal Info Block: 2
METADATA INFORMATION
--------------------------------------------
Range: 2 - 28
Bootable Folder ID: 0
Startup App ID: 0
Startup Open Folder ID: 0
Mac OS 8/9 Blessed System Folder ID: 0
Mac OS X Blessed System Folder ID: 0
Number of files: 7
Number of folders: 4
CONTENT INFORMATION
--------------------------------------------
Block Range: 0 - 2559
Allocation Block Size: 4096
Number of Free Blocks: 443
From this output we can confirm the 4K allocation block size, some relevant time information associated with access to the volume, and a couple other pieces of OS X operating system-specific startup metadata that aren’t relevant on a nonsystem volume and are thus displayed as “0”. These include the two Startup items and the “Blessed” System Folder lines. These would point to items in the /System/Library/CoreServices directory on an OS X boot volume.
In addition to various Sleuth Kit tools, we can also use HFSExplorer from Catacombae. HFSExplorer is an open source cross-platform application that can be used to open and examine HFS, HFS+, and HFSX volumes. In addition, individual files can be extracted for detailed examination. See Figure 6.1 for the HFSExplorer display of the file system information from the Digital Corpora test image.
Figure 6.1 File system information in HFSExplorer.
We can continue our examination using fls from the Sleuth Kit.
forensics:~$ fls nps-2009-hfsjtest1/image.gen1.dmg
r/r 3: $ExtentsFile
r/r 4: $CatalogFile
r/r 5: $BadBlockFile
r/r 6: $AllocationFile
r/r 7: $StartupFile
r/r 8: $AttributesFile
d/d 21: .fseventsd
d/d 19: .HFS+ Private Directory Data^
r/r 16: .journal
r/r 17: .journal_info_block
d/d 20: .Trashes
r/r 24: file1.txt
r/r 25: file2.txt
d/d 18: ^^^^HFS+ Private Data
The “dollar” files are HFS+ special files used as the backbone of the HFS+ file system.
HFS+ Special Files
The bulk of the structures that an HFS+ relies upon for proper function are stored in the volume as hidden files, much like the MFT and associated files on an NTFS volume. An HFS+ volume has five such files, which are not directly accessible using standard file system utilities:
1. The allocation file is a bitmap that tracks the allocation status of each block of the volume.
2. The catalog file contains records for each file and directory on the volume. It serves many of the same functions that the Master File Table serves on an NTFS file system. By necessity, the location of the first extent of the catalog file is stored in the volume header. The location of all other files is stored in catalog records. HFS+ catalog records are 8K in length and include the catalog node ID (CNID) of the file or folder, the parent CNID, time stamp metadata, and information about the data and resource forks of the file.
3. The extents overflow file contains records for forks that have more than eight extents allocated to them. This file should be fairly sparse, as having more than eight extents indicates fairly severe fragmentation on an HFS+ file system.
4. The startup file is used to hold information used when booting from a system that doesn’t have knowledge of HFS+.
5. The attributes file can be used to store extended attributes for files. The attributes file is used in the per-file compression found in OS X 10.6.
One important item to note is that the allocation strategy for CNIDs is interesting from an analysis perspective. CNIDs are 32-bit values allocated sequentially starting from 16. They are not reused until all 32-bit integers (minus the reserved CNIDs) have been assigned. This allows the CNID to serve as a relative time marker. Files with higher CNID values are newer than files with lower CNID values, despite what any time stamp information would indicate. Additionally, missing CNID values indicate that a file was once present and has been subsequently deleted. See Chapter 9 for more information on relative time values and extended time analysis.
Next, we will examine metadata for a single regular file in detail using istat.
forensics:~$ istat nps-2009-hfsjtest1/image.gen1.dmg 24
Catalog Record: 24
Allocated
Type: File
Mode: rrw-r--r--
Size: 28
uid / gid: 501 / 501
Link count: 1
Admin flags: 0
Owner flags: 0
File type: 0000
File creator: 0000
Text encoding: 0
Resource fork size: 0
Times:
Created: Thu Jan 29 09:33:35 2009
Content Modified: Thu Jan 29 09:33:42 2009
Attributes Modified: Thu Jan 29 09:33:42 2009
Accessed: Thu Jan 29 09:33:35 2009
Backed Up: Wed Dec 31 16:00:00 1969
Data Fork Blocks:
2315
As you can see from the output just given, a Catalog Record supports five time stamps; however, only the first four are in active use on current HFS+ implementations.
Created: Updated when the file is created.
Content Modified: Updated when the file content is modified.
Attributes Modified: Updated when attributes (metadata) associated with the file are modified. This is similar to the inoded/metadata change time on Linux file systems.
Accessed: Updated when the file content is accessed.
Backed Up: Field is deprecated and usually null (as seen earlier).
Finally, to extract the file content we can use two different methods. First, the indirect method using icat.
forensics:~$ icat nps-2009-hfsjtest1/image.gen1.dmg 24
New file 1 contents - snarf
Alternatively, we can dump the allocation block directly using blkcat. We can see the block value in the istat output shown earlier under “Data Fork Blocks”:
forensics:~$ blkcat nps-2009-hfsjtest1/image.gen1.dmg 2315
New file 1 contents - snarf
Note that HFS+ volumes are capable of maintaining a journal; however, currently there are no open source forensic utilities capable of processing the journal for artifacts.
Deleted Data
Unfortunately, recovery of deleted files from HFS+ volumes is quite difficult. Because of the constant rebalancing of the B-Tree structures inside of the Catalog File, file metadata information is usually overwritten soon after a file is deleted from the file system. This leaves the examiner in much the same boat as on Linux—data recovery is sometimes possible via data carving, but associating recovered content with file names or dates will not be straightforward. Many data formats will contain extractable secondary identifying information or time information, however. Extraction of these data is covered in Chapter 8.
Ownership/Permissions
OS X uses POSIX standard permissions as default. These are described in Chapter 5. In addition to POSIX permissions, OS X 10.4 and newer supported extended ACLs for more finely grained control to files. This should not affect the forensic examiner’s ability to view file system content as we are viewing a dead file system outside of operating system restrictions. More information about the use and implementation of OS X extended ACLs is available at the Apple Developer Library [2].
OS X System Artifacts
Like Linux systems, OS X places all volumes under a single unified namespace below the root directory “/”. Immediately beneath the root directory are the following directories:
Applications—This directory is the standard location for all installed OS X applications. Generally this directory will hold applications designed to be launched interactively via the OS X GUI.
Library—Library directories hold supporting data that may need to be modified during execution of a program. This generally includes things such as preferences, recent items, and other similar data. The root Library directory contains system-wide configuration data. User-specific data are stored under user Library directories.
Network—Directory for items in the Network domain; generally empty.
System—This directory contains operating system-specific data, somewhat analogous to contents of the system32 directory on a Windows system.
Users—The parent directory for user home directories.
Volumes—The parent directory for mounted volumes; similar to /mnt or /media on Linux systems.
bin and sbin—These directories contain command-line utilities included in the OS X system.
private—This directory contains (among other things) OS X versions of /var, /tmp, and /etc.
Property Lists
Many artifacts of interest on an OS X system are stored as property lists or .plist files. There are two types of property lists: plain text, XML property lists and binary property lists. Plain text plist files can be examined directly or viewed in any XML display program. Binary plists need to be converted to plain text prior to analysis. Due to being more compact than their plain text equivalent, binary plists are becoming used more and more commonly. A typical OS X install will have thousands of plist files, so knowing which will be relevant to your examination is key.
Many OS X-native, closed source utilities interact with plist files, including a basic command line utility called plutil. Fortunately, Pete M. Wilson has developed a Perl script that can convert binary plist files to their plain text equivalent [3]. His script, plutil.pl, is quite simple to use. When provided with the name of a binary plist file, plutil.pl parses the file and outputs a plain text version in the same directory.
Bundles
On an OS X system, the “applications” users generally interact with are not monolithic files at all, but are in fact special directories known as bundles. Bundles are directories that have their contents hidden from the end user’s view by the operating system. Opening or double-clicking on an application bundle is enough to execute the application, but the actual executable code is several directories down from the bundle itself. Drilling down into the bundle via the OS X GUI can be performed via the right-click menu as shown in Figure 6.2.
Figure 6.2 “Show Package Contents” in OS X.
When examining an OS X system via the Sleuth Kit, the bundle will just be treated as a standard directory. Application bundles can be identified in a file listing by the “.app” extension in the directory name, and a set of subdirectories similar to the following:
Contents
Contents/Info.plist
Contents/MacOS
Contents/PkgInfo
Contents/Resources
Contents/Versions
The actual executable code is normally stored in the MacOS directory, with the other directories holding supporting data such as icons, text files, and the like.
System Startup and Services
On system boot, the bootloader boots the OS X kernel (/mach_kernel), which then runs the launchd process. Launchd serves as a replacement for init and the init scripts process found on Linux systems. The launchd takes its tasking from four directories. System tasks that run in the background are read from /System/Library/LaunchDaemons and /Library/LaunchDaemons, while user-interactive launch tasks are read from /System/Library/LaunchAgents and /Library/LaunchAgents. Launchd will read and process plists in these directories, launching the appropriate applications. Note that all of the plist files in these directories should be in the plain XML format and thus do not require conversion before examination. Per Apple’s documentation [4], the division of startup tasks is shown in Table 6.1.
Table 6.1
Standard Startup Locations
| /Library/LaunchAgents | Per-user agents provided by the administrator |
| /Library/LaunchDaemons | System-wide daemons provided by the administrator |
| /System/Library/LaunchAgents | Per-user agents provided by Mac OS X |
| /System/Library/Launch-Daemons | System-wide daemons provided by Mac OS X |
Kexts
OS X has the capability to load additional functionality into the kernel via kernel extensions. Kernel extensions are bundles with the extension kext and can be found in the /System/Library/Extensions directory. There are many Apple-provided kernel extensions in this directory, and there may be extensions for third-party hardware devices or programs that require low-level access, such as disk encryption software.
Network Configuration
The bulk of local system network configuration information on an OS X system is stored in various plist files under /Library/Preferences/SystemConfiguration. The preferences.plist file contains general settings for all the network interfaces on the system, as well as location-specific network profile information if this feature is in use. In addition, this file also shows the hostname of the computer, which may be important in a network-related examination.
<dict>
<key>ComputerName</key>
<string>forensic-macpro</string>
<key>ComputerNameEncoding</key>
<integer>1536</integer>
</dict>
The com.apple.network.identification.plist file is a rich source of historic network information. Among other data, this file contains a running list of previously assigned network addresses with time stamps. This information is obviously invaluable during investigation of a mobile laptop. For a relevant excerpt, see the following section.
<dict>
<key>Identifier</key>
<string>IPv4.Router=172.17.9.254;IPv4.RouterHardwareAddress=00:16:46:44:9a:43</string>
<key>Services</key>
<array>
<dict>
...
<key>IPv4</key>
<dict>
<key>Addresses</key>
<array>
<string>172.17.9.47</string>
</array>
<key>InterfaceName</key>
<string>en0</string>
...
<key>Timestamp</key>
<date>2010-03-30T20:15:59Z</date>
</dict>
Note that because this file does not appear to expire results or roll over, it is possible that historic network data could be stored indefinitely.
The com.apple.Bluetooth.plist file contains a list of all Bluetooth devices that have ever been paired with the system, including time stamps.
<key>LastInquiryUpdate</key>
<date>2010-04-07T23:36:07Z</date>
<key>LastNameUpdate</key>
<date>2010-04-08T01:01:10Z</date>
<key>LastServicesUpdate</key>
<date>2010-04-08T01:01:11Z</date>
<key>Manufacturer</key>
<integer>15</integer>
<key>Name</key>
<string>forensic-iphone</string>
<key>PageScanMode</key>
Hidden Directories
In addition to special bundle directory types that hide their contents from the user by default, OS X honors traditional Unix-style “dotfile” hiding. Files and directories named with a leading dot will be hidden from the user’s view by default. There are not as many of these hidden files on OS X systems as there are on a standard Linux installation but some are present, including a couple significant examples we will examine shortly.
Installed Applications
/Library/Receipts contains information about applications installed via the OS X Installer system. This directory contains various “pkg” bundles, which contain information about the installed package. The creation times of these directories should correspond with the date that the software was installed.
Swap and Hibernation dataData
OS X stores swap files and hibernation data under the /private/var/vm directory. Depending on how heavily used (and short on resources) the system is, there will be anywhere from 1 to 10 numbered swapfile items in this directory. These contain paged out sections of memory and can persist on disk for some time. Additionally, if hibernation is enabled, a sleepimage file will be present. This file will be the same size as the available RAM on the system and will contain a copy of memory as it existed the last time the system was put to sleep. Any techniques used for processing unstructured data streams are applicable to these files, including string extraction and file carving.
System Logs
OS X shares many logs with other Unix-like operating systems, such as Linux. In general, BSD and Linux-derived applications for OS X will store logs under /private/var/log. OS X will generally have a syslog daemon running and will generate many of the same logs (including syslog-derived logs) that a standard Linux system does. For detailed information on syslog and Linux logging, please see Chapter 5. Of the most interest to the examiner are the logfiles shown in Table 6.2, all found under /private/var/log.
Table 6.2
System Logs of Interest
| fsck_hfs.log | Record of all HFS/HFS+/HFSX volumes attached to the system |
| system.log | A catch-all log file, equivalent to messages on Linux |
| secure.log | Records all system authentication, including screensaver unlocks and SSH access. |
System-wide software created specifically for OS X will generally store logs under /Library/Logs. Examples include the “Software Update.log” file, which tracks when system software updates are applied, and the CrashReporter, HangReporter, and PanicReporter logs, which record application and kernel errors and make contain system state information related to the time they were generated.
User Artifacts
Each user on the system will have a plist stored under /private/var/db/dslocal/nodes/Default/users/ that corresponds to their short username. This contains basic user information similar to /etc/passwd entries on Linux systems, including the path to the user’s default shell, the user’s long displayed name, and the user’s UID. Group information is stored in /private/var/db/dslocal/nodes/Default/groups/ and is in a similar format. Of particular importance is the admin.plist file in the groups directory. Examining this file will help you determine if a given user has administrative or “root” privileges on this system. In the excerpt shown here, “root” and “user1” are both Administrators.
<array>
<string>Administrators</string>
</array>
<key>users</key>
<array>
<string>root</string>
<string>user1</string>
</array>
The /Library/Preferences/com.apple.loginwindow.plist file contains, among other items, information about the last user that logged into the system. This can be important during examination of a shared system.
<key>lastUser</key>
<string>loggedIn</string>
<key>lastUserName</key>
<string>forensic-user</string>
Home Directories
OS X systems are generally fairly “tidy.” As such, a user’s home directory is where most of the artifacts generated directly and indirectly by a user will be found. While certain user activities will generate artifacts in system areas (e.g., logging on and off), nearly all postauthentication user activity will be confined to items and residual data in their own home directory.
A standard user home directory will contain the default directories shown in Table 6.3.
Of all these directories, the one that contains the largest number of OS X-specific user artifacts is Library.
User’s Library
A user’s library contains a large number of indirect artifacts related to user activity. These include log files, preference settings, application artifacts, and artifacts generated from connecting to other devices or systems. It is an incredibly rich source of information exposing user activity on the system for several reasons. First, the Library is not a directory the user would ever explore under normal circumstances. Next, nearly all the artifacts present here are generated via interactive user activity, not automatic system processes. Finally, artifacts in the user’s Library will generally persist indefinitely unless purged actively. The Library contains a handful of subdirectories, each of which is intended to store specific classes of data. This section discusses some of the forensically interesting content of each of these directories.
Preferences
Library/Preferences/ contains preference data for applications installed on the system. This generally includes items such as recently opened files or network locations and any configuration changes the user may have customized. Among items of interest in Preferences is com.apple.quicktimeplayer.plist, which contains a list of video files that were opened using QuickTime, including the full path to the file. The following excerpt is from one of the author’s systems.
<dict>
<key>altname</key>
<string>IMG_1288.MOV - .../Downloads/IMG_1288.MOV</string>
<key>dataRef</key>
<data>
AAAAAAEeAAIAAAtNYWNpbnRvc2hIRAAAAAAAAAAAAAAAAAAAAADH
KHhBSCsAAAFJR2oMSU1HXzEyODguTU9WAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdr1
7cj4mD4AAAAAAAAAAP////8AAEkgAAAAAAAAAAAAAAAAABAACAAA
xyjowQAAABEACAAAyPj6rgAAAA4AGgAMAEkATQBHAF8AMQAyADgA
OAAuAE0ATwBWAA8AGAALAE0AYQBjAGkAbgB0AG8AcwBoAEgARAAS
ACFVc2Vycy9jb3J5L0Rvd25sb2Fkcy9JTUdfMTI4OC5NT1YAABMA
AS8AABUAAgAL//8AAA==
</data>
<key>dataRefType</key>
<string>alis</string>
<key>name</key>
<string>IMG_1288.MOV</string>
</dict>
Note that the “name” key is simply the bare file name, whereas the “altname” key is a relative path. The absolute path is embedded in the “dataRef” value. This is a base64-encoded value, which can be decoded any number of ways. The author prefers to use the decoding capabilities of openssl, as the openssl binary is generally present on any Unix-like system. There are many standalone base64 decoders for every imaginable operating system. To decode data, simply copy data out and save it to a file (1288-base64.data in this example) and run the following command:
forensics:~ user$ openssl enc -d -base64 -in 1288-base64.data -out decoded.bin
The full path can then be extracted using the strings command or by any hex dumping utility, such as xxd.
...
00000b0: 001a 000c 0049 004d 0047 005f 0031 0032 .....I.M.G._.1.2
00000c0: 0038 0038 002e 004d 004f 0056 000f 0018 .8.8...M.O.V....
00000d0: 000b 004d 0061 0063 0069 006e 0074 006f ...M.a.c.i.n.t.o
00000e0: 0073 0068 0048 0044 0012 0021 5573 6572 .s.h.H.D...!User
00000f0: 732f 636f 7279 2f44 6f77 6e6c 6f61 6473 s/cory/Downloads
0000100: 2f49 4d47 5f31 3238 382e 4d4f 5600 0013 /IMG_1288.MOV...
0000110: 0001 2f00 0015 0002 000b ffff 0000 ../...........
As the name implies, the com.apple.recentitems.plist contains numerous related to recently opened files and recently accessed file servers. Unfortunately, these entries are not time stamped so correlation with outside time sources (e.g., file system metadata) will be necessary to build a complete picture of use. The section that follows contains an excerpt displaying the last three Windows file share hosts this system contacted.
<key>Hosts</key>
<dict>
<key>Controller</key>
<string>CustomListItems</string>
<key>CustomListItems</key>
<array>
<dict>
<key>Name</key>
<string>forensics-2</string>
<key>URL</key>
<string>smb://forensics-2</string>
</dict>
<dict>
<key>Name</key>
<string>unicron</string>
<key>URL</key>
<string>smb://unicron</string>
</dict>
<dict>
<key>Name</key>
<string>parabola</string>
<key>URL</key>
<string>smb://parabola</string>
</dict>
</array>
<key>MaxAmount</key>
<integer>10</integer>
</dict>
The com.apple.DiskUtility.plist contains a key named “DUSavedDiskImageList,” which is used to populate the sidebar of the Disk Utility application. Items listed under this key display the full path for disk images that have been opened on the system. Note that this key can contain files that have been deleted from the system.
<key>DUSavedDiskImageList</key>
<array>
<string>/Users/forensic/Downloads/ntfs-3g-2010.1.16-macosx.dmg</string>
<string>/Users/forensic/Downloads/wxPython2.8-osx-unicode-2.8.9.1-universal-py2.4.dmg</string>
<string>/Users/forensic/Downloads/HFSDebug-Lite-4.33.dmg</string>
<string>/Users/forensic/Downloads/python-2.5-macosx.dmg</string>
<string>/Users/forensic/Downloads/notecase-1.9.8.dmg</string>
<string>/Users/forensic/Downloads/VirtualBox-3.2.10-66523-OSX.dmg</string>
</array>
The com.apple.finder.plist file is the main preference file for the Finder application, which is the graphical file explorer on OS X systems. This file contains numerous entries, but a few are of the most interest to an examiner. The “FXConnectToLastURL” key contains the full URL of the last server the system connected to via the Finder.
<key>FXConnectToLastURL</key>
<string>smb://my-server-1/c$</string>
Entries under the “FXDesktopVolumePositions” key correspond to the mount points and volume names of volumes that have been mounted on the system previously.
<key>FXDesktopVolumePositions</key>
<dict>
<key>/Volumes/1GB</key>
<dict>
...
</dict>
<key>/Volumes/BT4</key>
<dict>
...
Finally, the “FXRecentFolders” key contains the user’s most recently viewed directories.
<key>FXRecentFolders</key>
<array>
<dict>
<key>file-data</key>
...
<key>name</key>
<string>Downloads</string>
</dict>
As many Mac users also use iPods, iPhones, or iPads, examining the com.apple.iPod.plist may be an important part of an OS X investigation. This file contains data about any of these devices that have been attached to the system, including a wealth of identifying information (which has been redacted in the output here).
<key>Connected</key>
<date>2010-11-06T00:15:58Z</date>
<key>Device Class</key>
<string>iPhone</string>
<key>Family ID</key>
<integer>10004</integer>
<key>Firmware Version</key>
<integer>256</integer>
<key>Firmware Version String</key>
<string>4.1</string>
<key>ID</key>
<string>[REDACTED]</string>
<key>IMEI</key>
<string>[REDACTED]</string>
<key>Serial Number</key>
<string>[REDACTED]</string>
<key>Updater Family ID</key>
<integer>10004</integer>
<key>Use Count</key>
<integer>15</integer>
Application Support
The Application Support directory contains data supporting the operation of various programs installed on the system. This is generally used for data altered frequently and/or stored for long periods. Examples include Address Book application data, iPod syncing information, and profile data for the Firefox browser. Firefox browser data analysis is covered in detail in Chapter 7. Removing an application from the system will not usually remove any Application Support data so this can be a rich source of archival data.
Data synced from an iPod, iPhone, or iPad can be found in the Library/Application Support/MobileSync/Backup directory. This directory will contain one or more subdirectories that appear to be a long string of random digits. This is the device’s Unique Device Identifier (UDID). Multiple UDID directories may be present if multiple devices are synced to the machine or if multiple backups have occurred. The newest backup directory will be the “bare” UDID directory, and older backups will have the time and date they were created appended to the directory path (i.e., UDID-20101010-120000).
In each backup directory there will be (among the numerous files) an Info.plist file. This file contains information about the device that was backed up.
<key>Build Version</key>
<string>8A293</string>
<key>Device Name</key>
<string>Forensic iPhone</string>
<key>Display Name</key>
<string>Forensic iPhone</string>
<key>GUID</key>
<string>[REDACTED]</string>
<key>ICCID</key>
<string>[REDACTED]</string>
<key>IMEI</key>
<string>[REDACTED]</string>
<key>Last Backup Date</key>
<date>2010-07-24T06:22:33Z</date>
<key>Phone Number</key>
<string>1 (650) 555-1212</string>
<key>Product Type</key>
<string>iPhone2,1</string>
<key>Product Version</key>
<string>4.0</string>
<key>Serial Number</key>
<string>[REDACTED]</string>
<key>Sync Settings</key>
<dict>
While the values are redacted in this output, keep in mind that you can correlate the IMEI and Serial Number values from this file with those found in the com.apple.iPod.plist file given previously.
Logs
In addition to the system logs discussed earlier, the user’s Library/Logs/ directory holds many user-specific application logs. These will be almost universally plain text log files with a .log extension that can be viewed in any text editor or processed using similar techniques to those discussed in Chapter 5. In addition to user application-specific logs, the DiskUtility.log can be a valuable resource to determine if a performed any disk burning or other activities using the Disk Utility application (or applicable subsystems).
See the following segment for an excerpt from the DiskUtility.log. Note the time-stamped output, which can be correlated to access or modification times found in file system output.
2010-10-21 13:37:52 -0700: Disk Utility started.
2010-10-21 13:37:57 -0700: Burning Image "raptor20091026.iso"
2010-10-21 13:37:59 -0700: Image name: "raptor20091026.iso"
2010-10-21 13:37:59 -0700: Burn disc in: "HL-DT-ST DVD-RW GH41N"
2010-10-21 13:37:59 -0700: Erase disc before burning: No
2010-10-21 13:37:59 -0700: Leave disc appendable: No
2010-10-21 13:37:59 -0700: Verify burned data after burning: Yes
2010-10-21 13:37:59 -0700: Eject disc after burning
2010-10-21 13:37:59 -0700:
2010-10-21 13:37:59 -0700: Preparing data for burn
2010-10-21 13:37:59 -0700: Opening session
2010-10-21 13:37:59 -0700: Opening track
2010-10-21 13:37:59 -0700: Writing track
2010-10-21 13:40:52 -0700: Closing track
2010-10-21 13:40:52 -0700: Closing session
2010-10-21 13:40:56 -0700: Finishing burn
2010-10-21 13:40:56 -0700: Verifying burn...
2010-10-21 13:40:56 -0700: Verifying
2010-10-21 13:44:28 -0700: Burn completed successfully
Caches
The Cache directory is user-specific dumping ground for items intended to be temporary. Despite this, application data can persist in the Cache directory for a very long time, sometimes persisting even after the application that created data has been removed. As data stored in Cache directory are application specific, a detailed examination of the contents is outside of the scope of this chapter. An example of Cache content analysis can be found in Chapter 7.
.Trash
Each user directory should contain a hidden directory named “.Trash.” Unsurprisingly, this location is used as temporary file storage when a file is “deleted” using the Finder application. In OS X 10.5 and previous versions, simply viewing contents was the extent of examination possible for this directory. These versions of OS X did not keep track of the original location of the file, nor did they maintain any other metadata about the file. This has changed in OS X 10.6, which now stores the original path of the deleted file in a hidden .DS_Store file in the .Trash directory. The original path can be determined easily by viewing the .DS_Store file with a hex editor [5].
Shell History
OS X uses the Bourne Again Shell (BASH) by default, so if a user has used the terminal their shell history should be present in the user’s home directory in the “.bash_history” file. Because most OS X users will not use the Terminal at any point, the presence of entries in this file may be a sign that the user is a “power user” or is at least somewhat tech savvy. As on Linux, this file does not have time values associated with each entry, but through careful system examination, inferred times for listed activity may be deduced.
Summary
As Mac OS X systems continue to gain popularity, the ability to process these systems will become increasingly important. Additionally, many of the artifacts generated by OS X on desktops and laptops are also found on the iOS used in Apple’s line of mobile products—the iPod Touch, the iPhone, and the iPad. This chapter discussed analysis of the HFS+ file system used on OS X systems. It detailed the extraction of binary property list files, which are used to store the bulk of OS X’s configuration details and subsequently contain many artifacts of interest.
References
1. Technical Note TN1150: HFS Plus Volume Format. developer.apple.com/library/mac/technotes/tn/tn1150.html, (accessed 23.11.10).
2. Access Control Lists. http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFileSystem/Articles/ACLs.html.
3. System Startup Programming Topics: The Boot Process. http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPSystemStartup/Articles/BootProcess.html.
4. plutil.pl for Windows/Linux. http://scw.us/iPhone/plutil/.
5. Snow Leopard Put Back (Undelete). http://www.appleexaminer.com/MacsAndOS/Analysis/SLPutBack/SLPutBack.html.