Experienced Elementalist
- Joined
- Mar 15, 2009
- Messages
- 219
- Reaction score
- 39
Hey. Since everyone's been clamoring lately over how packets work, their involvement with everything, etc. I'll post this since Phail's thread is... lackluster, to say the least. I don't really have any interest in Gunz anymore as anything more than a sandbox for stuff I learn, so do what this info what you will.
If you wanna see the packets in action as an example, see the source to mine or Phail's server emu. I can post the structure though.
The first 10 bytes are the header, which goes as follows.
-Byte 1 -> Version. 0x64 if the packet isn't meant to be encrypted, 0x65 if the packet is meant to be encrypted, 0x0A if the packet is the key exchange packet.
-Byte 2 -> Always null (0x00).
-Bytes 3 and 4 -> The length of the whole packet (unsigned short).
-Bytes 5 and 6 -> The packet checksum (unsigned short).
-Bytes 7 and 8 -> The command size (packet length - 6; unsigned short).
-Bytes 9 and 10 -> The command ID/opcode (unsigned short). The entire protocol is mapped and public. If you can't find it, dump it from Olly.
After the header comes the actual data. In older versions of Gunz, each parameter is preceded by a byte indicating its type, but for newer versions (what everyone deals with now) there's no such byte, the client just knows what to expect, the parameter lists are hard-coded. So in most packets the structure is:
Header -> null byte (0x00) -> data.
Bytes are just one byte. Shorts are 2 bytes, ints are 4 bytes. Some of the possible data structures in Gunz packets are the following:
-Byte -> self explained
-Short -> self explained
-Int -> self explained
-Boolean -> one byte. 0x00 = false, 0x01 = true
-UID -> consists of 8 bytes, 4 for the low ID and 4 for the high ID
-String -> these can be tricky. Some strings don't contain a length indicator and are padded with null bytes to a certain length, others have an unsigned short with the length of the string + 2 (the +2 accounts for the null terminator and I don't know what the extra is for, error on MAIET's part?) before the actual string, then the string is written, followed by a null byte (0x00).
-Structure -> again, these can also be tricky. A structure is a collection of data all rolled into one data item. Think of it like a struct in C/C++. The struct first has an unsigned int indicating the size of all the members combined. This value can be no less than 8, so when calculating it do ((number of members * size of each member) + 8). After this is another unsigned int showing how many bytes each individual member is. Then there's another unsigned integer saying how many members to the struct there are. After these 3 ints, you write the actual members of the struct.
I think I covered everything. Might have missed something though, I don't know, it's late lol. Also, keep in mind that this doesn't cover the format of every single packet, just a good majority of them. I'll let you figure out the others, this should provide a good enough start.
If you wanna see the packets in action as an example, see the source to mine or Phail's server emu. I can post the structure though.
The first 10 bytes are the header, which goes as follows.
-Byte 1 -> Version. 0x64 if the packet isn't meant to be encrypted, 0x65 if the packet is meant to be encrypted, 0x0A if the packet is the key exchange packet.
-Byte 2 -> Always null (0x00).
-Bytes 3 and 4 -> The length of the whole packet (unsigned short).
-Bytes 5 and 6 -> The packet checksum (unsigned short).
-Bytes 7 and 8 -> The command size (packet length - 6; unsigned short).
-Bytes 9 and 10 -> The command ID/opcode (unsigned short). The entire protocol is mapped and public. If you can't find it, dump it from Olly.
After the header comes the actual data. In older versions of Gunz, each parameter is preceded by a byte indicating its type, but for newer versions (what everyone deals with now) there's no such byte, the client just knows what to expect, the parameter lists are hard-coded. So in most packets the structure is:
Header -> null byte (0x00) -> data.
Bytes are just one byte. Shorts are 2 bytes, ints are 4 bytes. Some of the possible data structures in Gunz packets are the following:
-Byte -> self explained
-Short -> self explained
-Int -> self explained
-Boolean -> one byte. 0x00 = false, 0x01 = true
-UID -> consists of 8 bytes, 4 for the low ID and 4 for the high ID
-String -> these can be tricky. Some strings don't contain a length indicator and are padded with null bytes to a certain length, others have an unsigned short with the length of the string + 2 (the +2 accounts for the null terminator and I don't know what the extra is for, error on MAIET's part?) before the actual string, then the string is written, followed by a null byte (0x00).
-Structure -> again, these can also be tricky. A structure is a collection of data all rolled into one data item. Think of it like a struct in C/C++. The struct first has an unsigned int indicating the size of all the members combined. This value can be no less than 8, so when calculating it do ((number of members * size of each member) + 8). After this is another unsigned int showing how many bytes each individual member is. Then there's another unsigned integer saying how many members to the struct there are. After these 3 ints, you write the actual members of the struct.
I think I covered everything. Might have missed something though, I don't know, it's late lol. Also, keep in mind that this doesn't cover the format of every single packet, just a good majority of them. I'll let you figure out the others, this should provide a good enough start.