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.
1 2 3 4 5 6 7 8 9 10 11 12
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.
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
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.
A quick Google search for this issue turned up a solution: Failed
brew update on El Capitan (OS X 10.11) Beta
1 2 3 4 5 6 7
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.
1 2 3 4 5 6 7 8
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.
1 2 3 4 5
Excellent, armed with the correct version I attempted to analyze the memory using the MacMountainLion_10_8_5_12f37_AMDx64 profile.
1 2 3
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.
1 2 3 4 5 6 7 8 9
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.
1 2 3 4 5 6 7 8
With great anticipation I attempted to analyze the memory again.
1 2 3 4 5 6
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