Request: tamper-proofing executables

I would appreciate any pointers to documents, source code or
programs that deal with using cryptographic techniques to detect
or prevent modification of executable code. I am looking for 
something that uses either a signature or a one-way hash to detect
modifications at run time. 
   Of particular interest is information on signing a file that
includes the signature as part of the file. Is this possible with
any of the common algorithms?
                                       Thanks! Dan
-- 
Dan Marner                             dmarner@mis.nu.edu
Network Weasel
National University                    "Not on MY network!"

On Fri, 8 Jul 1994, Dan Marner wrote:

>    I would appreciate any pointers to documents, source code or
> programs that deal with using cryptographic techniques to detect
> or prevent modification of executable code. I am looking for 
> something that uses either a signature or a one-way hash to detect
> modifications at run time. 
>    Of particular interest is information on signing a file that
> includes the signature as part of the file. Is this possible with
> any of the common algorithms?

	Hoom. Last year, I was working on an idea I head, of making 
self-encrypting executables. It used a simple XOR with a hardcoded value. 
Not very secure, but that wasn't the point. The XOR was meant to deter 
decompilers and stupid k00l /<-Rad hackerz from hex-editing the strings 
in the program. It as, of course, vulnerable to debuggers, but I did run 
into code later meant to deter them as well...
	My ramblings here do have a point, and it's this: It's VERY 
difficult to get an executable protection or encryption scheme to be 
undefeatable. If they have a debugger, a decompiler, and various other 
crypto-verification tools, they can defeat your scheme. Put a CRC of the 
MD5 hash in the file to make sure they don't replace the hash? They can 
generate the CRC of their hash and replace it in the file.
	I have yet to devise or find a foolproof [ ;) ] or unbreakable 
protection scheme. I'mm starting to think there's no such animal. What 
you CAN do is protect your executables against file corruption, viruses, 
and lame-0 hacker dudez. But, getting any secure PGP-level security is 
very difficult.
	OTOH, if anyone else has come up with a scheme that is hard to 
break / unbreakable, *please* come formward and correct me. I have a few 
applications that I'd like to apply this to. :)

--------------------------------------------------------------------------
Michael Brandt Handler                                <grendel@netaxs.com> 
Philadelphia, PA                                    <mh7p+@andrew.cmu.edu>
Currently at CMU, Pittsburgh, PA            PGP v2.6 public key on request
Boycott Canter & Siegel                <<NSA>> 1984: We're Behind Schedule

> 	I have yet to devise or find a foolproof [ ;) ] or unbreakable 
> protection scheme. I'mm starting to think there's no such animal. What 
> you CAN do is protect your executables against file corruption, viruses, 
> and lame-0 hacker dudez. But, getting any secure PGP-level security is 
> very difficult.
> 	OTOH, if anyone else has come up with a scheme that is hard to 
> break / unbreakable, *please* come formward and correct me. I have a few 
> applications that I'd like to apply this to. :)

There isn't any foolproof way.  The reason is that if you protect a program
through software, the hacker, if determined and of exceptionally high caliber
will turn to hardware.

I have a friend of mine who was in Russia a few years back while they were
trying to clone their own PC's.  One great method of debugging such home
made Russian brand machines was to use one computer to debug another computer.
How?  Somple.  You shut down the clock on one machine, let it execute one
instruction, then use the other computer to look at the memory of the
machine being debugged.  The debugger can modify memory or read memory.  It
would then execute one or many instructions on the debugged CPU by strobing
the clock.  I believe they even had a way of grabbing the current registers
on the target CPU via interrupts.  (ie: a hardware interrupt that points to
a ROM routine which then stores the current registers to some memory which is
not normally available to the program running on the debugged CPU except
when it is activated by the debugger CPU.)

Simpler schemes if I may point them out include the ISEPIK cartrige and its
ilk on Commodore 64 machines.  Infact I may point out that the Commodore128
which could emulate a C64 had a built in debugger which when the machine was
reset would let you look at most of the memory from a running C64 program! Now
some memory would be lost, granted, but a determined hacker could find a way
to get at it and create an image which could be restored later.

(Infact the C128 debugger was so good that GEOS 1.2 could be hacked with it!)
A lot of the earlier Activision games could be restarted by a simple SYS
call to one of the usual locations.  Usually restarting the computer and loading
a debugger did the trick.  With the C128, this was even easier.


Some UPS cards have the feature of saving the RAM of the currently running
machine to the drive because of a power failure.  This is evident in
notebook computers though they keep it in RAM.
(Infact the C128 debugger was so good that GEOS 1.2 could be hacked with it!)

Dan Marner:

|    I would appreciate any pointers to documents, source code or
| programs that deal with using cryptographic techniques to detect
| or prevent modification of executable code. I am looking for 
| something that uses either a signature or a one-way hash to detect
| modifications at run time. 
|    Of particular interest is information on signing a file that
| includes the signature as part of the file. Is this possible with
| any of the common algorithms?

	Tripwire will run as a seperate UNIX process to detect changes
to things that you define.  Most people who use it use it to watch
systems security.  We also use it to watch some software thats being
run through an FDA trial period; we have to document that it has not
changed at any point during the trial.

	Tripwire can be found in cert.org:pub/tools/tripwire.


Adam

