Source code protection

[adnzzzzZ]

From my limited knowledge of how computers work, I know that when you write a C program for example and you compile it, the returned executable has assembly instructions that the computer can execute to do what you told it to do. This executable can be disassembled and people can read this disassembled code to try to understand what were the instructions you originally told the computer to do, but they can't get the source code back as you wrote it.

So my very simple questions are these:

1) Is there a way for code written in LÖVE to have a similar level of protection as the one I just described for C programs?

If there is, then 1.a) What are the steps necessary to achieve this? Please describe these steps as clearly as possible assuming I'm a 5 year old, like, as easily as it is described here https://www.love2d.org/wiki/Game_Distribution possibly.

And if there is no way to do that, then 1.b) What is the closest you can get and what are the steps necessary for that?

Also, please refrain from asking me why I want to protect my source code, or trying to tell me why I shouldn't want to do it, or trying to educate me about the benefits of open sourcing code. This is not the thread for that. This thread is for discussion and reaching of conclusions regarding questions 1, 1.a and 1.b.

[Jasoco]

Well you can kind of protect the source, but it then makes it not cross-platform so you'd have to compile it for each system. As far as I'm aware that is.

It depends, is your code really that special that you need to protect it?

There was that incident with Oysi and his 3D engine that he didn't want to share because of previous code theft which is understandable, but if you really want to keep your code away from prying eyes, why not learn and use something else? I dunno. Lua and Löve are meant to be easy. It's free. And it can do lots of things. But if you want a big time game engine with secure code, there's other options. Though they always have outrageous prices. (I'm looking at you, Unity. God dangit. If you want to put your game on everything you will be spending a crapload of money every year for licensing.) Though not all are expensive. You could put games on iOS for $99 and have the benefit of also supporting OS X. But that leaves out Windows, Linux and Android. You could use Microsoft's equivalent, but then again it only supports their side of the fence and leaves out everyone else, i.e. every single popular mobile platform, but at least supports the popular desktop OS.

Then again it's all real code. Lua is scripting really. If you really want, you can consider Löve more of a prototyping platform. Like Flash. A lot of big games start as Flash and become so popular that they get recoded bigger and better in a "real" programming language for major release.

I'm just rambling. It's Christmas.

[adnzzzzZ]

Well you can kind of protect the source, but it then makes it not cross-platform so you'd have to compile it for each system. As far as I'm aware that is.

What are the steps necessary to do this? Also, please everyone else stay on topic. This is not the thread to question why someone wants to do this. It's simply to come to a conclusion of: "can LÖVE do this, if so how? If not, then what's the closest you can get?"

[Robin]

1. Run luac (bundled with the Lua interpreter your LÖVE is linked to) on your game files
2. Proceed as normal, using your compiled files instead of the source files for the .love.
3. Profit?

I've never done this, for reasons that are apparently off-topic, but I think that should be enough.

(If you do this and it means your game won't run on my computer, I reserve the right to call you a very silly person and ignore your game completely.)

[slime]

1. Run luac (bundled with the Lua interpreter your LÖVE is linked to) on your game files

One minor adjustment: LÖVE uses LuaJIT by default, so you should get a LuaJIT interpreter executable and use luajit -b rather than luac.
LuaJIT's bytecode is also portable between different architectures (unlike regular Lua's bytecode), so you only need to do it once to support all platforms.

[rok]

So to completely protect it one'd have to run luajit -b on each and every .lua file and everything should link as expected?

[josefnpat]

Compiling your code is trivial. I will quickly show you:

I wrote this simple script quickly:

Code: Select all

