2

My goal is hook all LoadLibrary calls from particular dll and its dependencies (which may be delayed importable). Here is how I'm trying to solve this task:

  1. Load this dll using DONT_RESOLVE_DLL_REFERENCES flag.

    1.1. Apply this algorithm to dll's submodules recursively.

  2. Fill the Import Table of this dll manually.
  3. Hook all LoadLibraryA, LoadLibraryW etc. functions just patching Import Table.
  4. Call DllMain of this dll manually with DLL_PROCESS_ATTACH flag.

And I had a problem with the last step. If I call DllMain manually then all inner LoadLibrary calls will be executed from my module's address space (not from dll's one) and all my hooks from step3 is not calling.

And I don't want to hook LoadLibrary calls in my main module because there is other code which calls LoadLibrary and I don't wont such side-effects.

So my question is how should I call DllMain in order to force it not using LoadLibrary from my main module? Is it because of the delayed-import? Or is it just because as I call DllMain? Or maybe there are better solution of this task?

Here is how I run dll:

void PEUtility::runDllMain(HMODULE module)
{
    typedef BOOL(WINAPI *DllMainFunPtr)(HMODULE, DWORD, LPVOID);

    auto header = ImageNtHeader(module);

    auto dllMain = (DllMainFunPtr)(header->OptionalHeader.AddressOfEntryPoint + (DWORD_PTR)module);
    dllMain(module, DLL_PROCESS_ATTACH, NULL);
}

Here is how I fill Import Table: my question about how I'm filling import table

LoadLibrary hooking is similar to Import Table filling.

UPDATE

I've added a couple of screenshots from ApiMonitor to demonstrate that LoadLibrary("...mso20win32client.dll") was called from different modules for the case then I load parent library olmapi32.dll (which depends on mso20win32client.dll) using all this stuff described above and for the case then I just call LoadLibrary:

When I use my method described above (using DONT_RESOLVE_DLL_REFERENCES, DllMain etc.) (NOTE LAST LINE: mso20win32client.dll was loaded from mapi32ex64.dll - my main module): loading 'olmapi32.dll' using stuff above

When I just call LoadLibrary("OLMAPI32.dll") (NOTE LAST LINE: mso20win32client.dll was loaded from olmapi32.dll - dll that I want do load using my method): enter image description here

Community
  • 1
  • 1
Dmitry Katkevich
  • 883
  • 7
  • 26
  • interesting how another DLL called LoadLibrary from your module. you are something confused. your way yourself load dll is incorrect. you for example not handle manifest in Dlls in this case, not create activation context. and at all, if say DLL not imported LoadLibrary, but used GetProcAddress to get this proc ? what at all you try doing ? target goal i mean. `header->OptionalHeader.AddressOfEntryPoint` you also not check for 0 – RbMm Nov 16 '16 at 13:30
  • @RnMn, do I understand correctly that loading library using `DONT_RESOLVE_DLL_REFERENCES` and calling DllMain for particular library is not enough for manifest and context? As for `GetProcAddress` - I'm hooking `kernel32` LoadLibrary functions and I guess this library always presents in dll's Import Table. Anyway I'm hooking predefined dlls set and non of these dlls do not use `GetProcAddress`. – Dmitry Katkevich Nov 16 '16 at 13:48
  • yes, when you use `DONT_RESOLVE_DLL_REFERENCES` dll manifest is not processing. like and tls. – RbMm Nov 16 '16 at 14:19
  • and for understand what happens you need use debugger and only debugger. any apimonitor not enough – RbMm Nov 16 '16 at 14:44

1 Answers1

1

For future readers who stumble upon this issue (and their goal is to do something between library loading and calling its init routine, for example hooking or changing some code), have a look at this answer: https://reverseengineering.stackexchange.com/a/6023

Basically you can hook LdrpCallInitRoutine in ntdll.dll, which is used to call the DLL entry point by the system:

BOOLEAN NTAPI LdrpCallInitRoutine(PDLL_INIT_ROUTINE EntryPoint, PVOID BaseAddress, ULONG Reason, PVOID Context);
p0358
  • 139
  • 1
  • 8