Almost solid gold .blend encryption for game distribution using ccrypt- A Guide

Game Engine Game Engine Resources
1

I have recently started to become more interested in the BGE and it’s potential for small scale commercial projects but as with everybody else I ran into the immediate hurdle of licensing and file protection issues because of blenderplayers’ GNU GPL license. After doing a little research I came across ccrypt and open-source encryption package that uses Rijndael cipher, also used by the US government.

With a little messing around I have come up with a system of encrypting/decrypting and playing your .blends that should be secure for most purposes and maintains the separation between your .blend and blenderplayer necessary to ensure the copyright status of your material. It is not entirely fool proof but could only be broken by someone willing to decompile your .exe file and who also has a working knowledge of ccrypt, for small scale public distribution I think it’s safe enough.

This guide is based on Windows systems, but ccrypt is available for mac, linux and other operating systems and the basic principle should be the same in most cases.

To follow this guide you will need you will need the precompiled Windows ccrypt package available here;

http://ccrypt.sourceforge.net/

and Bat2Exe Converter (also freeware) available here;

http://www.f2ko.de/programs.php?lang=en&pid=b2e

Download and extract both programs to the folders of your choice, open the folder into which you have placed ccrypt and copy these two files into your blender game folder; ccrypt.exe and cygwin1.dll once you have done that we are ready to start.

Firstly we need to encrypt your .blend file, we shall do this with a .bat file. Open up notepad and type

ccrypt -e -K <i>yourpassword</i> <i>your</i>.blend

Save it as a .bat file in your game folder (I will refer to it as encode.bat). Your password can be any combination of letters and numbers, but make sure you note it down otherwise you will not be able to decrypt your file. Also make sure you save a backup of your .blend before encrypting. Now simply open your game folder and run the .bat. After a few seconds you should notice that your .blend is appended with .cpt and is unreadable. Keep the .bat file as we will use it again later.

Next we will create a standard .bat for running your .blend in the standalone blenderplayer so open notepad and type

blenderplayer.exe <i>your</i>.blend

again save this as a .bat in the game folder with the name of your choice (I will call it player.bat).

Now we need to create a .vbs file that will act as the middleman between the de/encryption process and player.bat. So in a new notebook file type this code

Set WshShell = CreateObject("WScript.Shell") 
WshShell.Run chr(34) & "<b>player.bat</b>" & Chr(34), 0
Set WshShell = Nothing

Again saving to your game folder, this time with the extension .vbs I will call mine parse.vbs.

Once that is done we are almost ready to build the unpacker but first we need to convert encode.bat to an exe to hide your password from prying eyes. Use Bat2Exe converter to do this ensuring you select invisible application in the options panel before you compile, your game folder should now contain a file labeled encode.exe.

We are going to write one more .bat file (decode.bat) in notepad that will decrypt your .blend and re encrypt it once blenderplayer has launched.

The first line will decrypt your file:

ccrypt -d -K <i>yourpassword</i> <i>your</i>.blend.cpt

Next we need to give ccrypt a little time to decrypt the file before we try to launch it so we slow our .bat down a little by pinging a none existent IP address:

PING 1.1.1.1 -n 1 -w 10000 &gt;NUL

10000 is the time it should ping in milliseconds (ie 10secs) this could be altered for dealing with large .blends. I was testing with a 10mb .blend and 10 secs was far more than enough.

Next we call parse.vbs which will in turn launch player.bat and load your game, simply type

parse.vbs

Finally we need to re-encrypt your blend so we will call encode.exe

The full script should read:

ccrypt -d -K <i>yourPassword your</i>.blend.cpt

PING 1.1.1.1 -n 1 -w 10000 &gt;NUL 

parse.vbs 

encode.exe

If you save and run this .bat now hopefully you should see your .blend decrypted, blenderplayer launch and your .blend become re-encrypted a few seconds later. The final stage is to again hide your password from prying eyes by converting this .bat to an .exe, again ensuring you select invisible application before compiling. The resulting file will become the main .exe to launch your game, you can delete the encode and decode.bats and can happily bundle your pride and joy in an installer knowing that the integrity of your creative efforts is intact.

I would appreciate any thoughts you might have on this as to it’s relative safety compared to other methods and possibilities for further development.

I am considering automating the .bat creation process with a simple front-end app that would then only require the user to compile the .exe files. What do you think? Feedback appreciated.

