BGE Security - You know you can protect your standalone, right?

Hey. I was talking with some members here on BlenderArtists, saga and Moguri, and I was surprised at the amount that can be done to bypass the GPL licensing on the BlenderPlayer to account for a more secure, non open-source method of distribution for games created with the BGE.

For a long time now, I (and others, I’m sure) thought that the GPL licensing preventing games from being sold, as the GPL licensing on the BlenderPlayer would make it possible for end users to ask for your source code, and you would have to give it to them. If you chose not to include the blend file in the executable, then it’s less secure.

We found that it’s actually fairly easy to both bypass the GPL and have a fairly complex method of security. For example, you could use an external compiled Python file to encrypt and decrypt the external blend file - when you want to play it, you call the decryption function on the blend file, and once it’s loaded, you re-encrypt the file. It’s actually not that complex or difficult.

Saga also had another idea that was pretty good, though I’ll leave it to him to explain it. Basically, the GPL licensing isn’t really a problem anymore - you just have to be inventive.

Just decrypt the file into RAM and get rid of it after you’ve given the blend file to the BGE. There is no need to re-encrypt since you left the original encrypted version intact. However, this can still be broken, but it takes a much more dedicated person. Still, it only takes one person to write a script and distribute the script.

That’s true, but that’s the problem with encryption and security as a whole - no matter how powerful the encryption is, once it’s cracked, the program is ‘up for grabs’. It may take days of pure coding to crack encryption, but once it’s done and either the cracking script or the cracked program is distributed, any remaining security is pretty much worthless. Of course, things like copyrights also protect programs’ source codes from being distributed.

Anywho, you make a good point about just decrypting the file into RAM (that’s easy), and then pass it into the BGE - how would you get the BGE to load a file that isn’t stored on the hard-drive? The Game actuator and startGame() functions both take paths, not pointers to file objects.

EDIT: Do you mean write a temporary file somewhere and get the BGE to read that, and then delete that file? That could work, though I don’t like to write and delete new files from hard-drives - it might make some users un-easy.

I use LibLoad for most of my BGE work these days, and it allows you to pass in the blend data directly instead of giving it a file.

Really? I didn’t know that. I’ll have to look into it. Thanks for that info. The BGE’s actually more secure than I thought, then. There’s definitely room for commercial usage with the BGE.

It’s Dynamic Loading…it’s an awesome feature. I, myself have found great use of it. It can save your day too…
i think i might resume my small projects with dynamic loading for tests.
Once again thanks Moguri for sharing great info. and your amazing works.