Now that you’ve got a clean up-to-date instance of Immunity Debugger with, there are a few options that need to be configured.

Mona uses the concept of a working directory to write it’s output files.  Essentially everything that does gets written to output log files.  Inside of the working directory mona will create a directory for each process it debugs.  When we specify our working directory, we can use the two format specifiers %p and %i to tell mona to use the process name and pid inside the name respectively.  Since mona is creating folders and files, the Immunity Debugger process must have r/w access to the directory you give it.  Unless you’ve done strange things to your windows install, you needn’t worry about this issue.

Here’s how I’ve set up mona’s working directory on my machine:

!mona config -set workingfolder c:\monalogs\%p_%i

and set yourself as the author.  This will be used when you ask mona to create metasploit exploit / script skeletons.

!mona config -set author bsmartt

Here’s how mona should have responded:

fig. 2-1

Now, if you are like me and running vmware, we need to let mona know about this.  Mona does a lot of complex memory analysis in which is parses different modules loaded into memory looking for things that may be useful to us.  Since we want our exploits to be as universal as possible, we will need to not use anything from VMWare.  If you explore c:\program files\VMWare\VMWare Tools\, you will notice that there are multiple dlls inside of a few different folders.  The dll files that are inside the root directory of VMWare Tools share the name of common windows dll files, which are to be used instead of the windows common files.  We cannot exclude all of these from Mona due to possible overlap.  If you are unsure, you can always google it to see if it belongs to windows or vmware (the modules VMToolsHook.dll and vmtools.dll can be excluded, as is obvious by their name).  Starting with c:\Program Files\VMWare\VMWare Tools\win32\, we find two dll files, and upon searching google find out that they are not names of windows common dlls.  We can use the -set command to create the list of excluded modules and add a few to it.   From then on, we will use the -add command to add to the list.  It is important to get into the habit of checking the log windows while interacting with mona to ensure that you don’t make a mistake.

!mona config -set excluded_modules “vmGuestLibJava.dll,vmGuestLib.dll”

Now, lets go to a different folder, plugins.  It contains a few subfolders, lets pick ..\VMWare Tools\plugins\common\ and add these modules to the list:

!mona config -add excluded_modules “hgfsServer.dll,hgfsUsability.dll,thinprint.dll,vix.dll”

When you use the -add excluded_modules command, mona will show you what the list looks like before, what you’re attempting to add to it, and what it looks like after.  I highly recommend checking all of this output to make sure you didn’t make an error.  I added modules from the following folders to my excluded list:

c:\Program Files\VMWare\VMWare Tools\plugins\vmsvc\

c:\Program Files\VMWare\VMWare Tools\plugins\vmusr\

c:\Program Files\VMWare\VMWare Tools\Drivers\hgfs\

I recommend adding modules in small groups.  Immunity’s doesn’t fully support line wrapping, and it may start to get very confusing when you cant tell which modules got added and which didn’t.

I urge you to take the time to think about your windows machine.  What services are you running that you can’t assume other are as well?  One other that I have on my windows XP box is cygwin, which certainly can’t be assumed to be on every computer.

To end this tutorial, we will open the help menu:

!mona help

fig. 2-2

Inside the orange box you can see a list of all the commands mona knows.  For example, to get further help about seh, we can type:

!mona help seh

You now know how to fully learn mona on your own.  In the next part of this tutorial, we will see mona in action.



Knowledge of how to exploit the Windows Structured Exception Handler will be required for the next section: