Issues sending movement packets

[BoogieManTM]

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.

definitely not low labor, but it can go by smooth sometimes. I don't remember the last time i had to update the authentication sequence, for example. Many things do break, however, when parsing packets across multiple version. object_update is _Definitely_ the biggest pain in the ass packet of them all. Most packets (at least ones i actually use) don't change much at all.

[namreeb]

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

Yup. Shoot up into the sky -> fly super fast to above destination, port down to target z.

[lanman92]

How are you doing your speedhack? I was thinking about trying to just hook the CHANGE_SPEED packet and prevent sending it. Give that a go and if not, resort to hooking warden... So you can use the good 'ol standard.

EDIT: Scratch that, doesn't work.

[namreeb]

Look at how WoWX does it.

[lanman92]

Doesn't it just hook QPC and GetTickCount?

That's detected now, bro. I don't recommend doing so.

[namreeb]

Is it? Hmm.

[lanman92]

Since WoWX hooks warden it doesn't matter though. I don't think. It just unpatches while warden scans, then reapplies. You probably don't even notice the pause

[namreeb]

Can someone who knows more about Warden confirm/deny this?

[lanman92]

I was talking to Cypher a day or so ago. He said just hook it. WoWX does it for you.

[namreeb]

I can see that WoWX removes all patches/hooked functions, runs the scan(s), then re-applies them. The only question is have other checks/functions been added since WoWX was created?

[Cypher]

Errr. I don't remember talking to you or saying that but okay...

Anyway, unhooking the timing apis (GTC, QPC, etc) while Warden is scanning won't protect you from the speedhack scan.

[namreeb]

Is it a server side check, or some other warden module?

[kynox]

Both server and warden.

[namreeb]

I see. By that do you mean a dynamic module sent by warden? I was surprised to see how this code works as it would be fairly trivial to implement some basic sanity checking that is entirely server-side. If this is the case, I can't think of any way to implement a speed hack. Am I not thinking hard enough?

[kynox]

There are a number of ways, you just need to think outside the box.