Calculating a File Checksum

The checksum of a file is calculated using a hash function which outputs a string of characters of a given length depending on the function used. The file can be of any size and will always give the same checksum for a given function as long as no character in the file is changed. If only one character in the file is changed, the checksum calculated is completely different from the original. This provides a way to tell if a file has been changed or not. You calculate the checksum of a file and compare it with the published checksum. If they are different, then either the file has been changed or the published checksum is wrong. In either case, you would infer that the file cannot be safely used. The checksum acts as a fingerprint or thumbprint.

There are many programs which calculate checksums for arbitary files (for example AllIncCheckSum.exe) but the problem is this: In order to calculate a file checksum and compare it with the published checksum, you have to download and install the program to do the checksum calculation.

How do you know that this program is safe? Well, the program might be digitally signed, but you need the root certificate of the signing certificate's certificate chain installed on your PC. If you don't have these installed, then you have to install the certificates in the chain from a file, but this time you need to know if the file is safe. So, unless you know the author of the program (or file) personally, in which case you can gauge whether or not to trust the program, you need some other way to determine the program's (of file's) safety. In 2004, Microsoft provided a small program called FCIV.exe (the File Checksum Integrity Verifier) which can calculate the checksums for files.

For your safety, AllIncontext uses three methods for you to review the checksum:

• If a file needs a checksum, it is calculated and displayed on the relevant web page. This checksum is compared with a stored checksum and if there is a mismatch, an Error will be displayed on the web page and an item placed in the log file so that the problem can be corrected as quickly as possible. The stored checksum is secured by compiling the .NET assembly that displays the web page, and the assembly is strong named (that is, digitally signed). Any unauthorized change in the assembly means that it will not pass the .NET framework security checks.
• Instructions are given below on how to download Microsoft's digitally signed checksum program which can be used to calculate an arbitrary file checksum, which can then be compared with the published checksum (usually to be found on a web page). Since the Microsoft certificate chain is already installed on your PC, you don't have to download any additional file.
• The first method gives protection against a file being tampered with on a web server, and the second method allows you to re-calculate the file checksum on your PC. Unfortunately, there is a possibility (however small) that the web page you see and the file you download are subject to a Man-in-the-Middle attack. This can happen when you access a web page via both http:// and https:// (the use of SSL is no guarantee against an attack).
  One way to reduce this window of opportunity on Windows Vista and later is to duplicate the first method above on your PC. This requires you to download the AllIncVerifyCheckSum.exe program which is digitally signed. You still have to install the P7B files (but remember these are only text files and contain no code). You then run AllIncVerifyCheckSum.exe and if User Account Control (UAC) is active (note this will not work on Windows XP) any discrepancy in the EXE or the AllIncontext Root and Intermediate certificates for code signing will result in a pop-up window telling you there is a problem. Microsoft protects this window against malicious programs by using the Secure Desktop.
  If the pop-up window tells you that the EXE is OK, you still don't know if the P7B files might have had additional certificates added by the Man-in-the-Middle, who also changed the web page data stream to give you his (or her) File Checksum. These certificates could chain up to any Root certificate in your certificate store. To protect you against this, just drag and drop the P7B file onto the AllIncVerifyCheckSum.exe FileName Edit box. The File Checksum will be calculated and compared with the stored value (Note: this will only work for AllIncontext downloadable files such as P7B and Zip). If they match, then the P7B file has not been manipulated. If the AllIncCheckP7B.exe program were changed without being re-signed, UAC will not be able to verify the digital signature and you will see the pop-up window.

If you use these methods, the probability that any given file has been tampered with is minimized. Remember, maintaining security takes time and effort, but clearing up problems takes considerably longer (and will cost you more). For more information on FCIV (for example: how to get and install it), click here.

FCIV can calculate the checksum of a single file or of all files in a given folder. In order to keep things simple, we can create a batch file to run FCIV on Windows XP and a Powershell script to run FCIV on Vista and later. The batch file and the script will do the same thing: calculating all the checksums of files in a sub-folder of the FCIV folder and putting the results into a text file in the FCIV folder. You can then open this file and compare the calculated and published checksums.

For more information on the Windows XP batch file (and how to run it and calculate checksums), click here.
For more information on the Vista and later Powershell script (and how to run it and calculate checksums), click here.

Note: In Vista and later, files downloaded from the Internet are tagged with Zone information (such as coming from the Internet Zone). This tagging is done using Alternate Data Streams for a given file. These streams are a feature of the Windows NTFS file system. This means that a script file will not be run unless it is unblocked. As a further security measure, PowerShell has a default execution policy of Restricted which means it will not run any script. If the policy is changed to RemoteSigned, all scripts downloaded from the Internet, and properly signed, can be run. Furthermore, any unsigned script can be run if that script is unblocked. The steps for doing this are given in the Powershell script link above.

Once you are familiar with these steps, calculating checksums becomes a quick process. Note: You can use the powershell steps on XP if you have installed powershell on your XP PC, then you only have a single set of steps across Windows Operating Systems.