Home Original page

Selling Python Software

Andrew Dalke adalke at mindspring.com
Tue Nov 4 16:03:09 EST 2003 
Bengt Richter:
> 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?

As I mentioned, I'm not a hardware guy.  What I know is that
trying to hide code on a chip is open to its own sorts of attacks and
that at least some companies which have tried to do so (like pay-TV
companies) have had their systems broken, and not broken by the
efforts of a three letter agency.

> That was then.

Yup.

Crypto software is notoriously hard to write.  Even with the good
libraries we have now, people make mistakes and misuse them.
Similarly, while it people can make chips that are hard to decode,
doing so in practice is likely to be even harder.

> 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.

Then perhaps a small business instead of a hobbyist.  Still
doesn't require large government-based efforts to crack it.

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

That's what I did for that one.

Another time I was working for a company.  We were shipping a time-locked
program and had forgotten about it (there was a big lay off a few months
before I came in).  Then one day our customers started complaining that
it wasn't working.  The builds were done at another site, so as a backup
plan I figured out how to break our own scheme.  In that one I looked
for the time call then added some code to shift the return value some
arbitrary time in the future.

> 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.

Another one is the code in an old copy of MS Windows which gave a
warning message when run on top of DR-DOS (which had about 1/300th
of the marketplace).  See
 http://www.ddj.com/documents/s=1030/ddj9309d/

But these are defeatable.  For example, run the program under an
emulator, save the state after the license check occurs, and restart
by reloading from that state.  Or write a wrapper which intercepts
all I/O calls and returns the results from a known, good call (a
replay attack).

The system you propose seems to require a lot of changes to how
existing computer hardware is built, so that people can attach
dedicated compute resources.  It's definitely an interesting idea,
and not just for program hiding.  But a big change.

I'll end with a quote from E.E. "Doc" Smith's "Gray Lensman"
(p10 in my copy)

   Also, there was the apparently insuperable difficulty of
   the identification of authorized personnel.  Triplanetary's best
   scientists had done there best in the way of a non-counter-
   feitable badge -- the historic Golden Meteor, of which upon
   touch impressed upon the toucher's consciousness an unpro-
   nounceable, unspellable symbol -- but that best was not
   enough.  /What physical science could devise and synthesize,
   physical science could analyze and duplicate/; and that analy-
   sis and duplication had caused trouble indeed.

(I realize this is not at issue and that everyone agrees this
to be the case.  I just like the quote ;)

                    Andrew
                    dalke at dalkescientific.com
More information about the Python-list mailing list