Source code protection

[adnzzzzZ]

Alright, so after doing the luajit thing I got a luajit decompiler and tried it out.
I have some new questions:

1) This pretty much offers no protection as far as I'm concerned. Is the luajit method the only and best one available?

2) Assuming the answer to 1 is true, what are other techniques that can be used to make the steps to achieving a file like the one that that decompiler used harder? Now, I imagine that at this point describing things in terms of steps isn't possible anymore, so I'm happy with high level descriptions of the various techniques used.

For more complicated code it does a better job of obfuscating what is being done. Give the decompiler a more realistic example.

For example, this is the decompiled bytecode for a very simple example:

At this point, people messing with the game will actually have to be persistent.

Good point, I'll try with a bigger and more complicated example.

[ivan]

LÖVE is built to make both open-source and closed-source games. Putting that on the front page would be really misleading! It is true that it's easier to make a closed-but-easily-viewable-source game than a closed-and-hidden-source game using LÖVE though.

I think that closed source is not a bad thing - it's just unnecessary with games.
With games, the worst thing that could happen is somebody tampering with your highscores (not a big threat compared to business/web applications).
I used to think that compiling the Lua code would make this less likely but to be honest, if your code is well written then security shouldn't be a problem even for open source games.
So ya, nowadays the only reason why I compile my Lua code is so that people won't laugh at how bad my programming is.

[ejmr]

I think that closed source is not a bad thing - it's just unnecessary with games.
With games, the worst thing that could happen is somebody tampering with your highscores

I politely disagree with you that it’s unnecessary. Not all games need to bother having closed-off source code, but I wouldn’t want to write a networked, multiplayer game where malicious players could trivially cause problems for everyone.

[kikito]

Ok how about putting this text on the front page then:

Any software-based source code hiding, including compiling the Lua source, can be undone by a dedicated programmer in less than 1 hour. This is due to how LÖVE games are built. It's possible to make closed-source games with LÖVE, but if you don't want others to read your game's source code you should rely on a license file.

[adrix89]

Open source is a license.

Just because the source is visible doe not mean its open.

If all you worry about is someone stealing your code for their own commercial projects slap a GPL or CC-NC license and they will avoid it like the plague.

If you worry about someone redistributing your game you can separate the assets from the code so that the assets they have to buy or they will violate copyright even if the code is open.
The campaigns, maps, sprites and data would be copyrighted so not be able to be redistributed.
This will help customers can easily mod your game without legal issues and distribute the modifications while still being a paid game.

If you are really paranoid make a secret function that you can use to prove it is your code stolen.

Also compiling as a method of obfuscation is good enough, it is not a problem of the game being modifiable, its is a problem of your source being understandable. Outside of DRM and even that all games are modifiable to some extent.

[slime]

Ok how about putting this text on the front page then:

Any software-based source code hiding, including compiling the Lua source, can be undone by a dedicated programmer in less than 1 hour. This is due to how LÖVE games are built. It's possible to make closed-source games with LÖVE, but if you don't want others to read your game's source code you should rely on a license file.

I don't think that sends the right message to new users, and it's not specific to LÖVE or Lua anyway. Compiled C# and Java code (and code from many other languages) can be decompiled in the same manner as well – Unity and XNA both use C#, so even games like Hearthstone have the same "issue."

[adrix89]

IF someone really wants DRM you could have the game encrypted and have a DRM DLL and a key to unlock it.
The DLL would have its own launcher separate from the love.exe
It would be decrypted directly into RAM so not as easy to get.

Someone could probably make something like this.

[adnzzzzZ]

IF someone really wants DRM you could have the game encrypted and have a DRM DLL and a key to unlock it.
The DLL would have its own launcher separate from the love.exe
It would be decrypted directly into RAM so not as easy to get.

Someone could probably make something like this.

Could you expand on this?

Also it's nice to see that everyone just ignores my request to keep this thread on topic anyways. I've created a new thread where you can go and discuss issues unrelated to this thread: http://www.love2d.org/forums/viewtopic.php?f=3&t=79356

[josefnpat]

This has been an interesting thread to say the least.

There has been a lot of information compiled into this thread, so I went and took the liberty of creating a wiki page for it.

https://www.love2d.org/wiki/Source_Obfuscation

Keep in mind I have tried to be as objective in the writing of this page, and welcome any cleanup.

As a sidenote, I think linking this page on the "Game Distribution" page would help answer a lot of questions future lovers may have.

[szensk]

It should also note that if future versions of Love use LuaJIT 2.1, then the compiled versions for LuaJIT 2.0 won't work. Or at least there is no guarantee it will work.

from LuaJIT's website:

The generated bytecode is portable and can be loaded on any architecture that LuaJIT supports, independent of word size or endianess. However the bytecode compatibility versions must match. Bytecode stays compatible for dot releases (x.y.0 → x.y.1), but may change with major or minor releases (2.0 → 2.1) or between any beta release. Foreign bytecode (e.g. from Lua 5.1) is incompatible and cannot be loaded.