Simple Loader (Pointer Patching)
This is a Simple Loader that bootstraps itself with GetModuleHandle and GetProcAddress pointers provided at package time.
Project Files
Notes
One of the first tasks facing position-independent codes is resolving Win32 APIs to do things. Many Tradecraft Garden examples use resolve_eat.h to walk the Export Address Table to find pointers to GetProcessAddress and LoadLibraryA.
This example deviates from that and relies on pointers specified at package time. This is feasible, because Win32 loads kernel32.dll at the same location in all processes. The location only changes on reboot.
The Crystal Palace ./link command accepts KEY=value arguments to pass data to the .spec file. For example, to set GetModuleHandle ($GMH) to 0x75711245 and GetProcAddress ($GPA) to 0x75711222, we would use:
./link patch/loader.spec demo/test.x86.dll out.bin GMH=45127175 GPA=22127175
The demo\run.x86.exe and demo\run.x64.exe included with Crystal Palace will print GMH and GPA values for you, when run with no arguments.
loader.c and loader.spec demonstrate two ways to pass data into Crystal Palace PIC. The first option, which works for both x86 and x64, is to push and link our data into the PIC. The other option, x64-only (for PIC), is to use patch to update the contents of global variables allocated inside of our PIC's .text section. If you're building x64-only DLL loaders, this latter option is what I would use.
Conversation
- Shellcode: Resolving API addresses in memory (2017) by Odzhan describes the history of shellcodes resolving GetProcAddress and GetModuleHandle and introduces EMET and Export Address Filtering.
- NT shellcodes prevention demystified (2005) by Piotr Bania. This paper details mitigation ideas to disrupt shellcode looking for GetProcAddress and GetModuleHandle pointers as their first action. I include this as a historical example of security researchers zeroing in on this part of the offense chain for a very long time.
- Proposed Windows 10 EAF/EMET "Bypass" for Reflective DLL Injection (2017) by Sean Dillon (zerosum0x0) reflects that we were in a "golden era" of Windows exploitation and post-exploitation. But, on the horizon, were mitigations like EMET's Export Address Filtering mitigation becoming more common in Windows applications. This blog post proposes architectural changes to Reflective Loading to work-around this type of mitigation.
- EDR Analysis: Leveraging Fake DLLs, Guard Pages, and VEH for Enhanced Detection (2023) by Daniel Feichter walks through an EDR's detection scheme based on catching shellcode trying to resolve kernel32 DLL and ntdll APIs in the traditional ways.
License
This project is licensed under the GNU General Public License version 2 (GPLv2) or later..