How to Protect a Resulting .Exe?

[Puzzlem00n]

Okay, I don't really need to know this, but it's something I think I'd like to know in the future if it comes up. It says here on the wiki for game distribution:

2. The resulting executable from the merge will still be readable by archiving software, such as WinZip.

How could one post-process it so that the executable is not readable? I've looked around the internet, but I can't seem to find anything. Can anyone help me out?

[Adamantos]

... you could use a runtime compressor for your .exe-File.

Something like
http://upx.sourceforge.net/

[Puzzlem00n]

Thanks, but that doesn't exactly work. It seems I'd need to make sure the package can reference the required .dlls, which I'm not sure you can do.

Does anyone have any alternate solutions?

[TechnoCat]

http://stackoverflow.com/a/6888667/1185957
Have fun spending all your time futilely protecting your code.

[slime]

There is no perfect solution, not even for commercial games that use other languages. One way is to use luac to precompile your lua files, but compiled lua files are not compatible between architectures and Lua versions, so you have to be careful. Plus, regular compiled lua can easily be decompiled.
In most cases, hiding code is not worth the effort, especially because almost no one's code is worth anything on its own. Note that there is a difference between having an open-source license and having visible code - you can have visible code while still having a restrictive license that legally prevents people from using it wholesale.

[TechnoCat]

Note that there is a difference between having an open-source license and having visible code - you can have visible code while still having a restrictive license that legally prevents people from using it wholesale.

To drive this home, it is like buying a book. The contents are clearly viewable. An obfuscated book would be retarded. However, it is illegal to copy the contents of the book.

[Robin]

Like TechnoCat said.

If you can read a book, you can copy the words as well, there's nothing a publisher can do about that technical possibility.
If you can run a program, you can copy the functionality as well, there's nothing a publisher can do about that technical possibility.

Or, the other way around: if WinZip can't take a look at how your game works, neither can LÖVE.

[iemfi]

http://stackoverflow.com/a/6888667/1185957
Have fun spending all your time futilely protecting your code.

This link seems to go against everything which has been said in this thread (the second answer from stackoverflow especially). While it may be impossible to protect it 100% it seems easy enough to protect a program sufficiently to ensure that it would be easier to start from scratch than to try to decipher it. Whether one should do it or if it's worth the trouble is a completely different question IMO.

[josefnpat]

http://stackoverflow.com/a/6888667/1185957
Have fun spending all your time futilely protecting your code.

I love this post, but also see how for small time developers, it would be crazy to implement this.

[bartbes]

Java has similar problems, and they use obfuscation that basically changes all variable and function names so if you do manage to decompile it, it is quite hard to read. Though this works reasonably well, of course it isn't perfect (see minecraft).

The fundamental problem you come across when 'protecting' is that it has to be a) executable and b) decodable. Especially b is important, this means that for every lock, you need to ship its key too, the computer has to read it, after all.