Dotnet Source Example Sending Keyboard Input to Wow

[joe7314]

This is (I think pretty straight forward) code which will send keyboard messages to WoW.

It is in vb.net, c# ppl can easily convert it at the url:

Convert VB.NET to C#

If you have not used the utility Spy++ that comes with visual studio, not the express versions though Then you should give it a try. Start up Spy++ and start up wow, refresh the windows view. Use search because the list will likely be very long. When you open the search feature you will see what looks like a little target you might shoot a bow and arrow at. Click and drag and drop it onto the wow window and it will fill in the search criterea. Hit the button after that and it will take you to the WoW window. Right click and select "messages" and it will open a new view where you will see all the messages being sent to WoW (even your own, assuming you're running the attached program).

I haven't messed around with mouse messages yet. I read some discouraging information when I was developing this code, but if anyone has any tips or needs any tips that'd be great.

I'm releasing this in hopes of getting a little +rep, mainly because I have none.

I'm starting to code a "real" out of process bot from scratch, Unless Cypher converts me to memory reading But it would take a lot to do that, because I'm persistant once I get started on something and it would take something extra special to make me deal with { }, Begin and End is so much easier on the eyes (yes I'm an old man blind as a bat). Plus managed code ROCKS!

One thing I'd be very very very interested to see, is how this code works or doesn't work (or can be made to work) on foreign versions of Wow. I'm wondering how hard it might be to insert some culture stuff. All I am familar with is an american keyboard

Thanks for reading my rant, -Joe

[flo8464]

Always a good thing if people have the will to contribute, but this is stuff which should be obvious to everybody in this section.

[joe7314]

As I feared, this technique only works for the keyboard input. I'm working on something completely different for the mouse input.

The software I'm developing for mouse and keyboard input into WoW I am attempting to stick with the design that has 3 distinct features:

1) it's out of "really" out of process
2) works in the background (multiple WoW's on one machine)
3) requires only dotnet (with native/api calls, but not other libs)

One thing I forgot to mention that may be of some interest to people. Is the code that raises an event if the wow window closes. I orginally polled, but polling is icky, much better to have an event

 
Private Sub thisProcessExited(ByVal sender As Object, ByVal e As System.EventArgs)
        thisProcessClose()
    End Sub

    Private Sub ButtonLaunch_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ButtonLaunch.Click
        thisProcessClose()
        thisProcess = New Process
        thisProcess.StartInfo = thisProcessStartInfo
        thisProcess.EnableRaisingEvents = True
        AddHandler thisProcess.Exited, AddressOf Me.thisProcessExited
        thisProcess.Start()
    End Sub

I Apologize for my entry level contributions, but I started from scratch. It takes time to type type type (pun intended).

-Joe

[lanman92]

I don't know how you can read that VB... It looks like a 4 year old's language.

[amadmonk]

I'm not going to bash on the VB -- hooray for choice, even if it's not what I'd choose

However, you're going to have a problem:

You want this:

