Hooking LoadLibrary API call

Question

I want to load a different version of a DLL than is present in the working directory of the application. For this I need to hook the LoadLibrary call so that when the application makes a call to load the DLL I can substitute it with the newer version of that DLL transparently. I tried using NCodeHook and have the following code in my DLL which I inject into the application using NInjectLib but it crashes while loading kernel32.dll. Can anybody please tell me if this is the correct way of injecting the call or are there any other alternatives.

        // CodeHook.cpp : Defines the entry point for the DLL application.
//

#include "stdafx.h"
#include <NCodeHookInstantiation.h>
#include "CodeHook.h"

#ifdef _MANAGED
#pragma managed(push, off)
#endif

typedef HMODULE (WINAPI *LoadLibraryFPtr)(LPCTSTR dllName);

#pragma data_seg("SHARED")
LoadLibraryFPtr origFunc = NULL;
#pragma data_seg()          

#pragma comment(linker, "/section:SHARED,RWS")


HMODULE WINAPI LoadLibraryHook(LPCTSTR dllName)
  {
   if (origFunc != NULL) 
   {
  return origFunc(dllName);
   }
  }



BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
      )
{
    return TRUE;
}

CODEHOOK_API void Initialize (void) 
{ 
 NCodeHookIA32 nch;
 origFunc = nch.createHookByName("kernel32.dll", "LoadLibrary", LoadLibraryHook);
}

#ifdef _MANAGED
#pragma managed(pop)
#endif

Answer 1

I don't know the NCodeHook library, but one important thing to know is that there are actually 2 versions of the LoadLibrary function: LoadLibraryA(LPCSTR) and LoadLibraryW(LPCWSTR). Make sure you hook the correct one and use the appropriate function definition. You may also need to hook LoadLibraryExA/LoadLibraryExW

Detours is a more widely known library for API hooking. Also see this article for more hooking techniques.

Answer 2

There are lots of pitfalls associated with API hooking. I don't know specifics about the NCodeHook implementation, but there is potential for trouble if the API hooking code doesn't properly deal with non-writable pages. One would assume that the library would call VirtualProtect and that the OS would properly handle copy-on-write, but it's hard to say.

I agree with the comment that this might not be the best solution to your problem. API hooking relies on the application binary interface, which is quasi-documented at best. I would not recommend it for a commercial app that is intended for production use.

Side-by-side assemblies would definitely be useful, as the strong name removes any ambiguities about which DLL needs to be loaded. Alternatively, consider using LoadLibraryEx with an absolute path to the DLL and the LOAD_WITH_ALTERED_SEARCH_PATH flag.