## Tutorial - Crafting input with zynamics BinNavi

Crafting input to reach a particular location in the code is a frequent task one encounters in security analysis. Perhaps a particular location in the executable has been pinpointed by a static analysis tool, perhaps the use of a tool like BinDiff leads one to think a particular location could be "interesting" if reached with the proper inputs.
In the following, we will show that a particular integer overflow patched in MS08-062 was not actually dangerous: A potential integer overflow was patched, but we will see that there appears to be no way to trigger this particular integer overflow.
We have used BinDiff (or a similar tool) to compare the patched against the unpatched version, and suspect that the following code might be one of the security vulnerabilities fixed in this update:

    5FEFF0DB shr   esi, byte 10
    5FEFF0DE inc   esi
    5FEFF0DF shl   esi, byte 10
    5FEFF0E2 add   esi, eax
    5FEFF0E4 push  esi // int
    5FEFF0E5 push  eax // int
    5FEFF0E6 push  ds:[ebx+0x18] // void
    5FEFF0E9 mov   ss:[ebp+arg_0], esi
    5FEFF0EC call  cs:_webRealloc@12
    5FEFF0F1 cmp   eax, edi
    5FEFF0F3 jz    byte cs:loc_5FEFF167

The right-shift-left-shift trickery has been replaced by prudent checking for integer overflows in the patched version - so it is reasonable to assume that this particular location needs to be reached with a malicious value of 0xFFFFFFFF in ESI.
We also know that msw3prt.dll is an ISAPI component - and that ISAPI components "begin" their active life in a function call "HttpExtensionProc".
Our goal can now be formulated as follows:

Construct malicious input that triggers the memory corruption problem discussed above.

In doing so, we will get to know some of the core features of BinNavi.

### Creating a project

Assuming that you have created and configured access to your central disassembly storage (e.g. the PostgreSQL server), your screen should look somewhat like this (click on the picture to enlarge it):

As a first step, we will now create a new project in which we will work. Right-click on the database you wish to use, and click Connect. Once you are connected, right-click on Projects, and create a new project named "MS08-62-.printer integer overflow". This is where we will keep all data related to this particular vulnerability.
BinNavi supports multiple address spaces per project - this is useful in many scenarios, for example when a vulnerability involves complicated interactions between processes. For our purposes, the default address space will do though.

Now, as next step, we need to import the disassembly of the file we're dealing with into our database. This is done via right-clicking on Raw Modules and selecting Import Raw Module. We then select the IDA database msw3prt.idb. BinNavi will launch an instance of IDA in the background, and the disassembly will be imported into the database in the zynamics core database format (see documentation) intended to be used by all sorts of reverse engineering tools.

Before BinNavi can use this data though, it needs to perform some minor conversions - for this, please right-click on the raw module you just imported, and convert it to a BinNavi module. Your screen should now look something like this:

Now, since we wish to work with msw3prt.dll, we need to make sure that this DLL is mapped into our default address space. You can just drag & drop arbitrary DLLs from the "modules" tree into your address space.
So, let's get to work.

In order to open the Call graph of the DLL we're working with, click on the "Default address space->msw3prt.dll" field. Do a right-click-open on the "native callgraph" entry in the middle of your screen.
Your screen should look roughly like the following:

You probably have worked through the Usage->Graph Window chapter of this manual. We will nonetheless spend a few minutes getting used to the user interface before we focus on constructing a path through the executable again.

### "Surfing" through the callgraph

Proximity browsing coupled with the "Undo Selection" and "Redo Selection"-hotkeys allows "surfing" through the Call graph in a rather comfortable manner. Please position your cursor in the search field and type "HttpExtensionProc" followed by "Enter". The node with this name will be made visible, the graph layout will be recalculated, and the node in which the search string was found will be centered on screen. Click on the HttpExtensionProc node to select it, and click on the "hierarchical layout" button to have the layout recalculated.
Your screen should look somewhat like this:

By default, the proximity browsing settings are configured so that all nodes within a distance of two "hops" from your selection are made visible. While this is useful for many scenarios, we want to change this for the Call graph "surfing" we're about to do. Please go to Graph->Proximity Browsing Settings and set both slides to 1. After you click OK, your screen should look roughly like this:

