A reference implementation of a perfect in-memory dynamic library loader for Windows.
The implementation may be considered perfect because it does not reimplement LoadLibrary, an approach that is inherently incomplete.
Rather, the implementation redirects LoadLibrary to use in-memory data, creating a solution that will always have feature parity with the native Windows loader.
More information is available in the release blog for the project.
This project implements three solutions for redirecting LoadLibrary.
The first is based off of A-Normal-User's work of redirecting LoadLibrary by placing hooks on NtOpenFile and NtMapViewOfSection.
This project only requires a hook on NtMapViewOfSection for most Windows releases, but does require additional hooks to handle changes made in Windows 11 24H2.
The second solution uses a similar method to Process Doppelgänging of updating an opened file in a transaction and using it to create a section object.
The solution differs from Tal Liberman and Eugene Kogan's work by redirecting LoadLibrary to use the section instead of using the section to create a new process or thread.
To my knowledge, this is a novel approach to using transactions and I personally refer to it as Module Doppelgänging to acknowledge Tal and Eugene's prior work.
The third solution uses a similar method to CheckPointSW's VectoredOverloading code.
The solution differs by hooking NtCreateSection to modify its input parameters and NtMapViewOfSection to hollow the mapped view of the section.
This approach is called module or section hollowing and it is not affected by the Windows 11 24H2 loader changes that affect approach one.
Alex Short
has a similar POC for the approach which is worth referencing.
- x86 and x64 support
Load methods
- Manual mapping
- Module doppelgänging
- Module/section hollowing
Hook methods
- Detour patching
- Hardware breakpoints
- Process instrumentation callbacks (e.g. "nirvana hooks")
Pre/post processing options
- Remove module load notifications
- Remove or overwrite module headers
- Remove process instrumentation callbacks
- Remove vectored exception handlers
- Unlink module from loader lists
✏️ The Module Doppelgänging and hardware breakpoint options for injecting a module are currently not supported on WoW64 processes.
Perfect loader uses CMake to generate and run the build system files for your platform.
git clone https://github.com/EvanMcBroom/perfect-loader.git
cd perfect-loader/builds
cmake -A {Win32 | x64} [-D=PL_BUILD_GUI=OFF] ..
cmake --build .
By default CMake will build the following:
| Artifact | Description |
|---|---|
gui.exe |
The GUI utility for testing the project. |
pl.lib |
The main static library for the project |
pl.dll |
A DLL that exposes the functionality of the project as a single exported C API |
run.exe |
An example utility which uses the library to load a DLL from memory |
testdll.dll |
An example DLL which may be used with the run.exe utility |
The GUI utility requires Internet access during CMake's generate step to download files for Dear ImGui.
To disable building the GUI, you may specify -D=PL_BUILD_GUI=OFF when generating build files.
Other CMake projects may use perfect loader by calling include on this directory from an overarching project's CMakeLists.txt files.
Doing so will add the static library and the shared library with the C API as CMake targets in the overarching project but will not add the gui utility, run utility, or the testdll library.