Как то раз столкнулся с интересной проблемой при открытии исполняемого файла в WinDbg на отладку. Для опытного реверсера ситуация, скорее всего, достаточно тривиальная, тем не менее с ней из раза в раз сталкиваются те, кто впервые пытается отладить типовой исполняемый модуль (.exe) при помощи отладчика WinDbg. Заключается она в том, что совершенно непонятно как поставить точку останова на непосредственно в точку входа, то есть на первую инструкцию (основной функции) отлаживаемого исполняемого файла. Обычно для отладки приложение открывается через меню File - Open Executable... (или просто нажатием комбинации клавиш Ctrl+E). По умолчанию, после загрузки исполняемого файла, отладчик останавливается задолго до начала непосредственно кода самой программы, где-то глубоко в коде загрузчика образов Windows. Вот типичный пример:
Последовательность вызова функций
Многие специалисты, по роду своей деятельности сталкивающиеся с исследованием различных модулей, анализом причин тех или иных сбоев и проводящие иную аналогичную работу, в своей практике часто сталкиваются с таким понятием как стек вызовов. Очевидно, что он фактически представляет собой очередность вызова функций в контексте выполняющегося потока. С первого взгляда может показаться, что стек вызовов достаточно тривиален, тем не менее, в нем далеко не все так очевидно, как хотелось бы, и поэтому я решил набросать (прежде всего для себя самого) небольшую шпаргалку относительно некоторых важных деталей. Помимо последовательности вызова функций, так же неплохо было бы обсудить формат описания функций в стеке, да и некоторые другие нюансы. Тем, кому доводилось работать с различного рода задачами в отладчиках, к примеру, над изучением различного рода дампов памяти, или отладкой приложения, понимали, что одним из центральных аспектов является так называемый стек вызовов потока, который представляет собой список, состоящий из записей вида:
portcls!PcHandlePropertyWithTable+0x1b
Очевидно, что приведен всего-лишь общий вид записи, но нам интересна сегодня, в первую очередь, сама структура данной записи. В приведенном выше формате отладчик выводит данные о вызываемых в ходе выполнения кода функциях. Формат записи в стеке вызовов следующий:
Контекст устройства отображения
В многозадачной операционной системе семейства Windows отсутствует возможность прямого бесконтрольного вывода на экран (как это было во времена MSDOS), тут все подчинено некоему регламенту. С целью обеспечения возможности вывода на устройство (экран, принтер, память) одновременно от множества источников (приложений), в Windows был создан специализированный механизм под названием контекст устройства (device context, DC) и подмножество обеспечивающих его работу функций. Указанные функции определяют размер клиентской области, шрифт, цвета и другие GDI-атрибуты и возвращают (предоставляют) приложению так называемый дескриптор контекста устройства (Device Context Descriptor). Поскольку контекст устройства является одним из основополагающих понятий в понимании механизмов вывода информации на устройство, я постараюсь дать некоторое количество определений для погружения в тему:
Консольное приложение на ассемблере
После разработки серии оконных приложений, мы познакомились с основными принципами программирования графических примитивов. И тут дернула меня нечистая написать простую программку для решения специфической микрозадачи. Понятное дело, что использовать оконный интерфейс для подобного случая не очень то и хотелось, поэтому было решено сделать приложение консольным .. лучше бы я в этот огород вообще не лез! :) Ну уж, как говорится "взялся за гуж, не говори что не дюж".
Было бы бессмысленно отрицать, что в последние десятилетия роль графического интерфейса существенно возросла, тем не менее в новейших операционных системах текстовые режимы всё еще сохраняются в виде разнообразных графических подсистем, в частности - текстового пользовательского интерфейса (окна командной строки/терминала). Из этого следует, что если уж текстовый режим до сей поры присутствует в операционных системах, значит он не является исключительно аппаратным рудиментом, поддержка которого существует лишь на уровне видеоадаптера, а представляет собой актуальный и активно используемый механизм. Основная причина по которой текстовый режим всё еще существует, заключается в следующем:
STOP 0x00000033
Критическая ошибка STOP 00000033 имеет символическое имя UNEXPECTED_INITIALIZATION_CALL (НЕПРЕДУСМОТРЕННЫЙ_СИСТЕМНЫЙ_ВЫЗОВ). По задумке разработчиков, данный системный сбой должен сообщать нам о некоем "неожиданном" системном вызове, который по идее, не должен был быть осуществлен в той ситуации (контекст работы, глобальные флаги и переменные), в которой он произошел. Как всегда у Microsoft с классификацией ошибок черт ногу сломит, и порой довольно сложно понять причину только лишь по символическому имени :) Иначе говоря, если вы видите останов STOP 00000033, то возникла ситуация, в которой в контексте (процесса/потока) ядра, был выполнен вызов внутренней функции одного из этапов инициализации и в этот самый момент ядро находилось в фазе, в которой оно в данный момент не должно было находиться. В общем то, как вы сможете увидеть далее в статье, символическое имя не лишено смысла, поскольку в некоторым алгоритмическим нюансам сложно бывает придумать внятное описание.
ci.dll - библиотека проверки цифровых подписей
И последним этапом в цепочке проверки целостности кода стадии загрузки 32-битной операционной системы Windows 7 является библиотека ci.dll (именуемая разработчиками Модулем Целостности Кода, Code Integrity Module). Данный компонент впервые появился в операционной системе Windows 7 и в своем составе имеет функции, обеспечивающие проверку целостности бинарных образов на этапе отображения/загрузки в адресное пространство ядра. Таким образом, можно сделать вывод, что фактически проверке по задумке разработчиков, подлежат только ключевые образы, являющиеся для системы критичными в плане безопасности. Область действия функционала ci.dll ограничивается только локальной системой, то есть той, на которой непосредственно происходит выполнение кода функций, иначе говоря библиотека является ни чем иным как изолированным идентификатором безопасности локальной системы.
Теперь, собственно, сделаем небольшое отступление для того, что бы дать краткое описание необходимых для понимания происходящего механизмов. С определенного времени в Windows появились так называемые сертификаты подписи кода.
Отключение проверки целостности ядра ntoskrnl.exe
Никогда не интересовались каким именно образом ядро Windows проверяет собственный код на попытку внесения изменений? Ведь современные операционные системы должны иметь механизмы защиты и причин для этого достаточно, одни руткиты чего стоят. Например, в 32-разрядной системе (x86) Windows, начиная с версии Vista, вполне официально присутствуют опции включения/отключения проверки целостности компонентов, участвующих в процессе запуска операционной системы: это флаги загрузки ENABLE_INTEGRITY_CHECKS и TESTSIGNING. В этой же версии в ядре появилась новая функция, носящая название SepInitializeCodeIntegrity и фактически являющаяся контейнером (оберткой) для передачи управления функции CiInitialize (экспортируемой библиотекой ci.dll). В случае, когда проверка целостности включена в операционной системе, SepInitializeCodeIntegrity внутри себя выполняет вызов функции CiInitialize, при отключенной же проверке обращения к функциям данной библиотеки не происходит. Помимо своего собственного кода, ядро ntoskrnl.exe производит проверку некоторых других критичных для системы модулей: драйверов этапа загрузки (флаг BOOT_START), системных драйверов (флаг SYSTEM_START), и драйверов, подгружаемых уже в процессе функционирования операционной системы (флаги DEMAND_START, AUTO_START). Целостность кода загружаемых ядром исполняемых образов проверяется двумя ядерными функциями:
- Функция
SeValidateImageHeader(контейнер к функцииCiValidateImageHeaderиз ci.dll) -- вызывается на этапе отображения исполняемого образа в адресное пространство ядра. - Функция
SeValidateImageData(контейнер к функцииCiValidateImageDataиз ci.dll) -- вызывается на стадии загрузки модуля ядра.
Отключение проверки целостности bootmgr и winload
Зачастую возникают потребности изучения процесса загрузки операционной системы Windows на уровне исходного кода. Ну а тут уж без внесения изменений в код просто не обойтись.. и в этом самом месте нас ждет разочарование. Дело в том, что если вносить изменения в код модулей bootmgr, winload.exe и файлы драйверов, участвующих в процессе начальной загрузки, то процесс запуска операционной системы начинает "вылетать" с ошибками, "валиться" в синий экран и режим восстановления. Логично, ведь мы столкнулись с проверкой целостности bootmgr и winload, которая препятствует модификации исполняемых образов, задействованных в цепочке запуска. Подобный механизм впервые появился в линейке операционных систем Windows начиная с версии Vista и теперь приобрел перманентно-устойчивый вид. Для самописных драйверов разработчики оставили возможность загрузки в тестовом режиме (флаг TESTSIGNING), тем не менее остаются условия, при которых внесение изменений в код компонентов оканчивается отказом в запуске ОС. Исследователям архитектуры Windows этот факт существенно портит настроение, поэтому сегодня мы разберем несколько нестандартный метод отключения проверки целостности bootmgr и winload.
больше информации про отключение проверки целостности bootmgr и winload
IDA интерфейс не поддерживается
При использовании интерактивного дизассемблера IDA (6.х+ версий) на некоторых системах наблюдается интересная проблема: при типовой загрузке произвольного файла, для которого имеется отладочная информация, программа сперва выдает запрос на подгрузку файла символов (.pdb-файл) с сервера Microsoft или локального хранилища символов:
