Python obfuscation

Perhaps this could be a PEP:

1) Add a system path for decryption keys.
2) Add a system path for optional decryptors supplied by user
(to satisfy US Export Control)
3) When importing a module try: import routine except importation
error : for all decryptors present for all keys present run decryptor
upon module and retry, finally raise importation error.

With PGP encryption one could encrypt the pyc's with the private key
and sell a public key to the end user.

The Eternal Squire

Nov 9 '05 #5

Yu-Xi Lim

Steve Holden wrote:

Before adding complex protection mechanisms to your code you first need
some code worth protecting, which is to say it should have some novel
features or represent a lot of work that offers useful integrated
functionality for a task or a skill area.

Most inquiries of this nature appear to fall at that first hurdle.

There are things you can do, but I'm always keenly aware that very few
users of a program have both the skills and the inclination to rip off
the code even when the source is distributed as part of the product.
Personally I've never bothered with obfuscation, and prefer to rely on
copyright when I deliver code to customers.

As you said, if you have some novel features, you will need obfuscation.
Copyright doesn't protect the process and patents may take a while. In
the meanwhile, good obfuscation is reasonable protection, imho.

But I think you failed to note that it may not be a novel feature or
useful functionality. In fact, it might be the opposite: a function the
users want removed. A typical example would be a shareware registration
or nag screen. When the users have to start paying, they might then feel
inclied to "rip off the code", or in this case, rip out the code.

Nov 9 '05 #6

"bo****@gmail.com" <bo****@gmail.com> writes:

How effective can it be when python is designed to make writing this
kind of code hard(hopefully impossible) ? The most effective would be
renaming function and may be variables but if the functions are kept
short, they would at most looks like haskell ;-)

I haven't looked at obfuscator, so I have *no idea* how it works. The
following is how I'd do it.

Step one: globally replace all names in all python module withb names
that are composed of long strings of l, 1, 0 and 0. Fixing
cross-module references should be fun. Don't just make them random -
make them all start with the same sequence, and end with the same
sequence, having differences only in the middle.

Step two: repeat this process for the contents of binary modules, not
neglecting __builtins__. In this case, you probably can't remove the
old names, but you can add new things to the module, and make sure you
only reference those.

I'm not sure how to go about fixing things that are referenced by name
in binary modules. Maybe you'll have to leave those names in the
modules. But you an make sure that all references in Python source use
the new, binary-like names.

<mike

--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 9 '05 #7

petantik

Yu-Xi Lim wrote:

Steve Holden wrote:
Before adding complex protection mechanisms to your code you first need
some code worth protecting, which is to say it should have some novel
features or represent a lot of work that offers useful integrated
functionality for a task or a skill area.

Most inquiries of this nature appear to fall at that first hurdle.

There are things you can do, but I'm always keenly aware that very few
users of a program have both the skills and the inclination to rip off
the code even when the source is distributed as part of the product.
Personally I've never bothered with obfuscation, and prefer to rely on
copyright when I deliver code to customers.

As you said, if you have some novel features, you will need obfuscation.
Copyright doesn't protect the process and patents may take a while. In
the meanwhile, good obfuscation is reasonable protection, imho.

But I think you failed to note that it may not be a novel feature or
useful functionality. In fact, it might be the opposite: a function the
users want removed. A typical example would be a shareware registration
or nag screen. When the users have to start paying, they might then feel
inclied to "rip off the code", or in this case, rip out the code.

This is what I am talking about. If you look at programs written in C,
or others that compile into native binaries, there are many protection
schemes which are mainly used not to protect some novel process but to
ensure that their commercial software remains marketable.

People who download cracks/serial numbers rarely care about copyright.
So when python is used in more commercial software some sort of high
grade obfuscation may be needed. These packers sometimes also have an
embedded compression so that it can decompress the code 'on the fly'
reducing filesizes

http://petantik.blogsome.com - A Lucid Look at Reality

Nov 9 '05 #8

sjdevnull

Mike Meyer wrote:

Step one: globally replace all names in all python module withb names
that are composed of long strings of l, 1, 0 and 0. Fixing
cross-module references should be fun. Don't just make them random -
make them all start with the same sequence, and end with the same
sequence, having differences only in the middle.

Eliminating the original variable names may be useful in obfuscation,
but this doesn't seem to buy much over just replacing with random
strings; it's trivial to do a similar replacement to go from "10Oll10"
strings to "firstVariable", "secondVariable", etc strings.

Nov 9 '05 #9

Anand S Bisen

I dont know much !! But if somebody asks me this question my answer
would be to convert some of the meat inside my programs to C/C++ and
then provide the interface to those novel ideas to Python using swig.
And for another level of protection maybe use these offuscator on the
remaining Python source. What do you think ?

Anand S Bisen

petantik wrote:

Are there any commercial, or otherwise obfuscators for python source
code or byte code and what are their relative advantages or
disadvantages. I wonder because there are some byte code protection
available for java and .NET, although from what i've read these seem to
be not comprehensive as protection schemes

http://petantik.blogsome.com - Telling it like it is

Nov 9 '05 #10

Grant Edwards

On 2005-11-09, Anand S Bisen <vm*****@abisen.com> wrote:

I dont know much !! But if somebody asks me this question my
answer would be to convert some of the meat inside my programs
to C/C++ and then provide the interface to those novel ideas
to Python using swig. And for another level of protection
maybe use these offuscator on the remaining Python source.
What do you think ?

Um... sounds like an excellent way to burn hours while
introducing bugs and security problems?

--
Grant Edwards grante Yow! I feel... JUGULAR...
at
visi.com

Nov 9 '05 #11

Carl Friedrich Bolz

hi!

bo****@gmail.com wrote:

How effective can it be when python is designed to make writing this
kind of code hard(hopefully impossible) ? The most effective would be
renaming function and may be variables but if the functions are kept
short, they would at most looks like haskell ;-)

There just cannot be a python obfuscator that works for a general python
program. The problem is that on the one hand regular strings can be used
to lookup values in namespaces (e.g. with getattr) and on the other hand
the lookup of names can be controlled (e.g. with __getattr__ and
friends). Therefore any string can potentially contain a name that would
have to be changed to keep the code working after obfuscation. For
example how would you automatically obfuscate the following code:
class HelloWorld(object):
def hello(self):
return "world"

def world(self):
return "!"

if __name__ == '__main__':
h = HelloWorld()
s = "hello"
while 1:
f = getattr(h, s, None)
print s,
if f is None:
break
s = f()

While this is surely a contrived case that intentionally mixes names and
strings that are used for something in the application there are also
quite often legitimate use cases for this sort of behaviour. Duck typing
is basically based on this.

Cheers,

Carl Friedrich Bolz

Nov 10 '05 #12

Anand S Bisen <vm*****@abisen.com> wrote:

I dont know much !! But if somebody asks me this question my answer
would be to convert some of the meat inside my programs to C/C++ and
then provide the interface to those novel ideas to Python using swig.
And for another level of protection maybe use these offuscator on the
remaining Python source. What do you think ?

I think that's feeble protection. If you have valuable code, and
distribute it, people WILL crack it -- just check the warez sites for
experimental proof... EVERYTHING that people are really interested in
DOES get cracked, no matter what tricky machine-code the "protections"
are coded in.

