Apple Property List: Comparing the Mac OS X Property List to the Windows Registry

First published April 2009

Dennis Browning
Champlain College
Burlington, VT


This paper will introduce the Property Lists in the Apple OS X and compare them to the Microsoft Windows Registry. Also within this paper we will examine how important some of the Property List can be to an examination. Examples of crucial information that can be found within Property List will be presented.


Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.

Let it be noted that this paper is by no means a complete look into the property lists and Mac OS X. All information looked at this in this paper has been the product of personal research. All opinions expressed in this paper are those of the authors.


The Importance of Plist Examinations

In 2007, Derrick Farmer, a Champlain College student, wrote a paper entitled “A Forensic Analysis of the Windows Registry”. This paper explored some of the key locations of where vital information could be found during a computer investigation. In Farmer’s paper, he explores areas of the registry pertaining to the location of autorun locations, recent items, wireless networks, Internet history, and 3rd party software that has been installed on a Windows machine. In today’s world, Macintosh (Mac) computers are becoming very popular. For this reason, it is important for forensic examiners to understand where they can find similar information in Mac OS X as they would find in Windows. Property Lists are very similar to that of the Windows Registry. These files contain information that can make or break a case. In this paper I will be comparing the Mac version to the Registry entries found in Windows.


First off, it is important to know what a Property List (plist) actually is, and the type of information that can be stored within them. Apple Developers describe the plist as follows, “property lists organize data into named values and lists of values using several object types. These types give you the means to produce data that is meaningfully structured, transportable, storable, and accessible, but still as efficient as possible” (Property List Programming Topics, 2008). Plists can be considered the “registry” for OS X. A little later we will explore the structure of a plist file. The information contained within these files is different for each program on the system. Each contains the settings for the program, which calls the plist. Similar to Windows Registry entries, if you change any value set in the file, the program will run differently. It should be noted that plist are not a Mac OS X item. They are actually found within Linux and Unix distributions.

Structure of Property List

Plists can take one of three different formats. The most recent, and more common, format one will see is the XML format. This format is more portable then that of the alternatives and can be edited manually where as the other two options are not. The other two formats are binary and ASCII. Binary formats are still used today but, one will rarely find an ASCII formatted plist. Binary formatted plists will perform faster if the plist is a large collection of data. Figure 1 below shows the XML formatted plist viewed using the program TextEdit, which comes installed on all Mac’s. It is obviously very hard to read in this format. If you were to open this same file in a plist editor one can clearly see the structure of the file better as seen in Figure 2.

Note: Click images to view full size

Figure 1 TextEdit

Figure 2 Plist Editor Pro

Plists can be composed of one or two forms of structured data, Core Foundation or Cocoa. Core Foundation is described as follows by Apple Developers, “Core Foundation is a procedural C framework that is conceptually modeled on the object-oriented Foundation framework in Cocoa and that uses the abstraction of the opaque type as a procedural analog to an object” (Getting Started with Core Foundation, 2006). Cocoa is described as follows by Apple Developers, “Cocoa is Apple’s name for the collection of frameworks, APIs, and accompanying runtimes that make up the development layer of Mac OS X” (Cocoa). For more information on Cocoa and Core Foundation, please refer to the links in the reference. Figure 3 below shows a table of the plist types and various representations.

Figure 3 Taken from:

Examination Tools

There are many different tools available to forensic examiners to use for plist examinations. The tools used in this paper to analyze and parse through the plist files are Fat Cat Software’s Plist Edit Pro and Echo One’s File Juicer. Plist EditPro has a free trial period that was used for this research and can be obtained from File Juicer also has a free trial period that was used for this research paper. File Juicer can be obtained from Both programs were fully functional during the trials.

Plist Examination

Plist as Logs

In most cases, data is only written to plists on the initial install of a program or when OS X is first installed. In all other cases plists are written each time a program is run. For the purpose of this paper, the plists that are being looked at are updated each time they are used. We will be looking at plist files related to the following: autorun locations, recent items, wireless networks, mounted devices, Internet history, and installed programs, as they relate to their Mac OS X equivalent locations.

Autorun Locations

