MoVP II - 4.2 - Dumping, Scanning, and Searching Mac OSX Process Memory

In our previous post we discussed multiple ways of finding process structures in memory. Today we will discuss analysis of a process' address space. First we'll describe how Volatility handles all the possible scenarios that must be understood and properly implemented before you can access process memory on all Mac systems. Then we'll summarize some of the plugins that unlock the potential of Mac memory forensics once you have access to process memory - scanning for bash command history, looking for URLs or passwords in browser processes, dumping shared libraries and mapped files, etc.

Reading Mac Process Memory

The development phase of adding support for Mac process address spaces was a bit challenging. Mac setups have very unusual sharing of user and kernel virtual addressing and they use different architectures for processes and the kernel. This is drastically different from Windows and Linux.

To determine which hardware architecture to assign a process both the value of "x86_64_flag" as well as the process architecture must be known. The "x86_64_flag" tells whether the hardware used on the computer from the memory sample is capable of running in 64 bit mode or not.

With this information we can discuss all of the possibilities that Mac presents. If you would like to see the code that implements this logic, read the get_process_address_space function.

32 bit process on non-64 bit capable systems

This occurs on old computers that are not capable of running in 64 bit mode. The only sample we received like this came from a very old Mac that was running 10.5.x. On these systems, there is no splitting of the virtual addresses between userland processes and the kernel. This means we need to instantiate a new 32 bit PAE address space with the dtb value of the process.

32 bit process on 64 bit capable systems

This occurs when a 32 bit process is running on a 64 bit capable system. For this we must force a 64 bit address space to correctly translate process memory even though the process is running as 32 bit. 

64 bit process running on a 32 bit system

This occurs when 64 bit processes are running on a 32 bit kernel (no other major operating system supports this). We must force a 64 bit address space to properly translate process memory.

64 bit process on a 64 bit system

This is true 64 bit addressing and simply requires the use of the 64 bit address to correctly translate addresses.

Mac's very odd combinations of translation requirements is one of the stranger things we have encountered during memory forensics research and required a team effort to get all the details and possibilities sorted and tested.

mac_proc_maps

This plugin walks a process' memory mappings and prints the PID and name of the process along with the starting and ending address, permissions, and path of mapped file (if any), for each mapping.

$ python vol.py --profile=MacMountainLion_10_8_3_AMDx64 -f ~/10.8.3.mmr.macho mac_proc_maps --pid=1 
Volatile Systems Volatility Framework 2.3_alpha
Pid      Name                 Start              End                Perms     Map Name
-------- -------------------- ------------------ ------------------ --------- --------
1        launchd              0x000000010630c000 0x0000000106333000 r-x       Macintosh HD/sbin/launchd 
1        launchd              0x0000000106333000 0x0000000106335000 rw-       Macintosh HD/sbin/launchd
1        launchd              0x0000000106335000 0x000000010633b000 r--       Macintosh HD/sbin/launchd
1        launchd              0x000000010633b000 0x000000010633c000 r--        
1        launchd              0x000000010633c000 0x000000010633f000 r-x       Macintosh HD/usr/lib/libauditd.0.dylib
1        launchd              0x000000010633f000 0x0000000106340000 rw-       Macintosh HD/usr/lib/libauditd.0.dylib
1        launchd              0x0000000106340000 0x0000000106343000 r--       Macintosh HD/usr/lib/libauditd.0.dylib
1        launchd              0x0000000106343000 0x0000000106344000 r--       
1        launchd              0x0000000106344000 0x0000000106345000 rw-       Macintosh HD/private/var/db/dyld/dyld_shared_cache_x86_64
[snip]

This can be used to determine which shared libraries a process is using as well as where the stack and the heap are. If you want to analyze a specific region of memory, you will need to know the starting address of the mapping in order to pass it to mac_dump_maps.

mac_dump_maps

This plugin writes specified regions of process memory to disk. If no filters are specified then it dumps all regions from all processes to disk, which will likely be overwhelming unless you are looking to mass scan using tools such as AV or Yara.

In this example we dump the launchd binary from memory to disk. It could then be loaded into any reverse engineering tool. The starting address comes from the previous mac_proc_maps output.

$ python vol.py --profile=MacMountainLion_10_8_3_AMDx64 -f ~/10.8.3.mmr.macho mac_dump_maps --pid=1 --map-address=0x000000010630c000 --outputfile=launchd.binary.dmp
Volatile Systems Volatility Framework 2.3_alpha
Wrote 159744 bytes

$ file launchd.binary.dmp
launchd.binary.dmp: Mach-O 64-bit executable x86_64

mac_yarascan

Volatility already provides you with the ability to scan Windows and Linux memory dumps with yara signatures. There's no reason Mac should be an exception! Now you can run your rules against all of your Mac memory dumps as well.

$ python vol.py --profile=MacMountainLion_10_8_3_AMDx64 -f ~/Desktop/Storage/memory/Mac/10.8.3/10.8.3.mmr.rawpad mac_yarascan -p 261 -Y "http"
Volatile Systems Volatility Framework 2.3_beta

Task: Google Chrome pid 261 rule r1 addr 0x73c6a0d
0x00000000073c6a0d  68 74 74 70 73 3a 2f 2f 63 6f 64 65 2e 67 6f 6f   https://code.goo
0x00000000073c6a1d  67 6c 65 2e 63 6f 6d 2f 70 2f 76 6f 6c 61 74 69   gle.com/p/volati
0x00000000073c6a2d  6c 69 74 79 2f 77 69 6b 69 2f 52 65 6c 65 61 73   lity/wiki/Releas
0x00000000073c6a3d  65 32 33 52 65 6c 65 61 73 65 32 33 20 2d 20 76   e23Release23.-.v

Task: Google Chrome pid 261 rule r1 addr 0x73c6acf
0x00000000073c6acf  68 74 74 70 3a 2f 2f 65 6e 2e 77 69 6b 69 70 65   http://en.wikipe
0x00000000073c6adf  64 69 61 2e 6f 72 67 2f 77 69 6b 69 2f 54 7a 5f   dia.org/wiki/Tz_
0x00000000073c6aef  64 61 74 61 62 61 73 65 01 00 00 2e 37 9a ee 58   database....7..X
0x00000000073c6aff  90 57 00 00 81 3d 8b 25 0a 00 82 27 41 01 01 06   .W...=.%...'A...

Task: Google Chrome pid 261 rule r1 addr 0x9bc70e0
0x0000000009bc70e0  68 74 74 70 73 3a 2f 2f 74 77 69 74 74 65 72 2e   https://twitter.
0x0000000009bc70f0  63 6f 6d 2f 67 6c 65 65 64 61 00 00 36 00 2c 00   com/gleeda..6.,.
0x0000000009bc7100  31 00 32 00 30 00 35 00 37 00 30 00 31 00 2c 00   1.2.0.5.7.0.1.,.
0x0000000009bc7110  36 00 32 00 38 00 38 00 39 00 30 00 39 00 34 00   6.2.8.8.9.0.9.4.

Conclusion


In this post we have discussed how to analyze and access userlarnd memory of Mac OS X processes. We have also discussed how Mac utilizes differing hardware architectures and virtual address translation schemes in ways not done by any other major operating system. The ability to dump, scan, and search process memory gives you the ability to attribute data back to its owning process and identify which process(es) had access to data that may be interesting to your investigation.