Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Учебное пособие 1977

.pdf
Скачиваний:
15
Добавлен:
30.04.2022
Размер:
3.44 Mб
Скачать

потоков «попадают под трассировку». Пусть, например, мы дали команду Step в одном потоке программы, и в этот момент другой поток остановился на точке останова. Мы имеем два потока, выполнение которых приостановлено отладчиком. Когда мы дадим команду Step в следующий раз, будет продолжено выполнение второго потока. Что же касается первого потока, здесь ситуация зависит от отладчика. В одних отладчиках его выполнение никогда не возобновляется, что приводит к сбоям в работе анализируемой программы, в других при запуске отлаживаемой программы возобновляется выполнение всех приостановленных отладчиком потоков. При этом следующая остановка программы может произойти в любом из потоков программы, «попавших под трассировку». С точки зрения аналитика это выглядит как хаотичное и, на первый взгляд, абсолютно бессмысленное изменение данных в окнах отладчика. Дальнейшая работа в таком режиме становится практически невозможной.

Следует отметить, что некоторые отладчики (например, WinDbg) позволяют устанавливать точку останова на конкретный поток программы. К сожалению, такие точки останова часто работают некорректно.

Для того чтобы решить описанную проблему, при анализе параллельного кода нужно придерживаться следующего правила: в начале трассировки все точки останова должны быть удалены из программы. Только так можно гарантировать, что трассировке будет подвергнут единственный поток программы. Большинство отладчиков допускают временное удаление точки останова (команда Disable). При этом точка останова удаляется из отлаживаемой программы, но информация о ней сохраняется в памяти отладчика, и эта точка останова может быть восстановлена всего двумя-тремя нажатиями клавиш.

71

1.5.5.Особенности анализа кода в режиме ядра Windows

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

1)требуется проанализировать программное или программноаппаратное средство, включающее в себя один или несколько драйверов физических или логических устройств;

2)требуется проследить нетривиальный путь передачи информации от процесса-клиента к процессу-серверу. Например, требуется выяснить, какой процесс обслуживает серверный конец LPC-порта, к которому подключился анализируемый процесс-клиент. Другой пример – требуется выяснить, какой процесс отправил заданное оконное сообщение в окно анализируемого процесса.

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

Ядром данного отладчика является драйвер, который перехватывает большинство функций ядра Windows и предоставляет пользователю практически полный контроль над операционной системой. Пользователь при этом использует те же самые клавиатуру и мышь, что и остальные программы отлаживаемой системы, это большое достоинство данного отладчика. На те периоды времени, когда управление передается в Syser, работа операционной системы приостанавливается, системный таймер также приостанавливается и, с точки зрения системы, эти периоды как бы «выпадают из ее восприятия».

Работая с Syser, следует иметь в виду следующее: всегда, когда это возможно, следует запускать Syser в

72

виртуальной машине. Это заметно ускоряет перезагрузки операционной системы, которые при анализе кода ядра и драйверов обычно требуются очень часто;

не следует без веских причин запускать драйвер отладчика в режимах Automatic, System и Boot. В этом случае любая ошибка при загрузке отладчика приведет к полной невозможности загрузки операционной системы и потребует восстановления с использованием «безопасного режима» и других подобных средств. Не исключено, что потребуется полная переустановка операционной системы;

применять Syser для анализа кода, выполняющегося в режиме пользователя, следует лишь в случае крайней необходимости (например, если нужно выяснить, какой процесс-клиент вызвал ту или иную функцию ядра). Точки останова, поставленные в пользовательскую часть того или иного адресного пространства, часто работают некорректно. Если необходимо одновременно анализировать и клиентскую программу, и ядро, обычно более удобно запустить в системе два отладчика: Syser для анализа ядра и обычный отладчик для анализа клиентской программы;

условные (conditional) точки останова в Syser часто работают не корректно. Если условие накладывается на содержимое регистра, вероятность корректного срабатывания точки останова заметно

выше, чем если условие накладывается на содержимое области оперативной памяти;