There's ONE way to have uncrackable code -- don't distribute it, but
rather put it up on the net on a well-secured machine under your
control, available as (say) a webservice (subscription-only, pay per
use, or whatever business model you want). You can distribute all the
parts of your app that aren't worth protecting as a "fat client" app (in
Python or whatever) and keep those which ARE worth protecting on the
server that YOU control (and make sure it's very, VERY safe, of course);
and you may write the precious parts in Python, too, no problem.

This is (a minor) one of the many reasons that make webservices the way
of the future (hey, even *MSFT* noticed that recently, it seems...).
There are many other advantages, especially if you keep the clients
thin. The only issue is, your apps will require network connectivity to
execute... but these days, with airlines and train lines busy adding
wi-fi, and towns busily blanketing themselves with free wi-fi, etc, etc,
that's less and less likely to be a big problem...
Alex

Nov 10 '05 #13

Two things:

1) The decrypted modules should only reside in RAM, never in virtual
memory. Those RAM locations should be rendered inaccessible to Python
code.

2) Only sell to an honest customer willing to be locked into
nondisclosure agreements. This goes back to the maxim of good
salesmanship: Know Your Customer.

By definition, a lock keeps honest people out. The object of a lock is
to make it too expensive for all but the most dishonest, desperate, or
nihilistic to get into the house, because they can always smash a
window or a door open.

IMHO, I have never encountered a dishonest developer or business owner
who at the same time possessed anything remotely resembling a rational
business model. A person who cannot afford to get tools honestly is
seldom able to accomplish anything significant or constructive from a
business point of view with tools obtained dishonestly.

Consider EDA software like Cadence, Matlab, or BEACON that is guarded
by network license servers. The temptation is very strong for an
individual to rip it off, but then consider all the user technical
support and bug fixes that go into the package. Most relatively honest
people see a strong lock and get the message not to try. The others
who may rip off a locked package, but then the package becomes
worthless not because it doesn't work, but because the thief has to
work completely outside the knowledge base that an honest copy has
access to.

I have heard of the warez culture, but it seems to be nihilistic in the
extreme. I don't search for warez, I don't touch warez, and I do not
recommend anyone else to do so, because using it is simply bad business
practice and will get one ostracised by the very people one wants to
sell to. But at the end of the day it seems to serve as an
unauthorized marketing and sales channel to whet the appetites for
people to try the real thing.

The Eternal Squire

Nov 10 '05 #14

yepp

The Eternal Squire wrote:

1) The decrypted modules should only reside in RAM, never in virtual
memory. Those RAM locations should be rendered inaccessible to Python
code.
I'm starting to understand why FOSS developers are said to be productive
above the average: they don't have to mess their brains with stuff like
that.
snip

IMHO, I have never encountered a dishonest developer or business owner
who at the same time possessed anything remotely resembling a rational
business model.

Ah, what was the name of that company in ... mh, was it Redmond?

Once you got the model of free and open source software you can't but shake
your head at obfuscating people treating their users as enemies.
Intellectual property suffers in most cases from a significant lack of the
intellectual part.

Nov 10 '05 #15

On Wed, 09 Nov 2005 15:08:15 -0500, Yu-Xi Lim wrote:

As you said, if you have some novel features, you will need obfuscation.
Copyright doesn't protect the process and patents may take a while. In
the meanwhile, good obfuscation is reasonable protection, imho.

But I think you failed to note that it may not be a novel feature or
useful functionality. In fact, it might be the opposite: a function the
users want removed. A typical example would be a shareware registration
or nag screen. When the users have to start paying, they might then feel
inclied to "rip off the code", or in this case, rip out the code.

Which leads to the important counter-question. Since there is a Python
obfuscator, is there a Python un-obfuscator? I am aware that not all
obfuscations can be reversed, but some can.
--
Steven.

Nov 10 '05 #16

On Thu, 10 Nov 2005 13:35:00 +0100, yepp wrote:

The Eternal Squire wrote:

1) The decrypted modules should only reside in RAM, never in virtual
memory. Those RAM locations should be rendered inaccessible to Python
code.

I'm starting to understand why FOSS developers are said to be productive
above the average: they don't have to mess their brains with stuff like
that.

That's not *quite* true. There are FOSS programs that actually do care
about security. For instance, if you are encrypting data, you don't want
the memory containing the plaintext to be swapped to your swap
partition, where raw disk tools can recover it.

But as a general rule, you're right. If you, the developer, don't have to
think of your users as the enemy, you'd be amazed the amount of make-work
you don't have to do.
--
Steven.

Nov 10 '05 #17

skip

Steven> But as a general rule, you're right. If you, the developer,
Steven> don't have to think of your users as the enemy, you'd be amazed
Steven> the amount of make-work you don't have to do.

+1 QOTW.

Skip

Nov 10 '05 #18

petantik

Alex Martelli wrote:

Anand S Bisen <vm*****@abisen.com> wrote:
I dont know much !! But if somebody asks me this question my answer
would be to convert some of the meat inside my programs to C/C++ and
then provide the interface to those novel ideas to Python using swig.
And for another level of protection maybe use these offuscator on the
remaining Python source. What do you think ?

I think that's feeble protection. If you have valuable code, and
distribute it, people WILL crack it -- just check the warez sites for
experimental proof... EVERYTHING that people are really interested in
DOES get cracked, no matter what tricky machine-code the "protections"
are coded in.

