А сколько веселья можно устроить с загруженным драйвером! :-)
Для загрузки которого необходимо будет перевести ОС в режим принятия тестовой подписи, т.к. драйверы должны иметь цифровую подпись, либо подписать свой драйвер "утекшим" сертификатом, либо загружать свой неподписанный драйвер через какую-либо уязвимость в ядре или другом легитимном драйвере.
Целостность работающего процесса собрались проверять.
Целостность исполняемого файла
Давайте я просто перечисли самые простые способы обходов:
Безусловно, все эти проверки могут быть обойдены и абсолютной защиты не существует. Что, однако, не делает проверки бесполезными, особенно если использовать несколько подходов, делать проверки в разных местах и т.д.
Например, при реализации отладчика - продолжение выполнения при достижении программной точки останова (int 3). Выполнив инструкцию int 3, попадаем в обработчик (остановились, делаем, что нужно, например, смотрим значения в регистрах). Для продолжения выполнения перезаписываем установленный breakpoint исходными данными (разумеется они должны быть ранее сохранены) и снова выполняем инструкцию, вызвавшую исключение. Теперь выполняется код уже без breakpoint'a и выполнение идет дальше, например, до следующей точки останова.
Не соглашусь. Например, поля структуры EXCEPTION_POINTERS будут иметь различные имена и смещения в x86 и x64.
а все зависит от настроек кодогенератора и в первую очередь от настроек оптимизации
Разумеется, создаваемый машинный код будет зависеть и от этого. В данной статье я привел пример с анализом машинного кода для конкретного описанного случая и соответствующей настройкой в обработчике исключения.
Или, точнее, это будет "решение", которое очень запросто "превратится в тыкву" в самый неожиданный момент.
Разумеется, при пересборке с другими параметрами компилятора, без анализа сгенерированного машинного кода данное решение работать не будет.
А версия Windows какая была?
На файлы, подписанные утекшими сертификатами иногда антивирь ругается
Ну да, с 2021 года только Microsoft
Насколько я помню, не любого.
Но от VeriSign будет принят.
Нашел такой линк:
Deprecation of Software Publisher Certificates
/https://learn.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates#is-there-a-way-to-run-production-driver-packages-without-exposing-it-to-microsoft
Либо сертификатом от доверенного удостоверяющего центра, если драйвер подписан до 30 июня (точную дату не помню) 2021.
Для загрузки которого необходимо будет перевести ОС в режим принятия тестовой подписи, т.к. драйверы должны иметь цифровую подпись, либо подписать свой драйвер "утекшим" сертификатом, либо загружать свой неподписанный драйвер через какую-либо уязвимость в ядре или другом легитимном драйвере.
Не самый простой путь.
Целостность исполняемого файла
Безусловно, все эти проверки могут быть обойдены и абсолютной защиты не существует. Что, однако, не делает проверки бесполезными, особенно если использовать несколько подходов, делать проверки в разных местах и т.д.
Например, при реализации отладчика - продолжение выполнения при достижении программной точки останова (int 3). Выполнив инструкцию int 3, попадаем в обработчик (остановились, делаем, что нужно, например, смотрим значения в регистрах). Для продолжения выполнения перезаписываем установленный breakpoint исходными данными (разумеется они должны быть ранее сохранены) и снова выполняем инструкцию, вызвавшую исключение. Теперь выполняется код уже без breakpoint'a и выполнение идет дальше, например, до следующей точки останова.
Не соглашусь. Например, поля структуры EXCEPTION_POINTERS будут иметь различные имена и смещения в x86 и x64.
Разумеется, создаваемый машинный код будет зависеть и от этого. В данной статье я привел пример с анализом машинного кода для конкретного описанного случая и соответствующей настройкой в обработчике исключения.
Разумеется, при пересборке с другими параметрами компилятора, без анализа сгенерированного машинного кода данное решение работать не будет.