Obfuscation of code and assets

hello everyone, I am just starting with Castle Game Engine and Pascal!
A new language I am willing to learn :sweat_smile:
I have one question before diving deeper with the engine (I have followed the documentation code to start with).
So the question is: when I built the sample code I could access all my datas (gfx, sounds, …), aren’t they obfuscated? Same question for the code, anyone can see the code?
I may have tons of other questions coming :upside_down_face:

EDIT: Windows 10 64bit

Thank you.

Hello there! (Moved your post to new topic :slight_smile: )

No the data is not obfuscated. And while I believe there are no ready solutions to do that “automatically on all the assets” you can do that manually though. E.g. you can use BlowFish encryption on all XML assets, and i believe you can archive some assets into password-protected zip files.

The code on the other hand gets “compiled” so the original source is not available unless you publish it youself, e.g. on GitHub or as a separate package. However, as all compiled code it can be still reverse-engineered, but it’s hard so unless you’re developing something extremely expensive you shouldn’t be worried about that.

1 Like

thank you for your answer :slightly_smiling_face:
do you know if there is something like this in the planning?

That shouldn’t stop me from exploring Castle Engine :thinking: :slightly_smiling_face:

Are you asking about obfuscation of assets?

We don’t plan immediately to provide something like this, rather we give you tools to do it on your side – you can register a custom URL protocol, to read data in any way you like (including e.g. decrypt them using BlowFish) and use this system for all of your data. See castle-engine/examples/network/custom_url_handler at master · castle-engine/castle-engine · GitHub . In principle, the simplest would be to provide data as an encrypted zip file.

We could provide an example extending castle-engine/examples/network/custom_url_handler at master · castle-engine/castle-engine · GitHub to use BlowFish, if needed :slight_smile:

Note that CGE isn’t here very different than other engines :slight_smile: Other engines (e.g. Unity) also don’t put any special effort to obfuscate your data. Many engines pack your game data into separate file – but that’s just packed using well-known (or well-reverse-engineered) format, so users who want to “dive” into game data are free to do so. In our case, “Package” operation on a project packs it into zip, both the compiled exe and the data.

1 Like

Thank you for your answer :slightly_smiling_face:
The framework I am currently using has obfuscation :upside_down_face: when I export my game I have: “Encrypt asset files” and “Encrypt code files”.
I used godot a long time ago which has a .pck file which seems to encrypt the data(?) and I barely used unity so cannot really tell(?).

Imho users having access to my assets is not so cool :grimacing:
The compiled code is harder to reverse so this is good.

I am going to have a look at your links but it will take some time to digest as I am new to Pascal.

Looking forward to using Castle Engine (I installed the plugins for VSCode because Lazarus was so different from what I am used to).


As for Godot:

Note that Godot PCK is just an archive format, you can unpack it with e.g. GitHub - hhyyrylainen/GodotPckTool: Standalone tool for extracting and creating Godot .pck files .

Though I see they played with encryption, though also various comments point out it’s not critical:

That said, I of course don’t want to reject this idea just based on the grounds that others don’t have it :slight_smile: I understand the desire to obfuscate your data.

So this approach would do the trick:

  1. at release time, automatically encrypt all data (all the files in data/) with BlowFish
  2. when running in release mode, install URL handler (like in castle-engine/examples/network/custom_url_handler at master · castle-engine/castle-engine · GitHub ), that effectively reads the file from disk, decrypts (using a decryption key stored in exe) in memory, and serves a decrypted file.

( Note that I mention BlowFish just because it is trivial to use. There are other encryption algorithms available of course, they would play the role nicely too. )

If this is critical feature for you but you’re not sure how to exactly implement 1 or 2, let me know – we can help :slight_smile: I can also imagine implementing it at some point at CGE level.

1 Like

thank you michalis, it is not urgent for now, I was just asking :stuck_out_tongue:
I am far from finishing a project using Castle Engine :sweat_smile: so maybe when I am ready to release this feature will be available :slightly_smiling_face:

Thank you for your help, really appreciated.

Looking forward to play with Castle Engine and Pascal.

EDIT: imho assets shouldn’t be exposed to regular players? (only those who really want can crack anything using tools available on the web)

This comes late. There are 3rd party libraries that let you use a file as a container for a filesystem that only your application would know how to open. That would provide a level of obfuscation if you don’t want people spoiling surprises by looking at assets. I believe those offer encryption too… though why take such a performance hit! No asset is that valuable to hurt your performance. You would have to look into this. Delphi and Object Pascal are full dev systems you can do anything with. Michalis can’t do it ALL even though he seems to!

I also think he would not want to.

Real encryption with hardware key like Sentinel HASP can not be uploaded to GitHub.

And obfuscation like Godot would not really worth that much, ESPECIALLY if made in the open-source library. People would just make the unpacker using the CGE itself, just like the game does.

So, i think, since CGE seems already supporting ZIP format, then AES-encrypted (password-protected) ZIP should already do. or 7Z, or RAR,…

Obfuscation is one-way trip. It converts code from

DisplayMessage('Shots have been fired!');



There are even by far more elaborate obfuscation algorithms that instead of just replacing meaningful variables names and sometimes even keywords with random strings alsu use RTTI instead to de-obfuscate the execution code run-time, killing the performance in the process, but making sure that deobfuscation is even harder.

Knowing the encryption algorithm doesn’t help either, because it requires a decryption key, that’s the whole point of cryptography :smiley: Of course the decryption key can be reverse engineered from the executable. But definitely that will prevent 99.9% of users from peeking into game assets. And will make a lot of antiviruses very upset 'cause they wanna peek too :wink:

But I understand why some people may want that. Especially if some assets licenses come with demand to apply DRM over them.

Some game engines (like GDevelop) simply use… an obscure archive format, like asar. Of course you can unpack it with 7zip or some other advanced archiver, but will keep like 80-90% of curious dummies away.

…and then there are deobfuscators, automatic or even interactive like IDA Pro.

Byt the queston specifically was about obfuscation of assets. not of the code!

But definitely that will prevent 99.9% of users from peeking

…as long as the game is not popular. Otherwise there would be modding forums with HOWTOs and readymade tools.

Also, for every game with a good soundtrack there are torrents and rapidshares with the ripped OST. So much about DRM…

That said, there were casual phone games SDK where obfuscation was prependiong some fixed header and then XORing the reso of the file with a single, fixed byte value. Woulf you personally thing implementing such an obfuscation in CGE would be rewarding for you?..

On the other pole would be implementing something like DVD CSS, much more complex… and in the long run not that much more secure.

So, i think CGE already puts the asset to .zip? and modern .zip have strong AES encryption, so that is all it would take for an obfuscation i guess: just make that zip “password-protected”.

…ok, on a second look, it is ZLib, not Zip. Still the same, one can XOR the streams either before or after ZLib, and get the obfuscation level of the aforementioned SDK.

Obviously, it would be better but harder to XOR things in between CGE and ZLib, and it would be easier to implement and to deobfuscate to XOR things in between ZLib and disk.

Now, we just have to wait for someone who would consider such a task inspiring :slight_smile:

A questionable idea, actually, as it would defeat the ZLib

In one business app i found prior devs decided to apply some Blowfish or something to SQL update packs. And they made some ad hoc formats, tha provided extension points where no one needed them, but it totally gave no way to insert any layer between crypto and executor.

Double points scored by the fact, the exercution app was also the encryptor, so the devs were sure the update package would always been read - there was no formal tests, but since both encryptor and decrypto was one app, any compilation minutiae would probably symmetrically apply to both parts.

Learn’t this when i had to make some very redundant code, like 50K INSERT statements. Zip would handle them perfectly, yet there was no way to add it without breaking compatibility. And after encruption, of course, there was no entropy for packers to harvest…