Debugging Windows

You have basically three options for debugging Windows: the Microsoft tool chain, WinDbg; a kernel debugger, SoftICE; or OllyDbg. You can also use Visual Studio if you're so inclined.

Of these options, SoftICE is perhaps one of the oldest and most powerful. SoftICE features a macro language and can debug kernelspace. The downside of SoftICE is that it can be nearly impossible to install, and the GUI is somewhat old-school. Its main use is for debugging new device drivers. For a long time it was the only choice for a hacker, and so several good texts are available on how to use it. While debugging the kernel, SoftICE sets all the pages to writable; be aware of this fact if a kernel overflow you are working with seems to work only while SoftICE is enabled.

WinDbg can be set up to debug a kernelalthough it requires a serial cable and another computerbut it can also be extremely good for debugging an overflow in user space. WinDbg has a primitive language, but the user interface is terriblealmost impossible to use quickly and accurately. Nevertheless, because Microsoft uses this debugger, it does have a few nifty advanced features, like automatic access to their symbol server.

Just as SPIKE is the best fuzzer ever created, OllyDbg is the best debugger ever created. It supports amazing features such as run-traces (which allow you to execute backwards ) memory searching, memory breakpoints (you can tell it to, for example, set a break every time someone accesses anything in MSVCRT.DLL 's global data space), smart data windows (such as the ones above displaying the thread structure), an assembler, a file patcherbasically everything you need. If WinDbg doesn't support something you need, you can e-mail the author and the next version probably will. Spend some time attaching to processes with OllyDbg, then fuzzing them with SPIKE and analyzing their exceptions. This will get you quickly familiar with OllyDbg's excellent GUI.

Bugs in Win32

There are many bugs in Win32, and many of these are undocumented and painfully discovered by people writing shellcode. For example, Load_LibraryA() , which loads a DLL into memory, will fail if a period is in the PATH and the machine has not been patched for this particular bug. The WinSock routines will fail if the stack is not word aligned. Various other APIs are poorly documented on MSDN, if at all.

The bottom line is: When your shellcode is not working, the reason could quite possibly be a bug in Windows, and you might have to simply work around it.

Writing Windows Shellcode

Writing reliable Windows shellcode was for a long time a somewhat secret affair. The problem is that, unlike in Unix shellcode, you don't have system calls with a known API. Instead, the process has loaded function pointers to external functions such as CreateProcess() or ReadFile() into various places in memory. But you, the attacker, don't know where in memory these happen to be. Early shellcode just assumed they were in a certain place or guessed that they were in one of a few places. But this means that every time you create an exploit, you must version it across several different service packs or executables.

The trick to writing reliable and reusable shellcode is that Windows stores a pointer to the process environment block at a known location: FS:[0x30] . That plus 0xc is the load order module list pointer. Now, you have a linked list of modules you can traverse to look for kernel32.dll . From that you can find LoadLibraryA() and GetProcAddress() , which will allow you to load any needed DLLs and find the addresses of any other needed functions. You'll want to go back and reread the PE-COFF document from Microsoft's shellcode to do this.

This technique, however, tends to result in huge shellcode. Shellcode using this technique can range from 300 to 800 bytes, depending on functionality. Halvar Flake's code is highly optimized and is somewhere around 290 bytes.

There is, of course, another way. Various Chinese hackers have been writing shellcode that hunts through memory for kernel32 by setting an exception handler. See various NSFOCUS exploits for this technique put into practice against IIS.

Even this shellcode can be fairly large. Therefore, CANVAS uses a separate shellcode, which is 150 bytes encoded using CANVAS's chunked additive encoder (similar to an XOR encoder/decoder but using addl instead of xorl ), which simply uses exception handling to hunt through all the process memory for another set of shellcode prefixed with 8 bytes of tag value. This shellcode has proven to be highly reliable, and since you can put your main payload anywhere in memory, you don't have to worry about space restrictions.

A Hacker's Guide to the Win32 API

VirtualProtect() Sets the access control to a page of memory. Useful for changing .text segments to +w so that you can modify functions.

SetDefaultExceptionHandler Disassemble this to find the global exception handler location for a given service pack.

TlsSetValue()/TlsGetValue() Thread Local Storage is a space that each thread can use to store thread-specific variables (other than the stack or heap). Sometimes valuable pointers that your shellcode may want to ravage are located here.

WSASocket() Calling WSASocket() instead of socket() sets up a socket you can use directly as standard in or standard out. This technique can be used to make smaller shellcode if you're using shellcode that spawns a cmd.exe . (The problem in socket handles created with socket() is in the SO_OPENTYPE attribute.)

A Windows Family Tree from the Hacker's Perspective

Win9X/ME

No user or security infrastructure (largely obsolete).

WinNT

Hugely buggy RPC libraries make owning RPC services easyRPC data structures are not verified by default the way they are in Win2K, so almost any bad data will make them crash.
Doesn't support some NTLMv2 and other authentication options, making sniffing nicer.
IIS 4.0 runs entirely as system and doesn't restart after it crashes.

Win2K

NTLMv2 makes headway among entirely Win2K installation bases.
RPC libraries much less buggy than NT 4.0 (which isn't saying much).
SP4Exception registers are cleared.
IIS 5.0 runs as system, but most URL handlers don't run as system (with the exception of FrontPage, WebDav, and the like).

Win XP

Addition of Vectored Exception Handling makes things easier for heap overflows.
SP1Exception registers are cleared.
IIS 5.1URLs are limited to a reasonable size .

Windows 2003 Server

Entire OS compiled with stack canary , including kernel.
Parts of IIS moved into the kernel.
IIS 6.0 still written in C++, now runs under an entirely different setup with a management process and a bunch of managed processes, each of which can serve port 80/443 from particular URLs and virtual hosts .
Can finally detach from a process without it crashing. In previous versions of Win32, if you attached to a process with the debugger, detaching would forcefully kill it. This was useful sometimes, but mostly just annoying.