Re: Request: tamper-proofing executables

Tamperproofing things that aren't hardware is difficult.
If your code is sufficiently non-obfuscated to be worth tampering with,
Bad Guys can tamper with the tamper-checking code just as easily as they
can with the useful-stuff code.  One way around this is to leave
digital-signature-checking to exterior programs, e.g. include a PGP signature
(probably in a separate file to avoid mushing it into your binaries)
and let them check the signature from their own copy of PGP.
(Or for cheapness without patent problems, distribute a RIPEM-sig instead.)

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.  Sufficiently persistent Bad Guys
can respond to this by grabbing the code from memory as they run it,
and you can play games with them about decoding stuff a piece at a time, etc.
(All of this is of coure easier in LISP or interpreted languages.....)
How much work you want to put into this depends on how much effort
you think the Bad Guys are willing to spend cracking your code.

I've heard people talk about doing totally encrypted computation,
but I'm not sure whether anything practical hs been implemented.

		Bill
		
# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399
# email bill.stewart@pleasantonca.ncr.com billstewart@attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

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

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

This is as useful as writing your own PCode interpreter and encrypting the
PCode as it runs.  Whoop de doo. :-)  You can still get at the actual
interpreter and copy it along with the key and along with the code it is
executing it.  It's a simple thing.  Capture it in memory, save the memory
image to the disk, write some code to reload it, and restart it again.

There's no way to do this securely without hardware.  Optionally if you had
smart drives, that is disk drives with their own CPU and RAM, you could
make it very hard to defeat this by loading a program in the drive's CPU
which would run in sync with the actual program and spit out consecutive
encrypted sequences or issue challenge numbers and check them against the
previous number.  This makes it hard because now you have to hack two
devices.  Offers more protection than a single program doing this, but it
is still not foolproof.

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

Another alternative is to use a hardware key generator dongle.  But if the
hacker finds the algorithm and the key for this device, and it can be done
by probing it, he can simulate it in software.  Fer instance, if the program
accesses it via the operating system instead of direct I/O on the CPU, a
routine can be written to emulate this box in software.  For protected mode
CPU's with virtual ports, even doing direct I/O will fail....

There's always a way around everything but the most excruciatingly painful
schemes...

At best you can devfeat mediocre hackers and viruses attempting to screw with
your code...
At worst you can have lots of headaches trying to implement an overly secure
system when it isn't always called for.

Unless your program is some super duper new tech thing and you don't want
people to disassemble and reverse engineer it, don't bother with anything
more than a simple CRC and a bit of encryption...

How about a different tack, having all branch instructions feed in some 
number from the program, generated from the state of the program, to a 
lookup hard-key.  The program then branches to the appropriate site.

If the number of branches/states of program  was great enough, this might be 
secure(of cource, they can just watch it and recode, but they could 
probably re-write the code for this ammount.)

Roger.