More on Protecting Source Code

Chris Liechti 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
> 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