Opcodes Packets Reversing

WoW Opcodes, Packets and Reversing Introduction This guide is directed at people who know C/C++ and would like to work on finding or updating packet opcodes or structures but don’t know where to begin. This is a collection of advice and information rather than a step by step guide. Certain level of problem solving skill is required. Google and get Ida 5.5 with hex rays 1.1 It is your best friend in this task. Hex Rays decompiler plugin is very useful as it allows you to see content of most functions in understandable high level C syntax form. So even not knowing assembler you can do a lot. Get IDA database for 4.0.6 by TOM_RUS (and optionally 3.3.5). All the stuff needed to get started is already renamed there. Don’t forget to thank him. Place wow.exe (renamed to the same name as IDB file) to the same folder as the IDB. I recommend starting by doing a full exe decompile by pressing Ctrl+F5. It produces a huge file with source of all the functions that it could decompile. Then you can use it to quickly search for things. I use Total Commander for viewing as it is efficient for viewing and searching large text files. When looking for something in IDA - search Functions and Strings tabs (Alt+T). To see a function decompile you can press F5.

Opcodes Client and server communicate by means of sending binary packets of data. The header of each packet contains a 2 byte opcode number which specifies how the content has to be treated. Client and server have to follow the same protocol for packet formats in order to communicate successfully. Packets with wrong structure for the opcode lead to client freezes, error 132 crashes or other unspecified behavior. There are 3 types of packets: SMSG are server-> client CMSG are client -> server MSG are both ways. SMSG To find the structure that server has to use for a particular opcode, client code can be analyzed. For that we need to find a clientside handler function for the opcode.

Before 4.0 all the handlers were registered by a single function ClientServices__SetMessageHandler taking opcode number and handler function pointer. So 3.3.5 handlers can be easily found by searching the full decompile for ‘SetMessageHandler(12345,‘ with appropriate opcode number. As of 4.0.6 however the process is trickier and opcodes change on every client version update. There are 2 ways handlers are registered: 1) By assigning a handler pointer to an element of a huge array at a particular offset. Offset is derived from the opcode number by a mathematical transformation. We can convert back and forth between offsets and opcodes using OpcodeTools. So to find a client handler for a particular SMSG opcode you can convert it to an offset using tools and then search full decompile for ‘+ 8080’ (replaced by correct offset). Full 4.0.6 table of opcodes/handlers mapping dumped from handler is here. 2) Some opcodes are not in the main array and instead are first handled by a special function called NetClient__ProcessSpecialOpcodes which calls appropriate handler. It maps opcodes to small numbers (I call special numbers for no better term) that also can be converted back and forth by opcode tools. For each opcode it first calls a function to read the data where we can see the packet structure. Then it calls actual handler through a dword pointer to do the work required by the packet itself. You can find which function is assigned to it by following dword’s xref (shortcut X). Once you’ve found the handler you can discover the packet structure by looking at CDataStore__**** calls like CDataStore__GetInt32, CDataStore__GetInt64 etc. Once you have figured opcode number and its structure you may want to see how client reacts to getting this data. For that create a file called opcode.txt in the server bin directory and use “.debug opcode” command to send the test data to the client. CMSG For CMSG opcodes client sends the data that we need to properly decode and interpret in the server. To find a CMSG opcode for particular action you can enable server logging of all cmsgs received to console (in WorldSession::Update) and see the number it gets when you perform a clientside action. Client constructs the packet before it is sent through calls to functions like CDataStore__PutInt32, CDataStore__PutInt8 etc. The first call to CDataStore__PutInt32 places the opcode number at the beginning of the packet. So you can normally find where the client creates a CMSG by searching full decompile for e.g ‘31396);’ with correct decimal opcode value. When trying to figure out the meaning of data in each packet field you can do some digging in the decompile or get a packet dump from retail.

Debugging Sometimes looking at the decompile is not enough and you want to see what is going on at runtime. Luckily you can also debug in IDA. If you start WoW with debugger attached it crashes. So start it normally and then use Debugger -> ‘Attach to process’ once it is started. Debugging requires more knowledge of assembler but to make life easier you can press Tab to switch to decompile view and the cursor will be placed at the line that corresponds to current IP location. This way it’s easier to know where you are in overall function structure. Due to ASLR, every time you debug, IDA is going to do a rebase. To avoid waiting you can turn ASLR off in Wow.exe by using setdllcharacteristics tool.

General Reversing In many cases you’ll be left wondering wth is going on in the client code. Some things to try using as starting points:   

All LUA functions are renamed in IDA so you can try to connect them to packets sent. eEvents_FrameXML enum has many meaningfully named events that can be good ques. You can also download LUA source of WoW UI and see what is going on there, what events the component you are interested in subscribes to, what LUA functions it calls etc.

When you want to reverse a new version of Wow.exe you can hope for TOM_RUS to release a new IDB or you can try updating it yourself. For that use a binary differ (like patfchdiff2) to get a mapping between function names/offsets in old and new IDB, then preprocess the text with a tool and import names of old renamed functions with an IDC script. More info is here.