I'd like to prevent a specific third-party DLL file from loading into my application's process at runtime. My initial attempt at this was using the MS Detours product.
I have a 32-bit MFC application running on Windows 10 64-bit. I tested with the free MS Detours 3.0 version as a feasibility check.
In my MFC application class constructor, I call Detours to intercept the "load library" APIs (LoadLibraryW, LoadLibraryExW, LoadLibraryA, and LoadLibraryExA). This lets me intercept library loading and currently I just log out the name of the library being loaded and then call the original API so it proceeds to load the library. The eventual plan would be to look for the specific third-party DLL file name and in that case just return failure, preventing the DLL file from loading.
This sort of works. When I run my test application, close it, and then check the log I see a bunch of library load messages logged from my intercept functions.
BUT, my code never sees the particular third-party DLL file I'm looking for. What's happening is that the third-party DLL file is already loaded by the time I get to my application class constructor. So I'm too late!
How can I get some code to execute EARLIER and so hopefully install the detours stuff BEFORE the third-party library gets injected?
Sounds like either:
your app is static linking to the target DLL directly
one of your app's dependent DLLs is static linking to the target DLL, or otherwise loading it while itself is being loaded.
the target DLL is listed in the AppInit_DLLs Registry key.
another process has loaded the DLL as a global hook via SetWindowsHookEx(), using a hook type that injects the DLL into all running processes.
Nothing you can do to intercept the target DLL if it is being loaded before your app's code starts running. Statically linked DLLs are loaded by the OS before the EXE's code starts running. So only dynamically loaded DLLs can be intercepted with a detour, and only if loaded after you have installed you detour.
You need to find where the target DLL is actually being loaded from.
If your EXE is static linking to it directly, load it dynamically instead, either explicitly via LoadLibrary() in your code, or via your linker's delay-load feature (if it has one), which uses LoadLibrary() internally.
If another DLL is loading it, load that DLL dynamically instead of static linking to it.
Probably, your code is referencing some function / export of the third part library.
One way you can try is to use /DELAYLOAD linker option to create stub function for the imported function.
See https://msdn.microsoft.com/en-us/library/151kt790.aspx for an explanation and requirements.
You can even provide an helper function to handle the loading of your dll, so you don't need retour.
