книги хакеры / Защита_от_взлома_сокеты,_эксплойты,_shell_код_Фостер_Дж_

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

Технология повторного использования кода определяется тем, как он написан. Лучше всего, если нужный код замкнут и легко включается в ваш проект (как, скажем, класс на C++ или DLL-библиотека). Однако так бывает далеко не всегда, поэтому часто приходится погружать код в автономный модуль.

Тип такого модуля-контейнера зависит от характера проекта. Чаще всего в этом качестве выступает класс на языке C++ или динамически загружаемая библиотека. Но что если требования изменятся или новая программа разрабатывается на другом языке? Снова выполняется процедура интеграции или код переписывается.

В этой главе мы рассмотрим другой вид интеграции, который позволяет обращаться к некоторому коду из программы на другом языке и даже с другой машины. Это «модель компонентных объектов» или COM (Component Object Model). Вы узнаете, что такое COM, как реализовать COM-компонент с помощью библиотеки Active Template Library (ATL) и как интегрировать этот компонент в существующую программу, относящуюся к информационной безопасности.

Модель COM

Уверенное владение теорией, лежащей в основе модели COM, необходимо для разработки приложений, основанных на этой технологии. Но это не тема для вводного обзора. Есть немало других хороших книг по этому предмету, например, «Inside COM» Дейла Роджерсона (Microsoft Press, 1996)1. Мы же ставим себе целью дать рабочие знания о наиболее часто используемых сторонах технологии COM, с которыми вам придется столкнуться.

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

1 Имеется русский перевод – Дейл Роджерсон «Основы COM» (Microsoft Press, Русская редакция; 1997).

COM-объект похож на любой другой объект в том смысле, что обладает методами, свойствами и внутренним состоянием. Но, в отличие от других объектных технологий, доступ к методам и свойствам, осуществляется через интерфейсы. У COM-объекта может быть много интерфейсов, но все они являются производными от IUnknown (см. ниже). Чтобы получить указатель на интерфейс объекта, нужно его запросить. Если быть точным, интерфейс запрашивается у среды исполнения COM во время загрузки объекта.

COM3интерфейсы

Спецификация COM требует, чтобы любой объект поддерживал интерфейс IUnknown и следовал соглашениям о вызове.

Интерфейс IUnknown

Первыми тремя методами любого COM-интерфейса должны быть методы, унаследованные от IUnknown: QueryInterface, AddRef и Release. Метод QueryInterface позволяет спросить у объекта, поддерживает ли он некий интерфейс. Если да, то возвращается указатель на этот интерфейс, в противном случае – код ошибки.

Для управления временем жизни COM-объектов применяется подсчет ссылок, этой цели служат методы AddRef и Release. Как явствует из названий, AddRef увеличивает счетчик ссылок на единицу, а Release уменьшает его. Если некоторая функция возвращает указатель на интерфейс в своем выходном параметре, то счетчик ссылок на него необходимо увеличить. Когда работа с интерфейсом закончена, клиент должен вызвать Release.

Соглашение о вызове

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

int __stdcall MyFunction()

{

return 10;

}

Именно среда исполнения выполняет действия, необходимые для того, чтобы клиент мог обратиться к COM-объекту. Но предварительно ее следует инициализировать. Для инициализации вызывается функция CoInitialize или CoInitializeEx. Разница между ними в том, что CoInitializeEx позволяет указать потоковую модель. Проще говоря, среда исполнения COM гарантирует, что любой доступ клиента к объекту и наоборот не будет противоречить выбранной потоковой модели. Если заданы несовместимые условия, то среда исполнения постарается исправить ситуацию, загрузив модуль-заместитель. Это процесс прозрачен для клиента, и в однопоточных программах на него можно не обращать внимания. По завершении работы нужно вызвать функцию CoUninitialize без аргументов, чтобы освободить занятые средой исполнения ресурсы.

Когда среда исполнения загружена, клиент может запросить интерфейс у любого объекта, зарегистрированного в локальной или удаленной системе. В первом случае это делает функция CoCreateInstance, во втором – CoCreateInstanceEx. Прототип функции CoCreateInstance следующий:

