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