IAT Hook via Kernel Driver

Question

I've wrote a kernel driver recently and it does multiple things, but I wanted to add a IAT hook for a certain driver.

I want to hook the IAT of another driver from my driver if that makes sense.

So I understand your typical IAT hook is done via DLL injection so you're within the same address space as said module.

The main question I'm having is can someone give an example of IAT hooking a kernel driver via a kernel driver? I can't figure it out.

I've been using multiple examples of regular IAT hooking via dll injection but applying it to the Kernel driver instead.

Expected outcome: Driver1.sys (does the IAT hook) parses the import table of Driver2.sys and replaces the function "DbgPrintEx" import with a function located in Driver1.sys aka accomplishing an IAT hook.

Here is what I wrote / referenced:

NTSTATUS _HOOKS_::HookFn(PVOID ModuleBase, const char* FunctionName, uintptr_t HookFunc, uintptr_t* OrigFunc) {

IMAGE_DOS_HEADER DosHeader{ 0 };
memcpy(&DosHeader, ModuleBase, sizeof(IMAGE_DOS_HEADER));

IMAGE_NT_HEADERS NtHeaders{ 0 };
memcpy(&NtHeaders, (PVOID)((uintptr_t)ModuleBase + DosHeader.e_lfanew), sizeof(IMAGE_NT_HEADERS));

IMAGE_IMPORT_DESCRIPTOR ImportDescriptor{ 0 };
IMAGE_DATA_DIRECTORY ImportsDirectory = NtHeaders.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT];

memcpy(&ImportDescriptor, (PVOID)((uintptr_t)ModuleBase + ImportsDirectory.VirtualAddress), sizeof(ImportDescriptor));

LPCSTR LibraryName = NULL;
PVOID Library = NULL;
IMAGE_IMPORT_BY_NAME FunctionNamee{ 0 };

while (ImportDescriptor.Name != NULL) {
    memcpy(&LibraryName, &ImportDescriptor.Name + (uintptr_t)ModuleBase, sizeof(LibraryName));

    IMAGE_THUNK_DATA OriginalFirstThunk{ 0 }, firstThunk{ 0 };
    memcpy(&OriginalFirstThunk, (PVOID)(ImportDescriptor.OriginalFirstThunk + (uintptr_t)ModuleBase), sizeof(IMAGE_THUNK_DATA));
    memcpy(&firstThunk, (PVOID)(ImportDescriptor.FirstThunk + (uintptr_t)ModuleBase), sizeof(IMAGE_THUNK_DATA));

    while (OriginalFirstThunk.u1.AddressOfData != NULL) {

        memcpy(&FunctionNamee, (PVOID)(OriginalFirstThunk.u1.AddressOfData + (uintptr_t)ModuleBase), sizeof(IMAGE_IMPORT_BY_NAME));

        Log::Debug("First function name -> %s\n", FunctionNamee);

        if (!strcmp(FunctionNamee.Name, FunctionName)) {
            Log::Debug("FOUND FUNCTION!!! Address -> %p\n", firstThunk.u1.Function);
        }
    }
}


return STATUS_SUCCESS;

This code BSOD's on: memcpy(&ImportDescriptor, (PVOID)((uintptr_t)ModuleBase + ImportsDirectory.VirtualAddress), sizeof(ImportDescriptor));

Correct me if I'm wrong but since kernel drivers share the same address space I can just simply use memcpy or RtlCopyMemory to obtain the structs needed for this hook, does anyone have any references or some sort of documentation I can read?

Thanks to all in advance!

extra info:

• Windows 10
• Using VMWare for testing
• I'm testing the hook on my own driver

EDIT: Posted the faulting source line that causes BSOD.

Upon debugging via WinDbg(x64), the driver obtains all the addresses correctly comparing them to memory view. Except ImportDescriptor gets an RVA of 0x6000, when inspecting ModuleBase + 0x6000 for the RVA it shows that this memory region is invalid, so I believe that the 0x6000 RVA is incorrect and I'm not sure why

BUG CHECK CODES:

• BSOD Error Code: PAGE_FAULT_IN_NONPAGED_AREA
• BUG Check Code: 50

Answer 1

The problem seems to be in the source address calculation:

&ImportDescriptor.Name + (uintptr_t)ModuleBase

This adds the address of a local variable (which is on the stack) to the image base, so the result is probably some non-existent address.

You should add its value, which is an RVA, to the image base. I.e. something like this:

memcpy(&LibraryName, (PVOID)((ULONG_PTR)ModuleBase+ImportDescriptor.Name) , sizeof(LibraryName))

Answer 2

So, it turns out that if you're testing an IAT hook on a driver, the driver must be compiled in the release mode rather than in the debug one.

If the driver is compiled in the debug mode, the RVA for the Import Descriptor seems to be wrong. But the issue is resolved with compiling in the release rather than in the debug mode.

Thanks to all for the help.

Answer 3

This is unfortunately not going to be an answer, because you don't give enough information. If I end up writing an answer, it will be a different one. So long I'll make this non-answer a community wiki, attempting to give clues, ask for details and point to resources.

Correct me if I'm wrong but since kernel drivers share the same address space I can just simply use memcpy or RtlCopyMemory [...]

Uhm this statement is "sort of" true, but then it also isn't. It depends on so many aspects in (Windows) kernel mode. While the address space (i.e. min through max address) is technically the same, it depends a whole lot in which context your code executes (e.g. the IRQL) and of the attributes for the memory you attempt to access (e.g. NonPagedPool vs. PagedPool).

However, this is introductory material for KM driver development, so I recommend you pick up a book such as "Windows Kernel Programming" from Pavel Yosifovich or even the somewhat older work "Programming the Microsoft Windows Driver Model" from Walter Oney. The courses offered by OSR and Yosifovich would also be a great way to learn this stuff.

Besides you forgot to mention which bug-check code you're getting. This is very much relevant to help you. The parameters included in the bug-check can also give an idea in absence of a full memory dump (or in your case a live debug session). The parameters are those four items included alongside the bug-check code in a blue screen.

• At what IRQL is your code executing during the bug-check? You can't touch
• How is the code marked in your driver? (e.g. PAGED_CODE() or similar?)
  • Also, in case you attempt this in DriverEntry that one always runs at PASSIVE_LEVEL either way ...
• Who is the caller of the function?
• Assuming you're not doing this inside an I/O request code path, you're still fairly wasteful with stack. KM code has quite the limits when it comes to available stack.
• All the above questions, comments, remarks also should be checked for code you call (such as Log::Debug()).

That said, your above statement should be true for all intents and purposes at PASSIVE_LEVEL and to some extent at APC_LEVEL. But even then it pays of to make use of SEH for some code and make use of MmIsAddressValid and ProbeForRead and similar routines as appropriate.

Btw: perhaps you'd like instead to tell us what it is you're trying? Although admittedly none of this is very closely related to RCE.