Obfuscate GDScript in production export

[tavurth]

Describe the project you are working on

Any project which can be released publicly where the developer might not want to have their code or structure implementation easily stolen.

Describe the problem or limitation you are having in your project

Currently Godot supports encryption of the exported files (if you use a custom build of the export templates)

However this is not really good enough. Almost every successful engine will at some point have a decompiler for the exported assets. (see ILSpy).

In-fact, due to the open source nature of Godot, I think it would be relatively simple to write a script-dumper, that uses the encryption to first de-crypt the files and then just dump them to some output folder once they've been loaded into memory.

Many others have also been worried about this issue, quite often with those issues being closed when the discussion goes more towards DRM or encryption.

❗️ This is not a discussion about DRM or Encryption ❗️

https://github.com/godotengine/godot/issues/39115 https://github.com/godotengine/godot/issues/24716 https://github.com/godotengine/godot/issues/19790

Describe the feature / enhancement and how it helps to overcome the problem or limitation

When exporting to production, exported GDscript files can be obfuscated with the names mangled.

In this case, adding encryption would add a layer of security, and if someone does decide to extract the files from the pck, they are left with an unintelligible mess of obfuscated code.

This additional security would put godot at the top end of protecting game assets, and likely bring users to our community.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

An example implementation can be found here

Here is a sample:

const my_variable = 5;
console.log(my_variable);

And obfuscated:

var _cs=["log"]; const _g0 = 5; console[_cs[0]](_g0);

If this enhancement will not be used often, can it be worked around with a few lines of script?

This should probably be core, because it could be part of the standard export pipeline.

Is there a reason why this should be core and not an add-on in the asset library?

I may work on an external plugin for this, but it would require duplicating the repository before every export, as this would mangle all script files.

This is not something which fits with a good export pipeline.

[Calinou]

Related to https://github.com/godotengine/godot-proposals/issues/1407.

I think the engine should minify scripts in release mode exports to reduce the PCK size, but obfuscation is much more complex to do correctly. In contrast, minification is much simpler and doesn't risk breaking as often, since it's mostly about removing comments and non-significant whitespace. Obfuscating a language like GDScript is potentially very difficult due to String-based signal connections, Object's set() and get() methods, among other things.

That said, I don't think minification would be relevant by default, since scripts are exported to bytecode already (.gdc files). If you want to make sure about this, export a ZIP file for your game data (instead of PCK) and open the resulting ZIP archive.

[tavurth]

Unfortunately breaking both the encryption and the bytecode compilation is already trivial at the time of writing:

So both of these included security features don't actually do anything to protect a games exported scripts or technology.

It took me less than 5 seconds to get access to a standard exported script. If I have to dig for the encryption key, the first time it will take me around 5 minutes and after that also less than 5 seconds.

Here is an example of one of my exported (production export) scripts after decompilation:

[tavurth]

Obfuscating a language like GDScript is potentially very difficult due to String-based signal connections, Object's set() and get() methods, among other things.

I think this is a task which should be taken step by step.

We build a basic framework for obfuscating tokens at export, which uses a script-wide name search.

Tokens such as $NodeNames can be frozen for now, but in future they could be obfuscated also (changing the .tscn files).

A broad whitelist of what to avoid obfuscating would help tremendously (i.e. never _physics_process)

---

Another way to provide increased security would be to allow customisation of the the location of the encryption key in the exported binary, although perhaps this warrants a separate proposal.

[zinnschlag]

This sounds flat out impossible. At least with the full scope of GDScript. Example:

a.call("%s_%s" % [b, c])

I don't see how you could obfuscate GDScript code without breaking a construct like this.

[tavurth]

a.call("%s_%s" % [b, c])

@zinnschlag JS actually doesn't mutate those unless you set the mangle level really high.

For your example, a basic obfuscation might look like:

0_1230a.call("%s_%s" % [0_1243a, 0_1550a])

By default I think a good first level would be obfuscation of func and var names.

Perhaps merging all GDscript files into a single large .gd file first at the time of export would help a lot with the mangling, as you could then operate on one large file instead of multiple separate ones.

[Calinou]

So both of these included security features don't actually do anything to protect a games exported scripts or technology.

