[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

encrypting python modules

Paul Sijben

1/11/2008 9:45:00 AM

Hello,

this question has come by repeatedly in several guises over the past
years but has never been solved in this forum as far as I have been able
to Google.

However since so many people are asking the question, I hope someone has
made a solution and is willing to share it.

The problem: I have a client-server app written in python. I want to
make sure that the client is not:
1) destabilized by users accidentally or on purpose dropping python
files in the path (after which calling the helpdesk will not be useful)
2) extended with "new features" without me knowing about it (again
resulting in calls to my helpdesk...)
3) trivially decompiled.

Added issue, I want the client to be able to update itself when I have
fixed bugs or created new functionality.

I know that I can not stop a dedicated hacker deconstructing my code.
Since all clients need to go through the server I am not afraid of
"freeloaders".

I am now considering overriding import with some code that will only
import modules signed and crypted by me.

However I can not imagine that I would be the first one planning to do this.
So is there a solution like this available somewhere?

Paul Sijben
15 Answers

Ben Finney

1/11/2008 10:47:00 PM

0

Paul Sijben <paul.sijben@xs4all.nl> writes:

> I know that I can not stop a dedicated hacker deconstructing my code.

A direct consequence of this is that you can not stop *anyone* from
deconstructing your code if it's in their possession. It takes only
one dedicated, skilled person to crack your obfuscation system and
distribute an automated process for doing so to anyone interested.

> However I can not imagine that I would be the first one planning to
> do this. So is there a solution like this available somewhere?

Trying to make bits uncopyable and unmodifiable is like trying to make
water not wet.

--
\ "The shortest distance between two points is under |
`\ construction." -- Noelie Alito |
_o__) |
Ben Finney

Mike Meyer

1/11/2008 11:22:00 PM

0

On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney <bignose+hates-spam@benfinney.id.au> wrote:

> Paul Sijben <paul.sijben@xs4all.nl> writes:
> > I know that I can not stop a dedicated hacker deconstructing my code.
> A direct consequence of this is that you can not stop *anyone* from
> deconstructing your code if it's in their possession. It takes only
> one dedicated, skilled person to crack your obfuscation system and
> distribute an automated process for doing so to anyone interested.

Except that's not what he's trying to do.

> > However I can not imagine that I would be the first one planning to
> > do this. So is there a solution like this available somewhere?
> Trying to make bits uncopyable and unmodifiable is like trying to make
> water not wet.

And again, that's not what he's trying to do. He wants to arrange
things so that he doesn't have to support unmodified versions of his
code, by making it impossible to import modified modules. While that's
still impossible, once you decide how difficult you want to make it
for people to do that, you can *probably* make it that difficult - but
the process gets progressively more difficult and expensive as you
make it harder.

I think he's contemplating only the simplest, least expensive step:
adding an import hook that only allows imports of digitally signed
modules. If planning to deploy on Windows, where he has to bundle a
python with his application, he may well implement the hook in the
interpreter instead of in python, so it's harder to find.

If you wanted to go to the expense, you could probably arrange things
so that the digital signatures are the more vulnerable attack vectors,
but I'd expect to spend millions of dollars doing so.

<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/consu...
Independent Network/Unix/Perforce consultant, email for more information.

Steven D'Aprano

1/12/2008 12:11:00 AM

0

On Fri, 11 Jan 2008 10:44:36 +0100, Paul Sijben wrote:

> Hello,
>
> this question has come by repeatedly in several guises over the past
> years but has never been solved in this forum as far as I have been able
> to Google.
>
> However since so many people are asking the question, I hope someone has
> made a solution and is willing to share it.
>
> The problem: I have a client-server app written in python. I want to
> make sure that the client is not:
> 1) destabilized by users accidentally or on purpose dropping python
> files in the path (after which calling the helpdesk will not be useful)
> 2) extended with "new features" without me knowing about it (again
> resulting in calls to my helpdesk...)

How often do these things *actually* happen?

Of those that actually do it, how many are clueless enough that when they
run into problems they blame you for it? (And remember that you won't
even find out about the non-clueless ones.)




--
Steven

Marc 'BlackJack' Rintsch

1/12/2008 1:08:00 AM

0

On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote:

> Trying to make bits uncopyable and unmodifiable is like trying to make
> water not wet.

Certainly not. I can put water into the freezer, but I have no idea how
to make bits uncopyable and unmodifiable while still delivering them to
the clients for execution. ;-)

Ciao,
Marc 'BlackJack' Rintsch

Ben Finney

1/12/2008 1:44:00 AM

0

Marc 'BlackJack' Rintsch <bj_666@gmx.net> writes:

> On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote:
>
> > Trying to make bits uncopyable and unmodifiable is like trying to
> > make water not wet.
>
> Certainly not. I can put water into the freezer

Turning it into ice, and making it not useable as water. So, to the
extent you've made it not-wet, you've also made it not-water.

To torture the analogy further, this would be equivalent to engraving
the bits in stone and sealing the whole in a concrete slab. While
still technically the bits can be extracted, the extent to which they
are uncopyable and unmodifiable is exactly the extent to which they
are useless as bits. As soon as they become available for use as
digital bits in some way, they become available for copying and
modifying again.

--
\ "People demand freedom of speech to make up for the freedom of |
`\ thought which they avoid." -- Soren Aabye Kierkegaard |
_o__) (1813-1855) |
Ben Finney

