This package contains the complete source code for an .EXE file
validation system that can be used in C and C++ programs. Using this
system you can make it more difficult for people to tamper with your
program's executable file. This can be of benifit to prevent users from
altering copyright notices, copy protection schemes and other
information stored in your program's .EXE file.

This package consits of two components:

1.) A small utility program, named exestamp, that will place a hash code
    "stamp" in your program's .EXE file. Currently, this hash code is a
    CRC32.
    
2.) The source code for a routine, named ValidateEXE(), that your
    program can use to determine whether or not it has been tampered
    with. This is done by comparing almost all of your program's .EXE
    file with the hash code stamp that was created using the exestamp
    utility.
    
The steps typically invovled in using this system are:

1.) Include the exevalid.h header file in your program's main module,
    using the line:
    
       #include "exevalid.h"

2.) Add a call to the ValidateEXE() function at the beginning of your
    program's main function, as demonstrated in the exedemod.c/
    exedemow.c files. The ValidateEXE() function accepts a single
    parameter, which must be a pointer to a string containing the full
    path and filename of your program's .EXE file. In DOS, this path and
    filename will be stored in the argv[0] parameter that is passed to
    the main() function. In Windows, this path and filename can be
    obtained by calling the GetModuleFileName() function. The
    ValidateEXE() function will return one of three values. A value of
    kValid indicates that the .EXE file is valid, a value of kInvalid
    indicates that the .EXE file is not valid or does not contain a hash
    code stamp, and kGeneralFailure indicates that ValidateEXE() was
    unable to allocate enough memory or was unable to access the
    specified .EXE file. If you find that ValidateEXE() is unable to
    allocate enough memory, you can adjust the size of its internal
    buffer by chaing the value of FILE_BUFFER_SIZE, in the exevalid.h
    file.
    
3.) Configure your compiler to also build and link in the exevalid.c
    file, or copy the contents of the exevalid.c file to one of your
    program's source code files. Configuring your compiler to build and
    link the exevalid.c file usually involves creating a "makefile" or
    "project file" that lists your program's source code files, along
    with the exevalid.c file.
    
4.) After building your program's .EXE file, but before executing it,
    run the exestamp utility to add a hash code stamp to your program.
    You may wish to automate the creation of the hash code by adding a
    call to the exestamp utility to your makefile. You should try to
    avoid running exestamp more than once on the same .EXE file, as
    doing so will create a second hash code stamp. Running exestamp on
    your program's .EXE file should always be the last thing that you do
    in building the program. If you are compressing the .EXE file using
    a utility such as PKLite, you must do so before running exestamp.
    
5.) When your program executes, the ValidateEXE() function will check
    that the hash code of your program's .EXE file matches the code
    created by exestamp. If the executable file appears valid, your
    program can continue executing normally. If, however, the executable
    has been tampered with, you can abort your program immediately, or
    carry out any other action that you wish.
    
The .EXE file validation system normally stores the hash code at the
very end of the .EXE file, and this hash code is calculated from all
bytes in the file up to the location of the hash code. You could modify
this system to store the hash code elsewhere, but must be careful not to
include the hash code itself in the bytes that are used to generate the
hash code.

How securely does this system prevent tampering with your program's .EXE
file? This system will almost certainly thwart a user attempting to edit
your program's .EXE file using just a hex editor. Unless the user
happens to produce a new .EXE file that generates an identical hash code
to the original, any changes will make the .EXE file appear invalid to
the ValidateEXE() function. Since this system uses a CRC32 as a hash
code, the chances of creating another .EXE file with the same hash code
are very unlikely.

However, if the user knows that your program has been protected using an
unmodified version of this package, they could alter your .EXE file, and
then calculate a new hash code stamp using the exestamp utility. If you
feel that this may happen, you may wish to use a customized version of
this system, that calculates different hash codes. To do this, simply
alter or replace the UpdateHash() function in the exevalid.c file. After
changing the UpdateHash() function, you should recompile your program
and the exestamp utility. Your modification to UpdateHash() could as
simple as adding a constant value to the hash code generated by the
function, or as sophisticated as an entirely new hash function.

This .EXE file validation package was created in 1994 by Brian Pirie,
and is released to the public domain. You are free to do what you wish
with this source code and any programs created with it. I cannot take
any responsibility for any damages incurred due to your use or inability
to use this package. Please keep in mind that no "anti-hacking" system
is 100% secure. It is your responsibility to evaluate the security of
this package in the context of your needs, before using it.

If you have any questions or comments concerning this package, please
feel free to get in touch with me by any of the following means:

   Internet Email : brian@bpecomm.ocunix.on.ca
  FidoNet Netmail : 1:243/8 (you will have to poll for a response.)
            Modem : +1 613 526 4466
Conventional Mail : Brian Pirie
                    #1416 - 2201 Riverside Drive
                    Ottawa, Ontario
                    K1H 8K9
                    Canada