#!/bin/sh
# usage: ./bytecode-love.sh <source directory>
WD=`pwd` # determine working directory
TEMP=`mktemp -d` # create a temporary directory
cp -Rv $1/* $TEMP # copy your source code to temp
cd $TEMP # move to temp
for file in $(find . -iname "*.lua") ; do # for each lua file recursively
  luajit -b ${file} ${file} # compile the code with luajit onto itself
done
zip -r $WD/$1-linux-`arch`.love * # zip the result up
rm -rf $TEMP # cleanup

And here it is in action:

Code: Select all

~/repos♠ ./bytecode-ize.sh healthcolor
‘healthcolor/healthcolor.lua’ -> ‘/tmp/tmp.4UyZ3AagUq/healthcolor.lua’
‘healthcolor/main.lua’ -> ‘/tmp/tmp.4UyZ3AagUq/main.lua’
File found: ./healthcolor.lua
File found: ./main.lua
  adding: healthcolor.lua (deflated 23%)
  adding: main.lua (deflated 31%)

This gives me a running .love. See attached .love for the output.

But here are the caveats:
1) [strike]This .love will only work on the target system (in my case, 64 bit linux installs). Go head non-64-bit-linux users. Download it and cry.[/strike]

LuaJIT's bytecode is also portable between different architectures (unlike regular Lua's bytecode), so you only need to do it once to support all platforms.

TIL? At the end of the day, this is LuaJIT, and not Lua5.1. More caveats?
2) To create a .love for each operating system, you will most likely have to run and test it on each target distribution.
3) While no one can read it, you won't get any help debugging and less testing or trying it out, especially from this community. More on this in a second.
4) You are not saving any significant amount of space, and in all technicality you are making it larger.

Code: Select all

-rw-rw-r-- 1 seppi seppi 763 Dec 25 14:35 healthcolor-linux-x86_64.love
-rw-rw-r-- 1 seppi seppi 587 Dec 25 14:46 healthcolor.love

In this instance you are going out of your way to make it harder to give you feedback (suggestions, bugfixes, balance changes, etc). While many of us are video gamers, we are all programmers that know how to code, and have a great interest in how things work. Here are the responses you can expect when you do post a precompiled love here:
A) Can you release a version for my OS?
B) Can you give us a an unencrypted version so we can help you?
C) <sarcasm> **FLAME FLAME FLAME** </sarcasm>

I don't want to speak on behalf of the love community, but I'd like to think we're a respectable bunch that understands the value of a software license. By compiling the .love you are saying that you don't trust us in that regard, and you have no interest in giving back to the community. While you may not be interested in the free and open spirit of the lzip/libpng that LOVE has been released under, most of us are very much interested in this.

When it comes to video game development, if you have a good enough idea for someone to rip off, they're going to do it no matter what. Compiling your source code is not going to stop anyone. If you seriously can't think of any examples, please ask and I'm sure that many of the forum posters here will be able to provide you with examples.

In conclusion, I want to say that compiling your source into bytecode is trivial for any moderate programmer, but the cons heavily outweigh the pros in this community specifically.

[slime]

1) This .love will only work on the target system (in my case, 64 bit linux installs).
2) To create a .love for each operating system, you will most likely have to run and test it on each target distribution.

Again, LuaJIT's bytecode is platform-independent, as long as LÖVE is using LuaJIT 2. Your test code runs fine in OS X for me (and it will run fine in Windows as well, with LÖVE 0.9).

By compiling the .love you are saying that you don't trust us in that regard, and you have no interest in giving back to the community. While you may not be interested in the free and open spirit of the lzip/libpng that LOVE has been released under, most of us are very much interested in this.

Having your source code "visible" in some way to the user doesn't mean it has an open-source license. In most countries, the creator of the code has full copyright ownership of it (i.e. you as a user have no rights to distribute or use it in other manners) if no explicit license is specified.

Obviously if you want help tracking down bugs or improving your code then compiling it to bytecode doesn't help, but it's generally better than alternative obfuscation methods. Error messages will still be pretty sane for bytecode-compiled code.

[kikito]

I think that, given the structure of LÖVE "programs" (basically, a zip file with Lua inside) the options are actually a bit limited "by design".

The easiest "barrier" is also the easiest one to bypass: you merge the zip with the source code with an exe. That will deter only the most casual of the hackers.

The second "barrier" has already been mentioned before: you use luajit to compile the Lua. This is a bit of a chore, since you have to do it once per env (i think) and you lose feedback info. I have never done so, but I remember that it was possible to decompile it. LuaJIT decompilers do exist, that is a fact. I don't know what you get exactly (maybe the variable names are lost). But don't think that once you go through all those hoops you are "safe".

A third "barrier" that people do is uglifying the code so that it is "deuglified" before it is run. This of course has the issue that in order to be able to execute the code you must add the "key" to "decode" the source code, so anyone who knows Lua and is motivated will be able to bypass that in less than 1 hour.

So even if you combine all the previous techniques, you are looking at investing days of dev time (especially if you plan to do more than 1 release) for something that any dedicated Lua programmer will be able to crack in 2 hours tops.

Another option, probably outside of reach for people who are into this kind of thing, is modifying the LÖVE C/C++ source code so that it is not "a zip file with Lua inside" any more. Even if you do that, it's still possible to extract the Lua source code from the executable in some occasions (this was done recently in another thread).

My conclusion is: this is a huge waste of time. All the "safety" measures available are easily overridable and/or have important drawbacks. It's investing days of your time when a hacker's time will be measured in hours or minutes. Put the zip file to scare the script kiddiez, and a legal doc to scare away the rest. And if that is not enough for you, consider not using LÖVE.

that the notion that LÖVE can't protect your source code at all keeps a lot of people away from using it

I am attracted to opensource, and want to learn from and share with others with it. If suddenly lots of closed-source projects started cropping up, I would certainly leave LÖVE. That's because openness is one of LÖVE's selling points for me. Based in what I have read in other posts, I think I am not the only one; some other people would leave LÖVE if it was "more closed".

I propose that we put the following on front page: LÖVE is built to make open-source games. If you want to make closed-source games, you might want to look elsewhere. If more "how to make closed-source LÖVE game" forum posts appear, we just point them to the front page. That would solve the issues these people have.

If someone discards LÖVE because of this, that's a sacrifice I am willing to make. I am not saying "sacrifice" with irony here; I think we might lose valuable people. I just think we would gain other valuable people in exchange. I think people who have strong feelings about hiding source code have enough other options to chose from, so it would not be a super great loss for them either.

I also want to stress that these opinions are only mine and I don't represent the LÖVE core devs; I am just a user.

[ejmr]

I have no suggestion to add which other members have not already described. But I simply want to point out an obversation that when I see these threads so many people dismiss hiding/obfuscating code because it’s not hard for programmers to get around. But few gamers are programmers, and whenever I see these discussions I feel like we forget that.