A popular user-mode debugger is OllyDbg, which can be found at www.ollydbg.de. As can be seen in Figure 11-2, the OllyDbg main screen is split into four sections. The Code section is used to view assembly of the binary. The Registers section is used to monitor the status of registers in real time. The Hex Dump section is used to view the raw hex of the binary. The Stack section is used to view the stack in real time. Each section has con- text-sensitive menus available by right-clicking in that section.
You may start debugging a program with OllyDbg in three ways:
• Open OllyDbg program; then select File | Open.
• Open OllyDbg program; then select File | Attach.
• Invoke from command line, for example, from a Metasploit shell as follows:
$Perl –e "exec '<path to olly>', 'program to debug', '<arguments>'"
254
Figure 11-2 Main screen of OllyDbg
For example, to debug our favorite meet.exe and send it 408As, simply type
$ Perl -e "exec 'F:\\toolz\\odbg110\\OLLYDBG.EXE', 'c:\\meet.exe', 'Mr',('A' x 408)"
The preceding command line will launch meet.exe inside of OllyDbg.
When learning OllyDbg, you will want to know the following common commands:
Shortcut Purpose
F2 Set breakpoint (bp)
F7 Step into a function
F8 Step over a function
F9 Continue to next bp, exception, or exit
CTRL-K Show call tree of functions
SHIFT-F9 Pass exception to program to handle
Click in code section, pressALT-Efor list of linked executable modules
List of linked executable modules Right-click on register value, select Follow
in Stack or Follow in Dump
Look at stack or memory location that corresponds to register value
CTRL-F2 Restart debugger
When you launch a program in OllyDbg, the debugger automatically pauses. This allows you to set breakpoints and examine the target of the debugging session before continuing. It is always a good idea to start off by checking what executable modules are linked to our program (ALT-E).
255
PARTIII
In this case, we see that only kernel32.dll and ntdll.dll are linked to meet.exe. This infor- mation is useful to us. We will see later that those programs contain opcodes that are available to us when exploiting.
Now we are ready to begin the analysis of this program. Since we are interested in the strcpyin thegreetingfunction, let’s find it by starting with the Executable Modules win- dow we already have open (ALT-E). Double-click on themeetmodule from the execut- able modules window and you will be taken to the function pointers of themeet.exe program. You will see all the functions of the program, in this casegreetingandmain.
Arrow down to the “JMP meet.greeting” line and pressENTERto follow thatJMPstate- ment into thegreetingfunction.
NOTE if you do not see the symbol names such as “greeting”, “strcpy”, and
“printf”, then either you have not compiled the binary with debugging symbols, or your OllyDbg symbols server needs to be updated by copying the dbghelp.dll and symsrv.dll files from your debuggers directory to the Ollydbg folder. This is not a problem; they are merely there as a convenience to the user and can be worked around without symbols.
Now that we are looking at the greeting function, let’s set a breakpoint at the vulnera- ble function call (strcpy). Arrow down until we get to line 0x00401034. At this line press F2to set a breakpoint; the address should turn red. Breakpoints allow us to return to this point quickly. For example, at this point we will restart the program withCTRL-F2and then pressF9to continue to the breakpoint. You should now see OllyDbg has halted on the function call we are interested in (strcpy).
Now that we have a breakpoint set on the vulnerable function call (strcpy), we can continue by stepping over thestrcpyfunction (pressF8). As the registers change, you will see them turn red. Since we just executed thestrcpyfunction call, you should see many of the registers turn red. Continue stepping through the program until you get to line 0x00401057, which is the RETN from thegreetingfunction. You will notice that the debugger realizes the function is about to return and provides you with useful informa- tion. For example, since the savedeiphas been overwritten with fourAs, the debugger indicates that the function is about to return to 0x41414141. Also notice how the func- tion epilog has copied the address of esp into ebp and then popped fourAs into that location (0x0012FF64 on the stack).
256
As expected, when you pressF8one more time, the program will fire an exception. This is called afirst chance exception, as the debugger and program are given a chance to handle the exception before the program crashes. You may pass the exception to the program by pressingSHIFT-F9. In this case, since there are no exception handlers in place, the pro- gram crashes.
After the program crashes, you may continue to inspect memory locations. For exam- ple, you may click in the stack section and scroll up to see the previous stack frame (that we just returned from, which is now grayed out). You can see (on our system) that the beginning of our malicious buffer was at 0x0012FDD0.
257
PARTIII
258
To continue inspecting the state of the crashed machine, within the stack section, scroll back down to the current stack frame (current stack frame will be highlighted).
You may also return to the current stack frame by clicking on the ESP register value to select it, then right-clicking on that selected value and selecting Follow in Stack. You will notice that a copy of the buffer is also located at the locationesp+4. Information like this becomes valuable later as we choose an attack vector.
Those of you who are visually stimulated will find OllyDbg very useful. Remember, OllyDbg only works in user space. If you need to dive into kernel space, you will have to use another debugger like WinDbg or SoftIce.