There's ONE way to have uncrackable code -- don't distribute it, but
rather put it up on the net on a well-secured machine under your
control, available as (say) a webservice (subscription-only, pay per
use, or whatever business model you want). You can distribute all the
parts of your app that aren't worth protecting as a "fat client" app (in
Python or whatever) and keep those which ARE worth protecting on the
server that YOU control (and make sure it's very, VERY safe, of course);
and you may write the precious parts in Python, too, no problem.

This is (a minor) one of the many reasons that make webservices the way
of the future (hey, even *MSFT* noticed that recently, it seems...).
There are many other advantages, especially if you keep the clients
thin. The only issue is, your apps will require network connectivity to
execute... but these days, with airlines and train lines busy adding
wi-fi, and towns busily blanketing themselves with free wi-fi, etc, etc,
that's less and less likely to be a big problem...
Alex

I think that is not workable because it is easy to say the the internet
is available everywhere.

It is not available in developing countries or in rural areas and so
these people who live/work there will never benefit from a webservice
type protection scheme, and what if the network in your area goes down?
bye bye app that I *really* need for tomorrow. Reliability is
important but so is protecting your code in an effective manner

I do believe that you are right about those that crack software for
kicks or money. If you look around at you local market place i'm sure
there are many 'discounted' commercial softwares/games sold. of course
the big software companies might say 'trusted computing will save us'
but I for one will never truly trust it.

Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

Nov 10 '05 #19

Ben Sizer

Alex Martelli wrote:

If you have valuable code, and
distribute it, people WILL crack it -- just check the warez sites for
experimental proof... EVERYTHING that people are really interested in
DOES get cracked, no matter what tricky machine-code the "protections"
are coded in.
That is very black and white thinking. It may be true that everything
gets cracked, but there are different degrees to which it might harm
your business model. On top of that, some users may be reluctant to
install binary cracks from obviously disreputable sources. Who knows
what spyware or viruses you could catch? Compare that to the simplicity
and safety of someone posting instructions to "open secure.py in
notepad, and change the 'if license_found:' line to 'if 1:'", for
example. No risk and even less effort than applying a patch.

If someone wants to break into your house, they will get in. But it's
still worth taking some precautions (locks, alarms, whatever) to reduce
the probability.
There's ONE way to have uncrackable code -- don't distribute it, but
rather put it up on the net on a well-secured machine under your
control, available as (say) a webservice (subscription-only, pay per
use, or whatever business model you want).
This is all well and good when:
- web access is free (it's not if you're on dialup, or on a portable
device/phone)
- web access is fast enough (it's not if you're working with certain
types of real-time games or multimedia)
- web access is convenient (it's not if you're behind a restrictive
firewall, or your country/area is poorly connected)

For example, I'd like to write a game in Python. I'd like to give the
game away free and charge for extra content. In C++ I can make it
difficult for users to share content with others who haven't paid for
it, with cryptographic hashes and the like. No, not impossible, but
difficult enough to deter most people. In Python it's much harder, when
the end user can open up the relevant file and quickly remove the
license check. No doubt this is another of the reasons why Python isn't
catching on quickly for game development, sadly.

(I'm not saying this is a deficiency of Python as such. It's just a
comment on the situation.)
This is (a minor) one of the many reasons that make webservices the way
of the future (hey, even *MSFT* noticed that recently, it seems...).

But they are not suitable for all applications, and probably never will
be.

--
Ben Sizer

Nov 10 '05 #20

Come on! I was only just trying to accomodate the OP with a plausible
method to fit his business model, based on techniques passed on to me
by my various teachers at school and my senseis at workplaces..
Please don't judge me for attempting to pass on experience. It's his
choice.

While I'd like to figure out myself a nice software package to write
and market and earn a good living now that I've walked away from the
rat race, I can also see myself having humanity as my client (the FOSS
model).

The Eternal Squire

Nov 10 '05 #21

Bill Mill

On 10 Nov 2005 08:40:17 -0800, Ben Sizer <ky*****@gmail.com> wrote:

Alex Martelli wrote:
This is (a minor) one of the many reasons that make webservices the way
of the future (hey, even *MSFT* noticed that recently, it seems...).

But they are not suitable for all applications, and probably never will
be.

Your only solution, then, is to write unpopular code. Because, as Alex
said, it will otherwise be broken into. Let's look at two very popular
pieces of code: Half-Life 2 and Windows XP. How are they secured?
Previous version of these software products used sophisticated
client-side programming to try and be secure, but the security was
nonexistant. Users share keys and cracks with each other.

Now, both of these programs require verification (phone and/or web) to
be used. The only truly secure method of assuring that they're not
used in ways you don't intend is to require the user to contact you to
use it, and that's a deal with the devil. One you might need to make
if security is that important to you, as Microsoft and Valve have
decided it is, but it's a deal with the devil nonetheless.

Peace
Bill Mill
bill.mill at gmail.com

Nov 10 '05 #22

"petantik" <pe***********@gmail.com> writes:

Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

Nah. Compiling/interpreting is an implementation detail, and
orthogonal to the issue of "high level". There are compilers for high
level languages, and interpreters for low level languages. At the
lowest level, a machine emulator is an interpreter for machine code,
which is the lowest level most programmers deal with (at least I think
it is....).

If you really wanted "compiler-like" security for Python, you could
write a Python compiler. There have been posts about a compiler that
generated C++ recently, though it's still under development, and I
haven't followed it closely. You might also consider retargetting one
of the existing Python compilers to your architecture of choice, or to
another language. You might also consider translating Python to a
language with similar capabilities for which a compiler exists, like
Common LISP.

Of course, once you've got machine code, it doesn't matter how high
level the source was. That may make getting the source back harder,
but people who are cracking your program don't want to do that - they
just want to find the place where the security happens, and either
figure out the input that will make it happy, or invert the behavior
after a test.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 10 '05 #23

On Thu, 10 Nov 2005 08:23:07 -0800, petantik wrote:

Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

Dude, a comprehension protection for *any* software can never be built
because of the fundamental nature of computers. Trying to stop bytes from
being copyable is like trying to stop water from being wet, and once
copied, all copies are identical and therefore indistinguishable.

It isn't a matter of protecting software or data. It is a question of how
hard do you want to make it for people to copy/crack? That itself has
costs, costs of time, space, complexity, bugs, lost opportunities,
customer dissatisfaction, and even legality.

Sony has just found that out: having been caught installing root-kits on
peoples computers, they are now being sued.

--
Steven.

Nov 10 '05 #24

Timothy Smith

Reliability is
important but so is protecting your code in an effective manner

there is no way to prevent people disassembling your code compiled or
otherwise. once you give then the program they can easily take it apart.
no if's, no but's; do NOT rely on binary's for security.

the big software companies might say 'trusted computing will save us'
but I for one will never truly trust it.

trusted computing it about your computer not trusting YOU. the computer
you pay for will decied based on some other company's whim's what you
are and are not allowed to do.
Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

i repeat. there is no such thing as protected code. i've seen people de
construct exe's written in C.

Nov 10 '05 #25

"Ben Sizer" <ky*****@gmail.com> writes:

For example, I'd like to write a game in Python. I'd like to give the
game away free and charge for extra content. In C++ I can make it
difficult for users to share content with others who haven't paid for
it, with cryptographic hashes and the like. No, not impossible, but
difficult enough to deter most people. In Python it's much harder, when
the end user can open up the relevant file and quickly remove the
license check. No doubt this is another of the reasons why Python isn't
catching on quickly for game development, sadly.

What makes you think this is the case? There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules. Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".

Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.

Not that I'm convinced that putting everything on a "secure server" is
proof against getting your code stolen. Last time I was involved with
security people, it was commonly acknowledge that there were two types
of security people: those who knew when their systems were last broken
into, and those who didn't. Source - and other things - gets stolen
from "secure servers" on a regular basis, and those machines don't
have to provide some way for the potential thieves to execute the
code. But at least with this model, some of the advantages are on your
side, so you stand a fighting chance.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 10 '05 #26

Carsten Haese

On Thu, 2005-11-10 at 16:53, Steven D'Aprano wrote:

Dude, a comprehension protection for *any* software can never be built
because of the fundamental nature of computers. Trying to stop bytes from
being copyable is like trying to stop water from being wet, and once
copied, all copies are identical and therefore indistinguishable.

+1 QOTW!

--
Carsten Haese - Software Engineer | Phone: (419) 794-2531
Unique Systems, Inc. | FAX: (419) 893-2840
1687 Woodlands Drive | Cell: (419) 343-7045
Maumee, OH 43537 | Email: ca*****@uniqsys.com

Nov 10 '05 #27

Yu-Xi Lim

Bill Mill wrote:

Your only solution, then, is to write unpopular code. Because, as Alex
said, it will otherwise be broken into. Let's look at two very popular
pieces of code: Half-Life 2 and Windows XP. How are they secured?
Previous version of these software products used sophisticated
client-side programming to try and be secure, but the security was
nonexistant. Users share keys and cracks with each other.
and

Mike Meyer wrote: What makes you think this is the case? There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules. Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".

Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.

Funny you should mention Half-Life 2. I actually went out and bought
Half-Life 2 from the store instead of waiting for a crack to be released
(the unique scheme they used meant that crackers will take a little
longer than usual). I really wanted to play this game (i.e., it's very
popular) and couldn't wait.

My brother is bugged by Civilization IV's copy protection. A couple of
days ago, after consulting me on what other options he could try, he
finally said in frustration, "Maybe I should go buy the game."

This is a personal anecdote, but I'm sure it applies to at least some
people. Obviously I'm not an honest person. But I'm not so against
spending money on software that I won't buy it if there's a pretty good
copy protection system on it. The "keeping honest people honest"
argument is simplistic and as Ben said, "black and white thinking".

Ben's analogy of the house is not a perfect example, but it's still a
fair one. You know that if some one really wants to break into your
house, he will get in, regardless of your sophisticated laser trip wire
system, ex-SAS guards, and genetically-engineered guard dogs. But as
long as the cost of protection is less than the cost of the item you're
protecting (multiplied by the relevant probabilities, factoring
recurring costs, etc), it's worthwhile to spend money on protection. If
that fails, then you will of course fall back on the law, but you still
try to prevent it from happening in the first place.

I do believe that code obfuscation and copy protection measures work, to
a limited extent. Few software companies believe that their copy
protection will be uncrackable (though their marketing droids may say
otherwise), but are most willing to invest in it to at least temporarily
stave off the piracy.

Distribution of python modules as compiled bytecode is a limited form of
obfuscation. Some believe it's enough. But if there's a free obfuscator
out there than can increase the difficulty of reverse engineering, why
not use that too? Costs you nothing, and may get you a customer or two
more before some one manages to crack that.

Obfuscation has it's place. It's not the final solution for software
protection (and there probably isn't one), but it is one more lock you
can use to deter or delay theives. You can't expect to win against
determined theives, but you can remove as many advantages that they have.

Now, both of these programs require verification (phone and/or web) to
be used. The only truly secure method of assuring that they're not
used in ways you don't intend is to require the user to contact you to
use it, and that's a deal with the devil. One you might need to make
if security is that important to you, as Microsoft and Valve have
decided it is, but it's a deal with the devil nonetheless.

This seems to be opposite to what you said in the previous paragraph.
Contacting and verifying with the company every time you use the
software is obviously not "the only truly secure method", since there
are cracks and keys floating around. It is also not quite as evil as it
may seem, since authorization is only required on initial use (and
online gaming).

Nov 11 '05 #28

Yu-Xi Lim <yu**@ece.gatech.edu> writes:

Bill Mill wrote:
Your only solution, then, is to write unpopular code. Because, as Alex
said, it will otherwise be broken into. Let's look at two very popular
pieces of code: Half-Life 2 and Windows XP. How are they secured?
Previous version of these software products used sophisticated
client-side programming to try and be secure, but the security was
nonexistant. Users share keys and cracks with each other. Mike Meyer wrote:
> What makes you think this is the case? There are ways to distribute
> Python modules so that the user can't just open them in a text
> editor. There are also ways to get cryptographic security for
> distributed modules. Yes, if you use the same methods you use in C++,
> it's "much harder". But by the same token, if you tried to use the
> methods you'd use in a Python program in C++, you'd find that the C++
> version was "much harder".

This is a personal anecdote, but I'm sure it applies to at least some
people. Obviously I'm not an honest person. But I'm not so against
spending money on software that I won't buy it if there's a pretty
good copy protection system on it. The "keeping honest people honest"
argument is simplistic and as Ben said, "black and white thinking".

And how much software is out there that you actually want so badly
that you'll buy it rather than wait unti it's cracked? Does it make up
a significant portion of the software you use? If not, then you as an
example of not merely "keeping honest people honest" are that it's
difference from reality is insignificant.
Ben's analogy of the house is not a perfect example, but it's still a
fair one. You know that if some one really wants to break into your
house, he will get in, regardless of your sophisticated laser trip
wire system, ex-SAS guards, and genetically-engineered guard dogs. But
as long as the cost of protection is less than the cost of the item
you're protecting (multiplied by the relevant probabilities, factoring
recurring costs, etc), it's worthwhile to spend money on
protection. If that fails, then you will of course fall back on the
law, but you still try to prevent it from happening in the first place.
Sounds like you just said that manufacturers should improve their
protection until they aren't making any profit on the product. That's
silly. The goal isn't to maximize protection, it's to maximize
profit. That means it only makes sense to spend money on better
protection if the cost of the protection is less than the expected
profit from adding it. The cost of the item you're protecting is
irrelevant. The cost of adding copy protection is *noticably* more
than the cost of the copy protection bits. A recent, heavily
publicized case where Sony added copy protection to a product cost
them sales, and from what I've heard, even legal fees.
I do believe that code obfuscation and copy protection measures work,
to a limited extent. Few software companies believe that their copy
protection will be uncrackable (though their marketing droids may say
otherwise), but are most willing to invest in it to at least
temporarily stave off the piracy.
Anything at all acts in the "keeping honest people honest"
capacity. It also delays the inevitable cracking - which is all you
can do. The only thing spending more on it does is lengthen the
delay. Hard data on how many sales that extra delay is responsible for
is, by it's very nature, impossible to come by. You've provided
anecdotal evidence that copy protection can improve sales. I've
provided anecdotal evidence that adding copy protection cost sales.
Distribution of python modules as compiled bytecode is a limited form
of obfuscation. Some believe it's enough. But if there's a free
obfuscator out there than can increase the difficulty of reverse
engineering, why not use that too? Costs you nothing, and may get you
a customer or two more before some one manages to crack that.

Um, if you think adding steps to the release process costs you
nothing, you don't understand the release process. If you've got a way
to obfuscate the code that doesn't require extra steps in the release
or development process, I'd love to hear about it.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 11 '05 #29

petantik <pe***********@gmail.com> wrote:
...

I think that is not workable because it is easy to say the the internet
is available everywhere.
This implies that, if it were difficult to say it, then the scheme WOULD
be workable... which I doubt is what you mean, of course;-)

