[Q] how to protect python program from decompilation

[Moshe Zadka]

On Sun, 18 Feb 2001 17:18:54 GMT, Leonid Gluhovsky <gleonid at actcom.co.il> wrote:
 
> I am not in a position to decide on this matter.  Let's say I am looking
> for a way to make it prohibitively hard for the customer to decompile
> the byte code.  I agree that complete protection is impossible. 

If management has asked you to find a problem, they should be able to
hear that the problem has no solution. Any protection scheme can be broken,
and most (hard!) ones can be broken by someone in less then a day. Consider
whether a day of someone else's time is worth more then (at least) an
hour of your time.

> Right now we are considering the following scheme: build a Python
> with opcodes in Include/opcode.h reshuffled, and without the dis module
> in it; use this interpreter to byte compile our code; use its Tools/freeze
> to package our program into executable and ship it to customers. 
> 
> What are the holes in this approach?  What is a better approach?

That an idiot with a debugger can see what each opcode does enough to remap
the opcodes, and then read from your program the freezed strings using
a tool I can probably write in Python in 15 minutes.
So, if I were to break your program (and I'm not -- I'm using only software
I have the source for at home), I estimate it would take me about one hour.
It's probably as good approach as any, but it's also probably as bad
as any too.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org