Security Ripcord

Cutaway Security Blog and Projects

Volatility OSX 10.8.5_12f37 Analysis Attempt

For the “TL;DR crowd,” there is nothing ground-breaking here. This is just a post to document some of the steps that I took to get back up to speed with memory analysis, a how-to.

The other day I was involved with a situation that involved collecting and analyzing the memory of an Apple system. I have to admit, it has been awhile since I’ve collected and analyzed the memory of any system. I was eager to get the memory dump and do a little checking of my own to get back up to speed with the capabilities of tools like Memoryze and Volatility.

The system was a Mac OS X Mountain Lion (10.8) 64-bit system and therefore memory was collected and analyzed with Memoryze for Mac. It was an easy process and produced the results required to gain an understanding of the system at that moment. A quick check of the system call list, using Memoryze, confirmed the OS version.

Memoryze SysCallList
1
2
3
4
5
6
7
8
9
10
11
12
cutaway> /Applications/Mandiant\ Mac\ Memoryze/macmemoryze syscalllist -s -f image.mem
INFO: [+] searching for lowGlo
INFO: [+] lowGlo [0000000012A24000]
INFO: [+] found os [Mac OS X 10.8 (Mountain Lion)] [64-bit]
INFO: [+] PA PML4 [0000000015091000]
INFO: [+] searching for kernel base
INFO: [+] found kaslr_base as [0000000012200000]
INFO: [+] running 64 sysent hunter
INFO: [+] searching for nsysent
INFO: [+] found sysent match @ 0x12a5d7f0
INFO: [+] found nsysent = 440
INFO: [+] finding the syscallnames..

Since the Memoryze analysis went so well I wanted to follow it up with analysis using Volatility. Afterall, it does seem that Volatility does have quite a few more options for extracting information from memory. This started me down the path of installing Volatility on my Mac Book Pro (MBP).

I considered pulling Volatility down via Git, installing all of the dependencies, and the compiling and installing the tool. But, after looking at the dependencies I realized the better option would be to see if someone had already done all of this for me. Thus, I used Homebrew to install the tool.

Volatilty Homebrew Install
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
cutaway> brew install volatility
==> Installing dependencies for volatility: openssl, yara
==> Installing volatility dependency: openssl
==> Downloading https://homebrew.bintray.com/bottles/openssl-1.0.2h.el_capitan.b
######################################################################## 100.0%
==> Pouring openssl-1.0.2h.el_capitan.bottle.tar.gz
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/openssl/certs

and run
  /usr/local/opt/openssl/bin/c_rehash

This formula is keg-only, which means it was not symlinked into /usr/local.

Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/openssl/lib
    CPPFLAGS: -I/usr/local/opt/openssl/include

==> Summary
  /usr/local/Cellar/openssl/1.0.2h: 1,691 files, 12M
==> Installing volatility dependency: yara
==> Downloading https://homebrew.bintray.com/bottles/yara-3.4.0.el_capitan.bottl
######################################################################## 100.0%
==> Pouring yara-3.4.0.el_capitan.bottle.tar.gz
  /usr/local/Cellar/yara/3.4.0: 38 files, 1M
==> Installing volatility
==> Downloading https://homebrew.bintray.com/bottles/volatility-2.5.el_capitan.b
######################################################################## 100.0%
==> Pouring volatility-2.5.el_capitan.bottle.1.tar.gz
  /usr/local/Cellar/volatility/2.5: 1,906 files, 26.9M

With Volatility installed I realized that I had just recently updated to OSX El Capitan without updating my brew installation. So, I updated it, or tried to.

Homebrew Update Fail
1
2
cutaway> brew update
Error: /usr/local must be writable!

A quick Google search for this issue turned up a solution: Failed brew update on El Capitan (OS X 10.11) Beta

Homebrew Fix Permissions Fail
1
2
3
4
5
6
7
cutaway> sudo chown -R $(whoami):admin /usr/local
Password:
cutaway> brew update
Updated Homebrew from 9a9a989 to c55da93.
Updated 3 taps (caskroom/cask, homebrew/core, homebrew/dupes).
==> New Formulae
[snip package info]

With Homebrew successfully updated I felt good to use Volatility. I remembered from my previous dealings with memory analysis, from over five years ago, that memory analysis on Unix-based systems had a heavy dependence on understanding how the kernel was configured to manage memory. Meaning that each kernel version required a special configuration. I figured that OSX was no different and therefore I checked for instructions on Volatilitys website. Indeed, Volatilitys Mac page explains the requirement for using a pre-generated profile or generating your own.

This situation is punctuated by the fact that Volatility does not have non-Windows profiles installed by default. Volatility uses the “–info” option to list currently installed plugins and profiles. By searching for “A Profile for” in the “–info” output we get a list of installed profiles.

Volatility Initial Profile List
1
2
3
4
5
6
7
8
cutaway> vol.py --info | grep "A Profile for"
Volatility Foundation Volatility Framework 2.5
VistaSP0x64     - A Profile for Windows Vista SP0 x64
VistaSP0x86     - A Profile for Windows Vista SP0 x86
VistaSP1x64     - A Profile for Windows Vista SP1 x64
VistaSP1x86     - A Profile for Windows Vista SP1 x86

[snip Windows profiles]