My goal isn't to "protect" anything; it's just to optimize the export. Remember that Godot already has script encryption (3.x) and PCK encryption (master) support.

[tavurth]

My goal isn't to "protect" anything; it's just to optimize the export.

Yep, I understood, this proposal is about protection of assets, and not about performance.

Remember that Godot already has

The script and pck encryption can be easily bypassed as shown above.

[zinnschlag]

By default I think a good first level would be obfuscation of func and var names.

If you obfuscation function names then the example I gave won't work any more, since it constructs a function name dynamically at run time.

[tavurth]

If you obfuscation function names then the example I gave won't work any more, since it constructs a function name dynamically at run time.

~The example I wrote would still work correctly, since only the name of the variable is changing, not the contents.~

Ah I see you mean the naming of the function. In this case I recommend having the ability to exclude items from the obfuscation.

Javascript does this with the #no-mangle comment header

[tavurth]

So I've been jamming on this idea in Python and I seem to have got at least some progress:

Before, taken from godot-simple-state

After (running without issues):

Currently it runs a system-wide search for things to replace, and supports # no-mangle.

The obfuscation code needs a bit of a cleanup but I think this is at least an example of what we could do in-engine before export.

[tavurth]

I pushed the work I made so far here: https://github.com/tavurth/godot-gdscript-obfuscator

So far it's not working on the full repository, as .tscn files would need to be updated too. At the moment export variables are mangled which causes issues as the names from the .tscn file cannot be found.

I will look into this more when I'm closer to my project release.

[grayhaze]

I agree this would be very useful. I'm currently creating a puzzle game with procedural puzzle generation, which I've worked on sporadically for several years, and I'd like to protect the generation code as much as possible to prevent clones just ripping off my approach. The type of puzzles I'm creating aren't new, but I believe my generation code is unique and produces much better results than currently available alternatives. Obfuscation seems the perfect way of achieving this.

[lesleyrs]

Is the lack of this feature just a matter of being low priority, are people against it or is there another problem implementing?

Isn't this a major detriment to people making commercial games in Godot?

I did some reading on this but didn't find a clear answer whether decompiled gdc files retain the original identifier names or not? Not that it makes a big difference but if they do then I would love to see obfuscation.

[tavurth]

I did some reading on this but didn't find a clear answer whether decompiled gdc files retain the original identifier names or not? Not that it makes a big difference but if they do then I would love to see obfuscation.

You can see my screenshot above, this is what files look like after you decompile them, comments stripped but everything else the same as before:

When I posted this on reddit around 60% of people were leaving extremely negative feedback, with people yelling at me for starting work on it.

I found that a bit confusing, but my conclusion was that a large proportion of godot devs are either:

1. Uninformed about why obfuscation can be necessary to protect some games (i.e preventing hacking by using different obfuscation methods for each version)
2. Working on creating hobby projects without the idea to release something that could ever need protecting
3. Want to actually decompile and read the source code of other godot projects. (Perhaps they already are doing this)

I still feel like this is an extremely necessary part of the godot ecosystem.

We don't have to pay anything to Godot for using this engine in exported games, but creating a cool new game currently can easily be ripped off, changed some way and released on a market where the legal system has no effect. (I'm sure you can imagine such markets).

[dalexeev]

Is the lack of this feature just a matter of being low priority, are people against it or is there another problem implementing?

The lack of a feature in Godot is 90% of the time caused by a lack of people willing to do it. Also, obfuscation causes some code slowdown, meaning this potential feature should be disabled by default. I think that for a large number of projects, performance is still more important than protection.

Obfuscation is not a very reliable way to protect the code, it's just a way to make it harder to crack. Obfuscation won't help if the cracker has enough desire and deobfuscation tools (which will definitely appear over time).

You can try some third party tools to protect your code (DRM). Creating such tools is a difficult and ethically controversial goal for an open source project. I'm not sure if obfuscation that doesn't have an optimization goal (such as minimizing local variable names, constant folding, function inlining, etc.) is acceptable for an open source project. Although I understand your desire to protect your work and that it is quite common in game development.

[lesleyrs]

