Selling Python Software

[Will Stuyvesant]

Suppose I want to sell a (small, 1000 lines) Python program. It is a
commandline program for database applications and I have a customer.
The customer wants to "try it out" before buying. The try-out version
should be a full, complete, version.

As much as I like the opensource movement, I have a problem now. If I
just give them the Python source code then they can show it to their
programmers and they have no reason anymore to pay money to me. Sure
that would break our agreements, but you know bussiness, legal issues.
The thing the customer is interested in is the algorithm used in the
program. Not much I could do about such a scenario effectively.

I tried py2exe before, but someone told me it is always possible to
decompile...rev ealing the source code.

Anybody has a solution to this, besides more legal paperwork (I am in
europe...forget about claiming your rights here)? Is it not possible
to give away a Windows .exe file that can not be decompiled (or only
with *extreme* difficulty)?

[Erik Max Francis]

Will Stuyvesant wrote:

I tried py2exe before, but someone told me it is always possible to
decompile...rev ealing the source code.

It's always possible to decompile programs compiled to machine code, as
well, you know. Ultimately, every software developer must defend
himself with licenses and legal means, not technical ones.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ The most exhausting thing in life is being insincere.
\__/ Anne Morrow Lindbergh

[Alex Martelli]

Erik Max Francis wrote:

Will Stuyvesant wrote:

I tried py2exe before, but someone told me it is always possible to
decompile...rev ealing the source code.

It's always possible to decompile programs compiled to machine code, as
well, you know. Ultimately, every software developer must defend
himself with licenses and legal means, not technical ones.

....unless said SW developer keeps the extremely precious parts of his
SW safely on a network server under his control (yes, it IS possible
to technically secure that -- start with an OpenBSD install...:-) and
only distributes the run-of-the-mill "client-oid" parts he doesn't
particularly mind about. The server-side SW can supply the precious
parts of the overall program's functionality to the client-side SW
via secure webservices or proprietary protocols; this also allows you
to enforce different business models (subscription, pay-per-use, ...)
more easily than distributing things does.

Very little software is WORTH protecting so closely, but for that
1 in 1000, or whatever, this option IS, IMHO, worth considering.
Alex

[Alex Martelli]

Will Stuyvesant wrote:

Suppose I want to sell a (small, 1000 lines) Python program. It is a
commandline program for database applications and I have a customer.
The customer wants to "try it out" before buying. The try-out version
should be a full, complete, version.

As much as I like the opensource movement, I have a problem now. If I
just give them the Python source code then they can show it to their
programmers and they have no reason anymore to pay money to me. Sure
that would break our agreements, but you know bussiness, legal issues.
The thing the customer is interested in is the algorithm used in the
program. Not much I could do about such a scenario effectively.

I tried py2exe before, but someone told me it is always possible to
decompile...rev ealing the source code.
Yes, exactly as could be done if you coded your precious algorithm
in C, machine-language, or whatever: if you distribute executable
code it CAN be cracked and the algorithm reverse-engineered (see any
warez site: game companies go to HUGE length to defend their programs
and they STILL get cracked anyway).

Anybody has a solution to this, besides more legal paperwork (I am in
europe...forget about claiming your rights here)? Is it not possible
to give away a Windows .exe file that can not be decompiled (or only
with *extreme* difficulty)?

"Can not be decompiled" is impossible whatever language you're using.

"*extreme* difficulty" is in the eye of the beholder. You can e.g.
add layers of encryption/decription to the bytecode, etc, but whatever
you do somebody else can undo. Depending on the relative skills of
you and the "somebody else" the ratio (your effort to keep things
secret, to theirs to uncover them) can be any.

Couldn't you keep some crucial part of your precious algorithm OFF
the code you distribute, and have said code access said part via
webservices towards your personally-controlled, secure host?
Alex

[Radovan Garabik]

Will Stuyvesant <hw***@hotmail. com> wrote:

Suppose I want to sell a (small, 1000 lines) Python program. It is a
commandline program for database applications and I have a customer.
The customer wants to "try it out" before buying. The try-out version
should be a full, complete, version.

As much as I like the opensource movement, I have a problem now. If I
just give them the Python source code then they can show it to their
programmers and they have no reason anymore to pay money to me. Sure
that would break our agreements, but you know bussiness, legal issues.
The thing the customer is interested in is the algorithm used in the
program. Not much I could do about such a scenario effectively.

I tried py2exe before, but someone told me it is always possible to
decompile...rev ealing the source code.

Anybody has a solution to this, besides more legal paperwork (I am in
europe...forget about claiming your rights here)? Is it not possible
to give away a Windows .exe file that can not be decompiled (or only
with *extreme* difficulty)?

