Problems encountered when developing a keyboard filter driver to simulate buttons

How to dynamically load the keyboard Filter Driver

I recently wrote a keyboard filter driver. The problem was that after the dynamic loading was completed, a blue screen would be displayed when I had another key operation. After reading some information, I finally understood the reason and wrote it for your reference, so that later friends may not repeat this depressing process.

It is important to understand the working principle of the dynamic anti-load keyboard filter driver. It is important to know that the keyboard filter driver works in asynchronous mode. To get a key operation, first you need to send an irp_mj_read to the device stack of the driver. What kind of processing will the driver do when it receives the IRP? It will keep this IRP as pending uncertain, because there is no button operation until a key is actually pressed, the driver will immediately complete this IRP, use the data of the key that you just pressed as the return value of the IRP. After the IRP is returned with the corresponding data, the operating system will pass these values to the corresponding Event System for processing. What then ?? The system will immediately send an irp_mj_read request, wait for the next key operation, and repeat the above steps. That is to say, at any time, the device Stack has a keyboard irp_mj_read request in pending state. This means that only when the response is completed and new IRP requests are not sent Will a short time be taken. From this we thought that when we dynamically load the keyboard filter driver in the general way, basically there are irp_mj_read requests in the pending unknown state, but we are not carrying the driver, in the future, when you press the button, you need to handle this IRP, but you cannot find the corresponding driver. Of course, the screen will be blue.

The above analyzes the reason for the dynamic royal keyboard filter driver blue screen, and analyzes that there is a short time stack bottom without IRP in the middle, so let's find a solution to it.

According to an e-document on the internet, only ioattachdevice mounting/device/keyboardclass0 (or others) can be used for dynamic load control, but not for upperfilters loading. The original text of this section is as follows:

This problem occurs in most of the keyloggers Based on the sysinternals ctrl2cap model, which has been widely adopted and adapted. it applies to the earlier versions of the filter, which manually attach to/device/keyboardclass0 (or others) using ioattachdevice. (if you install your filter by adding it to the upperfilters value of hkcr/CCS/control/class/{4d36e96b-e325-11ce-bfc1-08002be10318} key More recent versions of ctrl2cap do, you just can't unload: Your filter is wedged into the stack for as long as the system is running and can't get out. but if you wedge by ioattachdevice, unloading is still possible in theory .).

Let's further analyze the reason for the blue screen. Why is there an IRP at the bottom of the stack? This is because irm_mj_read is asynchronous. for asynchronous requests, we basically care about the results of this asynchronous request. How can we get the completed data? You must have thought of the Setting completion routine. Yes, that's it. Because we have set a completion routine for irp_mj_read, our completion routine will be called after the completion of the IRP, giving us the opportunity to process the returned data. In this case, we dynamically load the keyboard filter driver, that is, the completion routine has been taken away by us, in the future, after pressing this IRP button again, the interface will call the interface that does not exist at all. The blue screen can be imagined.

Is there no problem if you do not set the completion routine? The answer is yes. However, without the completion of the routine, we can't process the returned data, and thus the function of the keyboard filter driver is largely lost. How can we set a complete routine to process data and achieve dynamic load control? Here we think that when irp_mj_read arrives, I will not set the completion routine for this IRP, nor pass the IRP down, but create my own IRP, then, follow the previous irp_mj_read settings and complete the routines for this IRP. Then, the IRP is passed down and the original irp_mj_read is set to pending. When there is a button operation, my IRP returns the completion routine that is triggered for it. Here, the irp_mj_read is obtained to fill in the previous irp_mj_read and then the irp_mj_read is returned. This is equivalent to using a proxy, which is transparent. Here we have implemented the completion routine, that is, the opportunity to process data. Next we should focus on how to implement dynamic load control after such processing?

Let's assume that we have received the request from Yu Zai. Let's see the status of all the IRPs currently:
(1) The original irp_mj_read that we saved is in pending. Note that it is not passed down and the completion routine is not set.
(2) A self-constructed IRP is at the bottom of the stack. Note that we have set a completion routine for this IRP.
Basically these two IRPs, because our own IRPs have their own completion routines, the same situation may occur during the attack, resulting in a blue screen. What should we do? We noticed that the IRP is constructed by ourselves, so we can cancel it. This will not have a big impact. However, after the cancellation, the original irp_mj_read at the bottom of the stack is gone. Note that (1), do we still have the original irp_mj_read? Yes, it is to pass down the original irp_mj_read. Here, we must note that our own driver is about to handle loads immediately, so we should not set the completion routine for it when passing the original irp_mj_read. Pass down to control our driver. Haha, success !!!

 

Of course, there is a simpler method here, which can also be implemented by using counters. It is much simpler :)