Regards

wallacemarino

2

Enhancing Security

As I’ve said there is no way to stop a determined bod who can use ccrypt from breaking the encryption, but there are ways to stop the casual decompiler from gaining your password.

Firstly you can rename ccrypt.exe to whatever you like so that it is not immediately obvious what encryption you are using, it is also possible to call your password from the first line of another (perhaps also encrypted/hidden) file rather than put it directly into your .bat/exe by using -k instead of -K.

I created a notebook file with the password on the first line and some other random text too. I saved this as my own file type so it can’t be immediately opened in anything else (key.wal get it?) encrypted it and made it hidden too. So the decode.bat looked like this;

ccrypt -d -K 1234 key.wal.cpt

ccrypt -d -k key.wal my.blend.cpt

ccrypt -e -K 1234 key.wal

PING 1.1.1.1 -n 1 -w 10000 &gt;NUL 

parse.vbs

encode.exe

and the encode.bat looked like this.

ccrypt -d -K 1234 key.wal.cpt

ccrypt -e -k key.wal my.blend

ccrypt -e -K 1234 key.wal

I doubt anyone who didn’t know ccrypt would be able to figure out the password for my.blend even if they did decompile the .exe.

3

Interesting idea. It seems like you’re really knowledgeable about this encryption stuff - I’m pretty new to the idea. While this seems very safe, it’s a Windows-only approach, correct?

1 Like
4

Actually I don’t know a lot about encryption at all, I figured this out from what I read on the ccrypt site last night and what I knew about writing/running .bat files. The specific instructions I give are for Windows yes, but there are precompiled versions of ccrypt for Linux and Mac too, as long as you are able to write something similar to a .bat file and able to convert that into an .exe style package then it should be pretty easy to port, that’s why I pm’d you as I guessed from your post on my other thread that you are not a windows user and as I don’t have access to/experience with anything other than windows I am unable to test functionality for other platforms myself.

Where I have used a .vbs file to sit between the two bats this could actually be any type of file that is capable of running a command, I only used this one as it has the added advantage of making player.bat’s runtime invisible.

All you need is some kind of file that will run commands, ccrypt and some type of exe style compiler and it should work.

1 Like
5

Not into games myself, but this encryption sh#t is pretty cool. Thanks for the info man.

6

No probs 3dementia, hope it is of some use to you, I’d like to hear any results if you do use it.

7

Wallacemarino, this looks like a good project. However, there are several things that you need to take into consideration:

  1. Is waiting “X” number of ms long enough? What would happen if the processor is busy or old (where it would take much longer than the estimated ms)? Have you taken into consideration the speed of the processor and the speed of the hard drive? You need to remember that all computers are different.

  2. What is stopping the user from copying the decrypted files? (people can still see hidden files).

  3. What would stop the user from replacing the blenderplayer.exe with a “fake” blenderplayer (or even blender itself).

  4. Have you taken into account sandboxes, emulators, injected dlls, and GL interceptors?

  5. Have you taken into account if the hard drive (or application) has restricted write permission.

  6. Encrypting the blenderplayer itself may violate the GPL (as there has been heat around this issue before). However, this case may be an except since you also provide the software to encrypt the blenderplayer.

  7. What is stopping people from using a fake ccrypt installation and stealing the key?

8

@Wallace - C-106 makes good points. To fix the first problem C-106 brought up, you could try checking the update date and time of the decrypted blend file. Once the blend file’s ‘Last Modified’ time is within a reasonable margin (a few seconds) of the current time, you can run the decrypted blend file, as it is now finished.

@C-106 - Nice to see you back here. How’s BPPlayer going?

9

