closed source

[Milos Prudek]

Hi,

is it technically possible to distribute a python project as a closed
source, i.e. encrypted?

I believe that *.pyc files do not work without *.py sources... and they can
be easily decompiled.

--
Milos Prudek

[Peter Hansen]

Re: closed source

Milos Prudek wrote:[color=blue]
>
> is it technically possible to distribute a python project as a closed
> source, i.e. encrypted?
>
> I believe that *.pyc files do not work without *.py sources... and they can
> be easily decompiled.[/color]

Numerous (*many*) past discussions of this have occurred... check the archives.

Short answer: .pyc files work fine without .py files (for the record), but
yes they can be decompiled (using "decompyle" , for example), and no it's
effectively not possible to do what you are asking, but note that it's
also impossible with any other language either...

If you *really* need protection, you must run your protected source on your
own server and make the algorithms available across the network. If you
don't want to do this route, your only other real choice is to accept a
greater risk that someone will see your source (heaven forbid!) and mitigate
that risk by having appropriate software licence agreements in place with
your customers.

-Peter

[Cameron Laird]

Re: closed source

In article <3F968833.C1F4A 1FF@engcorp.com >,
Peter Hansen <peter@engcorp. com> wrote:[color=blue]
>Milos Prudek wrote:[color=green]
>>
>> is it technically possible to distribute a python project as a closed
>> source, i.e. encrypted?
>>
>> I believe that *.pyc files do not work without *.py sources... and they can
>> be easily decompiled.[/color]
>
>Numerous (*many*) past discussions of this have occurred... check the archives.
>
>Short answer: .pyc files work fine without .py files (for the record), but
>yes they can be decompiled (using "decompyle" , for example), and no it's
>effectively not possible to do what you are asking, but note that it's
>also impossible with any other language either...
>
>If you *really* need protection, you must run your protected source on your
>own server and make the algorithms available across the network. If you
>don't want to do this route, your only other real choice is to accept a
>greater risk that someone will see your source (heaven forbid!) and mitigate
>that risk by having appropriate software licence agreements in place with
>your customers.
>
>-Peter[/color]

A few metacomments: Mr. Prudek, there certainly are concentrations
of software practitioners where it's conventional to think and act
in terms of "closed source", and to involve such technical realities
as "compilatio n", "obfuscatio n", "encryption ", and so on. A non-zero
minority of the comp.lang.pytho n participants hold and practice this
view.

For the most part, however, conventional wisdom in comp.lang.pytho n
is either indifferent, dismissive, or hostile to such approaches.

Peter's quite right in reporting that there has been a LOT of discus-
sion of these matters in the past, and moreover that it's worthwhile
to read at least some of these.

If you'd like to make a quick but significant contribution to the
Python community, you might consider summarizing in the Wiki <URL:
http://www.python.org/cgi-bin/moinmoin/ > what you learn on the
subject.
--

Cameron Laird <claird@phaseit .net>
Business: http://www.Phaseit.net

[Alan James Salmoni]

Re: closed source

Milos Prudek <me@me.cz> wrote in message news:<bn60l5$tj ubr$1@ID-205031.news.uni-berlin.de>...[color=blue]
> Hi,
>
> is it technically possible to distribute a python project as a closed
> source, i.e. encrypted?
>
> I believe that *.pyc files do not work without *.py sources... and they can
> be easily decompiled.[/color]

Hi Milos,

I don't know if this is suitable for your project, but if (IIRC) you
use Jython, you can byte-compile the code which will run as a Java
application, but will be hard for anyone else to work out (it's not
impossible of course, it just takes a lot of work).

Alan James Salmoni
SalStat Statistics

http://salstat.sunsite.dk

[Michael Geary]

Re: closed source

> Milos Prudek:[color=blue][color=green]
> > is it technically possible to distribute a python project as a closed
> > source, i.e. encrypted?
> >
> > I believe that *.pyc files do not work without *.py sources... and
> > they can be easily decompiled.[/color][/color]

Alan James Salmoni:[color=blue]
> I don't know if this is suitable for your project, but if (IIRC) you
> use Jython, you can byte-compile the code which will run as a Java
> application, but will be hard for anyone else to work out (it's not
> impossible of course, it just takes a lot of work).[/color]

That will certainly do the trick... as long as no one clicks here:

http://www.google.com/search?q=java+decompiler

-Mike

[Michael Hudson]

Re: closed source

"Michael Geary" <Mike@DeleteThi s.Geary.com> writes:
[color=blue][color=green]
> > Milos Prudek:[color=darkred]
> > > is it technically possible to distribute a python project as a closed
> > > source, i.e. encrypted?
> > >
> > > I believe that *.pyc files do not work without *.py sources... and
> > > they can be easily decompiled.[/color][/color]
>
> Alan James Salmoni:[color=green]
> > I don't know if this is suitable for your project, but if (IIRC) you
> > use Jython, you can byte-compile the code which will run as a Java
> > application, but will be hard for anyone else to work out (it's not
> > impossible of course, it just takes a lot of work).[/color]
>
> That will certainly do the trick... as long as no one clicks here:
>
> http://www.google.com/search?q=java+decompiler[/color]

I wonder what a Java decompiler would make of compiled-from-Jython
bytecode... would look a bit like the output of Python2C except in
Java, I guess.

Cheers,
mwh

--
Monte Carlo sampling is no way to understand code.
-- Gordon McMillan, comp.lang.pytho n

[Milos Prudek]

Re: closed source

> Numerous (*many*) past discussions of this have occurred... check the archives.

I would. I could not find web-searchable archives.
[color=blue]
> own server and make the algorithms available across the network. If you
> don't want to do this route, your only other real choice is to accept a
> greater risk that someone will see your source (heaven forbid!) and mitigate
> that risk by having appropriate software licence agreements in place with
> your customers.[/color]

Perfectly reasonable. Source availability / decompile option actually
helps protect the source, because source code theft can be easiliy
proved. Very good point.

This will not protect against illegal copying, however. Let's say that I
need to create a program that could be downloaded as a demo, with
activation code sent to people who purchase the software. This code
could be generated by a small C program that creates a hash of the
purchaser's hardware config. Inside the main Python program there would
be an extension written in C that would check the activation code
against the purchaser's hardware.

The idea here is that C is much harder to decompile than Python.

Now, for popular software such as Windows or Dreamweaver any protection
is useless, because the demand for pirated software is too strong and
the best minds pit against this protection. The program I talk about is
intended for a very small market, though.

BTW I am a huge fan of Open Source. This is simply a technical question
that a client asked.

Is this protection implementable?

--
Milos Prudek
_______________ __
Most websites are
confused chintzy gaudy conflicting tacky unpleasant... unusable.
Learn how usable YOUR website is! http://www.spoxdesign.com

[Milos Prudek]

Re: closed source

[color=blue]
> A few metacomments: Mr. Prudek, there certainly are concentrations
> of software practitioners where it's conventional to think and act
> in terms of "closed source", and to involve such technical realities
> as "compilatio n", "obfuscatio n", "encryption ", and so on. A non-zero
> minority of the comp.lang.pytho n participants hold and practice this
> view.[/color]

I understand. I know that I can receive hostile comments to this
specific question. My only feeble defense is that my contribution to
Open Source is also non-zero:

- Translation of http://www.dwheeler.com/oss_fs_why.html into Czech.

- KDE 2.0 documentation: The kmenuedit Handbook, Kicker Handbook.

--
Milos Prudek
_______________ __
Most websites are
confused chintzy gaudy conflicting tacky unpleasant... unusable.
Learn how usable YOUR website is! http://www.spoxdesign.com

[Alan Kennedy]

Re: closed source

Michael Hudson wrote:[color=blue]
> I wonder what a Java decompiler would make of compiled-from-Jython
> bytecode... would look a bit like the output of Python2C except in
> Java, I guess.[/color]

I'm using jython to script Apache Axis.

Axis has the ability to derive WSDL from a web service implementation
class, by reflecting on the class and generating the relevant WSDL
document.

If you use a jython object as the implementation class, the generated
WSDL is quite a mess, in that it contains WSDL declarations for all
the methods that implement jython interpretation.

In order to clean up the generated WSDL, I made a simple skeleton java
class that implements the web service, and that delegates all calls to
an instance of the jython class that actually implements the service.

I could imagine that decompiled jythonc'ed jython classes would be
quite hard to understand, especially if you're not familiar with
jython.

