Godot macht es Dieben zu einfach

In einer idealen Welt sollte dieser Artikel gar nicht notwendig sein. Leider neigen aber manche Menschen dazu, ihr eigenes Glück darin zu suchen, die Arbeit anderer widerrechtlich zu benutzen, um sie unter ihrem eigenen Namen zu verkaufen. Auch wenn es theoretisch jedes Projekt treffen kann, muss ich leider zugeben, dass Godot es den Dieben dabei viel zu einfach macht, so sehr mir Godot auch am Herzen liegt. Warum das so ist und wie man es möglichen Dieben erschweren kann, möchte ich in diesem Artikel beleuchten. Wichtig ist mir, direkt festzuhalten, dass diese ganze Thematik nichts mit Kopierschutz oder DRM zu tun hat.

Zwei solcher Fälle werden in den beiden Videos von den Betroffenen beschrieben:

Das Vorgehen ist in beiden Fällen ähnlich: Die Diebe nutzen kostenlose Versionen der Spiele, verändern sie minimal (Name, Logo, Integration von Werbung, …) und veröffentlichen sie auf anderen Plattformen. Zwar sind die Assets in der Regel über das Urheberrecht geschützt, aber dass die eigentlichen Rechteinhaber diesen Diebstahl mitbekommen, ist oft Zufall und bis dann anschließend die eigenen Rechte durchgesetzt werden können, kann einige Zeit vergehen. Aber warum sind Godot-Spiele dabei besonders gefährdet, schließlich kann man auch bei anderen Engine-Projekten bspw. Assets “exportieren”?

Das Problem

Beim Exportieren von Godot-Projekten werden, mal Plugins und GDExtension ausgenommen, in der Regel zwei Dateien erzeugt. Eine plattformabhängige ausführbare Datei, bspw. .exe für Windows, und eine plattformunabhängige PCK-Datei. Diese PCK-Datei enthält alle konfigurierten Projektdateien, was standardmäßig allen Projektdateien entspricht. Und aus dieser PCK-Datei lässt sich wiederum das gesamte Projekt rekonstruieren, d.h. die gesamte Verzeichnisstruktur, die GDScript-Dateien (inkl. eventueller Kommentare), die project.godot Datei, alle importierten Ressourcen und teilweise selbst C#-Dateien können in ihre Originalformate zurückkonvertiert werden. Somit händigt man mit der PCK-Datei eigentlich immer das gesamte Projekt aus, da der Export anscheinend verlustfrei geschieht. Auch wenn man statt GDScript auf C# setzt, macht es standardmäßig keinen Unterschied, da auch C#-Code oft relativ einfach rekonstruiert werden kann.

Auch beim Web-Export wird die PCK-Datei erstellt und muss vom Web-Server ausgeliefert werden. Dies hat zur Folge, dass Diebe Skripte schreiben können, die bspw. itch.io nach Browserspielen durchforsten, die mit Godot erstellt wurden, um so den gesamten Diebstahl zu automatisieren.

Die Tools dafür sind leider problemlos zu finden und sind ziemlich komfortabel in der Benutzung. Ich habe selbst testweise verschiedene Godot-Projekte damit rekonstruieren lassen und war im ersten Moment wirklich sehr erstaunt, dass ich nach nur wenigen Klicks ein Godot-Projekt hatte, was ich ganz normal in der passenden Godot-Version öffnen konnte. Plötzlich wäre ich in der Lage gewesen, den Namen, das Logo und beliebige andere Komponenten zu verändern oder auszutauschen, um so in unter 5 Minuten meine eigene illegale Version eines Spiels zu erstellen.

Decompiling und Reverse-Engineering waren schon immer möglich und werden immer möglich sein, aber das war selten eine Frage von wenigen Minuten. Wie einfach es Godot möglichen Dieben macht, ist erschreckend.

Projektseitiger Status

Das Problem ist natürlich auch in der Godot-Community bekannt und es gibt verschiedene Proposals, die sich mit möglichen Lösungen beschäftigen. Allen voran vermutlich Obfuscate GDScript in production export, aber auch Implement a transpiler for GDScript to C++ und Use an intermediate representation format for GDScript würden für eine kleinere Angriffsfläche sorgen. Wenn man etwas in den Archiven stöbert findet man auch noch weitere Vorschläge:

• Protect Game Resources
• PCK files include human-readable script code
• Protecting game resources in exported apk

