Best input method?

[amadmonk]

So I've got a basic question I want to pose to y'all. What is the best method for submitting input to WoW? I want to do things like set targets, cast spells, and move.

The options I see are as follows:

• Simulated input

This is injecting keystrokes and/or mouse input; it's the method my bot is using right now. The upside of this method is that it's the most "life like" of all the methods (short of actually playing the game ). It looks to the client like the user is actually playing the game. So my suspicion is that for non-public bots, it's the least likely to get you banned.

The downside is that it's not super reliable. All sorts of timing issues can screw up keystroke injection. Additionally, it creates one more layer of verification -- I have to make sure that my injection of CTRL-ALT-F3 (or whatever) really did trigger "Greater Heal" (or whatever). In other words, there's no direct connection between your simulated input and the desired behavior. There's only an implied connection, assuming your bindings are right, assuming the input buffer accepted your input, etc.

• Packet injection

This is the method I'm currently contemplating. It also seems low on the detectability scale (with one big caveat; since I'd essentially have to man-in-the-middle all traffic, would the Warden traffic get screwed up?). Also, there's no need to verify that client action caused the correct messages to be sent to the server, since you initiate those messages directly.

The downside is mostly synchronization. Since the client cooperates with the server in a number of different ways (movement, and IIRC an initial check for things like ranges, mana, etc.), it's quite possible to send packets that cause your client to get out-of-sync with the server. With this method you start to run into the complexities of a clientless bot (which is more involved than I want to go).

• LUA injection

This seems to be the route that most of the folks on the forum are using. One benefit of calling dostring is that, in theory, I'd have all of the power of LUA at my disposal (meaning I could do more than just cast spells, etc.).

The downside of LUA calls, to me, are detectability (you're running code in-process again), the need to maintain more offsets (right now I only need to keep track of the SRP key and the CTM offsets), and the need to do lots and lots of injections (or do resident code with an EndScene hook).

So, these are my thoughts on the pros/cons of the various ways of "getting input into WoW." I'd like to hear y'all's opinion, because I'm becoming less and less enamored of my current method (simulated keystrokes).

[LegacyAX]

couldnt you hijack wow's user32.dll and call the sendMessageA function internally?

Just an idea, I call it out of process to send Ctrl+v commands and {ENTER} to send lua commands.. but Just thought of the in process idea.. If anything I want to use Lua_Dostring...
just working on the main thread stuff, since when I use my own thread (I know I know cypher lol CreateRemoteThread is for cheap asses haha) I cant call protected API (duh)

good luck, id like to hear what the gurus have to say.

[amadmonk]

Well if I go the inject LUA route, I'll probably just do it "right" with an EndScene hook and some IPC.

And sending input to WoW is pretty trivial with PostMessage. I guess I could shim user32 inside the process, but why? You'd have all of the limitations of message passing, plus all the limitations of being in-process.

My current leaning is towards sending the packets, as long as I'm not going to trip up Warden that way. But I'm also waffling wrt LUA. I haven't really followed the discussion on calling LUA from my code, and I'm trying to figure out if I'd have to recode everything in C++ just to make it work (don't wanna, don't wanna, don't wanna -- hate C++ after too many years working w/it).

[BoogieManTM]

So I've got a basic question I want to pose to y'all. What is the best method for submitting input to WoW? I want to do things like set targets, cast spells, and move.

The options I see are as follows:

• Packet injection

This is the method I'm currently contemplating. It also seems low on the detectability scale (with one big caveat; since I'd essentially have to man-in-the-middle all traffic, would the Warden traffic get screwed up?). Also, there's no need to verify that client action caused the correct messages to be sent to the server, since you initiate those messages directly.

The downside is mostly synchronization. Since the client cooperates with the server in a number of different ways (movement, and IIRC an initial check for things like ranges, mana, etc.), it's quite possible to send packets that cause your client to get out-of-sync with the server. With this method you start to run into the complexities of a clientless bot (which is more involved than I want to go).

