How protect proprietary Python code? (bytecode obfuscation?, what better?)

Alex Martelli aleaxit at yahoo.com
Thu Apr 20 10:31:46 EDT 2006


Ben Sizer <kylotan at gmail.com> wrote:

> bruno at modulix wrote:
> > Let's rephrase it:
> > "do you really think that native code is harder *enough* to
> > reverse-engineer ?"
> 
> I don't know. In terms of copy protection, popular off-the-shelf
> software is going to get cracked whether it's written in Python or x86
> ASM, that much is true. But in terms of perhaps protecting innovative
> algorithms from competitors, or something similar, compilation into
> native code does a great job of hiding your work. Not a perfect job,
> but a good enough job.

If they're truly worth protecting, they're worth reverse engineering.

Remember, the competition includes excellent programmers working in
countries where $10 an hour's salary is luxury and IP law enforcements
non-existent, so the cost to reveng is not as high as you might think.

 
> I know some people talk a lot about using web services to keep the
> proprietary data behind a secure server, but there is a large number of

Ah yes, that would be me;-).  Except that I don't limit my advice to
proprietary DATA -- it also applies to CODE worth keeping secret.

> applications where this is not practical - eg. image/audio processing,
> computer games, artificial intelligence, or several other applications
> with heavy real-time or cpu-intensive requirements, or embedded systems
> that don't have web access.

Fewer and fewer systems "intrinsically lack" net access.  For example,
good (costly) computer games more and more need net access to be played
in the best way (multiplayer etc).

"CPU intensive" is a weird reason to want to avoid keeping in a well
protected environment any code that's really worth money -- if it IS
worth that much you're no doubt charging enough for it to afford
supplying the CPU power to your customers (whatever your business model,
say pay-per-use or subscription levels with different maxima, etc etc).

> 
> Perhaps the inclusion of ctypes will make it more practical to migrate
> any sensitive code into native code libraries.

Naah, ctypes shines when you access *pre-existing* dynamic libraries; if
you're building those libraries yourself, it makes more sense to make
them immediately usable from Python, e.g. via Pyrex, or SWIG, or SIP, or
the C API, etc, etc. And if your secrets are truly valuable, none of
those will really help keep them safe.

If your secrets are worth diddlysquat, and the only reason to "protect"
them is (e.g.) to keep some PHB happy (relying on the fact that he or
she has no clue as to reality anyway), then go ahead -- use a Caesar
cypher (as a just-arrested Mafia "capo di tutti i capi" appears to have
done -- Italian police easily broke it, enabling it to arrest several
other mafiosi!), or native code, or any other ineffectual approach.  But
if your wallet (or jailtime;-) is really on the line, do realize that
they ARE ineffectual.


Alex



More information about the Python-list mailing list