bdesth.nospam at removeme.free.fr
Fri Jun 27 14:56:08 CEST 2003
Aurélien Géron wrote:
> Catalin wrote:
>>>How can I make executables with python?
>>>I found some utilities that claim they can do something like that like
>>>Installer and py2exe but they actualy pack the code in a huge arhive!
>>>This solves the problem of giving python programs to users who don't
>>>have python but doesn't solve the problem of the source "secrecy"
> Bruno wrote:
>>1/ source "secrecy" (copyright) :
>>It's the wrong problem. *Any* binary code can be subject to
>>reverse-engineering. There are even tools to do this quite easily for
>>Java. The right way to protect your property is via copyright and licence.
> IMHO, Catalin has a good point here. I'm no legal expert, but I believe that
> copyrights and licences are not quite enough to protect your code. They just
> mean that if someone uses your code without your authorisation, you *could*
> theoretically sue them, but :
> 1- Would it be worth it to go and hire a lawyer and everything?
> 2- How would you prove it (or even know about it) if they just stole pieces
> of your code? Or even algorithms?
> 3- Moreover, you may never know who hacked your code. Look at all the games
> and excellent software cracked everyday: do you know who dunnit? Who would
> you sue?
This point out that binarie compilation does not enforce licence and
<troll>A simple solution is to make the code open-source !-)</troll>
> So why not simply compile your code and make it *harder* (although not
> impossible) to decypher:
Compiling also means loosing quite a great part of interpreted languages
> it'll stop most of the potential hackers. It's
> like the lock on your door: however weak it is, it'll stop most burglars
> because they won't bother fighting it at all: they'll just go and look for
> an unlocked house! Well... unless everyone knows there's a treasure inside
> it, that is. In which case there's not much you can do against determined
> hackers except to make the task difficult for them.
You can choose to only deliver bytecode (.pyc) files. But you have to be
sure the user has the right interpreter version... And like Java, there
is a simple way to decompyle...
> I agree with Bruno about Java decompilers, though : I used them many times
> and I am still amazed at the quality of the decompilation process. In one
> instance it even helped me recover my own code when all I had left was the
> compiled result! The recovered code was neatly indented and perhaps clearer
> than the original code! But there are also free "obfuscators" that make your
> compiled bytecode (a lot) harder to decompile.
Doesn't this affect bytecode quality ?
> Python bytecode has some pretty good decompilers too.
> But I don't know about any decent C decompiler. If anyone does, though, I'd
> be greatly interested.
I guess there is none. All you can do is hack the binary code. But some
people are pretty good at this.
>>3/ 'Slowness' :
>>I don't believe that 'packing' the program makes it slower.
>>Are you sure your Python code is really Pythonic ? There are tips and
>>tricks in how to 'optimize' Python code, and it can be very different
>>from low-level (C/C++ etc) languages techniques. You may want to have a
>>look at :
>>Now if you really need smallest possible footprint and blazing-fast
>>execution speed (which are antagonist needs anyway), and your program is
>>about low-level stuff, you may not have choosen the right tool !-)
> I don't see small footprint and fast execution speed as antagonist at all,
> quite the contrary.
This seems to be a quite common observation that programs can be
optimized for speed or for size, but not both (the program being
correctly written, of course...).
> In fact, assembly code produces the fastest and
> smallest programs.
I was talking about the same program written with the same language...
BTW, I'm not sure a human programmer can beat a good compiler, unless
the code is to be 'optimized' for one specific processor, which I don't
call optimization !-)
More information about the Python-list