Python executables?

Re: Python executables?

Catalin wrote:[color=blue]
> 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"
> (copyright).
> And the programs also run much slower and become extremely big compared
> to a normal C++ program for example. I made a test and a 2 programs
> doing the same thing where 400 KB with C Builder (static linked) and
> 2.80 MB with python+installe r in an arhive packed with upx and 6.9 MB
> with py2exe(unpacked ). And the speed difference was huge.
> So can a python program become a "real" executable(I am refering both to
> windows and unix platforms)?
> If this is imposible with python is it possible with jpython?
>[/color]

Here you expose 3 different problems :

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.

2/ Size of "packed" programs :
Realize that the pack must include the whole Python interpreter and
librairies. BTW, I personnaly never used such tools, but I think I
remember that some of them allow you to specify which parts you really need.

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 !-)

Bruno

Re: Python executables?

Catalin wrote:[color=blue][color=green]
> > 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"
> > (copyright).
> > And the programs also run much slower and become extremely big compared
> > to a normal C++ program for example. I made a test and a 2 programs
> > doing the same thing where 400 KB with C Builder (static linked) and
> > 2.80 MB with python+installe r in an arhive packed with upx and 6.9 MB
> > with py2exe(unpacked ). And the speed difference was huge.
> > So can a python program become a "real" executable(I am refering both to
> > windows and unix platforms)?
> > If this is imposible with python is it possible with jpython?[/color][/color]

Bruno wrote:[color=blue]
> Here you expose 3 different problems :
>
> 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.[/color]

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?

So why not simply compile your code and make it *harder* (although not
impossible) to decypher: 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.

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 "obfuscator s" that make your
compiled bytecode (a lot) harder to decompile.

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.

[color=blue]
> 2/ Size of "packed" programs :
> Realize that the pack must include the whole Python interpreter and
> librairies. BTW, I personnaly never used such tools, but I think I
> remember that some of them allow you to specify which parts you really[/color]
need.

Yes, some do.
[color=blue]
> 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 :
> http://manatee.mojam.com/~skip/python/fastpython.html
>
> 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 !-)[/color]
[color=blue]
>
> Bruno
>[/color]

I don't see small footprint and fast execution speed as antagonist at all,
quite the contrary. In fact, assembly code produces the fastest and
smallest programs.

But Bruno is right, IMHO, about choosing the right tool: if you need a 50k
program calculating Pi to the 5000th decimal in 0.1 seconds... python is
definitely *not* the way to go.

Aurélien

How users perceive speed improvements

On Thu, 26 Jun 2003 18:26:58 -0700, achrist@easystr eet.com wrote:[color=blue]
> This is a funny thing. IBM has done some studies[/color]

Cite, please.
[color=blue]
> that showed that users do prefer faster programs, but only 25% faster.
> If a program runs more than 25% faster than what they are used to,
> users don't like it.[/color]

I suspect the data would show they were studying a particular class of
program, and a particular class of user; the answer would only be
relevant to that scope.

We surely couldn't conclude that, if a web server became 60% faster in
completing its tasks, or if an interactive video game's refresh speed or
startup time became 60% faster, that "users [wouldn't] like it".

So, it's necessary to see the study to know what kind of software, and
what kind of users, were being studied; only then can we make
intelligent generalisations .

