Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > How protect proprietary Python code? (bytecode obfuscation?, what better?)

Reply
Thread Tools

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

 
 
bruno at modulix
Guest
Posts: n/a
 
      04-18-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> How can a proprietary software developer protect their Python code?
> People often ask me about obfuscating Python bytecode. They don't want
> people to easily decompile their proprietary Python app.


Do they ask the same thing for Java or .NET apps ?-)

> I suppose another idea is to rewrite entire Python app in C if compiled
> C code
> is harder to decompile.


Do you really think "native" code is harder to reverse-engineer than
Python's byte-code ?

> Any ideas?


I'm afraid that the only *proven* way to protect code from
reverse-engineering is to not distribute it *at all*.


--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '(E-Mail Removed)'.split('@')])"
 
Reply With Quote
 
 
 
 
Richard Brodie
Guest
Posts: n/a
 
      04-18-2006

"bruno at modulix" <(E-Mail Removed)> wrote in message
news:4444c777$0$9453$(E-Mail Removed)...

> Do they ask the same thing for Java or .NET apps ?-)


If you Google for "bytecode obfuscation", you'll find a large number
of products already exist for Java and .Net


 
Reply With Quote
 
 
 
 
Fredrik Lundh
Guest
Posts: n/a
 
      04-18-2006
Richard Brodie wrote:

>> Do they ask the same thing for Java or .NET apps ?-)

>
> If you Google for "bytecode obfuscation", you'll find a large number
> of products already exist for Java and .Net


and if you google for "python obfuscator", you'll find tools for python. including
tools that use "psychologically inspired techniques to produce extra confusion in
human readers" (probably by inserting small snippets of Perl here and there...).

</F>



 
Reply With Quote
 
Ben Sizer
Guest
Posts: n/a
 
      04-19-2006
bruno at modulix wrote:
> (E-Mail Removed) wrote:
> > I suppose another idea is to rewrite entire Python app in C if compiled
> > C code
> > is harder to decompile.

>
> Do you really think "native" code is harder to reverse-engineer than
> Python's byte-code ?


Yes, until there's a native code equivalent of "import dis" that
telepathically contacts the original programmer to obtain variable
names that aren't in the executable.

--
Ben Sizer

 
Reply With Quote
 
bruno at modulix
Guest
Posts: n/a
 
      04-19-2006
Ben Sizer wrote:
> bruno at modulix wrote:
>
>>(E-Mail Removed) wrote:
>>
>>>I suppose another idea is to rewrite entire Python app in C if compiled
>>>C code
>>>is harder to decompile.

>>
>>Do you really think "native" code is harder to reverse-engineer than
>>Python's byte-code ?

>
>
> Yes, until there's a native code equivalent of "import dis" that
> telepathically contacts the original programmer to obtain variable
> names that aren't in the executable.


Lol !-)

Ok, granted. Let's rephrase it:
"do you really think that native code is harder *enough* to
reverse-engineer ?"

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '(E-Mail Removed)'.split('@')])"
 
Reply With Quote
 
Ben Sizer
Guest
Posts: n/a
 
      04-20-2006
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.

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

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

--
Ben Sizer

 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      04-20-2006
Ben Sizer <(E-Mail Removed)> 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
 
Reply With Quote
 
Ben Sizer
Guest
Posts: n/a
 
      04-20-2006
Alex Martelli wrote:
> Ben Sizer <(E-Mail Removed)> wrote:
>
> > 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.


It's a sliding scale though. You don't need to be able to stop
everybody to make it worthwhile.

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


Whether $10 is a lot or a little is not as important as whether that
$10 could be better spent. It's easy to drill down far enough to break
copy protection but nowhere near as easy to derive a high level
algorithm from the assembly language. So in the latter case, a little
protection goes a long way.

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


Code is data, data is code. I meant it to refer to all information
stored that way.

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


Sure, but there's still many, many programs that don't fit that
criteria. Nor are people generally happy about being compelled to use
online services to 'activate' their games.

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


Maybe I wasn't making myself clear - I just meant that you can't be
doing round-trips to a web server for per-pixel calculations.

--
Ben Sizer

 
Reply With Quote
 
AdrianC AdrianC is offline
Junior Member
Join Date: Sep 2010
Posts: 1
 
      09-19-2010
you know, embedding the python code as a string inside a C app is very easy to crack... just open the binary with "vi" (or any text editor that doesn't mind binary here and there )

you could embed the pyc file though but still, can be reversed easily
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Can firefox open .mht files? This is the proprietary format that ie uses to save pages as web mail. John Toliver Firefox 13 11-06-2009 07:35 PM
Need help calling a proprietary C DLL from Python Craig Python 24 03-27-2008 03:58 AM
Re: How protect proprietary Python code? (bytecode obfuscation?, what better?) Biggmatt Python 0 04-19-2006 03:07 AM
Using Python with COM to communicate with proprietary Windows software Joakim Persson Python 8 09-21-2005 01:05 PM



Advertisments