Mac OS X memory analysis with Volafox

-
Mac OS X memory analysis with Volafox:

Kyeong-Sik Lee and the Korean Digital Forensic Research Center have released Volafox, a free and open-source tool to analyze Mac OS X memory images. Volafox is based on work by Matthieu Suiche (paper and slides) and the Volatility memory analysis framework.


Volafox is written in pure Python and requires Python 2.5 or later. You simply download and unzip the archive. The tool's usage is straight forward:



$ python volafox.py
Memory analyzer for OS X 0.5 - n0fate
Contact: rapfer@gmail.com
usage: python volafox.py -i MEMORY_IMAGE -s KERNEL_IMAGE -o INFORMATION

-= CAUTION =-
this program need to physical memory image, kernel image(mach_kernel)
and it support to Intel x86 Architecture only :(

INFORMATION:
os_version  Dawin kernel detail version
machine_info  Kernel version, cpu, memory information
mount_info  Mount information
kern_kext_info  Kernel KEXT(Kernel Extensions) information
kext_info  KEXT(Kernel Extensions) information
proc_info  Process list
syscall_info  Kernel systemcall information


The memory image needs to be in plain format. So, it can not process images that were obtained by ATC-NY's Mac Memory Reader without further format conversion. Having a Mach-O Address Space for this would be a nice addition.



While it should be possible to find the kernel in the memory dump, this has not been implemented (yet) and Volafox requires a separate kernel image.



For starters, I suggest to go with the sample files that were provided by the author: a memory image and the proper Mach kernel. Now let's find out about the OS version first:



$ python volafox.py -i MemoryImage.mem -s mach_kernel -o os_version
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: os_version
Detail dawin kernel version: 10A432


This command displays the ProductBuildVersion that you can also find in /System/Library/CoreServices/SystemVersion.plist.



Here is some more information about the machine:



$ python volafox.py -i MemoryImage.mem -s mach_kernel -o machine_info
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: machine_info

-= Mac OS X Basic Information =-
Major Version: 10
Minor Version: 0
Number of Physical CPUs: 2
Size of memory in bytes: 536870912 bytes
Size of physical memory: 536870912 bytes
Number of physical CPUs now available: 2
Max number of physical CPUs now possible: 2
Number of logical CPUs now available: 2
Max number of logical CPUs now possible: 2


Volafox can traverse the list of mounted file systems:



$ python volafox.py -i MemoryImage.mem -s mach_kernel -o mount_info
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: mount_info

-= Mount List =-
list entry fstypename mount on name mount from name
0304a290 hfs / /dev/disk0s2
03049948 devfs /dev devfs
03049000 autofs /net map -hosts
0403d520 autofs /home map auto_home
00000000 vmhgfs /Volumes/VMware Shared Folders .host:/


OS X maintains a doubly-linked list of processes; the list head is reachable via the kernproc symbol (see Mattieu Suiche's paper). 



$ python volafox.py -i MemoryImage.mem -s mach_kernel -o proc_info
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: proc_info

-= process list =-
list_entry_next pid ppid process name username
03290d20 0 0 kernel_task  
03290a80 1 0 launchdask n0fate 
032902a0 2 1 launchctlk root 
032907e0 10 1 kextddask root 
03290540 11 1 DirectoryService root 
03290000 12 1 notifydask root 
0359bd20 13 1 diskarbitrationd root 
0359ba80 14 1 configdask root 
0359b7e0 15 1 syslogdask root 
0359b540 16 1 distnotedk root 
0359b000 17 1 mDNSResponder _mdnsresponder 
0359b2a0 19 1 securitydk _mdnsresponder 
03a5a7e0 24 1 ntpdhdask _mdnsresponder 
03bc7d20 26 1 usbmuxdask _usbmuxd 
03bc7a80 30 1 mdschdask _mdnsresponder 
03bc77e0 31 1 loginwindow n0fate 
03bc72a0 32 1 KernelEventAgent _mdnsresponder 
03bc7000 34 1 hiddhdask _mdnsresponder 
03bdaa80 35 1 fseventsdk _mdnsresponder 
03befd20 37 1 dynamic_pager _mdnsresponder 
03bef7e0 42 1 autofsdask _mdnsresponder 
03a5a2a0 53 1 taskgatedk _usbmuxd 
03bdad20 54 1 coreservicesd root 
03a5a540 55 1 WindowServer root 
03bda540 57 1 vmware-tools-dae _mdnsresponder 
03a5a000 74 1 airportdsk _atsserver 
03befa80 78 1 coreaudiod _coreaudiod 
03bda2a0 79 1 launchdask n0fate 
03bef000 83 79 Dockhdask n0fate 
03bc7540 84 79 SystemUIServer n0fate 
04166d20 85 79 Finderask n0fate 
03bef2a0 92 79 fontddask n0fate 
041667e0 95 79 pboardask n0fate 
04166000 96 79 quicklookd n0fate 
044ddd20 99 79 UserEventAgent n0fate 
044dd000 100 79 ServerScanner n0fate 
044fed20 105 79 AirPort Base Sta n0fate 
044dd7e0 106 79 vmware-tools-use n0fate 
044dd540 108 79 CCacheServer n0fate 
03bda000 110 79 TISwitcher n0fate 
0085e758 120 1 backupdask n0fate


A process can be selected by its PID in order to display a few more details:



$ python volafox.py -i MemoryImage.mem -s mach_kernel -o proc_info -x 120
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: proc_info
Dump PID: 120

-= process: 120=-
list_entry_next pid ppid process name  username
0085e758 120 1 backupdask n0fate
task_ptr: 3bd81f4
vm_map_t: 41b2520
prev: 46145d8
next: 461402c
start: 100000000
end: 7fffffe00000
neutries: 3a
entries_pageable: 1
pmap_t: 3bf59f8
page directory pointer: 3bf5828
phys.address of dirbase: 4705c2400000000
object to pde: 1
ref count: 1
nx_enabled: 2
task_map: 0
pm_cr3: 0
pm_pdpt: 25c00000259
pm_pml4: 127df00000000000


Volafox also enumerates lists of kernel extensions and system calls. It will raise a flag if a syscall appears to be hooked.

Comments

Post a Comment

Popular posts from this blog

Investigating Indicators of Compromise In Your Environment With Latest Version of Redline

-
Image
Investigating Indicators of Compromise In Your Environment With Latest Version of Redline : Recently, Mandiant ® released a new version of Redline ™ . If you are not familiar with Redline, it is a great tool for investigating a specific Windows host in depth. We will have a more thorough look into Redline in the next month or so. What I wanted to touch on today is one of Redline’s brand new features: you can now use Indicators of Compromise (IOCs) to drive your Redline investigations. If you are not familiar with IOCs, I urge to you take a moment and head over to http://OpenIOC.org and have a look around. IOCs are the best way for finding indications of compromise and/or intrusion throughout your enterprise. IOCs are one of the main technologies that power Mandiant Intelligent Response, Mandiant’s flagship IR appliance, and have previously been accessible in free products with IOC Editor & IOC Finder . Some blog entries that might help bring you up to speed are Ryan Kazanciya...
Read more

Painting a Picture of W32.Flamer

-
Image
Painting a Picture of W32.Flamer : The number of different components in W32.Flamer is difficult to grasp. The threat is a well designed platform including, among other things, a Web server, a database server, and secure shell communications. It includes a scripting interpreter which allows the attackers to easily deploy updated functionality through various scripts. These scripts are split up into 'apps' and the attackers even appear to have something equivalent to an 'app store' from where they can retrieve new apps containing malicious functionality. To get an idea of how all these components fit together, the best place to start is a file called mssecmgr.ocx . This is W32.Flamer's main file and it is the first element of the threat executed by an infected computer. The file mssecmgr.ocx contains a large number of sub-components. A breakdown of the various components and how they are stored in this file are shown in Figure 1 below: Figure 1. Overview of W...
Read more

Flame: Bunny, Frog, Munch and BeetleJuice…

-
Image
Flame: Bunny, Frog, Munch and BeetleJuice… : As already mentioned in the previous blog post about Flame, the volume of its code and functionality are so great that it will take several months for a complete analysis. We’re planning on continually disclosing in our publications the most important and interesting details of its functionality as we reveal them.At the moment we are receiving many inquiries about how to check systems for a Flame infection. Of course the simplest answer, for us, is to advise to use Kaspersky Lab Antivirus or Internet Security. We successfully detect and delete all possible modifications of the main module and extra components of Flame.However, for those who want to carry out a detailed check themselves, at the end of this article we will give the necessary recommendations and advice. MSSECMGR.OCX The main module of Flame is a DLL file called mssecmgr.ocx. We’ve discovered two modifications of this module. Most of the infected machines contained its “big” ver...
Read more