I am new to windows filter drivers. From the sample code of (MSDN) what I have seen is that, File system filter driver, has Filter Manager associated with it, and process filter driver doesn't have Filter Manager associated with it. So why is that difference?
So need some suggestions and help.
It seems that you might want to read Windows Internals by Alex Ionescu, this will clear things up for you, starting from the bottom and will help you understand the whole thing.
Basically, in the past, filesystem filter drivers were built in a way that it would sit in a the right position in the exact filesystem DEVICE STACK, for example, NTFS. That way it would get the chance to filter IRPs.
Nowadays, the thing you mentioned, the filter manager (FLTMGR) has its own (legacy) driver at the top and on the bottom of the device stack, and it lets you register a callback function that everytime an IRP gets caughted, you'll get a chance to handle it.
Process (creation/deletion) filtering is a bit different, it is not handled using IRPs, basically in the call flow of NtCreateUserProcess on the kernel side there is a function responsible for calling whatever function registered for this kind of callback.
I hope that it clears things for you.
Related
I read here that the inverse is possible, but how does one achieve such a thing? I'd hope there's a simple way, similar to calling from a loaded DLL, but my google research comes up with nothing. My only other thought is that one could pass some predefined constants through WriteFile or DeviceIoControl that the driver parses like a switch statement to execute the relevant function; does a more direct method exist?
The question is why would you want to do it? Generally if you have to rely on some mechanism like this, you need to revisit the design of the application/driver that you are writing.
The correct way to do something in context of your user mode application is exactly what you described. You can do a DeviceIoControl call to your driver and the driver validates all the parameters that you have passed, then carries out the operation on behalf of the user mode call.
If for some reason, you need to call into kernel directly, you will have to resort to undocumented methods. There are ways to hook into kernel dispatch table and overwrite one of the dispatch handler to redirect the call to your function. But I hope you never ever ship anything like this to your customer. This is good for learning how the dispatch table works, etc but introduces several security nightmares. Ultimately your software should not be responsible for someone's machine getting hacked.
Okay first a little context. I have started working on a project in my uni, one of the goals of which are to develop a module that will log when a process tries to:
-create, delete or modify a file (filesystem activity basically)
-create, detete or modify a registry id/value
We will actually be specifying a process for this module to monitor, and whenever this process tries to perform any of the activities listed above it will get logged.
Right now, i am looking into the basics of Driver development, and Filter Drivers as suggested by my DS. Here is my question,
What would be the best method to achieve this, would it be by writing a filter driver of some sort? if yes than exactly what filter driver, a filesystem filter driver or a minifilter driver or something else? Or don't know maybe some other technique?
I just need a little direction, so that i can do targeted research and implementation, as i don't have much time for this project!
File system minifilter drivers is the way to do this.
But the tricky part would be how do specify process to monitor. If you are thinking of PID then its quite straight forward, but if you are thinking of using process/executable name like notepad.exe then that becomes little complicated.
Just to give you hint, you can get PID for the operation in mini filter but not process name. So you will have to maintain a map of PID to process name in your minifilter driver. You way want to use PsSetCreateProcessNotifyRoutineEx and PsSetLoadImageNotifyRoutine.
I need a two-way communication between a kernel-mode WFP driver and a user-mode application. The driver initiates the communication by passing a URL to the application which then does a categorization of that URL (Entertainment, News, Adult, etc.) and passes that category back to the driver. The driver needs to know the category in the filter function because it may block certain web pages based on that information. I had a thread in the application that was making an I/O request that the driver would complete with the URL and a GUID, and then the application would write the category into the registry under that GUID where the driver would pick it up. Unfortunately, as the driver verifier pointed out, this is unstable because the Zw registry functions have to run at PASSIVE_LEVEL. I was thinking about trying the same thing with mapped memory buffers, but I’m not sure what the interrupt requirements are for that. Also, I thought about lowering the interrupt level before the registry function calls, but I don't know what the side effects of that are.
You just need to have two different kinds of I/O request.
If you're using DeviceIoControl to retrieve the URLs (I think this would be the most suitable method) this is as simple as adding a second I/O control code.
If you're using ReadFile or equivalent, things would normally get a bit messier, but as it happens in this specific case you only have two kinds of operations, one of which is a read (driver->application) and the other of which is a write (application->driver). So you could just use WriteFile to send the reply, including of course the GUID so that the driver can match up your reply to the right query.
Another approach (more similar to your original one) would be to use a shared memory buffer. See this answer for more details. The problem with that idea is that you would either need to use a spinlock (at the cost of system performance and power consumption, and of course not being able to work on a single-core system) or to poll (which is both inefficient and not really suitable for time-sensitive operations).
There is nothing unstable about PASSIVE_LEVEL. Access to registry must be at PASSIVE_LEVEL so it's not possible directly if driver is running at higher IRQL. You can do it by offloading to work item, though. Lowering the IRQL is usually not recommended as it contradicts the OS intentions.
Your protocol indeed sounds somewhat cumbersome and doing a direct app-driver communication is probably preferable. You can find useful information about this here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff554436(v=vs.85).aspx
Since the callouts are at DISPATCH, your processing has to be done either in a worker thread or a DPC, which will allow you to use ZwXXX. You should into inverted callbacks for communication purposes, there's a good document on OSR.
I've just started poking around WFP but it looks like even in the samples that they provide, Microsoft reinject the packets. I haven't looked into it that closely but it seems that they drop the packet and re-inject whenever processed. That would be enough for your use mode engine to make the decision. You should also limit the packet capture to a specific port (80 in your case) so that you don't do extra processing that you don't need.
Is there any way to hook all disk writes going thru the system, and receive the file names of whatever's being modified, using the Win32 API? Or is this something that would require writing a driver?
You can't do this in user mode, it needs to be kernel mode and so that means a driver. You need a File System Filter Driver.
If you don't care about intercepting the actual data, and only want to know which files are being modified/created/deleted then you can use the ReadDirectoryChangesW API to get that info from userland. Note however that it's one of the hardest functions to use effectively and efficiently, and you should be familiar with IOCP to use it correctly.
I'd like to call my app from my driver when an interesting event happens in the Windows kernel. I need to be able to pass at least 4 bytes of data back to user mode. How to achieve this? These events might happen quite, but not too, often, so I don't want to build a queue system and use IOCTLs.
I was thinking of something like the driver gets loaded, the user mode app registers its callback using IOCTL and kernel keeps calling that callback when events happen and finally the user mode client unregisters the callback and no more data is send to user mode. Is this possible?
I'm new to kernel programming, so after a day of googling I decided to ask here. I've noticed that there isn't much discussion about the kernel and drivers. And even less proper docs.