Difference between revisions of "Source Obfuscation"
(WIP) |
m (LJ2.1 GC64) |
||
(6 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
There are three general ways to prevent users from straightforwardly accessing source code found within LÖVE distributed games. | There are three general ways to prevent users from straightforwardly accessing source code found within LÖVE distributed games. | ||
− | + | {{notice|If you seek to prevent piracy, please do not consider any of these to be an end all solution. Any form of obfuscation will '''only''' slow down those who seek to reverse engineer your code.}} | |
− | + | {{notice|If you are concerned about people using your code in other projects, do the correct thing and license your code properly instead.}} | |
1) Concatinate the .love file with the love binary. | 1) Concatinate the .love file with the love binary. | ||
Line 21: | Line 21: | ||
</source> | </source> | ||
− | To circumvent this, one could use a | + | To circumvent this, one could use a LuaJIT decompiler such as [https://github.com/bobsayshilol/luajit-decomp luajit-decomp]. |
− | ''Note: while this bytecode will work very well across platforms, it will not work with built versions of LÖVE that do not have LuaJIT.'' | + | ''Note: while this bytecode will work very well across platforms, it will not work with built versions of LÖVE that do not have LuaJIT. Also note that LÖVE currently uses LuaJIT 2.0 and may switch to LuaJIT 2.1 in the future, which is not compatible. To complicate things even more, there's also LuaJIT 2.1 with GC64 used on ARM64 and some x64 architecture, which has incompatible bytecode with LuaJIT 2.1 (let alone 2.0)'' |
If your built version of LÖVE does not use LuaJIT, you can '''destructively''' compile a script like so: | If your built version of LÖVE does not use LuaJIT, you can '''destructively''' compile a script like so: | ||
Line 31: | Line 31: | ||
</source> | </source> | ||
− | To circumvent this, one could use a | + | To circumvent this, one could use a Lua decompiler such as [https://github.com/viruscamp/luadec LuaDec]. |
''Note: this bytecode will only work on your platform (Windows, OSX, Linux) and on that specific architecture ( x86, x86_64, ARM ).'' | ''Note: this bytecode will only work on your platform (Windows, OSX, Linux) and on that specific architecture ( x86, x86_64, ARM ).'' | ||
− | |||
− | |||
Here is a simple script that would create a .love for you that is entirely compiled with LuaJIT. | Here is a simple script that would create a .love for you that is entirely compiled with LuaJIT. | ||
Line 60: | Line 58: | ||
'''While these tools may obfuscate the code, a veteran programmer will be able to reverse engeineer the code similar to those mentioned earlier.''' | '''While these tools may obfuscate the code, a veteran programmer will be able to reverse engeineer the code similar to those mentioned earlier.''' | ||
+ | |||
+ | == Other Languages == | ||
+ | {{i18n|Source Obfuscation}} |
Latest revision as of 02:18, 21 May 2021
There are three general ways to prevent users from straightforwardly accessing source code found within LÖVE distributed games.
If you seek to prevent piracy, please do not consider any of these to be an end all solution. Any form of obfuscation will only slow down those who seek to reverse engineer your code. |
If you are concerned about people using your code in other projects, do the correct thing and license your code properly instead. |
1) Concatinate the .love file with the love binary.
Please see Game_Distribution for advice on how to do this per platform.
To circumvent this, simply treat the concatinated executable as a zip file.
2) Compile Lua source to bytecode.
One can use the a Lua compiler to encode the Lua source code into compiled Lua source code.
Most built versions of LÖVE 0.8.0+ use LuaJIT by default. In the case that they do, you can destructively compile a script like so:
luajit -b main.lua main.lua
To circumvent this, one could use a LuaJIT decompiler such as luajit-decomp.
Note: while this bytecode will work very well across platforms, it will not work with built versions of LÖVE that do not have LuaJIT. Also note that LÖVE currently uses LuaJIT 2.0 and may switch to LuaJIT 2.1 in the future, which is not compatible. To complicate things even more, there's also LuaJIT 2.1 with GC64 used on ARM64 and some x64 architecture, which has incompatible bytecode with LuaJIT 2.1 (let alone 2.0)
If your built version of LÖVE does not use LuaJIT, you can destructively compile a script like so:
luac -o main.lua main.lua
To circumvent this, one could use a Lua decompiler such as LuaDec.
Note: this bytecode will only work on your platform (Windows, OSX, Linux) and on that specific architecture ( x86, x86_64, ARM ).
Here is a simple script that would create a .love for you that is entirely compiled with LuaJIT.
#!/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
3) Use a tool designed for obfusication of Lua source code.
There are many tools available for Lua source obfusication.
http://lua-users.org/wiki/LuaTools
While these tools may obfuscate the code, a veteran programmer will be able to reverse engeineer the code similar to those mentioned earlier.
Other Languages
Dansk –
Deutsch –
English –
Español –
Français –
Indonesia –
Italiano –
Lietuviškai –
Magyar –
Nederlands –
Polski –
Português –
Română –
Slovenský –
Suomi –
Svenska –
Türkçe –
Česky –
Ελληνικά –
Български –
Русский –
Српски –
Українська –
עברית –
ไทย –
日本語 –
正體中文 –
简体中文 –
Tiếng Việt –
한국어
More info