NAVAL

POSTGRADUATE

SCHOOL

 

MONTEREY, CALIFORNIA

 

 

 

THESIS

 

Text Box: MEMORY FORENSICS AND THE MACINTOSH OS X OPERATING SYSTEM

by

Charles B. Leopard

June 2015

Thesis Advisor: 	Michael McCarrin
Co-Advisor: 	Neil Rowe

Distribution authorized to U.S. Government Agencies only. (Test and Evaluation) (May 8, 2015). Other requests for this document shall be referred to President, Code 261, Naval Postgraduate School, Monterey, CA 93943-5000 via the Defense Technical Information Center, 8725 John J. Kingman Rd., STE 0944, Ft. Belvoir, VA 22060-6218.


THIS PAGE INTENTIONALLY LEFT BLANK



REPORT DOCUMENTATION PAGE

Form Approved OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington DC 20503.

1. AGENCY USE ONLY (Leave blank)

 

2. REPORT DATE 

June 2015

3. REPORT TYPE AND DATES COVERED

Master’s Thesis

4. TITLE AND SUBTITLE 

MEMORY FORENSICS AND THE MACINTOSH OS X OPERATING SYSTEM

5. FUNDING NUMBERS

 

6. AUTHOR(S)  Charles B. Leopard

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Naval Postgraduate School

Monterey, CA  93943-5000

8. PERFORMING ORGANIZATION REPORT NUMBER   

9. SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES)

N/A

 

10. SPONSORING/MONITORING

    AGENCY REPORT NUMBER

11. SUPPLEMENTARY NOTES  The views expressed in this thesis are those of the author and do not reflect the official policy or position of the Department of Defense or the U.S. Government.  IRB Protocol number ____N/A____.

12a. DISTRIBUTION / AVAILABILITY STATEMENT 

Distribution authorized to U.S. Government Agencies only. (Test and Evaluation) (May 8, 2015). Other requests for this document shall be referred to President, Code 261, Naval Postgraduate School, Monterey, CA 93943-5000 via the Defense Technical Information Center, 8725 John J. Kingman Rd., STE 0944, Ft. Belvoir, VA 22060-6218.

12b. DISTRIBUTION CODE

 

13. ABSTRACT (maximum 200 words)

Memory acquisition is essential to defeat anti-forensic operating system features and investigate advanced cyber-attacks that leave little or no evidence on physical storage media. The forensic community has developed tools to acquire physical memory from Apple’s Macintosh computers. Unfortunately, many forensic examiners rely on the tools without understanding how they function and without testing their performance or evaluating their ability to successfully recover forensic artifacts from the memory captures.

This thesis presents results of testing conducted with three prominent OS X memory-acquisition tools. Our research assesses the risk of system crash during memory acquisition, analyzes the performance of memory-acquisition tools, provides insight into the valuable forensic artifacts residing in volatile data and advances the state of knowledge on how best to handle volatile data on Macintosh computers. We find that, though all tools tested were able to capture system memory in most cases, the open-source memory-acquisition tool OSXPmem outperforms its proprietary counterparts in terms of reliability and support for all memory configurations and versions of the OS X operating system tested.

14. SUBJECT TERMS

Macintosh computers, OS X, memory acquisition, memory analysis, memory forensics, FileVault,

15. NUMBER OF PAGES

84

16. PRICE CODE

17. SECURITY CLASSIFICATION OF REPORT

Unclassified

18. SECURITY CLASSIFICATION OF THIS PAGE

Unclassified

19. SECURITY CLASSIFICATION OF ABSTRACT

Unclassified

20. LIMITATION OF ABSTRACT

 

UU

NSN 7540-01-280-5500                                                                                                                           Standard Form 298 (Rev. 2-89)

                                                                                                                                                                  Prescribed by ANSI Std. 239-18


THIS PAGE INTENTIONALLY LEFT BLANK


Distribution authorized to U.S. Government Agencies only. (Test and Evaluation) (May 8, 2015). Other requests for this document shall be referred to President, Code 261, Naval Postgraduate School, Monterey, CA 93943-5000 via the Defense Technical Information Center, 8725 John J. Kingman Rd., STE 0944, Ft. Belvoir, VA 22060-6218.

 

 

MEMORY FORENSICS AND THE MACINTOSH OS X OPERATING SYSTEM

 

 

Charles B. Leopard

Civilian, United States Secret Service

 

 

Submitted in partial fulfillment of the

requirements for the degree of

 

 

MASTER OF SCIENCE IN CYBER SYSTEMS AND OPERATIONS

 

from the

 

NAVAL POSTGRADUATE SCHOOL

June 2015

 

 

 

 

Author:                       Charles Leopard

 

 

 

Approved by:             Michael McCarrin

Thesis Advisor

 

 

 

Neil Rowe

Co-Advisor

 

 

 

Cynthia Irvine

Chair Cyber Academic Group


THIS PAGE INTENTIONALLY LEFT BLANK


 

ABSTRACT

Memory acquisition is essential to defeat anti-forensic operating system features and investigate advanced cyber-attacks that leave little or no evidence on physical storage media. The forensic community has developed tools to acquire physical memory from Apple’s Macintosh computers. Unfortunately, many forensic examiners rely on the tools without understanding how they function and without testing their performance or evaluating their ability to successfully recover forensic artifacts from the memory captures.

This thesis presents results of testing conducted with three prominent OS X memory-acquisition tools. Our research assesses the risk of system crash during memory acquisition, analyzes the performance of memory-acquisition tools, provides insight into the valuable forensic artifacts residing in volatile data and advances the state of knowledge on how best to handle volatile data on Macintosh computers. We find that, though all tools tested were able to capture system memory in most cases, the open-source memory-acquisition tool OSXPmem outperforms its proprietary counterparts in terms of reliability and support for all memory configurations and versions of the OS X operating system tested.

 

 


THIS PAGE INTENTIONALLY LEFT BLANK


TABLE OF CONTENTS

I.             INTRODUCTION....................................................................................................... 1

II.            background and LITERATURE review................................................... 5

A.           motivations for memory analysis............................................. 5

1.            Macintosh OS X Memory Artifacts................................................ 6

2.            FileVault2 Full Disk Encryption..................................................... 6

3.            Keychains........................................................................................... 8

4.            Encrypted Virtual Memory.............................................................. 9

5.            Secure Erase................................................................................... 10

B.           Basics of memory in os x................................................................ 10

1.            System Address Map.................................................................... 10

2.            Memory Compression................................................................... 13

C.           OS X Memory acquisition and analysis.................................. 14

1.            Hardware-Assisted Memory Acquisition.................................. 14

2.            OS X Memory Software Acquisition Tools.............................. 15

3.            How Software Acquisition Tools Work.................................... 15

4.            OS X Memory Analysis Tools...................................................... 17

5.            Mitigating Anti-forensic Techniques......................................... 18

III.           METHODOLOGY FOR TESTING  MEMORY-ACQUISITION TOOLS.......... 20

A.           OS X memory capture Tools To be Tested......................... 20

B.           Experiment 1: testing TOOLS’ ability to successfully capture memory....................................................................................................... 20

C.           Experiment 2: Locating filevault2 encryption keys. 23

D.           Experiment 3: determining how memory changes over time         24

E.           experiment 4: ComparING the memory captures taken with tools to VM Memory Snapshots and to one another...................... 25

F.           experiment 5: Testing memory-acquisition tools in a non-virtual environment.......................................................................................... 26

IV.          RESULTS OF Memory-acquisition tool testing............................. 29

A.           Experiment 1: testing TOOLS’ ability to successfully capture memory....................................................................................................... 29

1.            Evaluation Criteria 1: Obtaining a memory dump without crashing the system............................................................................................................. 30

2.            Evaluation Criteria 2: measuring memory footprint and memory-acquisition speed................................................................................................. 31

3.            Evaluation Criteria 3: verifying validity of the memory dumps and inspecting content for standard forensic artifacts..................................... 32

a.            ANALYSIS OF CAPTURES WITH VOLATILITY.......... 33

b.           ANALYSIS OF CAPTURES WITH REKALL................. 33

B.           Experiment 2: Locating filevault2 encryption keys. 33

C.           Experiment 3: determining how memory changes over time         34

D.           experiment 4: ComparING the memory captures taken with tools to VM Memory Snapshots and to one another...................... 44

1.            Comparing the Memory Captures taken with Tools to the VM Memory Snapshots........................................................................................ 44

2.            Tool Memory captures compared to one another................. 49

E.           experiment 5: memory-acquisition tools tested in non-virtual environment.......................................................................................... 53

V.           CONCLUSIONS AND RECOMMENDATIONS  FOR FUTURE RESEARCH 62

A.           SUMMARY OF MEMORY acquisition RESULTS........................... 62

B.           Problems of MEMORY ACQUISITION............................................. 64

C.           Recommendations for future work..................................... 65

appendix............................................................................................................................ 67

A.           BUILDING A TRUSTED TERMINAL ON A USB DEVICE.................. 67

B.           COLLECTING VOLATILE DATA WITH TRUSTED USB................... 68

List of References.................................................................................................... 70

initial distribution list.......................................................................................... 74

THIS PAGE INTENTIONALLY LEFT BLANK


LIST OF FIGURES

Figure 1.           FileVault2 Prompt during Installation......................................................... 8

Figure 2.           4th Generation Intel Core Processor Address Map [16, p. 23]............... 12

Figure 10.        User’s Login Password Located in Memory............................................ 34

Figure 11.        Activity Monitor Showing Processes Running on VM.......................... 35

Figure 12.        Match Percentage of 4 KiB blocks in VM Snapshots............................ 36

Figure 14.        Left: SV0 compared with SV10. Right: SV0 compared with SV15...... 38

Figure 15.        Left: SV0 compared with SV20. Right: SV0 compared with SV30...... 39

Figure 17.        OSXPMem Terminal Output of Memory Captured from VM................. 43

Figure 18.        Comparison of VM Snapshot SV1 and MacQuisition Memory Capture MV0           45

Figure 19.        Comparison of VM SnapShot SV1 and OSXPmem Memory Capture OV0  47

Figure 20.        Comparison of VM SnapShot SV1 and RECON Memory Capture taken at RV0    48

Figure 21         Comparison of Capture MV0 taken with MacQuisition and OV0 taken with OSXPmem   50

