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

Protecting Python source

P: n/a
Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

Is it possible to load the scripts from zip files where the zip files
are password protected ?

Any other ideas ?

Many thanks,

Alan
Jul 18 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
On Fri, Nov 26, 2004 at 07:01:27AM -0800, Alan Sheehan wrote:
Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. [...]


To get more meaningful answers, please expand on what exactly you mean with
"tamper proof". What is the attacker scenario? Are there passwords for external
systems embedded in the Python source code, or what's the deal about it?

-- Gerhard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBp0eqdIO4ozGCH14RAoqDAJ4ub7NKq7fTd+28oKG6rt LxWsP+WgCgmFZQ
UQlXTe8qpcUKITzGhegBdXo=
=7/id
-----END PGP SIGNATURE-----

Jul 18 '05 #2

P: n/a
Alan Sheehan wrote:
Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.
If all you want to prevent is casual user tinkering, just shipping compiled
bytecode is probably enough. (yes it *can* be decompiled, but a casual user
isn't going to bother, any more than they bother disassembling standard binaries).

For slightly greater obfuscation, push the key parts you wish to obscure into a
C/C++ extension module.

There's nothing to be done to stop the determined cracker, though, as anyone who
can effectively reverse engineer pure C++ programs is going to be able to figure
out how to interpret .pyc files pretty quickly.
Is it possible to load the scripts from zip files where the zip files
are password protected ?


Since the interpreter needs to read your zipfile, there are potential problems
with that. I believe it could be done, though. You'd need a C extension module
which knew the password and installed a custom import hook to handle opening the
zip file. And disassembling the extension module would also give an attacker
the password, thus allowing them access to the zipfile.

So, as Gerhard said, it really depends on what you mean by "tamper proof".

Cheers,
Nick.
Jul 18 '05 #3

P: n/a
ad*******@eircom.net (Alan Sheehan) writes:
Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

Is it possible to load the scripts from zip files where the zip files
are password protected ?

Any other ideas ?


For py2exe created distributions, the simplest and imo most effective
thing is to specify a different extension for the source archive, maybe
app.lib instead of library.zip. This way, there's at least no hint that
is is a zip archive.

For passwords, aren't there lots of zipfile password crackers out there?
And even in a password protected zipfile you are still able to see the
filenames iirc, and unless that has changed.

Thomas
Jul 18 '05 #4

P: n/a
> I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

You could try to obfuscate the code with the pyobfuscate package. The
scripts will be easy to reverse, but difficult to understand. I haven't
tried it because I haven't had this need, but it shoul work:

http://www.lysator.liu.se/~astrand/p...s/pyobfuscate/

Regards,
Josef
Jul 18 '05 #5

P: n/a
RCS
Alan Sheehan wrote:
Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?


An interesting question is, what makes your source code so innovative as
to mandate this tamper proof thing?

Just wondering.

QXX


Jul 18 '05 #6

P: n/a
Alan Sheehan <ad*******@eircom.net> wrote:
Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?


Like for any other language, the code you distribute _can_ be
decompiled, analyzed, studied, and modified, by any attacker determined
enough to bypass the technical and legal barriers. If your code is
worth protecting, then it's worth attacking.

Like for any other language, a solid solution is to put crucial parts of
your application on a server that is entirely under your control,
accessed by the rest of the application (the part that you distribute)
via any distributed processing technology -- Corba, XML-RPC, pyro,
whatever. The pluses and minuses are obvious: your application will run
only with network access (which is more and more widely available but
not yet universal); OTOH, you can exert fine control on who and when can
access the crucial parts (by subscription, pay per use, whatever
business model you fancy). It's the only approach that can be made as
solid as the server you use, which is _very_ solid. Even burning some
algorithms into a dedicated chip is less robust, since chips _do_ get
reverse engineered / decompiled too.

If all you want is to make the barriers as high as reasonably feasible,
crypted archives with a dedicated pyrex-coded module to decrypt and make
them accessible to the main program is one way. Legal barriers however
tend to work better than technical ones, which may be perceived as
interesting challenges and stimulate attacks. Note that just about any
piece of software that's widespread, whatever language and protection
scheme it may have used, is available in cracked form in the `warez'
circuits. Go server-side as much as you can, and rely on the awesome
coercive powers of the state for the rest -- "go legal, young man".
Alex
Jul 18 '05 #7

P: n/a
Alan Sheehan wrote:
Hi pythonistas,

I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

I understand I can supply .pyc or .pyo files but they can easily be
reverse engineered I am told.

Is it possible to load the scripts from zip files where the zip files
are password protected ?

Any other ideas ?
Use Pyrex in order to convert the critical parts to C modules ...

Regards

Armin

Many thanks,

Alan

Jul 18 '05 #8

P: n/a
RCS schrieb:
I am looking for methods of deploying applications with end users so
that the python code is tamper proof. What are my options ?

An interesting question is, what makes your source code so innovative as
to mandate this tamper proof thing?


I can think of 3 reasons to prevent tampering:

- You need money and want to sell your software on a "per seat" basis.

- You don't want customers to fiddle with your code and then innocently
call for support and demand "bug fixes" for free.

- Your customer demands closed source because the code contains trade
secrets.

Protecting source has nothing to do with innovation. It's about making
money.

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Jul 18 '05 #9

P: n/a
On Mon, 2004-11-29 at 18:04, Peter Maas wrote:
I can think of 3 reasons to prevent tampering:

- You need money and want to sell your software on a "per seat" basis.
If you mean that you therefore must add built-in copy-protection, then
sure. Users will always get around it if they really want to, so
tamper-resistance is probably closer to the truth, but it'll slow them
down.

On the other hand, one can license software per-seat quite effectively
without software enforcement, or with only informative software
enforcement ("By the way, you appear to be over your seat count."). In
many cases this is good enough - the user can always crack / steal your
software, tamper resistant or not (witness: the games industry), and
code without copy protection is a LOT friendly.

For example, my employer currently relies on software that has a dongle.
The software manufacturer has gone out of business, so if that dongle
dies we're in trouble, as development of a replacement is moving slowly.
In future, if we're given the choice between a product that's superior
in price or functionality but has opressive copy protection and one
that's more limited or more expensive, but has no software enforcement
of copy protection, we'll buy the inferior or overpriced one.

We're quite capable of monitoring our own license compliance. Those who
aren't are also generally quite capable of 'fixing' the software, tamper
resistant or not, so I really don't see the point.
- You don't want customers to fiddle with your code and then innocently
call for support and demand "bug fixes" for free.
There, what you really want is tamper-evident code not tamper-proof
code. That's quite a bit more practical IMO, and may be a good place to
look at digital signing.
- Your customer demands closed source because the code contains trade
secrets.


My understanding is that that's never guaranteed safe, no? Or are
restrictions against reverse engineering now commonly enforcable?

--
Craig Ringer

Jul 18 '05 #10

P: n/a
Craig Ringer schrieb:
On Mon, 2004-11-29 at 18:04, Peter Maas wrote:

I can think of 3 reasons to prevent tampering:
[...] My understanding is that that's never guaranteed safe, no? Or are
restrictions against reverse engineering now commonly enforcable?


It's not guaranteed but if protection works in 99.9% of all instal-
lations it makes sense, at least if you are not producing highly
visible software like Windows.

Reverse engineering may be possible but in most cases it is a huge
effort. Think of the samba project which builds Windows server
software by analyzing network packets and this is probably easier
than to analyze machine code.

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Jul 18 '05 #11

P: n/a
On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:
If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?


To avoid embarassment.

--
Grant Edwards grante Yow! Why don't you
at ever enter and CONTESTS,
visi.com Marvin?? Don't you know
your own ZIPCODE?
Jul 18 '05 #12

P: n/a
On Monday 29 November 2004 14:13, Grant Edwards wrote:
On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:
If the "reverse engineering" argument boils down to "protecting source doesn't make sense" then why does Microsoft try so hard to protect
its sources?


To avoid embarassment.


+1 QOTW

Jul 18 '05 #13

P: n/a
+1 QOTW

Jul 18 '05 #14

P: n/a
Grant Edwards schrieb:
On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:
If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?

To avoid embarassment.


:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Jul 18 '05 #15

P: n/a
Peter Maas wrote:
Grant Edwards schrieb:
On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:
If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?


To avoid embarassment.


:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.


BWAAHHAHAHA!!!

Damn you!! Coke is so hard to clean off a keyboard!!

Good laugh, thankyou so much :-D
--
Gustavo Córdova Avila <gu*************@q-voz.com>
<mailto:gu*************@q-voz.com>
*Tel:* +52 (81) 8130-1919 ext. 127
Integraciones del Norte, S.A. de C.V.
Padua #6047, Colonia Satélite Acueducto
Monterrey, Nuevo León, México.
Jul 18 '05 #16

P: n/a
Gustavo Córdova Avila wrote:
Peter Maas wrote:
Grant Edwards schrieb:
On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?
To avoid embarassment.

:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.


BWAAHHAHAHA!!!

Damn you!! Coke is so hard to clean off a keyboard!!


Yeah, I hate the way the powder builds up between the keys.

Oh.

You meant the _drink_...

-Peter
Jul 18 '05 #17

P: n/a
Peter Hansen wrote:
Gustavo Córdova Avila wrote:
Peter Maas wrote:
Grant Edwards schrieb:

On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:

> If the "reverse engineering" argument boils down to "protecting source
> doesn't make sense" then why does Microsoft try so hard to protect
> its sources?

To avoid embarassment.

:) This cannot be the whole truth otherwise they wouldn't release
embarrasing binaries.

BWAAHHAHAHA!!!

Damn you!! Coke is so hard to clean off a keyboard!!

Yeah, I hate the way the powder builds up between the keys.

Oh.

You meant the _drink_...

-Peter


Nice. Very nice!!
Jul 18 '05 #18

P: n/a
Grant Edwards wrote:
On 2004-11-29, Peter Maas <pe***@somewhere.com> wrote:
If the "reverse engineering" argument boils down to "protecting source
doesn't make sense" then why does Microsoft try so hard to protect
its sources?


To avoid embarassment.


+1 QOTW (Everyone else was doing it, I just wanted to be popular!)
Jul 18 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.