Encryption of source

[u9_]

@rude, I did a forum search, but couldn't find anything, so i thought i'd ask. I am sure you have already thought about this, but will there ever be any possibility to encrypt ones source code in case one wants to release a commercial game?

I can imagine there are a few problems: Source code for love available, license of love cannot be changed, or you would have to obtain commercial license for all libraries love is built on, etc. etc. I can imagine there are lots of problems.

What's the status on this? Do you see this as impossible or is it feasible?

[rude]

I have not done extensive research in this area. At least not on the technical side.

I have, however, made sure that you can use LÖVE commericially without any license pain. LÖVE is licensed under ZLIB/PNG, which means that you may create modified closed-source versions as you see fit. Moreover, the libraries used by LÖVE are carefully chosen so that you do not need to think about obtaining commercial licenses. There are two limitations only:

1. You may not create a modified version of LÖVE and claim that it is the original. (This is imposed by ZLIB/PNG).
2. You must use LGPL-licensed libraries in DLL/SO/MYLIB-form. Right now, that includes SDL, SDL_mixer and DevIL. (Imposed by LGPL).

As for encryption: that would be great, but not practically possible with the .love-files alone. Also, I don't know how encryption algorithms work for games. Can anyone tell how the "serial key" relates to the encryption key? With some superhax-use of DLL's, it's probably possible to realize some encryption scheme without recompiling LÖVE too.

Please do come forth with suggestions. I'll share my idea first, which does not take serial keys into account. One could encrypt all game files and create a special module (using liblove) which provides an implementation of love::File. This module has the encryption key built-in, so it knows how to decrypt the files.

Code: Select all

require("haxfs.dll")

-- A love::File should be returned. I'll have to create a tutorial
-- one day on how to do this.
file = haxfs.newFile("bgmusic")

-- Love will accept the object where applicable.
music = love.audio.newMusic(file)

Of course, one could very easily get access to the decrypted files like this:

Code: Select all

require("haxfs.dll")
require("evil.dll")

-- A love::File should be returned. I'll have to create a tutorial
-- one day on how to do this.
file = haxfs.newFile("bgmusic")

-- Love will accept the object where applicable.
music = love.audio.newMusic(file)

-- Saves decrypted file.
evil.save(file)

... which I do not see a way around without recompiling. If recompiling is acceptable, then we have more options. You could embed the encryption mechanism (and key) directly into the exe, and use a custom encrypted setup script instead of main.lua.

Either way, people will eventually hack their way into your game and get your files no matter what we do, but this may be able to stop 99% of those nosy people.

[Merkoth]

If the only thing you want to encryot is your sourcecode, you can always use Luac from any Lua distribution. Your source will be safe from anyone but those insane enough to learn the Lua's VM bytecode

[rude]

Yeah, maybe that's good enough, or at least better than nothing. Perhaps we should add native AES support for love.filesystem, and then people can store the key in the compiled main.lua. Which reminds me that LÖVE must also be able to look for main.luac if main.lua isn't there.

Some hardcore haxoors will probably be able figure out the key pretty easily, though. It's not exactly bulletproof.

[u9_]

Good news on the license issues

I was basically thinking of the source code only. As long as it is not just right-clicking "open with winzip" and you have the entire source code, then i'm happy There will always be piracy, but the important thing is keeping all your source code safe in case you want to release a sequel

[Merkoth]

Yeah, maybe that's good enough, or at least better than nothing. Perhaps we should add native AES support for love.filesystem, and then people can store the key in the compiled main.lua. Which reminds me that LÖVE must also be able to look for main.luac if main.lua isn't there.

Some hardcore haxoors will probably be able figure out the key pretty easily, though. It's not exactly bulletproof.

I could swear I released a "compiled" version of Zoomer and that it worked fine with .luc

[mike]

There will always be piracy, but the important thing is keeping all your source code safe in case you want to release a sequel

As an avid pirate I would like to point out the distinction between stealing somebody else's work to pass it off as your own and just stealing other people's work.