Just Curious

Hi all,

This is about the concept of hooking APIs.

Jeff Richter says in this book Programming Applications for MSWin 4th Ed. pg
818

HMODULE WINAPI CAPIHook::LoadLibraryExA(PCSTR pszModulePath, HANDLE hFile,
WORD dwFlags)
{

HMODULE hMod=::LoadLibraryExA(pszModulePath,hFile,dwFlags);
FixupNewlyLoadedModule(hMod,dwFlags);

}

He is essentially hooking into LoadLibrary itself so that all modules loaded
there after can be patched if need be. This is fine.

If I know the hooking logic correctly, then it is like this…

  1. You get the address of an exported function.
  2. Replace that address in the IAT with that of yur function, which has the
    exact same signature as the old one, ofcourse after storing away the
    original address in a function pointer.
  3. Now when the original function is called, the call comes to our function,
    we play aroud with it and then (maybe) call the original fucntion through
    the function pointer.

This works for C programs, and I am a C programmer, however, in the above
code, Jeff calles the original LoadLibraryExA( )…

HMODULE hMod=::LoadLibraryExA(pszModulePath,hFile,dwFlags);

The scope resolution operator seems to have done aways with the function
pointer concept.

I cannot understand how this happens. Maybe my C++ concepts are junk, but
can someone enlighten me please.

Thanks

  • Amitrajit

Developer wrote:

Hi all,

This is about the concept of hooking APIs.

Jeff Richter says in this book Programming Applications for MSWin 4th
Ed. pg 818

HMODULE WINAPI CAPIHook::LoadLibraryExA(PCSTR pszModulePath, HANDLE
hFile, WORD dwFlags)
{
HMODULE hMod=::LoadLibraryExA(pszModulePath,hFile,dwFlags);
FixupNewlyLoadedModule(hMod,dwFlags);
}

He is essentially hooking into LoadLibrary itself so that all modules
loaded there after can be patched if need be. This is fine.

No, that’s not what he’s doing. This is NOT hooking LoadLibraryExA.
This is just a wrapper around it. More later…

If I know the hooking logic correctly, then it is like this…

  1. You get the address of an exported function.
  2. Replace that address in the IAT with that of yur function, which
    has the exact same signature as the old one, ofcourse after storing
    away the original address in a function pointer.
  3. Now when the original function is called, the call comes to our
    function, we play aroud with it and then (maybe) call the original
    fucntion through the function pointer.

This works for C programs, and I am a C programmer, however, in the
above code, Jeff calles the original LoadLibraryExA( )…

HMODULE hMod=::LoadLibraryExA(pszModulePath,hFile,dwFlags);

The scope resolution operator seems to have done aways with the
function pointer concept.

I cannot understand how this happens. Maybe my C++ concepts are junk,
but can someone enlighten me please.

No, it’s not that complicated. This is not “hooking” the LoadLibraryExA
API. This is just a simple wrapper around it. There is no relationship
between CAPIHook::LoadLibraryExA and the standard LoadLibraryExA. They
just happen to have the same function name. Other callers of
::LoadLibraryExA will still call the original API; the only code that
will call THIS version is code that specifically call this class member.

The hooking magic happens inside FixupNewlyLoadedModule. Calls to APIs
inside this newly loaded library will be hooked, but not LoadLibraryExA.

Perhaps it would have made more sense if the function had been called
CAPIHook::Here_is_a_library_that_I_want_to_hook.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim.

Amitr0