Device Driver Feasibility
-
I would like to know if the following device driver is possible in Windows 10: A driver that receives a notification whenever a user mode process is created, and can then load a user-specified user mode DLL into that process before any user mode code in the process executes (including TLS callbacks.) I'm not asking for code or how to write it, I'm only asking if the facilities exist in Windows 10 to make such a driver possible.
The difficult we do right away... ...the impossible takes slightly longer.
-
I would like to know if the following device driver is possible in Windows 10: A driver that receives a notification whenever a user mode process is created, and can then load a user-specified user mode DLL into that process before any user mode code in the process executes (including TLS callbacks.) I'm not asking for code or how to write it, I'm only asking if the facilities exist in Windows 10 to make such a driver possible.
The difficult we do right away... ...the impossible takes slightly longer.
-
Hi, Yes. You should look at the PsSetCreateProcessNotifyRoutine routine[^]. There are other ways to do this without using a device driver. Could you elaborate on what you are attempting to achieve? Best Wishes, -David Delaune
Hi David, I would like to create an API hooking DLL that logs and documents the API calls that a given process makes. (It's my million-dollar product idea) So I need a way to inject my DLL at process startup and into all child processes. Ever since Microsoft disabled the registry key that used to have User32.dll load the DLL on my behalf, I have been stuck for a way to do this. Let me point out that all of the user mode ways of doing this are not acceptable because I need the DLL to be injected before any user code executes in the target process, including TLS callbacks. Any pointers are greatly appreciated. Thanks, Rich
The difficult we do right away... ...the impossible takes slightly longer.
-
Hi David, I would like to create an API hooking DLL that logs and documents the API calls that a given process makes. (It's my million-dollar product idea) So I need a way to inject my DLL at process startup and into all child processes. Ever since Microsoft disabled the registry key that used to have User32.dll load the DLL on my behalf, I have been stuck for a way to do this. Let me point out that all of the user mode ways of doing this are not acceptable because I need the DLL to be injected before any user code executes in the target process, including TLS callbacks. Any pointers are greatly appreciated. Thanks, Rich
The difficult we do right away... ...the impossible takes slightly longer.
Hi,
Richard Andrew x64 wrote:
I would like to create an API hooking DLL that logs and documents the API calls that a given process makes. (It's my million-dollar product idea)
Hooking? Are you sure that you actually have a solid plan for what you want to do? What are you defining as 'API calls'? Are you referring to a specific Microsoft API? Sounds like you want to perform instrumentation[^]? Are you looking to implement something like Intel VTune[^]? If so check out DynamoRIO [^].
Richard Andrew x64 wrote:
Let me point out that all of the user mode ways of doing this are not acceptable because I need the DLL to be injected before any user code executes in the target process, including TLS callbacks.
Have you experimented with the CreateProcess function[^] and the
DEBUG_PROCESSandDEBUG_ONLY_THIS_PROCESSflags combined withCREATE_SUSPENDED? This should give you access to the process before anything as executed including TLS callbacks. Is there a specific reason why you believe that you need to use a device driver? Are you trying to avoid the TLS callbacks and process initialization for a single process or system-wide? From usermode you can use the Application Compatibility Toolkit[^] to load a DLL into any process system-wide immediately after kernel32/user32 is loaded and before any usermode code has executed. On Windows 10 you can get the AppCompat toolkit as part of the -
Hi,
Richard Andrew x64 wrote:
I would like to create an API hooking DLL that logs and documents the API calls that a given process makes. (It's my million-dollar product idea)
Hooking? Are you sure that you actually have a solid plan for what you want to do? What are you defining as 'API calls'? Are you referring to a specific Microsoft API? Sounds like you want to perform instrumentation[^]? Are you looking to implement something like Intel VTune[^]? If so check out DynamoRIO [^].
Richard Andrew x64 wrote:
Let me point out that all of the user mode ways of doing this are not acceptable because I need the DLL to be injected before any user code executes in the target process, including TLS callbacks.
Have you experimented with the CreateProcess function[^] and the
DEBUG_PROCESSandDEBUG_ONLY_THIS_PROCESSflags combined withCREATE_SUSPENDED? This should give you access to the process before anything as executed including TLS callbacks. Is there a specific reason why you believe that you need to use a device driver? Are you trying to avoid the TLS callbacks and process initialization for a single process or system-wide? From usermode you can use the Application Compatibility Toolkit[^] to load a DLL into any process system-wide immediately after kernel32/user32 is loaded and before any usermode code has executed. On Windows 10 you can get the AppCompat toolkit as part of theFirst, thank you for your responses. I'm looking to implement something very much like this: API Monitor[^] Yes I have tried
CreateProcesswithDEBUG_PROCESSandCREATE_SUSPENDED, but that doesn't work for my purposes, and here's why: Once my hook DLL is inside a process, I need it to be injected into all child processes as well. This means hooking any API's that create processes. I have found that some programs use theDEBUG_PROCESSandCREATE_SUSPENDEDtrick as well. And I haven't yet figured out a way to inject my DLL and return the child process to the calling program in the state that it expects it to be in. What usually happens is a crash of the child process, because the calling program couldn't do what it wanted to do with the child process before any user code executed. Did you follow that? :-) That is why I think I need a driver to accomplish this, because I have tried every user-mode way of doing it and just couldn't make it work.The difficult we do right away... ...the impossible takes slightly longer.
-
First, thank you for your responses. I'm looking to implement something very much like this: API Monitor[^] Yes I have tried
CreateProcesswithDEBUG_PROCESSandCREATE_SUSPENDED, but that doesn't work for my purposes, and here's why: Once my hook DLL is inside a process, I need it to be injected into all child processes as well. This means hooking any API's that create processes. I have found that some programs use theDEBUG_PROCESSandCREATE_SUSPENDEDtrick as well. And I haven't yet figured out a way to inject my DLL and return the child process to the calling program in the state that it expects it to be in. What usually happens is a crash of the child process, because the calling program couldn't do what it wanted to do with the child process before any user code executed. Did you follow that? :-) That is why I think I need a driver to accomplish this, because I have tried every user-mode way of doing it and just couldn't make it work.The difficult we do right away... ...the impossible takes slightly longer.
Hi, That's an impressive body of work by Rohitab Batra. However I see a lot of problems with that software suite. The XML files that contain the API structs, interface and other definitions will not match on some operating systems... depending on update/patch level. If you ran his software on 10,000 computers 'in the wild' you would find that a certain percentage of those may not completely match his XML descriptions. It would be much better if he downloaded symbols from the Microsoft symbol server and used the Debug Interface Access SDK[^] to extract that data from the PDB symbol files. It is still an impressive piece of software and looks very useful for malware analysis and other debugging scenarios. Best Wishes, -David Delaune
-
Hi, That's an impressive body of work by Rohitab Batra. However I see a lot of problems with that software suite. The XML files that contain the API structs, interface and other definitions will not match on some operating systems... depending on update/patch level. If you ran his software on 10,000 computers 'in the wild' you would find that a certain percentage of those may not completely match his XML descriptions. It would be much better if he downloaded symbols from the Microsoft symbol server and used the Debug Interface Access SDK[^] to extract that data from the PDB symbol files. It is still an impressive piece of software and looks very useful for malware analysis and other debugging scenarios. Best Wishes, -David Delaune
Hi David. One follow-up question, if I may. How can the UDT's of the Win32 API be extracted from the public PDB files if the source information is stripped from them? I mean, yes it would be possible to get information about the functions, but not about the types passed into them. Am I correct?
The difficult we do right away... ...the impossible takes slightly longer.
-
Hi David. One follow-up question, if I may. How can the UDT's of the Win32 API be extracted from the public PDB files if the source information is stripped from them? I mean, yes it would be possible to get information about the functions, but not about the types passed into them. Am I correct?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
Am I correct?
Yes, you are partially correct. Microsoft has made some private symbols available to some ISV and partner programs after signing NDA and some special agreements. There is also the 'https://codepremium.msdn.microsoft.com/symbols' private symbol server made available through the shared source initiative[^]. Code Center Premium[^] I took a brief look at his software package and was immediately impressed. It would be a great tool for sandbox automated malware analysis. However it is severely lacking in one single area... the function signatures in his XML files will not match on all operating systems. To make matters worse... he does't even mention which OS/Patch level those definitions match. If he would author a tool for generating those function and type definitions using the Debug Interface Access SDK[^] it would be a much better tool. It would allow his software to perfectly match the machine it is running on regardless of Update/Patch level. Best Wishes, -David Delaune
