AutoHotkey Community

[Astaelan]

Alright, it's been a long time since I've been to these forums, the last time was regarding a topic that seemed to go on for some 52 pages after I left. I'm back again to bring life to this topic once more.

The topic is that of simulated input to applications (particularily those using DirectInput or other kernel level means of input detection). As before, I solved this problem but the solution was erratic at best. Having lost interest in the project, I moved on and to no big surprise have come full circle to the same problem. After searching the forums, I see some folks have found some ingenious solutions stemming from the original idea. However, nothing concrete has yet been provided to solve this problem.

My original project involved kbdclass and mouclass drivers. At the time, and even now, I was and still am fresh to writing drivers, it's not something I do every day, however at the time of the first attempt I did not understand that the class level drivers are the first stop for all data, it seems like it may be more compatible and friendly to use a higher level filter driver. It is still handled within the kernel, however rather than replacing your standard kbdclass driver, a kbfiltr can attach itself to one (or many) devices as required. A little probing of google rendered some results that allow you to easily attach to the first keyboard on the system which is 99% of the time going to result in the desired effect, attaching to your main keyboard. Within this realm, it is possible to change, remove, or add new data to the buffered IO queues. However, some who could contribute to this may not fully understand how this works so I'm going to elaborate.

The kbfiltr driver is attached to a kbdclass driver. Now, when a kbdclass or kbfiltr is called into, you're not JUST passing keys. In fact, your keyboard in this case, passes various types of IO commands to the same function, you may read a key, write a key, deal with special scan codes to interact with keyboards that have lights, stuff like that. So this one stop access point we'll call the ServiceCallback. So how does this all relate to injecting input undetected? Glad you asked.

First of all, these 2 drivers appear to only work with PS/2 devices, this explains why my first attempt may have failed with the mouse when trying to write that driver, I probably had my keyboard plugged in via PS/2 (to avoid legacy USB support in BIOS when reformatting), but left my mouse plugged in by USB. So herein is the problem, USB devices won't be affected by these drivers. Is this a big problem? Not really, and one I will be overlooking for the remainder of this solution. It will be assumed that your keyboard and mouse can be plugged in via PS/2 ports, but if you're adamant and skilled, you can get the Windows WDK and attempt to write USB drivers to the same effect, it just so happens the PS/2 stuff is significantly less involved not having to deal with many of the intricacies of the USB standard.

Okay, so you asked how this relates to injecting input, I'm getting to that! There is a Win32API function called DeviceIoControl, and this allows you to send IO control commands to the driver, more importantly to that previously mentioned ServiceCallback. So as you may or may not realize, the driver isn't specific about the IO control codes it is sent, it is upto you writing the driver to determine how control codes are processed, including unknown codes. However, if this has interested you then you may have already done a little digging and found that there is mention of an INJECT IO control command, and a little more trial and error would make you realize that it doesn't do anything, the control code appears to be ignored, or at least this was the result of prior testing I had done for the first attempt.

So, the solution to undetectable input lies in kbfiltr and moufiltr. To that end I have recently started playing a game when I'm kinda bored, called 2Moons, suffering from much the same problems as the prior Priston Tale, and many other games it would seem. If I get this solution to work, it should be as simple as updating your driver in device manager with an INF and SYS file to allow injection. From there, it's left to user-land to provide wrappers around the DeviceIOControl calls to make injection more end-user friendly.

I know there is a fairly large interest in this topic, so I guess I'm posting to reactivate that interest and ensure that someone else hasn't already provided this solution and I have somehow overlooked it somewhere. Please disclude my old solution, as it was a kbdclass filter and was far more detrimental to the system in terms of ease of installation. Removing a kbfiltr be as easy as removing a single registry entry and deleting the .SYS file, while the kbdclass stuff required reinstalling the original driver from the windows installation if you wanted to remove it.

Chris, I know I spoke with you directly about this subject quite extensively, and recent posts from you show you haven't followed up on it with AutoHotKey, but that you seem willing to adopt a solution like this as an optional install, or secondary download. This project is not at the top of my priorities list, but if this topic picks up some momentum and discussion by a few coders who know what they're doing, then I might take some of the feedback and get the driver written. It's not that complicated in it's own, but you may want to wrap the DeviceIOControl calls in AHK, or you may want a separate DLL to use for calling into to make it easier, a discussion would be prudent.

On a side note, I see AHK's language grammar and functionality has come a long way from when I last used it, that's great to see as I've considered using Spart (.NET spirit clone) to write my own AHK like clone until I found AHK's grammar had matured a bit to allow more complex concepts. Still, might be a fun project to try.

So, everyone, show your interest, motivate me to write the drivers, show me it won't go to waste

[[VxE]]

Hmm... that's some intriguing ideas there.
I might not have any experience in WDK, but I can assure you that if you devise a way to get AHK's artificial input to masquerade as physical input (through tweaked drivers), everyone who plays MMOs will be interested.

As for method of implementation, it may be convenient to package the driver tweak files into a single DLL, which then would allow easy integration into AHK via DllCall. Doing so could also make (un)installing the tweaks as easy as a Dllcall.

And, just to be sure, this post is in the 'help' section because you want motivational help?
_________________
My Home Thread
More Common Answers: [1]. It's in the FAQ [2]. Ternary ( a ? b : c ) guide [3]. Post code inside [code][/code] tags !

[Erittaf]

well the MMO crowd will certainly love it... until the MMO makers find out what you've done and reverse engineer it and block it. It'll take some time but it would be cool for a while.

As for myself I can't think of a situation where I would use it but I'm sure if it were available I would certainly find myself using it for something that I would not have otherwise thought of or thought possible.

Short version.... yeah, go for it.

P.S. look out for AV complications!

[Astaelan]

Hey guys, nice to see some immediate feedback. Regarding VxE, it's in the help forum because while I have had a little experience with this, most of the interest will be generated from here as people ask for help trying to get input to work.
To that end, I will post my results as I go, I need to rehook my mouse and keyboard to the PS/2 ports before I start, then I'm going to start with the mouse filter I think. On the other hand, part of the help forum is I wouldn't mind getting feedback from anyone who's done something like this before.
I will be starting on this later this evening.
Regarding Erittaf, I don't think this would be detectable persay. It appears like a valid keyboard driver, it's kernel level and is where DirectInput and other methods who restrict input get their input from. Worst case scenario, a game USES a kernel driver to get it's input (what is the world coming to when we're rootkitting on game installations?), and even then we can push the filter down to a lower level and still maintain access to inject data before calling the higher level kernel driver they use to get input. The only way this could be detected is enumerating the keyboard filters and specifically scanning for a specifically compiled version. This might stop the use of AHK itself, but wouldn't stop people from compiling their own driver with some changes to prevent it from being detected, and still be able to use it with AHK with whatever implementation is decided on for communicating to the driver.

[Lissy]

Bump

Any project page or website for beta testing release or non working tryout workaround examples.

Thanks

[Astaelan]

Nothing as of yet. As it turns out, my original code was lost in a system crash, so I was starting from scratch. After looking over the keyboard and mouse filter examples, I'm convinced there is a way to inject packets from an upper-level filter, however I had some difficulties in getting the upper-level filter installed to the devices. This is different from my original attempt in the fact that the original attempt used lower-level class driver rather than filters. It may not be possible to do injection with a filter, but I'm not entirely willing to accept that yet.

In all seriousness, the solution is not something that's going to be cut and dry, works for everyone, runs out of the box and has no impact on the system. After all, we're dealing with drivers. The mouclass and kbdclass drivers are effectively the lowest level between a physical device and windows. As far as the kernel is concerned it cannot tell the difference between you injecting fake data, versus being copied from the IO port queue. If you are truely interested in this solution, or testing a quick work around, I recommend you get the WDK. With accepting that the lower-level class drivers may be the only way to achieve the desired results, it should only take a person a few lines of code to add the injection.

Long story short, those who are weak of heart should probably forfeit the idea now, but those who are eager and not worried about having to reinstall windows drivers, should rip open the WDK and look at the 2 examples. Having already done this route with mouclass and kbdclass before I'm not eager to try and figure it out again, I was truely hoping to get it working with the upper level filters such that they could at least be loaded once, and disabled when not in use (As close to unloading on the fly as you get with drivers)

Best of luck to all.

[nahckcaj]

Hi Astaelan,

I happened to fall on this thread regarding kbd and mou. I was like you, when I got really bored and started to picked up online games again. And it comes to my concern about this topic as I played along.

I don't have a good programming background, but I do play around with simple autohotkey codings.

I started researching about dll, SendInput, .sys class files, drivers etc. And I actually started a topic about integrating autohotkey into driver-based. Then I ended up in Micha's dll thread, where he programmed it to suit HID devices. That is pretty much useful for me at the start, but Micha is kinda busy to reply my message. Somehow I managed to find about kbdclass then your Kbfiltr and Moufiltr.

Did you mean you are going to stop this project? I think you're the only person whom I came across is keen on doing this. I actually heard from my lecturer before, about making an input device automatic. This website actually enlightened me alot about this whole thing which I'm researching. http://pro-k.com.my

Someone actually made such a device specially for all these. The whole thing seemed so simple, but yet it's hard for me to find any solution. Although that device uses another form of inputting, I think it's pretty much similar to what we are talking about. They are using one of the method to make it work.

Astaelan, I hope you're still around, and maybe my info could push you a little.

I'll continue researching until not anytime I will give up.