Python obfuscation

[Mike Meyer]

Yu-Xi Lim <yuxi at 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 <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.