AutoHotkey Community

Well, so far in my research, the best option has been the idea of hooking the creation of DirectInput. I'm still trying to get a grasp on Madshi's library, I'm in contact with him via the forums as well to try and get some feedback on how it can be done. I'm almost certain, from further research on this subject, that this is the best way to approach this.

As far as it breaking down the road with future versions, thankfully that's one part of the DirectX SDK that hasn't had significant changes. I don't think this would be a significant issue once it's working. And even if it only works with 30 percent of DirectX games, that's 30 percent more than you had before. Though I REALLY think this is going to apply to about 90 percent of the DirectX games that use DirectInput. The other 10 percent fall into a new category with DirectX 9's callback method being introduced.

I'm going to continue working on this problem. If I get a working concept that can adjust the calls to GetDeviceState, then I'll be happy to pass it on.

Since Chris says he's going to be overloaded for the next 4 weeks, I was hoping maybe Wingfat would like to get in touch by ICQ or MSN and see if we can worth through creating a working hook. That would at least be a start. If we can hook GetDeviceState, we're half way there. Just manipulate as desired and exit the callback.

I'm really burning out trying to do this on my own, so I hope Wingfat will join my crusade! C'mon!

Hey i am ready to help in any way i can. You should register and get a allias on this site so i can send you a messgae. I didn't see your ICQ or MSN ids, plus i cant use those programs at work. email or this fourm is the best option.

Sorry about that Wingfat, I've registered now.

Email me at astaelan@telus.net

I don't often sit on the forum waiting for private messages, I'm constantly bouncing between 3 or 4 forums and 10 search engines, another 20 pages trying to dig for some tidbits of information. I think I'm getting really close now with the idea of using Madshi's madHookCode and hooking the device creations. Here's what my latest research and posting in other forums has made me aware of:

First, by using a free program available at http://www.smidgeonsoft.com/ called PEBrowse (some of you might have known of this already, I didn't), you can find out what exports a DLL has. For example, opening DINPUT.DLL showed me that 3 different creation methods are available:

DirectInputeCreateA, DirectInputCreateW, and DirectInputCreateEx

According to Madshi's latest hint (he likes to hint and point but never give actual answers, it's kinda fun, heh), and some other research, I found that you can create 2 things. First, an EXE, which uses madHookCode to call InjectLibrary. This has the ability to Inject a DLL of your choice into any program. The way it was explained is that it effectively patches the program in such a way that a call to LoadLibrary would be on the first line of the Main execution.
Once this has been achieved, the only other word for the EXE is to call UninjectLibrary when you are done. My understanding is that once you InjectLibrary, I THINK a hook is created so that any program matching criteria passed to InjectLibrary, will be hooked upon their execution. This means InjectLibrary returns immediately if all goes well. This is where I'm currently having some troubles, but I'll continue on the explanation.

Let's assume the DLL is called Hooker.dll for lack of better naming, heh. What we code into Hooker.dll is the actual calls to HookAPI. This is where the "exports" from DINPUT.DLL come into play. By hooking DirectInputCreateA, W, and/or Ex, it is my understanding we can obtain the DirectInput interface for the generic DirectInput object.
Further research leads me to believe that once you have this, you use the interface to hook a specific method. This is where HookCode comes into play. By calling HookCode on index 3 (the fourth method, 0 inclusive), I believe we are hooking CreateDevice. The first 3 (0-2) are the reserved COM interfaces for Query, AddRef, RemoveRef, whatever they are called. The first one after these, I believe I found in some research was CreateDevice.
So, by calling HookCode on CreateDevice, we should be able to get 2 more interface pointers. One for the Keyboard and one for the Mouse. It's entirely possible you could also get pointers for Joysticks and I believe ForceFeedback devices as well if you wanted to go that far. My concern right now is Mouse and Keyboard, with Mouse being more important.

Okay, so let's assume now we have piDIKeyboard and piDIMouse, being pointers to interfaces of the DirectInput Keyboard and DirectInput Mouse that the program has Created. Some internal workings of madHookCode demand that we declare a Next hook, which is actually the original hook before we hook into it. So, by calling the original hook for these first, DirectInput does it's job, creates the device and before we return from the hooks, we can call the next hook in the chain. Once we have those 2 pointers, we have to figure out what index the GetDeviceState method is in order to hook it.

Right now, my latest post to Madshi is requesting some information on how you find out the index of method's to pass to HookCode... He explained PEBrowse to find the initial export, but I'm not sure how to calculate the index of the interface methods after that. It may be as simple as opening a specific header file like dinput.h and counting the methods on the DirectInput interface types... That's going to be my next stop to see if it seems to make sense.

Wingfat, feel free to contact me, unfortunately forums and email are a very slow means of communication, I'm hoping ICQ or MSN are a viable option outside of work hours for you? My profile contains my ICQ and MSN but just in case, it's 2447380 or astaelan@hotmail.com and the email I check most frequently is astaelan@telus.net

Hope to hear from you soon. I'm hell-bent on figuring this out, happy to have someone on the team!

Well, after a bit more work I am discouraged again. I have used PEBrowse to open up the exe for the game, and found that only DDRAW.DLL and DSOUND.DLL are imported. Whereas in EQGAME.EXE, I see DINPUT8.DLL imported...
I'm not sure if it's possible for the program to hide it's imports, so it may be possible that DINPUT8.DLL is still being used, however I have now figured out how to hook, and none of the 3 hooks I've created are being called. Looks like I've done everything correctly, code returns happy, but the callback never occurs after the injection occurs.
I'm going to extend my hooks to hook DINPUT8.DLL as well and see if I can get EQ to at least trigger the hook. If I can, then I'm doing this right and I can write a hook for EQ, but it may not be possible for the game I'm interested in.

Also, I'm not sure about the commercial liscencing issues. What are the limitations on AutoHotKey for commercial uses? That's the main issue with being able to use Madshi's madCodeHook with AUtoHotKey, as there are special commercial liscensing issues. Furthermore, you CAN purchase the source, but as this is an open source project, I can't see there being money spent to incorporate the library statically.

Anyways, off to see if I can hook DINPUT8.DLL now, and if EQ will trigger it...

Well, I have some good news and some bad news.

The good news is, I successfully hooked DirectInput8Create and it was triggered by Everquest. Purely a test to confirm I was doing it right. Okay, so after that, I hooked all the other create's I could find. No problem. Still, EQ only triggered on the one as expected.

Next, I ran Priston Tale the same way, and nothing happened, as expected. This prompted me to further investigate and I found that in a DLL called HanDes.dll they have Imported GetKeyState, but not GetKeyboardState. They imported a bunch, I will list them below.

So I was thinking, if they are hooking all these, then maybe AutoHotKey still has a chance to work without utilizing any DirectInput stuff since this game doesn't use it.

Any thoughts on this? Does AutoHotKey hook GetKeyboardState or GetKeyState? Maybe that's the problem...

From what I can tell, GetKeyState only handles a limited number of keyboard keys only. How would mouse be hooked then? Probably with the SendMessage/PostMessage stuff? How can we use this to work around it, any ideas?



Thanks, hope this helps some?

None beyond what's in the GPL. In fact, if I recall l correctly, commercial uses aren't even mentioned in the GPL because all usages are considered equivalent.

If this turns out to be a problem due to the more restrictive nature of madCodeHook's license, it might be possible to distribute the hook module separately so that non-commercial users could freely apply it to their own copies of AutoHotkey.

No, but your mention of these triggered an insight: If the game operates by polling the keyboard, it is quite possible that the Send command fails to work because the keys aren't being held down long enough. I know there is at least one other game that benefits from modifying the send command as in the below example. Please experiment with this on your games to see if it helps:

SetKeyDelay, 50
Send, {k down}{k up} ; Separate down & up events to force a delay between them.

Interesting that the game might be using these... if they're hooking the keyboard or the mouse at a low level, that would allow the game to ignore artificial input if it chose to (by checking the INJECTED flag).

Hmm, I hadn't considered the lack of delay, I'll give that a try. Is there a similar SetKeyDelay for mouse delays?

I am going to try:

MouseClick, RIGHT, , , , , D
Sleep, 100
MouseClick, RIGHT, , , , , U

Should this effectively cause a right click down event, a wait of 1/10th of a second, then the corrisponding right click up event, correct?

I just tried, and it had no effect. Works fine at the desktop, with a slightly noticable delay.

So no luck there. However, you mentioned that it is interesting they use SetWindowsHookExA and UnhookWindowsHookEx... I wrote a program when I first started working with AutoHotKey to test all the flags of mouse_event and keybd_event's normally. Mine had different values, though INJECTED was still not set. Then I used the real mouse to create an event, this produced identical information to my third test, which was an autohotkey event. So, as far as I can tell, AutoHotKey is not adding the injected flag as we suspected. If it is, it's doing it at such a time I cannot detect... I've hooked the keyboard and mouse messages and they had no injected bit set.

I think I've almost given up on trying to automate this game, they are just too smart. The DLL seems to hook all the calls, and the game calls it through some DecryptFunc call the DLL exports. Hooking this function might be possible but it would take a long time to even figure out what is going on because I think everything the game does, it does through that DLL and that 1 function call. Just for the record, the function returns an int, and takes 2 char *'s (note: NOT const char *, just char *). No idea what's going on here, I may get bored enough to hook this method and find out what is going on later.

As far as my success with DirectInput, I was able to hook DirectInput8Create successfully, tested with Everquest and it notified me that I hooked it. With a little more work I'm certain I could hook further in and get to GetDeviceState, and hook mouse and keyboard for DirectInput games. If you're still interested in this, I can post my sample code that uses madCodeHook and you can implement madCodeHook as a plugin for non commercial users, and for those who have commercial liscenses from Madshi.

This game is truely frustrated me, but at the very least I can contribute what I learned about system wide API hooking and DLL injection, and not have been a total waste of time

Let me know if you want me to post it here, or email it to you Chris.

Yes, SetMouseDelay. Though in its case, the delay also affects the delay between the down and up events, so there is no need to separate them (I had forgotten that you were primarily interested in mouse clicks, not keystrokes).

Are you sure you were using a low-level hook? This is different from the standard type of hooks that also work on Windows 9x. All I can say for certain is that the injected flag is set differently for physical events than it is for artificial events, at least on my system. In addition, as far as I know, there is no control over how it is set; the system does it automatically based on where the input came from originally.

It would be good to have that for future reference, thanks.

If it's huge, it's probably best not to post it here. Even if it's moderate size it's probably better to send it to people upon request, because the forum converts all tabs to spaces and has other effects on formatting. My address is support@autohotkey.com

Thanks for all your work in this area. Although you didn't succeed on the game you were interested in, you may well have paved the road for myself or others to make progress in the future.

Unfortunately, had no luck with this. I guess it's just too smart with how it's using HanDes.dll to do it's own low level hooking.

On your other question, yes, I was using LL hooks and checking for injected flags. The program I had hooking the low level event, could not see any difference in any of the available data, particularily the flags where the MSDN said the INJECTED bit would be set. My real mouse and AutoHotKey seemed to generate the same flags, neither of which evaluated as having the bit set. But, if you said on your own system you can confirm with low level hooks that AutoHotKey does generate an event with the INJECTED bit set, and your real mouse doesn't, then I must have overlooked something. I was going to utilize a hook and strip the injected bit off the data, and that would overcome the problem I thought. Except, I found no bit set to strip. Though I am almost certain I used the same low level hook you're referring to, it's been a while since I did that and I think the code for it's gone now. But I recall finding 2 different hooks, like WH_KEYBOARD and WH_KEYBOARD_LL or something like that. I used the LL hooks and found no injected bits.

If I could identify where the bit is set, I could hook the API method and fool it into thinking injected input is real by stripping the flag. I just can't seem to identify the flag as being set anywhere. If you have working code for your system that does proves autohotkey sends an INJECTED event, and your physical mouse does not, I could probably hook that method with madCodeHook and perhaps strip the injected flag before it's returned.

Anyway, with regard to the DirectInput code, I'd be happy to email it to you. If I either figure this out (if you have that code to prove the injected bit is set?), or I give up, then I'll clean up my DirectInput hooking code, and see about my ideas on extending it to actually hooking GetDeviceState itself, as it currently just hooks DirectInput's initial interface. Then I'll send it off.

None the less, it was a frustrating but fun experience, I learned a lot. Appreciate your help with struggling through it, and I'm glad to have produced something you'll be able to benefit from.

