Loading Win32/64 DLLs "manually" without LoadLibrary()

• Download LoadDLL.zip (Visual C++ 2010 solution with example program and C/C++ DLLs) - 20.4 KB

Introduction

Sooner or later many people start thinking about loading a DLL without LoadLibrary(). OK, maybe not so many... It has only a few advantages and can introduce lots of inconvenience problems when coding the DLL (depending on what your DLL does) compared to a situation where you load the DLL with an ordinary LoadLibrary() call, so this technique has limited use. (I will aim the inconvenience problems below.) Still this tip can make good service as a tutorial if you want to understand what's going on behind the curtains... I myself used this stuff to write DLLs in C/C++ instead of coding offset independent assembly (in an anticheat engine), but that is another story.

Implementation

The most important steps of DLL loading are:

1. Mapping or loading the DLL into memory.
2. Relocating offsets in the DLL using the relocating table of the DLL (if present).
3. Resolving the dependencies of the DLL, loading other DLLs needed by this DLL and resolving the offset of the needed functions.
4. Calling its entrypoint (if present) with the DLL_PROCESS_ATTACH parameter.

I wrote the code that performed these steps but then quickly found out something is not OK: This loaded DLL doesn't have a valid HMODULE/HINSTANCE handle and many windows functions expect you to specify one (for example, GetProcAddress(), CreateDialog(), and so on...). Actually the HINSTANCE handle of a module is nothing more than the address of the DOS/PE header of the loaded DLL in memory. I tried to pass this address to the functions but it didn't work because windows checks whether this handle is really a handle and not only the contents of memory! This makes using manually loaded DLLs a bit harder! I had to write my own GetProcAddress() because the windows version didn't work with my DLLs. Later I found out that I want to use dialog resources in the DLL and CreateDialog() also requires a module handle to get the dialog resources from the DLL. For this reason I invented my custom FindResource() function that works with manually loaded DLLs and it can be used to find dialog resources that can be passed to the CreateDialogIndirect() function. You can use other types of resources as well in manually loaded DLLs if you find a function for that resource that cooperates with FindResource(). In this tip you get the code for the manual DLL loader and GetProcAddress(), but I post here the resource related functions in another tip.

Limitations

1. The loaded DLL doesn't have a HMODULE so it makes life harder especially when its about resources.
2. The DllMain() doesn't receive DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications. You could simulate this by creating a small DLL that you load with normal LoadLibrary() and from the DllMain() of this normally loaded DLL you could call the entrypoint of your manually loaded DLLs in case of DLL_THREAD_ATTACH/DLL_THREAD_DETACH.
3. If your DLL imports other DLLs, then the other DLLs are loaded with the WinAPI LoadLibrary(). This is actually not a limitation, just mentioned it for your information. Actually it would be useless to start loading for example kernel32.dll with manual dll loading, most system DLLs would probably disfunction/crash!
4. DLLs that make use of SEH *may* fail. The fact that the DLL contains SEH related code alone isn't a problem but the __try blocks in the loaded DLL won't be able to catch the exceptions because the ntdll.dll!RtlIsValidHandler() doesn't accept exception handler routines from the memory area of our manually loaded DLL (because this memory area isn't mapped from a PE file). This is a problem only if an exception is raised inside a __try block of the DLL (because windows can't run the exception handler of the DLL and raises another exception that escapes the exception handler of the DLL - the result is usually a crash).
5. Whether the CRT works with manual DLL loading or not depends on several things. It depends on the actual CRT version you are using and the functions you call from the CRT. If you are using just a few simple functions (like printf) then the CRT may work. I've written my DLLs with /NODEFAULTLIB linker option that means you can't reach CRT functions and it reduces your DLL size considerably (like with 4K intros). But then you have to go with pure WinAPI! This can be quite inconvenient but you can overcome this by writing your own mini CRT. I've provided one such mini CRT in my C++ example without attempting to be comprehensive but it at least allows you to use the most basic C++ features: automatically initialized static variables, new/delete operators. BTW, if you are about to use this code then you should understand most of these problems and you should appreciate that writing C/C++ DLL without CRT is still much more convenient than writing something as an offset independent or relocatable assembly patch.

Using the code

Write your DLL in C/C++. If you don't want to use the default CRT then link with /NODEFAULTLIB. It's a good practice to write your code so that a define can switch between original windows LoadLibrary() and the manual loader I provided (in my example solution you can do this by switching to the "Debug LoadLibrary" configuration). This way you can easily test whether a bug or crash happens because of manual loading or not and an additional benefit of being able to switch to the original windows LoadLibrary() is that you can debug the code of the DLL only that way (as the debugger identifies code only inside normally loaded modules).

With my manual loader you have to use my custom GetProcAddress() on the loaded DLL. If you want to use dialog resources (or some other kind of resource, but dialog is the most common) then you can use the FindResource() function I provided in one of my other tips (and the CreateDialogIndirect WinAPI function) because that works with both normally and manually loaded DLLs: The inner working of FindResource() and LoadString() Win32 functions. Download the attached VC++2010 solution that contains a sample program that loads and uses 2 DLLs. One DLL has been written in C and the other in C++.

History:

• Around 2000: The first spaghetti version of this code has born (Win32-only).
• 2012 July: Publication on codeproject in its original form.
• 2013 Sept: De-spaghettization of the code, adding 64 bit support and an example VC++2010 solution with DLL loading example with DLLs written in C and C++. The C++ DLL contains a mini home grown CRT.