hello everyone, I am just starting with Castle Game Engine and Pascal!
A new language I am willing to learn 
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 
EDIT: Windows 10 64bit
Thank you.
Hello there! (Moved your post to new topic 
)
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.
thank you for your answer 
do you know if there is something like this in the planning?
That shouldnât stop me from exploring Castle Engine 
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
Note that CGE isnât here very different than other engines 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.
Thank you for your answer
The framework I am currently using has obfuscation 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 
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).
Best.
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:
Can you encrypt PCK files? - Archive - Godot Forum ,
Current versions of the engine donât have this option; it was recently added to the unstable (and eventually the 4.0 version) of the engine. Please bear in mind that users can still dig through the binary, extract the encryption key, decrypt the PCK file, and search for whatever they want (though this will be more difficult).
https://github.com/godotengine/godot/issues/19790 ,
Protect Game Resources ¡ Issue #19790 ¡ godotengine/godot ¡ GitHub says:
Do other game engines have any built-it âassets protectionâ? Nop, Unity and Unreal forums are full of the similar âProtect game resourcesâ topics, with the exactly same answer: âitâs pointlessâ. (And asset stores are full of third-party snake-oil tools).
That said, I of course donât want to reject this idea just based on the grounds that others donât have it I understand the desire to obfuscate your data.
So this approach would do the trick:
( 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 I can also imagine implementing it at some point at CGE level.
thank you michalis, it is not urgent for now, I was just asking 
I am far from finishing a project using Castle Engine so maybe when I am ready to release this feature will be available
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
Player.Gun.Shoot;
DisplayMessage('Shots have been fired!');
PlaySound('machine_gun');
to
z.p.k;s(q('U2hvdHMgaGF2ZSBiZWVuIGZpcmVkIQ=='));c(q('J21hY2hpbmVfZ3VuJw=='));
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 
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 
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
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âŚ