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!)
"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
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-----
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
participants (7)
-
Adam Shostack -
Dan Marner -
Michael Handler -
michael shiplett -
Mike Johnson second login -
Patrick G. Bridges -
rarachel＠prism.poly.edu