It is not available in developing countries or in rural areas and so
Things are getting better all the time in these respects - and they will
keep getting better, quite apart from "web apps", because access to
information is MUCH more precious than mere computation.
these people who live/work there will never benefit from a webservice
type protection scheme,
It's debatable whether the customer BENEFITS from having their ability
to run an application RESTRICTED. It appears that the trend (in
developing countries even more than in rich ones) is towards using open
source, anyway.
and what if the network in your area goes down?
bye bye app that I *really* need for tomorrow. Reliability is
But the risk of your specific MACHINE going down is much higher than
that of the NET going down in all of its forms at once! If I rely on a
web app, and need to use it tonight to have something ready tomorrow,
then if my machine goes down (or I suffer a power brown-out in my area,
an occurrence that is frequent in many developing countries, and not
unheard of in developed ones), then I stand a chance to rush elsewhere,
to a library, town hall, internet cafe, or ANY other location where I
may be able to grab a machine, ANY machine, connect to the net, identify
and authenticate myself, and keep using that crucial web app. If said
app is well designed and mature, it will have autosaved most of my work
up to the point of my machine's crash (or the area brown-out, etc), too.

The importance of reliability speaks in FAVOUR of keeping important
stuff on the internet, rather than on unreliable, crash-prone local
machines (...and when's the last time you did a full backup of all of
your work with all proper precautions...? For most users, "never" --
for users of web apps hosted on well-maintained sites, on the other
hand, backups ARE taken care of, professionally and properly!).

