BattleEye RCon Protocol
Das BattlEye RCon Protocol ist ein proprietäres Netzwerkprotokoll, welches zur Steuerung und Administration der gleichnamigen Anti-Cheat-Lösung BattlEye von BattlEye Innovations e.K. dient. Ursprünglich kam es vor allem in den Computerspielen der Firma Bohemia Interactive[1] zum Einsatz, hat sich aber mittlerweile auch bei zahlreichen anderen Spielen von anderen namhaften Herstellern wie etwa Fortnite[2] von Epic Games oder Playerunknown’s Battlegrounds[3] von PUBG Corporation durchgesetzt. Dabei kann die Software sowohl nur als Serverseitige als auch als Client- und Serverseitige Anti-Cheat-Lösung eingesetzt werden.
Es wird vor allem zur Administration von Gameservern genutzt und ist oft die einzige Möglichkeit diesen zu Steuern bzw. zu Administrieren. Das Protokoll ermöglicht es mehreren Nutzern gleichzeitig sich mit dem Server zu verbinden und so zum einen die Konsolenausgabe mitzulesen und zum anderen aktiv Befehle an den Server zu senden. Dabei unterscheiden sich die nutzbaren Befehle bei jedem Computerspiel stark, da diese von den Herstellern definiert werden.
So existieren für die einzelnen Spiele selbst zahlreiche, von der jeweiligen Community erstellte, RCon-Clients, welche auf die Verwaltungs des jeweiligen Gameservers und dessen Befehle spezialisiert sind, wobei diese auch oft bei anderen Spielen durch die Anpassung des Befehlssatzes zum Einsatz kommen können.[4]
Die Kommunikation zwischen Client und Server erfolgt über das UDP/IP Protokoll und nutzt dabei proprietäre Ports des Gameservers. Da die Zustellung von Datenpaketen über UDP-Verbindungen nicht garantiert ist, sorgt das RCon-Protokoll durch eine fortlaufende Sequenznummer und andere Mechanismen selbst für die zuverlässige Zustellung der einzelnen Pakete. Zudem wird vor allem durch die verbindungslose und vergleichsweise sparsame Datenübertragung über das UDP-Protokoll, mit auf das Nötigste reduzierten Headern, garantiert, dass selbst bei einer Vielzahl von verbundenen RCon-Clients, die eigentlich Bandbreite und Rechenleistung des Servers nicht zu sehr in Anspruch genommen wird und so zu einem sehr großen Teil dem eigentlichen Gameserver und seinen Spielern zur Verfügung steht.
Aufbau
[Bearbeiten | Quelltext bearbeiten]Ein typisches Paket sieht wie folgt aus: (jede Zelle ein Byte wenn nicht anderweitig deklariert)
| 7-Byte Packet Header |
|---|
| Payload
… |
Header
[Bearbeiten | Quelltext bearbeiten]Dabei ist der Packet-Header wie folgt aufgebaut:
| 'B'(0x42) | 'E'(0x45) | 4-Byte CRC32 Checksum vom Payload | 0xFF |
|---|---|---|---|
| Payload
… | |||
Zu Beginn stehen die als ACSI codierten und ein Byte großen Buchstaben B und E als Abkürzung für die Software selbst. Nachfolgend eine vier Byte große CRC32-Prüfsumme des Payloads zur Kontrolle der ankommenden Datenpakete auf Vollständigkeit und Unversehrtheit. Abschließend folgt ein festes Byte mit dem Wert 0xFF, welches den Header abschließt.
Payload
[Bearbeiten | Quelltext bearbeiten]Hier kann anhand des ersten Bytes des Payloads zwischen drei verschiedenen Typen von Paketen unterschieden werden.
Login (0x00)
[Bearbeiten | Quelltext bearbeiten]Zu Beginn der Kommunikation mit dem Server muss jeder Client ein initiales Login-Paket mit dem nötigen RCon-Passwort an den Gameserver senden.
| Header | |
|---|---|
| 0x00 (Login Paket) | Passwort (ASCII formatierter String ohne Null-Terminator) |
Dieser prüft das Passwort auf Korrektheit und antwortet dem anfragenden Client mit einem der beiden folgenden Pakete:
- Sollte BattlEye-RCon am Server aktiviert sein und das Passwort stimmt mit dem in der Config-Datei des Servers überein
| Header | |
|---|---|
| 0x00 (Login Paket) | 0x01 (Login erfolgreich) |
- Sollte BattlEye-RCon am Server aktiviert sein und das Passwort stimmt nicht mit dem in der Config-Datei des Servers überein
| Header | |
|---|---|
| 0x00 (Login Paket) | 0x00 (Login fehlgeschlagen) |
Sollte der Server die Anfrage unbeantwortet lassen, ist er entweder nicht erreichbar oder BattlEye-RCon ist deaktiviert (kein Passwort definiert).
Command (0x01)
[Bearbeiten | Quelltext bearbeiten]Nach dem erfolgreichen Login hat jeder Client die Möglichkeit, verschiedene Befehle an den Server zu senden.
| Header | ||
|---|---|---|
| 0x01 (Command Paket) | 1-Byte Sequenznummer | Befehl (ASCII formatierter String ohne Null-Terminator) |
Dabei ist zu beachten, dass die Sequenznummer eine vorzeichenlose und ein Byte große Zahl ist, welche initial beim Wert 0x00 startet. Sollte der maximale Wert von 0xFF überschritten werden startet die Squenz wieder beim Initialwert 0x00.
Der Server bearbeitet daraufhin den Befehl des Clients und antwortet mit folgendem Paket:
| Header | ||
|---|---|---|
| 0x01 (Command Paket) | 1-Byte Sequenznummer | Command-Payload |
Hierbei ist zwischen drei verschiedenen Command-Payloads zu unterscheiden:
- Kein Command-Payload (0-Bytes), wodurch der Server dem Client den Erhalt des Befehles quittiert, da standardmäßig auf jenen Befehl keinen Antwort in Form eines textbasierten Outputs folgt.
- Ein rein ASCII formatierter String (Ohne Null-Terminator), welcher die Antwort auf den Befehl in Form eines textbasierten Outputs enthält.
- Ein indexbasierter Header, welcher bei sehr langen textbasierten Outputs zum Einsatz kommt. Hierbei wird die Antwort des Servers fragmentiert und muss vom Client wieder zusammengesetzt werden:
| Header | ||
|---|---|---|
| Command Packet Header | ||
| 0x00 (Fragmentierung) | 1-Byte Gesamtzahl an Teilpaketen | 1-Byte Teilpaket-Sequenznummer |
| Textbasierter Output (ASCII formatierter String ohne Null-Terminator) | ||
Dabei ist zu beachten, dass die Teilpaket-Sequenznummer und die Gesamtzahl an Teilpakete eine vorzeichenlose und ein Byte große Zahl sind. Zudem beginnt die Teilpaket-Sequenznummer beim Initialwert 0x00 und steigt bis zur Gesamtzahl an Teilpacken minus eins. Des Weiteren können vom Server maximal 256 (0x00 bis 0xFF) Teilpakete übertragen werden, wobei der fehlende Teil von sehr großen Antworten, welcher die maximale Paketanzahl überschreiten würde, erst gar nicht gesendet wird und die Antwort somit nach dem letzten Teilpaket (0xFF) endet.
Server-Message (0x02)
[Bearbeiten | Quelltext bearbeiten]Nach dem erfolgreichen Login werden alle Nachrichten, welche der Server an die Konsole sendet, auch dem Client zugestellt.
| Header | ||
|---|---|---|
| 0x02 (Server-Message Paket) | 1-Byte Sequenznummer | Nachricht (ASCII formatierter String ohne Null-Terminator) |
Dabei ist zu beachten, dass die Sequenznummer eine vorzeichenlose und ein Byte große Zahl ist, welche initial beim Wert 0x00 startet. Sollte der maximale Wert von 0xFF überschritten werden startet die Squenz wieder beim Initialwert 0x00.
Jedes ankommende Server-Message Paket muss der Client gegenüber dem Server mittels einer eigenen Nachricht an diesen quittieren.
| Header | |
|---|---|
| 0x02 (Server-Message Paket) | 1-Byte Sequenznummer |
Hierbei ist zu beachten, dass die Sequenznummer in der Antwortnachricht des Client an den Server, der Sequenznummer der zu quittierenden Nachricht des Server an den Client entspricht.
Besonderheiten
[Bearbeiten | Quelltext bearbeiten]Da das RCon-Protokoll auf UDP aufsetzt, hat der Server keine Möglichkeit die Verbindung zu den einzelnen Client nativ zu überprüfen. Deshalb ist es notwendig spätestens alle 45 Sekunden ein Command-Paket an den Server zu senden, um diesem zu signalisieren, dass der Client noch verbunden ist. Dies kann entweder einer der Standardbefehle oder ein leerer Befehle, d. h. ein leerer String (0-Bytes), welcher als Keep-Alive-Packet genutzt wird sein.
Des Weiteren sendet der Server bei nicht erhaltenem Response auf Server-Messages diese 4 mal alle 2 Sekunden erneut.
Sollten der Client im angegebenen Zeitraum kein Command-Paket oder einen Server-Message Response gesendet haben, wird er vom Server aus der Liste der eingeloggten Clients entfernt und erhält keinen Server-Messages mehr bzw. kann keine Befehle mehr an den Server senden. Somit muss die Verbindung erneut aufgebaut und der Login-Prozess erneut vollzogen werden.
Einsatz
[Bearbeiten | Quelltext bearbeiten]Die Anti-Cheat-Lösung BattlEye sowie das oben beschriebene Protokoll finden in einigen bekannten Videospielen einsatz, wobei die folgende Liste der offiziellen Liste des Herstellers entnommen wurde:
Weblinks
[Bearbeiten | Quelltext bearbeiten]Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Bohemia Interactive: BattlEye. Bohemia Interactive, abgerufen am 31. Juli 2019.
- ↑ Fortnite-Team: 1.7.1 Patch-Notes. Epic Games, abgerufen am 31. Juli 2019.
- ↑ PUBG Corporation: Accountsperren in PUBG von BattlEye. PUBG Corporation, abgerufen am 31. Juli 2019.
- ↑ Battleye RCon Projekte. Abgerufen am 31. Juli 2019.