Encryption of source

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
u9_
Citizen
Posts: 54
Joined: Thu Oct 23, 2008 7:12 am

Encryption of source

Post by u9_ » Tue Nov 18, 2008 8:34 am

@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?

User avatar
rude
Administrator
Posts: 1051
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Encryption of source

Post by rude » Tue Nov 18, 2008 11:36 am

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. :D

User avatar
Merkoth
Party member
Posts: 186
Joined: Mon Feb 04, 2008 11:43 pm
Location: Buenos Aires, Argentina

Re: Encryption of source

Post by Merkoth » Tue Nov 18, 2008 2:47 pm

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 :P

User avatar
rude
Administrator
Posts: 1051
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Encryption of source

Post by rude » Tue Nov 18, 2008 3:51 pm

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. :3

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

u9_
Citizen
Posts: 54
Joined: Thu Oct 23, 2008 7:12 am

Re: Encryption of source

Post by u9_ » Tue Nov 18, 2008 4:30 pm

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 ;)

User avatar
Merkoth
Party member
Posts: 186
Joined: Mon Feb 04, 2008 11:43 pm
Location: Buenos Aires, Argentina

Re: Encryption of source

Post by Merkoth » Tue Nov 18, 2008 6:33 pm

rude wrote: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. :3

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 :shock:

User avatar
mike
Administrator
Posts: 364
Joined: Mon Feb 04, 2008 5:24 pm

Re: Encryption of source

Post by mike » Tue Nov 18, 2008 10:58 pm

u9_ wrote: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.
Now posting IN STEREO (where available)

Post Reply

Who is online

Users browsing this forum: Google [Bot], master both and 5 guests