Für eine ernstzunehmende Lösung müsste Godot vermutlich große interne Umstrukturierungen vornehmen, was starke Inkompatibilitäten nach sich ziehen würde, sodass dies frühestens mit Godot 5 umgesetzt werden könnte. Mit ernstzunehmend meine ich hier auch keine perfekte Lösung, die kann es technisch nicht geben, aber eine, die mögliche Diebe ähnlich lange beschäftigt wie die exportierten Projekte anderer Engines. Und auch wenn in den Diskussionen zu diesem Thema so gerne damit argumentiert wird, dass so etwas nicht möglich ist, da Godot OpenSource ist und jeder ja den Quellcode lesen kann, ist es für mich kein haltbares Argument, da der kostenlose Zugriff auf den Quellcode der UnrealEngine problemlos möglich ist und auch der Quellcode von Unity beim passenden Preismodell zugreifbar wird.

Mögliche Lösungswege

1. Godot unterstützt direkt die Verschlüsselung der PCK-Datei mit Hilfe von 256-Bit AES. Auch wenn 256-Bit AES generell sehr sicher ist, muss man bedenken, dass der Schlüssel ja irgendwo gespeichert werden muss, damit das Spiel beim Start auf die Inhalte zugreifen kann. Der Schlüssel wird dementsprechend innerhalb der plattformspezifischen ausführbaren Datei gespeichert und mögliche Diebe müssen diesen dort dann nur noch extrahieren. Das ist zwar nicht ganz trivial, aber selbstverständlich gibt es auch bereits dafür Assistenten, die das Auslesen des Keys vereinfachen. Daher hält diese Gegenmaßnahme leider niemanden mit wirklich krimineller Energie auf.
   Es gibt auch noch Projekte wie Godot Secure, die es noch weiter erschweren sollen, aber der Einsatz solcher Skripte birgt wieder neue Risiken.
2. Man sollte beim Exportieren penibel darauf achten, dass man wirklich nur die Ressourcen exportiert, die für diese Version des Spiels erforderlich sind. Auch wenn dies den Diebstahl nicht verhindern kann, so begrenzt es zumindest den Schaden. Hätten die Entwickler im zweiten Video darauf geachtet, hätten die Diebe nur den Umfang der Demo stehlen können und nicht noch weitere Inhalte.
3. Man sollte essentielle Spielmechaniken nicht mit GDScript umsetzen. Falls man C# nutzt, sollte man NativeAOT aktivieren, da dadurch direkt plattformspezifischer Maschinencode erzeugt wird. Die Standardtools für die Extraktion der PCK-Dateien können diesen nicht direkt dekompilieren und auch andere Decompiler können ohne Debug-Informationen in der Regel nicht mehr den ursprünglichen Quellcode rekonstruieren, sondern nur noch Funktionsäquivalente.
   Alternativ lagert man die essentiellen Teile in eine eigene GDExtension, bspw. mit Godot-CPP für C++, aus und profitiert bei rechenintensiven Algorithmen von deutlich höherer Laufzeitperformance. Leider kann auch so der Diebstahl nur erschwert bzw. eingeschränkt werden, da bspw. die mitgelieferten Bibliotheken plattformspezifisch sind und so aus der gestohlenen Steam-Demo für Windows nicht einfach eine Mobile-App (Android / iOS) werden kann.
4. Die wohl mächtigste Gegenmaßnahme ist Marketing. Denn die Bekanntheit eines Spiels erhöht den Aufwand für Diebe enorm. Wenn die Spielerschaft euer Spiel durch Social Media, Dev-Logs etc. bereits kennt, wird sie vermutlich auch die illegale Kopie erkennen und euch hoffentlich darüber informieren, sodass ihr einerseits schneller reagieren könnt und andererseits der Profit vermutlich geringer ausfallen wird.

Es gibt auch den Talk “The Clone Wars: Defending Godot Games From Reupload Scams” von Yasen Dinkov von der GodotCon 2026 zu dem Thema, mit nochmal weiteren Tipps.

Leider gibt es in diesem Fall nicht einfach “DIE Lösung”, stattdessen sollte man auf das Schweizer-Käse-Modell setzen, also die verschiedenen Optionen passend miteinander kombinieren. Einen Angreifer, der es wirklich ernst meint, wird es zwar nicht abschrecken, aber für die Diebe, die auf den schnellen Profit aus sind, wird der Aufwand irgendwann zu groß, sodass sie sich vermutlich andere, leichtere Ziele suchen.

Fazit

Ist Godot nun ein Risiko? Nach meinen Ausführungen sollte jedem klar sein, welchen Risiken man sich aussetzt. Ist es ein Problem? Meiner Meinung nach nicht wirklich, auch wenn ich mir eine bessere engineseitige Lösung wünschen würde. Wenn man sich der Gefahren bewusst ist, kann man gezielt daran arbeiten, die Angriffsfläche so klein wie möglich zu halten und im Idealfall kommt dabei sogar das besser optimierte Spiel für den Spieler raus. Ich selbst habe gerade erst einen Map-Generator von GDScript auf C++ umgestellt und dadurch benötigt der Algorithmus nur noch 12ms statt vorher 450ms.