Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #144, ЯНВАРЬ 2011 г.

Под присмотром Monitor API: Как отслеживать вызовы API-функций и зачем это нужно?

Отладчик и дизассемблер — это, безусловно, лучшие инструменты, чтобы посмотреть, как устроена какая-то программа изнутри. Но есть еще один инструмент, который быстро может дать картину того, что происходит внутри приложения и как оно взаимодействует с операционной системой. Это монитор API-вызовов.

Работа многих приложений и самой Windows во многом построена на системе DLL, т.е. динамически загружаемых библиотек. Приложениями предоставляются сервисные API-функции, с помощью которых они могут взаимодействовать с системой. Условно говоря, есть функции для чтения и записи в реестр, работы с файловой системой, сетевого взаимодействия и т.д. Фиксируя вызовы API-функций, мы можем узнать многое о работе приложения. А перехват таких вызов (и спуфинг результата их выполнения) позволяет обойти многие ограничения системы и делать с ней практически что угодно.

Существует немало программ, которые мониторят обращения к API-функциям. Взять хотя бы небезызвестные утилиты RegMon и FileMon Марка Руссиновича. Отслеживая вызовы API-функций, касающихся взаимодействия с реестром и файловой системой, они выводят информацию в удобном для анализа виде. Фактически, идея написать материал о давно существовавших API-шпионах появилась под впечатлением от нового релиза программы API Monitor. Она делает то же самое, что и масса других подобных программ — фиксирует обращения к API-функциям и COM-методам. Но то, как она реализована, заслуживает всяческих похвал.

Чем удивил API Monitor?

Сам проект довольно старый: его предыдущая 1.5 версия выходила еще в далеком 2001 году. Прошлым летом разработчики реанимировали проект и полностью переписали код. Теперь это офигенный инструмент! Кратко пройдемся по его возможностям.

  • В первую очередь стоит отметить совершенно чумовой интерфейс, который отличается наглядностью и удобством. Чего стоит только подсветка синтаксиса в вызываемых функциях. В специальном поле "Summary", где отображается активность приложения, выводится информация о каждом вызове API: идентификатор нити, название DLL, сделавшей вызов, а также подсвеченный синтаксис API-вызова со всеми параметрами и возвращенным значением. Причем, если вызов не удался, информация об этом будет также наглядно отображена.
  • В программе по умолчанию включено описание 10000 API функций из 166 DLL'ек, а также 700 методов из более чем 600 COM-интерфейсов (включая Shell, Browser, DirectShow, DirectSound, DirectX и т.д.). Для большего удобства все API организованы в категории и подкатегории в соответствии со структурой в библиотеке MSDN. Специальное поле интерфейса "API Capture Filter" позволяет удобно выбрать те API-шки, которые необходимо мониторить. Помимо этого, API Monitor декодирует GUID’ы, IID’ы и REFIID’ы и приводит их в понятный читаемый формат. Двойной клик по функции в любом месте программы откроет браузер с ее описанием на сайте MSDN.
  • API Monitor может декодировать параметры функций и возвращаемые значения, чтобы представить их в понятном формате. Это опять же заслуга внутренней базы. Функция CreateFileW имеет параметр dwSareMode. Например, при создании файла блокнотом оно имеет значение "1", не сильно понятно, правда? Если включить декодирование (кликаем на название столбцов в поле "Parameters" и выбираем "Decode Parametres Values"), то API Monitor покажет уже понятное значение "FILE_SHARE_READ | FILE_SHARE_WRITE".
  • С помощью API монитора ты можешь посмотреть как входящий, так и исходящий буферы. Причем количество данных, которое необходимо отображать пользователю, автоматически высчитывается, используя аргументы, переданные API-функции, или возвращаемое значение. К примеру, у функции для чтения файла ReadFile есть буфер lpBuffer — его размер автоматически определяется API Monitor'ом благодаря параметру lpNumberOfBytesRead (количество прочитанных байтов) после вызова функции. Поэтому, если посмотреть на содержание буфера (оно отображается в специальном поле — Hex Buffer), то в нем мы увидим данные именно в том количестве, в котором были прочитаны приложением. В настройках, кстати, можно задать максимальное количество байт, которые программа будет перехватывать.
  • В поле Summary не просто отображаются вызванные функции, но и строится дерево вызовов, показывающее иерархию API вызовов. Если одна из функций вызвала другую, это будет наглядно отображено в дереве. Еще одно важное поле программы – это “Call Stack”, в котором ты можешь посмотреть стек вызовов.
  • Если вызов API-функции не удастся, API Monitor вызывает соответствующие функции, чтобы получить дополнительную информацию об ошибке. Для этого поддерживаются функции GetLastError, CommDlgExtendedError, WSAGetLastError. В дополнение программа преобразует значения NTSTATUS и HRESULT в читаемый формат. Например, если Notepad не смог выполнить функцию CreateFile, то API Monitor выдаст и ошибку, и расшифровку. Например, такую "5 — отказано в доступе".
  • В новой версии API Monitor реализована полноценная поддержка 64-битных приложений. Фактически, на сайте разработчика доступны две отдельные версии: для 32- и 64-бит. Сразу хочу оговориться, что 32-битная версия может быть использована только для мониторинга за 32-битными приложениями. Даже если ты собираешься отслеживать вызовы 32-битного приложения под 64-битной редакцией Windows, тебе все равно нужна 32-битный API Monitor.