1) it's out of "really" out of process
2) works in the background (multiple WoW's on one machine)

You won't be able to get that, at least not for mouse input. You can do *most* keyboard input with POST's to background windows (although typing in the chat box will be challenging, as you'll soon discover).

However, mouse input is a different ball of wax. Mouse capture in a background windo is completely impossible (AFAIK) in WoW without (a) some kind of hook, which defeats your "out of process" thing. Without mouse capture, any kind of mouse movement is impossible, and you're stuck with WASD for movement. Also, you'll need to have some kind of ScreenToWorld implementation going to "click" on anything except the UI.

TLDR:

Keyboard input is a piece of cake. Mouse input -- ESPECIALLY background mouse input, which *requires* mouse movement messages to simulate actual input events -- is a much more challenging issue.

I'd love to hear about any success stories out there where people are doing completely non-injected, and non-CTM based movement.

[lanman92]

Isn't the only relatively safe way to do background mouse movement through a driver? Unfortunately, it would be much difficult to do this on x64 windows. Wasn't Glider using a driver to hook GetCursorPos(or whatever it's kernel-mode equivalent is..)?

On another note, it's not really too difficult to get keyboard turning properly, but it's slow.

[RoKFenris]

One way (although probably unacceptable for most of you) is to do it under Linux. You just need to:
- Set Wine to run applications on a virtual desktop, and run WoW fullscreen. This makes WoW think it is always on the foreground.
- add a single line to dlls/winex11.drv/mouse.c, in the X11DRV_GetCursorPos function, in order for Wine to never query the real cursor position and just use the last cursor position message.
- send mouse events to the wine window. As a bonus, Wine does not care about the hardware flag; WoW will see anything sent its way as if it was sent by the hardware.

[joe7314]

I am starstruck a few excellant coders actually responded. There are so many quotes I wanted to address I couldn't pick one. But I can confirm everything that has been said here is true.

It seems I can not have my cake and eat it too. I have to compromise on something. (stupid mouse architecture) It was designed the way it is for drag and drop operations.

Dotnet has a class called native window that I was hoping to utilize along with rawinput but that requires a hook anyway (injection). Of couse I tried everything else mentioned in the thread (which is why I can confirm it in first person). The best I could do was "share" the mouse under the conditions that the wow windows are not minimized (not background).

I can not express how much I hate writing device drivers. Another way to put that is I can not express how much I hate rebooting every 5 minutes. But it's a real possibilty at some point. For the immediate time being I'm sticking with the keyboard while I work on the rest of my packet sniffing routines.

Movement is not going to be a problem (totally out of process) I can confirm that (it's just a matter of time for me to write the code). But without the mouse things like clicking on a mailbox or bobber are things I have no idea on how to do without mouse input. Is there a way to do these types of things with just a keyboard? I haven't looked into any wow api's since most of the really helpful functions are protected now, so much to do and so little time...

I have also not had time to look into warden at all, since my plans are to stay completely out of process. But I would like to know how warm the water is because it's looking so inviting; My question is this: Lets say I'm running Spy++ (or any other software that installs a hook/uses injection). I know it's not an "instant ban" because I've done it a few times. And since global hooking is (more common that it should be) my point being that it is not "rare" at all. How does warden react to it, if at all? Another way to phrase the question would be, does warden care or react at all if you use SetWindowsHookEx to hook into wow's WndProc? I'm assuming this is what Spy++ does (it's certainly the easiest/quickest to code way).

As for World to Screen (yeah, like I'll get that far anytime soon). One thing that had crossed my mind (not really for world to screen) but more for accepting and turning in quests and other dialogs is; (I am assuming it's possible to get a screenshot when the window is minimized?) I have TON of image processing software I've written in assembly to defeat captcha's (obfuscated graphics). Obviously graphics that are not obfuscated should be a peice of cake. I should have no problems figuring out where to click for dialogs / and determining which dialogs are showing if indeed I can take a screen shot. In that scenerio detecting the mouse cursor when over a mailbox, flightmaster, fishing bobber is a peice of cake. But of course that requires a mouse (which has me chasing my tail right now). I would like to stay out of process but...

Can someone familiar with working in process tell me what the dynamics are for the safest intrusion in to get the background mouse input functioning? It may be worth considering for now.

[amadmonk]

I am starstruck a few excellant coders actually responded. There are so many quotes I wanted to address I couldn't pick one. But I can confirm everything that has been said here is true.

It seems I can not have my cake and eat it too. I have to compromise on something. (stupid mouse architecture) It was designed the way it is for drag and drop operations.

Dotnet has a class called native window that I was hoping to utilize along with rawinput but that requires a hook anyway (injection). Of couse I tried everything else mentioned in the thread (which is why I can confirm it in first person). The best I could do was "share" the mouse under the conditions that the wow windows are not minimized (not background).

I can not express how much I hate writing device drivers. Another way to put that is I can not express how much I hate rebooting every 5 minutes. But it's a real possibilty at some point. For the immediate time being I'm sticking with the keyboard while I work on the rest of my packet sniffing routines.

This is sort of what you're stuck with if you don't want to inject and you want more than a minimal level of interactivity for background windows. It's sad, but it's just the way Windows works.

I too hate writing device drivers, especially since on x64 it's damned near impossible to consistently load your custom driver without running your entire windows in a debug mode that is flaky and just tanks performance.

Movement is not going to be a problem (totally out of process) I can confirm that (it's just a matter of time for me to write the code). But without the mouse things like clicking on a mailbox or bobber are things I have no idea on how to do without mouse input. Is there a way to do these types of things with just a keyboard? I haven't looked into any wow api's since most of the really helpful functions are protected now, so much to do and so little time...

In a word, no. The reason it's so challenging is specifically to defeat exactly what you're trying to do Without injection or some kind of modification, you can't call protected functions from a tainted Lua path, period. That means that all of the various Interact() functions that you'd like to use are off limits.

The *only* way to make it work without injection is going to be to get mouse input working. Have fun with that... it's possible, but the amount of work required is tremendous, especially when you consider that you're really gaining nothing over an injected bot (and losing quite a bit).

I have also not had time to look into warden at all, since my plans are to stay completely out of process. But I would like to know how warm the water is because it's looking so inviting; My question is this: Lets say I'm running Spy++ (or any other software that installs a hook/uses injection). I know it's not an "instant ban" because I've done it a few times. And since global hooking is (more common that it should be) my point being that it is not "rare" at all. How does warden react to it, if at all? Another way to phrase the question would be, does warden care or react at all if you use SetWindowsHookEx to hook into wow's WndProc? I'm assuming this is what Spy++ does (it's certainly the easiest/quickest to code way).

I can pretty much assure you that unless you (a) use someone else's lib (which would match a known checksum) or (b) touch one of a small handful of protected locations (and sadly for you, I believe SetCursorPos is pretty well defended... check w/the Warden guys to confirm), you're fairly safe.

Of course, at this point, you're injected, so why not just bite the bullet...

As for World to Screen (yeah, like I'll get that far anytime soon). One thing that had crossed my mind (not really for world to screen) but more for accepting and turning in quests and other dialogs is; (I am assuming it's possible to get a screenshot when the window is minimized?) I have TON of image processing software I've written in assembly to defeat captcha's (obfuscated graphics). Obviously graphics that are not obfuscated should be a peice of cake. I should have no problems figuring out where to click for dialogs / and determining which dialogs are showing if indeed I can take a screen shot. In that scenerio detecting the mouse cursor when over a mailbox, flightmaster, fishing bobber is a peice of cake. But of course that requires a mouse (which has me chasing my tail right now). I would like to stay out of process but...

I built a pixelbot a while back (as my first real out-of-process bot), and there are a LOT of complicated things to consider -- UI scaling, rotatins/translations, screen pos, clipping... The number of things that can go wrong with OCR-type code is far, far larger than the things that can go right.

Can someone familiar with working in process tell me what the dynamics are for the safest intrusion in to get the background mouse input functioning? It may be worth considering for now.

I run my own in-process bot, and I have been exactly where you are now. I will tell you flat out: it's not worth it. Unless you're willing to inject, movement and interaction is insanely tricky, and very fragile. You have to do all kinds of ugly things like set the camera to zero distance at all times, etc. Quite often methods break if there's a LoS issue or your camera is wrong.

I hate to be the bearer of bad news, but if you search on here, you'll find that all of the successful bots are either permanently resident in-process, or dynamically create threads to call various engine functions via stuff like BlackMagic and so on (which is essentially the same from a safety perspective, and much more fragile from an architectural perspective, IMO).

Bottom line again, and I know I'm probably raining on your parade here, it's just not worth the work for no real benefit.

[joe7314]

Bottom line again, and I know I'm probably raining on your parade here, it's just not worth the work for no real benefit.

I'm not a stranger to wasting my time Chalk it up to personal growth or having a Hobby (anything a psychologist would think is healthy so they don't lock me away).

This is sort of what you're stuck with if you don't want to inject and you want more than a minimal level of interactivity for background windows. It's sad, but it's just the way Windows works.

Yes indeed. However, RoKFenris has a good idea. I will look into running each WoW on it's own desktop. Windows only "flags" one desktop at a time for userinput (the "InputDesktop") it's kind of like the concept of air force one, there are a several desktops on the system, just like there are several planes in the world but whichever plane the president is on switches to that call sign, whichever desktop is capable/has user input enabled is the InputDesktop. Unfortunately even though the process is running on a "NonInputDesktop" it can not use SetCursorPos until it is "switched" to be the InputDesktop, which means switching everytime you need to set the cursor position. Regardless, I am going to give it a try, but I have a sinking feeling there will be too much overhead switching desktops; however there might be some solutions to make it feasible (at least it's not outright impossible, like my original criterea). But take this paragraph with a grain of salt, I have never messed with switching desktops programmatically via the api so I'll just have to try it and let ppl know what I find out.

[amadmonk]

That's a pretty interesting idea (separate desktops). I still think you're wasting your time, from a pragmatic point of view.

However, from the point of view of wanting to overcome a technical challenge, I perfectly understand. Most of the guys on the elite forum think my taking a perfectly (high) functioning totally in-process bot and spreading its logic out over several processes is madness. I say -- maybe, but where's the fun in always doing the easy thing? So... I get the urge to fight the beast on your own, and I salute you!

[joe7314]

However, from the point of view of wanting to overcome a technical challenge, I perfectly understand.

Yes, as Cypher pointed out there are virtual no out of process bots (just ppl mislabeling them).

I did write some software to switch desktops, open wow, switch back. But I didn't get any further than that. For now I'm just going to take a break from the issue and work on the radar/object manager. I'll keep everyone posted when I dive back into it. Thanks for all the great feedback

[L33ch]

Hey all,

not sure if it's worth a damn cent but i can always try....

I also had mouse problems, or focus problems or... etc...
It was at that time I realized my goal, making a healbot for myself...
I wanted to leave options open so I thought about how I could have several WoW's running AND have keyboard & mouse functions

long story short.... I bought another big pc, installed ESXI, dumped 4 images of WinXP on it.

Virtual pc's made it easy for me, to have full control of all my bots i made it client-server~ish so i can send actions from my pc (or work).

There are some mouse issues in VMware, but nothing you can't get around.

Also I got adviced to use virtualbox and to run WoW in opengl mode (-opengl at the end of the startup command) haven't looked at it yet though...

here are some general tips, I didn't follow them as I already had experience with VMware and WoW.... *cough* but it might come in handy
http://www.mmowned.com/forums/bots-p...l-machine.html

I hope this helps

[Multitask]

sorry for necro, but download link appears to be broken. any chance someone has this and can reupload?

or has the infamous notepad keyboard hook example i have herd so much about on forums but have yet to find

decided to post here because i felt it was better than creating a thread.