468,473 Members | 1,762 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,473 developers. It's quick & easy.

Re: Any reliable obfurscator for Python 2.5

En Sun, 20 Apr 2008 10:32:36 -0300, Banibrata Dutta <ba*************@gmail.comescribió:
On 4/20/08, Gabriel Genellina <ga*******@yahoo.com.arwrote:
>>
En Sun, 20 Apr 2008 01:55:51 -0300, Banibrata Dutta <
ba*************@gmail.comescribió:
Wanted to check if there is any known, reliable, FOSS/Libre --
Obfurscator
for Python 2.5 code.

Why do you want to do that in the first place?


I need to do to retain the confidentiality for certain core components,
which are not supposed to be open. While I do have the option of
implementing them in C/C++, I'm trying to see if I can avoid that for 2
reasons --
1. Its a fairly large and complex set of components, and doing it in C/C++
'might' take significantly longer.
2. I'd try to avoid having mix of languages if possible. It makes the
developement easier to maintain/manage over a period of time.

There is very few you can do to obfuscate Python code. You can't rename
>classes nor methods nor global variables nor argument names due to the
dynamic nature of Python. All you can safely do is to remove comments and
join simple statements using ;


I do not understand the nuances of dynamic languages completely, so this
might be a foolish assumption, but if i make a complete, self-contained
Python application (collection of modules), then just before shipping a
production copy, why can't I replace 'all' symbols i.e. classes, methods,
variables etc ? Esply if I'm compiling the source ?
Because *any* string can be used to retrieve an attribute, it is not easy to replace *every* occurence of an attribute name (the code may use arbitrary expressions with getattr). The code may contain external references to class names (e.g. pickles, logging config files) that must be kept; also code that uses exec/eval will not find the referenced objects. Even local names are necesary in some cases like "%(some)s %(format)d" % locals().
If you remove docstrings, some things may break. Even renaming local
>variables isn't safe in all cases.

Hmmm... but I'm aware of atleast 2 Obfuscators one commercial and one FOSS,
that seem to exist for Python. The commercial one is what I might try if I
don't find anything FOSS. The FOSS one seems to be a dead project. If they
are (or have been) there, I guess obfuscation is a doable thing, no ?
Sure, it can be done - with a lot of care, and I'm sure *some* code will fail. You may distribute compiled .pyc files - that's enough for most people who cares at all. Paranoids use a modified version of the interpreter incompatible with the standard one.
In any case, bug reports (including tracebacks) are less valuable and harder to read.

--
Gabriel Genellina

Jun 27 '08 #1
0 892

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Aubrey Hutchison | last post: by
5 posts views Thread by Pierre-Eric.Melchy | last post: by
4 posts views Thread by John Grant | last post: by
5 posts views Thread by pabloski | last post: by
reply views Thread by eliss | last post: by
1 post views Thread by =?Utf-8?B?S2F1c2hhbCBNZWh0YQ==?= | last post: by
9 posts views Thread by Steve Holden | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.