To install, simply download the installer, run it, and follow the on-screen instructions. Like most Windows software, this shell extension can be uninstalled using the program uninstallation applet found in the Windows Control Panel.
For advanced users: To run the installer in quiet (unattended) mode, invoke the installer with the /quiet command-line switch, and to extract the files to the current directory without installing, invoke the installer with the /extract command-line switch.
Technically, yes, but for all practical intents and purposes, no. Since checksums digest a potentially infinite number of bits down to a small, finite number of bits, there will be "collisions". However, the likelihood of such collisions happening randomly is extremely low. Even for the "weakest" algorithm, CRC-32, the probability that, given a file, you will find a different file with the same checksum is 1 in 4 billion. For 128-bit checksums (MD4, MD5), the probability is an unfathomably small 1 in 340 billion billion billion billion, and for SHA-1, it is even smaller.
While random collisions are all but impossible, someone may try to specially craft a file that has the same checksum as another, different file. This is feasible (though it may be difficult, depending on the algorithm) with CRC-32, MD4, and MD5, but it is not feasible with SHA-1.
Check for data corruption: The most common use for checksums is to verify that data is intact and uncorrupted. It is often a good idea to check the checksum of a large download against a known, expected checksum to ensure that you have all the bytes and that there was no corruption in the transmission. Many file sharing applications use checksums to verify the integrity of each piece of data that it receives; with HashCheck, you can perform this sort of verification with anything that you download.
Know if two files are the same: Instead of directly comparing two files to see if they are the same, you can compare their checksums; this can be useful when it is not practical or convenient to directly compare two files.
Know what files have changed: If you create a checksum file of a collection of files, you have essentially taken a "fingerprint" of a "snapshot" of that data; if you take another such "fingerprint" later on, you can compare the two to see what files in the collection have been changed, added, and removed.
Limited authentication of data: If you are using a "secure" algorithm (i.e., it is not feasible for someone to craft a different, malicious piece of data that has the same hash as a piece of good data; SHA-1 is secure) and you have a hash that is trustworthy, then you can use that to verify if a piece of data is trustworthy. Note that the second condition is very important: If someone has maliciously tampered with a piece of data, he could easily calculate a new checksum for the tampered data and feed that checksum to you. So in order for a checksum to be useful in verifying security, you must first be able to trust the checksum. For example, imagine a software publisher that tries to distribute a piece of software through a third-party mirror (which you do not trust) or through file sharing (which you trust even less) in an attempt to reduce bandwidth costs. If they post the hashes of their files on their own, reasonably trustworthy server, then you can use them to verify that what you downloaded from the untrustworthy third-party mirror is authentic.
Authenticate data: For true authenticity verification, you should look at public key cryptography and digital signatures because hashes can only validate data if the hash itself can be trusted, and the only way to fully establish the trust of a hash is to couple it with cryptography (which, effectively, is what a digital signature is).
Recover or repair data: Checksums can only tell you if data is corrupted; it cannot fix that corruption. For this, you need to couple checksums with redundancy data, such as Reed-Solomon codes (optical discs such as CDs make extensive use of such error-correction codes).
Know what exactly has changed: While checksums can tell you which files have been altered, it cannot how the content of each file has been altered; it is not a replacement for diff.
HashCheck supports the CRC-32, MD4, MD5, and SHA-1 algorithms.
HashCheck creates checksum files in the SFV format for CRC-32, and in a format compatible with the output of the standard md4sum, md5sum, and sha1sum tools for the other algorithms; checksum files produced by HashCheck can be encoded in UTF-8, UTF-16LE, or the system's default ANSI code page.
HashCheck can read SFV checksum files as well as checksum files created by directing standard md4sum, md5sum, or sha1sum output to a file. It can detect and handle virtually any sort of character and line-ending encoding: UTF-8 (with or without signature), UTF-16LE/BE (with or without BOM), or the default ANSI code page on your system.
Many algorithms are flexibly defined with respect to variables such as the desired output size (e.g., ranging from 224 bits to 512 bits for SHA-2) and the number of rounds used (e.g., 3 to 5 for HAVAL), which means that in order for the algorithm to be useful, the person creating the hash will have to specify these parameters, and most importantly, the person verifying the hash will have to know what parameters were used when creating the hash. This, along with the relative rarity of many of the algorithms out there, make them unsuitable for the intended use cases of HashCheck.† After all, you do not calculate a hash for a file just because you can—the hash has to be useful, which many of these are not.
† To detect non-malicious corruption and damage, 32-bit is adequate, 128-bit is overkill, and using anything greater than 160-bit demonstrates a lack of understanding of hashes and checksums. To protect against malicious corruption, SHA-1 is secure, and if you find that you need something stronger, then you should be looking at digitally signing your files instead of using HashCheck.
As a shell extension, HashCheck was designed to be integrated into and invoked from Windows Explorer, so command-line support is very limited.
Verifying a checksum file: The following command will open a checksum file for verification in the HashCheck GUI:
rundll32 %WinDir%\System32\ShellExt\HashCheck.dll HashVerify_RunDLL example.md5
Creating a checksum file: HashCheck does not support the creation of checksum files from the command line, but you can use tools such as hashutils for this. For example:
sha1sum *.zip > example.sha1
Since shell extensions are run "in-process", a shell extension must be compiled to use the same CPU instruction set as its host process. For example, when you are running the 64-bit version of Windows Explorer, you will need the 64-bit version of the shell extension. If, however, you are using the shell extension from the Open File dialog of Microsoft Office (which is a 32-bit process), then you will need the 32-bit version. Since you can run both 32-bit and 64-bit host processes, both the 32-bit and 64-bit versions of the shell extension need to be installed on 64-bit versions of Windows. Similarly, this is why 64-bit versions of Windows contain two versions of every system DLL: one for use by 32-bit processes, and one for use by 64-bit processes.
The extended context menu is the what you get when you hold down the Shift key while invoking the context menu in the Windows shell.