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.

HowTo: Understanding a packet header

Let's take a look at some of the packets we already know and understand. First of a few basics as a reminder:

1. each and every packet has a header and a body
2. the header is fixed size, the body is variable in size
3. the header is fixed in content, the body varies

For now let's focus on what we know about the header.

Bytes	Description	Length
0x00-0x01	The session ID. The server and the client each have a session ID.	2
0x02-0x03	The length of the packets body in bytes	2
0x04-0x07	The command (aka action aka OP code) this packet will perform	4
0x08-0x0B	The sequence number of the packet (necessary for ordering UDP packets)	4
0x0C-0x0F	The checksum of the packets body	4
0x10-0x11	Packet group number (e.g. 0xffeb, confirmed in the 08004002 packet)	4
0x12-0x13	Unclear, get increased by the server	4

HowTo: Capture decrypted packets

To get decrypted packets for further analysis, you can easily capture and decrypt them using the LOTRO-Tools.

First of all clone the git repository from https://gitlab.com/lotro/server.

Open the Solution "LOTRO-Tools.sln" in Monodevelop or Visual Studio.

Build the project LOTROPacketCaptureAndAutoDecryption and launch it from bin/Debug/LOTROPacketCaptureAndAutoDecryption.exe

Look into the subfolder decrypted_packets for available files. The files contain a single packet each. The filename is like the following:

• 4 digits represent the sequential number of captured packets
• the text "client" says it was a packet sent by the client, the text "server" indicates it was a packet from the server
• the last 8 digits describe the action to be performed by the packet

Examples:

0000_client-00010000 is the first package captured (sequence starts at 0000), was sent from the client and contains the action 00010000

0001_server-00040000 is the second package captured, was sent by the server and contains the action 00040000

HowTo: Use LOTRO-Tools on Linux

LOTRO-Tools was developed on Windows using winpcap. It fails on Linux because SharpPcap is erroneously looking for "libwpcap.so" (as it would look for wpcap.dll on Windows), while it should look for "libpcap.so" instead. You can work around that using

sudo ln -s /usr/lib/libpcap.so /usr/lib/libwpcap.so

HowTo: Capture the appropriate packets between the client and the server

To only capture the packets necessary for analysis of the game protocol (i.e. not the chat protocol), you can use the following pcap (e.g. Wireshark) filter:

!broadcast and !multicast and udp and !port 53 and !port 59511 and !port 161 and !port 2900 and !port 5355