Figure 22.        Comparison of Capture MV0 taken with MacQuisition and RV0 taken with RECON        51

Figure 23.        Comparison of Capture OV0 taken with OSXPmem and RV0 taken with RECON            52

Figure 24.        Match Percentage of 4 KiB Blocks (excluding nulls) of Memory Captures from Mac Mini......................................................................................................................... 54

Figure 25.        Left: comparison of MacQuisition Memory Captures MM0 and MM2.5 minutes; Right: comparison of captures MM0 and MM30................................................. 55

Figure 26.        Left: comparison of OSXPmem Memory Captures OM0 and OM2.5; right: comparison of captures OM0 and OM30............................................................................ 57

Figure 27.        Left: comparison of RECON Memory Captures RM0 and RM2.5; right: comparison of captures RM0 and RM30............................................................................ 59

 


THIS PAGE INTENTIONALLY LEFT BLANK


LIST OF TABLES

Table 1.             Rekall Plugins used in Experiment 1....................................................... 22

Table 2.             Volatility Plugins used in Experiment 1................................................... 22

Table 3.             Snapshot Naming Convention.................................................................. 25

Table 4.             Memory-acquisition Tool Success Rates................................................. 30

Table 5.             Summary of Tool Memory Footprint and Time to complete Capture... 31

Table 6.             Size of Physical Memory Captures........................................................... 63

 

 


THIS PAGE INTENTIONALLY LEFT BLANK


LIST OF ACRONYMS AND ABBREVIATIONS

DMA                           Direct Memory Access

DMI                             Direct Media Interface

DRAM                        Dynamic Random Access Memory

EFI                              Extensible Firmware Interface

ELF                             Executable and Linkable Format

E01                             Expert Witness Format

GiB                             Gibibyte, 230 bytes

KiB                              Kibibyte, 210 bytes

ME                              Management Engine

MiB                             Mebibyte, 220 bytes

PCI                             Peripheral Component Interface

RAM                           Random Access Memory

TOLUD                       Top of Low Usable DRAM

TOUUD                      Top of Upper Usable DRAM

TSEG                         Top Segment (of main memory)

VM                              Virtual Machine

 

 


 

THIS PAGE INTENTIONALLY LEFT BLANK

 


ACKNOWLEDGMENTS

I would like to thank Michael McCarrin for his expert guidance and direction on this project. Professor McCarrin provided valuable support and suggestions, and he skillfully kept me on track when I drifted off course.

I also would like to thank Dr. Neil Rowe for his comments and guidance on this project.  This work is much better thanks to his mentorship.

In addition, I would like to thank Michael Cohen, Johannes Stuttgen, and Andrew Case for their work in memory forensics and their willingness to provide detailed explanations to my questions.

 

 

 


 

THIS PAGE INTENTIONALLY LEFT BLANK

 


I.             INTRODUCTION

Cyber criminals continually expand their capabilities as well as their ability to conceal malicious activity. Though emerging technologies and anti-forensic features of current operating systems may provide benefits to non-malicious users, such as added privacy protection, they have also aided cyber criminals and increased the difficulty of investigating cybercrimes. To counter the efforts of these criminals, computer forensic examiners must adopt and develop new techniques and tools.

Recent Macintosh OS X operating systems, including Mavericks (10.9) and Yosemite (10.10), incorporate many anti-forensic features that were unimaginable a decade ago. Users have the ability to fully encrypt the operating system volume, making it impossible to recover forensic evidence in a reasonable time frame without the user providing their login password. A user also has the ability to conceal evidence by creating encrypted custom-sized volumes located anywhere on the operating system volume. These encrypted volumes may use different passwords other than the user’s login password. Other features include encrypted virtual memory, the ability to encrypt connected devices, and the option to securely erase free space as well as the contents of the Trash Bin.

Traditionally, computer forensic examiners followed a straightforward approach to acquiring forensic evidence. Examiners would simply “pull the plug” to power off computer systems that were to be acquired, remove the secondary storage, and analyze it. For many years, such an acquisition was the only means to acquire computer forensic evidence. The approach captures every byte of non-volatile evidence, is repeatable, and does not modify any evidence. The advantages of a traditional acquisition, also known as a dead acquisition, have allowed it to be widely accepted by Federal and State courts [1].

Anti-forensic features of current operating systems have led many computer-forensics examiners to consider different methods of acquiring forensic evidence. The most significant difference between the traditional approach and newer methodologies involves the acquisition of main memory and other volatile data from live systems. Memory forensics, a relatively new and emerging field of digital investigations, allows for the recovery of encryption keys, network packets, injected code, hidden processes and communications from volatile memory [2]. In addition, memory-resident viruses may only be discernible by memory analysis [3].

The memory acquisition process involves the use of hardware or software to acquire the contents of physical memory, also known as Random Access Memory (RAM).  While there are numerous memory-acquisition tools and analysis programs for Windows operating systems, there are only a few for current Macintosh OS X operating systems despite their growing market share. The acquisition of physical memory from OS X operating systems is intrinsically more complex than acquiring non-volatile data, and presents risks including the loss of evidence. Despite the risks, the success of many investigations is dependent on capturing and analyzing this data. Unfortunately, many forensic examiners blindly rely on the tools without an understanding of how the tools function, without testing their performances or evaluating their ability to successfully recover forensic artifacts from the acquired memory captures.

The purpose of this research is to test the available memory-acquisition tools designed for use with Macintosh OS X operating systems. Investigators need to know the reliability of the tools and risks of using them, such as crashing the system. Our work tests the success rates of the tools based on whether they are able to acquire memory without crashing a system and whether they capture forensic artifacts. We also study the block-level fidelity of memory capture tools by comparing them against a baseline constructed from VMWare snapshots, and evaluate whether observed variations affect the examiner’s ability to obtain forensic evidence. This analysis has the added benefit of providing investigators with an understanding of how memory is changing over time as well as the effects memory-acquisition tools have on the memory dumps they acquire.


 

 

THIS PAGE INTENTIONALLY LEFT BLANK

 

II.           background and LITERATURE review

There is a significant amount of published research on memory acquisition and analysis for Windows operating systems. Far less research is available on the current Macintosh operating systems; however, many of the methods of memory acquisition and analysis of Windows systems also apply to Macintosh systems.

A significant portion of research on the acquisition and analysis of memory from Macintosh operating systems has been done by The Volatility Foundation, which is responsible for the Volatility Framework. The Volatility Framework is an open-source tool, written in Python, that aids in the analysis of acquired memory captures. The tool was first released in 2007 and initially only provided support for Windows memory captures. In October 2013, with the release of Volatility 2.3.1, support was provided for the Macintosh OS X operating system [4].

In 2014, the developer of the Volatility Project and various contributors co-authored The Art of Memory Forensics, which provides a wealth of information pertaining to Macintosh OS X memory forensics [2]. Another significant resource regarding OS X memory forensics is the Rekall Memory Forensic Framework. This framework originally began as a branch within the Volatility Project and became a stand-alone project in December 2013 [5].

A.           motivations for memory analysis

This section discusses the importance of memory analysis—from the treasure trove of forensic artifacts that can only be recovered from memory, to its important role in locating evidence that was once easily accessible but is now protected by anti-forensic features. These features, such as FileVault2, have greatly reduced the feasibility of recovering forensic artifacts through traditional forensic post-mortem analysis alone.

1.            Macintosh OS X Memory Artifacts

The contents of random-access memory (RAM) may include encryption keys, full-content network packets, malware, hidden processes, and remnants of communications and other files [2]. Many artifacts are either difficult to obtain or outright unavailable if the RAM is excluded from forensic analysis. Ligh et al. demonstrate the effectiveness of OS X memory forensics by analyzing OS X processes and network artifacts [2]. Their work also discusses how to search for malware and how to trace user activity by examining application remnants stored in memory.

The study of malware and network data present two particularly compelling use cases for memory forensics. The advanced threat landscape includes memory-resident viruses and ephemeral in-memory malware. According to Roberts [3], many of the current sophisticated threats do not exist on disk; rather they reside only in memory.  Without analyzing the memory, these threats cannot be discovered.

Network communications travel through physical memory before arriving at their destination and remain in memory until they are overwritten. As a result, full-content network packets are located within the physical memory. A memory capture may contain several minutes of full network content or less depending on the size of physical memory and its usage. In addition, network communications from previous sessions may also be recovered [6].

2.            FileVault2 Full Disk Encryption

Since the launch of Macintosh OS X 10.7 (Lion), Apple has provided the ability to encrypt the entire volume containing the operating system. Apple describes the feature, named FileVault2, as full-disk XTS-AES 128bit encryption “to help keep your data secure” [7]. In reality the full disk is not encrypted since the recovery partition and the Extensible Firmware Interface (EFI) partition are not encrypted. However, enabling this feature may be sufficient to defeat traditional post-mortem forensic analysis if the analyst is unable to recover the key.

Beginning with OS X Yosemite (10.10), the installation program asks the user whether they would like to encrypt the disk. Without any user input, the default behavior is to select the option to enable FileVault2 and to store the password in the user’s iCloud account, as shown in Figure 2. For this reason, more users are likely to use FileVault2 [8]. Previously, a user would have to go to System Preferences and manually enable it.

When FileVault2 is enabled, the firmware loads code from the recovery partition and displays a user interface. The recovery partition contains the EncryptedRoot.plist.wipekey file that, with the user’s password or recovery token, unlocks the volume master key [9]. Once the volume’s master key is unlocked, the OS X operating system stores the key in physical memory. This allows the operating system to retrieve and write data to disk without need to derive the key every time the disk is accessed [9]. Choudary et al. determined that the volume master key can be extracted from physical memory using a GNU debugger [9], demonstrating that the encryption can be broken by a forensic examiner with access to the contents of memory.

 Figure 1.       FileVault2 Prompt during Installation

Passware, a maker of password recovery and e-Discovery software, sells a Passware Password Recovery Forensic Kit that automates the process of decrypting FileVault2 disks by extracting the key from a memory capture. Passware’s product can also recover user login passwords as well as passwords from encrypted keychains [10]. Because the product relies on analysis of a memory dump, Passware’s success is dependent on the ability of memory-acquisition tools to successfully acquire a memory capture containing the encryption keys. Conversely, the successful recovery of a key using their product is an indication that memory was correctly captured. We take advantage of this fact in our testing methodology (see Chapter 3).