STDAPI CoCreateInstance( REFCLSID rclsid,

LPUNKNOWN pUnkOuter, DWORD dwClsContext,

REFIID riid, LPVOID * ppv

);

Наибольший интерес представляют параметры rclsid, dwClsContext, riid è ppv. Параметр pUnkOuter применяется для агрегирования, мы о нем говорить не будем. Параметр rclsid определяет, какой объект должен быть загружен. Флаг dwClsContext говорит, куда следует загружать объект: в клиентский процесс или в отдельный.

Среда исполнения COM опознает COM-объекты по глобально уникальному идентификатору (GUID). В качестве синонимов аббревиатуры GUID употребляются также CLSID и IID. Выше было показано, что функция CoCreateInstance принимает аргумент типа REFCLSID, идентифицирующий объект. Кроме того, она принимает еще идентификатор IID того интерфейса, который нужно запросить у объекта после того, как он будет загружен. Откуда берутся эти величины, мы узнаем позже, когда будет говорить о регистрации COM-объектов.

Ниже приведен пример инициализации COM, создания COM-объекта и завершения.

//Инициализировать COM CoInitialize(0);

//Инициализировать экземпляр анализатора MSXML, для которого

//CLSID равен CLSID_DOMDocument

hr = CoCreateInstance( CLSID_DOMDocument, NULL, CLSCTX_INPROC_SERVER, IID_IXMLDOMDocument, (PVOID*)&pDoc);

if (SUCCEEDED(hr) && pDoc)

{

// Сделать что-то с указателем на интерфейс pDoc pDoc->Release();

}

// Завершить работу с COM CoUninitialize();

}

Реализация COM3объекта

Клиент обращается ко всем COM-объектам по единой схеме, не зависящей от реализации самого объекта. Но это вовсе не означает, что все объекты реализуются одинаково. Например, среда исполнения COM поддерживает внутрипроцессные (типа DLL) и внепроцессные (исполняемый файл) объекты.

Если выбрана внутрипроцессная модель, то среда исполнения ожидает, что содержащий COM-объект модуль (DLL) реализует определенную функциональность, в частности, экспортирует некоторые функции.

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

Всякий модуль должен реализовывать среди прочего процедуры регистрации и активации. На этапе регистрации объект информирует среду исполнения о способе своей загрузки: как внутрипроцессный или внепроцессный сервер.

Регистрация COM-объекта

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

Ключ реестра HKEY_CLASSES_ROOT\CLSID – это контейнер для всех зарегистрированных в системе компонентов, индексированный значением CLSID. Любой компонент обязан зарегистрировать свой CLSID под этим ключом.

Êëþ÷ HKEY_CLASSES_ROOT\CLSID\ {xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}

Наличие ключа CLSID внутри HKEY_CLASSES_ROOT\CLSID означает, что COM-объект зарегистрирован. Значением этого ключа по умолчанию является понятное человеку имя компонента, например, Msxml. Этот ключ должен иметь потомка, описывающего возможные способы создания, к примеру, InprocServer32 èëè LocalServer32. Как следует из названий, InprocServer32

означает, что объект загружается в адресное пространство клиента, а LocalServer32 – что он будет создан как отдельный процесс.

Êëþ÷ InprocServer32

У ключа InprocServer32 есть несколько элементов-потомков, которые сообщают среде исполнения COM, как следует загружать объект. Значением по умолчанию является физический путь к объекту в файловой системе.

Значение, связанное с именем ThreadingModel, говорит, какая потоковая модель поддерживается данным объектом. Возможны, в частности, следующие модели: Apartment (раздельная), Free (свободная) и Both (обоюдная).

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

Êëþ÷ LocalServer32

Êàê è InprocServer32, êëþ÷ LocalServer32 сообщает среде исполнения COM, как загружать объекты из конкретного сервера, но в данном случае, сервер представляет собой исполняемый файл.

Значением по умолчанию является путь к файлу, который запускается

âпроцессе загрузки объекта.

Èу этого ключа есть потомок ProgID, содержащий текстовое имя компонента.

Реализация внутрипроцессного сервера

Модули, реализующие модель внутрипроцессного сервера, обычно оформляются в виде DLL. Спецификация COM требует, чтобы любой внутрипро-