[python-win32] Anti-reverse Python-based binaries?

Sturla Molden sturla at molden.no
Thu Feb 23 18:41:36 CET 2012


On 09.02.2012 07:51, Jun Koi wrote:

> 1) how serious this problem is in your opinion? is it really true that
> it is impossible to protect the binaries from reversing?

You are probably aware that binary machine code from a C compiler can be 
decompiled as well (e.g. to x86 assemby).

Decompiling Java bytecode or .NET bytecode is trivial. The .NET 
framework even provides a decompiler.

Python bytecode are not any worse.

So if your bytecode is not safe enough, then I am not sure anything will 
be. You might try to control the hardware, e.g. keep your dark secrets 
hidden behind a web service and only provide a front-end for the 
clients. That is what Google mostly does.

> 3) if it is true that it is quite trivial to reverse the Python
> binaries, how are you currently protecting your binaries?

Are you afraid someone will accidentally see your code? Is it that bad?

The main problem is managers confusing "obscurity" with "copy 
protection". If you need to protect an invention, file a patent claim. 
If you need protection against software piracy, remember that a program 
can be copied without reverse-engineering.

But anyway, sure you can go for code obfuscation. I would have used 
Cython with --embed instead of py2exe. Now you can provide your custom 
module loader, and e.g keep the bytecode as encrypted text strings. 
Since you can also build a custom Python interpreter from source, it is 
also possible to make sure bytecode and attribute names are scrambled. 
So you end up with an EXE and some DLLs that have strings of encrypted 
bytecode only your custom built interpreter can make sence of. And I 
would also link the custom Python interpreter statically, to make sure 
it is not easily accessible for testing. It would still run with the 
same speed as normal Python.

Sturla


More information about the python-win32 mailing list