3.            Keychains

The Macintosh OS X Keychain Access is a utility that allows a user to track and remember multiple passwords, certificates, keys, and secure notes. All passwords for a user are unlocked upon a successful logon. Unlike Windows operating systems, OS X does not have registry files to store Internet and frequently-used passwords such as wireless network credentials. The Keychain utility is the Macintosh OS X’s answer for storing frequently used passwords. Users may also create and store custom Keychains using the Keychain Access utility. Custom Keychains have a separate password and are not unlocked at logon time. In addition, custom Keychains can be stored anywhere, including on external devices.

Ligh et al. [2] demonstrated how memory analysis techniques can be used to successfully recover keychain passwords as well as passwords used by OS X applications. The login.keychain file is located in physical memory and holds encryption keys. Using an OS X memory analysis tool, the encryption keys can be extracted from the login.keychain file. Ligh et al. successfully used a password-cracking program to unlock the encryption keys and recover a user’s Apple ID and password as well as the user’s Gmail password [2, pp.1971–2004].

4.            Encrypted Virtual Memory

Beginning with OS X Lion (10.7), Macintosh computers automatically encrypt virtual memory. In non-volatile forensics the swap file—the file on disk that contains the virtual memory—was an area of valuable forensic artifacts such as user passwords and other data that once resided in physical memory. Encrypting this file renders these artifacts inaccessible to an examiner.

However, Richard and Case make an argument that the Macintosh OS X encrypted swap file may not be such a bad thing for forensic examiners. They present the difficulties of “capturing mutually consistent memory dumps and swap files” as well as coping with operating systems using encrypted swap [11]. It is difficult to get a complete and consistent picture of memory when comparing what is found in the swap file to what is recovered from a physical memory capture. If the swap file is unreadable due to encryption, it may result in some data loss, but it frees a forensic examiner and the analysis tools from the burden of correlating what is recovered from the swap file with the data located in physical memory. Furthermore, memory compression, introduced in OS X Mavericks (10.9), partially mitigates the concern about artifacts that are lost due to swap encryption. We discuss memory compression in more detail in Section B, below.

5.            Secure Erase

The Disk Utility in OS X allows a user to choose to erase all free space in secondary storage with either a “Zero Out Data” option or “7-Pass Erase” option. The “Zero Out Data” option writes one pass of zeroes over all the unused disk space whereas the “7-Pass Erase” option performs seven passes over the data overwriting the unused data repeatedly on each pass [12]. OS X also provides the user the ability to “Secure Empty Trash” which overwrites the files, making them impossible to recover from disk space [13]. Despite this, an analysis of the memory may still reveal memory-resident application artifacts, encryption keys, advanced malware that resides only in the memory, and remnants of data that may not be found on disk.

B.           Basics of memory in os x

The layout of the physical address space and how OS X utilizes memory compression are essential to understanding how OS X memory analysis tools must work. For example, if, during memory acquisition, a tool interferes with a region of memory reserved for a graphics card, the system may crash, rendering all volatile data lost. Analysis tools must also be able to decompress regions of compressed memory.

1.            System Address Map

The physical address space is the range of memory addresses that can appear on the memory bus including reserved regions [14]. This space maps to more than simply RAM chips; segments of usable memory are interleaved with reserved regions: regions reserved for device memory, containing integrated memory or registers belonging to ROM and PCI resources such as graphics and network cards [15]. Since the physical address space is not contiguous, the chipset must route memory access around reserved regions to permit all the RAM to be used. This design may cause raw memory captures to be larger than the size of usable RAM [14].

According to Intel’s datasheet for the 4th Generation Intel Core Processor family [16] memory controllers usually map PCI devices right below the 4 GiB limit as well as towards the end of the physical address space. Figure 1 illustrates an example of an address map used by the 4th Generation Intel Core Processor.

 

Figure 2.        4th Generation Intel Core Processor Address Map [16, p. 23]

Notice that the memory layout depends on whether the address map is seen from the perspective of the CPU core(s) or the memory controller [16, p.23]. System address maps from the perspective of the CPU core(s) and the dynamic random-access memory (DRAM) controller are different because the memory controller does not have or require visibility into memory ranges used by PCI/PCIe devices. The CPU views the memory ranges from the Top of Low Usable DRAM (TOLUD) to the 4 GiB limit as being allocated to PCI/PCIe devices [16, p.34]. On the other hand, the memory controller views the same memory range as being allocated to DRAM [16, p.23]. These different perspectives are possible because the processor remaps the respective memory range in the DRAM from TOLUD to 4 GiB to a new memory range above 4 GiB in the CPU memory space [16, pp.33-35].

The memory controller ultimately observes the available DRAM as a contiguous memory range while the CPU core view of the memory range is segmented [16, p.23]. The CPU core view contains what are known as “holes” in the memory range below 4 GiB that do not belong to DRAM [16, p.34]. It should also be noted that some DRAM is “stolen” by the graphics card, System Management Mode, and the Management Engine making the size of actually accessible DRAM smaller than size of the installed DRAM [16, pp.26-31].

2.            Memory Compression

Apple implemented memory compression beginning with the release of OS X Mavericks (10.9). Memory compression frees space in physical memory and allows for more data to be stored in memory versus out on disk. Apple maintains that memory compression and decompression are almost instantaneous [17].

Macintosh OS X uses the open-source dictionary-based WKdm algorithm and multiple cores of the system's CPU to shrink the usage of physical memory by inactive applications [11]. Due to compressed memory, there may be more forensic artifacts found within the physical memory since less data is written to swap space. Macintosh OS X acquisition tools acquire the physical memory in its current state. If areas of memory are acquired in a compressed state, memory-analysis tools require programming to decompress some pages of memory before analysis.

C.           OS X Memory acquisition and analysis        

Memory acquisition is a critical and precarious step in memory forensics and there are a limited number of tools available to acquire memory from Macintosh systems. Anti-forensic features, such as FileVault2, have rendered ineffective hardware-assisted memory acquisition tools, which work via direct memory access, requiring most examiners to rely on a few OS X memory software-acquisition tools. These tools require administrative credentials to read the memory from a special device file. Once the acquisition of memory is complete, the memory must be analyzed with tools that are designed for the kernel version of the system from which the memory was captured.

1.            Hardware-Assisted Memory Acquisition

Most memory-acquisition tools require the computer to be unlocked and accessible from within the user interface. However, hardware-assisted acquisition tools circumvent the need to have access to an unlocked computer. They rely on Direct Memory Access (DMA), using a technology such as Firewire, Thunderbolt or an ExpressCard/PCMCIA expansion port. Fortunately, nearly every Macintosh computer offers a Firewire or Thunderbolt port. Acquiring Macintosh memory contents through DMA also does not require an Administrator’s password and will work even if the computer is locked [2, pp.294–296].

The disadvantage of using DMA to acquire a memory capture is that the technology only permits the acquisition of the first 4 GiB of RAM [2, pp.294–296]. In computer systems having more than 4 GiB of RAM, the password hashes may be located in the upper limits of RAM and therefore will not be found in the first 4 GiB.

Inception and Passware’s Firewire Memory Imager are tools designed to exploit DMA allowing access to the first 4 GiB of RAM. The tools will even work on locked systems and support OS X versions 10.5 through 10.9. The tools do not yet support Yosemite or any Ivy Bridge systems running OS X version 10.8.2 and later. Macs manufactured since 2013 have enabled VT-d, Intel Virtualization Technology for Directed I/O, which works as a DMA remapper and effectively blocks DMA requests. If FileVault2 is enabled, OS X will automatically turn off DMA when the computer is locked [18].

2.            OS X Memory Software Acquisition Tools

Macintosh OS X memory software acquisition tools must be run from the user’s interface on an unlocked system. There are only a few of these tools that work on current Macintosh OS X operating systems. Internet searches and a survey of forensic examiners indicate that OSXPMem, BlackBag Technologies’ MacQuisition, and Sumuri’s RECON are the only acquisition tools that provide support for OS X Mavericks (10.9) and/or Yosemite (10.10).

OSXPmem is an open-source memory-acquisition tool that can be downloaded from the Rekall Memory Forensic Framework GitHub website [9]. The source code for Rekall Memory Forensic Framework’s latest release, version 1.2.1, also contains OSXPmem.

BlackBag Technologies offers a live forensics and memory-acquisition tool named MacQuisition. The current version, 2014 R1, was released in February 2014. MacQuisition is available for purchase for approximately $1000.00 [19].

Sumuri Forensics offers a live forensics and memory acquisition tool named RECON. The current version, 1.0.11, is available for purchase for approximately $1500.00 [20].

3.            How Software Acquisition Tools Work

Prior to OS X version 10.6, physical memory could be accessed through a device file known as /dev/mem or through /dev/kmem, which points to the kernel’s virtual address space [2, pp.1965]. When these device files were available, the program dd could read the contents of memory through the device files. In recent versions of the operating system this method is no longer possible and specialized acquisition tools are required.

Of the three available memory acquisition tools for OS X, the open-source OSXPmem is the most thoroughly documented with respect to its acquisition method. The tool is comprised of two components. One component is a user mode acquisition tool, osxpmem, which obtains offsets and sizes of physical memory and then writes them to disk. The other is pmem.kext, a BSD kernel extension that allows read-only access to physical memory. Effectively once the pmem.kext is loaded into the kernel, physical memory can be read from the /dev/pmem/ device file [21].

Memory protection prevents a normal user from accessing memory directly. This is the reason that a kernel driver must be loaded into the kernel. Once the driver is loaded, the memory can be read by a user-mode application [2, pp. 1739-1740]. To load the driver into the kernel, administrative credentials are needed. Acquisition tools cannot simply read physical memory as one large chunk since, as described above, the physical address space is comprised of main memory interleaved with reserved regions. An acquisition tool must avoid the reserved regions to prevent a kernel crash and capture a memory dump successfully [2, pp. 1740-1741]. Memory acquisition tools often report these regions of memory as “bad addresses” as shown in Figure 16.