use upx to pack it. Of course, it is always possible to unpack
the executable, but if an effort to do so is bigger that money they would
pay you, it would not be in their interest. Or enter into google
"encrypt executable" and it will give you a plethora of links.

--
-----------------------------------------------------------
| Radovan GarabÃ*k http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__ garabik @ kassiopeia.juls .savba.sk |
-----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

[John J. Lee]

Alex Martelli <al***@aleax.it > writes:
[...]

"Can not be decompiled" is impossible whatever language you're using.

"*extreme* difficulty" is in the eye of the beholder. You can e.g.
add layers of encryption/decription to the bytecode, etc, but whatever
you do somebody else can undo. Depending on the relative skills of
you and the "somebody else" the ratio (your effort to keep things
secret, to theirs to uncover them) can be any.

[...]

Whie this is all true, you seem to put undue emphasis on the fact that
it's always *possible* to decompile stuff. Isn't the point you make
in your last sentence actually crucial here? The game is to make your
opponent (customer ;-) incur more expense in decompiling it than it
would cost to just go ahead and pay you, is it not? And yeah, you
also have to take into account how much it costs you to come up with
the protection scheme, of course.

So, is there a good practical solution of that form, for Python code
of this sort of size (or any other size)? I suspect the answer for
standard Python may be no, while the answer for optimising compilers
may be yes -- but that's just a guess.
John

[Peter Hansen]

Will Stuyvesant wrote:

Suppose I want to sell a (small, 1000 lines) Python program. It is a
commandline program for database applications and I have a customer.
The customer wants to "try it out" before buying. The try-out version
should be a full, complete, version.

As much as I like the opensource movement, I have a problem now. If I
just give them the Python source code then they can show it to their
programmers and they have no reason anymore to pay money to me. Sure
that would break our agreements, but you know bussiness, legal issues.
The thing the customer is interested in is the algorithm used in the
program. Not much I could do about such a scenario effectively.

I tried py2exe before, but someone told me it is always possible to
decompile...rev ealing the source code.

Anybody has a solution to this, besides more legal paperwork (I am in
europe...forget about claiming your rights here)? Is it not possible
to give away a Windows .exe file that can not be decompiled (or only
with *extreme* difficulty)?

I've read the other answers here, which pretty much just repeat past
discussions, but I think the various respondents have to some extent
not paid close attention to your *specific* needs here.

Alex is pretty close to the mark, but there's no need to be as extreme
as his "start with OpenBSD install" response to Erik Max Francis, as
you definitely don't need the high security of this approach.

Nevertheless, the server-based-code approach is definitely the only
one that is worth the effort here, considering that the effort is
practically nil (or should be, as if you're really trying to sell
commercial software, having access to an Internet server should be
a pretty trivial thing). You could use Pyro to make the fact that
part of the system is running on a server practically transparent
both to the potential customer and to you. Moving the server-based
code into the real application once they've paid you would be a
tiny last step.

"Only decompiled with *extreme* difficulty?" There is no such approach
within your means, I'm afraid, and there are any number of stories
from the real world which ipso facto prove it. There *are* hardware-key
based solutions, but I can tell you from personal experience that
they will really not stop a determined attacker and in any case they
will cost more to implement than the potential income from your
1000-line Python program.

On another note, having been in the consulting business myself for
years (before my current job) I would give you this advice. Don't
underestimate the value of a trusting business relationship, nor
the value of a decent written contract. If you are right that this
customer would cheat you at the earliest opportunity, you are
likely going to find yourself cheated in some manner no matter
what you do. Without adequate attention to written agreements and
a good mutual understanding, you could just as well find yourself
in the position of having delivered the final, unprotected version
to them and still not get paid because "it doesn't meet the
requirements you promised to implement" or something like that.

A decent license *should* be adequate for just about any customer
with whom you ought to be doing business. IMHO.

-Peter

[Alex Martelli]

John J. Lee wrote:

Alex Martelli <al***@aleax.it > writes:
[...]

"Can not be decompiled" is impossible whatever language you're using.

"*extreme* difficulty" is in the eye of the beholder. You can e.g.
add layers of encryption/decription to the bytecode, etc, but whatever
you do somebody else can undo. Depending on the relative skills of
you and the "somebody else" the ratio (your effort to keep things
secret, to theirs to uncover them) can be any. [...]

Whie this is all true, you seem to put undue emphasis on the fact that
it's always *possible* to decompile stuff. Isn't the point you make
in your last sentence actually crucial here? The game is to make your

