Official WinHasher Site: http://www.gpf-comics.com/dl/winhasher/
Last Updated September 21, 2007
From Wikipedia:
In cryptography, a cryptographic hash function is a transformation that takes an input and returns a fixed-size string, which is called the hash value. Hash functions with this property are used for a variety of computational purposes, including cryptography. The hash value is a concise representation of the longer message or document from which it was computed. The message digest is a sort of "digital fingerprint" of the larger document. Cryptographic hash functions are used to do message integrity checks and digital signatures in various information security applications, such as authentication and message integrity.
A hash function takes a long string (or "message") of any length as input and produces a fixed length string as output, sometimes termed a message digest or a digital fingerprint. A hash function (also called a "digest" or a "checksum") is a kind of "signature" for a stream of data that represents the contents. One analogy that explains the role of the hash function would be the "tamper-evident" seals used on a software package.
In various standards and applications, the two most-commonly used hash functions are MD5 and SHA-1.
For more information, look up "cryptographic hash function" on Wikipedia.
As described in the synopsis above, one of the primary uses of cryptographic hashes is to verify and validate computer software or digital files. It is common practice among many developers, especially in the Open Source community, to provide a hash of a file next to its download link. Once the user has downloaded the file, they can generate a hash using the same hashing algorithm on their own machine and compare this computed hash to the hash listed on the originating site. If the two hashes match, the user can then safely assume that (1) the downloaded file arrived intact and uncorrupted and (2) it has not been tampered with since the original hash displayed on the site was posted.
However, security experts will wisely caution that this does NOT guarantee that downloaded file is completely safe. A hacker or malicious system administrator could have easily modified the file after the developer posted it, recomputed the hash, and placed the modified file and hash in the original's place. It also does not guarantee that the file is free from viruses, trojans, or other malware that have infected the file before the hash was computed. Therefore, cryptographic hashes should be just one in a series of checks a user should perform before deciding that a file downloaded from the Internet is safe to use.
Cryptographic hashing is readily available on many computer operating systems. It often comes built-in to the OS or as a (relatively) standard optional package. Mac OS, Linux, Free/OpenBSD, and many other OSes include OpenSSL as either a pre-installed or easily installable optional component. OpenSSL includes several command-line components for generating cryptographic hashes and there are number of graphical user interface (GUI) applications that allow point-and-click access to its capabilities.
Not so with Microsoft Windows. Windows does not include any built-in utilities for cryptographic hashes, and installing and using OpenSSL on Windows is not a trivial matter. The typical Windows user of today is much less familiar with the Windows Console (i.e. command line) let alone compiling software from source. And while cryptographic hashes are pretty much standard in programming libraries such as the Microsoft .NET Framework, the user is required to write and compile their own applications to use them.
This "hashing divide" has annoyed me for some time. While I consider myself to be an operating system agnostic and find myself equally home on both Windows and Linux, there are many times I've downloaded Windows-only software but didn't have the capability to verify the file's hash. Either I've been unable to install and run OpenSSL on a given machine, or I haven't had the time or access to a Linux box to copy the file over, generate the hash, and verify it before install. So I wanted to create a quick, simple, easy-to-use Windows app so I could get the hash of a file without waiting or moving it around. I also thought it would be a nice idea to be able to quickly compare the hashes of multiple files without having to generate each one and manually check every hexadecimal digit, so I added that functionality too. After writing the program, I thought it might be useful to others, so I decided to share.
WinHasher supports the following cryptographic hashes, which are made available by default through the Microsoft .NET Framework either as pure managed classes or interfaces to the unmanaged Microsoft CryptoAPI:
In addition, the following hashing algorithms have been added, either from freely available sources or completely written from scratch by myself:
It is my eventual goal to include other cryptographic hashes into this application, either by including code from freely available sources or by writing the algorithms myself.
[ Return to Table of Contents ]
The primary system requirement for WinHasher is the Microsoft .NET 2.0 Framework. This is a special series of common libraries that specially-built applications can call upon to provide standard Windows functionality. (Hard-core developers will recognize this is a gross oversimplification, but that should suffice for most people.) As such, WinHasher will not work unless .NET 2.0 is installed. .NET itself has its own system requirements that must be met in order for it to be usable, but if your system meets these requirements running WinHasher will be no problem.
To download the Microsoft .NET 2.0 Framework or obtain more information about it, click here. It should also be available through Windows Update or Microsoft Update on most versions of Windows newer that Windows 98SE. Note that .NET 3.0 or higher is NOT an "upgrade" from 2.0; it is a separate framework, designed to be installed alongside 2.0. So if you have .NET 1.1, 3.0, or any other version of the framework installed, you still must install .NET 2.0 for WinHasher to work.
Beyond .NET's own requirements, WinHasher doesn't require much. However, since cryptographic hashes are very CPU intensive to produce, it should be pointed out that WinHasher will perform better with more RAM and CPU horsepower available. Therefore, the faster your CPU is and the greater amount of free RAM available, the faster WinHasher will work. This is especially true for multi-file comparisons of very large files.
Installing WinHasher should be a breeze, thanks to InnoSetup. Simply download and run the installer program, just like you would for virtually any Windows application. However, the setup program include a number of options that can get confusing, so let's talk a little about each one.
After choosing the install location, you will be presented with a series installable "components." There are three main components: the WinHasher Windows application, the WinHasher console (command-line) application, and the HTML help files. Since this help file pertains to the console application, we will ignore the Windows application option for now. Installing the HTML help installs this file and the necessary shortcuts to access it.
When you install the console version of WinHasher, the installer will run a little helper application that will add the path to the console programs to your system's PATH environment variable. That way you will be able to access WinHasher from any directory on your system. WinHasher tries to play nice and appends its path to the end of the PATH so it shouldn't interfere with other programs. Note, however, that if your PATH is ridiculously long it could cause problems and Windows won't be able to find the programs. If you decide to uninstall WinHasher, it will also clean up after itself and remove its path from the PATH. (I hate it when other programs don't do this.) Note that on Windows 98 and ME, changing the PATH requires a reboot to take effect; on NT-derived systems (including 2000, XP, and Vista) you must close all open console windows and restart them before the PATH change takes effect.
One of the beauties about using the .NET Framework to develop WinHasher is that it's technically not restricted to Microsoft Windows. Anyone can (in theory) develop their own .NET framework based on Microsoft's specifications to run on any platform, and thus run any .NET application built for that framework. Mono is one such project which runs .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. However, at the time of this writing, Mono mostly supports .NET 1.1 and only partially supports .NET 2.0. MoMA reports that WinHasher should work with Mono 1.2.5 (or higher, I assume). However, I do not plan to officially offer support for non-Windows use of WinHasher. Personally, I think there are much better tools already available for other OSes, and you'd be better off using those instead. Still, if you're a glutton for punishment, feel free to give it a try.
[ Return to Table of Contents ]
hash programThe primary console program for WinHasher is hash. Run without any arguments, hash will display a somewhat standard usage statement:
C:\Program Files\WinHasher>hash
WinHasher v. 1.0.0.0
Copyright 2007, Jeffrey T. Darlington. All rights reserved.
http://www.gpf-comics.com/dl/winhasher/
Usage: hash [-md5|-sha1|-sha256|-sha384|-sha512|-ripemd160|-whirlpool|
-tiger] filename1 [filename2 ...]
WinHasher first looks at the first argument to see if it is a switch that
indicates which hash to use. If found, it will use that hash algorithm;
if a switch is not found or is otherwise invalid, it will default to MD5.
It will then treat the rest of the inputs as paths to files. If the file
path contains spaces, make sure to enclose the entire path in quotes.
If only one file is specified, its hash will be returned. If more
than one file is specified, the hash of each file will be computed
and then compared. If all the hashes of all the files match, you will
receive a happy notification as such. If one or more of the hashes do
not match the others, a warning will be displayed.hash expects at least one command-line argument: a file to compute a hash for. If you supply a file name as an argument, hash will by default compute the MD5 hash of the file and return a hexadecimal representation of it:
C:\Program Files\WinHasher>hash C:\some\path\to\somefile.jpg 714168454140a73321c3dca260abf366
If the file's path contains spaces, you must include the entire path in double quotes:
C:\Program Files\WinHasher>hash "C:\This path has spaces\somefile.jpg" 714168454140a73321c3dca260abf366
If you specify multiple files on the command-line, hash enters comparison mode. The hash (MD5 by default) for each file is computed individually, then all the hashes are compared. If the hashes of every file specified are equal, then all the files are said to match:
C:\Program Files\WinHasher>hash file1.jpg file2.jpg Congratulations! All 2 files match!
However, if at least one file in the batch does not match the others, then the entire batch fails the test. So it's an all-or-nothing comparison:
C:\Program Files\WinHasher>hash file1.jpg file2.doc WARNING! One or more of these 2 files do not match!
Of course, while MD5 is the default hashing algorithm, it is far from the best choice. MD5 has been proven to have a number of collisions, so many security experts discourage its use. (However, it is still the prevalent hashing algorithm used on the Internet today, and thus why it's still the default.) To change which hashing algorithm to use, supply the appropriate algorithm switch as the first command-line argument. So for SHA-256:
C:\Program Files\WinHasher>hash -sha256 somefile.jpg ed25e7af09323d82af975641cbcd291368e50f173fd191e7760d05244aada29f
The algorithm switch consists of a hyphen (not a slash, which is the standard Windows command-line switch prefix, because it's always my hope to support other platforms) followed by the algorithm name in all lower case. Any punctuation (like the hyphens for the SHA family) are dropped. If you're ever in doubt on what a switch for a particular algorithm is, just run hash with no arguments to get the usage text. The algorithm switches will be listed and should be pretty easy to figure out.
The algorithm switch is always the first argument supplied, when present. If the first argument is not a recognized algorithm switch (say, you made a typo and typed hash -sha258), an error message is displayed and the algorithm defaults to MD5. Then the first argument is treated as a file name, which may or may not be what you wanted. (In this example, "-sha258" is not likely to be a valid file name.)
The algorithm switch can, of course, be combined with multiple file arguments to do a comparison using that particular hash. For example, to compare three files using RIPEMD-160:
C:\Program Files\WinHasher>hash -ripemd160 file1.jpg file2.jpg file3.jpg
md5 and sha1Because MD5 and SHA-1 are so prevalent on the Internet, as a convenience, I've also included two alternate programs, md5 and sha1, that perform just these hashes. md5 is equivalent to running hash -md5, while sha1 is equivalent to hash -sha1. Neither of these programs will accept the algorithm switches as the first argument.
Creating these extra programs is a bit redundant, but Windows does not have a mechanism for aliases or symbolic links. If there is enough demand, I can create other "convenience" programs for the other algorithms. However, I also believe in the concept of less is more, so I will only go that route if there are enough requests.
[ Return to Table of Contents ]
This document is © Copyright 2007, Jeffrey T. Darlington. It and the software it describes are released under the GNU General Public License, Version 2.