OSXPmem and other OS X acquisition tools prior to OS X version 10.9 relied on Apple’s IOKit Framework and the IOMemoryDescriptor class to handle physical memory mapping [14]. This mapping is necessary since paging must map each process residing in a virtual address space to physical memory. Unfortunately, though the introduction of compressed memory beginning with OS X 10.9 improves performance, it complicates acquisition methods that rely on the IOMemoryDescriptor class to map the memory into the kernel [14].

To overcome the problems of compressed memory, OSXPMem changed its default mapping method to a method that no longer requires the kernel. The new mapping technique works by modifying the page tables, clearing the cache and therefore requiring the memory management unit to remap virtual memory addresses to physical memory [15].

4.            OS X Memory Analysis Tools

There are two popular open-source memory analysis tools: the Volatility Framework and the Rekall Memory Forensic Framework. Currently Macintosh OS X memory analysis tools require a significant amount of knowledge to operate and there is a steep learning curve for many examiners.

Both Volatility and Rekall rely on the use of memory “profiles” for their analysis. Memory profiles provide support for locating forensic artifacts in the specific operating system version from which the memory dump was acquired [2, pp. 2654]. Because operating systems often use structures (aka structs) that dictate the layout of memory [2, pp.137–138], memory-analysis tools must be able to find and read these structures to determine where useful data is located. A debugger must also perform a similar operation; therefore Rekall and Volatility rely on the Apple kernel-debug kit to determine where various important features are located in memory [2, pp. 204–206]. The memory profile includes the structure definitions for the kernel version, the addresses of global variables, and other information used in the analysis. Even slight changes in the memory layout of new versions of OS X require a new profile to be created.

The Volatility Framework GitHub Site [22] contains OS X profiles for versions 10.5–10.10.1. Each profile is represented by a zip file containing the output of dwarfdump, a tool that extracts debugging symbols [2, pp.2659–2660]. Volatility parses the zip file related to the memory capture being analyzed and converts it into a Python memory structure to locate information specified by the user’s command. The Rekall Memory Forensic Framework uses a profile JSON file which contains the kernel version, structure definitions, and metadata [23]. The Rekall Memory Forensic Framework will also auto-detect the required profile and load it from a public repository.

One disadvantage of any memory-acquisition tool is the potential change in data during the acquisition process. Simply running the software may change or overwrite the data that currently resides on the system. In addition, the memory capture represents a “smeared” snapshot of the data since memory is volatile and pages of memory are changing during the acquisition process [24].

5.            Mitigating Anti-forensic Techniques

Stuttgen and Cohen tested memory-acquisition tools against anti-forensic techniques and discovered that the acquisition tools could rather easily be manipulated. They determined that since most acquisition tools use “non-standard and undocumented” Application Programming Interfaces that are easily recognized, malware can target the acquisition tools [15].

Stuttgen and Cohen developed a new mapping technique, the Page Table Entry (PTE) Remapping, that works by modifying the page tables, clearing the cache, and therefore requiring the memory management unit to remap virtual memory addresses to physical memory. The technique does not rely on the operating system mapping physical pages and therefore can avoid simple hooking techniques used by malware [15].

 

THIS PAGE INTENTIONALLY LEFT BLANK

 

 

 

 

 

III.          METHODOLOGY FOR TESTING
MEMORY-ACQUISITION TOOLS

This chapter details our experimental setup and methodology. The initial experiment was designed to test the memory-acquisition tools’ ability to successfully capture memory. A successful capture was measured by whether the system crashed during the acquisition and whether we were able to detect forensic artifacts in the capture using memory-analysis tools. Next, we examined how memory changes over time by comparing the hash values of 4 KiB blocks of a VM snapshot with other VM snapshots taken at later times. Since a VM snapshot includes the VM’s main memory, we were able to create a baseline to compare the memory-acquisition tools. Finally, we tested the three memory-acquisition tools on a physical Mac Mini to ensure the changes in memory observed in the virtual environment were also evidenced in a non-virtual environment.

A.           OS X memory capture Tools To be Tested

We tested the following OS X memory-acquisition tools:

·         BlackBag Technologies MacQuisition, Version 2014R1

·         OSXPMem, Version RC3

·         Sumuri Forensics RECON, Version 1.0.11

B.           Experiment 1: testing TOOLS’ ability to successfully capture memory

Experiment 1 tested the basic ability of the tools to conduct a memory capture without crashing the operating system. The experiment was conducted using twenty-five MacBook Pro computers and twenty-five Mac Pro computers. All computers were new and had identical hardware and software installed. The hardware specifications were:

 

25 MacBook Pro Computers (Retina, 15-inch, Mid 2014)

Processor: 2.8 GHz Intel i7

Memory:    16 GiB 1600 MHz DDR3

Hard Drive: PCIe Flash 500 GiB

 

25 Mac Pro Computers (Late 2013)

Processor: 3.5 GHz 6-Core Intel Xeon E5

Memory:  64 GiB 1866 MHz DDR3

Hard Drive: PCIe Flash 500 GiB

The computer systems were first tested running OS X Mavericks (10.9.5). Each of the three OS X memory-acquisition tools was directed to write a memory capture to an external USB 3 hard drive (7200RPM). Subsequently each tool was tested on each computer system after being upgraded to Yosemite (10.10.1) and Yosemite (10.10.2).

Each of the three tools—MacQuisition, OSXPmem, and RECON—were used to capture physical memory on twenty-five MacBook Pro and twenty-five Mac Pro computers running OS X Mavericks, version 10.9.5. Subsequently, the process was repeated with each tool on the same machines after their operating systems were upgraded to OS X Yosemite (10.10.1) and then OS X Yosemite (10.10.2). In total 450 captures were performed during this experiment. The time of acquisition and the size of the raw memory capture was also recorded for each memory capture (See Table 6).

We evaluate the success rate with respect to three criteria. The first criteria measures the ability of the tools to write a physical-memory capture without crashing the computer system.  The second criteria depends on how obtrusive the tool is—i.e. what its memory footprint is and how long it takes to run. The third criteria examines the practical outcome of the tool by evaluating its ability to produce a capture from which standard forensic artifacts can be recovered using memory-analysis tools. To accomplish this, each memory capture was analyzed with the Volatility Framework and the Rekall Memory Forensic Framework to determine whether the memory captures contained forensic artifacts and to check if the captures had been corrupted. Table 1 lists the plugins that were invoked using Rekall with a brief description of the data reported. Table 2 provides an analogous list for Volatility plugins used.

 

Table 1.          Rekall Plugins used in Experiment 1

arp

Information about ARP tables

ifconfig

List network interface information

lsof

List open files, grouped by process

mount

Lists mount points

netstat

List per process network connections

psaux

List processes with their command line

route

Show routing tables

 


Table 2.          Volatility Plugins used in Experiment 1

mac_arp

Information about ARP tables

mac_bash

Prints bash history

mac_ifconfig

List network interface information

mac_lsof

List open files, grouped by process

mac_mount

Lists mount points

mac_netstat

List per process network connections

mac_psaux

List processes with their commandline

mac_route

Show routing tables

 

Code for Volatility and the Mavericks (10.9.5) Volatility profile were downloaded from the Volatility Foundation GitHub site [22]. Prior to extracting Volatility, all the dependencies were installed to include Distorm3, Yara, PyCrypto, PIL and OpenPyxl [2, p.135]. Volatility was then extracted to a directory on the desktop of the examination computer, a mid-2014 MacBook Pro computer running Mavericks (10.9.5).

Code for the Rekall Framework, version 1.2.1, was downloaded from the Rekall Memory Forensic Framework GitHub website [25]. Prior to building the Rekall Framework, Yara and Yara Python were installed. The framework was installed on a mid-2014 MacBook Pro computer running Mavericks (10.9.5) by using setup.py within the download directory. The Rekall Framework scans the memory capture and retrieves the required profile, specific to the kernel version of the operating system from which the memory capture was taken, from a public profile repository [26]. For this experiment the Rekall Framework profile for Mavericks 10.9.5 was used.

C.           Experiment 2: Locating filevault2 encryption keys

The vendor of Passware [19] claims that Passware Password Recovery Kit Forensic can scan a physical memory dump taken while the encrypted volume was mounted and locate the FileVault 2 encryption keys. Once the encryption keys are located, the forensic image of the FileVault 2 disk can be decrypted.

In Experiment 2, Passware Password Recovery Kit Forensic Version 13.1 was used to the confirm that encryption keys for FileVault 2 are located within OS X memory captures and can be used to decrypt the volume. To do this FileVault 2 was enabled on a MacBook Pro and a Mac Pro computer running Mavericks (10.9.5) as well as on a MacBook Pro and a Mac Pro computer running Yosemite (10.10.2). Memory captures were conducted using MacQuisition, OSXPMem, and RECON on both the MacBook Pro and Mac Pro computers running Mavericks (10.9.5). RECON failed to capture physical memory from the Mac Pro computers. OSXPMem was used to capture memory from the Mac Pro and MacBook Pro running Yosemite (10.10.2). MacQuisition does not support OS X Yosemite.

After a raw forensic image was taken from each of the computers, Passware Password Recovery Kit Forensic was used to decrypt the images by scanning the memory captures.

Additionally, the hex editor, iBored, was used to search each memory capture for the ASCII characters “longname”. Initially we identified this string by searching for the user’s login password and examining the ASCII characters located nearby. The term “longname” was found to be in close proximity to the user’s password and had the fewest false positives when searching for the user’s password.

D.           Experiment 3: determining how memory changes over time

The rate at which memory changes over time affects the state of the memory dumps acquired by memory-acquisition tools. To analyze memory changes over time we created a virtual machine (VM) using VMware Fusion Professional, version 7.1.1 and used VMWare’s snapshot tool to take a series of snapshots. The virtual machine was running Mavericks (10.9.5) and was configured to use 2 processor cores and 8 GiB of memory. The host machine was a MacBook Pro (Retina, 15-inch, Mid 2014) with a 2.8 GHz Intel i7 processor and 16 GiB of 1600 MHz DDR3 memory. Our procedure can be repeated as follows:

 

1)    Immediately after logging into the VM, use VMWare’s snapshot tool to take a VM Snapshot. Continue to take VM Snapshots every minute for the first fifteen minutes and then in five minute intervals an additional fifteen minutes. We refer to these snapshots as {SV0, SVT1…SV25, SV30} according to the minute in which the snapshot was taken, the machine from which it was taken and the tool with which it was acquired (see Table 3 for an explanation of our snapshot naming convention). A file of the type snapshot_NAMENUMBER.vmem, is generated each time a snapshot is taken. It contains the guest operating system’s main memory [27].

 

2)    Use the Volatility plugin imagecopy to convert the VM Snapshots from compressed formats into raw formats.

 

3)    Create MD5 hashes for every 4 KiB block of each raw image using the program MD5Deep.

 

4)    Compare the MD5 hashes of the 4 KiB blocks from each successive raw image (SV1 – SV30) with the original hashes generated from the VM Snapshots (SV0).

 

5)    Repeat the experiment three times.

 

To accomplish step 4, we used a Python script that compared corresponding hashes from the MD5 output for each raw dump and measured the percentage of 4 KiB blocks that match. Our script also generated a graph illustrating the locations of the matches in the memory space, as well as the blocks which contain null characters.

To track and compare numerous memory dumps created using different tools on different systems at different times, we established a naming convention in which the first letter of the memory dump name indicates the tool that was used to create it, the second letter indicates the platform on which it was created, and the remaining characters are digits representing the number of minutes after the machine was started at which the memory acquisition process that produced the dump was initiated. This convention is summarized in Table 3.

 

Table 3.          Snapshot Naming Convention

 

Tool Initial

Platform

Digit corresponding to time snapshot was initiated

S – VMWare snapshot

B – Mac Book Pro

0 – At startup

M - Macquisition

M – Mac Mini

1 – After 1 minute

O - OSXPmem

P – Mac Pro

2 – After 2 minutes

R - RECON

V – Virtual Machine

3, 4, 5 – Etc.

 

E.           experiment 4: ComparING the memory captures taken with tools to VM Memory Snapshots and to one another

In Experiment 4, we compared memory captured by each of our tools against the VM Snapshot that completed at a time closest to when each capture completed. We then compared each memory capture taken with the tools with one another. This comparison was accomplished using the steps listed below.

 

1)    Restore the VM to the original VM snapshot, SV0. Immediately acquire the memory from the VM with MacQuisition, producing memory dump MV0.

 

2)    Export the acquired memory capture to the host operating system.

 

3)    Using MD5Deep, create MD5 hashes for every 4 KiB block of the captured raw image.

 

4)    Compare the MacQuisition memory capture, MV0, with the VM Snapshot SV1 (again using our Python script for comparing lists of hashes). We used SV1 instead of SV0 since it is the closest to the time when the tool completed the acquisition.

 

5)    Repeat the steps using OSXPmem and RECON, producing snapshots OV0 and RV0. Note that OSXPmem by default generates the memory capture in ELF format. For this testing, the OSXPmem command option was provided to create a raw memory capture to match the output format of the other tools.

 

6)    Compare the memory captures generated by each tool using the process described above with one another (again using our Python script for comparing lists of hashes).

 

F.            experiment 5: Testing memory-acquisition tools in a non-virtual environment

To control for potential variations in behavior introduced by VMWare’s environment we tested the three memory acquisition tools on a physical Mac Mini (late 2014) with a 2.6 GHz Intel i7 processor, and 8 GiB of 1600 MHz DDR3 memory, running Mavericks (10.9.5). The memory captures were taken over a period of 30 minutes. Our procedure follows:

 

1)    Power on Mac Mini after a shutdown.

 

2)    Log on and immediately acquire the memory using MacQuisition, and label the memory capture as MM0.

 

3)    Repeat memory captures using MacQuisition at the following times:

                                   

              2.5 minutes

              5 minutes

              7.5 minutes

              10 minutes

              15 minutes

              20 minutes

              25 minutes

              30 minutes

 

4)    Export the acquired memory captures.

 

5)    Use MD5Deep to create MD5 hashes for every 4 KiB block of each raw image.

 

6)    Compare the MacQuisition memory capture, MM0, with the memory captures generated at the different time intervals (MM2.5 – MM30) (we again used a Python script for this).

 

7)    Repeat steps 1–6 using OSXPmem and RECON.


 

 

            THIS PAGE INTENTIONALLY LEFT BLANK

 

IV.         RESULTS OF Memory-acquisition tool testing

In aggregate, our experiments showed that all tools were capable of acquiring memory in most circumstances, and all acquired memory dumps contained the expected forensic artifacts. However, none of the tools were successful all of the time, and they varied in terms of their overall reliability and support across the full range of hardware and software on which the tests were performed. We found that the open-source OSXPmem performed best overall, and acquired memory in the least amount of time with the smallest footprint. The sections that follow provide a detailed account of the results of each experiment. 

 

A.           Experiment 1: testing TOOLS’ ability to successfully capture memory

Of the three criteria we examined, our evaluation of the ability of the tools to run without producing a crash showed the most important differences between the tools. It is important to note that the machines that crashed were not the same nor did any one machine crash more than once. In addition, even when systems crashed, a second acquisition attempt was often successful after the machines restarted, giving further evidence that the failure was not specific to the machine. The exception was when RECON was used to acquire memory from the Mac Pros with 64 GiB of RAM. All the machines crashed and additional attempts also failed. Although the tools also varied with respect to their memory footprint and acquisition speed, they were all identical in terms of the artifacts present in their output.

When the tools successfully acquired memory captures without crashing, the size of all the captures for machines with 16 GiB of physical RAM equaled 17.99 GiB and for machines with 64 GiB of RAM, the size of all the memory captures equaled 66 GiB.

1.            Evaluation Criteria 1: Obtaining a memory dump without crashing the system

If a memory-acquisition tool results in a system crashing, valuable data will be lost. For example, if an encrypted container was mounted at the time the memory-acquisition tool is run and system crashes, an examiner will no longer have access to the decrypted data. The potential of a tool crashing a system is a critical factor in determining to attempt to acquire physical memory rather than performing live forensics (See Appendix A and B). Our results show that the probability of a crash is non-negligible for all three tools, and in at least one case (running RECON on a Mac Pro with 64 GiB of RAM) a crash was virtually guaranteed.

While all the tools successfully captured memory from the MacBook Pro running Mavericks (10.9.5), only OSXPmem and RECON were capable of capturing memory from the MacBook Pros with Yosemite installed. All the tools crashed one or more computer systems. RECON crashed all Mac Pros having 64 GiB of RAM installed. The results agree with prior research in that there is an inherent risk for memory-acquisition tools to crash systems [2, pp. 1740-1741]. Our results for all tools on all systems tested are summarized in Table 4.

 

Table 4.          Memory-acquisition Tool Success Rates

Computer Tested

OS X 10.9.5

OS X 10.10.1

OS X 10.10.2

Success Rate

MacQuisition: MacBook Pro (16  RAM / mid-2014)

25 of 25

NA

NA

100%

MacQuisition: Mac Pro

(64 GiB RAM / Late 2013)

24 of 25

NA

NA

96%

OSXPMem: MacBook Pro

 (16  RAM / mid-2014)

25 of 25

25 of 25

24 of 25

98.67%

OSXPMem: Mac Pro

 (64 GiB RAM/ Late 2013)

24 of 25

25 of 25

24 of 25

97.33%

RECON: MacBook Pro

 (16 GiB RAM / mid-2014)

25 of 25

25 of 25

24 of 25

98.67%

RECON: Mac Pro

 (64 GiB RAM /Late 2013)

0 of 25

0 of 25

0 of 25

0%

 

Note that MacQuisition is only able to capture memory from OS X versions up to Mavericks (10.9.5). As Table 4 shows, we observed three crashes that occurred after starting osxpmem, one on a MacBook Pro and two on the Mac Pros. Following the reboot, osxpmem did successfully complete a memory capture in all three cases, though in a real acquisition scenario this would not have been possible, since login credentials were required during restart. RECON’s performance on the MacBook Pro was similar to osxpmem’s, but RECON failed to capture physical memory from any of the Mac Pro computers. Once RECON was launched, all the Mac Pro computers immediately crashed and began a reboot.

 

2.            Evaluation Criteria 2: measuring memory footprint and memory-acquisition speed

Table 5 shows the tools’ memory footprints and the average times to acquire the memory captures.

 

 

Table 5.          Summary of Tool Memory Footprint and Time to complete Capture

 

 

MacQuisition

OSXPmem

RECON

Time to Complete Acquisition for 16 GiB

 

4 min 58 sec

 

4 min 52 sec

 

5 min 16 sec

Time to Complete Acquisition for 64 GiB

 

13 min 26 sec

 

13 min 12 sec

 

N/A

Physical Memory Size

 

67.45 MiB

 

944 KiB

 

206.7 MiB

Virtual Memory Size

 

3.39 GiB

 

2.36 GiB

 

2.82 GiB

Shared Memory Size

 

44 MiB

 

220 KiB

 

76.4 MiB

Private Memory Size

 

32.3 MiB

 

280 KiB

 

151.4 MiB

 

We observed that OSXPmem had the smallest memory footprint and acquired memory in the least amount of time. OSXPmem is a command-line tool, and unlike the other tested tools, does not have a graphical user interface. A tool having a small memory footprint is advantageous since the tool must be loaded into memory to operate and therefore forensic artifacts may be overwritten. The time required by the tools to write a memory capture is also important. The longer the tool takes to write the memory capture the more likely the memory is changing which increases the “smear” of the capture.

3.            Evaluation Criteria 3: verifying validity of the memory dumps and inspecting content for standard forensic artifacts

Determining that the memory captured by the tools contains forensic artifacts is an important factor measuring the tools’ performance. The results of our experiments show that if a memory capture was completed without the system crashing, then the completed memory captures contained all forensic artifacts we searched for.

a.            ANALYSIS OF CAPTURES WITH VOLATILITY

The Volatility plugins used in this experiment (see Table 2) produced the same output for all the memory captures with only slight differences in size and time as would be expected in volatile data collection. The output from the Volatility plugins also matched with what was known about the state of the computer systems at the time of the captures. Volatility output listed the same default processes running on the VM as shown in Figure 11.

b.            ANALYSIS OF CAPTURES WITH REKALL

The Rekall plugins in this experiment (see Table 1) produced the same output for all the memory captures with only slight differences in size and time as would be expected in volatile data collection. The output from the Rekall plugins also matched with what was known to be true in the state of the computer systems at the time of the captures. Rekall reported the same default processes running on the VM as shown in Figure 11.

