Packet Research Guide


Jul 13, 2012
An optional, and decent resource:
Packet Research Guide:
From: Treeku, cAble, and Viaron.​

Section 1: Network Protocols

First, you need to understand network protocols. Network protocols describe the method by which data is transmitted between a client and a server (for example, your webbrowser is a client which interacts with a webserver, and a gameclient is the client which interacts with a gameserver).

Both protocols use a system of transferring one packet (think of a crisp packet) of data at a time. You cannot send two things at the exact same nanosecond; packets are sent one after the other, which means it's possible for the system to bottleneck and become slow and congested with too many packets (hence how denial of service attacks work).

There are two network protocols, which (almost) every operating system will have defined on its system:

TCP - Transmission Control Protocol - This protocol is a reliable protocol. If you you send data via TCP, it WILL reach its destination (unless the destination server is down when it gets there). Since packets can easily get lost, this protocol ensures that you data won't get lost and will reach its destination. The drawback is that it is slow. This protocol is satisfactory for websites and IRC, but not for gaming, which is speed-oriented.

UDP - User Datagram Protocol - This protocol is an unreliable protocol. Packets will often randomly get lost during transmission. HOWEVER, it is extremely fast and commonly used by computer games.

Now, SOE had a dilemma when making SWG. They wanted the speed of UDP, but with the reliability of TCP. That's why they decided to create a system called the SOE Protocol.

The SOE Protocol uses UDP, however it adds a sequence to all of its important packets. When the SWG client sends a packet to the server, it adds a sequence number to the packet (ie. packet #1, packet #2, packet #3, etc). The server expects to receive the packets in that order - packet #1, packet #2, packet #3. If it does (ie. if after receiving packet #2, the next one it receives is packet #3, not packet #'4) then it sends an Acknowledgement. If it doesn't (and it receives packet #4 but not packet #3), then it sends an Out Of Order packet requests that packet #3 be resent. The client stores all the packets it sends until they are acknowledged by the other side, incase they need to be resent.

In short, this system allows them to use the speed of UDP, while also keeping the system very reliable for important packets.

Section 2: Data Types

Next, you need to understand data types. In programming, data types are types of variables, such as numbers, strings (of characters), decimal numbers, long numbers, etc. Variables are often formatted like: my_variable = 2889. This may remind you of algebra, but don't be daunted - you don't need to have done algebra at school to learn all of this. It's pretty easy to pickup really.

Now, you may know how on TV, computing is often said to be 0s and 1s, which is true. 0 means an off switch and 1 means an on switch. Different combinations of these off and on switches is interpreted by the computer as different kinds of symbols, letters and numbers. Each on or off switch is known as a bit. 8 bits makes 1 byte. Each letter, number, character or symbol you see here = 1 byte.

1 byte = 8 bits.
short integer = 2 bytes
integer = 4 bytes
long integer = 8 bytes
float = 4 bytes
double = 8 bytes

Integer means whole number, without decimal points.
Float/Double means decimal number.

The larger the variable, the higher the number it can reach:

Short ranges from -32,000 - 32,000
Int ranges from -2billion to 2billion
Long ranges from -9trillion to 9trillion.

Signed means they can be positive and negative. Unsigned means they can only be positive numbers. If a number is unsigned in programming, then its range changes:

Unsigned Short ranges from 0 - 64,000
Unsigned Int ranges from 0to 4billion
Long ranges from 0 to 18trillion.

You can learn more about data types here:

After you've read that, you can learn about Hex here:

Section 3: Packet Structures

After you've learned all of this, read the SWGEmu Packet Wiki to learn all about SOE packets and how they are reversed, encrypted and compressed and how they are validated to have not been tampered with during transmission. I suggest you study them in the order that they are listed:

Section 4: Useful Tools

After you've grasped all of this, you might want to look at the SWG file format and study the clientside files:

You can use SIE to examine the SWG clientside files, which can give good clues to various things in the game and how it functioned:

When you have a packet log to review, you can use the following tools:
These tools will allow you to see each packet's Hex code and what it translates to. If it translates to a string, you can see it, for example "terrain_tatooine". If it's a number of some kind, you'll be unable to see what it means in the packet tools, but you can convert them to numbers using the Windows Calculator in Start -> Run -> calc. Just type in the hex code in the Hex Section, then switch to the Decimal Section to see how the number SHOULD look. Using this method, as well as possibly testing these packets out in the code, you can work out what different aspects of a packet mean.

The various tools to work out what hex variable is saying:
Number variables will often be reversed (see little endian and big endian). You can reverse them here:

Often, you will need to know the size of a string. You can also calculate that here: You can also put hex into here, removing the spaces and 0x and , and any other formatting using the Notepad Replace All function (replace with nothing to remove things easily). If you put the hex into it without spaces and calculate the length, since each byte = two hex characters, you can simply half the result to get the size of a packet.

SWG will also sometimes want a CRC32 of a filename. For example, to spawn an object you will need a CRC32 of its directory and filename. You can generate a CRC32 of a name here:

Section 5: Packet Reversing

Although we can analyze packets pretty well by looking at the hex as well as existing packets that the pre-cu teams have reversed, if we want to reverse any packets ourselves, we can work out their structure (whether variables are 1 byte, 2 byte, 4 bytes or 8 byte) using the following method, originally from SWGANH Wiki:

Download, then in order to reverse packet structures via live debugging in ollydbg:

  • Set a break point at location: 0x0118B064, it should read POP EBX
  • Send your packet
  • Olly should break, the client is now reading your packet, the number of bytes it is reading is in register ESI, you must first let it read the header, so you should go through a sequence of two bytes then four bytes, three times, eg: ESI reads:
  • Hit play every time you want the next value, after going through the header you are in the data! Write down ESI and hit play continually until the client stops breaking at that location
If you suspect a 4-byte variable is a float rather than an integer, you can sift it through the float converter and see if anything turns up.
Top Bottom