important but so is protecting your code in an effective manner
There is no effective manner of protecting your code, except running it
only on well-secured machines you control yourself. If you distribute
your code, in ANY form, and it's at all interesting to people with no
interest in respecting the law, then, it WILL be cracked (and if users
choose to respect the law, then you need no "protecting").

I do believe that you are right about those that crack software for
kicks or money. If you look around at you local market place i'm sure
there are many 'discounted' commercial softwares/games sold. of course
the big software companies might say 'trusted computing will save us'
but I for one will never truly trust it.

Perhaps a comprehensive protection for interpreted languages can never
be built because of their high level nature?

Many, perhaps most, of those cracked commercial programs have NOT been
written in "interpreted languages" (whatever that means), but in
assembly code, C, C++... so your last paragraph is easily shown to be an
irrelevant aside -- it's not an issue of what language the code is in.
Alex

Nov 11 '05 #30

Yu-Xi Lim <yu**@ece.gatech.edu> wrote:
...

My brother is bugged by Civilization IV's copy protection. A couple of
days ago, after consulting me on what other options he could try, he
finally said in frustration, "Maybe I should go buy the game."
It's interesting, in this context, that Civilization IV is mostly
written in Python (interfaced to some C++ via BoostPython).

It took me 12 seconds with a search engine to determine that CivIV's
protection uses "SafeDisc 4.60" and 30 more seconds to research that
issue enough to convince myself that there's enough information out
there that I could develop a crack for the thing (if I was interested in
so doing), quite apart from any consideration of the languages and
libraries used to develop it -- and I'm not even a particularly good
cracker, nor am I wired into any "underground channels", just looking at
information easily and openly available out on the web and in the index
of a major search engine.

Obfuscation has it's place.

What I think of this thesis is on a par of what I think of this way of
spelling the possessive adjective "its" (and equally unprintable in
polite company). If I could choose to eradicate only one of these two
from the world, I'd opt for the spelling -- the widespread and totally
unfounded belief in the worth of obfuscation is also damaging, but less
so, since it only steals some time and energy from developers who (if
they share this belief) can't be all that good anyway;-).
Alex

Nov 11 '05 #31

Magnus Lycka

petantik wrote:

Alex Martelli wrote:
I think that's feeble protection. If you have valuable code, and
distribute it, people WILL crack it -- just check the warez sites for
experimental proof... EVERYTHING that people are really interested in
DOES get cracked, no matter what tricky machine-code the "protections"
are coded in.

There's ONE way to have uncrackable code -- don't distribute it, but
rather put it up on the net on a well-secured machine under your
control, available as (say) a webservice (subscription-only, pay per
use, or whatever business model you want).
.... I think that is not workable because it is easy to say the the internet
is available everywhere.

It is not available in developing countries...

Erh, the internet is certainly spreading to most of the
world, and there is an abundance of cracked and pirated
software in the poorer countries in the world, so the
obfuscation part has certainly proven not to work there.

Nov 11 '05 #32

Magnus Lycka

The Eternal Squire wrote:

Two things: .... 2) Only sell to an honest customer willing to be locked into
nondisclosure agreements. This goes back to the maxim of good
salesmanship: Know Your Customer.

If you have this, you don't need the obfuscation.

Nov 11 '05 #33

Ben Sizer

Mike Meyer wrote:

Yu-Xi Lim <yu**@ece.gatech.edu> writes:
Ben's analogy of the house is not a perfect example, but it's still a
fair one. You know that if some one really wants to break into your
house, he will get in, regardless of your sophisticated laser trip
wire system, ex-SAS guards, and genetically-engineered guard dogs. But
as long as the cost of protection is less than the cost of the item
you're protecting (multiplied by the relevant probabilities, factoring
recurring costs, etc), it's worthwhile to spend money on
protection. If that fails, then you will of course fall back on the
law, but you still try to prevent it from happening in the first place.
Sounds like you just said that manufacturers should improve their
protection until they aren't making any profit on the product. That's
silly. The goal isn't to maximize protection, it's to maximize
profit. That means it only makes sense to spend money on better
protection if the cost of the protection is less than the expected
profit from adding it.

I agree with what you're saying, but it seems like you're arguing
against what was said rather than what was intended. Without wishing to
put words into anybody's mouths, I'm pretty sure what Yu-Xi Lim meant
was just that even imperfect protection is worthwhile if you estimate
that it will benefit you more than it will cost you. This is in
contrast to the opinion that any protection is useless because someone
will break it if they want to.
A recent, heavily
publicized case where Sony added copy protection to a product cost
them sales, and from what I've heard, even legal fees.

I think that's a poor example - the cost hasn't come from the mere act
of adding protection, but the method in which that protection operates.
I don't think anybody here - certainly not me - is talking about
infecting a user's system to protect our property, or taking any other
intrusive steps. I'd just like to make it non-trivial to make or use
additional copies.

--
Ben Sizer.

Nov 11 '05 #34

Ben Sizer

Mike Meyer wrote:

There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules.
I know distributing as bytecode helps, but I was under the impression
that the disassembers worked pretty well. With the dynamic nature of
the language I expect that all the variable names are largely left
intact. You win some, you lose some, I guess.

As for cryptographic security, could you provide a link or reference
for this? I am quite interested for obvious reasons. I'd be concerned
that there's a weak link in there at the decoding stage, however.

I have considered distributing my program as open source but with
encrypted data. Unfortunately anyone can just read the source to
determine the decryption method and password. Maybe I could put that
into an extension module, but that just moves the weak link along the
chain.
Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".
Well, I'm not sure what you mean here. A compiled C++ program is much
harder to extract information from than a compiled Python program.
That's without applying any special 'methods' on top of the normal
distribution process.
Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.

No, certainly not. But if you can mitigate your losses easily enough -
without infringing upon anyone else's rights, I must add - then why not
do so.

--
Ben Sizer.

Nov 11 '05 #35

"Ben Sizer" <ky*****@gmail.com> writes:

A recent, heavily
publicized case where Sony added copy protection to a product cost
them sales, and from what I've heard, even legal fees. I think that's a poor example - the cost hasn't come from the mere act
of adding protection, but the method in which that protection operates.

That was sort of the point - that the effect on the bottom line of
adding copy protection is usually worse than just the cost of the
software, and can be much worse. This is a particularly egregious
example, but that just makes it an egregious example, not a poor one.
I don't think anybody here - certainly not me - is talking about
infecting a user's system to protect our property, or taking any other
intrusive steps. I'd just like to make it non-trivial to make or use
additional copies.

