Better encryption for your game scripts in Godot, one commit away?

Protecting game assets and scripts has always been a cat-and-mouse game between developers and those who try to reverse-engineer or copy their work. If you’ve been building with Godot, you may already know that the engine offers PCK encryption as part of its export pipeline. On paper, this sounds like a good way to secure your GDScripts, scenes, or resources. In practice, however, the protection is often limited.

The limits of current PCK encryption

Godot currently uses AES-256 encryption to protect .pck or .zip packs. The idea is simple: your assets get encrypted, and the engine uses a key to decrypt them at runtime.

The problem?

• That key has to be included in the shipped binary, otherwise the game couldn’t load its assets.
• Attackers can extract that key by analyzing the binary or watching the game in memory as it runs.
• Once the key is known, the pack can be decrypted with relative ease.

In fact, it’s trivially easy today thanks to community-made tools like gdke. This project demonstrates just how quickly the standard Godot encryption scheme can be broken. You don’t even need to be an expert reverse engineer—if you know the engine’s patterns, you can locate the decryption key in the binary and use it to unpack the whole game.

This is the downside of standardized security: because every Godot project uses the same approach, once someone documents the method, it can be automated and shared. Encryption in this context becomes less of a true lock and more of a shared secret hidden in the same place for every developer. For attackers, it’s a one-time investment that works on all games.

A new possibility: custom encryption keys via GDExtension

A pull request to the Godot repository (PR #91884) proposes something quite powerful:

It allows loading packs with a custom encryption key, provided by the developer at runtime.

Why is this important? Because it breaks the current limitation of having to rely on a single key hardcoded into the Godot binary.

With this change, developers could:

• Implement their own encryption key logic in a GDExtension, written in C++, Rust, or another supported language and handle the decryption key in custom ways, for example, deriving it dynamically, hiding it across multiple locations, or even fetching components of it from an external source.
• Avoid recompiling the entire engine, since GDExtensions can plug into Godot natively.

This doesn’t magically make the key a total secret , as nothing client-side is ever truly secret, but it raises the bar a bit.

Instead of looking in the Godot binary for a static key, using a already built tool, an attacker would now need to reverse-engineer your custom native code or it could potentially compile a custom built of Godot to hijack the decrypt function to print this key.

Maybe in the future Godot would natively allow us to use custom encryption via something like GDExtensions but even in that case one could potentially hijack the load resource to print the data.

But having this combined with something like GDMaim which is a GDScript obfuscation plugin for the Godot Engine might just make it a bit more complicated for less determined individuals.

Why this matters for us game developers?

For developers shipping commercial games, protecting scripts and assets isn’t just about piracy—it’s also about protecting your competitive advantage, preventing copycat clones, and sometimes even complying with licensing restrictions for third-party assets.

Today, Godot’s encryption is often bypassed by anyone with enough motivation. With this new flexibility:

• You can craft a more layered defense against casual attackers.
• Your asset protection becomes more customized, making generic tools like gdke ineffective against your particular setup.
• You can integrate platform-specific security features (e.g. using secure enclaves or obfuscation libraries on certain platforms).

While it won’t provide bulletproof security, it gives developers a stronger toolkit. Think of it less like a lock and more like adding multiple obstacles—each one buys you more time and discourages more would-be attackers.