![]() ![]() Windows provides many providers out of the box, each exposing a rich set of events. These events can be logged to a file (.ETL extension) and then analyzed, or alternatively logged in real time to listening consumers. In ETW, providers spit out events that ETW consumers consume. ProcMonX, on the other hand, uses Event Tracing for Windows (ETW), a diagnostics and logging mechanism that existed since Windows 2000. Other types of operations such as memory allocation events is nearly impossible to get since these cannot really be hooked. For example, to get network related events, one would have to write some sort of NDIS filter or perhaps use the Windows Filtering Platform (WFP), both of which are far from trivial. ![]() With this approach, adding new functionality is really difficult. File system operations – Use a file system mini filter, to hook pre and post file system operations.This is how ProcMon knows how the operation completed. Every possible registry operations can be hooked – before the operation and afterwards. Registry events – Use the CmRegisterCallbackEx function to register callbacks for pre and post operations.Image loading/unloading – Use the PsSetLoadImageNotifyRoutineEx to register a callback for such notifications.Thread creation/termination – Use the PsSetCreateThreadNotifyRoutine function with a callback invoked for every thread creation or termination.The full command line is available to the callback along with creating thread/process. Process creation/termination – Use the PsSetCreateProcessNotifyRoutineEx function to hook process creation and termination.Here is a list of events and the way ProcMon gets to the data (I have not actually since the source code, but that’s how I would have implemented it): ![]() The upside to using a driver is the ability to get the most accurate data, since some form of hooking is involved. ![]()
0 Comments
Leave a Reply. |