Distributing Software to Distance Education Students – Checksums

One of the issues with distributing software to distance education students is ensuring that the software package they are trying to install hasn’t been corrupted ins some way during transport. For example, one of the ways we ship software to students is via USB memory stick. But in one course last year, it seems that some of the sticks were a bit dodgy, and the files wouldn’t install from them.

Which is where checksums come in.

If a student is having issues installing a piece of software, we can check the checksum of the distributed installer package to see if it matches the checksum of a pristine package. If it doesn’t, we know the problem is a corrupted installer package (rather than a problem downstream of that, for example).

So what is a checksum? Essentially, it’s a single number derived from all the bits in the file you’re generating the checksum for. If any bit in the file is changed, the checksum should too.

So here are a couple of ways of generating checksums…

---

WINDOWS:

Download the Windows fciv (Windows File Checksum Integrity Verifier) utility: https://support.microsoft.com/en-gb/kb/841290

Run a command of the form:
fciv.exe c:\Users\MY_USER\PATH\FILE_CHECK.SUFFIX

This will produce checksums using different coding mechanisms:

MD5(FILE_CHECK.SUFFIX)= SOME_LONG_HEXADECIMAL_STRING
SHA1(FILE_CHECK.SUFFIX)= A_DIFFERENT_LONG_ALPHANUMERIC_STRING

---

MAC / LINUX:

On a Mac, you can find the checksum using the following command:

openssl sha1 PATH/FILE_CHECK.SUFFIX
openssl md5 PATH/FILE_CHECK.SUFFIX

For example:

openssl md5 ~/USERRELATIVEPATH/FILE_CHECK.SUFFIX
SHA1(PATH/FILE_CHECK.SUFFIX)= SOME_LONG_HEXADECIMAL_STRING

---

If we distribute a copy of the checksum for installer packages, along with the installer packages, assuming that the checksum is not corrupted, a student can check that the installer package is not corrupted by generating the checksum for their installer package and comparing it to the distributed one.

When it comes to support in the event of a problem, and a call to the help desk, then the first question from support can be: “Have you checked the checksum of the original package?” (Or we can prompt students to do this themselves as part of self-service support…)

Even better if we shipped a simple one-click file integrity checking utility that:

1) runs a checksum test on itself to check that it’s working;
2) runs a checksum test on the distributed package(s) to check that they are not corrupted.