HowTo: Understand 0B000002 vs. 0B004002 packets

The 0B000002 and 0B004002 are both ping pong packets (i.e. they are exchanged between client and server without any user input, just to confirm the connection works). What makes them really interesting is that they are quite different, but very similar.

Let me explain: The 0B000002 has 18 bytes of body, while the 0B004002 has 22 bytes, a difference of four bytes. The body if 0B004002 is offset by these 4 bytes.

Meaning	Bytes 0B000002	Bytes 0B004002
Sequence number of the last packet seen from "the other side"	N/A	0x14 - 0x17
Value specified in the 01000006 packet sent by the server	0x14 - 0x17	0x18 - 0x1b
Unknown, but constantly increasing number	0x18 - 0x1b	0x1c - 0x1f
Client/Server uptime?	0x1c - 0x21	0x20 - 0x25
Byteswapped confirmation that a packet group was received (e.g. 0x0000ebff will be sent by the client, when all packets of the group ffeb are received)	0x12 - 0x25	0x26 - 0x29

As you can see both packets share the same payload, but the 0B004002 one also ships upfront the sequence number of the last packet received by the other side of the communication.

HowTo: Read the first packet sent by the server

The first packet sent by the server back to the client can be understood as follows:

Header:

Bytes	Description	Length
0x00-0x01	Set to the session ID of the server	2
0x02-0x03	The length of the packets body in bytes	2
0x04-0x07	The command (aka action aka OP code): 04000000	4
0x08-0x0B	The sequence number of the packet: 00000000	4
0x0C-0x0F	The checksum of the packets body	4
0x10-0x11	Unknown initial value	4
0x12-0x13	Unknown initial value	4

Body:

Bytes	Description	Length
0x14-0x17	Base value for "ping pong" packets, though byte-swapped	4
0x18-0x1b	Unknown	4
0x1c-0x23	Some kind of session key (returned byte swapped in the next packet from the client)	4
0x24-0x25	Padding: 00 00	2
0x26-0x27	Session ID for the client (will be the first 2 bytes of every next packet from the client)	2
0x28-0x2b	Base for the checksum generation on the server	4
0x2c-0x2f	Base for the checksum generation on the client	4
0x30-0x3f	Some constant (same for every account, every server)	16

That's all currently known behind the magic happening in the first packet from the server.

HowTo: Read the first packet sent by the client

The first packet sent by the client to the server can be understood as follows:

Header:

Bytes	Description	Length
0x00-0x01	Set to 00 00 (no session ID yet)	2
0x02-0x03	The length of the packets body in bytes	2
0x04-0x07	The command (aka action aka OP code): 00010000	4
0x08-0x0B	The sequence number of the packet: 00000000	4
0x0C-0x0F	The checksum of the packets body	4
0x10-0x11	00 00	4
0x12-0x13	00 00	4

Body:

Bytes	Description	Length
0x14	Length of the following (ASCII) string	1
0x15-0x53	The client version "061004_netver:..." as ASCII string	63
0x54-0x57	Length of the following block (0x0145 bytes, byte swapped)	4
0x58-0x5B	Unknown?	4
0x5C-0x5F	Set to 04 00 00 00 if a GLS ticket follows	4
0x60-0x63	Seconds since 1970, bytes must be read "backwards"	4
0x64	Length of the following (UTF-16) string	4
0x65-0x96	The account identifier? (a GUID/UUID in UTF-16)	4
0x97-0x9a	GLS ticket length (byte swapped) 0x0102 == 258 bytes	4
0x9b-0x19c	GLS ticket generated by the launcher	4

That's all currently known behind the magic happening in the first packet.