Paul Sijben

1/14/2008 8:50:00 AM

0


> How often do these things *actually* happen?
>
> Of those that actually do it, how many are clueless enough that when they
> run into problems they blame you for it? (And remember that you won't
> even find out about the non-clueless ones.)
>
>
This is a rethorical question, right?

Paul Sijben

1/14/2008 9:01:00 AM

0

Mike,

thanks for the constructive feedback.Indeed i probably need to patch
import in some way. Looks like there is no standard way to get this
done. So I guess I have do it myself...

In the famous last words department: how hard can that be? ;-)

Paul



Mike Meyer wrote:
> On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney <bignose+hates-spam@benfinney.id.au> wrote:
>
>> Paul Sijben <paul.sijben@xs4all.nl> writes:
>>> I know that I can not stop a dedicated hacker deconstructing my code.
>> A direct consequence of this is that you can not stop *anyone* from
>> deconstructing your code if it's in their possession. It takes only
>> one dedicated, skilled person to crack your obfuscation system and
>> distribute an automated process for doing so to anyone interested.
>
> Except that's not what he's trying to do.
>
>>> However I can not imagine that I would be the first one planning to
>>> do this. So is there a solution like this available somewhere?
>> Trying to make bits uncopyable and unmodifiable is like trying to make
>> water not wet.
>
> And again, that's not what he's trying to do. He wants to arrange
> things so that he doesn't have to support unmodified versions of his
> code, by making it impossible to import modified modules. While that's
> still impossible, once you decide how difficult you want to make it
> for people to do that, you can *probably* make it that difficult - but
> the process gets progressively more difficult and expensive as you
> make it harder.
>
> I think he's contemplating only the simplest, least expensive step:
> adding an import hook that only allows imports of digitally signed
> modules. If planning to deploy on Windows, where he has to bundle a
> python with his application, he may well implement the hook in the
> interpreter instead of in python, so it's harder to find.
>
> If you wanted to go to the expense, you could probably arrange things
> so that the digital signatures are the more vulnerable attack vectors,
> but I'd expect to spend millions of dollars doing so.
>
> <mike

Robert Latest

1/14/2008 9:03:00 AM

0

Paul Sijben wrote:

> The problem: I have a client-server app written in python. I want to
> make sure that the client is not:
> 1) destabilized by users accidentally or on purpose dropping python
> files in the path (after which calling the helpdesk will not be useful)
> 2) extended with "new features" without me knowing about it (again
> resulting in calls to my helpdesk...)

You could check the MD5 hashes of your files.

robert

Paul Sijben

1/14/2008 10:59:00 AM

0

Robert Latest wrote:
> Paul Sijben wrote:
>
>> The problem: I have a client-server app written in python. I want to
>> make sure that the client is not:
>> 1) destabilized by users accidentally or on purpose dropping python
>> files in the path (after which calling the helpdesk will not be useful)
>> 2) extended with "new features" without me knowing about it (again
>> resulting in calls to my helpdesk...)
>
> You could check the MD5 hashes of your files.
>
> robert

indeed but I still need to hook into import to do that reliably, right?

Steven D'Aprano

1/14/2008 11:09:00 AM

0

On Mon, 14 Jan 2008 09:49:49 +0100, Paul Sijben wrote:

>> How often do these things *actually* happen?
>>
>> Of those that actually do it, how many are clueless enough that when
>> they run into problems they blame you for it? (And remember that you
>> won't even find out about the non-clueless ones.)
>>
>>
> This is a rethorical question, right?

No, it's a serious question. You distribute Python code, and you're
worried that your users will modify the source code and then neglect to
mention it when they report bugs which they introduced.

Before you build an elephant-proof fence around your house, it is quite
reasonable to ask whether or not there are actually elephants in your
neighbourhood.



--
Steven