Try this test script. On my system it proves that the injected bit is different. If you let the mouse move artificially every 3 seconds, the physical idle time is unaffected. But if you physically move the mouse, it will reset the physical idle time too:

#InstallKeybdHook
#InstallMouseHook

SetTimer, ReportIdleTime, 1000
SetTimer, MoveMouse, 3000
return

ReportIdleTime:
ToolTip, Overall: %A_TimeIdle%`nPhysical: %A_TimeIdlePhysical%
return

MoveMouse:
MouseMove, 3, 3,, R
return


That's pretty interesting. I once tried this and would be willing to try it again if you think it might help you.

If the above script works for you like it does for me, the relevant part of the source code is in hook_include.cpp. For keyboard, the flags field should have LLKHF_INJECTED in it if it's an artificial event. For mouse, it should have LLMHF_INJECTED (one letter different) instead.

Hmm, I ran the script and as you suggested, the Overall time updates to 0 periodically, while the Physical time only updates to 0 when I actually move the mouse.

hook_include.cpp you say... Hmm. I'd like to take up your offer on attempting to see if we can write an external program to strip that injected bit. I wasn't able to detect it in my hooks. I'm going to check out your source and see if I can figure out what you hooked to find the difference.

Another similar approach using madCodeHook, is that we can maybe try hooking the PostMessage or SendMessage or something like that, and stripping the injected bit there. This allows for a global system-wide hook on any API call. We can hook right into calls to PostMessage. This is how the DInput way works.

Anyway, I want to try the first approach with just writing an EXE which hooks the same low level events AutoHotKey does and see if I can detect the same injected bits. If so, I don't see why we can't strip that information before the hook returns.

My head is really spinning from the last week, I'm not sure I can focus straight at the moment. I really want to solve this problem, but I've come full circle to the first thing I tried and that's kinda depressing, heh. None the less, maybe some mind numbing XBox and then I'll dig into AutoHotKey source. At least it's in C++

If you decide to go ahead and give it a try yourself, pass me your results, and I'll play around with it too...

Talk to you soon.

If you want, I can send you a modified AutoHotkey.exe that turns off the injected bit before passing the struct-pointer on to the next hook. In theory, this should convert all artificial input into physical input. However, although it's worth a try, I fear it will not be that simple: modifying the struct in one hook might be ignored (not seen) in the others. And even if it works, DirectInput might gather its input separately and at a lower level than low-level hooks.

I don't see a strong enough relationship between PostMessage and the injected bit. As far as I know, the bit is available only to low level hooks and has nothing to do with Post/SendMessage. However, MSDN does say that the mechanism by which keystrokes and mouse events get routed to an LL hook is via GetMessage/PeekMessage. But it was my understanding that this is something built-into those functions and not something conveyed via message.

Okay, so if you made a modified AutoHotKey, you would basically have your hooks strip the injected bit, right? This brings up a question you sorta mentioned. What order must you start the script and game in question in order for the hooking order to work correctly? I would think you would have to start the game first, then once it's running, start the script. This is based on the idea that new hooks are added to the front of the list and called before older hooks, is that correct?

If you modified AutoHotKey to strip injected bit from input it sends, how would this be activated? Special directive? Always present when a script is running? Not quite sure how you would intend to incorporate it right into AutoHotKey...

I had another thought too. When you call the mouse_event API call, what exactly does this do? Does this call something like SendMessage or PostMessage to create the new event? Could you not hook those then, and strip injected at that point? Hook PostMessage and SendMessage system wide, and anytime there is an injected bit set, remove it and continue passing to the next hook?

I hope you realize right now that we're no longer dealing with DirectInput, right? I mean, I found out this game in question doesn't use DirectInput, so that's why we're looking at the injected bit again. I am pretty sure I can hook DirectInput using madHookCode, but I gave up on that for now because it doesn't apply to my situation like I thought.

Please go ahead and make whatever changes you think might work and email me a new EXE. I just don't quite understand what changes you are going to make so that all events have injected stripped, but if I can run the same test script you sent me earlier and have virtual events reset the both the overall timer AND the physical timer, then I think we might have something.

Thanks for digging into this, much appreciated, I know you are really busy.

Yes, that is true; but only if the game is also using an LL hook or if DirectInput is somehow related to LL hooks in a way that would be affected by loading order.

Because I'm rather pessimistic that it would work, I hadn't thought that far ahead yet. If it does work, a new command or directive seems best.

My understanding is that these functions simulate events at a fairly low level but do not directly produce messages. Other parts of the OS will instead do that if the event hits against an active window that has an message queue. For example, if you click on a console app that has no message queue (no message loop), I would guess that the OS does not generate any events.

I don't think mouse and keyboard messages contain the injected bit. If they did, that would open up all kinds of possibilities for further testing.

I know you probably said so, but it hadn't sunk in; thanks for pointing it out. However, although some games might be using something other than DirectInput to ignore simulated events (perhaps a hook or VxD?), it seems likely that many other games do exclusively use DirectInput. As as a consequence (intentional or not) such games probably block keybd_event and mouse_event.

I just ran another test and was pleasantly surprised. It seems that an LL hook on top of all other LL hooks can alter the bit in a way seen by the other hooks. My original test a long time ago had failed because I was trying to simulate Ctrl-Alt-Del; it probably didn't work because that is trapped in or near the keyboard driver itself.

Here are the details of the test:
To be sure the test was correct, I ran 3 different scripts simultaneously. They should be started in this order:
1) The one that simulates a mouse event every 3 seconds.
2) The one that watches and reports physical vs. overall idle time.
3) The one that that strips off the injected bit before passing the event on to the other hooks (unlike the others, this would should use the modified AutoHotkey.exe).

After doing this, the simulated mouse movement was seen as physical instead of artificial. Although this is promising, it might not help for your game if it does not use an LL hook, or does not actually check the injected bit (i.e. if it's using some other way to differentiate between artificial and physical).

Instead, I have posted it below in case anyone else wants to try it with a game. Note that most likely it will need to be started *after* the game to have the best chance of working.

http://www.autohotkey.com/misc/AutoHotk ... ysical.zip (also includes the test scripts)

Awesome Chris, this is exactly what I was wondering about.

As for your Control-Alt-Delete issue you are correct on that. It falls into the same category as some other special extended key combinations that windows filters at a lower level itself without hooks (PrintScreen, etc).

I'm very happy yo hear about your success in stripping the bit. The order in which you executed seems to make a lot of sense, and I think you answered a question I was going to ask about AutoHotKey, I'll ask anyway.

Let's say I have script1, this script has the purpose that when I press control-, it will run a second script and then exit the first script (with ExitApp). The result is the second script gets run and the first one is closed. My question is, if I use this first script to start the second script, do the scripts share any memory or process space between each other? What I want to know is if I use the first script to start the second script after the game is running, will this work correctly to "start my script after the game", or is some magic going to happen because the scripts run at the same time for a moment?

I guess the question comes down to whether AutoHotKey is run once for each script, or once for all running scripts at the moment and shared somehow? Just want to make sure if I USE autohotkey to start the script in the game, that it won't cause some hassles with hooking because the first script had AutoHotKey open before the game was started... Does that make sense? Hard to convey what I mean here... I guess if all else fails I can use windows AT command to start the script 2 minutes after I run the game, to ensure my theory is correct.

As for this game in question, it doesn't use DirectInput as you are now aware. However, I think that this injected bit has been the problem all along. This was my first idea, but like yourself, my first attempts were not very successful in detecting the injected bit in the low level hooks. Kudo's for pegging that down and thank you kindly for posting this modified zip.

Do I have to do anything special to strip the injected bit (as your point 3 indicates), or does this version just do it automatically for now without any directives/special code?

With this new AutoHotKey, my test script is simple. I'm going to call "MouseClick, RIGHT". My assumption is the new EXE is going to automatically strip the injected bit for me, right? I'll test again with the original script you sent to see if it's stripping at the desktop at least.

Thanks again, we're getting close I think

EDIT
I noticed that if I run the first 2 scripts with the modified AutoHotKey.exe, I don't need to run the third one, at least not at the desktop. The physical is automatically updated by the move events in the first script as long as it's run by the modified EXE. I took at look at the third script, not sure if I understand it's purpose. Are you just trying to add a new hook to the top of the list with the last script, since it's run after the game which will add a hook too? I'm sure I've confused you good, I haven't been explaining myself well today (I caught a flu )