Packet reversing findings

[namreeb]

Any help with what's wrong with this code? I don't think many other ppl can provide light on this. I keep getting a null pointer(0x0000 referencing 0x00000).

dbgout << packet.m_buffer << std::endl;

Should the packet be a pointer...?

Yes it should, assuming you're using CDataStore, which is basically just a pretty wrapper for a vector.

[lanman92]

yeahhhh, I decided just to go all-out on inline asm for this xD I just find it easier =/ not sure why, but C++ is just ugly to me. I think it's the ide...

[namreeb]

yuck......

[lanman92]

Haha, it's just preference Hard-coded offsets are ugly, but I like it better. It's just how my head works I guess.

[namreeb]

Do you have any insights on what the 'a2' argument to LoadMovePacket is? or 'a5' and 'a6' even?

[lanman92]

Tbh, I haven't looked at that function yet. My guess is it might be current location/rot/etc. Just a guess. Not sure. I'll look at it. I'm having issues reading the opcodes of each packet right now =/ movzx...sigh...

[namreeb]

I don't see how you can possibly be sending packets without answering these questions. Am I missing something?

[lanman92]

I'm not sending packets yet :P Why are you hovering around that function? The lua movement functions all use 'formpacket' and the offset that I'm using(0x5F92F0). Just look at [[arg0 + 0x4] + 0] and you can then check if the opcode is >= movement_opcodes_low and <= movement_opcodes_high. That's how I'm going to do it.

[lanman92]

Here's an example dump of an unencrypted jump packet going into the forementioned function :P

BB 00 00 00 00 10 00 00 00 00 E4 D3 9D 0C 9F 8C
E6 44 11 BD CB 44 17 DE C1 42 6E 1E A7 40 00 00
00 00 D8 93 FE C0 04 FB F9 3E C4 69 5F BF 00 00

Compared to the structure listed by MangOS(well, not a structure...but u get it...)
recv_data >> MovementFlags;
recv_data >> movementInfo.unk1;
recv_data >> movementInfo.time;
recv_data >> movementInfo.x;
recv_data >> movementInfo.y;
recv_data >> movementInfo.z;
recv_data >> movementInfo.o;

[namreeb]

I must be completely lost. What you're saying makes no sense to me.

[lanman92]

Look at the opcode of that dump, the first byte. Then the next 5 bytes is size, 0x10. Now, there's 4 bytes of unk. Still part of the header I believe though. Haven't really looked into it. Then there's the good stuff. The X, Y, Z, orientation, and movement flags. I may have dumped a bit much there.

EDIT: I just realized that the clients may be sending as big-endian data. I was unsure why the 0xBB is the first byte, when it should be in the second if it was little-endian.

[BoogieManTM]

EDIT: I just realized that the clients may be sending as big-endian data. I was unsure why the 0xBB is the first byte, when it should be in the second if it was little-endian.

network byte = big endian. the TCP/IP standard is to send all numeric values in network byte/big endian order.

[Apoc]

System.Net.IPAddress.HostToNetworkOrder() does some neat stuff. Though, you're better off just plain breaking it down to bytes, then reversing it.

public byte[] GetReverseOrder(int val)
{
byte[] ret = BitConverter.ToBytes(val);
Array.Reverse(ret);
return ret;
}

[amadmonk]

...BitConverter.ToBytes(val);...

Arg, arg, arg. Why do I always forget about the BitConverter class? Grr, I ended up rewriting 90% of its functionality...

[Apoc]

I oopsed with my post.

It's actually BitConverter.GetBytes not ToBytes.