B.           Experiment 2: Locating filevault2 encryption keys

Passware Password Recovery Kit Forensic located the encryption keys in all of the memory captures tested and successfully decrypted the FileVault2 volumes.

The OS X user’s login password was located within all the memory captures using the hex editor iBored by searching for the term “longname”. On all memory captures the password remained in the same block of memory after a thirty minute time period. Figure 10 shows a binary property list located in a memory capture containing the user’s password.

Figure 10.      User’s Login Password Located in Memory

C.           Experiment 3: determining how memory changes over time

In experiment 3 described in section “D” of the previous chapter, VM Snapshots were taken over a period of 30 minutes on a VM with Mac OS version Mavericks (10.9.5) installed. Our Python script was then used to determine the number of 4 KiB blocks whose hash values remain unchanged between the original snapshot and snapshots taken at a later times. Figure 11 shows the Activity Monitor report of the processes running on the VM machine by default and shows that 1.35 GiB of memory is in use. The top command indicated that between 110 and 120 processes were running on the VM prior the snapshots being captured.

Figure 11.      Activity Monitor Showing Processes Running on VM

Figure 12 graphs the 4 KiB block match percentages from the VM snapshots. The percentages are the mean of the results from three experiments. The data graphed shows that only 5.33% of the 4 KiB blocks of memory had changed after 30 minutes. This suggests that the blocks of memory are not changing drastically on OS X systems that are only running default processes.

 

Figure 12.      Match Percentage of 4 KiB blocks in VM Snapshots

Figures 13, 14, and 15 show the 4 KiB blocks in the VM snapshots that changed over time as well as the blocks that contain null characters. Null characters are defined as zeroes (0x00) for our experiments. The red blocks indicate matches which do not contain null characters; the grey blocks represent blocks that match but contain null characters; and the white blocks represent blocks that have changed and do not match. The top left corner of the diagram represents the beginning of memory, and the memory addresses increase from left to right in 4 KiB block increments. There are 1024 blocks represented in each horizontal row so each horizontal slice represents 4 MiB of memory. Note that the total space represented is 9 GiB, for reasons discussed at the end of this section.

Figure            13.            Left: comparison of the original VM Snapshot SV0 with VM Snapshot SV1. Right: SV0 compared with SV5.

The left graph in Figure 13 is a comparison of the hash values of the 4 KiB blocks from the VM snapshots SV0 and SV1 (one minute apart). The right graph is the same comparison between VM snapshots SV0 and SV5 (five minutes apart). The comparison shows nearly no discernible difference in memory over the first five minutes. A lack of white space implies that all blocks were matches (though most of the matches were nulls).

 

            Figure 14.      Left: SV0 compared with SV10. Right: SV0 compared with SV15.

The left graph in Figure 14 is a comparison of the hash values of the 4 KiB blocks from the VM snapshots taken at SV0 and SV10 (ten minutes apart). The right graph is the same comparison between VM snapshots taken at SV0 and SV15 (fifteen minutes apart). The visual representation of the blocks of memory shows a white area (blocks that do not match) appearing after the first GiB of memory between SV0 and SV10. This same white area widens further in the comparison between snapshots SV0 and SV15. This widening corresponds to the sharp drop shown between 8 and 11 minutes in Figure 12.

Figure 15.      Left: SV0 compared with SV20. Right: SV0 compared with SV30.

The left graph in Figure 15 is a comparison of the hash values of the 4 KiB blocks from the VM snapshots taken at SV0 and SV20 (twenty minutes apart). The right graph is the same comparison between VM snapshots taken at SV0 and SV30 (thirty minutes apart). The visual representation of the blocks of memory shows that the white area (blocks that do not match) shown in Figure 14 does not appear to widen during these time intervals. This again, corresponds with our expectations from Figure 12 and indicates that overall the blocks of memory appear to change minimally over thirty-minute period of time when there are only the default processes running on the system.

Note that, as with the captures obtained in section A of this chapter, the memory captures compared here and in the following section are considerably larger than the total allocated physical memory. This outcome is expected due to the presence of reserved areas in the memory.

In Chapter 2, we noted the datasheet for 4th Generation Intel Core Processor Address Map delineates reserved areas in the memory range below 4GiB that do not belong to DRAM [16, p.34]. A similar structure can be observed empirically in the layout of memory of our virtual machines. The vmem files containing the operating system memory generated from the VM snapshots were converted to raw images. Each vmem file as well as each tool memory capture resulted in a raw image that was 9 GiB in size. The VM configuration allocated 8 GiB to physical memory, and therefore the memory captures are approximately 1 GiB larger in file size.

Observing the graphs of the memory captures taken with the acquisition tools in Figures 16, 17, and 18, all three of the tools captured the same range of null values as observed in the first half of the graphs. The device log created by MacQuisition, Figure 16, reported “bad addresses” were padded with zeroes beginning at block 786432 and ending at block 1048575. Each block contains 4096 bytes resulting in approximately 1 GiB of null characters. We inspected the block range in all three tool memory captures with a hex editor and confirmed that all the tools padded the same block range with zeroes. The MacQuisition device log also reported that the VM configured with 8 GiB of RAM resulted in 9 GiB memory capture in a raw format written to file.

Figure 16.      MacQuisition Device Log of Memory Captured from VM

The osxpmem utility prints to screen the sections of RAM as they are read and written to the memory-dump file. Figure 17 is the output shown after running the osxpmem command on the VM. The output lists the starting and ending physical address for each segment as well as a label for the type of data contained within that region. The “MMIO” regions may contain device memory and may not be backed by physical memory whereas the regions named “Conventional” are backed by physical memory [14]. As with the other acquisition methods, a 9 GiB raw format memory capture was written to file.

Stuttgen and Cohen [15] discussed how physical memory addresses are also used for communication with devices on the motherboard. This communication, known as memory-mapped I/O, may be from devices such as video cards, PCI cards, and flash memory [16, p.23]. The 1 GiB block ranges observed between 3 GiB and 4 GiB in Figures16, 17, and 18, appear to be reserved for memory-mapped I/O [15]. The chipset routes memory access around these reserved regions so that all RAM is used. This results in the memory captures being larger than the size of the RAM [14].

Figure 17.      OSXPMem Terminal Output of Memory Captured from VM

 

D.           experiment 4: ComparING the memory captures taken with tools to VM Memory Snapshots and to one another

This section presents comparisons of the tool memory captures and the VM memory snapshots taken at 1 minute after logging in to system, as well as the results of each tool memory capture compared to each other. Overall, we see similar regions of non-null matches in all comparisons. However, the tool memory captures show that most of the null characters observed in the VM snapshots were overwritten with data when the acquisition tools themselves acquired the memory. This would suggest as the memory-capture tools run, blocks of memory containing null characters get changed while other blocks remain mostly unchanged. Since these regions are large and outside the memory space used by the tools, it is unlikely that the tools themselves are changing the data directly. Rather, we conclude that some other mechanism of the operating system is writing to unused space in memory during the acquisition process.

 

1.            Comparing the Memory Captures taken with Tools to the VM Memory Snapshots

Figures 18, 19, and 20 represent a show the 4 KiB block matches between the tool-acquired memory captures and the VM snapshot SV1 (initiated at time = 1 minute). The color key is the same as for Figures 13-15.

Figure 18.      Comparison of VM Snapshot SV1 and MacQuisition Memory Capture MV0

The graph in Figure 18 shows that slightly more than the first GiB of the memory capture contains blocks that match the blocks in the VM snapshot. There is a large area of null values that occurs between the third and fourth GiB of memory which is in agreement with our research in Chapter 2 pertaining to known reserved areas of memory. There are two more significant blocks of null characters that remain while the remaining blocks of memory appear to have changed during the acquisition.

 

Figure 19.      Comparison of VM SnapShot SV1 and OSXPmem Memory Capture OV0

The graph in Figure 19 shows that slightly more than the first GiB of the memory capture contains blocks that match the blocks in the VM snapshot. There is the same large area of null values that occurs between the third and fourth GiB of memory known to be a reserved area of memory. The remaining blocks of memory appear to have changed during the acquisition.

Figure 20.      Comparison of VM SnapShot SV1 and RECON Memory Capture taken at RV0

The graph in Figure 20 again shows that slightly more than the first GiB of the memory capture contains blocks that match the blocks in the VM snapshot. There is the same large area of null values that occurs between the third and fourth GiB of memory known to be a reserved area of memory. The remaining blocks of memory appear to have changed during the acquisition.

In Figures 18, 19, and 20, there are significantly more blocks of memory that do not match (white area) compared to what was observed when comparing the VM snapshots (see Figures 13, 14, and 15). However, most non-null space is the same. Also, the areas containing the blocks that do not match are the same ones that contained null values in the VM snapshots. This suggest that data was not lost but added as the null values seen in the VM snapshots were overwritten with data. Since we have already verified through memory analysis with Rekall and Volatility that we are able to recover forensic artifacts from the memory captures, we do not believe the tools are failing to recover forensic artifacts.

2.            Tool Memory captures compared to one another

The results observed in Figures 18, 19, and 20 show that each tool capture from the VM represents the non-match region (white areas) differently. The contrast between the MacQuisition capture and the other tool captures is apparent. Figure 18 shows two large areas of null values that are not observed in the other two tool captures. Figures 21, 22, and 23 represent comparisons of the tool memory captures from the VM to one another. The comparison between MV0 and OV0 shown in Figure 21 shows that the non-matching areas observed in MV0 (Figure 18) and OV0 (Figure 19) are not the same. This is also true for the comparison between MacQuisition and RECON (Figure 22) and OSXPmem and RECON (Figure 23).

Compare_OSXPMEMandMAQatT1

Figure 21       Comparison of Capture MV0 taken with MacQuisition and OV0 taken with OSXPmem

Figure 22.      Comparison of Capture MV0 taken with MacQuisition and RV0 taken with RECON

 


Figure 23.      Comparison of Capture OV0 taken with OSXPmem and RV0 taken with RECON

Figures 21, 22, and 23 show that each tool is capturing the same matched blocks and the same the reserved region as the VM snapshot. The tools captures differ in how they capture blocks of memory that do not match the blocks from VM snapshot. This suggests not only that the tools are introducing considerable change to the memory space during the acquisition process, but also that each is changing the space in a unique way, so the changes from different tools do not match each other.

