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.
participants (4)
-
Ian Farquhar -
rarachel@prism.poly.edu -
Roger Bryner -
wcs@anchor.ho.att.com