Как проверить контрольную сумму установщика Windows перед запуском и зачем это нужно

Контрольная сумма — это короткая строка символов, уникально идентифицирующая содержимое файла. Даже изменение одного бита в установщике полностью меняет полученный хеш. Сравнение вычисленного значения с эталонным, опубликованным разработчиком, — единственный надёжный способ убедиться, что файл не повреждён при загрузке и не был подменён злоумышленниками.

Главный ориентир: всегда сверяйте SHA-256. Это текущий стандарт для распространения ПО. MD5 и SHA-1 считаются устаревшими — для них известны коллизии, позволяющие подобрать другой файл с тем же хешем. Если разработчик публикует только MD5 или SHA-1, используйте их, но относитесь к такому распространению с осторожностью.

Зачем проверять хеш перед запуском

Три основных сценария, когда верификация критична:

• Загрузка с зеркал или сторонних источников. Официальный сайт может отдавать файл через CDN или редиректы на файловые хостинги. Промежуточный сервер может подменить исполняемый файл, добавив нежелательное ПО или вредоносный код.
• Подозрение на повреждение при передаче. Нестабильное соединение, обрыв загрузки, ошибки диска или антивирус, «лечащий» файл на лету, могут изменить бинарник так, что он запустится, но будет работать некорректно.
• Получение файла по незащищённому каналу. HTTP без TLS, локальная сеть, флешка, переданная третьим лицом — в этих случаях нет гарантии, что файл дошёл до вас в исходном виде.

Если вы качаете установщик с официального HTTPS-сайта крупного вендора (Microsoft, Adobe, JetBrains, GitHub Releases) и браузер не сообщал об ошибках, риск минимален. Проверка всё равно полезна как привычка, но не обязательна каждый раз.

Где найти эталонные значения

Разработчики публикуют хеши в нескольких местах. Порядок надёжности:

1. Страница загрузки на официальном сайте. Часто в виде раскрывающегося блока «Checksums», «Verify download» или отдельной ссылки на файл .sha256 / .sha256sum рядом с инсталлятором.
2. GitHub / GitLab Releases. В описании релиза или в активе SHA256SUMS / SHA256SUMS.txt.
3. Файл с хешами в том же каталоге на FTP/HTTP-зеркале. Обычно называется SHA256SUMS, sha256sum.txt или аналогично.
4. Ключи подписи (PGP/GPG). Некоторые проекты (например, VeraCrypt, Tor, Linux-дистрибутивы) подписывают файл хешей или сам инсталлятор detached-подписью .asc / .sig. Это даёт гарантию авторства, а не только целостности.

Важно: эталонный хеш нужно брать из того же источника, что и информация о релизе, а не из случайного блога или форума. Если на странице загрузки нет хешей — это повод насторожиться, но не повод отказываться от программы. Многие легатимные проекты всё ещё не публикуют их открыто.

Встроенные средства Windows: PowerShell и certutil

Дополнительное ПО не требуется. В Windows 10/11 и Windows Server 2016+ доступны два нативных способа.

PowerShell — Get-FileHash

Самый удобный вариант. Поддерживает SHA256 (по умолчанию), SHA1, SHA384, SHA512, MD5.

Get-FileHash -Path «C:\Path\to\installer.exe» -Algorithm SHA256

Результат — объект с полями Algorithm, Hash, Path. Хеш выводится в верхнем регистре без пробелов. Для сравнения с эталоном (часто в нижнем регистре) удобно привести к единому виду:

(Get-FileHash «C:\Path\to\installer.exe» -Algorithm SHA256).Hash.ToLower()

Если нужно проверить несколько файлов сразу:

Get-ChildItem «C:\Downloads\*.exe» | Get-FileHash -Algorithm SHA256 | Format-Table Path, Hash -AutoSize

certutil — классическая утилита

Работает во всех поддерживаемых версиях Windows, включая старые сборки без PowerShell 5+. Синтаксис:

certutil -hashfile «C:\Path\to\installer.exe» SHA256

Вывод содержит хеш в виде групп по два символа, разделённых пробелами, и строку «CertUtil: -hashfile command completed successfully.». Для автоматического сравнения вывод придётся парсить, поэтому для ручной проверки PowerShell удобнее.

Поддерживаемые алгоритмы: MD2, MD4, MD5, SHA1, SHA256, SHA384, SHA512.

Сторонние утилиты с графическим интерфейсом

Если вы проверяете хеши регулярно или хотите визуально сравнить строки без копирования в блокнот, удобны небольшие портативные программы.

