Kernel32.dll vs Kernelbase.dll - reasons behind a design choice

[Necroxys77]

Hi,

I'm trying to create a plugin that is able to inject breakpoints not only on the entry point of some API calls - like envom plugin already does - but also in specific addresses inside the trapped function - i.e. on ret instructions of Sleep.
Studying the code, I noticed that kernel32.dll acts like a stub/trampoline for the actual implementation of its functions - that reside inside kernelbase.dll.

Is there any reason why a plugin like envmon is designed to trap using kernel32.dll instead of kernelbase.dll? I don't want to miss something important before proceeding with the design.

Thank you.

EDIT:
Considering again Sleep function, I noticed that trapping it through kernelbase.dll doesn't work. On the other hand, trapping it through kernel32.dll is OK. Why?

EDIT2:
To better explain the problem, see the following graph:

Basically I would like to take control in 0x0DCE1809 address, but even if DRAKVUF successfully calculates the address (kernelbase base + Sleep offset from Rekall profile) and injects the bp, this breakpoint is never hit. The only function that I was able to trap with kernelbase.dll was GetComputerNameExW - indeed, it's already managed inside envmon.

[tklengyel]

/cc @zodeak

[icedevml]

Is there any reason why a plugin like envmon is designed to trap using kernel32.dll instead of kernelbase.dll? I don't want to miss something important before proceeding with the design.

@Necroxys77 It may be one of the problems described in #669. Most probably the DLL is not entirely mapped inside the memory (Windows is doing some kind of lazy-loading per 4 kB pages) and some essential information is not available, thus you can not properly hook this DLL. The kernel32.dll has much more "dense" memory layout because it contains only trampolines to the proper functions, thus there is a higher probability that hooking will succeed.

I'm already working on these problems in #675, if you are still interested.

[Necroxys77]

@Necroxys77 It may be one of the problems described in #669. Most probably the DLL is not entirely mapped inside the memory (Windows is doing some kind of lazy-loading per 4 kB pages) and some essential information is not available, thus you can not properly hook this DLL. The kernel32.dll has much more "dense" memory layout because it contains only trampolines to the proper functions, thus there is a higher probability that hooking will succeed.

I'm already working on these problems in #675, if you are still interested.

Thanks for the reply @icedevml.
It's a really strange behavior, I'll study in detail your progress in the next days.

A stranger fact is the following one: I manually put a breakpoint on ret instruction of Sleep (@ 0x0DCE1819) and its callback was successfully raised once that breakpoint was hit. I'm just lucky in the lazy-loading mechanism?

[icedevml]

@Necroxys77 The manually is essential here. Most probably vmi_translate_sym2v doesn't work because it has to parse the DLL export information in order to map Sleep to a virtual address. For some reason this information doesn't physically exist in the memory at the moment you request for it. LibVMI (AFAIK) can't read memory which is swapped-out or file-backed and that's the direct cause. You may however apply some hacks to overcome it, e.g. manually cause a page fault to force Windows to load the required memory.

When you put the address "by hand" - it works, because the above problems don't apply.