DLL Injection Win32 API

Question

I want to know which Win32 API functions a certain executable calls. The executable is a 32-bit application. I know what steps to take to perform a DLL injection and hook an API function.

However, there is one thing I don't quite understand: how does my custom DLL know when to load into the virtual address space of the process and hook the real DLL (overwriting the first x bytes with a jump function).

Please read this article: https://dzone.com/articles/windows-api-hooking-and-dll-injection

It calls the Kernel32.dll function CreateProcess with the parameter CREATE _SUSPENDED, then it does a DLL injection (allocates memory etc. and finally loads the custom DLL into the virtual address space). However, the first question I have is: it is assumed that the process will call the function CreateFileA, for example (which makes sense if the program is for example notepad.exe). To hook this function, Kernel32CUSTOM.dll is loaded into the virtual address space of the process (since this DLL consists of the CreateFileAHOOKED function). But is it right that this method can only be used in such a case? Because if you do not know which functions a process will call, then you cannot know in advance which custom functions are to be loaded into the virtual address space.

Secondly, the process is first suspended to load its custom DLL into the virtual address space. So far, so good, but how is the actual hook set (the process has not loaded the real Kernel32.dll up to this point, so you cannot use a jump function (as the real Kernel32.dll is not loaded). Or does it also load the real Kernel32.dll into the virtual address space after it has stopped the process?

EDIT:

You can look at an executable's "import table"

Thanks, I will have a look at it, this one is I think known as the IAT hooking method(?), I didn't have a closer look at this one yet (maybe I focused too much on the other method: inline hooking. ALthough, I'm not sure if IAT hooking is in my case a viable approach, because I want to know how often, in which order etc. the API functions are called.

The more advanced option is that..... 
.......fetched so you can hook it too.

That makes sense. Assuming I use this method to hook GetProcAddress in Kernel32.dll, I need to know when Kernel32.dll is loaded (LoadLibrary) into the virtual address space of the process (at runtime) and when exactly this function is called by the process?

rather than re-mapping the linked library as writable and overwriting its function... 

Interesting approach, I will have a look at this.

Obviously, none of these are foolproof approaches.

True, not all ransomware samples use for example the Windows API, but that's a limitation I accept (though a more solid approach would be a minifilter driver in Kernel, like Procmon).

And my last question, what do you think of inline hooking in combination with your approach of hooking GetProcAddress.. so when a certain API function (e.g. CreateFileA) is called, memory is allocated in the virtual address space of the process, the custom DLL is loaded and the original x bytes of the original function are overwritten with a jump function etc.

Answer 1

First of all, as mentallurg said, this doesn't really belong on Security.SE unless there's some actual security question you have about this.

Second, you don't need to write anything to do this; Process Monitor on Windows can generally achieve your goal here just fine, and likely better than you would write by hand.

With those said...

---

There are, in general, two ways to know what functions a program will call. You can look at an executable's "import table" - the list of functions that are dynamically linked at program start - using almost any program that understands the PE binary format; it's a common thing to look at. If you want a nice graphical view of the imports not just in your program but in its dependencies, Microsoft's "Dependency Walker" tool is like 20+ years old but does this job just fine. Hooking the program's imports before execution starts is an easy option here.

The more advanced option is that, if the program uses any of the GetProcAddress functions (which take a function name and optional DLL handle, and return a function pointer; this can be used to call functions in dynamically linked libraries at runtime), you'll want to hook that and use it to look up what function pointer is being fetched so you can hook it too. In fact, in that case it's actually easier; rather than re-mapping the linked library as writable and overwriting its function, you can write out a shim function (that calls the original, unmodified target function) onto the heap somewhere, mark that as executable, and then have your hooked GetProcAddress return the pointer to the shim.

Obviously, none of these are foolproof approaches. Software can always un-hook itself, or bypass shims if it knows the correct offsets, or directly invoke system calls without going through the WinAPI (user32) or even NT-native user-mode syscall (kernel32) libraries. Functions can also be statically linked into an executable, in which case they won't show in the imports or exports any more than any other internal-only function does.