I've returned software that wouldn't run from a backup copy. Would I
return your software? If yes, have you factored the loss of sales to
people like me into your profit calculations?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 11 '05 #36

petantik

Ben Sizer wrote:

Mike Meyer wrote:
There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules.

I know distributing as bytecode helps, but I was under the impression
that the disassembers worked pretty well. With the dynamic nature of
the language I expect that all the variable names are largely left
intact. You win some, you lose some, I guess.

As for cryptographic security, could you provide a link or reference
for this? I am quite interested for obvious reasons. I'd be concerned
that there's a weak link in there at the decoding stage, however.

I have considered distributing my program as open source but with
encrypted data. Unfortunately anyone can just read the source to
determine the decryption method and password. Maybe I could put that
into an extension module, but that just moves the weak link along the
chain.
Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".

Well, I'm not sure what you mean here. A compiled C++ program is much
harder to extract information from than a compiled Python program.
That's without applying any special 'methods' on top of the normal
distribution process.
Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.

No, certainly not. But if you can mitigate your losses easily enough -
without infringing upon anyone else's rights, I must add - then why not
do so.

--
Ben Sizer.

The economics of software distribution must certainly come into it,
doing a cost/benefit analysis of whether it's worth the effort to
protect your code from would be crackers.

The problem with code protection methodology in general is that once
its cracked everyone has access to code for, maybe, all software using
the particular protection scheme.

the argument that most people buy software rather than get a pirated
version depends on the country that they are in e.g. china's piracy
problem where shops sell pirated software with no retribution by the
state - remember china is about to be the worlds largest economic
superpower

The above problem illustrate why code needs to be protected in an
effective way, by law and code protection schemes

With python there is no comfort factor in knowing that your code is
being protected, well not than I can see, compared with protection
schemes for compiled code which are used by many commercial software
companies.

Of course, we know that there can never be a 100% way to protect code
that some pirate won't overcome but it still stops the casual user or
beginner 'crackers' from stealing the code and digging in to your
profit margin.

btw i'm no expert on copy protection mechanism but the question I
raised originally, i believe, is valid and should be discussed

http://petantik.blogsome.com - A Lucid Look at Reality

Nov 11 '05 #37

"Ben Sizer" <ky*****@gmail.com> writes:

Mike Meyer wrote:
There are ways to distribute
Python modules so that the user can't just open them in a text
editor. There are also ways to get cryptographic security for
distributed modules. As for cryptographic security, could you provide a link or reference
for this? I am quite interested for obvious reasons. I'd be concerned
that there's a weak link in there at the decoding stage, however.

How about some ideas: Store your code in a zip file, and add it to the
search path. That immediately takes you out of the "just open the file
with a text editor" mode. For cryptographic security, use the ihooks
module to make "import" detect and decode encrypted modules before
actually importing them. Or digitally sign the modules, and check the
signature at import time. All of these are dead simple in Python.
I have considered distributing my program as open source but with
encrypted data. Unfortunately anyone can just read the source to
determine the decryption method and password. Maybe I could put that
into an extension module, but that just moves the weak link along the
chain.
This isn't aPython problem, it's a problem with what you're doing. Try
Alex's solution, and put the data on a network server that goes
through whatever authentication you want it to.

Yes, if you use the same methods you use in C++,
it's "much harder". But by the same token, if you tried to use the
methods you'd use in a Python program in C++, you'd find that the C++
version was "much harder".

Well, I'm not sure what you mean here. A compiled C++ program is much
harder to extract information from than a compiled Python program.

It is? Is the Python disassembler so much advanced over the state of
the art of binary disassemblers, then? Or maybe it's the Python
decompilers that are so advanced? As far as I can tell, the only real
difference between Python bytecodes and x86 (for instance) binaries is
that Python bytecodes keep the variable names around so it can do
run-timme lookups. That's not that big a difference.

As for what I meant - Python has ihooks and imp, that make it simple
to customize import behavior. Doing those kinds of things with C++
code requires building the tools to do that kind of thing from
scratch.

Of course, as Alex pointed out, all of these are just keeping honest
people honest. The crooks have all the advantages in this game, so you
really can't expect to win.

No, certainly not. But if you can mitigate your losses easily enough -
without infringing upon anyone else's rights, I must add - then why not
do so.

Elsewhere in the thread, you said:
I'd just like to make it non-trivial to make or use additional copies.

How do you do that without infringing my fair use rights?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 11 '05 #38

On Fri, 11 Nov 2005 11:17:43 -0500, Mike Meyer wrote:

I'd just like to make it non-trivial to make or use additional copies.

How do you do that without infringing my fair use rights?

And that is the million dollar question.

So-called "intellectual property" is a government-granted monopoly which
is not based on any principle of ownership. Ideas are not something you
can own in any real sense (as opposed to the legal fiction), ideas are
something that you can *have* -- but having had an idea, you can't
naturally prevent others from having the same idea independently, or
making use of your idea if you tell them about it -- and should you tell
them your idea so that now they have it as well, that does not diminish
the fact that you also have that idea.

Given the absolute lack of real evidence that strong "intellectual
property" laws are good for either innovation or the economy, and given
the absolute artificiality of treating ideas as if they were scarce goods,
I don't understand why the artificial monopoly rights of copyright holders
are allowed to trump the natural rights of copyright users.

--
Steven.

Nov 22 '05 #39

On Fri, 11 Nov 2005 08:11:32 -0800, petantik wrote:

the argument that most people buy software rather than get a pirated
version depends on the country that they are in e.g. china's piracy
problem where shops sell pirated software with no retribution by the
state - remember china is about to be the worlds largest economic
superpower

The above problem illustrate why code needs to be protected in an
effective way, by law and code protection schemes

I'm sorry, what problem? You haven't actually stated a problem -- in fact,
you have just given a perfect example of why the so-called "problem" is
not a problem at all. Let us see:

Historically, the UK had no concept of intellectual property rights until
very recently, and even when it was introduced, it was very limited until
the late 20th century.

Likewise for continental Europe.

Nevertheless, the UK and Europe became economic superpowers.

The USA, like China and Russia today, was a pirate nation for the first
century or two of its existence. American publishers simply reprinted
English books without paying royalties until well into the 20th century.
Hollywood got its start by fleeing the east coast to California, where
enforcement of Thomas Edison's patents on motion picture technology was
not enforced.

The USA has become an economic superpower.

China has little effective protection for artificial monopoly rights over
ideas. China is becoming an economic superpower.

So where is the problem?

Ah, now I understand it. Having become rich and powerful by ignoring
so-called intellectual property, the UK, Europe and especially the USA is
desperate to ensure that the developing world does not also become rich
and powerful. One way of doing so is to force a system of artificial
government-granted monopolies, together with all the proven economic
inefficiencies of such monopolies, on the developing world.

--
Steven.

Nov 22 '05 #40

On Thu, 10 Nov 2005 21:41:52 -0800, Alex Martelli wrote:

Obfuscation has it's place.
What I think of this thesis is on a par of what I think of this way of
spelling the possessive adjective "its" (and equally unprintable in
polite company).

