Login (Auth) Protocol

Overview

All login server/client packets are encrypted using a modified blowfish scheme. Each Blowfish encrypted block is 64 bits long. Once a client connects, server initiates communications by sending an initialization packet. This packet is encrypted with a constant blowfish key (which can be found in the client). What is important, this packet contains the blowfish key used for further communications.

First packet from the server:

1. Write packet data
2. Extend packet size to a multiple of 8
3. Encipher packet data by a 32-bit XOR key
4. Append 8 bytes
5. Store XOR key in the first 4 appended bytes
6. Encipher packet using a blowfish key known in advance
7. Send packet

Other packets from the server:

1. Write packet data
2. Extend packet size to a multiple of 8
3. Calculate packet checksum (simple/fast, XOR-based scheme)
4. Append 8 bytes
5. Store checksum in the first 4 appended bytes
6. Encipher packet using the blowfish key sent in the first packet
7. Send packet

Packets from the client:

1. Write packet data
2. Extend packet size to a multiple of 8
3. Calculate packet checksum (simple/fast, XOR-based scheme)
4. Append 16 bytes
5. Store checksum in the first 4 appended bytes
6. Encipher packet using the blowfish key received from the server
7. Send packet

NetPro-specifics

The scheme described above applies to 'modern' protocol 50721. NetPro also supports legacy auth protocols, such as 30821, including its modifications for C3 557/560, as well as C4 65x.

Invasive operations

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

1. Blowfish key is extracted from SM SetEncryption packet
2. Game server list type is extracted from CM RequestServerList packet
3. Original SM ServerList packet is dropped; it is replaced by a packet where all game servers specify the IP & port of this application (see serviceconfig.xml/<gameWorldSocket>)
4. Selected server ID is extracted from CM RequestServerLogin packet

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

Auth credential safety

As noted above, NetPro does not take any action against the RequestLogin (also known as C_LOGIN or RL) packet. The server-supplied RSA public key in SetEncryption (where applicable) is also left unchanged. Moreover, NetPro does not attempt to make any unsolicited connections, nor does it store any information about your use of the application (it does store packet logs on your machine for your convenience).

On the other hand, you are free to make use of the FastLogin script found in the examples.fastlogin package. As the name implies, it does interact with both SetEncryption and RequestLogin packets. Also, it is not tagged with a @DisabledScript annotation, so it is active by default.

Despite this, as long as the configuration file is empty/missing, FastLogin will not take any action. Therefore, the default configuration of NetPro will not attempt to access your credentials in any way (nor will it attempt to transfer them).

Source code related to invasive operations can be found in the netpro-commons-l2 dependency. Source code of examples.fastlogin.FastLogin can obviously be found in scripts/ folder.

C4 disclaimer

NetPro (just like every other app out there) does not support the clean C4 client installation's auth scheme. The original C4 AuthGateD is gone and the 656 client seems hypersensitive to the environment. On top of this, C4's GG is blacklisted at nProtect, rendering the unmodified C4 client completely useless (if either any GG file is missing or GG is not loaded, the client WILL NOT respond to Auth(Gate)D). So you should move to another revision (e.g. 660) or either disable hypersensitivity or do something else (e.g. L2Gold).