3/6/2023 0 Comments Windows process monitorThat subsystem DLL function will check the parameters and that everything is good to go, and will make a call to the native API corresponding function in “ntdll.dll”.That function will at some point call the appropriate subsystem DLL (kernel32.dll, ws2_32.dll, advapi.dll…etc.).An application wants to do something, by calling the appropriate function in its code (reading / writing a file, printing a document, communicating via the network…etc.).This example can be generalized to illustrates what happens every time an application requests a resource from the kernel. Below is a diagram illustrating what we’ve just talked about in an abstract way. Safe to say we will get back from the kernel into our original calling function with our file created. I will spare you what’ll happen in the rest of the journey of the thread. “ntdll.dll” is the lowest point we can reach in user mode and it’s the DLL that implements the undocumented windows API and the one responsible for the jump between user mode and kernel mode.Ĭontinuing with our example, the function that will get called from the “ntdll.dll” is the “NtWriteFile” which will be the one responsible for the switch from user mode to the “executive” in kernel mode. In truth the “WriteFile” function is just a wrapper that will check the parameters being sent and call another function in another DLL named “ntdll.dll”. Which is a user mode DLL that contains the Win32 base API and our “ WriteFile” function.īut as we’ve said “kernel32.dll” is still in user mode, that means we still need to go down. 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |