Encryption in Construct 2

Okay, so right now I'm gonna cover what I think is an important topic; Encryption of your files. This topic was requested by glerikud and a few other people on the Construct 3 official thread

Before I start I want to be clear: I could not care less about protecting my assets from being stolen. If I make a successful game, I would LOVE to see people modding it or reusing part of it to make fan games or games using some of its mechanics as long as they don't make money out of it without my permission.

We discussed it on the C3 Official Thread with newt Eisenhans and X3M — Bleenx and a few other people

Construct 2 suffers a big problem, assets are absolutely not protected in the exported product.

Just to illustrate how big of a problem this has become.. the following quote is taken right from the steam community forum of a (relatively) known C2 game published there:

[quote:2dfy6lzy]"How to get the soundtrack for free + view sound clips/sprites/sheets.

Go to the directory of your folder and open "package.nw" with winrar. Then extract it to a custom folder and you are done. Save yourself 5 bucks, only if you want to.

You can probably customize the game and put it back as a nw file"

The main question is: Do Construct (2 or 3) really need to feature some sort of DRM or encryption?

Ashley and newt defended that it would add a lot of loading time to your game without even preventing people to steal your assets.

I personally think that loading time isn't a problem if most of the important assets are decrypted on start. Plus decrypting times on images will clearly not be as huge as decrypting an audio file. And most people are concerned about protecting their visual content. Plus many people don't really care if loading times are increased if their assets are protected:

I don't really care if loading times slow down if I can protect my assets from the majority of the users.

Talking about protection, YES it's not perfect and YES you will always be able to steal data by some dark mean BUT:

1) It won't be as easy as unzipping a rar file, so most of auto proclaimed 12 year old hacker won't be able to do much

2) Yes people will always be able to take screenshots and record audio in order to steal data, but again, it will be much harder

3) If they manage to crack encryption, then it means that they worked quite a bit to get there, and at this point, just let them take some of your assets as a reward of their time spent stealing them, and if they ever use them in a manner you don't like, just strike them. They'd have spent several hours to steal assets to get blocked in the end. Most people would give up at this point.

It is NOT useless as Newt and Ashley tend to say and even if it's far from perfect it's still like having a wall instead of a sheet of paper protecting you and your assets.

Newt made an interesting point about how it was necessary to get a new editor in order to have that encryption feature:

[quote:2dfy6lzy]I would point out that one of the reasons why we needed a new editor was to make it easier to add things like asset protection.

[quote:2dfy6lzy]Secondly the engine would have to be altered to decrypt them every time, on top of load time. As I said the C2 editor made the first part complicated.

[quote:2dfy6lzy]Then as to the issues with the C2 editor, just remember the issues we had getting additional features to tilemaps.

To which I replied that no, we didn't need one because RPG Maker MV a software running on OpenGL (like Construct) and exporting HTML5 games (like Construct) on NW.js for desktop builds (like Construct) featured encryption as part of their 1.3 update:

[quote:2dfy6lzy]

RPG Maker 1.3 Update! [...]

You can now Encrypt your games, both images AND audio using a simple encryption built into the Engine!

The only editor-side add that is needed is literally adding a checkbox with encrypt audio and encrypt images as well as having a textbox where we can enter an ecrypt key.

This is how RPG Maker MV did it:

This where it could be added in C2:

I'm pretty sure C2 can handle this change

So. This topic is open for you to discuss this. Please don't repeat yourselves and try to build actually good arguments in order to have a good respectful discussion.

Okay, I would like to start this discussion short and eventually it will get longer overtime...

As a start, I'm very sure not all agree to this so making this feature optional would be fair for both sides.

But if performance loss / loading time is very significant, I don't think we have any need for this feature.

Talking about protection, YES it's not perfect and YES you will always be able to steal data by some dark mean BUT:

1) It won't be as easy as unzipping a rar file, so most of auto proclaimed 12 year old hacker won't be able to do much

2) Yes people will always be able to take screenshots and record audio in order to steal data, but again, it will be much harder

3) If they manage to crack encryption, then it means that they worked quite a bit to get there, and at this point, just let them take some of your assets as a reward of their time spent stealing them, and if they ever use them in a manner you don't like, just strike them. They'd have spent several hours to steal assets to get blocked in the end. Most people would give up at this point.

Lets not forget #4:

4) If the Pro Hacker finally finds a way to decipher the encryption, everything is already pointless. Like the C2 community, there are also

hacking communities. It means that 12 year old hacker wannabes can finally show off what they learned on youtube.com.

This feature is debatable but not very compelling.

My main concern is if you have something like a 400mb project, it could take maybe 30 seconds to decrypt everything. Firstly, is that a trade-off you're happy to make? Secondly since it's decrypted in RAM, tools can still take your content from there. So you could end up with a significant performance decrease, and no meaningful protection - the worst of both worlds.

I'd also point out that your code is already pretty well protected if you minify it.

[quote:myxou902]As a start, I'm very sure not all agree to this so making this feature optional would be fair for both sides.

Yeah ofc

[quote:myxou902]It means that 12 year old hacker wannabes can finally show off what they learned on youtube.com.

No actually. If you add an encryption key then the process wil have to be repeated for each new game and each build of said game if it uses a different encryption key

[quote:myxou902]it could take maybe 30 seconds to decrypt everything. Firstly, is that a trade-off you're happy to make?

30 seconds is merely nothing for adventure games or some arcade games that keep you for hours. So people may say that yes, they would be happy to make that trade-off.

[quote:myxou902]since it's decrypted in RAM, tools can still take your content from there

Yeah, again. But it's still harder to extract than just decompressing files. It offers a slight protection.

[quote:myxou902]So you could end up with a significant performance decrease, and no meaningful protection - the worst of both worlds.

