How to Use Hash Values to Check Whether Officially Distributed Files Have Been Modified

A hash value can show whether a downloaded file matches the exact file represented by an official reference value. The process requires three things: the correct file, the same hashing algorithm used by the publisher, and a trustworthy source for the expected result.

The filename and displayed file size are not enough. A modified installer can retain the original name, extension, and approximate size. Hashing reads the contents and produces a fixed-length digest. Even a small change to the data normally produces a completely different result. Microsoft describes file hashes as content-based values and notes that changing the file without changing its name or extension still changes the calculated hash.

A matching result means that the local file corresponds to the version used to generate the published hash. It does not prove that the software is harmless, free of vulnerabilities, or genuinely supplied by the company named on an untrusted page. The credibility of the reference value must be established separately.

For installers, firmware, operating-system images, device recovery packages, and administrative tools, the stronger process is to combine hash comparison with a digital signature or signed checksum file whenever the publisher provides one.

Trusted Reference Hash Sources

The expected hash should come from the organization responsible for the file. Suitable locations include the developer’s official download page, release notes, authenticated software repository, security bulletin, or official checksum file.

Avoid copying the value from an unrelated blog, discussion post, download directory, or file-sharing page. A third party can publish a modified installer and calculate a matching hash for that modified copy. The calculation would be correct, but it would say nothing about whether the file came from the legitimate publisher.

A checksum shown beside the download on the same compromised page has a similar limitation. If an attacker can replace both the file and the displayed value, the comparison will still succeed. GnuPG’s own integrity guidance warns that altering a file and the checksum displayed on the same webpage may require little additional effort. It recommends using release announcements and, preferably, signed releases as stronger references.

Record the page or release notice from which the expected value was obtained. When mirrors are involved, the file can come from an authorized mirror while the expected digest comes from the original project.

A stronger arrangement separates the two channels. For example, the software may be hosted on a mirror, while a signed checksum list is published through the developer’s official repository or release announcement. Compromising both independent locations is generally more difficult than altering one page.

SHA-256 and SHA-512 Selection

For ordinary security-oriented file integrity checks, SHA-256 or SHA-512 is usually the appropriate choice when the publisher supplies either one. Both belong to the SHA-2 family specified in NIST’s Secure Hash Standard. NIST describes these algorithms as methods for generating message digests that can reveal whether data has changed since the digest was produced.

Do not guess the algorithm solely from the appearance of the value. Follow the label used by the publisher. SHA-256 is often displayed as 64 hexadecimal characters, but a digest can also be encoded in Base64 or another supported format.

MD5 and SHA-1 may still detect accidental corruption, but they should not be the preferred security check for software that could have been deliberately substituted. Microsoft’s current PowerShell documentation states that MD5 and SHA-1 are no longer considered secure against attack. GNU Coreutils similarly classifies SHA-2 as suitable against malicious tampering while describing MD5 and SHA-1 as unsuitable for that purpose.

Use the strongest officially supplied option rather than calculating an unrelated algorithm. A locally generated SHA-512 value cannot be compared with a publisher’s SHA-256 reference. Both sides must use the same algorithm and representation.

When the publisher offers only an old checksum for a security-sensitive download, look for another validation route. A code signature, detached OpenPGP signature, signed repository metadata, or authenticated package manager can provide stronger evidence than an unsigned MD5 or SHA-1 value.

Exact File Identity

Checksums are tied to exact file contents. Two packages for the same application can legitimately produce completely different hashes.

Before starting the comparison, confirm the full filename, product version, patch number, build identifier, operating system, processor architecture, language, and package format.

A Windows x64 installer should not be compared with the value for the ARM64 package. A macOS disk image will not match a Linux archive. A revised build uploaded under a new version number will produce a different result even when the visible program name remains unchanged.

The release date also helps resolve mismatches. A publisher may replace a defective installer while retaining a similar filename. The new file will have a new hash, and an older release notice may still show the previous value.

Save these details together:

• Full filename and extension
• Product version and build number
• Operating system and architecture
• Download date
• File size
• Hash algorithm
• Official expected digest

The file size is useful as a preliminary warning but not as proof. Two different files can have the same size. The digest comparison remains necessary.

Local Hash Calculation

Calculate the hash on the computer that holds the downloaded file. Uploading an installer, firmware image, or confidential package to a random online checksum service is unnecessary and may disclose the file to another party.

On Windows, PowerShell provides Get-FileHash. SHA-256 is its default algorithm, although stating the algorithm explicitly makes the command easier to review later.

Get-FileHash "C:\Users\Name\Downloads\example.iso" -Algorithm SHA256

For SHA-512:

Get-FileHash "C:\Users\Name\Downloads\example.iso" -Algorithm SHA512

The output identifies the selected algorithm, calculated hash, and file path. Confirm that the path points to the actual downloaded file rather than an older copy stored in another folder.

On macOS, Terminal includes shasum. Apple’s official package-management guidance uses the following SHA-256 form:

shasum -a 256 "/Users/Name/Downloads/example.dmg"

For SHA-512:

shasum -a 512 "/Users/Name/Downloads/example.dmg"

On Linux systems with GNU Coreutils, use sha256sum or sha512sum. GNU documents these commands as utilities for producing and validating SHA-2 digests.

sha256sum "/home/name/Downloads/example.iso"

sha512sum "/home/name/Downloads/example.iso"

These commands read the file without modifying it. Large ISO images and firmware packages may take longer because the entire file must be processed.

Complete Digest Comparison

Compare the entire digest, not only the first or last several characters. A partial visual match is not an integrity check.

Hexadecimal letters are generally case-insensitive, so uppercase and lowercase versions of the same digest are equivalent. Formatting spaces can be removed when they are used only to improve readability. Do not remove, reorder, or ignore actual characters within the value.

Copy the calculated and expected values into a local text editor when visual comparison is difficult. Another option on PowerShell is to store the official value and let the shell perform the equality test:

$expected = "PASTE_THE_OFFICIAL_SHA256_VALUE_HERE"
$actual = (Get-FileHash "C:\Users\Name\Downloads\example.iso" -Algorithm SHA256).Hash
$actual -eq $expected

A result of True means the strings match. The accuracy of the conclusion still depends on whether $expected came from the correct official release and represents the same package.

When a project provides a checksum file in the expected GNU format, Linux can validate it directly:

sha256sum --check SHA256SUMS

This method reduces copying errors, but the checksum file itself must still come from a trusted source or carry a valid digital signature.

Mismatch Investigation

Do not run, install, extract, mount, or flash a file whose digest differs from the official value.

Begin with ordinary causes. Confirm that the expected value belongs to the same version, architecture, language, and package type. Verify that SHA-256 is being compared with SHA-256 rather than SHA-512, SHA-1, or MD5.

Confirm the encoding as well. A publisher may display the digest in Base64, while the local command produces hexadecimal output. The underlying digest may be the same even though the text looks completely different.

When the package and format are correct, delete the questionable copy and obtain it again from the publisher or an authorized mirror. Recalculate the hash on the new file.

A successful second comparison suggests that the first copy was incomplete or corrupted. A repeated mismatch can mean that the publisher replaced the file without updating its documentation, a mirror is serving an older build, a caching layer returned another version, or the download has been altered.

Do not decide which explanation is correct without evidence. Review the newest official release notes and security notices. Contact the publisher through a separately confirmed support channel when the discrepancy remains unresolved.

For software installers obtained outside an operating system’s managed application store, the download process is only part of the risk. How to Avoid Bundled Programs When Installing a Torrent Client is also relevant before running an installer that may offer additional software, browser changes, or optional components during setup.

Hash Matching and Digital Signatures

A matching hash establishes consistency with the referenced file. A digital signature can additionally connect the file or checksum list to a signing identity.

For OpenPGP releases, publishers may provide a detached .sig or .asc file. A typical command is:

gpg --verify example.iso.sig example.iso

GnuPG advises using an already trusted installation to verify the downloaded release. Using the newly downloaded copy of GnuPG to authenticate itself defeats much of the purpose.

A message saying “Good signature” confirms that the signature is mathematically valid for the displayed key. It does not automatically prove that the key belongs to the legitimate publisher. Compare the complete key fingerprint with a value published through an independent official channel. GnuPG specifically recommends checking the fingerprint when the key has not already been established as trusted.

Windows executable files and scripts may use Authenticode. PowerShell can inspect the signature with:

Get-AuthenticodeSignature "C:\Users\Name\Downloads\installer.exe"

Microsoft explains that Authenticode combines code integrity with certificates issued through trusted certificate authorities to identify the software publisher. The PowerShell command reports the file’s signature information and whether its status is valid.

A valid signature deserves further review when the publisher name is unexpected. Malware can also be signed, and a valid certificate does not guarantee good software behavior. The signer should match the organization expected to distribute the application.

On macOS, signed installer packages can display certificate information through the Installer interface. Apple states that its package installer verifies signed package contents and stops when an integrity problem is detected.

Practical Verification Standard

A useful decision standard is based on both the result and the source.

When the full SHA-256 or SHA-512 digest matches a value taken from the correct official release, the local file corresponds to the publisher’s referenced copy.

When the digest does not match, the file should remain unopened until the version, algorithm, download source, and publisher documentation have been reconciled.

When the digest matches a value found only on an untrusted download page, the comparison proves only that the page and file agree with each other. It does not establish that either came from the claimed publisher.

When a digital signature is valid and the signing certificate or OpenPGP fingerprint has been independently authenticated, the evidence is stronger because both integrity and signing identity have been examined.

Hash verification is most valuable for files capable of changing a system: installers, operating-system images, firmware, recovery tools, drivers, security applications, and administrative utilities. The process takes only a few commands, but it prevents a corrupted, incorrect, or substituted package from being accepted solely because its filename and download page look familiar.