[Question] Detouring and calling SendPacket C++

[amadmonk]

IIRC the movement packet (and most of the WoW packets, actually) use a binary-coded packed guid representation. It's not too hard to figure out.

Edit: oops, posted that without hitting refresh, so I didn't see what TOM_RUS posted... but yeah, what he said.

[Flushie]

That works so...

*((int*)(address+1)) = (DWORD)(&SendPacketJump) - address - 5;

Okay, I see what your doing, at first I was like No, then I was like Oh.

[Azzie2k8]

IIRC the movement packet (and most of the WoW packets, actually) use a binary-coded packed guid representation. It's not too hard to figure out.

Edit: oops, posted that without hitting refresh, so I didn't see what TOM_RUS posted... but yeah, what he said.

yeah well I read an article about how it is compressed but I dont see a reason why I should bother myself with this. I took a look at it and my player guid is compressed to 4 bytes so if I read the structure like

struct MovementPacket
{
	unsigned int opcode; // 4
	unsigned int guid; // 8
	unsigned int Flags1; // 12
	unsigned short Flags2; // 14
	unsigned int time; // 18
	float x; // 22
	float y; // 26
	float z; // 30
	float orientation; // 34
	float optional; // 38
};

I only have a size of 38 as packet but the Datastore m_size value is 41...Thats mainly what I dont get...

This is the bytewise look of a heartbeat packet I received while running in a straight line on ground without a mount.

Type: Heartbeat
m_size: 41

1 7c
2 17
3 0
4 0

5 cf
6 72
7 88
8 bc
9 2
10 80
11 5

12 1
13 0
14 0
15 0

16 0
17 80

18 c3
19 91
20 8
21 0

22 ef
23 ae
24 fe
25 44

26 90
27 6
28 b9
29 44

30 99
31 eb
32 8b
33 42

34 cf
35 45
36 ef
37 3f

38 0
39 0
40 0
41 0

If I look at it from button to top then 41 -38 should be the optional float whenever pitch is involed (this is zero since I was running on ground in a straight line). 37-34 should be orientation and 33 - 22 position. 21 - 18 should be time 17,16 Flags2, 15 - 12 Flags. 11-8 should be the guid now but that doesnt make sense, right ? the first 4 byte are actually the opcode so the only thing I can think of this is that the guid is actually from 11-5 meaning it would be 7 byte wide ?!

I think I have a serious mistake in there but I am just not sure what I didnt understand

[Azzie2k8]

Okay so after I took a closer look at this I think I found what my problem was: my own stupidity.

I am at my girlfriends place atm so I cannot check this but if what I read is true and I understood it correctly than I should have never tried to look at the packet as a structure like this but at each byte.

After doing the guid conversion manually I realized that there really are only 7 bytes representing the guid as you can see here

guid in hex: 580000002BC8872

packets in hex:
5 80 2 bc 88 72 cf

cf in bin: 11001111
-> 4 bytes not 0 2 bytes zero and 2 bytes not zero
   1  1   0  0  1  1  1  1
-> 05 80 00 00 02 bc 88 72

The cf being the mask telling me where exactly the 0x00 were.

so with this I should be able to convert the packet to readable data meaning that I now know that the first 4 bytes belong to hte opcode, the next 7 to the guid and so on.

So is it correct that I need to handle this packet byte by byte at least for the guid and then basicly go on with either 2 or 4 bytes steps interpreting those as flags, position and so on ?

If this is a stupid question I am sorry I will personally check this as soon as I am back at my pc

[LordJZ]

This is called 'packed guid'

[Azzie2k8]

This is called 'packed guid'

I know since so many actually told me that but for some reason I was stuck with the idea that the guid is compressed to a generl datatype like int and thought I could still read this as a struct but now i realized that i had been wrong all the time...