A desktop updater that hashes itself before it trusts a download

A desktop program that replaces its own executable is doing something an attacker would like to be able to do for them. The update path has to answer a plain question: how does the program know the file it is about to run is the file that was published? Tantalum answers with hashes, checked twice.

What happens at launch

When Tantalum starts, the updater runs through four steps:

1. It computes the SHA-256 hash of the executable that is currently running.
2. It fetches the latest release from the project's GitHub releases, and the matching .sha256 file published beside the download.
3. It compares the two hashes. If they differ, a different build has been published.
4. If the remote version is newer, it offers the update.

The comparison is between the file on disk and the published hash, not between two version strings. A version number is text anyone can type. A hash only matches when the bytes match.

Windows builds are published as zip files, so the hash file describes the .exe inside the archive, and that is the file the running program is compared with.

Verified again before it replaces anything

If the user accepts the update, the new binary is downloaded and hashed a second time. Only if that hash matches the published one does the updater replace the program and restart it. A download that was cut off, corrupted or swapped on the way fails the check and nothing is replaced. The download has a five minute timeout, because installers are large and connections vary.

Never on a development build

An updater that runs on a developer's machine can overwrite the build being worked on. Tantalum only offers updates to a published install. The check looks at where the program is running from, and it declines when the process is a .dll hosted by dotnet run, or when its path is inside a bin\Debug or obj folder. In those cases it logs that the update was skipped because this is a development build.

What the log says

Every step is logged. For each check the log records the latest release version, the asset name, the local hash and the expected hash, and then either that a new version is available or that the program is up to date. If the check fails for any reason, such as no network, the failure is logged and the program carries on without an update. A failed check is never a reason to stop the program starting.

What it does not do

A hash published next to a download proves the download matches what was published. It does not prove the publisher is who you think. If someone who controls the release page replaced both files, the hashes would still match each other. The protection is against corruption and against a swapped download file. Signing the release, which ties the binary to a key, is the next step up, and it is a different mechanism from the one described here.

The rest of how Tantalum behaves as a Windows application is in the overview. The current download is on the Tantalum page.

Written by Caisson AI. Questions or corrections go to hello@caissonai.co.