Encryption in Construct 2

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.

True, but your content has to be pretty top notch to have even the slightest chance of being stolen anyway. Just saying.

True, but your content has to be pretty top notch to have even the slightest chance of being stolen anyway. Just saying.

True, and The next Penelope is a good exemple. As it did happen that someone stole assets from the game

Here's a little game that decided to leave all its assets out in the open.

http://www.darkestdungeon.com/

So far it sold about 1.1 million copies I think?

I was part of this conversation in the C3 thread as well. A major concern of mine in regards to not being able to encrypt one's assets is that sometimes assets from a third party are licensed under the condition that the developer takes the appropriate steps to protect those assets by encrypting them.

This is done in order to protect the developer from legal litigation by said third party. Simply stated: plausible deniability. You as the developer took steps to protect the assets, and when someone hacks that encryption, you cannot be held legally responsible.

I came upon this at the GraphicsRiver asset foundry in their extended license:

[quote:2s9rz8if]11. You must not permit an end user of the End Product to extract the Item and use it separately from the End Product.

https://graphicriver.net/licenses/terms/extended

I read this, and in my opinion unencrypted assets potentially break this requirement. Tom's opinion is that as long as a Terms and Conditions statement (txt file) accompanies your game, you should be fine.

Definition of "Permit": officially allow (someone) to do something.

So in my understanding of this, as long as you do not give official permission for them to take the assets you're good. Put in your T&C something along the lines of "You are not permitted to extract and use any assets in this game for any purpose". I can see how this might be interpreted in the way you say though, but doubt that's the spirit of it because it's impossible to enforce imo.

Probably best to check with Envato though of course. If you don't want to clarify that with them, let me know and I can send them an email if it's a big concern for you.

* This is my opinion, IANAL etc.

So I contacted Envato (owners of GraphicsRiver) and today Envato Market Help got back to me:

[quote:2s9rz8if]

Thanks for taking the time to thoroughly research the terms of our license usage. Many people buy the assets without caring. That being said, you should be fine with an extended license but adding the statement on what is not allowed is wise. I can see how GraphicRiver assets would commonly be distributed in other items but that should cover you legally, if needed. The buyer would then be essentially doing what we ask of our buyers in our disclosures.

Go forth and prosper!

Kind Regards,

Now, the part that worries me once again is the "you should be fine" and "should cover you legally" parts. "should" will not hold up in the worst legal scenario.

Of course, it is a very slim chance that someone will care about all this, I agree. But let's just assume someone develops a game in Construct 2/3 that becomes incredibly successful, and sells tens of millions of copies. The game uses a number of assets from GraphicsRiver. The designer of those assets notices this, and downloads/installs the game on a Windows machine, and discovers that his/her assets are unencrypted, and anyone can have access to them by merely unzipping them. The designer (US based) is aware of point (11) of the extended license, and decides to take legal action against the game developer in the US.

Even though the developer included a T&C, I could imagine that US copyright lawyers shred it to pieces because of the fact the plaintiff's assets were not encrypted at all and left out in the open, because in my view (11) implies that the developer must take appropriate steps to help protect the plaintiff's assets, and a case could possibly made by high-flying lawyers that the defendant failed to do so.

I am aware that it is highly unlikely and doubtful that such a situation may occur, but the point I am making is simple: if Construct allows for a simple asset encryption option during export, the game developer won't have to run any such risk at all in the first place.

All the other game engines allow the user to encrypt their files. Yes, assets can be hacked/ripped anyway, yet I think it is a fundamental option to have anyway. At least provide the option to do so.

There's third party plugs you can use to do that already.

Convert your assets to base64, encode them with one of the encoder plugs, add the encrypted text files to the project files.

Load by url already converts the decrypted base64 images, and there's even an audio plug to play base64 audio(haven't tried it in a while however).

Theres also an audio stream plug which has pros, and cons.

If it really is a big issue for you then you can continue down the third party path for easier methods.

In other words there are options beyond relying on Scirra.

Edit:

Supposedly C3 was to make it easier to work with the sdk, and roll our own plugs.

Of course no way to know if that's part of the free version.

There's third party plugs you can use to do that already.

Convert your assets to base64, encode them with one of the encoder plugs, add the encrypted text files to the project files.

Load by url already converts the decrypted base64 images, and there's even an audio plug to play base64 audio(haven't tried it in a while however).

Theres also an audio stream plug which has pros, and cons.

If it really is a big issue for you then you can continue down the third party path for easier methods.

In other words there are options beyond relying on Scirra.

Edit:

Supposedly C3 was to make it easier to work with the sdk, and roll our own plugs.

Of course no way to know if that's part of the free version.

I am not sure whether "load image by URL" works with NW.js exported applications. Aside from this, it would be way too much of a hassle to deal with hundreds of assets this way.