содержимое некоторых областей системного адресного пространства (например, области памяти, занимаемой программным модулем win32k.sys) зависит от того, в контексте какого процесса выполняется код ядра. Если отладчик явно некорректно показывает содержимое какого-то участка системного адресного пространства, следует явно переключить отладчик на адресное пространство нужного процесса;

показывая пользователю текущий стек вызовов функций, Syser иногда ошибается, не замечая некоторые кадры стека;

73

почти весь код ядра и драйверов является параллельным. Анализируя код, выполняющийся в режиме ядра, следует придерживаться рекомендаций, приведенных в предыдущем подразделе;

код ядра и драйверов не всегда выполняется в контексте процесса, инициировавшего обрабатываемый запрос. При обработке аппаратных прерываний, асинхронном вводе-выводе и в некоторых других подобных ситуациях выполнение кода в режиме ядра может происходить в контексте любого процесса, выполняющегося в системе в данный момент;

если необходимо проанализировать под отладчиком основную точку входа драйвера (DriverEntry), практически невозможно установить точку останова в нужный участок кода, используя лишь штатные средства отладчика. Это связано с тем, что анализируемый код начинает выполняться немедленно после загрузки в память, и «поймать» момент времени, когда интересующий аналитика код уже загружен, но еще не выполняется, практически невозможно. Данную проблему можно решить, вставив команду int 3 (байт СС) непосредственно в секцию кода файла анализируемого программного файла. Если в заголовке этого файла установлена ненулевая контрольная сумма, перед стартом драйвера контрольную сумму следует либо обнулить, либо (лучше) перезаписать с учетом изменений, внесенных в машинный код. Команда int 3, встретившаяся в машинном коде, воспринимается отладчиком Syser как точка останова, при ее выполнении управление передается в отладчик. В этот момент аналитик должен с помощью команды eb восстановить байт, поверх которого им был записан байт СС, далее можно выполнять анализ кода как обычно. Не следует без крайней необходимости применять этот прием к драйверам, загружаемым автоматически, – в этом случае малейшая ошибка при работе с отладчиком может привести к невозможности загрузки операционной системы. Если же имеется крайняя необходимость применить данный прием к автоматически загружаемому драйверу, следует предварительно убедиться,

74

что после перезагрузки операционной системы Syser загрузится раньше анализируемого драйвера. Также следует иметь в виду, что

этот прием применим лишь в отношении тех драйверов, для которых операционная система не проверяет цифровую подпись файла;

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

как правило, Syser не вполне корректно интерпретирует загруженную в него символьную информацию об анализируемых программных модулях. Работая с Syser, полезно держать перед собой открытое окно «умного» дизассемблера, например IDA.

Помимо Syser, для анализа кода, выполняющегося в режиме ядра, можно использовать отладчик WinDbg, входящий в состав программного пакета Debugging Tools for Windows. Достоинства и недостатки этих двух отладчиков примерно компенсируют друг друга, и выбор между Syser и WinDbg – дело личных предпочтений аналитика.

1.6. Вспомогательные инструменты анализа программ

Помимо специализированных программных средств (отладчиков и дизассемблеров) при анализе программ часто применяются вспомогательные инструменты. Большинство из этих вспомогательных инструментов представляют собой программы-мониторы, отслеживающие те или иные информационные потоки, протекающие в операционной системе. Как правило, программа-монитор позволяет быстро выделить среди всех информационных потоков потоки, инициированные анализируемой программой. Анализ этих информационных потоков позволяет быстро получить

75

некоторые сведения о работе анализируемой программы. Рассмотрим некоторые наиболее популярные утилитымониторы, а также некоторые другие популярные вспомогательные инструменты анализа программ подробнее.

Монитор активности процессов РгосМоп

Программа РгосМоп позволяет регистрировать:

обращения к любым логическим дискам, а также к именованным каналам (named pipes), почтовым ящикам (mailslots) и сетевым ресурсам, доступным по протоколу SMB (ресурсы с именами вида \\server\share);

обращения к ключам и значениям реестра;