-- 
Adam Shostack 				       adam@bwh.harvard.edu

Politics.  From the greek "poly," meaning many, and ticks, a small,
annoying bloodsucker.

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "MH" == Michael Handler <grendel@netaxs.com> writes:

    MH> On Fri, 8 Jul 1994, Dan Marner wrote:
    >> I would appreciate any pointers to documents, source code or
    >> programs that deal with using cryptographic techniques to
    >> detect or prevent modification of executable code. I am looking
    >> for something that uses either a signature or a one-way hash to
    >> detect modifications at run time.  Of particular interest is
    >> information on signing a file that includes the signature as
    >> part of the file. Is this possible with any of the common
    >> algorithms?

I wrote some code about six months ago to embed digital signatures
of each section of an executable in to the data section of a program
(a.out format executables). 

The program had several limitations that I know how to get around, 
but never did:
1. I only got as far signing the text section of the program
2. The signature didn't contain several important pieces of information
3. It used LUC for its algorithm, and I'd prefer to use PGP and RSAREF

Anyway, it some provides minimal security:
 If the signature is intact and verifies, you know exactly as much as
with a signed e-mail message: the author of the program (assuming you have
his public key) and that certain portions of the program haven't been 
tampered with. This is, of course useful information. I never got around
to writing the code that did verification at runtime, although it shouldn't 
be to bad: I embedded a symbol in the symbol table pointing to the signature.
I plan to try to clean it up this fall and make many changes...

    MH> I have yet to devise
    MH> or find a foolproof [ ;) ] or unbreakable protection
    MH> scheme. I'mm starting to think there's no such animal. What
    MH> you CAN do is protect your executables against file
    MH> corruption, viruses, and lame-0 hacker dudez.  

Well, it depends on what kind of protection you want. I think
foolproof runtime verification would be quite difficult, although I
still need to think about it... Any reasonable hacker would just
change most programs to jump around the verification routines. On the
other hand, I think that pre-runtime verification would be doable by a
separate program. Of course, then you have to trust that program, and
how do you verify that it hasn't been tampered with? A chicken and the egg 
problem, clearly... Let me think about it some more...

- -- 
*** Patrick G. Bridges  		patrick@CS.MsState.Edu ***
***      PGP 2.6 public key available via finger or server     ***
***             PGP 2.6 Public Key Fingerprint:		       ***
***      D6 09 C7 1F 4C 18 D5 18  7E 02 50 E6 B1 AB A5 2C      ***
***                #include <std/disclaimer.h>		       ***

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBLh2ffEoL7Aaetl5pAQEmgwP+LD90HEpuSJm2meXT1p1oTw4Y+7B4kyrj
+huFWDnnPycLmcAf8viLjP8TE5akZKydf+ZRT3Mh+YieoiVRlDgNNydPcN7me9FQ
745PLWsv9KbcvB2AbZrQLzjlCxSToCzJP2O5Vk2QAhYnuiEODc50ACF3Ek5tIDSU
k5ev1lpXUzY=
=nSUY
-----END PGP SIGNATURE-----

"dm" == Dan Marner <dmarner@mis.nu.edu> writes:

dm>    I would appreciate any pointers to documents, source code or
dm> programs that deal with using cryptographic techniques to detect
dm> or prevent modification of executable code. I am looking for 
dm> something that uses either a signature or a one-way hash to detect
dm> modifications at run time. 
dm>    Of particular interest is information on signing a file that
dm> includes the signature as part of the file. Is this possible with
dm> any of the common algorithms?
  Claris has or had some checks in their software to attempt to
recognize that the application had been modified. I think this even
detected a (previously unknown?) Macintosh virus.

  Regardless, this scheme seems rather susceptible to attack. More
useful is something like tripwire--a regularly run program which keeps
checksums of various files on disk; stores the checksums on apart from
the data; and compares the previous checksum with the current
checksum.

michael

On Fri, 8 Jul 1994, Dan Marner wrote:
>    I would appreciate any pointers to documents, source code or
> programs that deal with using cryptographic techniques to detect
> or prevent modification of executable code. I am looking for 
> something that uses either a signature or a one-way hash to detect
> modifications at run time. 
>    Of particular interest is information on signing a file that
> includes the signature as part of the file. Is this possible with
> any of the common algorithms?

There are lots of ways to detect modification of executable code, and 
possibly take some action based on the outcome.  The hard part comes when 
you consider that the code doing the checking may itself be hacked.  A 
determined hacker would just patch the code to jump around the test.  I 
suggest three things to make it harder:`

1.  Make more than one test in more than one place in the code, making it 
harder to find all of them.

2.  If you use any embeded keys, create them at run time from pieces 
stored in different places in the code and/or data.

3.  Store the code in compressed format.  One nice way to do this is with 
PKLite Professional with the -e option.

The choice of algorithms used to sign the files (i. e. DSA vs RSA vs 
salted hash vs simple CRC) is probably less important than the details 
mentioned above.  The only way to substantially increase the security of 
the check is to add a hardware device (i. e. dongle or custom hardware 
card), but people generally hate those since they are usually used just 
for copy protection.  On the other hand, clever application of the above 
software techniques is probably good enough to avoid common virii, 
unintentional damage to files, and the average hacker.

Peace to you.
Mike Johnson