More on Protecting Source Code
cliechti at gmx.net
Tue Sep 17 21:15:03 CEST 2002
Kerim Borchaev <warkid at storm.ru> wrote in
news:mailman.1032260602.11981.python-list at python.org:
> Hello David,
> Tuesday, September 17, 2002, 7:26:06 AM, you wrote:
> DL> I suppose one solution is to modify the Python interpreter with
> different DL> op-codes and that ought to make it somewhat painful for
> the average hacker. DL> A better solution is to make a .pyc file
> approximately as hard as a binary DL> .exe file to decompile - however
> that could be done.
> Just a thought.
> Keeping your python modules encripted(e.g. with rotor module?) you can
> reimplement __import__ builtin to properly handle importing these
that sounds nice at first, but how would you code the custom import? if one
has the readable code for that one using it to read the encrypted files is
a no-issue. and if you decrypt it the plain text sources are in memory and
a simple snapshot of the applications memory reveals the source.
a simple way to semi obfuscate is to use the freeze tool which embedds the
python bytecodes in a C array. as you also link against a python
interpreter there are no version issues and distributing gets easy.
if somebody wants to change the opcodes for this python interpreter - go
on, that should be easy and the python decompilers won't work out of the
if somebody believes that there should be better security there might be
ways, but i think that you need expert knowledge in encryption, the OS it
runs on, attack methods of crackers etc. to achieve a much higher level of
security. probably too much effort just to eventualy loose...
just distributing bytecode (forzen or not) should be save enough for most
commercial purposes. i don't think that java is any more secure than python
in this respect.
Chris <cliechti at gmx.net>
More information about the Python-list