порождение и завершение процессов и потоков, загрузку и выгрузку библиотек и драйверов;

интенсивность использования аппаратных ресурсов компьютера теми или иными процессами и потоками.

Поддерживается особый режим регистрации указанных событий в процессе загрузки операционной системы.

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

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

Внешний вид основного экрана программы показан на рис. 1.17.

76

Рис. 1.17. Примерный вид основного окна программы РгосМоп

При запуске РгосМоп в системе с работающим антивирусным монитором возможна ложная тревога антивирусного монитора.

Утилита управления процессами Process Explorer Утилита Process Explorer оказывает неоценимую

помощь в просмотре и управлении процессами. Утилита не требует установки, достаточно распаковать архив и запустить файл procexp.exe. Основное окно утилиты показано на рис. 1.18.

Рис. 1.18. Примерный вид основного окна программы

Process Explorer 77

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

NtQuerySystemlnformation из библиотеки ntdll.dll. Двойной щелчок по имени процесса открывает окно его свойств. В нижней части главного окна показана детальная информация о выделенном в верхней части процессе. Это может быть список библиотек, используемых процессом, или список открытых процессом объектов операционной системы: файлов, ключей реестра и т.д. К сожалению, в списке объектов, выдаваемом Process Explorer, отражаются не все объекты, открытые процессом, а лишь те объекты, в отношении которых нормально срабатывают функции ядра ObReferenceObjectBy Handle и ObQuery Name String.

Впрочем, если в ходе выполнения одной из этих функций произошла ошибка, получить имя объекта можно лишь весьма нетривиальными «хакерскими» приемами.

Остановить (suspend), а затем возобновить (resume).

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

полное имя ЕХЕ-файла, посредством которого порожден процесс;

командную строку, переданную процессу; текущую директорию процесса; имя пользователя, с полномочиями которого

выполняется процесс;

время запуска процесса;

78

сведения об использовании процессом аппаратных ресурсов компьютера (также можно получить общую сводку по всей операционной системе);

список потоков процесса, при этом для каждого потока можно получить очень подробную информацию, включающую в себя, в том числе, и стек вызовов функций внутри данного потока;

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

списки групп и привилегий в маркере доступа процесса, состояние каждой привилегии (включена или выключена);

переменные окружения;

текстовые строки, присутствующие в ЕХЕ-файле и адресном пространстве процесса;

свойства сервисов, выполняющихся в контексте процесса.

С помощью Process Explorer можно аварийно завершить любой процесс, выполняющийся в системе, а также любой поток любого процесса. Кроме того, можно управлять приоритетами процессов и порядком выбора процессоров для выполнения потоков любого процесса. Для каждого объекта, открытого процессом, можно просмотреть следующие его свойства:

имя; тип;

постоянный объект или временный; количество ссылок и хэндлов; дескриптор защиты.

Любой хэндл любого объекта, открытого любым процессом, с помощью Process Explorer можно принудительно закрыть.

Для каждого программного модуля, загруженного в

79

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

Полезными функциями программы Process Explorer являются функции Find Handle и Find DLL. Они позволяют быстро получить список процессов, открывших заданный объект или загрузивших в свое адресное пространство заданный программный модуль.

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

После этого в верхней части главного окна Process Explorer будет подсвечено имя искомого процесса (аналогичная функция поддерживается утилитой Spy++, входящей в состав пакета Microsoft Visual Studio).

Утилита Process Explorer часто используется не только как вспомогательный инструмент программ, но и как средство выявления и уничтожения компьютерных вирусов и других вредоносных программ, которые не обнаруживаются специализированным антивирусным программным обеспечением, имеющимся в распоряжении пользователя.

Подробнее применение Process Explorer в этой роли будет описано в подразделе. 2.9.

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

В качестве примера приведем отчет антивирусного монитора AVZ о результатах поиска стелс-вирусов в системе, в которой установлен программный комплекс Folder Lock, позволяющий создавать на дисках компьютера скрытые директории, невидимые для пользователя до тех пор, пока в

80