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

В описании свойства перед его именем должен находиться один из атрибутов propget èëè propput. Атрибут propget говорит, что функция может принимать только один выходной параметр. Этот факт описывается атрибутом, предшествующим объявлению аргументов: [out, retval]. Функция с атрибутом propput принимает только один входной параметр, что подчеркивается нали- чием перед объявлением его атрибута [in]. При описании интерфейсов поча- ще обращайтесь к документации в MSDN, чтобы выяснить, как выразить желаемое на языке IDL. Главное, помните, что описание интерфейса не должно допускать неоднозначного толкования.

Закончив описывать COM-интерфейсы на IDL, приступим к определению окружения, в котором они будут существовать, то есть библиотеки типов и кокласса (сокращенное название для «класса компонента»). На IDL это выглядит так:

[uuid("DEEC1A90-820C-4744-Be1D-9E3C357EDE81"), version(1.0)] library SpaceShipLib

{

importlib("stdole32.tlb");

[uuid("305441D4-9014-4D49-A54F-2DF536E5EC67")] coclass SpaceShip

{

interface IWarpEngine;

};

};

Как и во всех конструкциях IDL, в первой строке описываются атрибуты следующей ниже библиотеки. Это ее идентификатор LIBID и номер версии. Разделlibrary предписывает IDL построить библиотеку типов (TypeLib). В ней в двоичном виде хранится вся информация об используемых типах. Из этой библиотеки среда исполнения COM узнает о порядке использования компонента.

В теле раздела library находятся, в частности, описания коклассов. В данном случае есть всего один такой класс SpaceShip, а кроме того импортируется откомпилированная библиотека типов stdole32.tlb.

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

После создания IDL-файла его нужно откомпилировать с помощью MIDL. Программа MIDL распознает различные флаги в командной строке, но на

регистрации COM-объекта. ATL запускает встроенный механизм, который обновляет реестр в соответствии со сценарием. Рассмотрим пример:

HKCR {

NoRemove CLSID {

ForceRemove {9C129B36-EE42-4669-B217-4154821F9B4E} =

s 'MySimpleObject Class' {

InprocServer32 = s '%MODULE%' {

val ThreadingModel = s 'Apartment'

}

}

}

}

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

HKEY_CLASSES_ROOT (èëè HKCR);

HKEY_CURRENT_USER (èëè HKCU);

HKEY_LOCAL_MACHINE (èëè HKLM);

HKEY_USERS (èëè HKU);

HKEY_PERFORMANCE_DATA (èëè HKPD);

HKEY_DYN_DATA (èëè HKDD);

HKEY_CURRENT_CONFIG (èëè HKCC).

В нашем примере использован ключ HKCR (или HKEY_CLASSES_ROOT). Все, что следует за корневым ключом, называется реестровым выражением и состоит из команд добавления или удаления ключа. Все потомки корневого элемента в показанном выше сценарии – это выражения, инструктирующие ATL добавить в реестр ключи с указанными значениями. Рассмотрим каждую строку сценария:

NoRemove CLSID {

Здесь от ATL требуется при необходимости создать ключ CLSID, но никогда не удалять существующий.

ForceRemove {9C129B36-EE42-4669-B217-4154821F9B4E} =

s 'MySimpleObject Class' {

В этой строке дается задание создать ключ, содержащий значение GUID. Атрибут ForceRemove говорит, что ключ следует удалить при удалении COM-

ключа строковое значение по умолчанию (о чем свидетельствует буква ‘s’, предшествующая литералу) и записать в него строку «MySimpleObject Class». Важно отметить, что если ключ помечен атрибутом ForceRemove, то и все его потомки тоже будут удалены.

InprocServer32 = s '%MODULE%' {

val ThreadingModel = s 'Apartment'

}

Этот фрагмент аналогичен предыдущему; здесь тоже создается новый ключ, на этот раз с именем InprocServer32, для которого значением по умол- чанию является путь к файлу регистрируемого модуля. Вы, конечно, поняли, что строка %MODULE% интерпретируется как переменная окружения сценария или макрос, который подставляется во время запуска сценария препроцессором, входящим в состав ATL.

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

поместить сценарий в раздел ресурсов компонента;

объявить идентификатор соответствующего ресурса.

Для выполнения первого шага перейдите на вкладку Resource View в проекте, создаваемом в Visual Studio, щелкните правой кнопкой по ресурсному файлу и выберите из контекстного меню пункт Add Resource (ñì. ðèñ. 13.3).

Рис. 13.3. Диалоговое окно для добавления ресурса в Visual Studio.NET

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

Мастер, входящий в Visual C++, сгенерировал показанную выше экспортируемую функцию DllGetClassObject, заставив ее просто делегировать всю работу методу DllGetClassObject глобального объекта _AtlModule. Тот проанализирует запрос и, если запрошенный компонент будет найден, создаст и вернет фабрику класса для него.

ATL определяет, какие объекты может предоставить, на основании информации, полученной от самих объектов, которые объявили о себе и пожелали предоставлять свои услуги клиентам модуля. Такое объявление делается с помощью макроса OBJECT_ENTRY_AUTO, который обычно располагается после объявления соответствующего класса. Этот макрос вставляет CLSID и имя класса в карту объектов модуля, поддерживаемую ATL. Зная это, ATL может правильно выполнить регистрацию и создание фабрики класса.

STDAPI DllRegisterServer(void)

{

HRESULT hê = _AtlModule.DllRegisterServer() return hr;

}

Здесь представлено определение экспортируемой функции DllRegisterServer. Как видно, она делегирует всю работу методу DllRegisterServer глобального объекта _AtlModule.

STDAPI DllUnregisterServer(void)

{

HRESULT hê = _AtlModule.DllUnregisterServer() return hr;

}

И здесь то же самое – экспортируемая функция делегирует запрос методу _AtlModule.

STDAPI DllCanUnloadNow(void)

{

Точка входа в модуль

Все динамически загружаемые библиотеки в Windows должны экспортировать точку входа DllMain. Если вас устраивает стандартная реализация, то можете просто обратиться к методу DllMain класса CAtlDllModuleT. Впрочем, это необязательно. Предлагаемая ATL реализация делает несколько простых проверок и возвращает TRUE.

Реализация внепроцессного COM-сервера

Зная, как реализуется COM-сервер в виде DLL, вы, наверное, сочтете, что написание сервера в виде EXE-файла аналогично и в чем-то даже проще. ATL предоставляет обширную поддержку практически для всех аспектов реализации EXE-сервера.

Глобальная переменная _AtlModule

В случае EXE-сервера переменная _AtlModule представляет собой объект класса производного от шаблонного класса CAtlExeModuleT. Вы можете сконфигурировать этот класс с помощью макросов ATL. Вот пример объявления и определения переменной _AtlModule.

class CSpaceShipModule :

public CAtlExeModuleT< CSpaceShipModule >

{

public: DECLARE_LIBID(LIBID_SpaceShipLib)

DECLARE_REGISTRY_APPID_RESOURCEID(IDR_SPACESHIP, "{48DF7A09-18CF-4C05-969C-2AAA42363B4AD}")

}

CSpaceShipModule _AtlModule;

Здесь объявлен класс CSpaceShipModule, наследующий классу CAtlExeModuleT, и и с помощью макросов для него задана некоторая статическая информация.

Точка входа в модуль

Существенная часть работы EXE-сервера выполняется в его точке входа. Чтобы предоставить доступ к своим объектам клиентам, находящимся в другом процессе, сервер должен выполнить ряд действий: