BattleEye RCon Protocol
The BattlEye RCon Protocol is a proprietary internet protocol which is used to control and administer the anti-cheat solution BattlEye from BattlEye Innovations eK. Originally it was mainly used in computer games from Bohemia Interactive , but has now also established itself in numerous other games from other well-known manufacturers such as Fortnite from Epic Games or Playerunknown's Battlegrounds from PUBG Corporation . The software can be used both as a server-side and as a client- and server-side anti-cheat solution .
It is mainly used to administer game servers and is often the only way to control or administer them. The protocol enables several users to connect to the server at the same time, reading the console output on the one hand and actively sending commands to the server on the other. The usable commands differ greatly for each computer game, as these are defined by the manufacturers.
For the individual games themselves, there are numerous RCon clients created by the respective community, which specialize in the administration of the respective game server and its commands, whereby these can often be used for other games by adapting the command set.
The communication between client and server takes place via the UDP / IP protocol and uses proprietary ports of the game server. Since the delivery of data packets via UDP connections is not guaranteed, the RCon protocol itself ensures the reliable delivery of the individual packets through a consecutive sequence number and other mechanisms. In addition, the connectionless and comparatively economical data transmission via the UDP protocol, with headers reduced to the bare essentials, guarantees that even with a large number of connected RCon clients, the bandwidth and computing power of the server are not used too much and is thus to a very large extent available to the actual game server and its players.
construction
A typical packet looks like this: (each cell one byte unless otherwise declared)
| 7-byte packet header |
|---|
| Payload
... |
Header:
The packet header is structured as follows:
| 'B' (0x42) | 'E' (0x45) | 4-byte CRC32 checksum from the payload | 0xFF |
|---|---|---|---|
| Payload
... |
|||
At the beginning are as ACSI coded and a byte capital letters B and E as an abbreviation for the software itself following a four-byte. CRC32 - checksum of the payload to monitor the incoming data packets for completeness and integrity. This is followed by a fixed byte with the value 0xFF , which closes the header.
Payload:
The first byte of the payload can be used to distinguish between three different types of packets.
Login (0x00)
At the beginning of communication with the server, each client must send an initial login package with the required RCon password to the game server.
| Header | |
|---|---|
| 0x00 (login package) | Password (ASCII formatted string without null terminator) |
This checks the password for correctness and answers the requesting client with one of the following two packets:
- BattlEye-RCon should be activated on the server and the password matches that in the server's config file
| Header | |
|---|---|
| 0x00 (login package) | 0x01 (login successful) |
- If BattlEye-RCon is activated on the server and the password does not match the one in the server's config file
| Header | |
|---|---|
| 0x00 (login package) | 0x00 (login failed) |
If the server leaves the request unanswered, it is either not available or BattlEye-RCon is deactivated (no password defined).
Command (0x01)
After the successful login, each client has the option of sending various commands to the server.
| Header | ||
|---|---|---|
| 0x01 (command package) | 1-byte sequence number | Command (ASCII formatted string without null terminator) |
It should be noted that the sequence number is an unsigned and one-byte number, which initially starts with the value 0x00 . If the maximum value of 0xFF is exceeded, the sequence starts again at the initial value 0x00 .
The server then processes the client's command and responds with the following packet:
| Header | ||
|---|---|---|
| 0x01 (command package) | 1-byte sequence number | Command payload |
A distinction must be made between three different command payloads:
- No command payload (0 bytes), as a result of which the server acknowledges receipt of the command to the client , since by default this command is not followed by a response in the form of a text-based output.
- A purely ASCII formatted string (without null terminator ), which contains the response to the command in the form of a text-based output.
- An index-based header that is used for very long text-based outputs. The server's response is fragmented and has to be put together again by the client:
| Header | ||
|---|---|---|
| Command Packet Header | ||
| 0x00 (fragmentation) | 1-byte total number of partial packages | 1-byte partial packet sequence number |
| Text-based output (ASCII formatted string without null terminator) | ||
It should be noted that the partial packet sequence number and the total number of partial packets are an unsigned and one byte number. In addition, the partial package sequence number begins with the initial value 0x00 and increases to the total number of partial packages minus one. Furthermore, a maximum of 256 ( 0x00 to 0xFF ) partial packets can be transmitted by the server , whereby the missing part of very large responses, which would exceed the maximum number of packets, is not sent at all and the response thus ends after the last partial packet (0xFF).
Server message (0x02)
After the successful login, all messages that the server sends to the console are also delivered to the client.
| Header | ||
|---|---|---|
| 0x02 (server message package) | 1-byte sequence number | Message (ASCII formatted string without null terminator) |
It should be noted that the sequence number is an unsigned and one-byte number, which initially starts with the value 0x00 . If the maximum value of 0xFF is exceeded, the sequence starts again at the initial value 0x00 .
The client must acknowledge each incoming server message packet to the server by means of a separate message to the server .
| Header | |
|---|---|
| 0x02 (server message package) | 1-byte sequence number |
It should be noted that the sequence number in the response message from the client to the server corresponds to the sequence number of the message from the server to the client to be acknowledged.
particularities
Since the RCon protocol is based on UDP , the server has no way of natively checking the connection to the individual client. It is therefore necessary to send a command packet to the server every 45 seconds at the latest in order to signal to it that the client is still connected. This can either be one of the standard commands or an empty command, i.e. H. be an empty string (0 bytes), which is used as a keep-alive packet .
In addition, if a response to server messages is not received, the server resends these 4 times every 2 seconds.
If the client has not sent a command packet or a server message response within the specified period, the server removes it from the list of logged-in clients and no longer receives any server messages or can no longer send commands to the server. The connection must therefore be re-established and the login process must be carried out again.
commitment
The anti-cheat solution BattlEye and the protocol described above are used in some well-known video games, the following list being taken from the manufacturer's official list:
Web links
Individual evidence
- ↑ Bohemia Interactive: BattlEye. Bohemia Interactive, accessed July 31, 2019 .
- ↑ Fortnite Team: 1.7.1 Patch Notes. Epic Games, accessed July 31, 2019 .
- ↑ PUBG Corporation: account suspensions in PUBG of BattlEye. PUBG Corporation, accessed July 31, 2019 .
- ↑ BattlEye RCon projects. Accessed July 31, 2019 .