• Windows (Win32) Shell coding pointers – I

    Although a bit dated, these pointers for shell coding provide a decent starting point for enthusiasts to go and poke around with binaries :-). Most of the information is collected from various texts on nologin.org (read win32-shellcode.pdf and many more) during the last few years and experiences with binaries. These pointers are definitely good for win 9x/2k/NT, some are applicable to XP too.

    Here we go!

    NT-based versions of Windows expose a system call interface through int 0×2e. Newer versions of NT, such as Windows XP, are capable of using the optimized sysenter instruction. Both of these mechanisms accomplish the goal of transitioning from Ring3, user-mode, to Ring0, kernel-mode.

    Windows, like Linux, stores the system call number, or command, in the eax register.

    The system call number in both operating systems is simply an index into an array that stores a function pointer to transition to once the system call interrupt is received.

    System call numbers are prone to change between versions of Windows whereas Linux system call numbers are set in stone. This difference is the source of the problem with writing reliable shell code for Windows and for this reason it is generally considered “bad practice” to write code for Windows that uses system calls directly

    Unlike Linux, Windows does not export a socket API via the system call interface. This immediately eliminates the possibility of doing network based shell code via this mechanism.

    In Windows, like Unix variants, standard user-mode API’s are exported in the form of dynamically loadable objects that are mapped into process space during run time. The common names for these types of object files are Shared Object (.so) or, in the case of Windows, Dynamically Linked Library (.dll).

    The possibility exists for users to change the address that kernel32.dll loads at by using the rebase.exe tool.

    The process of determining the kernel32.dll base address involves making use of the Process Environment Block (PEB).

    The operating system allocates a structure for every running process that can always be found at fs:[0×30] from within the process.

    The PEB structure holds information about the process’ heaps, binary image information, and, most importantly, three linked lists regarding loaded modules that have been mapped into process space. The linked lists themselves differ in purposes from showing the order in which the modules were loaded to the order in which the modules were initialized. The initialization order linked list is of most interest as the order in which kernel32.dll is initialized is always constant as the second module to be initialized. It is this fact that one can take the most advantage of. By walking the list to the second entry, one can deterministically extract the base address for kernel32.dll.

    DLL Portable Executable images have an export directory table. The export directory table holds information such as the number of exported symbols as well as the Relative Virtual Address (RVA) of the functions array, symbol names array, and ordinals array. These arrays match one-to-one with exported symbol indexes.

    To resolve a symbol one must walk the export table by going through the symbol names array and hashing the string name associated with the given symbol until it matches the hash of the symbol requested.

    A string can be optimized down into a four byte hash.

    Sometimes one can make use of a DLL’s Import Address Table to resolve the VMA of functions for use in a reliable fashion (used in Metasploit samples).

    Connectback shell code, or reverse shell as it is also called, is the process by which a TCP connection is established to a remote host and a command interpreter’s output and input are directed to and from the allocated TCP connection.

    Happy coding!