Musings and confusings. All things DFIR.

OSX (Mac) Memory Acquisition and Analysis Using OSXpmem and Volatility

Macs don’t get much love in the forensics community, aside from @iamevltwin (Sarah Edwards), @patrickolsen (Patrick Olsen), @patrickwardle (Patrick Wardle), and a few other incredibly awesome pioneers in the field. We see blog posts all the time about Windows forensics and malware analysis techniques, along with some Linux forensic analysis, but rarely do we see any posts about Mac technical/forensic analysis or techniques. I find this odd, considering the surge in usage and deployment over the last several years, particularly within enterprises. Well, with my most recent two part Mac post as well as this one, I’m attempting to change this, my friends!

Macs need love and disk/memory analysis as well, amirite?

Let’s have a look at memory acquisition of OSX systems using a nifty tool called OSXpmem.

OSXpmem is a part of the pmem suite created by the developers of Rekall. Rekall itself is actually a very useful utility built for both memory acquisition and live memory analysis on Windows, Linux, and OSX systems. While I will be delving into Rekall in a future post, for this we will simply be focusing on OSXpmem, which is an awesome command-line utility for quickly and easily collecting RAM from a Mac system. One of its greatest features is its output to an AFF4 volume, which has a ton of useful features (likely to be discussed in a dedicated post in the future as well).

Acquiring Memory

So, what’s the easiest way to get up and running with the tool for memory acquisition?

  1. Download latest release (as of this post, the latest osxpmem release is “2.1.post4”).
  2. Unzip the package
    1. $ unzip osxpmem.osxpmem-2.1.post4.zip
  3. Run it to collect memory from the local system
    1. $ ./osxpmem.app/osxpmem -o <output_dir>

Super simple, right?

Wellll, maybe not that simple. When you run it, even as sudo/root, you may get the following error:

$ sudo osxpmem.app/osxpmem -o Memory_Captures/mem.aff4
Imaging memory
E1229 15:17:26.335978 3375588288 aff4_file.cc:289] Can not open file /dev/pmem :No such file or directory
/Users/jp/Projects/osxpmem.app/MacPmem.kext failed to load - (libkern/kext) authentication failure (file ownership/permissions); check the system/kernel logs for errors or try kextutil(8).
E1229 15:17:26.606639 3375588288 osxpmem.cc:283] Unable to load driver at /Users/jp/Projects/osxpmem.app/MacPmem.kext
E1229 15:17:26.606714 3375588288 pmem_imager.cc:328] Imaging failed with error: -8

How usefully nondescript. Let me save you some time, as searching the system/kernel logs as suggested yields nothing useful.

So, instead, let’s use the native utility kextutil’s “test” parameter (-t) to see if that gets us anywhere…

$ sudo kextutil -t osxpmem.app/MacPmem.kext/
Diagnostics for osxpmem.app/MacPmem.kext:
Authentication Failures:
File owner/permissions are incorrect (must be root:wheel, nonwritable by group/other):
osxpmem.app/MacPmem.kext
Contents
_CodeSignature
CodeResources
Info.plist
MacOS
MacPmem

Nice. It finally tells us what’s wrong. The file ownership/permissions must be changed to “root:wheel”. Easy enough…

$ sudo chown -R root:wheel osxpmem.app/

So, let’s try again…

$ sudo osxpmem.app/osxpmem -o Memory_Captures/mem.aff4
Imaging memory
Creating output AFF4 ZipFile.
Reading 0x8000 0MiB / 8095MiB 0MiB/s
Reading 0xe38000 14MiB / 8095MiB 56MiB/s
Reading 0x1c88000 28MiB / 8095MiB 56MiB/s
Reading 0x2ac0000 42MiB / 8095MiB 56MiB/s
Reading 0x3978000 57MiB / 8095MiB 58MiB/s
Reading 0x47c8000 71MiB / 8095MiB 56MiB/s
Reading 0x5678000 86MiB / 8095MiB 58MiB/s
Reading 0x6500000 101MiB / 8095MiB 57MiB/s

Reading 0x1f7478000 8052MiB / 8095MiB 39MiB/s
Reading 0x1f7d68000 8061MiB / 8095MiB 35MiB/s
Reading 0x1f8708000 8071MiB / 8095MiB 38MiB/s
Reading 0x1f9150000 8081MiB / 8095MiB 41MiB/s
Reading 0x1f9c00000 8092MiB / 8095MiB 41MiB/s