But certainly not impossible. It's more of a hindrance than a
showstopper.

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Peter Hansen]

Re: closed source

Milos Prudek wrote:[color=blue]
>[color=green]
> > Numerous (*many*) past discussions of this have occurred... check the archives.[/color]
>
> I would. I could not find web-searchable archives.[/color]

Groups.google.c om is quite capable. Use "comp.lang.pyth on" in
the search, or use the more flexible Advanced Search page.
[color=blue]
> This will not protect against illegal copying, however. Let's say that I
> need to create a program that could be downloaded as a demo, with
> activation code sent to people who purchase the software. This code
> could be generated by a small C program that creates a hash of the
> purchaser's hardware config. Inside the main Python program there would
> be an extension written in C that would check the activation code
> against the purchaser's hardware.
>
> The idea here is that C is much harder to decompile than Python.[/color]

As has been noted in the past, it's not that much harder. Most useful
software is cracked within days of its release, or even earlier. I
saw a cracked copy of a popular German CAD package on a Warez site
*before* it was sent to me by mail in the form of my free upgrade
(issued as soon as the software was ready). This is not unusual,
so when we advise you not to bother, we're just trying to make sure
you aren't lulled into a false sense of security.
[color=blue]
> Now, for popular software such as Windows or Dreamweaver any protection
> is useless, because the demand for pirated software is too strong and
> the best minds pit against this protection. The program I talk about is
> intended for a very small market, though.[/color]

Trust me, this German CAD package (Eagle) does not have a very large
market compared to things like Dreamweaver.
[color=blue]
> BTW I am a huge fan of Open Source. This is simply a technical question
> that a client asked.
>
> Is this protection implementable?[/color]

I think I basically covered that in my first response, in the parts
which refrained from expressing any judgment, if you'd care to check
them again. :-) (An even shorter summary: no.)

-Peter

[Milos Prudek]

Re: closed source

> Groups.google.c om is quite capable. Use "comp.lang.pyth on" in[color=blue]
> the search, or use the more flexible Advanced Search page.[/color]

Indeed. I'm stupid. Sorry.
[color=blue]
> As has been noted in the past, it's not that much harder. Most useful
> software is cracked within days of its release, or even earlier. I[/color]

I think I agree with you in principle (finally). Crack can often be
achieved without decompile...
[color=blue]
> Trust me, this German CAD package (Eagle) does not have a very large
> market compared to things like Dreamweaver.[/color]

In my specific case I know for sure that there is a shareware program
written in Visual Basic with this kind of protection, and a crack has
never been created. Purportedly because no decompiler for recent VB
compilers is in the wild...


--
Milos Prudek
_______________ __
Most websites are
confused chintzy gaudy conflicting tacky unpleasant... unusable.
Learn how usable YOUR website is! http://www.spoxdesign.com

[Werner Schiendl]

Re: closed source

Hi,

Milos Prudek wrote:
[color=blue]
>
> Is this protection implementable?
>[/color]

Some points that come to mind.

Personally I think C is still harder to decompile than Python (or for
that matter any VM based language like Java or .NET IL).

The reason is, that these VMs usually have much higher level constructs
than plain x86 assembly language (create object, access member, etc.
have their own opcode)

So you could write an extension module containing some part of the logic
and also the protection algorithm. Having only the protection in the C
extension is counter-productive, as it makes it even simpler to crack.
So be sure to add some logic vital to your application here.


Another point would be that I'd use some sort of strong encryption for
the key, similar to PGP signed mail messages. This does not prevent
actually cracking the software, but it's close to impossible to write a
key generator for it.

In addition, be sure to add the licensee's name in plain text in the
licence - nobody will give away such a license file, right?


Anyway you should be aware of what the other's in this thread said:
there is no real way of protection *except* not giving the software out
of your hands (i. e. make it a web service and only hand out a client).


hth

Werner

[Tayss]

Re: closed source

"Michael Geary" <Mike@DeleteThi s.Geary.com> wrote in message news:<vpeu6imo2 5575c@corp.supe rnews.com>...[color=blue]
> That will certainly do the trick... as long as no one clicks here:
>
> http://www.google.com/search?q=java+decompiler[/color]

Which will work, until someone clicks here:

http://www.google.com/search?q=java+obfuscator

;)