Derrick Farmer defines autorun locations as “Registry keys that launch programs or applications during the boot process” (Farmer, D, 2007). This has a very similar meaning in the Mac world. On a Mac, the location of this information is in the loginitems.plist. An examiner should look at this location to see what programs or applications are of any evidentiary value to the case. For the most part, when someone installs a program on a Windows machine, the program has a default setting of starting on boot. For example, AOL Instant Messenger (AIM), when installed, will automatically start on start-up unless told otherwise. On the Mac side of installations, this is not as accurate. If one wants to have a program start on login/boot, they must tell the program to do so. It would be beneficial for examiners to look at the startup items, as it would be proof that the user of that Mac intended for the program to start on login/boot. The loginitems.plist can be found in the following location: /user/Library/Preferences/

Recent Items

In the Windows environment, the registry contains entries for Most Recently Used (MRU) list, and User Assist. The MRU is a list of recent programs and files accessed. Multiple lists are created throughout the registry. MRU’s are similar to the history that one can view in an Internet browser. The sites that have been most recently visited are kept in a list for the user to go back to if needed. In addition to the MRU, Windows has the UserAssist entry. This entry holds information about the most frequent programs used by a user. These entries are actually encrypted using the ROT-13 algorithm. To learn more about ROT-13, please visit the following site:

In the Mac environment, these lists are more limited. During the research for this paper, only one location could be found with recently open items. Within the /user/Library/Preferences/, the last 10 accessed applications, documents, hosts, and servers are listed. Within the settings for each section, a user can increase or decrease the amount of records that are kept. By default, Mac OS X keeps track of the last 10. Figure 4a below shows an entry into the applications section of the plist. Figures 4b and 4c show the most recent files opened and hosts connected to, respectively.

Figure 4a Most Recent Application Run

Figure 4b Most Recent File Opened

Figure 4c Most Recent Host/Computer Connected to

The information that can be found in this plist, unfortunately is only available as long as it been one of the last items opened in its respective section. Although, it can be beneficial for an examiner, if the user has only connected to a select few hosts.

Wireless Networks

In a forensic investigation, being able to determine if a suspect’s computer was connected to a wireless network could be of evidentiary value. The SSID or service set identifier is recorded for all wireless networks that are added to the users preferred network connections. This can include connections to Wi-Fi hotspots at Starbucks or similar hotspots. In the Windows Registry, SSID’s are stored in one key and the settings, such as the IP address, subnet mask and other information about a particular network is stored in another key. This is similar on a Mac. The two important plists to look at can be found at the following locations: /hd/Library/Preferences/SystemConfiguration/ and /hd/Library/Preferences/SystemConfiguration/ By using the two of these files together, an examiner can see the last date that the computer was connected to that network by looking at the For example, figure 5a shows the SSID of “3dd”. Also, you can see that the security type and password are shown. The password is hashed.

Figure 5a

Once the examiner has the timestamp found in the Airport Preferences plist, they can then go to the Network Identification plist. In there they will find the corresponding date on an entry to find out more information about the network including: DNS servers, IP address, the interface used (wired or wireless), subnet mask, and router IP. Figures 5b-5d show the information.

Figure 5b Timestamp Match to figure 5a

Figure 5c DNS servers connected to

Figure 5d IP address obtained, router IP and Subnet Mask

Based on the above information, an examiner can determine if or when a suspect was connected to a network. An examiner can use the DNS Servers to find out the Internet Service Provider (ISP) to which the suspect connected to the Internet with. Many ISP’s keep record of the hardware address that is obtaining an IP address from them. By getting a subpoena, an examiner can get log histories for the owner of the network.

Mounted Devices

USB devices and other mounted devices, such as CD/DVD installers, are almost an everyday occurrence now. A feature of the USB devices registry key found on a Windows machine is that the serial number for the USB device is recorded, making it easier to prove that a certain USB was connected to the suspect’s computer. Some USB devices don’t have a serial number so a random string is created in place of the serial number. On a Mac, this is not true. While a Mac does recorded that a USB device was connected to a machine, it does not record the serial number of that device. On the Mac, the plist /user/Library/Preferences/, shows all devices, whether it is a USB device, image, CD, DVD, or iPod, that are connected to the computer while logged in as a certain user. In this plist, the location of where the Finder opened the item is recorded under the FXDesktopVolumesPositions Key. The Finder is Mac’s version of Explorer in Windows. If a USB device or CD has an unique name, this plist is useful to show that at some point, the device was mounted on the suspect’s computer. In figure 6a you can see Volumes that were mounted. Volumes can include USB devices, CD’s, DVD’s, and iPods.

Figure 6a Volumes Mounted