YES! It worked! As you can see, my system has 8GB of memory that was (by default) exported to an AFF4 volume/file called “mem.aff4”.

You also have the option to include additional local files within the resulting AFF4 volume/file via the “-i </path/to/file> -i </path/to/file> …” command line option(s), which can be useful in producing a singular output volume containing not only memory but other files (binaries/logs/etc.) you’d like to analyze as well. In the past, I used this option to collect the local /bin/bash file when Volatility used to require the bash shell’s memory address be provided in order to parse command history and produce associated timestamps when using the linux_bash plugin. Though the documentation still shows it as a requirement, it’s actually not needed anymore and parses it all just fine.

In addition, you may also export the memory image to a singular RAW or ELF file by using the “–format elf” or “–format raw” command line options if that suits your fancy. However, for this post, I am using the default AFF4 output so that we may explore its use and features a bit.

So, without further ado, let’s take a look at the resulting AFF4 volume/file.

$ sudo osxpmem.app/osxpmem -V Memory_Captures/mem.aff4
Password:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix aff4: <http://aff4.org/Schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix memory: <http://aff4.org/Schema#memory/> .
<aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem>
aff4:category memory:physical ;
aff4:stored <aff4://7f482355-5683-46bb-87c0-21afd75dbbeb> ;
a aff4:map .
<aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem/data>
aff4:chunk_size 32768 ;
aff4:chunks_per_segment 1024 ;
aff4:compression <https://www.ietf.org/rfc/rfc1950.txt> ;
aff4:size 8488656896 ;
aff4:stored <aff4://7f482355-5683-46bb-87c0-21afd75dbbeb> ;
a aff4:image .
Objects in use:
Objects in cache:
aff4://7f482355-5683-46bb-87c0-21afd75dbbeb - 0
aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/information.turtle - 0
file:///Users/jp/Projects/Memory_Captures/mem.aff4 - 0

Here, you can see that we extracted a memory image to the AFF4 stream “7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem“.

Now, what can we do with this? Well, one thing you could do (if not using Rekall to analyze this image) might be to extract the AFF4 memory image stream into a singular raw file for parsing/analysis by other tools such as Volatility, page_brute, yara, strings, etc. To do that, we perform the following:

$ sudo osxpmem.app/osxpmem -e /dev/pmem -o Memory_Captures/mem.raw Memory_Captures/mem.aff4
Extracting aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem into file:///Users/jp/Projects/Memory_Captures/mem.raw
Reading 0x8000 0MiB / 9968MiB 0MiB/s
Reading 0x750000 7MiB / 9968MiB 28MiB/s
Reading 0xde0000 13MiB / 9968MiB 25MiB/s
Reading 0x1480000 20MiB / 9968MiB 25MiB/s

Reading 0x26d938000 9945MiB / 9968MiB 21MiB/s
Reading 0x26deb8000 9950MiB / 9968MiB 21MiB/s
Reading 0x26e418000 9956MiB / 9968MiB 20MiB/s
Reading 0x26eab0000 9962MiB / 9968MiB 25MiB/s

$ ls -l Memory_Captures/
total 25665056
-rwxr-xr-x 1 root staff 2688302741 Dec 29 15:30 mem.aff4
-rwxr-xr-x 1 root staff 10452205568 Dec 29 16:10 mem.raw

As you can see, the raw image is uncompressed and thus substantially larger than the AFF4 volume (one of the useful features of AFF4 is its compression options). Nonetheless, there you have it. A raw memory image to parse to your heart’s content with whatever tools you like.

However, before we move on, I personally like to unload the kernel extension for one last good measure so that it’s not just hanging out there for no purpose.

$ sudo osxpmem.app/osxpmem -u
Unloading driver /Users/jp/Projects/osxpmem.app/MacPmem.kext

Creating a Memory Profile

**Update 11/2019**

The dwarfdump conversion process using Volatility’s convert.py utility is broken for any recent version of OSX/MacOS. If you try to perform it, you will likely get a “State machine broken! level 0!” error stemming from this area in the convert.py code. I am unaware of any current fix for this as it appears the Volatility team is focusing all their efforts in the Volatility 3 build.

——