Obfuscators are actually good for their original purpose of saving
space and possibly execution time... however, they are painful to use.
Which sounds good to those who want closed source to come at a
disadvantage.

[Greg Brunet]

Re: closed source

FWIW:

Without rehashing all of the other points constantly made on this topic:
I tried to use decompyle on some of my programs to see what it would
produce, but the current version does not seem to work on Windows, and
doesn't decompyle Python 2.3 in any case. I'm sure that this will be
corrected in time, but for the time being, your code may be a little
'safer' than normal.

One other comment on the subject of VB decompilers (in one of your
responses) - they have been available in the past, and the concern about
decompiling .NET code (of any language source) is something that has
caused a number of code obfuscators to become available to 'protect' the
'compiled' code (sometimes referred to as MSIL).

--
Greg


"Milos Prudek" <me@me.cz> wrote in message
news:bn60l5$tju br$1@ID-205031.news.uni-berlin.de...[color=blue]
> Hi,
>
> is it technically possible to distribute a python project as a closed
> source, i.e. encrypted?
>
> I believe that *.pyc files do not work without *.py sources... and[/color]
they can[color=blue]
> be easily decompiled.
>
> --
> Milos Prudek[/color]

[David Bolen]

Re: closed source

Milos Prudek <milos.prudek@t iscali.cz> writes:
[color=blue]
> This will not protect against illegal copying, however. Let's say that
> I need to create a program that could be downloaded as a demo, with
> activation code sent to people who purchase the software. This code
> could be generated by a small C program that creates a hash of the
> purchaser's hardware config. Inside the main Python program there
> would be an extension written in C that would check the activation
> code against the purchaser's hardware.
>
> The idea here is that C is much harder to decompile than Python.[/color]

Definitely true - I think anything that does a native compilation is
much harder to decompile into usable information (but clearly not
impossible) simply because the compiled form is much further removed
from the original source.

But while your suggested approach would work in terms of making it
harder for the user to expose the actual authentication mechanism, it
might not make it much harder to avoid the authentication entirely.
Don't forget that it would only increase security to the extent of how
you use that module, since you basically just push the problem up a
level higher. Given the above approach, if I wanted to crack it, I
would just decompile the main Python program, and remove the call to
the C extension module, replacing it instead with appropriate code to
make it seem like the extension module call succeeded.

So in the end, as long as there's any interpreted code that is in
control of the authentication, you might not be any better off, so why
expend the effort in the first place. I think this is largely true
for any interpreted language.

I suppose you could choose to make your main entry point into C code,
only handing control to the Python interpreter after validation. The
model could be close to how Python packaging tools such as Gordan
McMillan's installer works, since the main entry point is as an
executable, and it sets up things (including the installer's import
hooks) before handing control over to the interpreter. But of course,
unless you obfuscate how the files are packaged together, access to
the original source would still be provided and someone ingenious
enough could just find a way to skip over the startup code.

Having thought about this myself in the past, if I absolutely had to
try to cover all but the most persistent folks, I'd probably try an
approach that encrypted my pyc files, and required a custom importer
to decrypt them on import. I'd use something similar to your
extension module idea (agreeing that native code is a bit more
resistent to effective decompilation). But the extension module would
do more than just validation. That is, when supplied with an
appropriate message (perhaps encrypted with a public key to match a
compiled in private key or something), it wouldn't just say yes/no,
but would, if ok, also establish itself as an import hook in the
system. When the application modules would get imported they would
automatically be decrypted. Since all of the key management and
encryption/decryption was in the extension module it would be a little
more secure against tampering. And since the extension module was
needed for imports but only provided an import hook when given a valid
key, it would be harder to work around by just manipulating the Python
code using the module.

I still have a feeling there would be a way to extract the modules in
an unencrypted form by someone with a working key (since once imported
the objects exist in memory, but I'm not sure how easy it would be to
regenerated marshalled bytecode files) but it should be limited to
someone starting with a working application, and then probably a
fairly persistent and knowledgeable person. The only place the
original source would exist unencrypted would be in the running
application.

I suppose if I made the authentication/import hook module into the
application entry point I might help close that loophole a bit tighter
as well. Might be an interesting experiment.

This would entail a reasonably amount of extra effort though, so I'd
probably look for other non-technical solutions first before falling back
on something like this.

-- David