Re: Is there any plan to make luajit support bytecode?

[Peter Cawley <lua@...>]

On Fri, Apr 15, 2011 at 12:50 PM, Axel Kittenberger <axkibe@gmail.com> wrote:
>> Good point, at least I can quickly find one disasm for Lua 5.2 - ChunkSpy.
>> I guess rolling your own package loader that uses some cryptography is good way to go.
>
> Pah, its all in your head. encrypting this is pretty futile, since you
> have to give "the enemy" a decrypter with the product.
>
> And what is "the enemy" actually? A player that wants to hack a god
> mode into a game? Its not that it is so difficult to do otherwise,
> even on pure assembled C code. Take a look at "CheatEngine" and
> various tutorials online how to use it.
>
> Is the "the enemy" the competition? Exactly those sure know how to
> call a decompiler, or how to find the decryption code in your C code,
> and apply it.
>
> No, if you want byte code support, you need to argue with:
> * size on harddisc
> * loadding time
> * portability with lua tools creating bytecode
>
> Never this encryption "arms race":
>
> Take a look at:
>
> http://permalink.gmane.org/gmane.comp.lang.lua.general/77118
>
> To see Mike Palls hate against the obfustication / deobfustication "arms race".

In this context, the aim is not to make it impossible to recover some
kind of source, but to make it reasonably difficult to recover some
kind of source. Outside the sphere of open source, there are those who
see the "arms race" as worthwhile, at least up to a point. In this
context, encryption does not necessarily mean trying to shoehorn some
cryptographically secure algorithm like AES (as code for AES is easily
recognisable, and you have to include the decryption algorithm and
keys), but instead a relatively simple bespoke algorithm that just
adds to the layers of confusion that an attacker has to work through.

As has always been the case, an attacker can fire a decompiler or
disassembler like Hex-Rays or IDA on the compiled parts of a product,
and thus recover some kind of source corresponding to the original
C/C++ source. The aim is to engineer a similar environment for the Lua
source contained in the product, and by implementing convoluted logic
for decrypting and loading Lua source in the C/C++ source, you're some
of the way to achieving this.