Acquiring a memory image is great, but unfortunately is useless (with respect to Volatility) without the appropriate profile to parse it. Volatility requires a memory profile be specified when parsing a memory image via the “–profile=<profile>” command line option. By default, Volatility includes a ton of profiles for Windows, but such is not the case for Linux and Mac. Though a profiles repository has been created containing a substantial set of profiles for Linux and Mac, YMMV. In my situation, I’m running the latest MacOS Sierra release 10.12.3, for which no profile existed as of this post (nor did it for 10.12.2 until I created and submitted one to the repo as well :D). Therefore, I had to create my own profile. Luckily, the folks at Volatility do a great job walking us through building a profile on a Mac. Though, there are a few clarifications I’d like to address.

To begin, I need to provide some clarification/correction for the initial step, focusing on the part in italics:

“To create a profile, you first need to download the KernelDebugKit for the kernel you want to analyze. This can be downloaded from the Apple Developer’s website (click OS X Kernel Debug Kits on the right). This account is free and only requires a valid Email address.

After the DebugKit is downloaded, mount the dmg file. This will place the contents at “/Volumes/KernelDebugKit”.”

While the above statement is true, if you immediately dismount a package once it’s installed like I do, you should instead pay attention to the installer to see where it is putting the files for long term access. Independent of the mounted package, the KDK is installed in the following location, which will need to be referenced for future use once the package is dismounted post-install:

/Library/Developer/KDKs/KDK_<version>.kdk/

As of current, for macOS Sierra 10.12.2 and 10.12.3, the <version> will be “10.12.2_16C67” and “KDK_10.12.3_16D32.kdk“, respectively.

/Library/Developer/KDKs/KDK_10.12.2_16C67.kdk/
/Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/

Thus, “Step 1” for building a 10.12.3 profile would be the following (for a 64-bit 10.12.3 system):

$ dwarfdump -arch x86_64 /Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel.dSYM > 10.12.3_x64.dwarfdump

Also note that the referenced kernel file names vary from the current instructions (e.g., “mach_kernel.dSYM” is now “kernel.dSYM”, and “mach_kernel” is now just “kernel”). So, do exercise additional caution when running the commands. For ease of reference, below should be the locations for both of these files on a macOS Sierra 10.12.3 64-bit system (but note that this may change with future versions):

/Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel
/Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel.dSYM

All of the above is actually noted during the install as well:

To save everyone a bit of time and translation from current Volatility documentation, I’ve written out the latest required steps below for relatively easy copy/paste into your terminal. For this, we are using the latest 10.12.3 release and associated KDK as an example:

  1. Check to see if a profile is already available for your particular OSX version/release
    1. https://github.com/volatilityfoundation/profiles/tree/master/Mac
  2. If not, download and install the KDK appropriate for your current (or targeted) OSX version/release
    1. http://developer.apple.com/hardwaredrivers
  3. Get the dwarf debug info from the kernel.
    1. $ dwarfdump -arch x86_64 /Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel.dSYM > 10.12.3_x64.dwarfdump
  4. Convert the dwarfdump output to Linux style output readable by Volatility
    1. $ python tools/mac/convert.py 10.12.3_x64.dwarfdump converted-10.12.3_x64.dwarfdump
  5. Create the types from the converted file
    1. $ python tools/mac/convert.py converted-10.12.3_x64.dwarfdump > 10.12.3.64bit.vtypes
  6. Generate symbol information
    1. $ dsymutil -s -arch x86_64 /Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel > 10.12.3.64bit.symbol.dsymutil
  7. Create a zip file of the *.dsymutil and *.vtypes files
    1. $ zip 10.12.3.64bit.zip 10.12.3.64bit.symbol.dsymutil 10.12.3.64bit.vtypes
    2. **See note at end of instructions**
  8. Copy the zip file to to the volatility/plugins/overlays/mac/ directory (remember, we are already inside the root /volatility directory)
    1. $ cp 10.12.3.64bit.zip volatility/plugins/overlays/mac/
  9. Verify your profile is registered and ready for use
    1. $ python vol.py --info | grep "A Profile for Mac"
      1. The profile name presented is the string you will pass to the “–profile=” parameter when analyzing a memory image from this version/release in Volatility

**Note: While I append “x64” or “64bit” to my various output files to keep track of which architecture build I’m producing, doing so for the final .zip output file yields profile names with rather weird-looking duplicate 64-bit identifiers (e.g., “Mac10_12_3_64bitx64”). If you would like cleaner looking profile names (at the cost of losing the filename identifier denoting the arch build), you should instead drop the trailing identifier and provide a name the file like the following “10.12.3.zip”, thus yielding a prettier (IMO) profile name like “Mac10_12_3x64”.

