godaddy/procfilter

Breaking down the source code into smaller pieces

hdi-amiri opened this issue · 3 comments

After compiling the source code successfully, I am trying to understand the core functionality of this tool which is blocking process execution on some criteria.

In this line of code we are requesting the user-land to tell us what should we do with this newly created process, I was wondering if the driver is blocked in this line of code? Say if we have 10 newly created processes what really happens?

This method defined here does the job of informing the driver which is mostly called in pfworker.cpp like here. When the service is started running, the call to DriverInit() initializes the driver and loads it and create a thread which runs the WINAPI function ep_DriverService. this function also runs PfWorkerWork in another thread, PfWorkerWork is the function that writes the response to the driver back. How this PfWorkerWork is connected with core api's ProcFilterEvent defined here?

ewil commented

The thread creating the process will be blocked in the kernel until the userland service responds with a scan result. A single thread can only create 1 process at once and the scan is performed as part of the new process being created. Creation of 10 processes is not a parallel operation from the perspective of a single thread. To the thread creating the process, the ProcFilter scan is just part of the overhead of creation. If there were multiple threads creating multiple processes simultaneously, each thread would block in parallel with each other since they're separate events and would be handled separately.

PfWorkerWork is connected to the API via ApiEventExport() defined at

DWORD
. ApiEventExport() notifies all interested plugins that an event is happening.
if (ApiEventExport(e) & PROCFILTER_RESULT_BLOCK_PROCESS) {
is an example of this.

Does this help?

Yeah, Pretty sure it helped a lot, Since I am very new to driver development I find a lot of things going on here strange. Are you using Inverted Call model for communicating between driver and service?

ewil commented

Yes, I believe it is similar. https://github.com/godaddy/procfilter/blob/master/driver/kmdriver.cpp#L824 Is the section that decides how to react to a read request from the service. The decision is whether to complete the read immediately with data or to mark the read as pending, just as any other I/O operation where data is not available yet.