Aside: given that "it's" is "it is", how would you spell the possessive
case of it?
If I could choose to eradicate only one of these two
from the world, I'd opt for the spelling -- the widespread and totally
unfounded belief in the worth of obfuscation is also damaging, but less
so, since it only steals some time and energy from developers who (if
they share this belief) can't be all that good anyway;-).

Not that I disagree with you about obfuscation in general, but I can think
of one particular usage case for obfuscation which is neither useless nor
morally suspect:

"Now listen carefully class, your homework for this week is to write a
program to blurgle a frobnitz. As a test of correctness, your program
must return the same results as the test function blurglise. Before you
get any clever ideas of copying the code from blurglise, keep in mind
firstly that the source code is obfuscated, and secondly that I am not an
idiot, I will recognise my own code if you try to pass it off as yours."

--
Steven.

Nov 22 '05 #41

My, we're about to get *seriously* off topic.

Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:

On Fri, 11 Nov 2005 11:17:43 -0500, Mike Meyer wrote:
I'd just like to make it non-trivial to make or use additional copies. How do you do that without infringing my fair use rights?

And that is the million dollar question.

So-called "intellectual property" is a government-granted monopoly which
is not based on any principle of ownership. Ideas are not something you
can own in any real sense (as opposed to the legal fiction), ideas are
something that you can *have* -- but having had an idea, you can't
naturally prevent others from having the same idea independently, or
making use of your idea if you tell them about it -- and should you tell
them your idea so that now they have it as well, that does not diminish
the fact that you also have that idea.

It's a common misconception that ideas are protected by intellectual
property laws. They're not. Well, they're not supposed to be.

Copyright doesn't protect ideas, plot lines or similar
things. Copyright protects expression of those things in a tangible
medium. So if you read a book, then write a book with the same plot
line, you aren't in violation of copyright. Characters can be
protected by copyright, so you do have to be a bit careful about that.

Patents aren't supposed to protect ideas - they're supposed to protect
inventions. That's a fuzzy line, and the interpretation of 35 USC
Section 101 that allows the patenting of software has made it even
fuzzier. This broad interpretation has recently been used to patent
story lines <URL:
http://www.groklaw.net/article.php?s...51103183218268 >, which is
close enough to patenting ideas that I can't really tell the
difference.
Given the absolute lack of real evidence that strong "intellectual
property" laws are good for either innovation or the economy, and given
the absolute artificiality of treating ideas as if they were scarce goods,
I don't understand why the artificial monopoly rights of copyright holders
are allowed to trump the natural rights of copyright users.

Because the copyright holders are organized, and have money to
influence congress that outweighs the funds that - since they're
generally unorganized - individual copyright holders have
available. So you get laws that help copyright holders enforce and
extend their copyright at the expense of the rights of the general
public.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 22 '05 #42

Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

On Thu, 10 Nov 2005 21:41:52 -0800, Alex Martelli wrote:
Obfuscation has it's place.
What I think of this thesis is on a par of what I think of this way of
spelling the possessive adjective "its" (and equally unprintable in
polite company).

Aside: given that "it's" is "it is", how would you spell the possessive
case of it?

As I was thought and have always seen it spelled in good literature --
"its". I'm not at all tempted to affix "'s" to make possessives out of
pronouns -- "I's", "you's", "we's"...?!-) Remember, English is not my
native language, so what I have internalized are _rules_, not a native
speaker's magical communion with the language...;-)

Not that I disagree with you about obfuscation in general, but I can think
of one particular usage case for obfuscation which is neither useless nor
morally suspect:

"Now listen carefully class, your homework for this week is to write a
program to blurgle a frobnitz. As a test of correctness, your program
must return the same results as the test function blurglise. Before you
get any clever ideas of copying the code from blurglise, keep in mind
firstly that the source code is obfuscated, and secondly that I am not an
idiot, I will recognise my own code if you try to pass it off as yours."

Sure, that's one example -- but the instructor SHOULD really consider
placing burglise on a secure server on the intranet instead, making it
available (via CGI, webservice, whatever) to check input/output
relationships, rather than making the obfuscated code available and
raising questions of obfuscation and reverse engineering.
Alex

Nov 22 '05 #43

Without copyright, how could one possibly earn a living writing a
novel? And I submit that many ISD's are only a single person burning
with that one software idea of a lifetime, the equivalent of the Great
American Novel. Are we to punish that impulse by denying that person
a legal monopoly on that idea?

I believe piracy is bad for everyone: the consumer, the writer, and
the country as a whole. I don't oppose copyleft, but then, I don't
oppose copyright either. Let's distribute the former for free, and
honor the need for the writer of the latter to earn a living.

The Eternal Squire

Nov 22 '05 #44

Yu-Xi Lim

Alex Martelli wrote:

It's interesting, in this context, that Civilization IV is mostly
written in Python (interfaced to some C++ via BoostPython).

It took me 12 seconds with a search engine to determine that CivIV's
protection uses "SafeDisc 4.60" and 30 more seconds to research that
issue enough to convince myself that there's enough information out
there that I could develop a crack for the thing (if I was interested in
so doing), quite apart from any consideration of the languages and
libraries used to develop it -- and I'm not even a particularly good
cracker, nor am I wired into any "underground channels", just looking at
information easily and openly available out on the web and in the index
of a major search engine.
Yes, I never said it's uncrackable. The cracks available are iffy and
the alternatives are sufficiently inconvenient to dissuade the
less-savvy user from attempting them. In which case, the copy protection
has succeeded.
What I think of this thesis is on a par of what I think of this way of
spelling the possessive adjective "its" (and equally unprintable in
polite company). If I could choose to eradicate only one of these two
from the world, I'd opt for the spelling -- the widespread and totally
unfounded belief in the worth of obfuscation is also damaging, but less
so, since it only steals some time and energy from developers who (if
they share this belief) can't be all that good anyway;-).

The level of pedantry here is amazing and it doesn't apply only to
programming languages. While we are discussing my typos, I'd like to
note that I may accidentally interchange "you're" and "your", "there",
"they're", and "their", and a bunch of other homonyms.

I hadn't seen any damage done from misusing "it's". Certainly not on par
with the Sony case which Mike Meyer cites as evidence against copy
protection (and presumably obfuscation, which was the topic of the
discussion)

This topic seems to be drifting. I thought I might clarify what I mean
by "code obfuscation" to get things back on track.

Code obfuscation is a transformation of the program (whether at source
code level, intermediate object code level, binary executable level,
etc) to hinder (prevention seems impossible) reverse engineering
(attempts to determine the workings of the code, to modify the function
of the code, etc). While there are many possible transformations that
can be done on programs (compression, run-time optimizations, etc), the
key here is the intent to hinder reverse engineering. I hope this is
agreeable to everyone.

Python already conveniently supports certain transformations on
programs. Off the top of my head, I think of compiled bytecode (pyc and
pyo files), and modules in zip archives. Any of these can be used as a
means of obfuscation. (Compiled languages naturally undergo
transformations which tend to have more effectiveness against reverse
engineering)

Now, to address points made by Mike Meyer. He says that obfuscation adds
steps to the release process and also cites Sony's XCP fiasco as an
example of unseen costs of "copy protection".

