Game Protocol

Overview

The same encryption scheme (with only minor differences) was used both pre- and post-C4, so it was essentially unchanged.

All game server/client packets are enciphered using an XOR-based scheme.

The initial key is made of two parts: a dynamic part given by the game server and a pre-shared part known to the game client (and server) in advance. Legacy clients had two pre-shared key parts. The one to be selected was determined by evaluating the dynamic key part sent by server.

During cipher operations, the last 4 bytes (DWORD) of the dynamic key part is incremented by the amount of bytes processed by each operation.

Once a client connects, it will immediately send an unenciphered protocol version packet. The server will respond with an unenciphered packet specifying whether the protocol is supported and disclose the mutable key part. The server, if applicable, will also identify itself and send an initial opcode obfuscation key for the client. If the opcode obfuscation key is not 0, client will then shuffle most of its 1st and 2nd opcodes.

The CM obfuscation key also changes each time a character is logged in.

Except for the first packet, each game server packet is transmitted by taking the following steps:

1. Write packet data
2. Encipher payload using XOR with both parts of the key
3. Update the mutable part of the key
4. Send packet

Except for the first packet, each game client packet is transmitted by taking the following steps:

1. Write packet data
2. Obfuscate opcode(s)
3. Encipher payload using XOR with both parts of the key
4. Update the mutable part of the key
5. Send packet Game server/client packets are not padded.

NetPro-specific

In order to successfully intercept transmitted data, the following invasive operations are performed by this application:

1. Protocol version is extracted from CM SendProtocolVersion packet
2. XOR and obfuscation keys are extracted from SM VersionCheck packet
3. Obfuscation key is extracted from SM CharacterSelected packet

These can be found in the supplied packet definitions by searching for __INVASIVE_AUTO_ script aliases.

NetPro is also able to function without these aliases (or definitions themselves), but the hardcoded algorithm is currently out-of-date.

New protocol revisions

Each time packet content's structure changes, the network protocol revision number changes.

Whenever you encounter an unknown protocol revision, e.g. , you must update all_known_protocols.xml.

CM opcode shuffling

From time to time (usually after a major Lineage II update) new packets are added to the network protocol (or old ones are removed/replaced). This does require the obfuscation configuration to be adjusted.

First of all, the obfuscation table sizes need to be increased to allow new opcodes to be shuffled.

Secondly, some opcodes may become excluded from the shuffling scheme (or old exceptions may be revoked).