Stuck with packet structure reversing

[ZealX]

Greetings, I've been trying to figure out how to get to the opcode packet structures, but there are several issues I could use help with. I searched these forums for anything related to "opcodes", "IDA" and similar, which might be useful, but I am still without answers. My hopes are that you guys can at least point me in the right direction.

So I've been using arctium sniffer to get some data from retail. Let's take the following one as an example:

opcode:  0x0097 (SMSG)
offset:  0x006B3865
raw data:  09 00 00 00 A8 C4 85 3F

1) The first thing that confuses me is how the hack was the offset calculated based on the opcode (0x0097 -> 0x006B3865), since I cannot find a pattern when looking at the other opcodes ? I got the mentioned value from arctium parser, and I dont belive they are wrong, since they got some really essential opcodes right (movement, login etc.). It's certainly not opcode + 400000 like instructed in other topics here.

Moving on, I opened wow.exe in IDA and searched for the function "6B3865" and got to the following

; Attributes: bp-based frame

sub_6B3865 proc near

var_4= dword ptr -4
arg_0= dword ptr  8

push    ebp
mov     ebp, esp
push    ecx
and     [ebp+var_4], 0
push    esi
lea     eax, [ebp+var_4]
mov     esi, ecx
mov     ecx, [ebp+arg_0]
push    eax
call    sub_40F2A5
mov     eax, [ebp+var_4]
xorps   xmm0, xmm0
mov     ecx, [ebp+arg_0]
mov     [esi+10h], eax
lea     eax, [ebp+var_4]
push    eax
movss   [ebp+var_4], xmm0
call    sub_40F30E
movss   xmm0, [ebp+var_4]
movss   dword ptr [esi+14h], xmm0
pop     esi
leave
retn    8
sub_6B3865 endp

Or when looking at C pseudocode

int __thiscall sub_6B3865(void *this, int a2, int a3)
{
  int result; // eax@1
  int v5; // [sp+4h] [bp-4h]@1

  v5 = 0;
  _ESI = this;
  sub_40F2A5(&v5);
  __asm { xorps   xmm0, xmm0 }
  *((_DWORD *)_ESI + 4) = v5;
  __asm { movss   [ebp+var_4], xmm0 }
  result = sub_40F30E(&v5);
  __asm
  {
    movss   xmm0, [ebp+var_4]
    movss   dword ptr [esi+14h], xmm0
  }
  return result;
}

2) Assuming this is the handler function, could anyone please give a basic walkthrough on where exactly is the packet data processed there ? I Have no idea what to think. Do the function arguments int a2, and int a3 indicate that the packet structure are 2x int32s (would match the data length = 8 bytes).

Thanks in advance for any help!

[namreeb]

The 'usual' way for finding the location of a handler function for a particular opcode is to hook the function which registers that handler. Here is an example that I posted a while back for the 1.12.1 client: http://www.ownedcore.com/forums/worl...ml#post2191709 ([WoW] 1.12.1.5875 Info Dump Thread)

Edit: Oh, and the 'usual' way for determining the structure of a packet is to see how the the packet is read, and what is done with those values. The first step in doing this is to identify the CPacket::Read32, ::Read16, etc. functions, and label them within IDA to make the psuedo-code Hex-Rays gives you more readable.

[ZealX]

I'll see if it proves to make sense when disassembling the 1.12.1 client, and that I can ask for further pointers :P
Thanks a lot for the response btw!

[mansemino]

Hi, ZealX

Atm, the smsg opcodes are "grouped" in several "groups" according to their kind; Some of them get their handlers at runtime and others can be accessed by getting their "group" handler. For the last ones, the method is something like this:

a.1- Get opcode
a.2- Do some operation to get their "group" or type (by shifting, masking, etc.)
a.3- According to their type, call the main handler for the group (movement, spell, quest...)
a.4- If the opcode doesn't have a "type", look for its handler in memory at runtime (doing some other calculations)

The main handler for each "group" of opcodes does something similar to the above, to get the constructor, handler and destructor for each opcode:

b.1- Do some operations with the opcode value to determine which opcode is, in the group (again, by shifting, masking, etc.)
b.2- In some cases, this will lead to a value for a "switch" clause; In some other cases, the value is checked with nested "if" clauses
b.3- Once it gets the final value, it calls the constructor/call handler/destructor for the opcode.

If you want to dig a bit in this with IDA and 5.4.1.17538 client (x86), I can suggest you to look at 0x78D225 (not rebased): This is what I tried to explain from a.1 to a.4
Also, you can look to 0x65261C (not rebased): This is what I explain from b.1 to b.3


A very diferent subject is how each packet is made; The data for each packet is created by "bitpacking" some fields of its struct and by scrambling the struct fields for each packet... In example, the packet for the opcode with value 0x97 has 2 fields: An Int32 (first) and a Float (second) (the smsg is TimeAdjustment, so I guess the first value is the base and the second is the multiplier).

