Windows will call eventually the API function that is responsible for writing files, namely “WriteFile” from the “kernel32.dll”. So let’s say that our application wants to write a file, and calls the appropriate functions in its code. To do that our process will need to use the Windows API.įor the purposes of this discussion we will not care in what language our application is written, instead we’ll only focus on how the system will handle the request. It could write / read a file, access the network, draw something on the screen and so on.Īll of these actions requires the process to interact with the kernel, as it is the sole responsible for all, including system resources. Our process will want to do something at one point in its lifetime as a good process should. In windows this application will be represented by a process in user mode when it runs, and we’ll possess at least one thread of execution. So let’s say we have an application and we’ll call it “Application X”. Whereas the kernel space will handle everything related to memory, drivers, file system, I/O…etc. User space will contain everything ranging from applications, services, system processes like the service control manager, sessions manager and everything that the user will execute. Windows segregates user operations and OS operations by what’s called “User Space / User Mode” and “Kernel Space / Kernel Mode”. Windows Internals and The Win32 APIīefore we start our journey into procmon, I think we should make a little detour and understand what happens when a process tries to request something from the OS by taking a look at some Internals. We’ll start with an introduction on what happens when a process request something form the OS and then we’ll dive into procmon and how we can use some of its features to understand and hunt malware. In this third part, we’ll be taking a look at the powerful “Process Monitor” or “procmon” for short.
0 kommentar(er)
