Issues sending movement packets

[namreeb]

I've been experimenting with moving my toon with packets. While some people seem to do this by hooking and modifying legitimate packets as they are sent, I have been trying for a slightly less kludged approach. I am building my own packets and sending them. This "works" in the sense that the packets are well-formed, and a second toon watching can see the movement.

My issue is this: sending the packets alone is not enough. The client must also be made aware of the new position somehow or nothing will happen on the screen. Moreover, the client still thinks it is located in the old position, so the next time it sends a movement packet, we will be disconnected for sending a position so far away from what the server has for us (assuming we've moved more than a few steps away).

Now, I've been trying to figure out a way to deal with this problem. So far the most successful approach has been to simultaneously update the static locations for our x, y and z values:

		DWORD p1;

		p1 = *(DWORD *)(0x010BD5F4);
		p1 = *(DWORD *)(p1 + 0x34);
		p1 = *(DWORD *)(p1 + 0x24);

		x = (float *)(p1 + 0x798);
		y = x + sizeof(float);
		z = y + sizeof(float);

		// *x = ..., *y = ..., *z = ...

This renders the change on the screen, which means movement packets sent out after the code has finished its move do not cause an automatic disconnect. However, this method is now causing WoW to crash. The crash is located in the function at 0x007AC100, which seems to be a member function of some class having to do with the encryption key for the connection. I have no idea what it does, and see nothing in my code that should be having any affect on it what-so-ever (other than whatever affect any other packet would have).

Is this what other people do, and I just have to bite the bullet and solve this crash, or is there another method to leave my automated movement in the right place?

An interesting piece of information I noticed about this crash. My code accomplishes the movement by sending a MSG_MOVE_START_FORWARD packet, followed by a MSG_MOVE_HEARTBEAT packet twice a second for some amount of time (say 20 seconds for this example). Now, the crash ALWAYS happens after half (yes -- exactly half, I think) of the total expected amount of MSG_MOVE_HEARTBEAT packets get sent out. This is extremely odd. I do not even at the moment use a variable to store this time delta value. It is a magic number inserted in the code in one position (prior to generating the MSG_MOVE_START_FORWARD packet). The code is there to send a MSG_MOVE_STOP packet, but it never gets that far.

Thanks!

[ashleyww]

I dont know how to fix this... but i would like to know, how are you making the packets.

[lanman92]

UnKnowned made a post on teleporting if that's what you're looking to do. It was a while back, and I think it may have used Area triggers instead of movement packets, but it's still great. I'm still trying to figure out how to do this as well. I thought about sending a massive amount of packets containing nudges and msgmovestop/start to get to somewhere, but this is kind of ugly. As for just doing this, why not overwrite your movement state?

[namreeb]

I'm not trying to teleport yet. I'm trying to just make the toon walk at this point. Gotta crawl before you can walk! And as for the timing, I am currently sending out 1 heartbeat every 500ms or so for 20 seconds. I measured WoW's pace for this at about the same.

[ramey]

Why not just use CTM unless you're trying for a clientless bot?

[namreeb]

Did you not read what I said? I'm just playing around with it. I hope to do other things later once I gain some understanding of what's going on.

[kynox]

The nudge spam idea won't work, the server has a certain tolerance for packet spam before it drops you.

In regards to your crash, i imagine it's stack corruption or something.

[namreeb]

So I noticed. I partly identified my problem. Assertions were disabled for the datastore code, which relies on their statements being evaluated (yes, even when its not compiled in debug mode).

[kynox]

Ah, yes. Part of the reason i have come to despise that class.

[ramey]

I did read it, but I took it as you were planning to use it instead of pointlessly struggling to get something to work and posting it on a forum, acting like it matters more than it does! But hey, good luck, sorry for trying to let you know of an easier way if you already didn't know..

[namreeb]

If you took it that way you obviously didn't understand. I'm doing this for neither of your two reasons. In fact, I'm doing it with purpose *gasp*. I'm trying to understand the packet structure (and the code to generate it) with some relatively simple commands that have readily observable results.

I'm sure when you do something like this you can just skip right to a full-blown production implementation. I shall try to be more like you in the future (but less condescending).

Anyways, apology accepted. I would glady live without your input if it means I don't have to suffer your arrogance. gtfo. </squable>

[amadmonk]

So, this is an interesting task you've given yourself. I've been in a similar hell lately (attempting to re-decode the SMSG_UPDATE_OBJECT and other packet changes since 3.13; I'm reversing the packet receive functions atm).

When I started using packet sniffing for my bot, I was under the (sadly mistaken) assumption that packet structure was unlikely to change significantly from point release to point release, whereas memory layout might. Wow, was I wrong. About 1/3 of the packets have had structural changes since 3.12, ranging from adding a byte field to changing packed guids into unpacked guids to a completely different structure for spline movement updates. I'm starting to wonder if the WoW devs are juggling crap just to mess with us... (why else would you change a packed guid to an unpacked guid in a particular opcode, and nothing else??)

I'm starting to think that packet sniffing is not such a low-labor method for controlling a bot after all.

Given, all of the info about the packet layout is present in the binary, but my whole goal here was to not have to spend 10 hours in IDA trying to divine the intent of an opcode parser after every 2-3 week point-release patch. If I'm going to have to do that anyway, I might as well skip the overhead of packet sniffing.

So... good luck with this.

[namreeb]

Solved! You were right, Kynox. From my snippet above, my x, y, z were all float *. Instead of y = x + sizeof(float) I should have done y = x + 1. *innocent whistle*

[namreeb]

Sorry for the double post, but I thought I'd let those interested know that now that I've resolved my stack corruption issue, my teleporter now functions.

[YT]<object width="445" height="364"><param name="movie" value="http://www.youtube.com/v/M2A2f__mF5E&hl=en&fs=1&rel=0&color1=0x006699&color2=0x54abd6&border=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/M2A2f__mF5E&hl=en&fs=1&rel=0&color1=0x006699&color2=0x54abd6&border=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="445" height="364"></embed></object>[/YT]

[lanman92]

I don't really see the point =/ You plan on just using a speedhack once you're way up there?