Indeed, everything has a cost, and I was wrong in saying "free".
However, if convenient language-supported transforms are used, the
direct cost of using obfuscation would be miniscule in comparison to
just about everything else. Implementing it should be one simple step,
and testing it shouldn't be required (if you reasonably assume the
language isn't broken).

I am going to ignore certain aspects of the Sony XCP case, such as the
bad EULA and the bad PR (we shall leave that to the lawyers and
marketing folk and stick to something we programmers can actually fix).
What we have left is a broken software implementation of copy
protection. If language-supported (or even OS-supported, which would
have helped Sony*) transformations are used, we can expect to rule out
such brokenness, i.e. no obfuscation-induced incompatibilities and
related help-desk calls. This further reduces the unexpected costs of
code obfuscation to zero (did I miss anything?)

This form of obfuscation is certainly weak, but given that the costs are
so tiny, why not use it? Even if you could gain one customer (and a few
dollars if you're a shareware developer), you have more than recuperated
your costs. If you don't, you probably lost 5 minutes of development
time. Is this a worthwhile gamble? I believe so.

Mike Meyer may reiterate his point about "keeping honest people honest"
and thus such obfuscation has little ("insignificant") benefit. Whether
this little difference is "insignificant" is up to the
developer/publisher/etc to decide. My thesis (to borrow Alex Martelli's
language) is that it is possible to obtain *some* benefit from
obfuscation with *minimal* costs.

There are physical examples of attempts to hinder reverse engineering:
glueing the cases of devices shut and sealing integrated circuits in a
blob of epoxy, among others. With such examples, I don't think it's
unreasonable to believe that similar possibilities exist for software
products. This is not cited as concrete evidence, just something that
hints at a possibility.
* Someone may start crying out, "DRM-supporter! Burn him at the stake!"
I think code obfuscation and DRM should be approached as seperate
issues, unless one believes that the user's right to software includes
unlimited access to the source code. That itself is also a separate
discussion, imo.

Nov 22 '05 #45

Yu-Xi Lim

Alex Martelli wrote:

There is no effective manner of protecting your code, except running it
only on well-secured machines you control yourself. If you distribute
your code, in ANY form, and it's at all interesting to people with no
interest in respecting the law, then, it WILL be cracked (and if users
choose to respect the law, then you need no "protecting").

Indeed. An this extends to web services too. If you have input which can
be observed (or even better, controlled) and output that can be observed
too, one would be able to infer the workings of the code (reverse
engineering in one of its purest forms).

If your business strategy relies heavily on a proprietary algorithm or
even something as weak as lock-in via a proprietary "un-interoperable"
data format, then web services is not the final answer. It may work for
certain applications (Microsoft's for example) where the cost of reverse
engineering is equivalent to the cost of building from scratch.

Nov 22 '05 #46

Paul Rubin

"The Eternal Squire" <et***********@comcast.net> writes:

Without copyright, how could one possibly earn a living writing a
novel?
This guy seems to be doing ok: http://craphound.com
His publishers are the only ones allowed to sell his novels commercially,
but you can download them all and print them out noncommercially for
your own personal enjoyment or to share with your friends. No obfuscation
is needed.
And I submit that many ISD's are only a single person burning with
that one software idea of a lifetime, the equivalent of the Great
American Novel. Are we to punish that impulse by denying that
person a legal monopoly on that idea?
You know, there's lots of people who would like to make a living as
actors or musicians or novelists or whatever, and maybe they even have
enough talent and skill to do it, but for whatever reason it's just
not in the cards for them, copyright or not. So they do other things
instead. Maybe it's also not in the cards for some people to be
programmers even though they'd like to be, so they do other things
instead too. For the most part, I don't feel any sense of tragedy
about this.
I believe piracy is bad for everyone: the consumer, the writer, and
the country as a whole. I don't oppose copyleft, but then, I don't
oppose copyright either. Let's distribute the former for free, and
honor the need for the writer of the latter to earn a living.

Everyone has the right to try to earn a living from programming, but
no one is entitled to be guaranteed success at it.

Nov 22 '05 #47

Ben Finney

Yu-Xi Lim <yu**@ece.gatech.edu> wrote:

Code obfuscation is a transformation of the program (whether at
source code level, intermediate object code level, binary executable
level, etc) to hinder (prevention seems impossible) reverse
engineering (attempts to determine the workings of the code, to
modify the function of the code, etc). While there are many possible
transformations that can be done on programs (compression, run-time
optimizations, etc), the key here is the intent to hinder reverse
engineering.
That's a workable definition.
I hope this is agreeable to everyone.

The definition is agreeably solid.

The intention is disagreeably sickening.

--
\ "Room service? Send up a larger room." -- Groucho Marx |
`\ |
_o__) |
Ben Finney

Nov 22 '05 #48

Yu-Xi Lim <yu**@ece.gatech.edu> writes:

Indeed, everything has a cost, and I was wrong in saying
"free". However, if convenient language-supported transforms are used,
the direct cost of using obfuscation would be miniscule in comparison
to just about everything else. Implementing it should be one simple
step, and testing it shouldn't be required (if you reasonably assume
the language isn't broken).
Failng to test what you ship is simply poor engineering and poor
marketing. If you're incompetent, you might skip those
steps. Otherwise, you have to test with obfuscation in place.
I am going to ignore certain aspects of the Sony XCP case, such as the
bad EULA and the bad PR (we shall leave that to the lawyers and
marketing folk and stick to something we programmers can actually
fix). What we have left is a broken software implementation of copy
protection. If language-supported (or even OS-supported, which would
have helped Sony*) transformations are used, we can expect to rule out
such brokenness, i.e. no obfuscation-induced incompatibilities and
related help-desk calls. This further reduces the unexpected costs of
code obfuscation to zero (did I miss anything?)
You ignored the fact that the *act* of copy protection cost them
customers. It wasn't the poor implementation or the EULA, it was the
fact that people who were denied their fair use rights returned or
refused to buy their product. The rest of it merely made it widely
publicized.
This form of obfuscation is certainly weak, but given that the costs
are so tiny, why not use it? Even if you could gain one customer (and
a few dollars if you're a shareware developer), you have more than
recuperated your costs. If you don't, you probably lost 5 minutes of
development time. Is this a worthwhile gamble? I believe so.
And if instead you lose one customer because you've denied them their
fair use rights, then your copy protection has lost you more in the
form of a cost that you overlooked than all the costs you actually
considered.
Mike Meyer may reiterate his point about "keeping honest people
honest" and thus such obfuscation has little ("insignificant")
benefit. Whether this little difference is "insignificant" is up to
the developer/publisher/etc to decide. My thesis (to borrow Alex
Martelli's language) is that it is possible to obtain *some* benefit
from obfuscation with *minimal* costs.

Actually, obfuscation by itself has *no* benefit. If all you do is
obfuscate the code, none of the pirates will ever notice - they'll
just copy the code without ever trying to read it. It's the copy
protection mechanisms you're trying to obfuscate that gains you the
alleged benefit. Once you provide a copy protection mechanism,
obfuscation has some benefit, though the costs aren't clearly minimal,
not if you're a cometent engineer. It's the benefits of the copy
protection that I claim are insignificant.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 22 '05 #49