lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 15/04/2011 15.15, Adam Strzelecki wrote:

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.


Sure they can and I've said there's no perfect protection. The aim is only to "encrypt" code with minimal effort in the way "decrypting" is simply uneconomical (unprofitable).

Consider also I am here thinking mostly about using LuaJIT is some indie or mobile development, where there is no single big "enemy" like in AAA, but thousands of developers that can peek (and they sure will) into your application. Most of them do not know much about IDA and stuff, some probably heard about Lua, but they do not have to be skilled to unzip your app (IPA) and read your text file scripts.

And I don't believe in good will of the competition, as I have seen many copied ideas and projects (including mine), many stealing code (like linking GPL code without absolutely no disclaimers) from others and pretty many scam too, especially on AppStore. It's not a big deal if you are big company and you have lawyers, but if you are small or one man company basic protection matters.


No, if you want byte code support, you need to argue with:
* size on harddisc
* loadding time
* portability with lua tools creating bytecode


IMHO portability has least importance, since you can prepare separate bytecode for each deployment scenario. Size&  loading time matters also only for big projects.


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".


I do understand this as this "arms race" is simple paranoid, but try do understand my point, that one of the reasons Java or .NET are popular in commercial projects you can have this basic level of protection of the box, however these are pretty heavy frameworks too, for example putting Mono in iPhone app takes away minimum 10MB, while 20MB is a limit of apps that can be distributed via 3G.

Regular Lua gives this basic level of protection which is bytecode that you can then embed into your application even into the binary and make custom loader. Pretty simple, but again requires skill to extract and decompile that. With LuaJIT you are limited because you need textual source code to be embedded anyhow.

I did have similar kind of discussion on Ruby forums. Some folks said, "protecting the code? what for!? world is beautiful, let's share the code!", unfortunately there were not using Ruby in commercial projects that are sold as a bundles/apps, but many of them were Rubyists living from talks and conferences ;P

Regards,
I'm no security specialist (and maybe some people on this list are), but from the path this discussion is taking I suspect there may be some basic misunderstanding which contributes to the obfuscation of this thread :-) 

(Warning: moderately long theoretical disquisition ahead)

For some of the ideas given below see:
http://www.cl.cam.ac.uk/~rja14/book.html
(note: the first edition of the book is completely online, scroll that page down for the links to the chapters in PDF).
Security (in general, but even code security) is a vague concept in itself. You cannot take any sensible decision without establishing a so-called "threat model", i.e. a model of the menace you are facing (or you will be likely face).
Without a threat model you may either grossly overestimate or underestimate the effort needed to thwart that menace. And a threat model is also needed to estimate the resources you need to employ to have a secure system.
Security is not an absolute notion: it is always relative to the threat model you established when designing the system, as the recent Fukushima disaster demonstrates - a totally safe shelter against 6m-high waves can crumble when faced with 12m-high ones :-(
Establishing a threat model can be as easy as saying you want to shield your system from the attacks from script kiddies but not from attacks from a C system programmer with 20 years of experience.
Of course the more detail you put in your model the better are the results of the risk analysis. But those details are part of the whole security design process - they have a cost! A detailed threat model is expensive. The more details mean higher costs (in establishing the model and in the subsequent analysis and system design).
So before taking any decision on whether you need obfuscation and to what extent, try making very clear what/who you are defending against (maybe you did, but it wasn't clear from the discussion). Otherwise you could waste you effort by trying to shoot a moving target and then end up having huge security holes in your system.
Security has many analogies to optimization: it is difficult even for an expert to say where are the bottlenecks for a piece of code. You have to profile it to be sure (and many times you have big surprises!). So make meaningful choices you have to measure/quantify things. Then you may decide a simple XOR mask is enough do defend against your "enemy", but you have to know your enemy first! 


best regards

-- Lorenzo