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
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