Using Volatility for Analysis

Once we have successfully created the appropriate profile for the acquired image, we can now use the plethora of native Volatility Mac OSX plugins provided to us for analysis.

To see the list of available plugins, simply type the following:

#Executed from within the root /volatility folder of a git cloned repo
$ python vol.py --info | grep "mac_"

#Using the standalone binary
$ ./volatility_2.6_mac64_standalone --info | grep "mac_"

Conclusion

That pretty much wraps it up for this post. There is certainly more to explore with OSXpmem, the AFF4 format, and Volatility. However, I encourage you to explore it on your own as I would like to save some feature exploration for future in-depth posts focused on using both Volatility and the Rekall suite.

/JP

Previous

Mac Dumpster Diving – Identifying Deleted File References in the Trash (.DS_Store) Files – Part 2

Next

The Importance of Incident Scoping/Assessment

31 Comments

  1. Con

    JP, you mention running the 2.6 standalone and searching for “mac_” plugins. However, it appears that the standalone doesn’t include any OSX profiles. How would this ever work?

    • Great question! When using the standalone version, you will need to specify the directory containing the profiles (and/or add’l plugins) you’d like to use. For example, let’s say I created some Mac profiles on my system in /Projects/Mac_Profiles. I would first verify the standalone binary can see them by running the following:

      ./volatility_2.6_mac64_standalone –plugins=/Projects/Mac_Profiles/ –info | grep “mac_”

      Once verified that the profiles are listed, I could then use them to pares images by doing the following:

      ./volatility_2.6_mac64_standalone –plugins=/Projects/Mac_Profiles/ –profile=<profile_name> -f <image_file> <plugin>

      Hope that helps!

  2. swtruffle

    Just a quick thank you for the sierra profiles.

  3. Kevin

    Hello! I’ve got my removable drive formatted as HFS+, but when I chown -R root:wheel osxpmem.app/, the permissions remain as “_unknown”. How do I remedy this?

  4. Ank

    Thanks Jonathan!

    I have been trying to get this done over a year ago with no luck. I spent many hours trying to get a profile created then and was also assisted by the Volatility team without being able to create my own profile in the end. I then gave up.

    Today I had an new issue to solve, came across your post, and your steps to creating a profile for the latest version of OSX worked like a charm, the first time around.

    Thanks again!

  5. Giuseppe

    I tried also as root, but anyway I got this error:

    sh-3.2# chown -R root:wheel osxpmem.app/
    sh-3.2# cd osxpmem.app/
    sh-3.2# ls -l
    total 1288
    drwxr-xr–@ 3 root wheel 96 Mar 15 2016 MacPmem.kext
    -rw-r–r–@ 1 root wheel 4433 May 23 2016 README.md
    drwxr-xr–@ 18 root wheel 576 May 23 2016 libs
    -rwxr-xr–@ 1 root wheel 647392 May 23 2016 osxpmem
    sh-3.2# ./osxpmem -o ram.aff4
    Imaging memory
    E0718 23:27:21.518577 2710475648 aff4_file.cc:289] Can not open file /dev/pmem :No such file or directory
    /Users/peppespe/Downloads/osxpmem.app/./MacPmem.kext failed to load – (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
    E0718 23:27:21.980655 2710475648 osxpmem.cc:283] Unable to load driver at /Users/peppespe/Downloads/osxpmem.app/./MacPmem.kext
    E0718 23:27:21.980736 2710475648 pmem_imager.cc:328] Imaging failed with error: -8

    • Hi Giusuppe,

      Thanks for the message. What you are unfortunately experiencing is OSX SIP (System Integrity Protection). Apple has implemented this as of El Capitan (onward) which over the years has disabled various functionality, currently disabling direct memory reads via kernel extension (kext) even as root.

      At this point, there is no current workaround or solution other than using MacQuisition to acquire RAM (which requires a reboot and may lose some data).

      Check out @BriMorLabs’ recent Twitter and blog post about the issue here.

      • ramesh

        Thanks for sharing!

        FYI – even after disabling SIP, file ownership/permissions changed to “root:wheel” I continue to see file ownership/permissions error …. any clue ? Thanks again

        • Hi Ramesh,

          With all the recent major (and minor) changes to MacOS, it doesn’t surprise me that one day something works and the next it doesn’t. Unfortunately, it’s really hard to diagnose those kind of issues over the internet, especially as we’re all trying to keep up with the pace of updates from Apple and substantial changes/evolution in OS security.

          If possible, I’d suggest posting an issue to the Rekall github page to see if they can directly assist.

  6. Giuseppe

    I tried also as roomt on my Mac OS X v.10.13.5, but anyway I got this error:

    sh-3.2# chown -R root:wheel osxpmem.app/
    sh-3.2# cd osxpmem.app/
    sh-3.2# ls -l
    total 1288
    drwxr-xr–@ 3 root wheel 96 Mar 15 2016 MacPmem.kext
    -rw-r–r–@ 1 root wheel 4433 May 23 2016 README.md
    drwxr-xr–@ 18 root wheel 576 May 23 2016 libs
    -rwxr-xr–@ 1 root wheel 647392 May 23 2016 osxpmem
    sh-3.2# ./osxpmem -o ram.aff4
    Imaging memory
    E0718 23:27:21.518577 2710475648 aff4_file.cc:289] Can not open file /dev/pmem :No such file or directory
    /Users/peppespe/Downloads/osxpmem.app/./MacPmem.kext failed to load – (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
    E0718 23:27:21.980655 2710475648 osxpmem.cc:283] Unable to load driver at /Users/peppespe/Downloads/osxpmem.app/./MacPmem.kext
    E0718 23:27:21.980736 2710475648 pmem_imager.cc:328] Imaging failed with error: -8

  7. Laure

    Hello,
    Got a problem at step 5:
    $ python tools/mac/convert.py converted-10.14.3_x64.dwarfdump > 10.14.3_x64.vtypes

    Traceback (most recent call last):
    File “tools/mac/convert.py”, line 562, in
    main()
    File “tools/mac/convert.py”, line 559, in main
    parse_dwarf()
    File “tools/mac/convert.py”, line 399, in parse_dwarf
    parser.feed_line(line)
    File “tools/mac/convert.py”, line 132, in feed_line
    self.process_statement(**parsed)
    File “tools/mac/convert.py”, line 250, in process_statement
    off = float(data[‘AT_data_member_location’])
    ValueError: could not convert string to float: x00

    Did you have that error too?
    Thanks

    • Sorry, I have not. Though, my first instinct is to check if it’s a python version issue (code written in 2.x and your local python version is 3.x, or vice versa). Aside from that, your best bet for troubleshooting such issues would likely be to post a Github issue for the code.

      -JP

      • Peter

        Hi, I don’t know if you still check this page but I am getting

        “Python: can’t open file ‘tools/mac/convert.py’: [Errno 2] No such file or directory”

        Any ideas?

        • Hi Peter,

          Hard to say without knowing what you’re attempting to execute/do and where that error comes from.

          That looks like a relative path (relative to which directory you are currently in), so it appears it is not finding the file where it expects it to be relative to where you are. Ensure you are executing from the directory it expects you to operate from, or if you are able to specify the absolute full path to convert.py, that will work as well.

          JP

  8. Martin

    How do you get which MacOS you need if you have been provided with a memdump from MAC? You use strings I believe. Can you provide an example what is the output and how to determine what is the MacOS version?

    • Hi Martin,

      I’m not aware of any easy way to determine what OS X profile you need just using a memory image. The best way is identifying/collecting that info from the source system at the time of collection.

      To make OS X memory analysis further difficult, Volatility doesn’t maintain a very up to date set of profiles for analysis (not to mention Apple has made it increasingly impossible to easily collect memory from any recent OS X releases).

      My only suggestion here is to check out the docs at https://github.com/volatilityfoundation/volatility/wiki/Mac to understand how you might go about creating your own profiles to test/use against your existing image in hopes that one will work.

      JP

  9. Wolfram

    Hello Jonathon,

    I’m trying to get an memory dump on high sierra.
    Unfortunately I’m unable to load the MacPmem.kext extension, even after changes the permissions.
    Is there any way to get it running without restarting?

  10. sonicballz

    Thank you Jonathan!

    Despite following your awesome guide, I have trouble with the convert.py while trying to convert dwarfdump to converted-dwarfdump (linux style output).

    – My current MacOS system: Mojave 10.14.5.
    – KDKs tried: 10.12.3 (same as yours), 10.13.6, and 10.14.5
    – Volatility 2.6.1 and GitHub current master

    All of them result in an error in the very first line of dwarfdump:

    $ python volatility-2.6.1/tools/mac/convert.py ~/10.12.3_x64.dwarfdump ~/converted-10.12.3_x64.dwarfdump
    converting file
    State machine broken! level 0! /Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/kernel: file format Mach-O 64-bit x86-64

    could you please enlighten me?

    thank you in advance for your time!

    Here you are my dwarfdumps:

    10.12.3.dwarfdump.zip:
    https://mega.nz/#!FFc2nKYZ!q8GfCgxpwRUdfrozOCWMYoolMIIyNyy_93CZOe1GDXo
    10.13.6.dwarfdump.zip:
    https://mega.nz/#!dM8jDKra!Yx9-ILGFVEpKMG9jriSFDuae3CwIikm54iQAha7xA-4
    10.14.5.dwarfdump.zip:
    https://mega.nz/#!cR0w3QDQ!Bhq4brvSe9RPVq5kuPp9iqeU3QjtJR6AKAb02uLoRjA

    • Thanks for the kind words!

      Unfortunately, this is the current state of Volatility as they transition to Volatility 3. It appears the conversion process performed by Volatility’s convert.py code is broken for any recent version of OS X (i.e. MacOS).

      I tried to help someone else do this recently as well and found this out.

      https://twitter.com/JPoForenso/status/1177693476143525889

      I will update the post to reflect this.

      Thanks for the comment!

      JP

      • sonicballz

        Thank you a lot for taking your time to analyze and answer my question!

        Before bothering you, I tried finding and fixing the error myself but honestly I wasn’t able to grasp the logic behind the parsing.

        According to your observations, in this case, do you believe the convert.py logic is fixable by a “KDK, dawrf, dwarfdump and vtypes newbie” or it requires a more in deep knowledge, analysis and understanding of the MacOS operating system and it would be pretty much a waste of time?

        Thank you a lot again for your analysis and kind answer!!

        • Great question. I myself took a cursory look at the code when I was first looking at this error and didn’t see anything readily apparent to me that would equate to an “easy fix”.

          If I had to guess, I surmise there were substantial changes to the symbols format/conversion process at some point with 10.12(ish) and later and it’s likely the Volatility team deemed it more important to focus on a complete new rebuild that would fix/improve a lot of things at a much higher/holistic level (hence the recent version 3 beta release) than spending time attempting to fix existing problems including this one.

          But, that’s just my guess, and it makes sense if it’s so.

          TL;DR – I don’t think there’s an easy way around this, so we just wait in hopes that Volatility v3 allows us to re-enter the open source OSX memory acquisition/analysis arena 🙂

          JP

          • sonicballz

            JP,

            thank you a lot again for your time and kindness on analyzing and offering such a valuable answer!

            My best regards..

          • You got it. Happy to help however I can. Thanks again for the question and follow up.

            JP

  11. Rinchon sangkhro

    Hi, Jonathon

    All the steps worked out fine for me except number 9. I am trying to create a profile for 10.14.6

    The last command does not display any list of profile. The only thing I get is:
    Volatility Foundation Volatility Framework 2.6

    Could this mean that my profile wasn’t created?

    • Hi Rinchon,

      Assuming you’ve disabled SIP and are successfully running all the previous steps, try removing the `| grep “A profile for Mac”` portion of the command and manually look at the output to see if the 10.14.6 profile is properly listed as available. If not, it is likely the previous steps did not work (which has been the case for many). You can see some of the previous comments relating to issues trying to create profiles for any relatively recent versions of OS X.

      Hope that helps.

      JP

  12. Diana

    Hello, thank you for this very detailed tutorial. For 10.12, since there are pre-built profiles available, I downloaded and copied them to the volatility/plugins/overlays/mac folder, however, whenever I run the python vol.py –info, I only see windows profiles, not a single Mac profile. Is there something wrong that I am doing? I am new to this so I’m not sure how to go about it.

    • Hi Diana,

      My best guess, if they’re not showing up, is to make sure that the profiles you’ve copied there are readable (i.e. have proper read permissions) by Volatility to read them. Sometimes that can be the cause of them not showing up as available profiles in Volatility output.

      You can set some standard read permissions (in Linux) via chmod 444 plugin. You can also copy permissions from an existing plugin that works via chmod --reference=reference_file plugin.

      Hope that helps!

      JP

Leave a Reply

Your email address will not be published. Required fields are marked *

No Bots. No Spam. *

Powered by WordPress & Theme by Anders Norén