Does a GDscript OBFUSCATOR exist to protect my scripts?

system · May 19, 2019, 5:33pm


	Attention	Topic was automatically imported from the old Question2Answer platform.
	Asked By	dubogo

Hi, im looking into using Godot but the lack of script protection turns me off a bit, i can only see compile to binary or encrypt script option which is very insecure and takes not long to reverse.
An obfuscator would be a real protection but i cannot find anything?
So how do you guys protect your sourcecode?

system · May 19, 2019, 8:15pm


	Reply From:	kidscancode

See the discussion here:

github.com/godotengine/godot

Protect Game Resources

opened 07:23PM - 26 Jun 18 UTC

closed 02:02AM - 30 Jun 18 UTC

domske

archived

**Godot version:** 3.0.4 **OS/device including version:** Windows 10 Perha…ps all supported platforms. **Issue description:** Protect the source code and resources of the game. Currently it's easy to "decompile" / extract all resources including scripts. Update: GD-Scripts are binary in pck-file. But the scenes are stored in plain text and editable. **Steps to reproduce:** e.g. Export as Windows Desktop (exe). Tested with the classic Godot (not mono) You'll get following files: - YourGame.exe - YourGame.pck (package of all resources. Not encrypted.) The same issue may affect all other platforms. Including Android and iOS. All assets and scripts are visible to anyone with a little knowledge of files.

system · March 15, 2022, 6:48pm


	Reply From:	tavurth

See discussion here:

github.com/godotengine/godot-proposals

Obfuscate GDScript in production export

opened 09:56AM - 15 Mar 22 UTC

tavurth

topic:gdscript topic:export

### 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](https://docs.godotengine.org/en/stable/development/compiling/compiling_with_script_encryption_key.html) (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](https://github.com/icsharpcode/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](https://github.com/javascript-obfuscator/javascript-obfuscator) Here is a sample: ```js const my_variable = 5; console.log(my_variable); ``` And obfuscated: ```js 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.