Obfuscation is not a very reliable way to protect the code, it's just a way to make it harder to crack. Obfuscation won't help if the cracker has enough desire and deobfuscation tools (which will definitely appear over time).

I guess this is just a problem for all languages that use byte code. Maybe my way of thinking is outdated but it feels wrong that somebody can just run a program and have direct access to the source code to easily modify various parts of the game inside godot engine itself and claim as their own? If that starts to happen enough times the idea of ownership gets very blurry.

Like with people making rom hacks they have to at least put in effort in order to do these things, and they don't have access to the original tools.

I'm not interested in DRM though.

[tavurth]

and claim as their own

Thankfully in Europe & most western countries the legal system takes care of this for you. If you are wondering if someone has copied your Godot game you can just decompile their source and find your lines of code directly to use in the lawsuit 🤷

However there are quite a few jurisdictions of the world where your lawsuit would land on deaf ears, or even worse have you labelled as the copier rather than the original owner.

Also, obfuscation causes some code slowdown, meaning this potential feature should be disabled by default

I haven't tested with my project above yet, but since I've reduced the byte size of each individual symbol in the obfuscated script, it would probably work with some small percentage performance increase.

[SysError99]

In my opinion, if we can't get obfuscation option in Godot because of various downsides, then minification should be trivial enough. It helps save some of space and make decompilation a little bit trickier with zero trade-offs.

[tavurth]

An example of why we need this:

https://www.reddit.com/r/gamedev/comments/ufa7q6/my_game_got_copied_changed_and_uploaded_to_google/

[timothyqiu]

If you are already compiling your own export template (e.g. in order to turn off some unused modules), changing the structure of GDScript byte code might be a good alternative to obfuscation. e.g. You can swap the order of constant count and identifier count fields when dumping and reading GDScript byte code.

Compile an editor and an export template with the modified engine. Export the project with the custom editor and export template. Then your exported project won't be able to be decompiled by a generic tool and is script-kiddie proof.

[the-key-point]

i dont have knowledge but having both in the default engine as an optional option if possible to exist, would be a unique step than other game engines have. What i meant is first obfuscating the code as tavurth suggested then converting the obfuscated code to bytecode as timothyqiu suggested.

[CsloudX]

I wish this feature too. Use the Godot RE Tools, my GDScript full exposure in 5 seconds. Although there was other methods to resist this, but all lose GDScript advantage. Encrypt Exported PCK I need complie export template myself. I need C++. I know full avoid cracking was impossible, but use Godot RE Tools, it too much easy. I agree implement full feature was difficult because set get or other something, and I also wish can impliemnt this step by step.

[timothyqiu]

Encrypt Exported PCK I need complie export template myself.

You can think a reverse engineering tool as a special kind of export template that iterates through all the resources instead of executing the game logic. Using a stock export template means the tool does not need to do anything that takes effort, as the export template's logic is open sourced.

You have to compile your own export template in order to hide what it does I think.

[naturally-intelligent]

I was shocked to see the RE tool exposed everything in my game, except for comments. Best to come to terms with it now than later I guess...

It would be nice to have a basic level of obfuscation for gdscript/tscn, doesn't have to be extreme, just a basic level would thwart most copycats

[SysError99]

To be fair, this type of problem already exists in some of popular game engines that use the same kind of build process, such as Unity. The only thing different is that on Unity there is already third party tool that obfuscates code, and even built-in IL2CPP tool that mitigates basic reverse engineering efforts. I have been in some of gaming groups and they indeed also do reverse engineering game files and have exposed its contents regularly. It's so trivial to do already and you only have few options to mitigate it.

In Godot's case (and few of open source game engines) is much more severe since the build process is already been made in public, so anyone can just observe a build process and find a way to reverse it. In fact, even encrypting the game engine and entire PCK file won't help that much (there is already a tool being made to find a key and decrypt game files) Plus, GDScript is also one of the weakest point of entire game engine in terms of protection. It doesn't even get minified, and it isn't a compiled code (although the exported script is a bytecode, but labels are still preserved) . It has some trade-offs especially in performance.

There aren't many things we can do to to mitigate any of reverse engineering efforts with a game engine that has simple build process. Even minification won't help that much. I only need minification feature to save some of disk space, such as internal function labels.