Устанавливаем простой hook

Впрочем, лучше всего ощутить все прелести API Monitor на практике. В общем случае необходимо указать монитору две вещи: функции для отслеживания и программы/сервисы, которые предположительно будут их вызывать. Для примера возьмем простую ситуацию, когда необходимо отследить факт создания файла в системе. За это в общем случае отвечают API-функции CreateFileA, CreateFileW и NtCreateFile, вот их вызовы мы и будем мониторить.

Их надо отметить в панели API Capture Filter. Как я уже сказал, список возможных функций для мониторинга очень внушительный, и даже несмотря на их удачную группировку найти нужные элементы, не зная, где они находятся, довольно сложно. Поэтому не стесняемся воспользоваться поиском (Ctrl-F или меню "Edit -> Find"), отыскав все необходимое по ключевому слову CreateFile. С этого момента API Monitor будет нам сообщать о вызове этих функций. Осталось выбрать программу. Это может быть уже существующий процесс, и в этом случае его достаточно выбрать в панели Running Processes, или же мы можем запустить приложение прямо из API Monitor'а. Выбирем второй вариант. Переходим "File -> Hook Process", выбираем в папке Windows notepad.exe (для простоты примера возьмем обычный блокнот).

В качестве аргументов, которые передаются приложению, предлагаю указать какой-нибудь текстовый файл. Тогда программа сразу же попытается создать документ — а именно это нам и надо. Нажимаем "ОК". Запустившийся блокнот справедливо замечает, что указанный текстовый файл он не нашел, и предлагает создать его. Соглашаемся и смотрим в вывод API Monitor. На панели Summary ты должен увидеть список вызовов, которые были сделаны Notepad'ом. Сначала приложение вызвало функцию CreateFileW из библиотеки kernel32.dll, которая в свою очередь вызвала NtCreateFile. Обрати внимание: текстовые параметры для наглядности выделены красным цветом.

Помимо этого, в выводе отражаются возвращаемое значение и коды ошибок. Функция NtCreateFile не нашла файл и поэтому вернула "STATUS_OBJECT_NOT_FOUND", а потому kernel32.dll вернула в Nodepad INVALID_HANDLE_VALUE и ошибку "2 = Не удается найти указанный файл". Если приложение попытается создать файл прямо в папке винды, то получит ошибку из-за отказа в доступе, и это также будет отражено в выводе API Monitor. В конце концов, NtCreateFile вернет статус "STATUS_SUCCESS" — файл создан. Вот где ощущается прелесть от декодированных ошибок.

Снифаем SSL-трафик браузера

