0

I was told by someone with a lot of experience that there is at least one alternate way to monitor Windows OS calls, in the context of for example, creating Process Monitor-like functionality or developing an anti-virus scanner, which is not "hooking" and that this alternate method is more efficient than hooking. However, I am unsure of which alternatives to hooking there are in the context of developing a filter driver to perform this task.

the_endian
  • 2,259
  • 1
  • 24
  • 49
  • 1
    Processor Monitor doesn't monitor Windows OS calls, but certain kinds of events in the Windows kernel. It does that through various techniques. For file monitoring it uses a device filter driver, much like a anti-virus scanner would. See https://stackoverflow.com/questions/1531800/how-does-a-windows-antivirus-hook-into-the-file-access-process This technique wouldn't work at all for monitoring the SSDT (SQL Server Data Tools) API which (I assume) is a user level API. – Ross Ridge Sep 27 '17 at 20:31
  • @RossRidge thanks but by SSDT I meant the System Service Dispatch Table calls aka syscalls – the_endian Sep 27 '17 at 20:34
  • 1
    You could be thinking of MS [Detours](https://www.microsoft.com/en-us/research/project/detours/) – JJF Sep 27 '17 at 20:43
  • @JJF definitely not detours because it's kernelmode driver functionality... is using callbacks to monitor considered hooking? – the_endian Sep 27 '17 at 20:44
  • 1
    The filter technique wouldn't work either for actual kernel system calls. I don't know if there's any good method for that, as any attempt to directly monitor those would run against Windows kernel modification protections. As far as I know Detours is entirely user mode works by "hooking" functions. – Ross Ridge Sep 27 '17 at 20:48
  • @conio you're sweating ridiculous details. I have a couple of simple questions/confusion on these things, one of which you frankly answered quite well, and now you're making assumptions which I don't have any interest in addressing. I also didn't know that the prev question was updated. Just don't overthink my questions please. – the_endian Sep 28 '17 at 03:23
  • @conio what you've said about "the question can't be answered" makes no logical sense. The question was "is there a way other than hooking to monitor native/SSDT API calls on a Windows System" you had said "no" as an answer and then deleted it. You then went in the comments and rambled about how you can't answer the question but then ended up saying "there cannot be a more efficient way than hooking." And thus answered the question again. The question is in the main text of the post. The answer has nothing to do with whether or not the person I mentioned knew what they were saying. – the_endian Sep 29 '17 at 18:46
  • If the answer is "no" the answer is "no". That doesn't mean the question is unanswerable or NP complete or whatever else you want to come up with. – the_endian Sep 29 '17 at 18:50

1 Answers1

0

No. There is no equivalent for SSDT hooking but this does't mean you can not monitor events. We have several CBs in KM which can be used for monitoring and altering the data/access rights, etc. If you're talking about AV scanner those CBs are sufficient most of the time. I think it's better to describe for what you need this. Then it's easier to say what to use instead.

side note this has be put as a comment. I think it's crazy that you have to earn more than 50 rep to be able to put comments!!! Comments are useful for better understanding the questions and clarify things. Why someone needs to have rep for that?!

EWD-0-
  • 113
  • 9
  • Ah yeah I’m talking about for an AV scan in order to view and attach some functionality to ALL calls to a given API like NtCreateFile or NtCreateSection for example in kernel mode. – the_endian Oct 24 '17 at 12:17
  • Ok. To intercept modification/access to file system you can write a **file system filter driver** and register it to receive a notification. You can implement a minifilter or use the old architecture. There is also a CB provided for **NtCreateSection** which can be set for minifilter, **IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION**. Also possible to set this via **FsRtlRegisterFileSystemFilterCallbacks: PreAcquireForSectionSynchronization** – EWD-0- Oct 24 '17 at 13:20
  • Ah perfect thanks a lot! If you want let me know and I can edit the question and maybe you can throw this info into the answer? Or do you want to just keep it in the comments? – the_endian Oct 26 '17 at 00:32