Re: obfuscating / protecting LUA code

[Mark Hamburg <mhamburg@...>]

What one could do in an obfuscator:

First add some sort of declaration of field names that could be obscured
because they are purely internal. (You could actually use runtime obscuring
by using tables as keys, but the VM and the language syntax are both
optimized for string keys.)

    -- Private Fields: _x, _y, _protectMe

Then write a script that sits upstream from the bytecode compiler which
looks for such declarations and replaces all of the uses of those field
names with nonsense.

You will want to be careful that the fields you name aren't part of an API,
but most internals shouldn't be.

You could do this on a larger scale obscuring even method names if you
processed all of your source code as a whole. The thing you have to be
careful of is identifying which names are truly obscurable because you can
find all of their uses and only their uses.

Mark

on 4/29/06 5:14 AM, Shmuel Zeigerman at shmuz@actcom.co.il wrote:

> David Given wrote:
> 
>> Shmuel Zeigerman wrote:
>> [...]
>>>  a1 = {  ["a2"] = 1, [1] = "a2",
>>>      ["a3"] = 2, [2] = "a3",  }
>> 
>> ...and the program has now told the user: "You have a3 emails waiting for
>> collection." Those field names aren't arbitrary, they're actual *data*.
> 
> Thanks for the good examples.
> The conclusion may be like this:
> There are names that are arbitrary, and names that are not. The first
> ones can be obfuscated, the second - cannot.