751 Protocol

 February 21, 2013. While the Evolution of Combat was launched

during the 743 revision of

AboutEdit

The 751 protocol is very similar to previous Runescape revisions. Not surprisingly, little has changed from the jump from pre-EoC to post EoC. Very little developers have participated in building the 751 or EoC era, because people either have little interest in EoC, or people don't have the required skill level to contribute. In the next paragraphs, you will learn about how the basic EoC protocol works, from update server to ground items.

Note: ShoeOnHead doesn't know what a protocol is. Be warned.

Js5/Handshake ProtocolEdit

First, a byte is read to indicate the type of protocol to decode.

Opcodes:

• 15 - Js5 Update (Stage at which the server updates the client by sending cache files)
• 14 - Js5 Login (Stage at which the server finishes Js5 update and is ready to show the login screen)

If the state of the protocol is to check the version, an unsigned byte is read from the buffer. This byte is the buffer length, in bytes, to check if the decoder knows what to expect from the client. Then, the version and sub-version are read as integers. Afterwords, the client expects a satus code, and an array of 25 integers that represent the update blueprints. The update status codes include:

• 0 - Status OK
• 6 - Status out of date
• 7  - Status full

Otherwise, the decoder should read an unsigned byte known as the packets. These packets tells the server what data to decode.

Opcodes:

• 0
• 1
• 2
• 3
• 4

Opcode 0 and 1:

Opcode 0 and 1 are responsible for telling the server that there is a new file request, the information is read by first reading a byte as the type. Next, an int is read as the file ID. However, if the opcode is 1, then the file request is marked as a "priority" file.

A file is encoded by first, writing a byte as the type. Next, and int is written as the file ID. A bitwise OR mask is written as a byte, containing 0x80 as the compression type. The end of the buffer should contain 0xFF as a byte.

Opcode 2 and 3:

Opcode 2 and 3 tell the server that the client is either, 2, performing a log in. Or 3, performing a log out. This keeps the server updated on the state of the client.

Opcode 4:

Opcode 4 is responsible for telling the server that there sould be an update in the encyption. An int is read as the encryption key, and a short is read as the padding.

The Login ProtocolEdit

The first byte read from the login buffer is a connection request. The connection requests veries depending on the stage of login you are at; or if the client is re-connecting after a lost connection to the server. A short is read directly after, which is always 0.

The connection requests include:

• 16 - Represents an initial login into the lobby.
• 18 - Represents a re-connection login after the client has lost communication with the server
• 19 - Represents A login into the world; via lobby

These connection requests will change a few things in the decoding process. So RS keeps track of the connection being processed. The next stage in the login protocol is to decode the client version and details. An int is read containing the client version, followed but a second int representing the sub version, which is normally 1. If the connection type represented a world login, then an extra useless byte is read. 

Next step is the encrypted buffer decode, which is encrypted using RSA to protect user credentials and private details. First, a byte is read as the buffer length, in bytes. This is to make sure there is enough data to decode. Next, the RSA buffer is intialized by using a private key and modulus key in a big integer.

A byte is read as the "magic number", which should be 10. After the magic number, 4 integers are read containing the XTEA keys. A long is then read as a verification, usually 0. Next and importantly, a null terminated string is read to represent the player's password. Then, a client session key and server session key are read as longs.

The next stage is to decode the XTEA buffer. The buffer is generated by deciphering the seeds that were sent earlier during the RSA buffer. Which is filled into an array of 4 keys. A boolean is read to indicate if the player's username should be read as a base37 string, or a regular string. If true, then Runescape reads the string as a base37. Otherwise it's just read as a null terminated string. After that, a byte is read to indicate the display mode of the user's client. A useless byte is read after the display mode, and if the connection type is world, then 2 useless shorts are read.

Next, machine information is decoded. RS reads this in a 24 byte block, and is usually skipped because it is not needed in RSPS.

After the machine information is either skipped or read, the CRC data is decoded. This is used to make sure the client is up to date. A string is read as the 'token', if the connection type is a lobby login, a byte is then read to intialize an array to represnt the index files. Then the data is read as an integer which should be intializing a new array. The array is filled by reading integers into the array. If the connection type is a world login, then a useless integer is read. Afterwords, a byte is read to indicate the amount of data to expect. This is just ignored.

Now for encoding login details to the client. This stage lets the client know about the player's profile, including rights or if they are a member or not. This stage also flags the client a response, letting it know if it should proceed to log in the player, or just notify as to why they cannot proceed. Such as invalid credentials.

First to notify the client of the login response, a var byte packet with the response code is sent. Following, is the login details. Lobby and world are different, have a lot of unkown data, and are lengthy to cover every byte. Most of the data is useless to RSPS, but some isn't; such as the last logged in date, subscription time left, messages in message centre, etc. This is all handled in the lobby. The rights and username are handled in both the lobby and world, this is to notify the client of the priveliges that the player has, and give an intial name to call the player by.

During the login session in the lobby, the player will recieve a packet that represents a worldlist update request. This will be covered later in this article.

Game PacketsEdit

Game packets will be covered in this section of the article. Some packets will be left out due to the lack of knowlege of them.

Outgoing:

Incoming:

Player RenderEdit

The only change in the rendering process that Jagex has implemented over the past few revisions is a new slot. The slot is 'pocket', and it is written after the existing aura slot. If the item is null, a null byte is written. Otherwise, 0x4000 + the pocket item ID is written as a short. Another simple change is a sheathing update. The bit mask is changed for the global data, and a single 0x1 byte is written, followed by 2 large smarts that indicate the model ID of the sheathed weapon. This block of slot data is written in the weapon or shield section (During the 3rd and 5th loop around the equipment slots).

ResourcesEdit

Downloadable sources: 

• Psychedelic - http://www.mediafire.com/download/43bdd52yej53q5t/Psychedelic.rar
• 751 Server - http://www.rune-server.org/runescape-development/rs-503-client-server/downloads/477426-751-server-so-far.html
• http://www.rune-server.org/runescape-development/rs-503-client-server/downloads/495915-xplur-eoc.html