Setting Up

Windows shellcode suffers from one major problem: Win32 offers no way to obtain direct access to the system calls. Surprisingly, this peculiarity was deliberate . Typically all the things about Windows that make it awful are also the things that make it great. In this case, the Win32 designers can fix or extend a buggy internal system call API without breaking any of the applications that use Win32's higher-level API.

For a small piece of assembly code that happens to be running inside another program, your shellcode has its work cut out for it, as follows :

• It must find the Win32 API functions it needs and build a call table.

• It must load whatever libraries you need in order to get connectivity out.

• It must connect to a remote server, download more shellcode, and execute it.

• It must exit cleanly, resuming the process or simply terminating it nicely .

• It must prevent other threads from killing it.

• It must repair one or more heaps if it wants to make Win32 calls that use the heap.

Finding the needed Win32 API functions used to be a simple matter of hardcoding either the addresses of the functions themselves or the addresses of GetProcAddressA() and LoadLibraryA() for a particular version of Windows into your shellcode. This method is still one of the quickest ways to write Win32 shellcode, but suffers from being tied to a particular version of the executable or Windows version. However, as the Slammer worm taught us, hardcoding of addresses can sometimes be a valuable shellcoding method.

Note  

The Slammer source code is widely available on the Internet, and provides a good example of hardcoded addresses.

In order to prevent reliance on any particular state of the executable or OS, you must use other techniques. One way to find the location of functions is to emulate the method a normal DLL would use to link into a process. You could also search through memory for kernel32.dll to find the process environment block for kernel32.dll (this method is often used by Chinese shellcoders ). Later in the chapter we will show you how to use the Windows exception-handling system to search through memory.