BGE proposal: game data encryption

Issue:
Currently .blend files offer little to no support to protect data from being extracted. While this might support the open source idea, it is not very supportive to technically protect copyrighted content.

To see the world as it is, it is easy to violate a licence when the obstacles or not noticeable. A lot of people ignore it or do not even think about what is legally allowed and what not. Some technical protection can help that people can’t excuse with “I just took it” - as they have to spend some effort.

My suggestion:
Create blend files with encrypted data (or parts of it) e.g. with an AddOn.
It should be possible to create encrypted files from all linked .blends to allow larger games.

Decrypt the data when loading from file:

  • at game start/scene load
  • when loading linked data from other (encrypted) blends
  • when using LibLoad
  • no encryption when loading into Blender

Benefits:

  • more protection than it is now
  • the source can be GPL and therefore integrated into the BGE sources
  • the encrypted code is used immediately (no encrypted file at any time)
  • the key can be delivered separately or included in the distribution
  • distribution of multiple encrypted files is possible
  • the GPL does not apply to the data

Drawbacks:

  • Someone could write an addon to decrypt the data and create unprotected .blends or loads the content into Blender. But the user needs to explicitly get and use this tool = he wants to violate the protection.
  • At one point the data needs to be decrypted - otherwise the BGE can’t use it

Workaround:
BBPlayer, Burster, SolarLunes decryption script.

Remarks:
Some protection is better than no protection.

Encryption via Add-on would separate encryption/decryption from Blender.
When decryption is in the BGE only, there is no need to touch the Blender source

Creating a game specific data format might increase the protection. The BGE converts some Blender data anyway. So why not encrypt the converted data? This way the BGE does not even need to convert that much and the data is not usable in Blender itself. But this is another topic.

As a very simple implementation: .blend data is zipped. Why not use the zip encryption ;)?

I think “.blend” files are ok the way they are concerning intelectual property savety. Noone outside of the blender community will know how to open a blend file and since blender doesn’t care about the file extensions you could just rename your “data.blend” into “data.dat” or whatever.
Protecting images, sounds/music etc. on the other hand woud be more important, I’d say.

@monster,

In the good old days there was a Lock blend feature what happend to that? That was easier in use i guess.

I like the zip encryption.

Everyone thinks they have something worth protecting …

^ My thoughts exactly. Where are the widely enough distributed BGE games? Where are the infringements?

That could be a nice idea if you want to protect your game assets. You could easily write a script that zips up your assets into a data file with a password and renames the zip (to something like .dat). When your game starts, you can unzip it. When the game’s finished, it can delete that folder. Not ideal, but it’d work.

Goran / Kheetor - Logically, it’s best not to wait until you have something worth protecting to try to find a way to protect it. However, I do agree that it doesn’t really matter in the long run - it’s trivial to grab pretty much any asset from a game. Models from console games can be found online, music rips, sounds, sprites - it’s not really worth it to protect them all just to keep people out.

My though is, such a change is not that complicated and I guess it would be accepted in an official build.

I say not, because a lot of people distribute their finished games as windows exe’s. I, and anyone else on mac and linux, can’t play them. The only way I can currently play said games is … by extracting them. While I understand some peoples security concerns, the ability to actually play the game is, to me, more important.

BBPlayer works on Windows, Linux and Mac and has been developed for years. To me, it doesn’t make sense to try to replicate the work that DeltaSpeeds has already done.

Having the developers for the engine working on the encryption would allow for further encryption only for specific parts of the .blend file (as monster mentioned), frequent updates (would work with every subsequent version of Blender and BlenderPlayer) and a faster workflow not having to use an external program to do something.

Another improvement to the system that could be made by the developers is to encrypt external assets too, such as textures and sounds, or linked .blends (including libLoad functionality), because packing all of your data into one .blend is mayhem for your hard drive and RAM.

This could also prohibit using a different BlenderPlayer with the game .blend, which could result in many different errors, glitches etc.

In addition to this, multi-platform exporting should be added.

I’m 100% toward this proposal.

I still don’t understand the benefit in what’s being suggested.

BPPlayer doesn’t have any of the drawbacks of the suggestion. You can also include assets in your .block file and pick your own compiled Blenderplayer. It’ll stop any other modified Blenderplayers from trying to use your content. You can also link to other .block files.

If you’re distributing your game then external programs will always be part of your work flow. Converting your .blend into .block is trivially easy compared to setting up the installer.

I’m guessing you’d use symmetric key encryption, which now leaves the problem of having to hide a key somewhere that people cannot find it. But, if an open source program is hiding the key for you, I can just read the source code and grab the key. Adding encryption features to the BGE is actually non-trivial, and I think generally seen as not worth the effort. Why spend development resources on trying to protect assets when any protection scheme can be circumvented?

It would seem the only true way to have a “secure” game, is a subscription, and data offsite that the player needs, and or services,

This proposal is less about the application file even when it might benefit a little bit too. The application file already applies this kind of protection (yes you can extract the blend file and therefore the assets). You need to explicitly spend this effort, rather than just open it with Blender.

