In an ideal world, this article wouldn’t even be necessary. Unfortunately, however, some people tend to find their own happiness in illegally using the work of others to sell it under their own name. Even though, in theory, this could happen to any project, I must sadly admit that Godot makes it far too easy for thieves, as much as Godot is close to my heart. In this article, I’d like to explore why this is the case and how we can make it more difficult for potential thieves. It’s important to me to state right away that this entire issue has nothing to do with copy protection or DRM.
Two such cases are described by the affected parties in the following videos:
The method is similar in both cases: The thieves use free versions of the games, make minor changes (name, logo, integration of ads, etc.), and publish them on other platforms. Although the assets are generally protected by copyright, it’s often just by chance that the actual rights holders notice this theft, and it can take some time before they’re able to enforce their rights. But why are Godot games particularly at risk? After all, you can “export” assets from other engine projects as well, can’t you?
The Problem
When exporting Godot projects (with the exception of plugins and GExtensions) two files are typically generated: a platform-specific executable file (e.g., .exe for Windows) and a platform-independent PCK file. This PCK file contains all configured project files, which by default corresponds to all project files. And from this PCK file, the entire project can be reconstructed. That is, the entire directory structure, the GDScript files (including any comments), the project.godot file, all imported resources, and in some cases even C# files can be converted back to their original formats. Thus, when you hand over the PCK file, you’re essentially handing over the entire project, since the export appears to be lossless. Even if you use C# instead of GDScript, it makes no difference by default, since C# code can often be reconstructed relatively easily as well.
A PCK file is also generated during web export and must be served by the web server. As a result, thieves can write scripts that, for example, scan itch.io for browser games created with Godot, thereby automating the entire theft process.
Unfortunately, the tools for this are easy to find and quite user-friendly. I tested them myself by having them reconstruct various Godot projects, and at first I was truly shocked that, after just a few clicks, I had a Godot project that I could open normally in the appropriate Godot version. Suddenly, I would have been able to change or replace the name, the logo, and any other components to create my own illegal version of a game in under 5 minutes.
Decompiling and reverse engineering have always been possible and always will be, but it was rarely a matter of just a few minutes. It’s alarming just how easy Godot makes it for potential thieves.
Project-side Status
Of course, this issue is also well-known in the Godot community, and there are various Proposals that explore possible solutions. Obfuscate GDScript in production export is probably the most prominent among them, but Implement a transpiler for GDScript to C++ and Use an intermediate representation format for GDScript would also reduce the attack surface. If you browse through the archives, you’ll find even more suggestions:
- Protect Game Resources
- PCK files include human-readable script code
- Protecting game resources in exported apk
For a viable solution, Godot would likely have to undergo major internal restructuring, which would result in significant incompatibilities, meaning this could be implemented no sooner than with Godot 5. By “viable”, I don’t mean a perfect solution, that’s technically impossible, but one that keeps potential thieves occupied for about as long as exported projects from other engines do. And even though people in discussions on this topic love to argue that something like this isn’t possible because Godot is open source and anyone can read the source code, I don’t find that a valid argument, since free access to the Unreal Engine’s source code is readily available, and Unity’s source code also becomes accessible with the right pricing model.
Possible Solutions
- Godot directly supports encrypting the PCK file using 256-bit AES. Even though 256-bit AES is generally very secure, it’s important to keep in mind that the key has to be stored somewhere so the game can access the content when it starts. Consequently, the key is stored within the platform-specific executable file, and potential thieves need only extract it from there. While this isn’t entirely trivial, there are, of course, already tools available that simplify the process of extracting the key. Therefore, this countermeasure unfortunately won’t prevent anyone with truly criminal intent.
There are also projects like Godot Secure that are designed to make it even more difficult, but using such scripts introduces new risks. - When exporting, you should take great care to ensure that you are exporting only the resources required for this version of the game. Even if this cannot prevent theft, it at least limits the damage. If the developers had taken this into account in the second video, the thieves would have been able to steal only the content included in the demo and no additional content.
- You should not implement essential game mechanics using GDScript. If you are using C#, you should enable NativeAOT, as this generates platform-specific machine code directly. The standard tools for extracting PCK files cannot decompile them directly, and other decompilers generally cannot reconstruct the original source code without debug information. They can only produce function equivalents.
Alternatively, you can move the essential parts into a separate GDExtension, for example, using Godot-CPP for C++, and benefit from significantly higher runtime performance for computationally intensive algorithms. Unfortunately, even this approach can only make theft more difficult or limit it to a certain extent, since, for example, the included libraries are platform-specific, meaning that the stolen Steam demo for Windows cannot simply be turned into a mobile app (Android/iOS). - Marketing is probably the most effective countermeasure. That’s because a game’s popularity makes it much harder for thieves to operate. If the gaming community is already familiar with your game through social media, dev logs, etc., they’ll likely recognize the illegal copy and, hopefully, let you know about it—which will allow you to respond more quickly and, in turn, likely reduce the profits made by those distributing it.
There is also a talk titled “The Clone Wars: Defending Godot Games From Reupload Scams” by Yasen Dinkov from GodotCon 2026 on this topic, which offers even more tips.
Unfortunately, there isn’t just “THE solution” in this case; instead, you should rely on the Swiss cheese model, which involves combining the various options in the right way. While this won’t deter a truly determined attacker, for thieves looking for a quick profit, the effort will eventually become too great, so they’ll likely look for other, easier targets.
Conclusion
So is Godot a risk? Based on what I’ve explained, it should be clear to everyone what risks you’re exposing yourself to. Is that a problem? In my opinion, not really—even though I’d prefer a better solution on the engine side. If you’re aware of the risks, you can work specifically to minimize your attack surface as much as possible, and ideally, this will even result in a better-optimized game for the player. I myself just converted a map generator from GDScript to C++, and as a result, the algorithm now takes only 12 ms instead of the previous 450 ms.