Our goal is now to understand the way we need to navigate from HttpExtensionProc to WebIppRcvData. In order to do this, please begin by clicking on the "hierarchical layout" button.

Now click on the node labeled "?ParseQueryString". This node will become selected and centered, with its immediate neighbors arranged around it. Please left-click the "?AllocString"-node now, and then left-click the "?StringCbCopy"-node, and finally, the "?StringCopyWorker"-node. You have just traversed the Call graph from the "root" (e.g. HttpExtensionProc) to one of the "leafs". If you hit "CTRL-Z" now, your last selection will be undone - moving you back to the node you had selected before the current selection. Hit "CTRL-Z" again, and again, to arrive at "?ParseQueryString" again.

If you hit "CTRL-Y", your selection is "redone" -- moving forwards again.

By using proximity browsing and the selection undo/redo, you can "surf" through the executable.

### Building a path through the executable

In order to build a path through the executable, we will begin by cutting down the Call graph to only those nodes that are of interest to us: Functions somewhere on the way between HttpExtensionProc and WebIppRcvData. Let's isolate these functions:

In the search window, search for WebIppRcvData. Select this node and click on the "select predecessors" button. Now only node sin the graph can lead to WebIppRcvData are selected. If you go to Graph->Delete Unselected Nodes, all nodes that are not on this path will be removed. Your result should look something like this:

This looks rather manageable, eh ? We will not need proximity browsing in such a small graph, therefore we can switch off proximity browsing in the Graph menu. Save this view (View->Save as) Right-click on WebIppRcvData and select Open Function.

The integer overflow in question occurred in basic block at address 0x5FEFF0DB in this function. We will now use the BinNavi Pathfinder plugin to generate a graph that shows us how we need to go about reaching the target address. In order to do this, switch to the database window again, and right-click on the msw3prt.dll module in the "modules" subtree. Your context menu should offer the option of running the Pathfinder plugin. Once you run it, you need to select a start- and endpoint for the path to be generated:

We select the beginning of HttpExtensionProc, and the target basic block 0x5FEFF0DB in WebIppRcvData. After we click OK, a new graphview will have been generated in our address space under msw3prt.dll->Module Views with the name "New Pathfinder View". If you open this view, you should see something like this:

The yellow block is our target block in WebIppRcvData, the green block is the starting point of HttpExtensionProc. This graph will be our "map" when we try to adjust our input to reach the vulnerability.

The first question is, clearly, how far down this path we can already go in "regular" execution. For this, we want to attach a debugger to the process we're targeting and see what we can reach.

### Configuring the debugger

BinNavi can communicate with a multitude of different debuggers over the network, each associated with a particular address space. This allows for great flexibility: For example, one could debug a Linux-based client in "lockstep" with a Win32-based server.

In order to configure a debugger for your BinNavi, go to the database window, and right-click on Debuggers. Create a new debugger (I call mine "WinXP VM") and set the IP address and port to the IP address of the machine where the BinNavi debugging agent is going to run.

Click on the MS08-62 project, and enable this debugger for this project by clicking the checkbox. Make sure you click on the "save" button after enabling the debugger.

Please select the default address space, and set the debugger to WinXP VM. Don't forget to click the save button!
Inside my Windows XP VM, I have enabled printer sharing, and configured IIS so that the .printer extension is properly passed on to msw3prt.dll.

The debug agent can be found in /BinNavi/debug/win32/client32.exe and is launched by supplying the process ID to be debugged as first argument.

In order to make sure the msw3prt.dll is loaded, we direct our browser to
http://172.16.155.132/printers/PDFCreator/.printer

Now close your views and reopen the path that was constructed (we need to do that since the views where opened before any debugger was configured). Click on the "connect to debugger" button in the debugger pane at the bottom of the screen. You should be greeted with the following screen:

Close the Debugger Options screen by clicking OK, and click on the "big red button" in the debugger pane. This will set breakpoints on all the nodes in the current graph view and allow us to understand which parts of the code we can already execute, and at which point we're taking a "wrong turn".

Now direct your browser to http://172.16.155.132/printers/PDFCreator/.printer again. The code will execute, and any breakpoints hit during this execution will be logged.

You can visualize which parts of the code you have successfully executed during this trace by clicking on the Traces tab. This tab will list all debug traces you have collected. In this screen, I have added a description to the debug trace (so that I can remember what I did to obtain the trace), and used the context menu to select the nodes executed in this trace.