Switching to an alternative is indeed the best solution in this case.

I think Rex has plug for that too.

http://c2rexplugins.weebly.com/rex_spri ... oader.html

The hard part would be making sure you had an existing blank frame for each image.

Something you would do without encryption anyway.

I think the argument for an external spite type would be the thing to look for here.

After some emailing back and forth regarding the actual legal stance related to GraphicsRiver's license and unencrypted assets in released (Windows) desktop games, I asked for a definitive legal answer rather than "should be fine", and I have been moved up to level 3 support - to their legal department! Seems the situation is not as clear cut as it seems to be.

The plot thickens... I'll keep you informed - might take a couple of days.

So I was thinking about this some more, and I guess something we could do with hopefully minimal performance impact is something simple like XOR encrypt the project name over the content of all asset files. If it's reversed at the point of loading hopefully there won't be too much delay (although this remains to be seen), and it stops you "just opening" any asset files.

The thing is this is basically homeopathy for security. It is not remotely secure in any meaningful way. XOR encryption is the type of thing treated as a joke by professionals (but it's quick and simple, which is the main reason I consider it). But - if you find the file you can't immediately open it until you figure out how to at least run the reverse XOR process. So this will function well enough to stop people idly browsing around your assets. But it won't pose much of a barrier to anyone with common technical skills. We could choose some really tough encryption, but then crackers will fall back to other tactics like scraping from RAM while your game startup time needlessly suffers.

My main objection is what does this really solve? I feel like people want to tick a box on a checklist that says "encryption" and get a warm fuzzy feeling that their work is at last safe, but that is not at all the case, even with some supposedly strong encryption. If someone wants to rip your music and sell it online, they can find a way. By far the more effective way to counter this is copyright law.

We're also a small team and I'm keen to spend time where it matters. Lots of people want exciting new features like modularity in events. I want to do that a lot more than I want to sit around fine-tuning the performance of a placebo algorithm.

So, is this really what people want? Do you really think this will make a material difference to anything?

I'd be more worried about protecting the whole game.

The only measure we have now is involves various ways of checking urls.

So, is this really what people want? Do you really think this will make a material difference to anything?

If it's quick and simple to do I think it would be a good idea to add, if for nothing else than to put people's minds at ease.

On a related note, I'd actually like to see an option to make build code less obfuscated, so end-users can mod it more easily.

what if let say in stead of naming the player "PlayerObj" can we name it the same name as the game ID like "com.wizdigitech.jamwheel" so when some one is try to decode it give him hell when they search and see more than one Game ID make it harder for the to know which is the correct one to change. i am planing to do that

change all my asset and variable names to the plugins name, game id etc

seen we cant encrypt it then make it a pain in hacker ass when they trying to decode it looool wish Ashley would do that with C3 instead of you know what already

change all my asset and variable names to the plugins name, game id etc

Most of that information - such as all object and variable names - is stripped out from exported projects. So going through your projects renaming things is a waste of time, because all that information is removed.

Also if you enable "minify script", the resulting obfuscation is pretty strong protection against anybody reverse-engineering the logic of your project.

Anyways, this is pretty confusing and I can't seem to pin down what people want. There's discussion of obfuscating the project data - which is already done pretty strongly on export! - or even asking for less obfuscation (you can turn off "minify script" if you want but that doesn't make your project easy to mod).

What exactly are people after here? I'm not going to start writing a feature until I have a clear answer that makes sense about what people want and why.

Instead of decrypting/encrypting, how about just inserting watermark over each and every sprite sheet during export? Then, when game is launched, C2/3 hides that watermark. This way, every asset is at least copyrighted to the author of that game. Also hacker(s)/cracker(s) has to at least do some clean up to be able to use those assets.

Of course this method can't be used for music and sound :/ Maybe an extra channel of noise is inserted in music file(s) on export? So if someone unzips music from game, those music pieces would be complete garbage. Then, after game launch, that noise channel is muted and music plays normally. Just an idea, dunno would it work at all.

This is my idea for this encryption/decryption topic. I don't know are my suggestions easy to implement in C2/3 but they are something to think of. Personally, I'm more interested of copyright issue than covering my assets because I do know that every game assets/GFX/music/sound etc can be ripped of from game. For example, every (or at least close to every) GFX/music piece from NES games are ripped of. People will find a way to hack your game, like it or not.

-M-

What exactly are people after here? I'm not going to start writing a feature until I have a clear answer that makes sense about what people want and why.

My understanding is Rayek, Eisenhans and maybe others are concerned about legal hassles with 3rd parties if their assets are exposed, and that even a modicum of protection would cover C2 users legally. Me, I'm not interested in encryption at all so you can disregard my earlier post.