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;
and Bat2Exe Converter (also freeware) available here;
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
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 126.96.36.199 -n 1 -w 10000 >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
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 188.8.131.52 -n 1 -w 10000 >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.