[naturally-intelligent]

Probably adding obfuscation/minification is not a good solution compared to transpiling?

Example: https://github.com/godotengine/godot-proposals/issues/3069

Imagine you could compile GDScript into C++ for release builds, would that be superior way of tripping up decompilers?

[Riteo]

@naturally-intelligent people have already tried using C++ transpilers to make RE harder with tools like unity, but this isn't the point of it at all.

C++ transpiling is a useful way of squeezing extra performance out of a game when it's needed without messing with C++ stuff directly, it's not meant at making RE harder.

[naturally-intelligent]

@Riteo It might not be the intention of transpiling, sure, but wouldn't it still help preventing reverse engineering?

[Riteo]

@naturally-intelligent perhaps. It'd be also definitely more obfuscated than, say, IL2CPP (the unity stuff) since there's no reflection to take into consideration (which basically preserves all symbol information and much more), but there are also very good c++ decompilers.

There's technically also the option of intermediate representation, which would deter RE similarly to transpiling if not even initially better, since there would be the need to build good decompilers.

The point is, though, that both methods aren't optimized at deterring RE per se, and implementing either just for the sake of it isn't a great idea at all IMO.

[russeg]

i think it should really be a priority to prevent godot games from being easily decompiled and recompiled. i mean, i used gdsdecomp full recovery on a steam game, and it was able to successfully unpack and make it importable in godot and make it run. that is really bad.

i know you can't protect assets from being ripped (not even unity), but in unity, you cannot import a decompiled unity project and make it run. having a game easily ripped and repacked (on android especially) hurts the small time devs (godots audience) since they don't have the resources to to fight back. do something for their sake at least.

[SysError99]

i know you can't protect assets from being ripped (not even unity), but in unity, you cannot import a decompiled unity project and make it run. having a game easily ripped and repacked (on android especially) hurts the small time devs (godots audience) since they don't have the resources to to fight back. do something for their sake at least.

The thing is, we cannot, or at least, not with this simple build process. GDScript compiled binary is still separated in files, "well-organised", and can be easily reversed even with official tools. Only way I could think of is that we need to completely revamp how GDScript compile process works. I don't think that many of contributors out there will even be interested into doing a complete overhaul of a new scripting architecture.

Even if we somehow have some of good contributors to actually pull it off and make the code not as easily decompiled anymore, you can't really have it protected completely since the build process is still the same. You can just take the supposedly 'single chunk of binary' to another project, wrap it up with new shell, and re-distribute it. It's that darn simple. You can have basically new game out of same core but new shell. It's exactly what's happening in Unity.

[Riteo]

@SysError99

even with official tools

What official tools? I'm pretty sure that Godot has no official RE tools.

[SysError99]

@SysError99

even with official tools

What official tools? I'm pretty sure that Godot has no official RE tools.

I could be mistaken since I saw some of Godot contributors actually do some jobs on the RE tools.

[Riteo]

@SysError99 I think you're talking about gsdecomp.

Yes, @bruvzg worked on it, but it is by no means official.

[hilajour]

There is another related concern that hasn't been mentioned in this discussion; GDScript cannot be compiled anymore in Godot 4.0. The .pck can be encrypted, but if you are worried about disclosing your source code, this is worse than having compilation but no encryption because (if I've understood correctly) your scripts will still be available in plaintext if/when the pck can be decrypted.

For those of us who use code comments as part of team internal communication, or as "notes to self", having unmodified source files distributed with the game binaries has bigger concerns than someone accessing the compiled algorithms. Program logic will always be accessible when running on an open platform, after all. But code comments, together with intact var/func names, may include yet unimplemented innovations, plans for the next release, detailed explanation of why it works better than the product of a competitor, etc.

Fortunately @vnen has a plan to implement intermediate representation, which will restore binary scripts, and he says would be "somewhat obfuscated", here: https://github.com/godotengine/godot/issues/59241#issuecomment-1384520401

[bruvzg]

GDScript cannot be compiled anymore in Godot 4.0.

