
When the client sends a packet to the server, the first byte encapsulates its opcode. This specific opcode is encrypted with a value generated by the ISAAC PRNG seeded with a dynamically server generated key during the login block. The server decrypts it and associates the opcode to the packet's respective predefined size. If the packet does not contain a fixed size, the opcode will be followed by either a byte or a word - varying per packet - for its proper size. This is then followed by the payload.
Login Protocol Overview
Every connection to the main 'gateway' server sends a single byte of data, mostly well known as the connection type. The connection type tells the main server which type of connection you wish to initiate. The old engine list consists of:
- Login request - connection type 14
- Update - connection type 15
- New connection login - connection type 16
- Reconnecting login - connection type 18
long encodedUsername = TextUtils.encodeAsBase37Integer(username); int usernameHash = (int) (encodedUsername > 16 & 31L); out.offset = 0; out.writeByte(14); // Initiate connection type out.writeByte(usernameHash); in.queueBytes(2, out.payload); for (int j = 0; j
At this point, the client reads in one byte, called the status code. The status code 0 is expected to start the login protocol correctly. If the status code is 0, the client reads a long, dubbed by many as the server session key. This is used to help generate a unique seed for the client session's packet opcode masking. The client then stores two ints that are the upper and lower ints of the client session key, which has the same purpose as the server's key. The client then starts writing the login block, which is RSA encrypted.
The login block starts with the byte 10, which is considered a magic number. Following it is the client session key and server session key longs. After the session keys, the session's UID (unique identifier or user identifier) is written to the block. This is used to distinguish between multiple sessions. Trailing behind the UID comes the client's username and password written as modified C-strings that are rather terminated with a 10 byte than a NUL byte. This block is then RSA encrypted and stored for later use.
RELATED VIDEO