When a user downloads a program on a Mac, a .dmg file is opened in order to install the program. This is equivalent to an installed .exe in Windows. On the Mac, these files are mounted in order for the user to see the install program. These files are also noted in this plist. Figure 6b shows an example of some .dmg files that have been mounted.

Figure 6b Software DMG’s

An examiner can use this list to see if software was ever downloaded onto the computer. For example, if an examiner is looking through a Mac to see if any kind of encryption software has been installed, it can be seen here that TrueCrypt was downloaded and mounted at some point. If the suspect says they have never looked into encryption software, the examiner can prove that they have.


In today’s music loving world, many people now have some form of MP3 player. With the advancement of technology, criminals are starting to hide information on iPods. On the Mac, the following plist can be informative to an examiner: /user/Library/Preferences/ With this file, the examiner can verify if an iPod has been connected to that computer. In figure 7 you can see that an iPod has been connected to the computer.

Figure 7 iPod Information /user/Library/Preferences/

With the information found in the above plist, an examiner can check the serial number to an iPod to see if it has been connected. If, in a case, a suspect states that they do not have an iPod, this file can show that an iPod has been used. The connected date shown above, shows the last date the iPod was in use on the suspects computer. The examiner can also prove how many times the iPod has been connected to that computer by the use count variable shown above.

Internet History


Safari is the native Internet browser on a Mac. This is similar to Internet Explorer on a Window’s machine. In Windows, the Internet Explorer Registry key has three subkeys, which include: main, typedURLs and download directory. On a Mac, Safari has a similar setup. Plists related to browsing history, download history, and cookies, each have their own location. In Internet Explorer, temporary internet files are stored as cache files, which is similar in Safari. These file are located in /user/Library/Caches/Safari. Using File Juicer, an examiner can view the contents of the caches files. File Juicer will take the Cache.db file found in the locations previously mentioned and parse through it, breaking cached items into folders of similar extensions. Figure 8a shows the folder created once File Juicer has processed the cache’s data.

Figure 8a File Juicer Results

The above listed index.html file, is a webpage created by File Juicer that contains all images found in the Safari Cache. This program makes it easier for an examiner to parse through potential evidence.

Another great place to look for evidence is the browser history. The plist found at /user/Library/Safari/History.plist provides an examiner with the Safari browser history. Figure 8b shows an example of the record in the plist.

Figure 8b Browser History

From the information found in this entry, an examiner can tell that the user visited this site nine times. The value found in lastVistedDate is formatted in absolute time and date. This can easily be converted using a program such as CFAbsoluteTimeConverter. This program can be downloaded from the following link: All that needs to be done is copy and paste the value into the program. The above value is converted to tell the examiner that the page was last visited on Sunday 07 September 2008 10:41:04 am. Time and dates are always great supporting evidence to help prove a suspect committed an act.

The downloads.plist file is another file for the examiner to look at for evidentiary information. This file provides an examiner with files that were downloaded using Safari. This plist can be found in the /user/Library/Safari/ directory as well. When looking at the information found in this plist, an examiner can prove that a program, such as Limewire, has been downloaded on the suspects computer. Figure 8c shows the entry in the downloads.plist that can prove that Limewire was indeed downloaded.

Figure 8c Download.plist

These files are great places to look for evidence. In Safari 3.2.1, similar to Internet Explorer 7, users can now clear all cookies, download history, cache, and all the great information examiners look for. If the user is smart enough to do this, the above plists get cleared and are of no use to an examiner.


When looking at alternative web browsers, such as Firefox, Opera, and Netscape, on a Windows machine, the information is recorded differently. On a Mac, this is similar. Since Firefox is not the native browser, information is stored differently. This folder can be found at /user/Library/Application Support/Firefox/Profiles. An examiner can take the profile folder and run it through File Juicer. File Juicer will again parse through all the files and provide the examiner with a folder with items in their respective folders. One difference here is when a user tells Firefox 2.0 or higher to clear its history, caches, etc., the typed URL’s are not cleared. A list of these URL’s can be found in File Juicer’s subfolder named URLs. If an examiner looks at the HTML page created, they will see a list of all URL’s that the enter key has been hit for. An example can be found in figure 8d.

Figure 8d URL’s

Other browser, such as Opera and Netscape, are similar to Firefox. They have a folder in the application support, which can be found to contain all information needed.


