Значение хэширования MD5 и SHA256 файла зависит от того, находится ли файл из папки system32. Зачем?

Question

Я вычислил значения хеша MD5 и SHA256 для notepad.exe и mspaint.exe через онлайн-генераторы хэшей md5FileCalculatorOnlinemd5. Что я заметил, так это то, что если я вычислил, когда оба exe присутствуют в их фактическом поведении в system32, то приходящее значение отличается от того, что помещено где-то из папки system32. В чем причина этого? Какое значение имеет правильное значение?

Я использую политику ограничения программного обеспечения для блокировки приложений, я создал правило хэша для файла notepad.exe (присутствует в папке SYSTE32) и заблокировал его. Когда я проверяю значение хэша в реестре, оно отличается от хэш-значения notepad.exe (из папки SYSTEM32), вычисленного с помощью других методов, таких как онлайн-калькуляторы md5 или через Windows API. Но когда я копирую файл notepad.exe в какую-либо другую папку, скажу на рабочем столе и вычисляя значение хэша, он поступает так же, как и в реестре, для которого я создал правило. Поэтому правильное значение - это то, что я получаю когда файл отсутствует в папке system32. Но я не понимаю, почему это происходит? Имеет ли он какое-то отношение к разрешениям?

Answer 1

Это из-за 32-разрядных приложений, работающих на 64-битной Windows, и того, как Windows обрабатывает папку System32 для этих программ.

Это также заставляло меня гать на некоторое время, потому что я не мог на всю жизнь понять, почему определенные файлы в System32 (а именно .dlls и .exes) возвращают разные хэши в зависимости от того, с чем я их проверил.

Используя HxD и Firefox, чтобы загрузить файл, чтобы проверить его хэш, у меня были разные результаты по сравнению с использованием хэш-проверки QTTabBar, которая работает внутри explorer.exe.

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

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

Но потом я подумал попробовать то же самое на другую папку, и, наконец, взломали, с небольшой помощью от Wikipedia:

Операционная система использует % SystemRoot% \ System32 для его 64-битная библиотека и исполняемые файлы. Это сделано для отстающих соображений совместимости, так как многие устаревшие приложения жестко запрограммированы на , используя этот путь. При выполнении 32-разрядных приложений WoW64 прозрачно перенаправляет 32-разрядные библиотеки DLL на % SystemRoot% \ SysWOW64, который содержит 32-разрядные библиотеки и исполняемые файлы.

32-разрядные приложения обычно не знают , что они работают в 64-разрядной операционной системе.32-разрядные приложения могут получить доступ к % SystemRoot% \ System32 через псевдо % SystemRoot% \ Sysnative.

Поскольку HxD и Firefox (и большинство других браузеров) все 32-разрядные приложения, при загрузке файла в них, Windows на самом деле прозрачно перенаправлять их в файл с тем же именем в папке SysWOW64 (предположительно если вы запустили 64-битный браузер, вы не столкнетесь с этой проблемой).

Аналогично, когда вы копируете файл из System32 в другое место, explorer.exe, будучи 64-битным процессом, копирует исходный файл System32, а не эквивалент SysWOW64 (смутно названный).

Так как вики государств, если ввести %SystemRoot%\Sysnative в путь открытого диалога файла в вашем 32-битное приложение, он должен загрузить файл из папки реального System32, и дать вам правильный результат.

И если вы проверяете файлы в каталоге SysWOW64, все файлы должны возвращать одинаковые хэши независимо от того, с кем вы их открываете.

Дальнейшее чтение:

• SysWOW64
• Sysnative

Answer 2

Вы уверены, что проверяете тот же самый файл на разных путях? Я думаю, вы проверяете два разных файла notepad.exe. Проверьте размер файла ... он должен быть то же самое по байтам. Я только что проверил мой notepad.exe на двух различных путей C: \ Windows \ System32 и C: \ Windows и они Diferent.