I'm using the Windows Filter Platform to implement a simple firewall application.
Actually my driver is a callout driver and it can intercept 2 kinds of event: FWPM_LAYER_ALE_AUTH_CONNECT_V4 and FWPM_LAYER_ALE_AUTH_LISTEN_V4.
The driver can communicate with usermode app using inverted call model: the usermode app performs some IOCTLs, the driver save them on a queue and return a buffer when an event is triggered.
I have only a problem. I need receive a response from usermode app to the driver, so that the driver can block or permit the connection.
In past i have worked on a minifilter driver and i have used FltCreateCommunicationPort to send an event to usermode and wait a response from it ( with FltSendMessage from minifilter).
So the question: Is there something like this with WPF?
not sure if WFP provides such mechanism. But if your requirement is to share some notification events between user and kernel mode then you can use something similar as described in http://www.osronline.com/article.cfm?id=108.
WFP framework does not have any api like FltCreateCommunicationPort, you need to implement IOCTL and FwpsPendOperation0 and FwpsCompleteOperation0 WFP apis, check WDK WFP inspect sample.
Related
I'm currently working on a Core Audio user-space HAL plugin based largely on the "NullAudio" driver example provided by Apple. (Here's a link to the example driver.)
I'm trying to figure out how a client application can communicate with the driver in order to configure it. So far I've tried using CFPreferences and CFNotificationCenter but neither work. In the latter case I can only communicate using the Darwin notification center, but its notifications cannot include any data other than the name of the notification, and consequently it's not useful for this purpose.
Given that the HAL driver is sandboxed, what method am I supposed to use to have a client application communicate with the driver?
I have two apps that run on the same server. One is a c++ app and another is a java web server running on top of vertx. The webserver wants to send request to the C++ part and obtains response. ZeroMq seems a performing solution to do the inter process communication. And it exists a bridge to vertx (https://github.com/dano/vertx-zeromq), but no so well documented.
I'm wondering if what i think can be done with this bridge:
C++ zeroMq socket type is a dealer, it registers to the event bus by sending the appropriate message that contains the handler adress.
Webserver send data to the socket event bus handler address and get response in its callback.
Does it have an opportunity to work or i misunderstand the zeroMq bridge ?
That sounds correct to me but you don't need ZeroMQ - you can just used regular TCP - https://vertx.io/docs/vertx-tcp-eventbus-bridge/java/ and that has good documentation and support.
I'm currently looking into the benefits of using ZeroMQ for my project and suspect it is useful for more complex topologies like "broadcasting an event without knowing who wants it (don't require handlers to register)" but Vertx doesn't support this from what I can see.
I'm about to write the following interaction:
When there is a process about to start, driver will notify user app and then it will wait for response from the app.
The app will decide whether or not to allow that process to be created normally or terminated immediately, and send its decision back to the driver.
Base on the decision from user app. The driver will then allow or block the process execution.
This has to work for Windows XP - Windows 8.1.
My question is: What is recommended way to notify user-mode app from driver and then make the driver wait for the response?
The standard way to do this is to have the app start an asynchronous IOCTL to the driver. When the driver wants to notify the app that something happened, it completes the IRP and the IOCTL completes on the app side.
There is device connected to PC via 1Gbit Ethernet. WinXP/7
I want to capture data in the following way:
PC sends command to devices (initiate data acquisition)
Device is sending data to PC
User application waits for acquisition
Driver saves data in the memory
Device sends command to notify that it finished acquisition
Driver generates interrupt and user application starts reading data from driver
I have no idea how to implement that.
There is NIC driver. There is NDIS. Can user application communicate with NDIS?
Do i need to write additional driver to communicate with NDIS?
Your problem really has two parts:
How to send commands to the device
How to capture data sent from the device
The first problem has two possible solutions, depending on whether your device accepts commands encapsulated in IPv4/IPv6, or whether it requires some other low-level protocol. If the device accepts commands encapsulated in IPv4/IPv6, then just use the sockets API in your favorite programming language.
If the device requires its own non-IP protocol, then you need to add an NDIS protocol driver. There is a sample protocol driver that is included with the Windows Driver Kit; this driver essentially opens a channel that allows a usermode application to send any kind of packet. (This would be a security issue if it were deployed widely, which is why it's not a built-in feature of the operating system.) You may need to modify the protocol driver to selectively listen only for control messages from your device.
The second problem — packet capture — is already solved. You should be able to pull existing software off the shelf and integrate it in your solution. Microsoft Network Monitor has an API that you can use to easily start/stop packet capture, and iterate through the captured results. Alternatively, some people use WinPcap.
I have built a WFP callout driver which runs in kernel mode.
Now, I'm trying to figure out how to communicate between this driver and my GUI application which runs in user-mode. Any ideas?
Exactly what I want is something like this:
The callout driver detects an incomming connection on port 4444 (This is not part of my question)
The drivers send a message to the user-mode app.
The app shows a notification to the user and asks it if we should accept/block the connection.
The user-mode app sends back the user's response to the callout driver.
Thanks!
I agree with LordDoskias. You need to create a device object and make it available to the Win32 realm. Then you can use CreateFile, ReadFile, WriteFile and the already mentioned DeviceIoControl to send requests.
In order to get notifications from the driver to the application, you can use the so-called inverted call model. You send down some IRPs (via one of the mentioned mechanisms) and do that in an asynchronous manner (or in separate threads). Then, the driver keeps them dangling until it has to notify the user mode component about something and then returns the completed IRP. Alternative methods are to set some event and have the UM request whatever the driver keeps in some kind of queue...
The gist is, there is no direct way that the driver can send some message to the user mode application.
Check this API call - DeviceIoControl
Essentially what you would do is register the driver in the object manager, then your GUI application will be able to open it and send different commands and data (there are buffers to do that) and then you have to send some custom made IOCTL code (check with the WDK manual).
If your driver is registered as a minifilter driver,
you can use minifilter communication functions, such as FltSendMessage.
Otherwise, you can use the DeviceIoControl function as it was already suggested by the other users.