none
To get image path of drivers from Process ID RRS feed

  • Question

  • I am writing a kernel-level driver to hook a function, and a user-mode application with it. I want to get the image path of a driver from the Process ID. Currently, the method I'm using, retrieves the process ID as PID=4, which is a system process. But i want to find the name or imagepath of any driver calling the hooked function.

    How do i manage this? Any help will be greatly appreciated.

    Thanks :)

    Wednesday, April 17, 2013 11:20 AM

Answers

  • No you can't get a driver name from a process ID.  If it is a direct call to the function you can use RtlGetCallersAddress (an undocumented call but has been in Windows for a very long time) to get the address then see if you can match the address to the kernel memory region occupied by a driver.  This is where the PsSetLoadImageNotify support is needed to build and maintain the table of the drivers.

    What is it that you are hooking, there may still be a better way.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, April 17, 2013 2:11 PM

All replies

  • If you are hooking a kernel function, think very carefully about this.  If this is for research or testing purposes, hooking a kernel function can potentially be done, but if you are doing this for a production driver you are just creating problems.  If this is an attempt to find MALWARE forget it, even if you do the MALWARE driver can't be removed from the system.

    You can't get the image path of a driver from a process ID since all drivers can be thought of as DLL's.   You can use the PsSetLoadImageNotify to see what drivers are loaded and their address ranges.  You can use userspace calls (the kernel equivalents are undocumented and subject to change) to get a list of all drivers and their address ranges.  Depending on your hook you can look at the return address of the call and see what driver called you if it was a direct call.

    I strongly urge you to step back and think about what you are doing.  If you explain it here, we may be able to give you a solution that does not involve hooking.  The fact that you are asking about drivers and process ID's says you are a new developer for the Windows kernel, trying to hook as a newbie is just going to create problems.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, April 17, 2013 11:33 AM
  • Thanks for your explanation. My purpose is to only display a list of processes calling the particular function, in the user-mode application; in some cases, I am getting the system process with PID=4, so I figured that some drivers would be calling that function. In this regard, I was hoping to find the name or path of such drivers.


    Wednesday, April 17, 2013 1:14 PM
  • Is this a kernel function, through a system call?  Your explanation is still not clear on what you are hooking and its goal.  Be aware that hooking is much harder than most of the internet documents it to be.  For instance there are kernel calls that change often, there are others that expect no additional data on the stack (i.e. you can't have your stack frame there), and other tricky problems.

    If this is a call to a registry function, an I/O function, or some process functions there are ways to get callbacks that indicate what is going on without hooking.  As I stated in my original response don't use hooking in a production tool and of course you cannot use hooking on 64-bit since it will not work.  Finally, be aware that the authors some of the rootkit books that insist hooks have created protection code that opened the system to some of the worst security holes.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, April 17, 2013 1:28 PM
  • Yes, it's a kernel function. Thanks, I understand what you mean now; hooking is not a good idea overall. I will change my approach, but I'm still unclear about the second part; is it afterall possible to get the name or image path of drivers from Process IDs? even in user-level applications?


    Wednesday, April 17, 2013 1:39 PM
  • No you can't get a driver name from a process ID.  If it is a direct call to the function you can use RtlGetCallersAddress (an undocumented call but has been in Windows for a very long time) to get the address then see if you can match the address to the kernel memory region occupied by a driver.  This is where the PsSetLoadImageNotify support is needed to build and maintain the table of the drivers.

    What is it that you are hooking, there may still be a better way.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, April 17, 2013 2:11 PM