Protecting Your Godot Project from Decompilation

[sepTN]

In this post I would like to explore two ways of protecting your Godot Projects, of which many would consider it as a futile effort and better spend that effort on actually working your game. Nevertheless I think it's a bad attitude to just leave it open just because you think it's going to be pricked open anyway. While it's hard to avoid decompilation, it shouldn't be that hard to protect your code from common script kiddies.

---

When exporting your Godot project, for example, to Windows, you'll receive two essential files:

• MyProject.exe: Think of this as a runner, a mini Godot Engine with editor options stripped out, also known as a template.
• MyProject.pck. This file contains your entire Godot project directory, packed into a single file. By default, the runner will look for the .pck file with the same name.

Now, it's crucial to understand that if you don't put an encryption key, public tools like gdsdecomp can easily pry it open, giving unauthorized users access to your entire Godot project as if they had the original source code.

The decompiled Godot .pck will be a complete Godot project folder, which they can open in the editor and press play to see the project in action, complete with all the connections and comments you added in your .gd files (at least in Godot 4 as I'm writing this. In Godot 3, the comments were stripped).

But, if you do use an encryption key, your MyProject.pck will be unreadable because it's now encrypted. The regular, default or vanilla template won't work anymore. This is why when you want to enable encryption, you need to compile your own custom template with the encryption key enabled, so the compiler can slide-in the decryption key somewhere within your MyProject.exe.

Pre-Requisite: Compiling Your Own Godot Engine

Before proceeding further, make sure you already got the hang of working with source code. The process of compiling your own Godot Engine might sound intimidating, but it's relatively straightforward. Here's how you can do it:

1. Clone the Godot Engine Repository: Start by cloning the official Godot Engine repository to your local machine using Git.

git clone https://github.com/godotengine/godot.git

2. Install Requirements: Make sure you have all the necessary requirements installed to build the engine for your platform. Refer to the documentation for platform-specific requirements: Windows, MacOS, Linux.

3. Build the Engine: With the requirements in place, run the build system command for your platform.

scons platform=<platform>

Replace <platform> with your specific platform identifier, such as linuxbsd, macos, or windows. The compilation process may take some time depending on your hardware.

Method 1: Protecting Through Encryption

Now, let's delve into the realm of encryption. How do I encrypt my project so that people can't simply extract my assets?

Generate Your Key

First generate an 256-bit key. You can do it using openssl command-line tools, or many other ways. But for this example I will use the easiest way by running this snippet on my Godot:

extends Node

func _ready() -> void:
	print("Gimme Keys".sha256_text())

Results: 349e3c33f142fe97699bcfb447e2938c6bac7860b872a87b599a8a89f2f1cb39

Compile Godot Engine Using Your Key

After that, you need to slide in this key to your environment variable to your system.

Linux/MacOS

export SCRIPT_AES256_ENCRYPTION_KEY="your_generated_key"

Windows (Powershell)

$env:SCRIPT_AES256_ENCRYPTION_KEY="your_generated_key"

scons will try to read SCRIPT_AES256_ENCRYPTION_KEY in your system's Environment Variables, if it does find it, the script will then slide in that key in your binary.

• Compile your Godot Engine Editor

scons platform=<platform>

• Compile your Godot Export Template

scons platform=<platform> target=template_release
scons platform=<platform> target=template_debug

All the files will be created inside bin directory of your Godot source code.

Set Your Custom Template

Now you need to tell Godot Engine to use that custom template instead of the default template. You can do so by opening Project -> Export -> Add your platform and put your custom template in that field

Export Your Project

Head over to Encryption tab, make sure you:

• enable the Encrypt the exported PCK toggle.
• Fill in the Filters to include files/folders, if you leave it empty, nothing will actually get encrypted. *.* means that all files of all extensions will be encrypted.
• Fill in the Encryption Key with the exact same thing that you used during the compilation. Mine was 349e3c33f142fe97699bcfb447e2938c6bac7860b872a87b599a8a89f2f1cb39

All that left is to click the Export Project button.

Conclusion

Although using encryption can enhance your project's security, it's important to note that it's not entirely foolproof. While it's true that your .pck file will be jumbled mess, however since the encryption key is somewhere within the .exe. Public tools like gdke can attempt to grab the key. Or with tool like IDA, veteran reverse engineers would also have no problem in retracing your binary and find the key.

Unfortunately, there's no easy or perfect way to secure your code in open-source software. Every step is laid bare, and it's only a matter of time before someone develops a tool that retraces the steps backward, leading to a decompiler. So, if you want to protect your assets seriously, consider using C++ which I will explain in the next method.

Method 2: Protecting Through Engine Modification

Second way of protecting your Godot Project is to getting your hands dirty and directly change from the source. Open your Godot Engine source code and navigate to this file core/io/file_access_encrypted.cpp. And have a look. The function of interest is right at the top, open_and_parse which is responsible for encrypting and decrypting the .pck file.

Here's a simple example of how you can change the mechanism:

Inside that function, modify it into something like this:

You see what I did there? Now if they managed to use public tool and grab your private key, they didn't know that the key now has to be "reversed" in order to prick open your PCK. Save the file, and then recompile the Godot Engine Editor and your custom templates again. At this point gdsdecomp will not work anymore on your exported project since the mechanism has changed.

This is just a simple example just for a starter, for extra steps you can add some salts, flip some bytes, split the earth or something so that even if the public tool can find your encryption key, they still need to figure out what they should do with it, now that the procedure has changed from the original.

Disclaimer

There is no bulletproof way to protect your game from decompilation. When people want your code, they will have your code. The best you can do is to delay their effort and deters the common script kiddies. Accepting this reality is crucial in managing your expectations.

[RedDoor]

So I'm not familiar with compiling, but I assume that a project made using GDscript with Godot Engine is compiled when exported to the different platforms, despite GDscript being an interpretive language ?

[sepTN]

@RedDoor GDScript is indeed an interpreted language, however there is no compilation involved when exporting a project made using GDScript with the Godot Engine. When you export your project to different platforms, the GDScript code remains in its original text form and is interpreted by the Godot Engine runtime on the target platform.

There is no intermediate step of converting the GDScript code into machine code or a binary executable. Instead, the Godot Engine reads and executes the GDScript code directly by something called GDScript VM.

With that said, in the future this might change. There is a proposal submitted by Juan, to improve the performance of the GDScript, which might bring an actual compilation for GDScript.

[RedDoor]

@sepTN So when a project is exported, and made with GDscript, the VM is also in the exported project ?
If yes, what's the size of said VM ?

[sepTN]

GDScript VM is just like any other Godot Modules. And when you are using Godot C#, it will just simply use GodotSharp modules since you need that one to read C# bytecode.

Those modules are inside in the Editor itself (that's how you can debug and play the game in the IDE), and the templates.

If you have Steam version of Godot, this is what I mean by the templates

[RedDoor]

@sepTN alright I get it thanks !

[sepTN]

Since C++ might not be everyone's forte. So if there's anyone out there want to modify the way their PCK file is being parsed, I'm offering a free community service to help. Just mention me in chats.

And I imagine it will go like this:

• You create a private repository on Github, and import Godot Engine source codes.
• Invite me as a collaborators in that private repository.
• I will then clone it, push a commit with my proposed changes.
• You can review what has changed, then you can compile it yourself, or have Github actions handle it.

With caveats:

• No guarantee
• I'd do it when I have free time
• Tell me more about your project here

[rgyani]

These steps dont work for android, right?

I see all the options and was able to generate the templates, but the exported aab still contains plain source code

[jonathanhecl]

It is not possible that it is saving the gdscript in the pck and that it even includes the original comments.
Even the gdscript can be read with the notepad inside the pck.

This should be the most important thing in Godot's future roadmap.