In order to do true man in the middle proxying (with 4 total encryption contexts, send/recv client<->proxy, send/recv proxy<->server), you'd have to implement warden crypto. This isn't a fun task, as the key is scrambled every time a new module is loaded (usually only once per session). I'd avoid this route.

You can however still semi-man-in-the-middle, but you would have to alter the client's RC4 context for outbound packets in order to keep the encryption in sync every time you send a packet. Not exactly the most passive method, but the chances of getting detected are incredibly slim (if you're just altering the context, and not hooking/etc). the incoming (Server->Client) context in theory could be left alone, unless you wanted to forge server responses as well.

Other than that, the only packets you'd have to worry about as far as conflictions go, are movement packets. But if you are the only one sending movement packets, and the client isn't doing any of them (it wouldn't if you're not sending it any input, afaik), you should be fine. Though I'm not sure how stuff like interactions would work.

For example, I don't know how the client would handle it if you sent a CMSG_LOOT_OBJECT -> ObjGUID packet, got a response with the loot list.. if the client would just ignore it as it did not request the loot? Worth a shot though, I'm willing to bet it'd work :P

[amadmonk]

In order to do true man in the middle proxying (with 4 total encryption contexts, send/recv client<->proxy, send/recv proxy<->server), you'd have to implement warden crypto. This isn't a fun task, as the key is scrambled every time a new module is loaded (usually only once per session). I'd avoid this route.

Yeah, this is what I remember from our last discussion of clientless bots. I really don't want to try to attack Warden (for a lot of reasons, the biggest of which is that I'm lazy).

You can however still semi-man-in-the-middle, but you would have to alter the client's RC4 context for outbound packets in order to keep the encryption in sync every time you send a packet. Not exactly the most passive method, but the chances of getting detected are incredibly slim (if you're just altering the context, and not hooking/etc). the incoming (Server->Client) context in theory could be left alone, unless you wanted to forge server responses as well.

So, um, I have the feeling this is a stupid question, but how would you do a pseudo MITM without a proxy socket? Raw sockets to forge the headers?

Other than that, the only packets you'd have to worry about as far as conflictions go, are movement packets. But if you are the only one sending movement packets, and the client isn't doing any of them (it wouldn't if you're not sending it any input, afaik), you should be fine. Though I'm not sure how stuff like interactions would work.

For example, I don't know how the client would handle it if you sent a CMSG_LOOT_OBJECT -> ObjGUID packet, got a response with the loot list.. if the client would just ignore it as it did not request the loot? Worth a shot though, I'm willing to bet it'd work :P

Yeah, this was sort of my thought too; if you initiate actions via sends that the client knows nothing about, what will happen?

It's intellectually interesting, but -- as I mentioned -- I'm lazy. I'm starting to lean very much towards the LUA injection method for input (guess I still need to do CTM to move, though, unless there's a LUA callback for MoveToXYZ ) There's lots of prior art on here and it's not too complex. If I understand correctly, I register an EndScene hook, set up a couple of buffers for input strings and output results, disable the protection check (or maybe just dig out a 5 byte jmp cave in .text?), register a results callback, and start doing LUA.

Piece of cake...

Too bad keystroke injection is such a flaky POS method for sending input, because I get all of the data I need from packet reads atm (and I spent a buttload of work to get that working, including all the timing/spline crap now) so I was really close to being a completely mem-write-free bot.

[BoogieManTM]

Yeah, this is what I remember from our last discussion of clientless bots. I really don't want to try to attack Warden (for a lot of reasons, the biggest of which is that I'm lazy).



So, um, I have the feeling this is a stupid question, but how would you do a pseudo MITM without a proxy socket? Raw sockets to forge the headers?

You'd still be proxying the connection, but not at the wow protocol level. you'd just be passing it through as is (possibly passively decrypting it for your own informational purposes) and then injecting your sent packets

Yeah, this was sort of my thought too; if you initiate actions via sends that the client knows nothing about, what will happen?

