1994-07-11 - Re: Request: tamper-proofing executables

Header Data

From: Ian Farquhar <ifarqhar@laurel.ocs.mq.edu.au>
To: cypherpunks@toad.com
Message Hash: f47d82277331ef49edf4a887a1e344e9ea2d76965d3617c5500038f46c23f77a
Message ID: <199407110135.AA23576@laurel.ocs.mq.edu.au>
Reply To: N/A
UTC Datetime: 1994-07-11 01:35:31 UTC
Raw Date: Sun, 10 Jul 94 18:35:31 PDT

Raw message

From: Ian Farquhar <ifarqhar@laurel.ocs.mq.edu.au>
Date: Sun, 10 Jul 94 18:35:31 PDT
To: cypherpunks@toad.com
Subject: Re: Request: tamper-proofing executables
Message-ID: <199407110135.AA23576@laurel.ocs.mq.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


>This is as useful as writing your own PCode interpreter and encrypting the
>PCode as it runs.  Whoop de doo. :-)  

Somewhat easier, though.  And utilizing single-step defeats a lot of
debuggers too, who don't expect programs to use it.  The tool of choice
for killing such systems is an ICE, although most hackers do not have
access to these.

>Capture it in memory, save the memory
>image to the disk, write some code to reload it, and restart it again.

Exactly the point I made in the original article: the code to do the
decryption is vulnerable.

>There's no way to do this securely without hardware.  

Ditto in my original article.

>The best thing to do is to build a custom CPU with custom RAM and seal it in
>some epoxy with self destructive materials in it.  This is excruciatingly
>cumbersome, and you have to deal with the problem of heat dissipation. (Since
>the CPU is a custom made one, you can't simulate it or break it.  Since you
>have no access to RAM, you can get RAM images, etc.)

And it's not particularly secure, either.  There are well-known techniques
for defeating such approaches.  These are discussed in the CMU paper
I referred to.

							Ian.




Thread