Additionally, you may have noticed that the Download pre-built profiles section does not contain the version of OSX I need to analyze. This version was identified as [Mac OS X 10.8 (Mountain Lion)] [64-bit] by Memoryze. It seems that Memoryze is capable of conducting analysis on all OSX 10.8 kernels but Volatility requires a little more granularity. This sent me back to Google which quickly identified the method for discovering the exact version number. It seems that Volatility, of course, does it for us.

Volatility Initial Profile List
1
2
3
4
5
cutaway> vol.py mac_get_profile -f image.mem
Volatility Foundation Volatility Framework 2.5
Profile                                            Shift Address
-------------------------------------------------- -------------
MacMountainLion_10_8_5_12f37_AMDx64                0x00012200000

Excellent, armed with the correct version I attempted to analyze the memory using the MacMountainLion_10_8_5_12f37_AMDx64 profile.

Memory Analysis OSX 10.8.5 First Attempt
1
2
3
cutaway> vol.py mac_bash -f image.mem --profile=MacMountainLion_10_8_5_12f37_AMDx64
Volatility Foundation Volatility Framework 2.5
ERROR   : volatility.debug    : Invalid profile MacMountainLion_10_8_5_12f37_AMDx64 selected

Obviously I did something wrong. Of course, it turns out that OSX 10.8.5 isn’t listed in the profiles installed by Volatility. Going back over the Volatilitys Mac page I noticed that it wasnt even listed in the prebuilt profiles. But, at the very end of that list (yes, I’m a member of the TL;DR crowd) there is a reference to a profiles repository. Volatilitys Profiles is a Github repo that contains Linux and Mac profiles. These can be downloaded and installed following their instructions.

I followed these instructions and followed them. I copied the MountainLion_10.8.5_12f37_AMD.zip file into my Python installation at “/usr/local/lib/python2.7/site-packages/volatility/plugins/overlays/mac”. This time, instead of running a Volatility on the memory I decided to check the list of profiles first using the “vol.py –info” command. This produced the same output as previously shown. The output only contained a list of Windows-based profiles and did not include the OSX 10.8.5 profile.

Google searches didn’t help this time. So, I decided to figure it out myself. A quick directory listing actually identified my issue.

Volatility Python Directory Listing
1
2
3
4
5
6
7
8
9
cutaway> ls -al /usr/local/lib/python2.7/site-packages/volatility/plugins/overlays/mac
total 2472
drwxr-xr-x  6 dweber  admin      204 May  5 15:43 .
drwxr-xr-x  8 dweber  admin      272 May  5 15:03 ..
-rw-r--r--  1 dweber  admin  1251778 May  5 15:36 MountainLion_10.8.5_12f37_AMD.zip
lrwxr-xr-x  1 dweber  admin      114 May  5 15:03 __init__.py -> ../../../../../../../Cellar/volatility/2.5/lib/python2.7/site-packages/volatility/plugins/overlays/mac/__init__.py
lrwxr-xr-x  1 dweber  admin      109 May  5 15:03 mac.py -> ../../../../../../../Cellar/volatility/2.5/lib/python2.7/site-packages/volatility/plugins/overlays/mac/mac.py
lrwxr-xr-x  1 dweber  admin      111 May  5 15:03 macho.py -> ../../../../../../../Cellar/volatility/2.5/lib/python2.7/site-packages/volatility/plugins/overlays/mac/macho.py
cutaway> mv MountainLion_10.8.5_12f37_AMD.zip ../../../../../../../Cellar/volatility/2.5/lib/python2.7/site-packages/volatility/plugins/overlays/mac/

As you can see, I did install the MountainLion_10.8.5_12f37_AMD.zip in my Python 2.7 location. But, Homebrew actually installs Volatility in, what I assume, is the Cask location at “Cellar/volatility/2.5.” Once I moved the zip file to this location Volatility recognized the OSX 10.8.5 profile.

Volatility Profiles with OSX 10.8.5
1
2
3
4
5
6
7
8
cutaway> vol.py --info | grep "A Profile for"
Volatility Foundation Volatility Framework 2.5
MacMountainLion_10_8_5_12f37_AMDx64 - A Profile for Mac MountainLion_10.8.5_12f37_AMD x64
VistaSP0x64                         - A Profile for Windows Vista SP0 x64
VistaSP0x86                         - A Profile for Windows Vista SP0 x86
VistaSP1x64                         - A Profile for Windows Vista SP1 x64
VistaSP1x86                         - A Profile for Windows Vista SP1 x86
[snip Windows profiles]

With great anticipation I attempted to analyze the memory again.

Memory Analysis OSX 10.8.5 Second Attempt
1
2
3
4
5
6
cutaway> vol.py mac_bash -f image.mem --profile=MacMountainLion_10_8_5_12f37_AMDx64
Volatility Foundation Volatility Framework 2.5
No suitable address space mapping found
Tried to open image as:
 MachOAddressSpace: mac: need base
[snip similar error messages]

Still not working. A quick google turns up this error in the Volatility Foundation FAQ: No address space mapping, No valid DTB found. Basically, I’ve picked the wrong profile.

Additional Google searches and tweeks were unsuccessful. At this point it would be a waste of time and effort to attempt to build a profile from the system itself. Thus, without outside input, this is where I had to leave it. I have used my “phone-a-friend” option. I hope that person has time to respond.

Go forth and do good things, Cutaway