2

I wrote the following code in the file "orgin.lua"

if test==nil then
    print(aa["bb"]["cc"])  -- to produce a crash
end
print(1120)

when it crash ,it will generate the following information:

lua: origin.lua:3: attempt to index global 'aa' (a nil value)

In order to prevent decompilation and make sure the code is safe,I use the following command to convert my code:

luac -o -s test.lua origin.lua

I know the argument -s is strip debug information, then it do not show the number of rows when crash:

lua: ?:0: attempt to index global 'aa' (a nil value)

but how to bring debugging information when encryption then lua code use luac?Is there any solution?

user7733855
  • 59
  • 3

2 Answers2

1

There is no way to do this built into Lua, but there are some work-arounds.

If you only need line numbers, then one option is to leave the line numbers in the chunk. Line numbers are not that useful for reverse engineering (unluac currently doesn't use them at all), so it shouldn't affect security. Lua doesn't provide an option for this, but it is easy to modify Lua to leave them in when stripping. From ldump.c

n = (D->strip) ? 0 : f->sizelineinfo;

can be changed to

n = f->sizelineinfo;

(Disclaimer: untested)

A more complicated option would be to modify the Lua runtime to output the virtual machine program counter instead of the line number, and also output information describing the location of the current function in the chunk (e.g. top level, first function, second function nested in third function, etc). Then the line number could be looked up by the developer in a non-stripped version of the chunk. (Here is a reference to someone using this approach on lua-l -- no source code was provided, though.)

Note that preventing decompilation is not true security. It may help against casual attacks, but Lua bytecode is not hard to read.

tehtmi
  • 676
  • 4
  • 7
-1

luac does not encrypt the output. It compiles your Lua source code to bytecode, that's all. The code is neither encrypted nor does it run any faster, only the loadtime is shorter since the compilation step is not needed.

If you want your code to be encrypted, I suggest to encrypt the bytecode using e.g. AES-256 and then decode it in memory just before handing it to the Lua state. This way the bytecode is encrypted on disk, but decripted in memory.

The overhead is low. We use this technique since years.

Marc Balmer
  • 1,780
  • 1
  • 11
  • 18
  • 1
    Encrypting isn't a bad idea, but still isn't really secure if the attacker is in control of the host environment. (The decrypted chunk can be dumped from memory or the host program can be reverse engineered to find the encryption key.) If the encrypted chunk is not stripped, then it will be easier to decompile if and when the attacker gains access. Unlike encryption, stripping is not reversible. – tehtmi Feb 11 '18 at 17:15
  • We are aware that this form of encryption is not 100% secure, but at least is prevents from tampering with the files on disk. – Marc Balmer Feb 12 '18 at 09:38
  • @MarcBalmer No it doesn't. It's trivial to steal the key and then encrypt whatever modified files you want with it. – Joseph Sible-Reinstate Monica May 30 '20 at 16:51