--
\ "I went to a fancy french restaurant called 'Deja Vu.' The |
`\ headwaiter said, 'Don't I know you?'" -- Steven Wright |
_o__) |
http://bignose.squidly.org/ 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B

Re: Python executables?

Aurélien Géron wrote:[color=blue]
> Catalin wrote:
>[color=green][color=darkred]
>>>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"
>>>(copyright ).[/color][/color][/color]


(snip)[color=blue]
>
> Bruno wrote:[/color]
(snip)
[color=blue][color=green]
>>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.[/color]
>
>
> 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?[/color]

This point out that binarie compilation does not enforce licence and
copyright...

<troll>A simple solution is to make the code open-source !-)</troll>
[color=blue]
> So why not simply compile your code and make it *harder* (although not
> impossible) to decypher:[/color]

Compiling also means loosing quite a great part of interpreted languages
power.
[color=blue]
> 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.[/color]

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...
[color=blue]
> 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 "obfuscator s" that make your
> compiled bytecode (a lot) harder to decompile.[/color]

Doesn't this affect bytecode quality ?
[color=blue]
> 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.[/color]

I guess there is none. All you can do is hack the binary code. But some
people are pretty good at this.

(snip)
[color=blue][color=green]
>>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 :
>>http://manatee.mojam.com/~skip/python/fastpython.html
>>
>>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 !-)[/color]
>
> I don't see small footprint and fast execution speed as antagonist at all,
> quite the contrary.[/color]

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...).
[color=blue]
> In fact, assembly code produces the fastest and
> smallest programs.[/color]

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 !-)

Bruno

Re: Python executables?

Catalin <ady982@ploiest i.astral.ro> wrote in
news:mailman.10 56619905.13226. python-list@python.org :
[color=blue]
> And the programs also run much slower and become extremely big compared
> to a normal C++ program for example.[/color]

What are you doing that the speed decrease matters?
What are you doing that is so secret?

If it really is too slow (i.e. 100 times slower than C++ is one thing, but
if it still only takes 0.1s is that really a problem?), consider writing
the slow part in C or C++ as a compiled extension. That could get you the
speed and mildly-increased-code-security you desire for the delicate parts
of your program, plus the advantages of Python for all the rest.

sfb.

Re: Python executables?

On 27 Jun 2003 09:24:22 +0950, Ben Finney
<bignose-hates-spam@and-zip-does-too.com.au> wrote:
[color=blue][color=green]
>> 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"
>> (copyright).[/color]
>
>Wrong problem. If you want to hide your source code from your users,
>don't expect help from free software programmers.[/color]

I thought about this for a few days before responding (and Im sure I
did a few other things too ;) ), but I wanted to comment on this.

I think everyone that uses Python wants it to gain acceptance for the
great language that it is. I believe that stating an attitude in this
way is pretty counter productive in gaining any kind of wide-spread
acceptance.

Most of the replies to this request didn't mention the concept of NOT
protecting the software, but 2 did to different degrees. As someone
who uses and like open source software, and is slowly starting to
release some things as open source, and ALSO someone who sells
software and will continue in the future to sell software, I can say
that nothing turns me off more to a community than being told what my
goals should be.

I can understand wanting everything to be open, but thats not reality
and it never will be. Some people will always want things
proprietary, and they will only work within systems that allow that.
I think to be truly successful, systems will have to allow for this
and make it easy to do.

Currently Python does not make this REALLY easy to do, and in the
privacy portion, I believe its not even possible. This was a big
concern for me when I released my last for-sale software, but I just
decided I didn't care that much, and I love working in Python.

Some people will care enough, and will avoid Python because the
ability to protect their end results aren't there.

So far, the only semi-workable way to do this would be something like:

- Build a C program that embeds Python.
- Encrypt all the Python script/bytecode files.
- On runtime, decrypt the files and then execute.

Optional:

- Change the bytecode values in the Python source, and include your
new Python with different bytecode values.

I tried this last thing just to see if it would work, and I got some
problems compiling initially, so just gave up, but I think in theory
it should work.

Ignoring the Optional portion, this semi-solution is not actually very
secure. It does however move the problem into having to decompile a C
program, and then get it to decrypt the Python files. Then the normal
Python bytecode -> source. It means any cracker will have to know
something about both C and Python to do it, so a bit more barrier to
entry. It also means that in the US, the (vile and despicable, but
present) DMCA laws will make it a much more severe crime because
"cryptograp hy reverse engineering" needed to be applied, and may at
least reduce corporations from doing this for fear of
lawsuits/criminal charges if they are exposed.

Anyway, this is a good bit of work and not a great solution, but is
there anything else? If Python is to have avenues of support in all
walks of the software industry, will something like this be required?

From what I understand, there are also very good Java decompilers, but
no one seems to complain about Java's lack of security. Perhaps it is
because it is seen as something that is really "compiled" while
Python's loose compilation seems more whimsicle.

I think Python faces a lot of different public relations problems, and
just thought I'd pipe up about one that I have looked at myself, and
that I think most people coming into the Python world are faced with
and have to decide whether to ignore or not.


-Geoff Howland

Re: Python executables?

On 27 Jun 2003 09:24:22 +0950, Ben Finney
<bignose-hates-spam@and-zip-does-too.com.au> wrote:
[color=blue][color=green]
>> 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"
>> (copyright).[/color]
>
>Wrong problem. If you want to hide your source code from your users,
>don't expect help from free software programmers.[/color]

I thought about this for a few days before responding (and Im sure I
did a few other things too ;) ), but I wanted to comment on this.

I think everyone that uses Python wants it to gain acceptance for the
great language that it is. I believe that stating an attitude in this
way is pretty counter productive in gaining any kind of wide-spread
acceptance.

Most of the replies to this request didn't mention the concept of NOT
protecting the software, but 2 did to different degrees. As someone
who uses and like open source software, and is slowly starting to
release some things as open source, and ALSO someone who sells
software and will continue in the future to sell software, I can say
that nothing turns me off more to a community than being told what my
goals should be.

I can understand wanting everything to be open, but thats not reality
and it never will be. Some people will always want things
proprietary, and they will only work within systems that allow that.
I think to be truly successful, systems will have to allow for this
and make it easy to do.

Currently Python does not make this REALLY easy to do, and in the
privacy portion, I believe its not even possible. This was a big
concern for me when I released my last for-sale software, but I just
decided I didn't care that much, and I love working in Python.

Some people will care enough, and will avoid Python because the
ability to protect their end results aren't there.

So far, the only semi-workable way to do this would be something like:

- Build a C program that embeds Python.
- Encrypt all the Python script/bytecode files.
- On runtime, decrypt the files and then execute.

Optional:

- Change the bytecode values in the Python source, and include your
new Python with different bytecode values.

I tried this last thing just to see if it would work, and I got some
problems compiling initially, so just gave up, but I think in theory
it should work.

Ignoring the Optional portion, this semi-solution is not actually very
secure. It does however move the problem into having to decompile a C
program, and then get it to decrypt the Python files. Then the normal
Python bytecode -> source. It means any cracker will have to know
something about both C and Python to do it, so a bit more barrier to
entry. It also means that in the US, the (vile and despicable, but
present) DMCA laws will make it a much more severe crime because
"cryptograp hy reverse engineering" needed to be applied, and may at
least reduce corporations from doing this for fear of
lawsuits/criminal charges if they are exposed.

Anyway, this is a good bit of work and not a great solution, but is
there anything else? If Python is to have avenues of support in all
walks of the software industry, will something like this be required?

From what I understand, there are also very good Java decompilers, but
no one seems to complain about Java's lack of security. Perhaps it is
because it is seen as something that is really "compiled" while
Python's loose compilation seems more whimsicle.

I think Python faces a lot of different public relations problems, and
just thought I'd pipe up about one that I have looked at myself, and
that I think most people coming into the Python world are faced with
and have to decide whether to ignore or not.


-Geoff Howland