Of course it's crucial. But so what?
opponent (customer ;-) incur more expense in decompiling it than it
would cost to just go ahead and pay you, is it not? And yeah, you
also have to take into account how much it costs you to come up with
the protection scheme, of course.
Of course. It can be framed as a zero-sum game of incomplete
information on both sides. You don't really know that anybody
will ever try to steal your code -- any eurocent you invest in
protecting it might be a complete waste, if nobody ever even
dreams of so trying. At the other extreme, whoever tries to do
the stealing might be technically good and well informed, as well
as dishonest, so that in 5 minutes they destroy 5 days' worth of
work by you on "protection ". In both cases, investing in such
protection is throwing money away from your POV. The hypothetical
adversary, for his part, may not know and be unable to gauge the
effort needed to crack and steal your code -- if he's not well
informed nor competent, he might just be flailing around for 10
days and stop just before the 11th day's effort WOULD deliver the
illegal goods he's after.

Of course, guess what IS the effect on this game's payoff matrix
of discussing technical possibilities in a public forum. "I give
you three guesses, but the first two don't count"...:-).

So, is there a good practical solution of that form, for Python code
of this sort of size (or any other size)? I suspect the answer for
standard Python may be no, while the answer for optimising compilers
may be yes -- but that's just a guess.

The answer is no for either case. I've spent too high a proportion of
my life (at my previous employer) putting "protection systems" in
place (including optimising compilers, weird machine-code tricks,
even in one case some microcode hacks), and it was the worst waste of
my time anybody could possibly devise.

Part of the problem is, that the "warezdoodz culture" is stacked
against you. If you DO come up with a novel approach, that is a
challenge to guys who SPEND THEIR LIFE doing essentially nothing
but cracking software-protection schemes *for fun*. Even if it's
taken you 10 hours and it makes them spend 20 hours, they _do not
account this as a cost_, any more than a crossword enthusiast sees
as "a cost" the hours he spends cracking a particularly devious
crossword -- indeed, once said enthusiast is good enough, unless
the puzzle it's hard it's no fun. But don't think that therefore
using an obviously weak scheme is a counter: just below the top
crackerz there are layers and layers of progressively less capable
ones desperate to put notches in their belt.

To me, playing such zero-sum games is a net loss and waste of time
because with the same investment of my time and energy I could
be playing games with sum _greater_ than zero, as is normally the
case for technical development not connected to security issues
(i.e., where the only "net benefit" of the development doesn't
boil down to frustrating somebody else's attempts at cracking and
stealing) and even for much security-related work (e.g., most of
OpenBSD's developments help against plain old BUGS and crashes just
as much as they help against wilfull attacks against you).

There exist technical solutions that DO make it impossible for
anybody to crack your precious algorithms: just make those precious
algorithms available only from a network server under your total
control, NEVER giving out executable code for them. (You can then
work on securing the network server, etc, but these ARE problems
that are technically susceptible to good solutions). If anybody
refuses this solution (surely a costly one on some parameters) it
probably means their algorithms aren't worth all that much after
all (there may be connectivity, latency or bandwidth problems in
some cases, of course, but with the spread of network technologies
these are progressively less likely to apply as time goes by). If
the algorithms aren't worth all that much, they're not worth me
spending my time in zero-sum games to protect them -- lawyers are
probably more emotionally attuned than engineers to playing zero-
sum games, since so much of legal practice vs so little engineering
practice is like that, so that may be a back-up possibility.

It's not about programming languages at all. In the end, "clever"
schemes that are presumed to let people run code on machines under
their control yet never be able to "read" the code must rely on
machinecode tricks of some sort, anyway, since obviously, from a
technical viewpoint, if the code must be executable, it must be
*read* on the way to the execution engine -- if it's encrypted it
must exist in decrypted form at some point (and it can then be
captured and examined at that point), etc. Some of the code that
I was supposed to "protect" for my previous employer was in C,
Fortran, C++, and other high-level languages; some was in
machine code; other yet was in intermediate-code generated by a
proprietary scripting language; ... in the end it made no real
difference one way or another.
Alex

[Lulu of the Lotus-Eaters]

hw***@hotmail.c om (Will Stuyvesant) wrote previously:
|Is it not possible to give away a Windows .exe file that can not be
|decompiled (or only with *extreme* difficulty)?

NO! It is NOT possible.

It is not possible in Python. It is not possible in VB. It is not
possible in C#. It is not possible in C. It is not possible in
Fortran. It is, in fact, not possible in Assembly.

However, distributing a .pyc or an .exe make it require a little bit of
effort to find the underlying code... enough that someone needs to make
a conscious decision to do so, rather than "accidental ly" open the .py
file in Notepad.

Yours, Lulu...

--
mertz@ _/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: \_\_\_\_ n o
gnosis _/_/ Postmodern Enterprises \_\_
..cx _/_/ \_\_ d o
_/_/_/ IN A WORLD W/O WALLS, THERE WOULD BE NO GATES \_\_\_ z e

[Bengt Richter]

On Tue, 04 Nov 2003 09:03:51 GMT, "Andrew Dalke" <ad****@mindspr ing.com> wrote:

Bengt Richter:

OTOH, we are getting to the point where rather big functionality can beput

on a chip or tamper-proof-by-anyone-but-a-TLA-group module. I.e.,

visualize

the effect of CPUs' having secret-to-everyone private keys, along with

public keys,

Actually, we aren't. There have been various ways to pull data of
of a smart card (I recall readings some on RISKS, but the hits I
found are about 5+ years old). In circuit emulators get cheaper and
faster, just like the chips themselves. And when in doubt, you can
buy or even build your own STM pretty cheap -- in hobbiest range
even (a few thousand dollars).

Even if you knew exactly where on a chip to look, and it wasn't engineered
to have the key self-destruct when exposed, what would you do with the key?
You'd have the binary image of an executable meant to execute in the secret-room
processing core. How would you make it available to anyone else? You could re-encrypt
it with someone else's specific public key. Or distribute a program that does that,
along with the clear binary. But what if the program contains an auth challenge for the target
executing system? Now you have to reverse engineer the binary and see if you can modify it
to remove challenges and checks and still re-encrypt it to get it executed by other processors.
Or you have to translate the functionality to a program that runs in clear mode on the ordinary cores.
Sounds like real work to me, even if you have a decompyler and the inter-core comm specs.
Of course, someone will think it's fun work. And they would get to start over on the next program,
even assuming programs encrypted with the public key of the compromised system would be provided,
so there better not be a watermark left in the warez images that would indentify the compromised
system. Or else they would get to destroy another CPU module to find its key. Probably easier the
second time, assuming no self-destruct stuff ;-)

and built so they can accept your precious program code wrapped in a PGPencrypted

message that you have encrypted with its public key.

Some of the tricks are subtle, like looking at the power draw.
Eg, suppose the chip stops when it finds the key is invalid. That
time can be measured and gives clues as to how many steps it
went through, and even what operations were done. This can
turn an exponential search of key space into a linear one.

That was then. Plus remember this would not be an isolated card chip that you can
probe, it's one or more specialized cores someplace on a general purpose
multi-cpu chip that you can't get at as a hobbyist, because opening it without destroying
what you want to look at requires non-hobby equipment, by design.

This is not so magic. You could design a PC with a locked enclosure andspecial BIOS

to simulate this, except that that wouldn't be so hard to break into. But

the principle

is there. Taking the idea to SOC silicon is a matter of engineering, not

an idea break-through

(though someone will probably try to patent on-chip stuff as if it were

essentially different

and not obvious ;-/)

But the counter principle (breaking into a locked box in an uncontrolled
environment) is also there. There are a lot of attacks against smart
cards (eg, as used in pay TV systems), which cause improvements (new
generation of cards), which are matched by counter attacks.

These attacks don't require the resources of a No Such Agency,
only dedicated hobbiest with experience and time on their hands.

Sounds like an article of faith ;-)
Andrew
da***@dalkescie ntific.com
P.S.
I did have fun breaking the license protection on a company's
software. Ended up changing one byte. Took about 12 hours.
Would have been less if I knew Solaris assembly. And I did
ask them for permission to do so. :)

Changed a conditional jump to unconditional? Some schemes aren't so
static and centralized ...

I once ran into a scheme that IIRC involved a pre-execution snippet of code that had to
run full bore for _lots_ of cycles doing things to locations and values in
the program-to-be-executed that depended on precise timing and obscured info.
I guess the idea was that if someone tried to trace or step through it, it would
generate wrong locations and info and also stop short and the attacker would have
to set up to record memory addresses and values off the wires to figure out what to change,
but even then they would run into code that did mysterious randomly sprinkled
milestone checks, so capturing the core image after start wasn't free lunch either.
Plus it had to run in a privileged CPU mode, and it wasn't a stand-alone app, it
was part of an OS ... that wasn't open source ... and you didn't have to tools to rebuild...
This was just some code I stumbled on, I may have misunderstood, since I didn't
pursue it, being there for other reasons. But that was primitive compared to what you
could do with specialized chip design.

Regards,
Bengt Richter