This screen now tells us exactly where our code execution took a "wrong turn": The last selected node is exactly where we branched in the "wrong" direction. Use the paint bucket to color the currently selected nodes in a light hue of red, and zoom in on the branch we'd like to take.

If you do a shift + right click on any instruction prior to the branch, you will see that the address turns green. This means you've just set a breakpoint on the instruction in question. If you re-send your request now, the debugger should suspend on the location on which you set the breakpoint, and you should be able to inspect the register contents.

Single-stepping once, we can see that EAX contains the value "4" when we would like it to contain the value "1". Where is this value set ? If we search for "var_24" in our graph, we arrive at the following location:

We can see that the value is set to whatever was in arg_0->0x14 - and scrolling up a bit we see that this arg_0 was passed into the current function by a "push esi" at address 0x5FEF84FA, and that it was previously passed to ParseQueryString by these two lines:

    5FEF84EE push esi
    5FEF84EF call cs:?ParseQueryString@@YGHPAUALLINFO@@@Z

This leads us to the "guess" that the contents of the structure are initialized in said function. It would be nice if we could add this function to our graph, therefore we right-click on the node with the ParseQueryString-call and select "inline subfunction" for it.

The graph then looks like this:

We wish to set the value in question to 1 - so let's search for "0x14" in this graph and see where it might be set. The nicest way to do this is by using the "select by criteria"-dialog:

After selecting everything that contains 0x14 and coloring it in a bright yellow, the graph looks like this:

We will collect another trace in this graph with the same request, and select it again. This will immediately locate us the location at which the value in question was set:

The string that 0x5FEF1D74 points to is the string "POST" -- so clearly, we'd need to supply a "POST" request in order to get where we want to go. What does our trace look like if we send a simple POST ?
Also, we wanted to supply a length value of 0xFFFFFFFF for the integer overflow to work. Those of us that were around in 2002 remember vaguely that performing a chunked-encoding post to an IIS server will call the ISAPI in question with the cbTotalBytes length field set to 0xFFFFFFFF. We therefore create an artificial request as follows:

    POST /printers/PDFCreator/.printer HTTP/1.1
    Accept: */*
    Host: localhost
    Content-Type: application/x-www-form-urlencoded
    Transfer-Encoding: chunked
    Connection: keep-alive

    10
    PADPADPADPADPADP
    4
    XXXX
    4
    XXXX
    0

What does our trace look like now ?

We're much closer to where we want to be !
Let's have a look at the last branch in question:

    5FEFF0CC mov ecx, ds:[ebx+0x14]
    5FEFF0CF mov esi, ss:[ebp+arg_8]
    5FEFF0D2 mov eax, ds:[ebx+0x10]
    5FEFF0D5 add ecx, esi
    5FEFF0D7 cmp ecx, eax
    5FEFF0D9 jb byte cs:loc_5FEFF0FB

We need to be able to set ESI to 0xFFFFFFFF - so where did it come from ? Scrolling through our graph, we find it was passed into the current function here:

    FEF939F push ss:[ebp+arg_18] // int

Scrolling up one more block, we see the following code:

    5FEF988E push ds:[edi+0x74] // int
    5FEF9891 push ds:[edi+0x78] // hMem
    5FEF9894 push ds:[esi+12] // struct _IPPOBJ *
    5FEF9897 push ds:[esi+8] // unsigned __int16 *
    5FEF989A push ds:[esi+4] // hPrinter
    5FEF989D push ss:[ebp+arg_4] // __int16
    5FEF98A0 push edi // uBytes
    5FEF98A1 call cs:?Spl_IppJobData@@YGHPAU_EXTENSION_CONTROL_BLOCK

Unfortunately, this implies that we have no way of triggering this vulnerability: The argument passed in comes from [edi+0x74] - where edi points to the EXTENSION_CONTROL_BLOCK structure. This structure contains two length fields: cbTotalBytes at offset 0x70 which we can set to 0xFFFFFFFF, and cbAvailable which is located at offset 0x74 which we can only control within "reasonable" boundaries.

In the same graph, we can determine that the only other path leading to the integer overflow also passes the cbAvailable value to our target block. This means that there should be no way of triggering the integer overflow in question, irrespective of which path we take.