Chapter 7. Macintosh Forensic Analysis
Anthony Kokocinski
Contents
Introduction353
Imaging and File Systems353
Macintosh File Systems355
Property Lists359
User Accounts359
Applications364
System365
User Folders370
User Folders: Media Files371
User Folders: Applications372
Wrap Up382
References382
Introduction
Apple Macintosh computers running Mac OS X are in widespread use, and can pose a challenge for many digital forensic examiners. Lack of regular exposure to Macintosh systems as a source of evidence make it harder for digital forensic examiners to become adept at locating and interpreting useful information on these systems. Even forensic examiners with some familiarity with these systems may not be sufficiently conversant to perform a forensic examination using Macintosh-based automated tool suites. It is generally most effective to conduct a forensic examination of Macintosh systems in a native Macintosh environment. However, this chapter makes an effort to address repeated requests over the years for guidance on how to conduct Macintosh forensics using Microsoft Windows-based forensic tool suites.
This chapter covers basic information on hardships encountered when processing Mac OS X 10.2–10.5 systems, provides tips on where to find configuration and user data, and breaks down a few application-specific data structures. A few new tools will be introduced and common forensic tool suites for Windows will be reviewed as appropriate to the data storage.
Imaging and File Systems
Most Macintosh file systems are going to occur on easily identifiable media. Hard drives, optical discs, and thumb drives can all be formatted with Macintosh partitioning structure and file systems. These media can be imaged with traditional means and safety procedures. By now imaging computer systems, no matter what they are, should be ingrained into the brain of any digital forensic examiner and will not be repeated here. However, there are several common misconceptions that forensic practitioners have when imaging Macintosh systems.
Although Windows-based operating systems do not always understand Macintosh on disk structures, this does not absolve forensic practitioners from employing write protection when acquiring a forensic duplicate. In some cases, Windows may alter areas of Macintosh formatted media and can cause irreparable damage by trying to recover the disk to a format it understands.
It is possible to image many Macintosh systems equipped with at least one FireWire port by setting the machine into target disk mode. This can be done in a number of ways; the most notable is by holding down the T key as it boots up. This is a set of hard-coded instructions in both the Open Firmware of PowerPCs and EFI of Intel-based Macintoshes. This process was created as a convenience for Macintosh users who wanted an easy way to transfer data between machines and had gotten used to the previous way of moving data through SCSI. Target disk mode basically turns a Macintosh computer into a very expensive external hard drive, and like hard drive enclosed circuitry, simply putting the computer into this mode does not alter any data. Because some Macintosh laptops have hard drives that are very difficult to remove, some practitioners took the risk of putting the evidentiary system in target disk mode and connecting it directly to a Windows examination machine without write protection, just to avoid taking apart an iBook. In addition, when the G5 towers first came out, SATA was a less familiar hard drive interface and there were no hardware write-blockers for SATA, so practitioners used target disk mode in favor of buying additional hardware.
There are risks associated with using target disk mode to acquire a forensic image of a hard drive. In addition to the aforementioned risks of not using a write-blocker, the target disk mode function is not available by default if there is a firmware password, and key depresses are ignored upon boot up, until the set OS is engaged.
An increasing number of forensic tools are incorporating features for examin-ing Macintosh file systems, but they may not provide access to all on-disk structures. This has been a constant arms race between forensic suites, but it is often something that falls behind. In some instances, even some partition structures are not identified or are displayed correctly. If a single tool is relied upon without validation either manually or using another tool, then some information may be missing.
Macintosh systems can use more than one type of partition structure. Unlike Windows-based systems that use a relatively simplistic partitioning scheme, Macintosh systems commonly have many partitions that are often unknown to the casual user. These partitions are not an indication of a highly skilled user or of data hiding, but rather are used by the system to store drivers and other enabling software safely out of the way of the user of the system.
Macintosh File Systems
File systems are often a bit overwhelming, particularly when there are several data structures involved. Some digital forensic examiners maintain that background knowledge for understanding the logical structures of laying down data on a hard drive to be important but hard to keep in your head at all times during an analysis. For the vast majority of situations, however, it is sufficient to understand that Macintosh file systems maintain most of their information in the Catalog and Extent files.
There are numerous resources containing a wide variety and depth concerning Macintosh file systems that will not be reiterated here (Casey, 2004; http://developer.apple.com/technotes/tn/tn1150.html). A number of important considerations to remember when looking at files on a Macintosh file system such as HFS, HFS+ HFSX are covered here.
File System Date-time Stamps
The HFS+ and HFSX file systems support the following five date-time stamps:
▪ Create Date: When the file was created. Copying a file from one HFS volume to another generally preserves the create date.
▪ Modified Date: When the contents of the file was last changed.
▪ Attribute Modified Date: When attributes associated with the file were last altered, similar to the inode change time in UNIX. This can be updated without altering any of the data of the file. This is most commonly modified if the file is moved or renamed.
▪ Accessed Date: When the file was last accessed.
▪ Backup Date: A deprecated field that is not typically used.
These date-time stamps may not always be displayed or interpreted correctly by analysis tools. Figure 7.1 shows two forensic tools being used to view the same files on an HFS+ volume.
File Attributes
Macintosh operating systems can support file identification by both extension and type and creator codes. Forensic tools may not always display the type and creator codes, but they can be found in the Catalog tree alongside the other details about a file system object of interest. Other details contained in the Catalog tree that are often omitted by forensic tools include the Catalog Node Identifier (CNID) number, user and group numbers, and Unix-style file/folder permissions as shown in Figure 7.1(b).
Data versus Resource Forks
Macintosh file systems natively contain multiple “forks” for a file. By default a data and resource fork are maintained. Since this is somewhat of a foreign concept to other file systems, the two forks are often displayed as two files by forensic examination tools. The forensic tools often provide some form of notation along with a resource fork to differentiate it as shown in Figure 7.2A, Figure 7.2B and Figure 7.2C and this fork often contains information that is much more difficult to understand on non-Macintosh systems.
 |
| Figure 7.2A |
 |
| Figure 7.2B |
File Deletion
Because of the nature of HFS, HFS+, and HFSX volumes, recovery of deleted file system details is particularly difficult. Unlike many Windows and Unix systems, recovery of deleted file system information on Macintosh systems is nearly impossible because nodes in the Catalog file are so frequently overwritten. This is largely due to the B-tree balancing process in the Catalog file, which obliterates previous file system details. Standard data carving techniques can be used to recover some file contents from Macintosh volumes, but only the data fork. This fork will retain what is a “typical” structure of media, document, application files with well-defined file formats, and header signatures that tools like Foremost rely on for carving as discussed in Chapter 2, “Forensic Analysis.” The real difficulty comes in further correlation; pairing the carved data for each fork would be very difficult, especially since a lot of the data in resource forks is undocumented. Additionally, tying specific files to a user can be very difficult when file system details are no longer available in a Catalog file record. Therefore, attributing a file to a particular user is often possible only through forensic examination of data contents.
Inodes
Lastly, although HFS, HFS+, and HFSX do not organize file data with inodes like many Linux or Unix file systems, files could be seen on the file system that have their names start with iNode and then contain a number (Figure 7.3A and Figure 7.3B). These are not inodes, nor are they typically seen during normal user usage. These files are the central location for data that is shared between hard links on a volume. This is the procedure that HFS+ uses to hard link files that share the same data with multiple names.
 |
| Figure 7.3A |
Although there can always be more said about imaging, partitioning structure, and file systems, for brevity this is as far as we will visit this topic in this chapter with some very notable exceptions in upcoming sections.
Property Lists
Before delving further into forensic analysis of Macintosh systems, it is important to have a solid understanding of property lists. Property lists, also referred to as plist files, are the greatest source of information for settings and configurations on Mac OS X. Property lists are often simple text files formatted in XML to be read on the system. Often they will contain text strings, Boolean values, and occasionally encoded binary data. Although these files can be examined using a text editor, it is most effective to view the hierarchical information in these files using an XML reader.
The only caveat to this is that in Mac OS X 10.4, the binary plist format became popular for a number of property lists. Although these binary files still contain XML data, they are not easily readable with the built-in viewers of some forensic tools. A free XML viewer that can be used to examine these files is plist Editor for Windows (www.ipodrobot.com), shown in Figure 7.4. This utility can be used to examine text plist files as well as binary ones, but may not display all the information in binary plist files in a usable format. Therefore, it is advisable to examine property list files using multiple tools to extract the most information.
User Accounts
During the course of any forensic analysis of a computer it is important to enumerate the user accounts on the system, and associate information with that user. Although it may be difficult to tie a person to an action without admission, it is much easier to tie an account to an action. For this attribution process, account enumeration is critical in any forensic analysis, and Macintosh OS X systems are no different. For account enumeration there are three critical pieces, user account information stored in the user database, the user's password(s), and user information on the volume.
Depending on the version of Mac OS X that is being used on the system, user account information will be stored in different locations and formats. It is important to realize what kind of system you are looking at before trying to identify users. The most current version of Mac OS X, 10.5, stores this information in flat files located off the root of the drive at /private/var/db/dslocal/. Mac OS X 10.2–10.4 stores this information in a different location and format. Individual Store files store account information in a proprietary database format as shown in Figure 7.5 and are located in the /private/var/db/netinfo/local.nidb/ folder.
 |
| Figure 7.5 |
Although these formats may look different as files, they carry the same types of information:
▪ Name, the name of the shell account.
▪ Realname, the name of the GUI account typically seen at login.
▪ User ID number (uid); user created accounts typically start from 501. This value can be useful for determining the owner of a specific file since the attributes of the file will generally contain the UID.
▪ Group ID number (gid), is typically similar to the uid in later versions of Mac OS X.
▪ Picture, which corresponds to a picture on the drive that can be used for user identification from the GUI logon process.
▪ Authentication_authority, defines the type of security used for the password. Basic indicates the password is held in the database, Shadowhash indicates the password is held in a separate file.
▪ Home, the main folder on the system associated with the user account. This folder contains the user's desktop folder, and is the default location for user created and downloaded files. In addition, user specific configuration information is stored under this folder.
▪ Shareddir, which folder is by default shared when file sharing is turned on.
▪ Hint, if any text was supplied to the hint field during account creation.
As the databases progressed, new fields were added:
▪ Generateduid, a UUID field that was specific to each user. This would distinguish individual users generated between machines.
▪ Home_loc, a field to specify the file to be used as the Home folder, established for FileVault.
▪ Mcx_settings, an array set up to define parental control privileges. This regulates what a person can and cannot do on an account; able to be set only for nonadministrative users.
▪ Jpegphoto, a base64 encoded version of the logon picture, may supercede the picture field.
The information stored in the Directory Service structure of Mac OS X 10.5 is much easier to read using Windows-based forensic tools than the NetInfo structure of Mac OS X 10.2–10.4.
To pull the same information on a Mac OS X 10.5 system simply read the individual files in the /private/var/db/dslocal/nodes/Default/users/. Each of the user accounts will have a file in this folder. Some documents will have an underscore to begin the filename; typically these are system default accounts used for normal operation of the system. User generated accounts will typically not have this to start their name but this is not an absolute rule. Each of these files is a standard XML formatted plist file that can be examined with a text editor and interpreted using a plist viewer.
To pull the information out of the NetInfo database on Mac OS X 10.2–10.4 systems, simply copy the text from the Store.# files located in the /private/var/db/NetInfo/local.nidb/ folder. With some forensic tools you can copy the ASCII text only out of the file; then that text can be read in a simple text editor. Alternately, export the entire file and run a strings tool against it to extract the ASCII text.
One exception when examining NetInfo formatted account details is that accounts with parental controls enabled will generally have to be examined in a different manner. In this situation, the mcx_settings file contains an XML data array that shows specifically what the account may or may not be allowed to do.
In additional to the information contained in the user account database, useful information is contained within the groups. The most notable is whether or not a user is a member of the administrator group. The accounts with administrative privilege in Mac OS X 10.2 through 10.4 are listed in the Store.# file containing the admin group definitions. For a Mac OS X 10.5 this information is stored in the admin.plist file under the /private/var/db/dslocal/nodes/Default/groups/ folder.
After retrieving the account information from the subject system, there are a few critical pieces of information to note. For each account note the password hash (Mac OS X 10.2), the UUID (Mac OS X 10.3–10.5), and the Home folder (or file). These details are useful for identifying and accessing files on the system that are associated with a particular user account.
User Account Passwords
In some cases, it may be desirable to know the password for a specific user account on a Macintosh system. For instance, if user areas are encrypted using FileVault, obtaining the user's password may provide access to the data of interest.
Login passwords for Mac OS X have had some evolution along with the rest of the operating system. In Mac OS X 10.2 the passwords were standard Unix-style eight-character passwords. Users could choose longer passwords, and there was an advantage to doing so, but the password required for login was truncated to the first eight. The hash for these passwords was saved in the traditional DES 128 format and a standard compilation of John the Ripper (www.openwall.com/john/) can crack these passwords with no alteration.
The password format and location changed in Mac OS X 10.3. Recall that this is the first version of Mac OS X that contains the UUID field for a user in the database. This UUID is needed to identify the password.
Starting with Mac OS X 10.3 the passwords were removed from the NetInfo database and stored instead in the /private/var/db/shadow/hash/ folder of the system drive. The files within this folder are exactly the same as the UUID numbers pulled from the system files. These files contain a 104-character value that appears to be an NTLM hash crammed onto the front of a raw SHA1 password. This format of password hash can be attacked in two ways. The first 64 characters can be split off and formatted for John the Ripper to crack like a traditional NTLM password. However, this approach will only give you the first 14 characters of the password used on the system. If the password is longer than 14 characters you may have to crack the last 40 characters using a patched version of John the Ripper that supports raw SHA1 password hashes. Before installing a patched version of John the Ripper that does raw SHA1 passwords, be aware that later versions of Mac OS X use salted SHA1 passwords, which requires an additional modification to Jack the Ripper.
With Mac OS X 10.4 and 10.5 the shadowed passwords are still in the same location and linked to users with UUID numbers, but the internal format of the files has changed. Instead of 104 characters, the file contains 1240 characters. Also the NTLM hash is no longer stored by default. The NTLM hash will be stored only if the user account is enabled to accept Windows-style SMB clients as a form of file sharing. If this was not enabled, then the NTLM password will be all zeros.
The exact breakdown of the new shadowed file is unknown, but the first 64 characters represent an NTLM password if available, and characters 169 through 216 represent the new stored SHA1 hash. Observe that this value is 49 characters, which is longer than the 40 characters in Mac OS X 1.3. This is because the password is now salted, which makes brute force attacks more difficult because now cracking one password will make no difference for any of the others, unlike unsalted passwords. If the logon password is necessary, then having a fully patched version of John the Ripper, or another password cracker may be helpful.
Jaguar_user:<value>:::
NTLM_user:<value>:<value>:::
Panther_user:<value>:::
TigerLeopard_user:<value>:::
Once the passwords are on their way to being cracked, the last part of account enumeration can be conducted. Listed in the user account record will be where the home location is on the drive. With this information, document analysis can begin for that folder, with the assumption that all the documents and saved information can be attributed to the user. Unfortunately, without a software tool that can both identify ownership of the files and folders, as well as the permissions associated with them, it is difficult to establish ownership definitively, but general practice indicates that a user will store their documents in the Home folder.
Applications
Normally, during the course of an analysis it is important to note the applications installed on the system. The flexibility of Mac OS X may make this seem much harder than in earlier Macintosh systems. There are two types of executables for Mac OS X, command line binaries, and GUI applications. Most of the command line binaries will be installed in the default /bin, /sbin, /usr/bin, /usr/sbin, and many others consistent with Unix default folders. It is possible for users to install their own binaries, but this is for a higher skill level and will be discussed shortly. Most of the GUI applications can be found in /Applications and /System/Library/Coreservices. Most of the applications the system uses that are without direct user initiated control are in /System/Library/Coreservices. Most of the applications that the user uses are stored centrally in /Applications.
The /Applications folder on the root of the drive is the default location to install applications for most installers, and the typical place that users will install applications as well. Because of the structure of applications for Mac OS X, those locations are limitless. The /Applications folder contains subfolders for each application instead of executables. This is the way Mac OS hides the data from the casual user and makes installation and removal very easy. This folder structure is one example of how Mac OS X makes use of application bundles. A bundle is a way to group all the necessary libraries and executable code in one place. Each bundle contains pictures, language resources, plug-ins, and possibly multiple types of executable code. This allows the user to always see the same icon and applications, and for the system to load the pieces that it needs to support the structure. To make a parallel, it is as if all the .DLL files for a Windows application were stored in the same location as the application but generally hidden from view.
For most applications this makes installation as easy as drag and drop, and uninstallation as easy as throwing a folder into the trash. Because the code is always kept in the folder with the executable, and the user typically sees only the main icon, these applications can be put anywhere. Besides the /Applications folder, it is also common to find applications folders in the Home folder of a user. This is one of the spaces where Mac OS X will look for an application when you try to open a document.
Application bundles will typically start with a folder that has the extension .APP and contains a folder inside called “Contents”. The Contents folder contains a number of resources, including a file called info.plist that contains some of the most important information that a forensic examiner can obtain regarding the application. This file will contain version information as shown in Figure 7.4, in addition to often listing the types of file extensions associated with it for use.
 |
| Figure 7.4 |
Binary executables may also be installed from additional sources. One way is to download the source code, then compile and install the program. This requires the installation of the developer's tools found typically in the /Developer folder on a drive. This usually advances the user level of the person on the system; a stop-gap for this can be to use one of the automatic application building frameworks available (e.g., fink or darwinports). Once installed on the system, these frameworks assist the user in building these binaries from source code. Many of these projects or binaries will create /opt or /usr/local folders, neither of which are standard on a Mac OS X system.
System
Outside of the user area are often some configuration files of how the system operates independent of each user. For instance, in Mac OS X 10.3 or higher versions, a master encryption password can be set for the computer by one of the administrative accounts and this master keychain is located in the /Library/Keychains/ folder. A number of other useful configuration files are summarized in this section.
The network setting is kept in various places for all versions of Mac OS X. It is always an XML property list but it can be very convoluted text. In Mac OS X 10.2 this is located at /private/var/db/SystemConfiguration/preferences.xml. In Mac OS X 10.3–10.5 it is located at /Library/Preferences/SystemConfiguration/preferences.plist. This file will contain all the networking settings for all the available interfaces, as well as different settings based on different locations. This file will also contain the name of the computer as Mac OS X sees itself, as shown here along with two Wi-Fi network connections used by this system sometime in the past.
<key>System</key>
<dict>
<key>ComputerName</key>
<string>Eoghan Casey's MacBook Pro</string>
<key>ComputerNameEncoding</key>
<integer>0</integer>
</dict>
<key>SSID_STR</key>
<string>Port Networks Public Wi-Fi</string>
<key>SecurityType</key>
<string>Open</string>
<key>Unique Network ID</key>
<string>286EFFBD-0341-4AE5-9004-D288DE898175</string>
</dict>
<dict><key>SSID_STR</key>
<string>belkin54g</string>
<key>SecurityType</key>
<string>Open</string>
<key>Unique Network ID</key>
<string>21B63E36-97DD-4843-A358-62FA6E84EF21</string>
If a user has changed the default workgroup for SMB sharing, that information will be stored in /private/etc/smb.conf for Mac OS X 10.2–10.4, and in /private/var/db/smb.conf for Mac OS X 10.5. Please note the location difference for Mac OS X 10.5 because there are multiple smb.conf files on the system; the one mentioned previously will have the workgroup if set, and the NetBIOS name if set by the system.
The built-in firewall settings are stored in the com.apple.sharing.firewall.plist file for Mac OS X 10.2 through 10.4, which is stored in /Library/Preferences/ in plain text for Mac OS X 10.2 and 10.3. For Mac OS X 10.4 this becomes a binary property list file. For Mac OS X 10.5 this becomes a bit trickier; the firewall settings are located in part at /Library/Preferences/com.apple.alf.plist but this will list only specific application exceptions in addition to some preconfigured exceptions. If any of the services are set to run in sharing they will get an automatic pass. The most important field relating to the firewall operation is the globalstate, which can be set to 0 for off, 1 for essential only, and 2 for specific settings.
To figure out which services referenced in the firewall configuration file are actually running, it is necessary to look in the /System/Library/LaunchDaemons/ folder and read through the configuration files. These configuration files control which services are set to run at startup and which are not. Specifically, services that are not configured to run will contain a Disabled field in their configuration .plist file. On older versions of Mac OS X, some .plist files for running services may be located in the /Library/Preferences/ folder.
Printing on Mac OS X is handled through the CUPS service and will leave behind trace files that indicate printing, similar to some versions of Linux as detailed in Chapter 6, “UNIX Forensic Analysis.” On Mac OS X, print spool files are located in /private/var/spool/cups and these files are named with a “c” and then five numbers starting sequentially with 00001. The file system dates of these files indicate when the associated file was printed. These files store useful information about each print job in a binary format, including the owner of the print job, the name of the print job, and details about the printer. Occasionally there may be files in this folder starting with a ‘d’ that contain a PostScript representation of what is being printed. These print spool files can be found on both the originating Mac OS X system and if there is one acting as the print server.
Logs
There is one more part of the system settings that deserves some mention. Many of the running processes and daemons will store log files. The most common locations for the system are /private/var/log/ and /Library/Logs/. Most log files are easy to attribute to their respective daemons, and are searchable for relevant information from your forensic tool suite. Unfortunately, many of these logs files are stored for a limited period of time, and some are stored for a limited amount of space on the drive. If these limitations are imposed upon log files, then they will typically be broken up into sequential versions and then rotated in order. They may be broken up by space or date—either way there are often multiple versions of a log file. Most of these log files are compressed with gzip or bzip2, requiring additional extraction before most forensic tool suites can search them for keywords. The compressed version of these logs may need to be extracted and expanded before being re-added to the forensic tool for text searches. Fortunately, once uncompressed, most of these log files are straight ASCII text and are easily searched.
Connection of External Devices
To understand the value and challenges of these logs from a forensic perspective, consider the mounting of external devices in Mac OS X. Every version of Mac OS X, 10.2 through 10.5, seems to log this information differently. The most commonly used log is the /private/var/log/system.log. In version 10.2 a log entry containing the line “autodiskmount” is recorded every time an external disk is mounted. The information logged includes the disk/slice, file system type, read/write status, volume name, and mount point for that volume. This behavior continues in 10.3, with a few exceptions. The process name has changed to “diskarbitrationd” so each log entry will have that name instead of “autodiskmount,” and log entries will contain UUID values as identifiers for external devices. The UUID values are unique to the volume if it is a Macintosh native file system, and a FAT volume will register as all zeros.
When external devices are attached to a Mac OS X system, a mount point is created in /Volumes that contains the volume name. Although such mount points are deleted after the device is removed, forensic examination may reveal their existence if they have not been overwritten. In one case, the subject of an investigation denied accessing a particular computer, but forensic examination showed that her iPod had been connected to the computer on a recent date.
There are fewer logs associated with external media in more recent versions of Mac OS X. In Mac OS X 10.4 the behavior is exactly the same as 10.3, but only for externally connected FireWire drives. Logs are no longer generated for USB connected drives. In Mac OS X 10.5 registering mount points for drives is dropped altogether. There is a workaround if Spotlight is running, since this application will occasionally try to update the file system identifier on a removable volume. This process is automatic and, if data on that volume was updated since last in a Mac OS X 10.5 machine, or the volume uncleanly unmounted, Spotlight will update the fseventsd information. This method has some issues though; it will not work if you have used that volume only in Mac OS X 10.5 machines or if no changes have be made to that volume since the last time it was put in that machine.
Additional logs that may provide information about connected external media are the fsck_hfs.log and the DiskUtility.log. Both can be found in the user's Library/Logs folder and a copy of the fsck_hfs.log can be found in the /private/var/log folder. The fsck_hfs.log will show anytime an HFS, HFS+, or HFSX volume was mounted. Unfortunately this log does not include the volume name, and does not distinguish between physical devices and disk images. Therefore, it is advisable to correlate information in fsck_hfs.log with either the system.log or the DiskUtility.log. The DiskUtility.log will show disk manipulations by the user through the Disk Utility or the helper application. This includes formatting disks, creating or mounting disk images, or burning optical discs.
Logon/Logoff Activities
Mac OS X systems have many of the same logs associated with logon/logoff activities on Unix systems as detailed in Chapter 6, “UNIX Forensic Analysis.” The secure.log found in /private/var/log can give an idea of not only user login and logoff activity, but also connection activity and security escalations through authenticated means. This log is always found in the same place, although in Mac OS X 10.2 it seems to not be used although a placeholder may exist.
Entries in secure.log can be referenced against the utmp, wtmp, or utmpx files on the Mac OS X systems. You can find the utmp and the successor utmpx in /private/var/run/ and the wtmp file in the /private/var/log/ folder. In Mac OS X 10.5 the wtmp log is replaced by the asl.db file and log in the asl folder both found in the /private/var/log/ folder. All of these log files are different kinds of binary files; these files have no native viewer on a Windows machine.
It is important to note that all log files tend to rotate and may even be deleted as part of normal operation. Otherwise treat all entries as sequential; this may be an issue if the machine has been turned on and off intermittently over a period of years.
Disk Images (and other Frameworks)
Disk image files on Mac OS X systems typically have a .DMG file extension, and they generally encapsulate a file system. There are a few common types of disk image files (uncompressed, compressed, and encrypted), and it can be challenge to deal with them inside of Windows-based forensic tools. Uncompressed disk image files can be extracted and then used as logical drives to be reinserted into your forensic tool suite. These can typically be added as if they were raw image files. Compressed disk images and encrypted disk images cannot be directly loaded into a forensic tool suite. A Mac OS X computer is needed to open these files. This issue applies to the implementation of FileVault on Mac OS X 10.3 through 10.5. In Mac OS X 10.3 and 10.4, FileVault disk images are represented as a .sparseimage file in the user's Home folder. In Mac OS X 10.5 this format was changed into a .sparsebundle, which helps integrate with their backup utility Time Machine.
It is possible to mount an encrypted sparseimage file using a Mac OS X examination system, provided you can obtain the password for the user account. However, this is not possible on a Windows system. An alternate approach to opening an encrypted disk image that contains a user's FileVault protected data is to boot a clone of the system and log in as the user. In this way, you can log onto the system as the user, thus decrypting the FileVault protected data.
The reason that these disk images could be found anywhere on the system is because they are supported by no one specific program on the system, but a series of libraries running in the background as a framework to support this document type throughout the system. Another example of frameworks on the system is the support for QuickTime. The QuickTime framework supports a lot of the media usage on the Mac OS X system, from the iLife applications to the screensaver. These frameworks can be seen on the system in the /System/Library/Frameworks/ folder. Typically frameworks are used as support for multiple applications and functions on the system so that applications can share them.
User Folders
User folders are areas where information may be stored by default or choice by a specific user while they operate Mac OS X. Although some targeted browsing of files may be used during the course of the investigation, much of the data in user folders will be encountered as a result of automated processes such as string searches or media reviews.
Before we start examining results of automated processes, there are a few important aspects of user folders to highlight. In Mac OS X 10.2 through 10.5 there are a few default folders that are created when a new account is created, some with default data. Some of these are not required for Mac OS X operation.
▪ Desktop: Folder where items on the desktop are placed, empty by default, required by all active accounts
▪ Documents: Empty, in version 10.5 has About Stacks.pdf in new accounts
▪ Downloads: Version 10.5 only has About Downloads.pdf in new accounts
▪ Library: Default data for Finder operation, required by all active accounts
▪ Movies: Empty
▪ Music: Empty
▪ Pictures: Empty
▪ Public: Contains a Drop Box folder with set permissions for sharing
▪ Sites: Default data for personal web sharing option
Only two folders are really necessary for using Mac OS X through the Finder; the others help with some of the additional functionality. Many of the empty folders are just suggested placeholders for those types of data, and are also the defaults for some of the Apple applications. Of course, users can create other folders, or remove these folders or store data anywhere on the drive. Even some default application behavior can be altered to save data in different locations. The notable exception is the Library folder. Many applications store their specific user data in the Library folder and cannot be set to a different location. This is where a great deal of information will be found as discussed in application-specific sections later in this chapter.
Similar to other user's folders, the Trash is in the user's Home folder. This is typ-ically a hidden folder that is named .Trash and can be accessed by the user. This will contain documents the user has thrown out and, unlike the Windows Recycle Bin, the original location of the file is not preserved. This is the behav-ior for the boot volume. On external volumes the behavior is different. Since there is no user folder on an external volume, the Trash is organized at the root in a folder name .Trashes. Inside this folder are numbered folders that respond to the UID of the user that moved an item to the Trash and has not emptied it yet. That UID corresponds to the user that was logged in at the time and on that system. Because the Trash subfolders do not map to the UUID, only the UID, it may not be safe to conclude that a particular file was deleted by a certain user account simply based on its location in the Trash of a remov- able disk. Although there may be two documents in the .Trashes/501 folder, they may have been thrown out by different users on different systems.
User Folders: Media Files
The popular iLife suite of applications stores the majority of the media files in default locations within a user's Home folder. The files from iDvd are stored in Documents, the files from iPhoto are stored in Pictures, the files from iMovie are stored in Movies, and the files from iTunes are stored in Music.
By default iTunes stores its database in one folder, but it can be set to store data elsewhere. iTunes has one large database made up of many small files in a hierarchical structure. This structure is very complex and changes within the different versions of iLife but the media files should be very easy to view. Some caveats to this are the purchased media files from iTunes; some may be protected media and therefore unplayable. The media contained within those files however should be easy enough to determine from iTunes. Within each file purchased from iTunes whether protected or not, it will list the purchaser information. This may not be true for MP3 songs purchased elsewhere.
Similar to iTunes, iPhoto will organize the photos with a hierarchical structure with reference to date of import. iPhoto has a few major differences in organization. It will make use of link files for categorization as well as keeping multiple copies of the files that the user edited, so that an original to which a user can revert is always available. It may seem to someone who is browsing the folder that there are multiple versions of the file, although the user may see only one version of the file.
Unlike iTunes and iPhoto, iMovie and iDvd create separate project folders to contain different data. These are stored in Movies and Documents, respectively. Each of these folders may contain support media files for use in the project. Each project file uses the raw media similarly to iPhoto preserving the original data while just referencing any changes until a final movie is exported. This is why some movie files contained within may not play—they are just placeholders with references. Look for similar action within the DVD project folders as well.
iMovie underwent a significant change at some point for 2008 and, instead of project-specific folders, there are two folders in the Movies folder, iMovie Events and iMovie Projects. The first stores the raw DVD footage imported into iMovie and the second stores the project files, caches, and output from individual events. This gives the user the ability to pull from all media imported to make any movie. This centralizing of files makes it similar to iTunes and iPhoto.
It is possible to move some of these libraries as well as generate media content in other places—these are just the most common areas. Applications in the iLife suite change frequently so these are just guidelines rather than specific instructions of how to deal with this media. Fortunately, the content of the media is generally more important in an investigation than other factors.
User Folders: Applications
The configuration of a particular application and the usage artifacts it leaves behind can be very important in a forensic investigation. Many applications on Mac OS X property lists store configuration details and usage information, both as self-contained files as well as embedded in other files. The Library/Preferences folder under a user folder contains property lists for many applications, including records of recent activities. For instance, the following entries were extracted from the com.apple.mail.search.plist file, showing when the user searched e-mail for particular keywords.
<key>nist</key>
<dict>
<key>IsForToDos</key>
<false/>
<key>ModDate</key>
<date>2009-06-17T00:38:09Z</date>
<key>RetypeAttempts</key>
<integer>1</integer>
<key>SearchField</key>
<string>Subject</string>
<key>UseCount</key>
<integer>3</integer>
</dict>
<key>owen</key>
<dict>
<key>IsForToDos</key>
<false/>
<key>ModDate</key>
<date>2009-06-09T14:23:53Z</date>
<key>RetypeAttempts</key>
<integer>2</integer>
<key>SearchField</key>
<string>From</string>
<key>UseCount</key>
<integer>4</integer>
</dict>
Knowing what an individual was searching for in e-mail at a particular time may be of interest, and forensic examiners may also want to examine the contents of e-mail. This is just one example of the types of information that applications store in property list files on Mac OS X systems.
In one intellectual property theft case the suspect denied having accessed the files of concern, which were stored on a file server within the organization. An examination of property lists on his computer revealed several references to recently opened filenames, including those of concern. The property list showed the full path of each file stored on the server.
More recent versions of Mac OS X store configuration and usage details in SQLite3 database format. Use of these small databases began in Mac OS X 10.4 and became very prevalent in 10.5. A large number of these small databases are used to store and sort data for a variety of applications. This marks a drastic departure from previous convention for many of these applications as well as making sifting data out of it difficult for those not familiar with SQL commands.
Fortunately, inexpensive, user-friendly Windows-based programs like SQLite Database Browser (http://sqlitebrowser.sourceforge.net/) are available to examine these files as shown in Figure 7.6.
Once a file is loaded in SQLite Database Browser, the first tab of Database Structure shows how the data are organized, but it is the second Browse Data tab that is of the most use for forensic examination. This interface can be used to select individual tables and examine the data they contain. Unfortunately, there is no easy way to dump the data all neatly cross-correlated so some work will have to be done either by hand or with the crafting of some SQL commands. This type of tool is necessary for reviewing many of the SQLite databases found on Mac OS X because these files are not currently interpreted by any forensic suite packages.
Safari
The most commonly used application on computers is probably the web browser. Safari is the default browser included with Mac OS X systems, starting with Mac OS X 10.3 (it was available as a separate download for 10.2). Different versions of this browser store data in different locations and formats, and this browser is also affected by which version of Mac OS X upon which it is installed. It seems that the same version of Safari will store the cache data in different locations between Mac OS X 10.4 and 10.5. Some of the configuration information remains the same and some of it is a natural evolution of storage.
Each version maintains a list of configuration preferences in the com.apple.Safari.plist file in the user's Library/Preferences folder. In addition, usage artifacts found on different versions of Mac OS X are listed in Table 7.1.
An example of data contained in a Safari History.plist file is provided in Figure 7.7.
In Mac OS X 10.2 through 10.4, each user folder has 15 subfolders under Library/Caches/Safari that each have 15 subfolders, all of which contain cached data from recent web pages accessed using Safari as shown in Figure 7.8.
 |
| Figure 7.8 |
In Mac OS X 10.5 the storage of web browser cache data changes in more than one variation. Some systems will still have cache files and folders in the previous location, but these are from an older version of Safari—either an older version in use on the system or the last time a previous version was used, leaving behind residual cache files. The first change the system made was to move the cache into a database originally located in the user's Library/Caches/com.apple.Safari folder. This was the Cache.db file, and it may still be present on systems. At some further point this file was moved to a centralized location in /private/var/folders. Here there will be a two-character folder owned by root that contains a subfolder named with a 28-character string. Inside those are different temporary folders. This appears to be the new temporary space for data as opposed to using /var/tmp on previous versions of Mac OS X. Inside the -Caches- folder are a number of subfolders containing cached data associated with various applications. Data associated with Safari is stored in a subfolder named com.apple.Safari, which includes the Cache.db file. Unfortunately the only way we can tie files cached by Safari back to a particular user account outside of content is through identification of permissions and ownership. This would be an issue for users who rely upon EnCase solely, since it does not display permissions associated with files on Mac OS X systems.
Two individuals in an organization were suspected of having an affair, which was against company policy. They were both careful not to contact each other directly using e-mail or other common communication applications on their computers. However, they did share a web-based calendar to coordinate illicit meetings. Unbeknownst to them, the full calendar was cached by Safari on their computers.
Also with the switch to Mac OS X 10.4 a new folder appeared in the user's Library/Caches/Metadata/Safari. The first is the Bookmarks folder, which contains cache files that represent the bookmarks listed in the Bookmarks.plist. This folder persists in Mac OS X 10.5 and an additional History folder is added. This also contains cache files of all the places that have been viewed by the user. This will take the place of the cache folders found in earlier versions in the user's Library/Safari folder.
Because of the extra data in cache files for Safari along with cache data not being held in SQLite databases, deleted web page cache may prove very hard to reconstruct or to associate with a user.
The next most popular application outside of the web browser is generally the e-mail client. On the Mac OS X this client is named Mail and also stores user-specific information in the user's Library folder. Configuration details for Mac Mail, including the e-mail accounts and location of associated mailboxes on the system are stored in the Library/Preferences/com.apple.mail file.
In all versions of Mac OS X 10.2 through 10.5 most of the mail data is stored in the user's Library/Mail folder with slight variations by Mail version. Unlike Safari, Mail updates with the OS so you will not find the same version of Mail on different versions of Mac OS X, unless someone went to the trouble of replacing the application.
Mail in Mac OS X 10.2 and 10.3 essentially operates the same way. The main folder contains a folder for each account and one named Mailboxes. Each account folder name starts either with Mac or the connection type in capital letters, followed by a username@server structure. Each folder that starts with POP contains a file of current downloaded messages listed by id and another folder, INBOX.mbox. The INBOX.mbox folder contains configuration files for presentation in the Mail application and at least one file of ASCII mail text, essentially one large block of text that contains all the e-mails concurrently. Each account folder that starts with IMAP or Mac (which is an IMAP account) has a slightly different structure. There are .imapbox folders that contain a CachedMessages folder, which lists all the messages as sequential numbers with subversions indicating multipart messages as shown in Figure 7.9. The Mailboxes folder that was mentioned earlier stores account independent messages, such as drafts or outgoing messages before they are associated with an account.
 |
| Figure 7.9 |
In Mac OS X 10.4 the format associated with Mail data changes slightly. The POP folders now follow a similar format to the IMAP listed earlier. The main folder contains an INBOX.mbox/Messages/ folder. The e-mail messages are contained within as sequentially numbered EMLX files. These are the same type as before, just now with an extension. These files are still ASCII text.
Mac OS X 10.4 also introduces two new files for functionality. The first is SmartMailboxes.plist, which will sort the messages based upon filtering criteria without actually creating real mailboxes. The other is the Envelope Index, an SQLite database that contains calendar, message subject, e-mail addresses, and other information for easy searching of the data in the Mail application.
In Mac OS X 10.5 this evolution continues with further integration being supported by more SQLite databases. The individual e-mail files still have the same structure as Mac OS X 10.4. One of the new databases replaces the individual files that track downloaded messages by collating it into one file. An available feeds database file is updated from Safari as possible RSS feeds that can be subscribed to from within the Mail application.
Address Book
The Address Book is another application that has embraced the SQLite and plist format for much of the data manipulation. For Mac OS X 10.2 through 10.4 the Address Book data was stored in the user's Library/Application Support/Addressbook/ folder in a file named Addressbook.data. This was a proprietary file format that could be easily read only with the Address Book application itself. This changed in Mac OS X 10.5, and the Addressbook.data file may still exist, but it is leftover data no longer updated.
In Mac OS X 10.5 two structures seem to replicate that data. The AddressBook-v22.abcddb is an SQLite database that contains all the data in the Address Book. Interestingly, the same data is replicated in the Library/Application Support/Addressbook/Metadata folder, storing the same data in individual files as shown in Figure 7.10A and Figure 7.10B. There is an .ABCDP file for each contact as well as each group in the Address Book. These files build (or rebuild) the SQLite database upon launch of the application. The SQLite database is then used for the quick searching and the integration into the Mail and iChat application for address searching. Each .ABCDP file is just a property list and can be opened easily with Plist Editor.
 |
| Figure 7.10A |
iCal
The default calendar application for Mac OS X is iCal. This application stores all the data in the user's Library/Calendars folder, except in version 10.4. In Mac OS X 10.2 and 10.3 each calendar was represented by a .ICS file with the name of the calendar in the user's Library/Calendars folder. These files can be read either as text or with a calendar application.
In Mac OS X 10.4 this schema changed. Now the information is stored in the user's Library/Application Support/iCal folder. This folder contains several .calendar folders that represent each separate calendar. The information about which calendar is which is specified in the info.plist file contained in each folder. The data is stored in the corestorage.ics file also located in that folder.
Additionally, each event is also stored in the user's Library/Caches/Metadata/iCal folder. These are also broken down into folders for each calendar as well, although they do not seem to correlate the UUID values that each folder has for a name. In the cache, subfolders are individual .icalevent files, which are binary plist files that can be viewed with Plist Editor with no issue.
Mac OS X 10.5 changes the data storage location back to the user's Library/Calendars folder. A new file Calendar Cache is an SQLite database file that shows all the calendars integrated into one file as shown in Figure 7.11. Each calendar still has an individual folder with an info.plist file to identify the calendar.
For each calendar there is an Events folder named with a UUID value that contains each event in the calendar broken down into individual .ICS files as shown in Figure 7.12.
It is possible to see older versions of the calendar information stored in Mac OS X 10.5, so do not be surprised if there is data in the user's Library/Caches/Metadata/iCal or Library/Application Support/iCal. However, keep in mind that this is often older data, and most likely not with what the user is currently interacting. Although this may seem confusing and add work, it does provide a glimpse to previous activity.
Wrap Up
Hopefully this overview will assist in clarifying some of the issues of analyzing Mac OS X artifact data on a Windows system. Some of the forensic suites have different strengths, but there is no counterpart to every Mac OS X data structure. Largely notable exceptions are any of the encrypted files that are built-in such as FileVault or Keychains. The good information is that many of the most common data storage file types, plist and SQLite3 databases, are easily viewable on Windows with the addition of some free tools. This should suffice for all but the most complex of investigations involving Mac OS X artifacts.
References
Casey, http://developer.apple.com/technotes/tn/tn1150.html (2004).
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.