Утилита	Особенности	Алгоритмы
HashCheck Shell Extension	Интегрируется в свойства файла (вкладка «CRC SHA» / «Hashes»), открывается правым кликом. Открытый код, нет установки (регистрирует DLL).	CRC32, MD5, SHA-1, SHA-256, SHA-384, SHA-512
7-Zip	Правый клик → CRC SHA → SHA-256. Уже стоит у многих для архивов.	CRC32, CRC64, MD5, SHA-1, SHA-256, SHA-384, SHA-512, BLAKE2sp
HashTab	Вкладка в свойствах файла. Бесплатна для личного использования, закрытый код.	30+ алгоритмов, включая ed2k, Tiger, Whirlpool
OpenHashTab	Форк HashTab с открытым кодом, без рекламы и телеметрии.	Аналогично HashTab
RapidCRC Unicode	Портативное окно с drag-and-drop, пакетная проверка списка хешей из .sfv/.md5/.sha256.	CRC32, MD5, SHA-1, SHA-256, SHA-512, BLAKE2, и др.

Для разовой проверки достаточно 7-Zip или PowerShell. Для постоянной работы — HashCheck или OpenHashTab: они показывают хеш в двух кликах без открытия терминала.

Как сравнить полученный хеш с эталоном

Алгоритм прост, но есть нюансы:

1. Скопируйте эталонный хеш со страницы загрузки (Ctrl+C).
2. Получите хеш вашего файла любым способом выше.
3. Приведите оба к одному регистру (обычно нижнему) и уберите пробелы/переводы строк.
4. Сравните посимвольно. Даже один отличающийся символ — файл не тот.

Удобный трюк в PowerShell для мгновенного сравнения без глазомерки:

$expected = «a1b2c3d4e5f6…» # вставьте эталон в нижнем регистре
$actual = (Get-FileHash «C:\Path\to\installer.exe» -Algorithm SHA256).Hash.ToLower()
if ($expected -eq $actual) { Write-Host «OK: хеши совпадают» -ForegroundColor Green }
else { Write-Host «ОШИБКА: хеши НЕ совпадают» -ForegroundColor Red }

Если эталон опубликован в файле SHA256SUMS (формат: «хеш *имя_файла» или «хеш имя_файла»), можно автоматизировать проверку всего списка:

# Предполагаем, что файл SHA256SUMS лежит рядом с инсталляторами
$sums = Get-Content «C:\Downloads\SHA256SUMS»
foreach ($line in $sums) {
if ($line -match ‘^([a-f0-9]{64})\s+\*?(.+)$’) {
$expectedHash = $matches[1]
$fileName = $matches[2]
$filePath = «C:\Downloads\$fileName»
if (Test-Path $filePath) {
$actualHash = (Get-FileHash $filePath -Algorithm SHA256).Hash.ToLower()
$status = if ($expectedHash -eq $actualHash) { «OK» } else { «MISMATCH» }
Write-Host «$status $fileName»
} else {
Write-Host «MISSING $fileName»
}
}
}

Проверка цифровой подписи Authenticode — второй слой защиты

Контрольная сумма гарантирует целостность битов. Цифровая подпись гарантирует авторство: файл подписан сертификатом, выданным доверенным центром сертификации (CA), и не был изменён после подписания.

В Windows подпись проверяется автоматически при запуске (SmartScreen, UAC), но можно проверить вручную:

• Проводник: правый клик → Свойства → вкладка «Цифровые подписи». Если список пуст — файл не подписан.
• PowerShell: Get-AuthenticodeSignature «C:\Path\to\installer.exe». Поле Status должно быть Valid, SignerCertificate — содержать имя издателя.
• signtool (Windows SDK): signtool verify /pa /v «C:\Path\to\installer.exe» — подробный вывод с цепочкой сертификатов.

Важно: валидная подпись не отменяет проверку хеша. Подпись подтверждает, что файл подписан конкретным издателем в конкретный момент. Хеш подтверждает, что это именно тот файл, который имел в виду издатель (и который вы ожидаете получить). Используйте оба метода.

Типичные ошибки и как их избежать

• Сравнение хешей разного регистра или с пробелами. Всегда приводите к нижнему регистру и убирайте пробелы перед сравнением.
• Использование MD5/SHA-1 как единственной проверки. Для них известны коллизии. Подходит только если разработчик не предоставил SHA-256, и вы понимаете риск.
• Проверка хеша не того файла. Браузеры иногда скачивают в %TEMP% или добавляют суффикс (1), .part. Убедитесь, что проверяете именно итоговый .exe/.msi.
• Вера в подпись без проверки издателя. Подпись может быть валидной, но выдана на «John Doe» или компанию, не связанную с ПО. Читайте поле «Издатель» (Subject).
• Проверка после запуска. Если установщик уже запустился и распаковал себя во временную папку, исходный файл может быть удалён или изменён антивирусом. Проверяйте до первого запуска.
• Скачивание хеша с того же зеркала, что и файл. Если зеркало скомпрометировано, и файл, и файл с хешами могут быть подменены. Берите эталон с официального сайта проекта (HTTPS, основной домен).

Сценарии: как действовать в типичных ситуациях

