From: Ian Farquhar <ifarqhar@laurel.ocs.mq.edu.au>
To: cypherpunks@toad.com
Message Hash: 16887cddb7edb2ba1eb945741dd099d3799806b3f301152c6f4da7f03ea72c53
Message ID: <199407102309.AA17740@laurel.ocs.mq.edu.au>
Reply To: <9407100707.AA29634@anchor.ho.att.com>
UTC Datetime: 1994-07-10 23:09:27 UTC
Raw Date: Sun, 10 Jul 94 16:09:27 PDT
From: Ian Farquhar <ifarqhar@laurel.ocs.mq.edu.au>
Date: Sun, 10 Jul 94 16:09:27 PDT
To: cypherpunks@toad.com
Subject: Re: Request: tamper-proofing executables
In-Reply-To: <9407100707.AA29634@anchor.ho.att.com>
Message-ID: <199407102309.AA17740@laurel.ocs.mq.edu.au>
MIME-Version: 1.0
Content-Type: text/plain
>Some people have suggested code that does things like encrypt some
>critical parts of the code and decode them on the fly at runtime,
>using a key that's generated by checksumming the file and XORing
>with the last 8 bytes or some variant.
The neatest trick I heard of was to use the 68000's single step mode
to decrypt each word of the program on the fly, run it, then write it back
reencrypted under another key, so that a decrypted copy never existed in
memory, and what was there was a moving target. Unfortunately, the decrypting
software did sit in memory, and so you could eventually hack that right out,
and decode the core image.
>I've heard people talk about doing totally encrypted computation,
>but I'm not sure whether anything practical hs been implemented.
There was a CMU (I think) paper on the subject, but it assumed fully
protected hardware (CPU's wrapped in huge quantities of wire all sealed in
epoxy etc.) Such hardware tricks - as I think the NSA learned with
ViaLink - are never completely satisfactory. :)
Ian.
Return to July 1994
Return to “wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)”