[CentralOH] Eschew^H^H^H^H^Hmbrace Obfuscation

[jep200404 at columbus.rr.com]

On Sat, 23 May 2015 11:07:56 +0800, Kenneth Wee <vken85 at gmail.com> wrote:

> 2) Protecting I/P by obfuscation (self-preservation consideration)
> The need for protecting our I/P when customers insist they need to keep
> things local and secure. Which means they get access to code (source or
> not) of the system being deployed, i.e. the cloud is not an option.

Of course the best obfuscation is by mediocre programmers,
but then _nobody_ would understand the code.

If what you are trying to hide is some little algorithm, 
that is hard to hide in any language. Skype spent much 
work on obfuscating their stuff. It was cracked. 
How much of what you are doing is truly novel? 
A big complicated enterprised application would be 
harder to understand, even before getting to reverse-
engineering. 

Otherwise, write good code, then run your code through an 
obfuscator, which mangles the names, 
then ship only the .pyc files. 

    https://duckduckgo.com/html/?q=python+obfuscation
    http://www.simonroses.com/2013/10/appsec-myths-about-obfuscation-and-reversing-python/

At some point, it's easier to rewrite from scratch than 
to reverse engineer obfuscated code. The business folks 
should keep that in mind. The need for updates could 
make reverse-engineering less attractive, 
because that would be like maintaining a private fork.