As namreeb suggested, a good idea is to identify the functions to read/write Int32/Float/Byte/bit values, to get a more clear view of what each packet handler does...

Hope it helps ^^

[ZealX]

Thanks to tom_rus and his idb for 5.0.5, I managed to find the CDataStore__Get* functions and identify them for 5.4.1 - also had success for finding out the structure of some "easy" packets by looking at the already known handlers and following the calls of mentioned functions.
I pretty much have access to all handlers thanks to the arctiumSnifferBrowser you added on git, mansemino - conveniently calculates the offsets. I am curious tho how it calculates them, so far it seems to have calculated offsets for every opcode I wanted. There must be some easier generic way ?

Also playing with the instructions in your comment above, thanks a lot for taking the time and trying to explain!

[ZealX]

Ok so, I found the NetClientDispatcher function for 541 by studying the 505 idb tom_rus provided. This was missing, I didnt know how offsets are calculated, after seeing that all goes through the mentioned function and based on the calculations a handler is assigned, it finally makes sense! Thanks for the pointers mansemino and namreeb, big times!

Is there an "easy" way to update older IDBs to the never versions of the wow binary ? I cant imagine tom_rus does it by hand every time ... The list of functions doesnt seem to have an ending on the scrollbar lol ...

[ZenLulz]

Hi, ZealX,

You are right, there are different tools (called binary diffing) available to update a IDB file to a newer version of its binary. People around here like using the Pathdiff2 tool, an open source project you can find on Google code. If you are using an old version of IDA Pro (4.9 or 5.X), there is Turbodiff, a free tool from Corelabs. Finally, there is BinDiff from Zynamics, a very powerful diffing tool but not free.

You can find a modified version of Pathdiff2 on OwnedCore that renames all the functions in your new IDB from an older version.

Happy Reversing !
Cheers,
ZenLulz

[hardcpp]

Sub at 0x78D225

char __thiscall NetClient::ProcessMessage(int this, int a2, CDataStore_BitPack *p_Packet, int a4)
{
  int v5; // ebx@1
  char result; // al@2
  unsigned int v8; // eax@11
  int l_ArrOffset; // ecx@12
  unsigned int l_Opcode; // [sp+Ch] [bp-4h]@1 MAPDST

  ++sProcessedMessage;
  CDataStore::GetInt32(p_Packet, &l_Opcode);
  v5 = l_Opcode & 0x244;
  if ( (l_Opcode & 0x244) == 4 )
  {
    result = JAM::ClientDispatch(this, 0, a2, l_Opcode, p_Packet);
  }
  else if ( (l_Opcode & 0x276) == 0x50 )
  {
    result = Jam::ClientGuild(this, 0, a2, l_Opcode, p_Packet);
  }
  else if ( (l_Opcode & 0x1240) == 0x200 )
  {
    result = JAM::ClientMove(this, 0, a2, l_Opcode, p_Packet);
  }
  else if ( (l_Opcode & 0x1244) == 0x244 )
  {
    result = JAM::ClientQuest(this, 0, a2, l_Opcode, p_Packet);
  }
  else if ( (l_Opcode & 0x252) == 0x40 )
  {
    result = JAM::ClientSpell(this, 0, a2, l_Opcode, p_Packet);
  }
  else                                          // Old School Legacy Opcodes
  {
    (*(*this + 68))(this, l_Opcode);
    v8 = l_Opcode & 3 | ((l_Opcode & 0x38 | ((l_Opcode & 0x180 | (l_Opcode >> 1) & 0x7E00) >> 1)) >> 1);
    if ( v5 || (l_ArrOffset = *(this + 4 * v8 + 0x550)) == 0 )
      result = (p_Packet->DataStore[1].VTable)();// First CDataStore::NullSub
    else
      result = ((l_ArrOffset - ((l_Opcode | (l_Opcode << 16)) ^ 0x62A3A31D)))(
                 *(this + 4 * v8 + 0x2550),
                 l_Opcode,
                 a2,
                 p_Packet);
  }
  return result;
}

Your packet structure is

int __thiscall sub_6B3865(struct_v3_1 *this, CDataStore_BitPack *p_Packet, int a3)
{
  int result; // eax@1
  int l_ReadBuffer; // [sp+4h] [bp-4h]@1

  l_ReadBuffer = 0;
  CDataStore::GetInt32(p_Packet, &l_ReadBuffer);
  this->UnkDword = l_ReadBuffer;
  l_ReadBuffer = 0;
  result = CDataStore::GetFloat(p_Packet, &l_ReadBuffer);
  this->UnkSingle = l_ReadBuffer;
  return result;
}

0x0097 = SMSG_TIME_ADJUSTMENT ?

in your raw dump the value the float is 1.045064 and 9 for the uint32