[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Is obfuscation meaningful way to protect proprietary Lua code ?
- From: Marc Balmer <marc@...>
- Date: Tue, 17 Sep 2013 19:33:51 +0200
Am 17.09.13 13:36, schrieb liam mail:
> On 17 September 2013 06:42, Marc Balmer <marc@msys.ch> wrote:
>
>> Am 15.09.13 13:13, schrieb Dirk Laurie:
>>
>>> But really, if protecting proprietary code is you mission in life, Lua is
>>> not the ideal vehicle for you.
>>
>> This statement is utterly wrong. Encrypting proprietary code is
>> especially easy with Lua and it has absolutely nothing to do with Lua
>> bein the wrong vehicle. Actually development and testing is very easy,
>> and once you deploy, aou encrypt the bytecode.
>>
>> We do this very successfully since years, btw.
>>
>>
>>
>>
> IIRC from some of your other posting on this subject you decrypt the
> bytecode before loading into Lua, this would be a deterrent if the user
> never gets access to the binary; which again I seem to recall is the case
> for your usage. As soon as a user gets the binary they can bypass this
> attempt of securing the bytecode by patching the binary to either
> trampoline the load function which would receive decrypted bytecode or just
> look at the code inside the VM. Then there is the question of where the key
> is kept to decrypt the input? In the binary?, on the network? Is it not
> possible for someone to obtain this?
>
> In most cases if you want to protect your code from prying eyes, don't give
> it to anyone in any form. :)
That is what we do. Only the on-disk form of the software is encrypted.
Once in memory, the bytecode is just unmodified Lua bytecode.