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?
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.