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.
Related
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.
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'm working on a small chat application written in C++/Qt. My users are complaining that the connection is not shut down gracefully when they are closing the laptop lid and the computer enters standby.
Is there a Win32 hook available that is called when Windows is about to enter standby?
WM_POWERBROADCAST
Reimplement QCoreApplication::winEventFilter in your application to handle Windows standby events.
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.
I have to write a Windows Service application (no GUI) that will monitor an event, and if it occurs will send a standard windows message to an application. The handle of the application will be given to the service by a DLL which is then unloaded, so a windows message is the way we wish to use.
The question though is whether the service needs to do anything special to use SendMessage to the window handle, given that it might be on a different screen or something in Vista. Is this possible, and if so, what do I have to do please?
User Interface Privilege Isolation (UIPI):
Microsoft Windows Vista and later.
Message sending is subject to User
Interface Privilege Isolation (UIPI).
The thread of a process can send
messages only to message queues of
threads in processes of lesser or
equal integrity level.
Source
You can read about User Interface Privilege Isolation (UIPI) here.
To get around this you can set uiAccess to true in your manifest file. You also have to make sure your application is signed using authenticode with a certificate from a signing authority such as VeriSign. This can get pretty expensive.
Session 0 isolation:
It is also my belief that you can't call SendMessage across sessions. So if you have a service running in session 0 you need to find another means to communicate with your process that would be running in a session > 0. Example: via pipe.
In Windows Vista, Windows 2008 Server and later all services run in session 0, and all applications that you start run in session > 0. This is called session 0 isolation. Here is a good document that has information all about session 0 isolation.
If you don't have access to the source of the program you want to send messages to, you could get around this by making an application that communicates with your service and acts as a proxy to relay the message to the application in its same session.
Overall:
If you develop your application on pre-Vista and it works fine. There is a very high chance it will be broken in Vista.