Комментарии 22
Контрольная сумма в заголовке не является хэшом и элементарно подделывается, она ни от чего не защищает. Полагаться на нее крайне опасно!
Как-то всё-таки странно код написан. Возвращаемые значения часто не проверяются. Предполагаю, что это сделано только для целей иллюстрации, однако применение такого кода не очень хорошо.
Например, вызов GetModuleFileName(NULL, fileName, MAX_PATH); очень легко может заполнить fileName строкой, не закрытой нулевым символом. И последующий вызов CreateFile может улететь в крэш.
При помощи всех перечисленных способов, кроме последнего, можно проверить целостность не только исполняемого файла текущего процесса
Ох ну насмешили, так насмешили. Целостность работающего процесса собрались проверять. Если вас попатчили, то вы даже путь к своему бинарю можете не успеть найти, не то чтобы что-то проверить.
Давайте я просто перечисли самые простые способы обходов:
1) Затереть проверки
2) Затереть хэши-эталоны
3) Пересчитать хэши-эталоны на новые значения
4) Пропатчить в памяти
5) Пропатчить загружаемую библиотеку, а не сам файл
6) Пропатчить виндовые функции, которые вы дергаете для проверки
Тут я, скажем так, иссяк, потому что еще 5 способов это просто разные варианты четвертого.
А сколько веселья можно устроить с загруженным драйвером! :-)
А сколько веселья можно устроить с загруженным драйвером! :-)
Для загрузки которого необходимо будет перевести ОС в режим принятия тестовой подписи, т.к. драйверы должны иметь цифровую подпись, либо подписать свой драйвер "утекшим" сертификатом, либо загружать свой неподписанный драйвер через какую-либо уязвимость в ядре или другом легитимном драйвере.
Не самый простой путь.
Разве нельзя добавить свой сертификат в корневой доверенный?
Windows при загрузке драйверов доверяет только сертификатам Microsoft.
Либо сертификатом от доверенного удостоверяющего центра, если драйвер подписан до 30 июня (точную дату не помню) 2021.
Нам с коллегой удалось загрузить драйвер, подписанный самостоятельно сгенерированным сертификатом. Без включения тестового режима, отключения проверки подписей или отключения безопасной загрузки.
Пока неясно, это фича или мы случайно нашли какую-то огромных размеров дыру, которую никто не замечал годами. Подробностей, увы, не будет, коллега резко против того, чтобы их раскрывать.
А версия Windows какая была?
10 на виртуалке и 11 на боевой машине с Secure Boot, блокировкой вредоносных драйверов, HVCI (целостностью памяти), в общем, включена вся защита, какая только возможна.
Сейчас этот процесс генерации сертификатов и подписывания автоматизируем и дальше можно гонять уже на большем числе драйверов, особенно на тех, которые грузятся как можно раньше в процессе загрузки (типа драйвера контроллера накопителей).
Достаточно любого утёкшего просроченного сертификата + метки подписи, удостоверяющей, что файл подписан в прошлом, когда сертификат не был просрочен.
Большую часть таких сертификатов этим летом забанили, но пара-тройка ещё гуляют. Метку задним числом можно получить от специального сервера, а чтобы система ей доверяла - поместить корневой сертификат сервера в доверенные.
Целостность работающего процесса собрались проверять.
Целостность исполняемого файла
Давайте я просто перечисли самые простые способы обходов:
Безусловно, все эти проверки могут быть обойдены и абсолютной защиты не существует. Что, однако, не делает проверки бесполезными, особенно если использовать несколько подходов, делать проверки в разных местах и т.д.
Для подписания исполняемого файла сначала необходимо создать или приобрести сертификат.
Правильнее конечно приобрести, и кроме подписи необходимо проверять валидность сертификата, которым был подписан файл (функции CertGetCertificateChain и CertVerifyCertificateChainPolicy).
Использовать самоподписный сертификат, добавляя его в Trusted Root Certification Authorities, как в статье, стоит лишь для экспериментов.
Ну почему же, у меня вот специфическая задача, проверить перед загрузкой в память своего приложения, что мой плагин не пропатчен. Я пока вижу это так, генерирую пару пуб/приват ключи, хардкожу пуб ключ в бинарь своего приложения, подписываю приватным ключём свои сборки плагина. В приложении перед загрузкой плагина проверяю подпись с помощью захардкоженного пуб ключа. Зачем мне для этой задачи вся эта пки, какие доп гарантии это мне даст по сравнению с тем что я описал? Само приложение то будет подписано как надо, а вот плагин по простому. Приложение инсталится как положено, а вот плагин дестрибутится на флешках такова природа моего приложения.
Проверка целостности исполняемых файлов