Similar to the Windows world, when a user installs a program, a folder is then created for that piece of software. In Windows, the folder is usually created in the program files folder, and contains executable and other important files. Some files may also be placed in other directories. On a Mac, the executable is placed in the applications folder, and all other important files needed to run the program are placed in the application support folder found at /user/Library/. In Windows, for the most part, when a user uninstalls a program, all files and folders related to that program are subsequently deleted as well. On a Mac, this is not true. When a user uninstalls or deletes a program, all they are doing is removing the executable from the applications folder. The application support folder will still contain all of the files associated with that program. The examiner can now go in and see what programs have been installed on the machine even if the program has been deleted.

Just to show what some of the information that can be found in the application support folder, we will take a look at the folder for the program Adium. Figure 9a shows the Adium Folder.

Figure 9a Adium Application Folder

An examiner should be interested in the usernames that are associated with an instant messaging program like Adium. When the users folder is opened, the default user is the only one listed. When that folder is opened, an examiner has access to all of the settings and accounts that have been setup. Figure 9b shows the account setup under the default user account.

Figure 9b AIM user account

With the program Adium, a user can setup accounts for Facebook, MSN, Jabber, Yahoo and many others. If a user has setup multiple accounts, they would all be listed in the account.plist.

Within this user’s folder, there is another folder for logs. This log folder contains chat logs for every screen name the user has talked to. The chat logs are formatted as XML sites. Figure 9c shows part of a chat log.

Figure 9c Chat log

An examiner can use these logs to see the time and date of when a message was sent. Also by looking at the above figure, the examiner can see the user who sent the message and if the user has setup an alias for the screen name they are talking to.


The following list includes all of the plist entries that were discussed in this paper.

– /user/Library/Preferences/
– /user/Library/Preferences/
– /hd/Library/Preferences/SystemConfiguration/
– /hd/Library/Preferences/SystemConfiguration/
– /user/Library/Preferences/
o FXDesktopVolumesPositions Subkey
– /user/Library/Preferences/
– /user/Library/Caches/Safari
– /user/Library/Safari/
o History.plist
o Downloads.plist
– /user/Library/Application Support/Firefox/Profiles
– /user/Library/Application Support/Adium 2.0/Profiles


With the growing popularity of Mac’s in today’s technological world, it is important that Forensic Examiners have the knowledge of the location of potential evidentiary information on a Mac. Having a basic knowledge of the Mac OS X file structure and Linux file structure will only help an examiner comprehend what they are looking at. By knowing where the information is and how to interpret that information, an examiner can be confident when going into an investigation that involves a Mac. The files discussed in this paper are only a few of the many possible evidentiary locations that an examiner should look at.


Cocoa. (n.d.). Retrieved April 5, 2009, from
Farmer, D. (2007.). Computer Forensics – A Forensic Analysis Of The Windows Registry. Retrieved March 1, 2009, from
Fat Cat Software – PlistEdit Pro. (n.d.). Retrieved March 6, 2009, from
Getting Started with Core Foundation. (2006, November 7). Retrieved April 5, 2009, from
Hsoi’s Shop: Software . (n.d.). Retrieved April 5, 2009, from
Mac OS X Manual Page For plist(5). (2003.). Retrieved March 6, 2009, from
Property List Programming Guide: About Property Lists. (2008.). Retrieved March 6, 2009, from
Property List Programming Topics for Core Foundation: Introduction to Property List Programming Topics for Core Foundation. (2008.). Retrieved March 6, 2009, from
Read Me – File Juicer for Mac OS X. (2008, December 30). Retrieved March 2, 2009, from
ROT13 – Wikipedia, the free encyclopedia. (n.d.). Retrieved April 5, 2009, from
(2008). Mac OS X, iPod, and iPhone Forensic Analysis DVD Toolkit. US: Syngres


Below you will find a table showing the Windows Registry Key location and the Mac OS X plist location of the information discussed in this paper.


Info Windows Mac OS X
AutoRun -HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
-(ProfilePath)\Start Menu\Programs\Startup
Recently Items -HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
Wireless -HKLM\Software\Microsoft\WZCSVC\Parameters\Interfaces
USB & Mounted Devices -HKLM\System\ControlSet00x\Enum\USBSTOR
Native Browser -HKCU\Software\Microsoft\Internet Explorer
-HKCU\Software\Microsoft\Internet Explorer\Main
-HKCU\Software\Microsoft\Internet Explorer\TypedURLs
-HKCU\Software\Microsoft\Internet Explorer\Download Directory
Software -HKCU\Software\ /user/Library/Application Support

Leave a Comment

Latest Articles