3.x GDScript is compiled into byte code one-to-one without any changes or optimizations, source code is fully restorable (except comments and formatting), so there is not much difference.

[hilajour]

3.x GDScript is compiled into byte code one-to-one without any changes or optimizations, source code is fully restorable (except comments and formatting), so there is not much difference

There may not be much difference of how well the original source code can be restored (if we disregard the part about comments), but if it requires downloading and using an additional tool, as opposed to using a text editor which is standard in every OS, at least it's one extra step.

And if the new plan comes to fruition, any result from decompilation of stack references will require much more manual interpretation to use for unauthorized adaptations.

[RIKDXHQ11]

If Godot cannot avoid extracting and restoring game code, why should I use this engine? Just for the convenience of making games? Why don't I develop a fully compiled engine myself? Compile all resources and all code into binary (and confuse the code before compiling, using strange symbols to replace the English names of functions and variables)?

I think this is also why AAA manufacturers do not use ready-made engines, and their security cannot be trusted at all.

Many staff believe that we are complaining about DRM issues, which is not entirely a matter of avoiding piracy, but rather the loss and anger caused by the producers' wisdom being stolen by others. For example, if you create a game, it is great and many people like it, but there are bad people targeting its commercial value and stealing your source code (because you are completely unable to prevent code theft by others, and existing means cannot prevent this behavior), And developed another game for them. They only need to make a small amount of changes to make money. This behavior is called "skin changing game" in our country, which is very bad. Moreover, our intellectual property rights have been infringed, which is the most important point for us to raise opinions.

[CGcaspar]

The situation in Godot 4.0 is really bad, where not even comments are removed from the source code.

I am about to release a commercial mobile game developed with Godot 4.0 and was quite surprised to see that I could simply unzip the APK and see all my source code completely untouched.

This is definitely "special" compared to other game engines. Yes, you can decompile C# and C++ code aswell. But it is much harder to make sense of decompiled code in those languages. Which means, there is a higher barrier and more effort and resources required to work with this decompiled code.

When minified javascript running inside of a browser has better source code protection than a Godot project using GDScript then something is definitely wrong.

This is not about preventing modders or hackers from changing my game. This is about not giving away my original source code in unmodified form. This is about not having the feeling that I could have made my project open source to begin with. This is about the bare minimum of protection that I would expect (and get) from any other Engine.

I love Godot. I switched from Unreal to Godot because of the increased productivity and faster iteration cycles I have with this Engine. But this issue has me really consider my choices.

I love the idea of @vnen to implement intermediate representation for GDScript (https://github.com/godotengine/godot/issues/59241#issuecomment-1384520401). That would really be the fix of this issue for me. But I would like to know what the time horizon of this feature is and when we can expect this to actually happen. Are we talking about 4.1 or much later?

[tavurth]

I still believe that obfuscation would be the easiest, simplest option at the current time.

Adding a pre export hook or a gdscript export hook which could run for every file would allow developers like myself to at least uglify the gdscript before export.

Anyone have any idea how much effort something like that would take?

[bruvzg]

Anyone have any idea how much effort something like that would take?

You can do it by implementing add-on with the custom EditorExportPlugin, its _export_file virtual method should be called for every exported file.

[tavurth]

EditorExportPlugin, its _export_file virtual method should be called for every exported file.

Here's the direct link. for those interested in reading.

That's cool and useful!

As I see there's no way to modify the file contents before the export however. Perhaps returning a String of the new file contents could be allowed with another hook?

Something like _export_file_mutation?

This would allow me to transform the text in the file and return a new copy which could be exported. As I see at the moment I would have to change the file on disk before it was exported, which would also mangle the original.

[bruvzg]

As I see there's no way to modify the file contents before the export however.

I have not tested it, but you should be able to skip the original file, and use add_file to add custom file instead.

[tavurth]

I'm not sure if everyone has seen this, where someone made snake in one line of gdscript.

Compiling to such array style might also be an interesting way to solve this.

[RIKDXHQ11]

@LikeLakers2 I don't need absolute security, even if you install D encryption, it will still be cracked, which is not important because there are no situations where it is impossible to crack.. However, I can make it difficult for thieves to enter my home. I can use a virtual machine to put memory in, and I can also put code on the server side.. I have never said that UE4 and UNITY have no security concerns, but Godot is even worse than them. It's so bad that it even opens the back door (note, I'm not saying it's a Trojan Horse program), which is very convenient for thieves to enter.. In my words, laser anti-theft, strong adhesive, and power grid anti-theft can also be used to prevent thieves from entering the door, but this is not an absolute means, and may also be illegal means. There is a huge difference between these behaviors and welcoming thieves without any protection by completely opening the door. Even if you can disassemble my EXEC program, you will never be able to obtain my truly complete source code because it has been disrupted and encrypted. This is what I want. I don't mind someone playing my pirated game because it's inevitable, but I can't accept that the engine easily exposes the source code..

Finally, the staff also refuted and closed the discussion. In fact, they just didn't want to pay attention to this matter, because they thought that even closed source UNITY can be easily cracked, so GODOT can do nothing, and it is not a weakness. Yes, if I cover my eyes, I can't see the danger. Whether it's a cliff or the sea ahead, it's safe. Therefore, I think it is a wise choice for me to give up GODOT. :)