E.           experiment 5: memory-acquisition tools tested in non-virtual environment

The Mac Mini was configured with 8 GiB of physical memory, and therefore the memory captures were approximately 1.74 GiB larger in size; each tool acquired a 9.74 GiB raw file. Observing the graphs of the tool memory captures shown in Figures 25, 26, and 27, all three of the tools captured the same range of null values in the first half of the capture. This reserved area appears to be larger than what was observed during the analysis of the VM memory images. The tool memory captures were analyzed with a hex editor and it was determined that the reserved region began at 2.17 GiB and continued until 4 GiB. As discussed previously, since the physical address space consists of the entire range of memory addresses on the memory bus including the reserved regions, the raw memory dump will be larger than the physical size of the RAM.

Figure 24 shows the percentage of matching 4 KiB blocks that contain non-null characters acquired by each tool in relation to the time of the acquisition. The graph shows that the block matches that contain non-null characters begin at approximately 30-30% of the total captured material, but remain relatively stable, declining by less than 10% over a 30 minute period. The match percent is less than what observed in the virtual environment (See Figure 12). In Experiment 3, we observed the tools overwrite the null blocks, which accounted for approximately two-thirds of the memory capture, with data. Since we have observed in the prior experiment that the tools are changing a significant number of non-matching blocks, and in this experiment we are comparing the tool memory captures, we would expect a lower match percentage.

Figure 24.      Match Percentage of 4 KiB Blocks (excluding nulls) of Memory Captures from Mac Mini

The percentage shown in Figure 24 was calculated by excluding null values and dividing by the total number of non-null hashes in the memory capture containing the fewest non-nulls. For example if the one capture in the pair of memory captures being compared contained 1,000 non-null hashes and the second capture contained 900 non-null hashes, the matching percentage would be calculated by dividing the number of non-null hashes by 900. Figures 25, 26, and 27 compare the tool memory captures initiated at 0 and 2.5 minutes with the tool memory captures initiated at 0 and 30 minutes on the Mac Mini. As previously, the red blocks indicate matches which do not contain null characters; the grey blocks represent blocks that match but contain null characters; and the white blocks represent blocks that have changed and do not match.

Figure 25.      Left: comparison of MacQuisition Memory Captures MM0 and MM2.5 minutes; Right: comparison of captures MM0 and MM30.

Figure 25 shows a larger reserved area than what was observed previously in the virtual environment. The grey area, which contains null characters, represents this reserved area and appears to begin at approximately the 2 GiB mark and continue to the end of the 4 GiB mark. The graphs also show that a range of blocks, located just before the 6 GiB mark, changed between the memory capture MM2.5 and the capture MM30. The far edge of the red area remains approximately in the same location, but there are small waves of white blocks breaking up the red on the right figure.

 

Figure 26.      Left: comparison of OSXPmem Memory Captures OM0 and OM2.5; right: comparison of captures OM0 and OM30.

The graphs of OSXPmem memory captures in Figure 26 show a reserved area that appears to agree with the output of the MacQuisition captures, again beginning at approximately the 2 GiB mark and continuing to the end of the 4 GiB mark of memory. The graphs also show that a range of blocks, located just before the 6 GiB mark, changed between OM2.5 and OM30. The edge of the red area in the figure on the right has shifted and the region of matching blocks is less.

Figure 27.      Left: comparison of RECON Memory Captures RM0 and RM2.5; right: comparison of captures RM0 and RM30.

The graphs of RECON memory again show agreement with other tools regarding the location of reserved regions. The graphs also show that a range of blocks, located just before the 6 GiB mark, changed between the memory capture taken at T2.5 and the capture taken at T30. The edge of the red areas between the figures are similar to those observed in Figure 25.

Figures 25, 26, and 27 show that the matching blocks that do not contain null characters (red) appear to change over time but by relatively small percentage. The results are similar to the comparison of the VM snapshots that was completed in Experiment 3, and correspond closely with the plot of match percentages in Figure 12. By illustrating where the matches do and don’t occur, however, we can shed light on the cause of what appear to be low numbers. In particular, it is evident that certain regions of memory are relatively consistent, and are always captured, whereas other regions are always in flux.


 

THIS PAGE INTENTIONALLY LEFT BLANK

 

 

 

 

V.          CONCLUSIONS AND RECOMMENDATIONS
FOR FUTURE RESEARCH

This chapter provides a summary of the results of our testing of the OS X memory-acquisition tools. We also discuss limitations of memory acquisition from Macintosh computers and present ideas for future work.

A.           SUMMARY OF MEMORY acquisition RESULTS

MacQuisition was unable to capture memory from the current version of OS X and RECON crashed every system tested that was configured with 64 GiB of memory. OSXPmem also produced some crashes but performed best overall. OSXPmem, the only open-sourced tool tested, is the tool recommended for use by both the Volatility Foundation and Rekall. It is also the most thoroughly documented with respect to its acquisition method. OSXPmem successfully captured memory from all the systems tested regardless of the OS X version or the amount physical memory.

MacQuisition, RECON, and OSXPmem were all successful in capturing memory from OS X Mavericks (10.9.5) on Macintosh computers with 8 and 16 GiB of physical memory. The tools all proved successful in capturing valuable forensic artifacts such as FileVault2 encryption keys and volatile system data when a memory dump occurred without the system crashing.

The acquisition results indicate that the hardware of the Macintosh computer and the Macintosh OS X version affects a memory-acquisition tool’s ability to successfully capture physical memory. In particular, the results confirm risk of a computer system crashing during a physical memory capture, something also seen frequently with mobile-device acquisition [29]. Ligh et al. acknowledge the risk of memory-acquisition tools causing systems to crash since these can be sensitive to the OS X version or the installed hardware on the system [2. pp. 207-208]. The acquisition tool may access a reserved region or interfere with a system-critical function resulting in the system freezing or crashing.

The results also show that the file size of the memory captures were the same regardless of the acquisition tool used. As depicted in the Table 6, the memory dumps were larger than the amount of physical memory. Stuettgen and Cohen explain this as being due to the ability of modern chipsets to control memory access for regions reserved for firmware, ROM, and other PCI resources [15].

 

Table 6.          Size of Physical Memory Captures

Computer Tested

Physical Memory

Memory Capture

MacBook Pro

16 GiB

17.99 GiB

Mac Pro

64 GiB

66 GiB

Virtual Machine

8 GiB

9 GiB

 

The comparison of the VM snapshots taken over thirty minutes shows that on computers with only the default processes running, memory changes but not significantly. The analysis of the memory dumps with Volatility and Rekall revealed that despite the memory changing, many valuable forensic artifacts remained such as encryption keys and volatile system data.

We observed that when the memory-acquisition tools were used to capture memory from our VMs and compared with the baseline VM snapshots, the comparison revealed that the tools all acquired the blocks of memory that did not contain null characters. This suggests that the tools are acquiring the blocks of memory that are not changing between captures. Though there were significant regions of memory that did not match between the tool-acquired dumps and the VM snapshots, these regions all corresponded with memory blocks that contained nulls in the baseline. Our analysis of forensic artifacts using the Volatility and Rekall frameworks failed to detect any situations in which the non-matching regions corresponded to a loss of forensic evidence. On the contrary, since the regions or memory appear to have contained nulls before the memory acquisition tools were run, changes to these regions could not have resulted in data loss.

Our experiment testing the tools in a non-virtual environment proved all the tools successfully captured memory from a Mac Mini running Mavericks and having 8 GiB of memory. We observed the memory captures from all three of the tools appeared similar as far as the blocks that matched and did not match as well as the blocks containing null characters. The results also agree with the results of our tests in the virtual environment in that the regions of memory that match between comparisons does not change drastically over time.

B.           Problems of MEMORY ACQUISITION

RFC 3227 establishes an “Order of Volatility” and provides guidelines for evidence collection in digital forensics [30]. One guiding principle is that “when confronted with a choice between collection and analysis you should do collection first and analysis later”. Previous research by Aljaedi et al. [32] and Waits et al. [32] support the advantages of memory acquisition first.

However, there are limitations to acquiring physical memory from Macintosh computers. Memory acquisition requires administrative credentials, different results are obtained at different times and using different tools, there is an inherent risk of the system crashing, and there is a lag time after new versions of the operating system are released before acquisition and analysis tools are updated. As for the first issue, when investigating a compromised system or network, law-enforcement examiners are likely to be provided the administrative credentials by a victim but not a perpetrator, so memory acquisition is not always possible even when desired. As for the fourth issue, updates can be a serious obstacle. One method of overcoming these issues is to collect volatile data using live forensics. Appendix A and B describe procedures for handling this contingency. See Appendix A for details on building a trusted Terminal on a USB device. Appendix B provides an explanation on invoking native commands from the Terminal to collect volatile data. The advantage of live forensics is that these commands do not require the use of administrative credentials and the examiner receives valuable information immediately.

C.           Recommendations for future work

Our research observed that certain areas of memory did not change between memory captures. A reasonable explanation for this behavior is that these regions of memory are where the system volatile data resides. These areas most likely contain forensic artifacts such as lists of active processes and network connections. In other words, these are the artifacts that are recovered by the Volatility and Rekall plugins. While valuable data may exist in the regions of memory that does not match between comparisons, this data is most likely remnants of data cached by the system. Research that looks in to the regions of memory that are constantly changing would be beneficial.

The Macintosh computer systems in which memory was captured in research were only running the default processes and not running other memory-intensive processes. Research as to whether the success rates of OS X memory-acquisition tools are affected when the computer systems are performing other memory-intensive processes may be beneficial. Finally, further research is required to measure the effects on memory-acquisition tool performance when significant memory pressure is introduced to the systems.


 

 

 

THIS PAGE INTENTIONALLY LEFT BLANK

 

 

appendix

The procedures described below, in part, were presented in the Sumuri LLC. Macintosh Forensic Survival Course [33].

A.        BUILDING A TRUSTED TERMINAL ON A USB DEVICE

 

1.          Highlight your target disk in Disk Utility and select the Erase tab. Name the volume “TOOLS” and select Mac OS Extended (Journaled) for the format. Close Disk Utility.

2.   In the GUI find the Terminal Application under Applications > Utilities

