More on Protecting Source Code
Chris Liechti
cliechti at gmx.net
Tue Sep 17 15:15:03 EDT 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
> modules.
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
box.
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
--
Chris <cliechti at gmx.net>
More information about the Python-list
mailing list