[YuriSizov]

Please keep the discussion on topic. You've expressed your personal feelings plenty of times already, but they do not add to the technical discussion of this proposal. Locking the other discussion and marking these comments as off-topic was a hint that this is not a debate that belongs to GitHub and it should be stopped at this point.

Please use tools that are suitable for you. We do not claim that Godot is for everyone.

[RIKDXHQ11]

Please keep the discussion on topic. You've expressed your personal feelings plenty of times already, but they do not add to the technical discussion of this proposal. Locking the other discussion and marking these comments as off-topic was a hint that this is not a debate that belongs to GitHub and it should be stopped at this point.

Please use tools that are suitable for you. We do not claim that Godot is for everyone.

"Because just as I was about to reply to LikeLakers2, you locked the post. I'm just here to reply to this person, and now I don't want to talk to you anymore.". I will also tell people I know, or our forum, not to use your engine. Thank you. Goodbye.

[CsloudX]

"Because just as I was about to reply to LikeLakers2, you locked the post. I'm just here to reply to this person, and now I don't want to talk to you anymore.". I will also tell people I know, or our forum, not to use your engine. Thank you. Goodbye.

Please wait (https://github.com/godotengine/godot/issues/59241#issuecomment-1384520401).

[tavurth]

(godotengine/godot#59241 (comment)).

That is certainly interesting. I took a look in the issues and github projects but I could not find a specific issue or task which roadmaps this proposal.

In short:

• The current method in GDScript involves converting script tokens to a binary format, which is faster than tokenizing the script but still requires parsing and compiling.
• Intermediate representation (IR) in GDScript stores the script as a file that has already been tokenized, parsed, and compiled, which speeds up loading times and has other benefits such as potentially allowing for a smaller executable and more thorough type-checking.
• The IR code in GDScript is also somewhat obfuscated, making it harder to follow and potentially improving security.

So in current exports the code would look like:

var x = 1

But in the tokenised version the code would look like:

TK_PR_VAR TK_IDENTIFIER("x") TK_OP_EQUAL TK_CONSTANT(1)

Although it may still be possible to recompile that, it seems like some progress on this proposal. 🥳

Does anyone have a link to the specific part of the roadmap?

[SysError99]

As for summary, without the rework of how GDScript gets parsed and stored, we cannot solve the situation entirely.

However, as I looked through (https://github.com/godotengine/godot/issues/59241#issuecomment-1384520401) and I see the potential to extend this proposal even further. We can also make internal mappings of GDScript calls completely incomprehensible by using randomised names or even stack count of possible native calls with shuffled order. This will help on the RE effort as it makes native calls much harder to get traced back to its original name and using tools to automatically restore the source code will no longer be possible. But this method will need significant rework inside Godot building process, and potentially will need additional coding format for Godot to randomise internal callings and generate label mapping table for the editor to recognise and use it to remap calls for production export templates.

I should also mention that this method will only work if Godot users are willing to do a custom compiled version since the official export template will have same set of name bindings. But at least it helps the protection drastically with little to no effort (just do a manual compile and that's all).