By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,156 Members | 1,026 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,156 IT Pros & Developers. It's quick & easy.

closed source

P: n/a
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
Jul 18 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Milos Prudek wrote:

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.


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
Jul 18 '05 #2

P: n/a
In article <3F***************@engcorp.com>,
Peter Hansen <pe***@engcorp.com> wrote:
Milos Prudek wrote:

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.


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


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 "compilation", "obfuscation", "encryption", and so on. A non-zero
minority of the comp.lang.python participants hold and practice this
view.

For the most part, however, conventional wisdom in comp.lang.python
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 <cl****@phaseit.net>
Business: http://www.Phaseit.net
Jul 18 '05 #3

P: n/a
Milos Prudek <me@me.cz> wrote in message news:<bn************@ID-205031.news.uni-berlin.de>...
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.


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
Jul 18 '05 #4

P: n/a
> Milos Prudek:
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.

Alan James Salmoni: 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).


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

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

-Mike
Jul 18 '05 #5

P: n/a
"Michael Geary" <Mi**@DeleteThis.Geary.com> writes:
Milos Prudek:
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.


Alan James Salmoni:
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).


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

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


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.python
Jul 18 '05 #6

P: n/a
> Numerous (*many*) past discussions of this have occurred... check the archives.

I would. I could not find web-searchable archives.
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.


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

Jul 18 '05 #7

P: n/a
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 "compilation", "obfuscation", "encryption", and so on. A non-zero
minority of the comp.lang.python participants hold and practice this
view.


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

Jul 18 '05 #8

P: n/a
Michael Hudson wrote:
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.


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
Jul 18 '05 #9

P: n/a
Milos Prudek wrote:
Numerous (*many*) past discussions of this have occurred... check the archives.
I would. I could not find web-searchable archives.


Groups.google.com is quite capable. Use "comp.lang.python" in
the search, or use the more flexible Advanced Search page.
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.
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.
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.
Trust me, this German CAD package (Eagle) does not have a very large
market compared to things like Dreamweaver.
BTW I am a huge fan of Open Source. This is simply a technical question
that a client asked.

Is this protection implementable?


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
Jul 18 '05 #10

P: n/a
> Groups.google.com is quite capable. Use "comp.lang.python" in
the search, or use the more flexible Advanced Search page.
Indeed. I'm stupid. Sorry.
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
I think I agree with you in principle (finally). Crack can often be
achieved without decompile...
Trust me, this German CAD package (Eagle) does not have a very large
market compared to things like Dreamweaver.


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

Jul 18 '05 #11

P: n/a
Hi,

Milos Prudek wrote:

Is this protection implementable?


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
Jul 18 '05 #12

P: n/a
"Michael Geary" <Mi**@DeleteThis.Geary.com> wrote in message news:<vp************@corp.supernews.com>...
That will certainly do the trick... as long as no one clicks here:

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


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.
Jul 18 '05 #13

P: n/a
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:bn************@ID-205031.news.uni-berlin.de...
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


Jul 18 '05 #14

P: n/a
Milos Prudek <mi**********@tiscali.cz> writes:
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.


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
Jul 18 '05 #15

P: n/a
Alan Kennedy <al****@hotmail.com> writes:
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.


Also, whether Jython, or a Java obfuscator, it's not like the person
has to understand the majority of the application. All they need to
locate is the section that does the authentication or startup check,
and change just enough code to bypass it. Since there are typically
messages output when such checks fail, it's often easy to zero in on
the code involved.

-- David
Jul 18 '05 #16

P: n/a
David Bolen wrote:
Milos Prudek <mi**********@tiscali.cz> writes:
The idea here is that C is much harder to decompile than Python.


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.


Only if the bytecode in a known format. Otherwise the opposite is true -
you need to reverse engineer the whole interpreter before you can even start
reverse engineering the bytecode. This suggests an obvious solution: tweak
the Python interpreter to use a slightly different bytecode format. (This
only works if you can distribute a custom Python interpreter with your
compiled Python modules.)
--
Rainer Deyke - ra*****@eldwood.com - http://eldwood.com
Jul 18 '05 #17

P: n/a
David Bolen wrote:
Milos Prudek <mi**********@tiscali.cz> writes:
This will not protect against illegal copying, however. Let's say that
... 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 have said this often but I think it's worth repeating: if you
distribute executable code, no matter how cleverly disguised, somebody
else is going to be clever enough to hack away any authentication
etc. Proof by existence: any warez site.

If you have code so valuable you DO really truly want to protect it,
the solution lies in *web-services*. Carefully cut out the extremely
valuable parts of your application and DON'T distribute them as
any kind of executable code: only distribute "clients" that must
rely on connecting to a web-service, where you will make all the
juicy parts available. Your extremely precious code thus lives on
a server under your control, and you CAN secure it against hacking.
You also get to implement any business model you prefer (one-off
payment, subscription, pay-per-use, etc, etc). [Any kind of network
RPC protocol will work fine, of course -- "web-services" are just
one currently fashionable way to achieve such a protocol].

Of course this isn't applicable everywhere, although with the wider
and wider availability of connectivity (including wireless) the
area of applicability keeps growing. Some cases where this approach
can't be used might be handled instead by putting the extremely
valuable portions of your code into a custom integrated-circuit of
some kind (much harder to reproduce, though not impossible).

Striving to "protect" code which you distribute in executable form
is tilting at windmills. I've spent far too large a part of my
life hacking up such "protection" schemes, with and without "dongles"
of some kind to support them, and it's been far more effective in
bothering perfectly legitimate use than in foiling crackers and
warezguyz. These days, whenever somebody asks me about such
protection, I insist on the "webservice, or custom IC" as the only
really viable approaches. BTW, such conversations generally end
up, in 90% of the cases, concluding that the allegedly precious
code ISN'T really as precious as to be truly worth protecting -- if
so, putting in some looks-like-protection-to-the-clueless tweak may
of course be the easiest way to pacify a paranoic PHB ... :-) But
that's just as easy with Python as with any other language, of course.
Alex

Jul 18 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.