> Terminal and drag (copy) to your Tools Volume are type the below command.

Text Box: sudo cp –r /Applications/Utilities/terminal.app /Volumes/TOOLS

Text Box: Mkdir /Volumes/TOOLS/usr
Mkdir /Volumes/TOOLS/usr/X11

3.   Create the two (2) below directories:

 

 

Text Box: sudo cp -r /bin /Volumes/TOOLS;
sudo cp -r /sbin /Volumes/TOOLS;
sudo cp -r /usr/bin /Volumes/TOOLS/usr;
sudo cp -r /usr/sbin /Volumes/TOOLS/usr;
sudo cp -r /usr/X11/bin /Volumes/TOOLS/usr/X11;
cp /usr/sbin/system_profiler /Volumes/TOOLS

4    .Copy the Terminal commands to the Tools Volume    

5Open the Terminal on the Tools volume open

 

/Volumes/TOOLS/Terminal.app

 

 

 

Text Box: PATH=/Volumes/TOOLS/usr/bin:/Volumes/TOOLS/bin:/Volumes/TOOLS/usr/sbin:/
Volumes/TOOLS/sbin:/Volumes/TOOLS/usr/X11/bin
6.   Change paths for trusted disk Terminal application.

B.        COLLECTING VOLATILE DATA WITH TRUSTED USB

Create a log file to automatically collect and document your actions by typing the following command:

 

Script     /Volumes/Target/Evidence.txt

 

Then run the commands listed below to collect volatile data:

 

$ system_profiler

$date               (Current system date, time, and time zone)

$history           (History of commands run in terminal)

$ps aux          (Actively running processes)

$ifconfig          (Network devices and configurations)

$arp –an        (ARP Table)

$id                   (List users)

$lsof -i             (List open files)

$who               (List currently signed in users)

$ls –lRain      (Recursive listing of files)

$jobs               (List active jobs)

$mount            (List mounted volumes)

$netstat -an     (Displays input and output network status)  

Type exit to stop script.

Review Evidence.txt

THIS PAGE INTENTIONALLY LEFT BLANK

 

List of References

 

[1]        O. Carroll. (2008, January). Computer forensics: digital forensic analysis methodology. The United States Attorneys’ Bulletin. [Online]. 56(1). pp. 1-8. Available: http://www.justice.gov/sites/default/files/usao/legacy

/2008/02/04/usab5601.pdf

 

[2]        M. Ligh et al., Art of memory forensics. Indianapolis, IN: Wiley, 2014.

[3]        P. Roberts. (2013, Nov. 4). Ephemeral in-memory malware common at high value targets. Securityledger. [Online]. Available: https://securityledger.com/2013/11/ephemeral-in-memory-malware-common-at-high-value-targets/

[4]        Volatility Foundation. (n.d.). The Volatility Foundation–Open source memory forensics. Volatility Foundation. [Online]. Available: http://www.volatilityfoundation.org/#!about/cmf3. Accessed: Mar. 13, 2015.

[5]        Rekall Memory Forensic Framework. (n.d.). About the Rekall memory forensic framework. [Online]. Available: http://www.rekall-forensic.com/about.html#. Accessed: Mar. 13, 2015.

[6]        R. Beverly et al. (2011). Forensic carving of network packets and associated data structures, Sciencedirect.com, 2011. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S174228761100034X. Accessed: Mar. 13, 2015.

[7]        Apple Inc. (n.d.). OS X: About FileVault 2. [Online]. Available: https://support.apple.com/en-us/HT4790. Accessed: Mar. 08, 2015.

[8]        G. Cluley. “Take that FBI! OS X Yosemite Encrypts Disks by Default, Better Protecting Privacy”. (Oct. 20, 2014). The Mac Security Blog. [Blog entry]. Available: http://www.intego.com/mac-security-blog/yosemite-filevault/. Accessed: Mar. 09, 2015.

[9]        O. Choudary et al. (2012, Jul. 21). Infiltrate the vault: security analysis and decryption of lion full disk encryption. [Online]. Available: http://eprint.iacr.org/2012/374.pdf

[10]      Passware Inc. (n.d.). PNL #069 Passware Kit 13.1 adds GPU-accelerated recovery of FileVault2 passwords, recovers passwords for android images, decrypts QuickBooks & Quicken 2014, and is twice as fast. [Online]. Available: http://www.lostpassword.com/news/pnl69.htm. Accessed Mar. 08, 2015.

[11]      Richard, Golden, and Andrew Case. (2014). In lieu of swap: Analyzing compressed RAM in Mac OS X and Linux. Digital Investigation. [Online]. Volume 11. pp. S3-S12. Available: http://www.dfrws.org/2013/proceedings

/DFRWS2013-13.pdf

 

[12]      Apple Inc. (n.d.) OS X: About disk utility's erase free space feature. [Online]. Available: https://support.apple.com/en-us/HT201949. Accessed: Mar. 09, 2015.

[13]      Apple Inc. (n.d.) OS X Mavericks: Remove files and folders from your Mac. [Online]. Available: https://support.apple.com/kb/PH13765?

locale=en_US. Accessed Mar. 09, 2015.

 

[14]      M. Cohen. “Mapping Physical Memory”. (Mar. 28, 2014). Rekall Memory Forensics Blog. [Blog entry]. Available: http://rekall-forensic.blogspot.com/

2014_03_01_archive.html. Accessed: Mar. 8, 2015.

 

[15]      J. Stuttgen, and M. Cohen. (2013). Anti-forensic resilient memory acquisition. Digital Investigation. [Online]. Volume 10. pp. S105-S115. Available: http://www.dfrws.org/2013/proceedings/DFRWS2013-13.pdf

 

[16]      Intel Corp. (2012, Dec.). Desktop 4th generation Intel core processor family, desktop Intel Pentium processor family, and desktop Intel Celeron processor family. [Online]. Available: http://www.intel.com/content/dam/www/

public/us/en/documents/datasheets/4th-gen-core-family-desktop-vol-2-datasheet.pdf. Accessed May 25, 2015.

 

[17]      D. Dilger. (2013, Jun. 12). Compressed memory in OS X 10.9 Mavericks aims to free RAM, extend battery life. Appleinsider. [Online]. Available: http://appleinsider.com/articles/13/06/12/compressed-memory-in-os-x-109-mavericks-aims-to-free-ram-extend-battery-life

[18]      Break & Enter. (2015). Inception. [Online]. Available: http://www.breaknenter.org/projects/inception/. Accessed: Mar. 08, 2015.

[19]      Blackbag Technologies. (n.d.) Forensic imaging, live data acquisition, and targeted file collection for Mac, Macbook, Macbook Air, and OS X server computers – MacQuisition. [Online]. Available: https://www.blackbagtech.com/software-products/macquisition-6/macquisition.html. Accessed Mar. 08, 2015.

[20]      Sumuri LLC. (n.d.) RECON - Product categories. [Online]. Available: http://sumuri.com/product-category/recon/. Accessed Mar. 08, 2015.

[21]      M. Cohen. (2014, December). Release 1.2.1 Col de la Criox – Source Code. [Online]. Available: https://github.com/google/rekall/releases. Accessed Mar. 13, 2015.

[22]      Volatility Foundation. (2015, January). Volatility. [Online]. Available: https://github.com/volatilityfoundation. Accessed Mar. 09, 2015.

[23]      M. Cohen. “The Rekall Profile Repository and Profile Auto-selection”. (Feb. 20, 2014). Rekall Memory Forensics Blog. [Blog entry]. Available: http://rekall-forensic.blogspot.com/2014/02/the-rekall-profile-repository-and.html. Accessed Mar. 14, 2015.

[24]      M. Cohen. “The Pmem Memory acquisition suite”. (Apr. 24, 2015). Rekall Memory Forensics Blog. [Blog entry]. Available: http://rekall-forensic.blogspot.com/2015/04/the-pmem-memory-acquisition-suite.html. Accessed May 1, 2015.

[25]      Google. (2015, April). Rekall. [Online]. Available: https://github.com/google/rekall/releases. Accessed Jun. 5, 2015.

[26]      Google. (2015, June). Rekall – Profiles. [Online]. Available: https://github.com/google/rekall-profiles. Accessed Mar. 14, 2015.

[27]      VMware Inc. (n.d.) VMware – VMware workstation 9 documentation center. [Online]. Available: https://pubs.vmware.com/workstation-9/index.jsp?topic=%2Fcom.vmware.ws.using.doc%2FGUID-A968EF50-BA25-450A-9D1F-F8A9DEE640E7.html. Accessed May 27, 2015.

[27]      Blackbag Technologies. (n.d.). Forensic imaging, live data acquisition, and targeted file collection for Mac, MacBook, MacBook Air, and OS X server computers – MacQuisition. [Online]. Available: https://www.blackbagtech.com/software-products/macquisition-6/macquisition.html. Accessed Mar. 08, 2015.

[28]      Volatility Foundation. (2015, January) Volatility. [Online]. Available: https://github.com/volatilityfoundation/volatility/wiki/Mac-Command-Reference. Accessed Mar. 09, 2015.

[29]      Schwamm, R., and Rowe, N., Effects of the factory reset on mobile devices.  Journal of Digital Forensics, Security, and Law, Vol 9, No. 2 (Proceedings of the International Conference on Digital Forensics and Computer Crime, New Haven, CN, US, September 2014), pp. 205-220, 2014.

[30]      IETF Guidelines for Evidence Collection and Archiving, RFC 3227, 2002.

[31]      A. Aljaedi et al, “Comparative analysis of volatile memory forensics: Live response vs. memory imaging,” in 2011 IEEE Third Int'l Conf. on Privacy, Security, Risk and Trust, Boston, MA, 2011, pp. 1253-1258.

[32]      C. Waits et al, “Computer forensics: Results of live response inquiry vs. memory image," Carnegie Mellon University Software Engineering Institute, Pittsburgh, PA, CMU/SEI-2208-TN-017, Aug. 2008.

[33]      Sumuri LLC, “Macintosh Forensic Survival Course,” class notes for Treasury Computer Forensic Training Program, Brunswick, GA, spring 2012.

 

 


 

initial distribution list

1.         Defense Technical Information Center

            Ft. Belvoir, Virginia

 

2.         Dudley Knox Library

            Naval Postgraduate School

            Monterey, California