5. Удалите файл. Скачайте снова, лучше с другого зеркала или напрямую с официального сайта. Если повторяется — сообщите разработчику (возможно, релиз пересобрали без обновления хешей на странице). Не запускайте файл с несовпадающим хешем.

Ситуация	Что делать
Официальный сайт даёт только SHA-1 / MD5	Проверяйте то, что есть. Заведите issue разработчику с просьбой добавить SHA-256. Не отказывайтесь от ПО только из-за этого, но будьте внимательнее к источнику загрузки.
Хеш не совпадает
Файл не подписан, но хеш совпадает	Многие open-source проекты не покупают EV-сертификаты для подписи Windows. Совпадение SHA-256 с официального источника — достаточная гарантия. Решайте по доверию к проекту.
Файл подписан, но хеш на сайте другой	Возможно, разработчик переподписал тот же бинарник (редко) или вы смотрите хеш для другой версии/архитектуры. Уточните версию. Не запускайте, пока не разберётесь.
Скачали через торрент / файлообменник	Обязательно проверяйте SHA-256 с официального сайта. Подпись Authenticode также должна быть валидной. Риск подмены здесь максимален.
Установщик — .msi или .msix	То же самое: Get-FileHash работает с любыми файлами. .msix/.appx имеют встроенную подпись и проверку целостности при установке, но предварительная проверка хеша не лишняя.

Автоматизация для системных администраторов

Если вы развёртываете ПО на десятки машин, ручная проверка нереальна. Правильный подход — верификация на этапе подготовки пакета:

1. Скачайте инсталлятор на управляющую станцию / сервер сборки.
2. Проверьте хеш скриптом (пример выше) и подпись Get-AuthenticodeSignature.
3. Положите в репозиторий пакетов (SCCM, Intune, Chocolatey, Winget, PDQ Deploy) только верифицированный файл.
4. В политике развёртывания укажите хеш пакета (Chocolatey: checksum/checksum64, Winget: InstallerSha256). Клиентская сторона проверит его при скачивании автоматически.

Так вы исключаете человеческий фактор и «человек посередине» на этапе доставки к конечному компьютеру.

Ограничения метода

Проверка контрольной суммы не защищает от:

• Уязвимостей в самом ПО. Легатимный, неподделанный установщик может содержать нулевую уязвимость (0-day) или закладку разработчика (редко, но бывает — supply chain attacks вроде SolarWinds, event-stream).
• Компрометации сервера разработчика. Если злоумышленник получил доступ к релизному аккаунту и заменил и файл, и хеш на сайте — вы скачаете «официальный» вредоносный файл с верным хешем. Защита — подпись PGP/GPG с ключом, хранящимся у разработчика офлайн (hardware token), и проверка этой подписи.
• Атак на цепочку поставок до этапа релиза. Вредоносный код может быть внедрён в исходники или сборочную инфраструктуру (CI/CD) до создания релиза. Хеш финального артефакта будет «правильным».

Поэтому хеш — необходимый, но не достаточный слой защиты. Комбинируйте: HTTPS-загрузка с официального домена → проверка SHA-256 → проверка Authenticode → (при наличии) проверка PGP-подписи файла хешей → запуск в изолированной среде / песочнице для критичного ПО.

Краткий чек-лист перед запуском любого установщика

1. Файл скачан с официального сайта (HTTPS, верный домен) или доверенного зеркала, указанного на официальном сайте.
2. На странице загрузки найден эталонный SHA-256 (или SHA-1/MD5, если другого нет).
3. Вычислен хеш файла: (Get-FileHash «путь\файл.exe» -Algorithm SHA256).Hash.ToLower().
4. Хеши совпадают посимвольно.
5. В свойствах файла (вкладка «Цифровые подписи») есть подпись, статус «Действительная», издатель соответствует разработчику.
6. (Опционально) Проверена PGP-подпись файла хешей / инсталлятора, если проект её предоставляет.

Если все пункты выполнены — риск запуска поддельного или повреждённого файла минимален. Если хотя бы один пункт не пройден — не запускайте, пока не разберётесь в причине.

Что делать дальше

Сделайте проверку SHA-256 привычкой для каждого нового исполняемого файла, который вы запускаете с правами администратора. Добавьте в контекстное меню HashCheck или OpenHashTab — это уберёт барьер «надо открывать терминал». Для корпоративной среды заложите верификацию в процесс подготовки пакетов развёртывания. И помните: хеш защищает только от подмены и повреждения битов. От уязвимостей в коде защищают своевременные обновления, принцип минимальных привилегий и сетевая сегментация.

Материал носит информационный характер. Проверка контрольных сумм и цифровых подписей снижает риски, но не гарантирует отсутствие уязвимостей в самом программном обеспечении или компрометации инфраструктуры разработчика. Для критических систем комбинируйте верификацию артефактов с изоляцией, мониторингом и политиками нулевого доверия.