It's intellectually interesting, but -- as I mentioned -- I'm lazy. I'm starting to lean very much towards the LUA injection method for input (guess I still need to do CTM to move, though, unless there's a LUA callback for MoveToXYZ ) There's lots of prior art on here and it's not too complex. If I understand correctly, I register an EndScene hook, set up a couple of buffers for input strings and output results, disable the protection check (or maybe just dig out a 5 byte jmp cave in .text?), register a results callback, and start doing LUA.

Piece of cake...

Too bad keystroke injection is such a flaky POS method for sending input, because I get all of the data I need from packet reads atm (and I spent a buttload of work to get that working, including all the timing/spline crap now) so I was really close to being a completely mem-write-free bot.

Yeah not sure how that'd really work out. you would probably need to update your location on the client side(which you could easily do with a forged SMSG packet), too, if you did move around. Movement packets are a bitch, too.. very picky.

[amadmonk]

You'd still be proxying the connection, but not at the wow protocol level. you'd just be passing it through as is (possibly passively decrypting it for your own informational purposes) and then injecting your sent packets

Oh, I see, just send the packets as-is without doing the header encrypt/decrypt. I guess that would work, but there would be buttloads of potential race conditions (what happens if WoW wanted to send a packet just as I was sending one?). Since I am not assuming complete control of the pipe, I can't guarantee this won't happen (and in fact it would be most likely to happen at the worst time, possibly corrupting the RC4 buffer in the middle of a fight, or something).

Yeah not sure how that'd really work out. you would probably need to update your location on the client side(which you could easily do with a forged SMSG packet), too, if you did move around. Movement packets are a bitch, too.. very picky.

Yeah. And I don't know 100% of the packet structure for the move packets yet -- I know basic field lengths, but there are still a lot of fields I just skip and ignore. If I wanted to start forging my own movement packets, I'd have to dig much, much deeper into the packet structure and really understand it. Again, an interesting mental challenge, but I'm lazy... CTM works, for now...

[Cypher]

CGInputControl_C and ClickToMove imo.

[ramey]

ClickToMove should be fine unless you want finer control, like backpedaling, strafe, etc.

[Cypher]

ClickToMove should be fine unless you want finer control, like backpedaling, strafe, etc.

You also need CGInputControl_C if you want to do mouse turning.

[amadmonk]

For the most part "move to location XYZ" and "face mob guid XXXXX" should be enough.

I'd like to get my multibots up to where they can farm heroics (they're mmm 74 now, so a few more days or a week or so), and unfortunately heroic boss fights almost always require some positional niceness (although usually no more complicated than "stay out of the fire").

[abuckau907]

edited, will move to own post. Filler, sorry.

[ramey]

You also need CGInputControl_C if you want to do mouse turning.

Ah yeah, I remember experimenting a little bit with those flags, and just went and found CTM because I got annoyed by them :x

[jjaa]

Ah yeah, I remember experimenting a little bit with those flags, and just went and found CTM because I got annoyed by them :x

Mouse turning is a great way to do facing, its accurate and fast. It’s also what ISXWoW used. Basically what you do is start a right click with CInputControl and then use the functions
CGCamera__UpdateFreeLookFacing = 0x00697990, //3.1.3
CGCamera__SyncFreeLookFacing = 0x00697CB0, //3.1.3
To update your camera position. However if you still wish to use your mouse you will need to do some hooking. Look at ISXWoW for a reference. Also thank you Greyman for helping me get mine working

[ramey]

Mouse turning is a great way to do facing, its accurate and fast. It’s also what ISXWoW used. Basically what you do is start a right click with CInputControl and then use the functions
CGCamera__UpdateFreeLookFacing = 0x00697990, //3.1.3
CGCamera__SyncFreeLookFacing = 0x00697CB0, //3.1.3
To update your camera position. However if you still wish to use your mouse you will need to do some hooking. Look at ISXWoW for a reference. Also thank you Greyman for helping me get mine working

That is a pretty good way to do it. Will probably end up using that if I do get a need to set facing, thankiess