Теперь, когда мы разобрались с общим механизмом работы API Monitor, хочу показать тебе всю мощь того, что предоставляет возможность отслеживать и перехватывать API-вызовы. Для того чтобы пример был более практичным, возьмем ситуацию из реальной жизни, когда мне необходимо было отснифать SSL-трафик, передаваемый браузерами. API Monitor в этом случае позволяет нам просмотреть данные, которые будут отправлены на защищенный сайт до того, как их закриптует браузер. Этот способ, кстати, вполне можно использовать, чтобы восстановить пароли, которые когда-то были сохранены в браузере и забыты. Для начала схема для Internet Explorer:

  1. Открываем для примера любой сайт, который поддерживает авторизацию с использованием SSL. Пусть это будет Gmail.
  2. Среди вызываемых функций нас особенно интересует категория Windows Internet. Выберем весь раздел, в этом случае API Monitor будет отслеживать вызовы всех функций из этого раздела.
  3. В списке "Running Processes" находим процесс Internet Explorer и через контекстное меню включаем его мониторинг (Hook).
  4. Теперь возвращаемся в браузер, в случае необходимости вводим авторизационные данные и нажимаем на кнопку для авторизации. В этот момент имя пользователя и пароль будут отправлены на серверы Google через защищенное SSL-соединение. Но прежде они засветятся в вызовах API-функций в чистом виде.
  5. Среди вызовов, которые отследил API Monitor, будет вызов API-функции HttpSendRequestW. Посмотри на поле, где разбираются параметры функции: для каждого выводится его номер, тип, название, значение до и после вызова. Нас интересует параметр lpOptional и его значение после вызова (Post-Call Value). Кликнув на соответствующее значение в таблице в поле Hex Buffer, мы сможем увидеть данные, которые Internet Explorer засабмитил на сайт. Слева данные в шестнадцатеричном виде, справа — в ASCII. Среди прочего несложно находится запрос с перечнем полей и их значений, в том числе имя пользователя и пароль.

Если взять браузер Firefox, то он не использует стандартные функции Windows Internet — вместо этого применяются рантайм Netscape Portable Runtime и библиотеки Mozilla SSL. Впрочем, API Monitor отлично справляется и с ними. Нас, чтобы добавить конкретики, интересует PR_Write. Далее ставим хук на процесс Firefox'а, выполняем процедуру авторизации, и смотрим информацию о перехваченных вызовах. В окне Summary ты увидишь множество вызовов PR_Write, выполненных библиотекой xul.dll. Это нам и нужно. Один из этих вызовов выполняет POST-запрос с интересующими нас данными, которые передаются в параметре buf. Нас интересует тот, который начинается с "POST /accounts/ServiceLoginAuth" (смотри поле "Hex Buffer"). Просто просматривай для каждого вызова Pre-Call Value буфера, и в одном из них ты увидишь интересующие данные. Есть нюанс. Возможно, API Monitor не перехватывает достаточно данных. Чтобы это исправить, перейди "Tools -> Options" и увеличь значение параметра "Maximum size of captured buffers". Теперь все точно должно работать.

Только монитор

Помимо непосредственно API-шпионов, есть утилиты, которые позволяют не только отслеживать вызов API-функций, но, к примеру, влиять на их выполнение. Но если необходим удобный качественный шпион, которым действительно удобно пользоваться, то новый API Monitor — это то, что доктор прописал. К тому же программа поддерживает подключаемые описания вообще для любой DLL-библиотеки, оформленные в специальном XML-формате, что делает ее еще и более универсальной.

Программы для мониторинга API-вызовов

WinApiOverride

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

kerberos

Шпион для отлова вызовов WinAPI функций. Утилита перехватывает не только API, но и пользовательские функции, поддерживает плагины. Лог работы шпиона в виде текстового файла *.rep сохраняется в папке с исследуемым приложением.

APISpy32

APISpy32 — шпион за вызовами WinAPI. Программа может следить за всеми процессами одновременно в системе, имея для этого специальный навороченный движок.

DVD

Все программы из этой статьи ты найдешь на нашем DVD-приложении.

Содержание