This is why it should be optionnal and let the dev decide wether he wants to use it and try for himself if the trade-off it worth or not.

[quote:myxou902]I'd also point out that your code is already pretty well protected if you minify it.

This is clearly not a problem as even if people consider minifying as not a protection because it just removes useless spaces and returns, they can always obfuscate their code using some free online tool that will clearly make it even harder to reverse engineer https://www.javascriptobfuscator.com/

skymen

1- For js files inside the .nw package:

There is a solution called v8 snapshot which could be added to C2 : https://github.com/nwjs/nw.js/wiki/Prot ... 8-snapshot

But it comes with some drawbacks such as noticeable performance decrease in your game.

2- For image assets:

You can load base64 images instead of importing files.

3- For sound files:

Same, using base64 sounds can solve the issue.

And all 2 and 3 would be encrypted since they reside inside the c2runtime.js file which will become c2runtime.bin

But again, performance issues cannot be overlooked.

skymen Thank you for creating this topic.

I understand that not every developer need this feature, so making it optional is a good idea. Personally what bothers me now about the lack of encryption is that every user can unzip the assets if they realize that they just need to rename a file. Of course no encryption is unbreakable, but I don't think that should be the goal here. I'd be satisfied with some simple method to prevent the everyday PC user to unzip the assets.

[quote:ut51dsqp]I'd also point out that your code is already pretty well protected if you minify it.

This is clearly not a problem as even if people consider minifying as not a protection because it just removes useless spaces and returns, they can always obfuscate their code using some free online tool that will clearly make it even harder to reverse engineer

I guess the name isn't clear: enabling "minify script" uses Google Closure Compiler in advanced mode, which also does very thorough obfuscation. Even if you "beautify" it to try to make it readable, it's still very difficult to work with. So C2 already does this.

1- For js files inside the .nw package:

There is a solution called v8 snapshot which could be added to C2 : https://github.com/nwjs/nw.js/wiki/Prot ... 8-snapshot

But it comes with some drawbacks such as noticeable performance decrease in your game.

2- For image assets:

You can load base64 images instead of importing files.

3- For sound files:

Same, using base64 sounds can solve the issue.

And all 2 and 3 would be encrypted since they reside inside the c2runtime.js file which will become c2runtime.bin

But again, performance issues cannot be overlooked.

Concerning code, yes Ashley already addressed this and it's clearly not a problem.

Concerning base64 images I use that in my current rogue like game in dev. Mainly because it allows me to develop a 3rd party tool using construct that will make it easier to add characters and weapons, and also because I don't really care about loading time as they're already pretty long due to the Rogue like generation mechanics ^^.

I guess the name isn't clear: enabling "minify script" uses Google Closure Compiler in advanced mode, which also does very thorough obfuscation. Even if you "beautify" it to try to make it readable, it's still very difficult to work with. So C2 already does this.

I didn't know that. Thank you for clearing that out <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Base64 is interesting, but it increases the size on disk considerably.

Another thing to consider for sound is that we can now generate it in in browser, and that means we don't have to rely on pre generated files.

It does mean we need more ways/ tools to create something for game use.

Base64 is interesting, but it increases the size on disk considerably.

Yeah unless someone finds a way to make some sort of data compressor. But that'd add to the loading time too I guess

Another thing to consider for sound is that we can now generate it in in browser, and that means we don't have to rely on pre generated files.

It does mean we need more ways/ tools to create something for game use.

Oh yeah! That'd be sick tbh. Well, something that would really be sick af is if it were possible to retrieve sound files from bfxr, chiptone or even jukedeck! Ashley I'd love to hear you on this one, cause if this is possible then it would add a lot of sound deepness into a game even if it reduces its sound identity. That'd be a very good trade-off for fast paced arcade games or survival games where sounds and/or music are not the main focus. I can Imagine a game distantly generating a music file from Jukedeck and upload it to a server every now and then, and then would retrieve random files from said server. This would mean infinite modular original soundtrack.

There's third party plugs already for generation, including one that uses the Sfxr code base.

We just need editors to work with them better. In C3 hopefully.

I need to say that the generation does come at a cost to cpu usage, but it should be quite useful in moderation.

Yeah. We can always generate a few sounds at start or when a specific action is done and store and repeat the generated soud for that action. So you have a new set of sounds on each new game

Base64 is not encryption. It's just a different format for the same data. Using Base64 is like swapping PNG for JPEG, it offers no protection at all, and only works if someone knows how to extract one format but not the other, which seems unlikely.

Base64 is also a text-based format so uses more space on disk and more memory too. So given how some people are worried about their games taking too much memory, that also seems like a bad tradeoff to make.

I wouldn't bee to concerned about your content being stolen. If it's copyrighted material, you could always wave the big lawsuit flag at the perpetrators and I'd imagine that most of them would just drop the assets and go steal them from someone else.

Base64 is not encryption. It's just a different format for the same data. Using Base64 is like swapping PNG for JPEG, it offers no protection at all, and only works if someone knows how to extract one format but not the other, which seems unlikely.

Base64 is also a text-based format so uses more space on disk and more memory too. So given how some people are worried about their games taking too much memory, that also seems like a bad tradeoff to make.

Yeah, you're totally right, but it's hidden in the code or in JSON files, so harder for anyone to look into it and to change back.

Also, I think the main use of this would be as I said to make 3rd party editors as there is no way to load animations and images from external files in C2 (tell me if I'm wrong tho)

I wouldn't bee to concerned about your content being stolen. If it's copyrighted material, you could always wave the big lawsuit flag at the perpetrators and I'd imagine that most of them would just drop the assets and go steal them from someone else.

Yeah, but most of the time people don't really care, because, either they did not pay attention to your warning, or they know you're not rich enough to actually open a lawsuit against him.