The other problem with the application file is, that you have to licence your assets with GPL. With that you can’t forbid to extract the data, you even have to provide the original .blend file if requested (I doubt that anyone ever did that). A lot of game creator do not want to use this licence for their assets.

The proposal is to add an obstacle onto the .blend files itself (similar to the BBPlayer) but still getting the option to distribute multiple files and to licence at the copyright holder’s wish.

The benefit of the BBPlayer is, it is closed source and makes the obstacle to decode the file pretty high. But I do not know if you can use it with linked files. So I guess this is a asset file solution again.

Yes, I’m aware of this. This will fit into the “obstacle” design. It is not simple to get around, but not that easy as it is right now.
The other option is to distribute the key separate.

For this approach symmetric key is sufficient enough. I was thinking if asymmetric keys might help. They would help to authenticate the originator (like a CSC). This could even be used to create watermarks. But this is a different topic.

At any point the decryption has to take place, so asymmetric or symmetric would not matter. If the key is distributed separately does not matter that much either.

I guess the above mentioned “lock flag” [I did not know there is such a thing] is a similar obstacle and surely simpler to implement.

The encryption/decryption itself should not be that hard. There should libraries out there (i do not know if they are GPL compatible). Even Python can do zip-encryption.

I guess the most effort needs to be spend at the UI.

Btw. this is just an idea. I do not have any specific project that needs that or is worth to be protected more than a written letter.
It is nice to see the different thoughts on that.

I don’t see the logic.

You don’t even know if you’re going to need a protection mechanism, but even if you were somehow certain (let’s assume that you can guarantee a finished product, at a certain level of quality), you don’t know the optimal protection method until there’s a complete product to analyze, because “how best to protect something” depends heavily on what you’re actually trying to protect (code, assets, some network token?).

You need the finished product to make the best decisions.

But even if there was a perfect method, it’s probably not in your best interest to use it: Every mod, every spinoff, every piece of silly derivative art will ultimately link back to your IP. It’s like free advertising, keeping your brand relevant.

I would be more interested in methods to make our games more accessible, not less.

It’s still not as fast as it should be, and you can’t encrypt parts of your source .blend. Also, packing data into a single file causes some performance issues – why load all of the textures if only one is needed?

I think that a way to counter that could be to add an md5 hashcode to the .blend or any of its specific data, then only those with the passcode can view it. The blenderplayer could contain this key to open the .blend (making sure that the blenderplayer is unable to be extracted without the hashcode too).

Yes, I’m aware of this. This will fit into the “obstacle” design. It is not simple to get around, but not that easy as it is right now.
The other option is to distribute the key separate.

It stops being an obstacle after the first person has broken it and released an easy method. A good example would be that script for separating the blenderplayer from the blend file in EXEs.

If someone wanted to properly protect their assets, they can do it with several methods:

  • Online server
  • BPPlayer
  • Core functionality in .pyc files

I suspect the majority of the users of this suggested encryption will be new developers that will tick the box because they like the idea of it, then when they get stuck they’ll upload an unusable blend to the community when they ask for help. Then ether the user will have to be guided through turning the option off, or all the people that help on this forum will end up making/distributing tools for by-passing the encryption.

what about a UUID for each blender user?

(don’t kill me)

Like you have to register your blender player to get it to work?

like steam?

The logic is that it would be folly to wait until you need something to see if or how it could be supported. It’s like going into game development knowing you want to make Android games, and then choosing the BGE. You’d do better learning an engine that supports Android as a platform.

In the same way, if you start a project thinking that there will be some way to protect your assets from users and complete the entire thing, only to find out there isn’t such a mechanism in place, you could feel like you wasted your time (if that’s something you needed). Note that for clarity, I’d pretty much be talking about mainly .blend files, which would hold, at least, your meshes, animations, and levels.

Again, not saying it’s something that needs to be done, but it’s best to think about it for the whole community than on a case-by-case basis later (where no community-wide need may be visualized, even if the whole community does want it).

As for spin-offs / mods / etc. supporting it, yeah, sure, more talk about your game’s good. However, there’s also the very real possibility of someone grabbing your stuff and using it for their own game. This is especially possible for .blend files where everything’s there - the animations, the rigs, the meshes. It’s all set up and ready to be appended into another project. But then again, it doesn’t really matter because whatever process you use will be cracked in the end (see below).

@TheDave - I’m pretty sure an easy solution to that proposed problem would be to simply rename modified blend files to be something that new users wouldn’t think are blend files. That way, they wouldn’t upload unusable files.

@sdfgeoff - Moguri added a one-click exporter to all platforms add-on, so there should be cross-platform compatibility for all BGE games, essentially (assuming that one picks out any bugs they find).

@BPR - I think that’d be a bit much to ensure it works (cost-wise, at least).


No matter what the approach, it’s going to get cracked, so I’m not sure it’s worth it in the end. If something is done, I’d probably just ask for another BGE-specific format that just contains BGE data (and so can’t be opened by Blender). That would probably also be non-trivial, though, so ionno.