Hi C-106 Delta, thanks for your considered response. I will try to address your questions as best I can.

  1. As I stated at the start of this thread, I am interested in this for small commercial projects, this system would be impractical for .blend files of more than a few hundred megabytes because the time it would take for ccrypt to decrypt the file would result in a poor end-user experience. As I said I tested this on my system with a 10mb file whilst running seven or eight applications and the de/encryption time was one to two seconds, I left the delay at ten seconds specifically to allow headroom for slower systems the biggest .blend I currently have on my computer is around 100mb and that takes around ten seconds to decrypt, so it’s practical to assume a 1 second decrypt time for every 10mb of data as an approximate working figure for my system. It would be up you to test how long it takes to encrypt the file on different systems, allow a decent headroom to account for this and consider these factors when defining your minimum system requirements for your final distribution.

  2. It’s pretty much impossible to stop someone copying a decrypted file once it’s on their system and the file has to be decrypted in order for blenderplayer to run it, the idea of this is to make the time window for possible copying as small as possible. As soon as blenderplayer has loaded your file the re-encryption process starts so the only possible time available to copy the file is what is left of the ping delay once the file has decrypted and the time it takes for blenderplayer to load your game. I would like to be able to eliminate this window altogether but at the minute I can’t see how this would be possible. -Suggestions please? It would also be advisable to make your distribution .blend an autorun so that if it is copied and opened into blender it automatically starts the game engine so the user has no access to the console and exits blender when you when you stop the game engine. This doesn’t stop people appending from your file, but it’s another loop to jump through to get at the material.

  3. Currently I have no work around for this, if the program was killed at the correct time your file would more than likely remain unencrypted. The system I’m looking into (see point 4) may be able to force re-encryption in the event of an early kill but I’m not 100% sure.

  4. Blenderplayer is not part of the encryption process so replacing it would make no difference. I’ve already stated that this system would currently be crackable by someone who knows ccrypt, my thoughts for the next stage of the process are to build an exe that uses a random number generator to automatically change the key every time the exe is run, the file that contains the key information would be encrypted using a different algorithm than ccrypt . (As for blender itself, I dealt with this in question 2.)

  5. No I haven’t really thought about these, as I said in an earlier post I’m not expert at this I’m just looking into solutions for my own purposes and thought I’d share with the community. From what I understand about GL interceptors they would operate on blenderplayer itself not the .blend file as blenderplayer is never encrypted I don’t think it would be possible to account for that with this system. If anybody knows more about these issues I am more than willing to accept suggestions.

  6. I hadn’t considered this, but correct me if I’m wrong with restricted write permissions a user would be unable to save a game either as blenderplayer would need to write to the same folder to create the save. I assume the best workaround would be to advise the user to allow the program the necessary permissions during the install process.

  7. See point 4
    Please feel free to offer comment and suggestions, all ideas/criticisms are appreciated.

10

@Joeman16. That is a good suggestion, I will look into that with the next stage of development. Thanks.

11

@ C-106 Delta I’ve put some more thought into point 2, how would you stop someone copying the decrypted files. As I have discussed once a file is decrypted it is available for copying and the blend has to be decrypted in order to be loaded, therefore the only practical solution I can see is to work with the clipboard itself. In the executable that I am planning for stage two it would be possible to add a looping event, that would write a short text string to the clipboard, perhaps once every second (the words “Don’t steal my blend” might fit the bill.) and would run for the duration of the exe, as the blend is re-encrypted before the exe finishes this should make it practically impossible to copy the blend whilst it is decrypted on the users system. As it is such a small piece of data it should not have any considerable effect on the running speed of the rest of the exe, and as the whole exe runs for such a short period it should not infringe too much on the user. The final operation before the exe closes would be to clear the clipboard data.

Combined with a separately encoded key file I am hoping this might prove sufficiently uncrackable for practical purposes.

Of course I don’t know for sure if this would work without implementing it, but I am mad busy with another project at least until the weekend so I won’t have time to test out these theories until then.

I’d like to know your thoughts.

12

This is awesome, blender game engine ll keep outdated untill we have some decent group working on this games, and nobody does that because they ll have no profit with a game made on blender, the GPL really is something that should be redesigned, if we live on socialism maybe the GPL work out good, but on captalism we are screwed thinking like that. If you have the money you work with payed programs, if you dont have you get screwed up by the GPL. Maybe Im wrong, but this is, on a dramatic way, the way I see.

13

I personally also think that simply retyping the blenderplayer source with a new license could be a community project that wouldn’t be hard at all to do. Once that’s done, all that would need to be done is to submit the new source to the Blender Foundation to include with the Blender source (and build afterwards). That would fix the licensing agreement problem and the security problem.

14

Using the clipboard isn’t a bad idea. However, users (and programs) can still access the clipboard. You need to make sure you clear the clipboard very quickly. In addition, the clipboard only holds a pointer to the file, not the file itself.

Blenderplayer is not part of the encryption process so replacing it would make no difference.

(As for blender itself, I dealt with this in question 2.)
Actually, it does make a difference. Anyone can re-compile the blenderplayer to output the blend file. The same goes for blender. Anyone can compile blender and disable auto-start scripts (this is one of many reasons why auto-start scripts are unreliable). You can also disable auto-start scripts by opening blender first and going to File->Open.

However, I wasn’t only referring to blender and the blenderplayer. “Any” application could be used as a fake blenderplayer. Basically any “fake” application could be used to output the blend file and command line parameters with minimal effort. To fix this problem, you need a system that can tell the difference between a “real” blenderplayer and a “fake” blenderplayer.

Well… there is “middle ground”. It’s basically “open source and non-copyleft” licenses. Some examples include BSD, FreeBSD and MIT licenses. (It might just be me, but) it seems like non-copyleft applications have been increasing rapidly over the last few years.

In order to change the blender’s license, everyone who has ever written code for blender would have to agree on the new license (which is almost impossible). No one can just “retype the license” since it’s not their work.

15

That would be the case if we just asked the authors of the BlenderPlayer to change the license, but the source code isn’t ‘owned’ by anyone, correct? I mean, if someone codes…


// Licensed under GPL
float variable;
variable = 0.1

I would have to ask the author for permission to code this


/// Licensed under Creative Commons
float myvar;
myvar = 0.1;

myself? I mean, I can’t write my own BlenderPlayer? What about if I looked at the original source to see how it worked - would that be alright? (I’m not trying to sound angry or anything - I just don’t really know about licensing issues).

16

@Joeman16, yes you can write your own blenderplayer by all means, but if you want to release it under anything else other than the current GPL license you would have to write an entirely new player using none of the original source code. The conditions in blenderplayers GPL state that you can use, modify and distribute it anyway, but that you must do so under the same license conditions (ie free to use and modify). Everybody who has ever contributed code to the blenderplayer did so on these conditions, so as C-106 Delta says you would have to get the permission of every contributer in order to change the license if you used any of the original source code.

17

@C 106 Delta

Let me make clear what I am trying to achieve here. Until we get a new more permissively licensed blenderplayer then blender games are never going to be completely secure, but then when you think about it what game is? At the minute, because of the licensing issues of blenderplayer, we can’t commercially release a runtime which means your .blend has to be supplied directly.

As soon as we have seperated the .blend from the player we are already covered by copyright laws, what is in the .blend is our property encrypting shouldn’t even be necessary, but for the majority of people developing blender projects that is a bit too much of a risk and feels inherently unsafe. A lot of major games developers leave their source material un-encrypted and available with the distribution package safe in the knowledge they can prosecute under copyright law. What I am looking for here is a middleground where blender developers planning small scale distributions, who likely can’t afford legal fees for copyright challenges can do so feeling that their material is relatively safe, not an absolutely platinum level security system.

With that I would like to go back to point 6 of your original questions, encrypting blenderplayer itself. You mentioned some problems with this issue before but suggested this case might be exempt due to supplying the encryption software itself, can you point me in the direction of more discussion on this matter?

As blenderplayer.exe is relatively small, what if I were to supply two copies of blenderplayer with a distribution? One unencrypted and offering source code availability and the other encrypted, for use by the game itself I will not have modified the source in anyway, just encrypted and possibly renamed it. If i can encrypt the player then I can add a lot of control to how the game is opened ensuring that it couldn’t be replaced by a fake version of the player. Of course the encrypted .blend and blenderplayer would still be packed and initiated separately.

18

What if I don’t release my source files with my compiled game?

19

Josip, are you referring to a game compiled as a runtime? If so that is the problem we are trying to work around. If you compile your game as a runtime it is packaged with blenderplayer and so comes under th umbrella of blenderplayer’s GPL meaning you have to make your source material both available and modifiable in order to distribute it.

Compiling game together with blenderplayer = your game is open source, free, modifiable, redistributable.

If you don’t compile your game you are then faced with the problems we are dealing with above.

20

This is a serious problem. I have a few ways on my mind how to bend the rules if I can.
If I have to make the source available, do I have to distribute it with the game?
If not, then I can make the source available on my web site for registered users who have bought the game.

One other thing. There is a few web plugins that can play blender games, are they covered with this licence?

Edit:
Do I have to give source files of my compiled python scripts?