Delphi. Трюки и эффекты - страница 94

Возвращаясь к теме расположения ловушки зададимся вопросом: почему именно DLL? Чем плохо расположение ловушки в ЕХЕ-модуле приложения? Самое время вспомнить о том, что каждый процесс в Windows выполняется в своем собственном адресном пространстве. Поэтому адрес функции в исполняемом файле одного процесса вполне может быть адресом структуры данных где-то внутри другого процесса (рис. 10.1).

Рис. 10.1. Пример адресного пространства разных процессов

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

• спроецировать библиотеку с ловушкой в адресное пространство исследуемого процесса;

• однозначно определить положение (адрес) функции-ловушки в адресном пространстве исследуемого процесса.

Описанные выше манипуляции с DLL проиллюстрированы на рис. 10.2 (Процесс 2 на рисунке – процесс, в который внедряется ловушка).

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

Примечание

В каждой библиотеке реализуется функция DIIMain, вызываемая (упрощенно) при загрузке/выгрузке библиотеки. Жаль только, что при описанном способе подгрузки DLL эта функция не вызывается. Это приводит к усложнению кодаловушки, в чем вы сможете вскоре убедиться.

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

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

Составление списка открытых окон

Список (а точнее, дерево) окон, открытых в момент запуска программы, показан на рис. 10.3.

Рис. 10.3. Дерево открытых окон

Форма, показанная на рис. 10.3, имеет имя f rmMain. Элемент управления TreeView имеет имя tree. Часть программы, отвечающая за построение дерева, относительно проста. Она использует вскользь рассмотренный в гл.2 механизм перечисления окон. Составление дерева окон начинается с процедуры LoadWindowsTree, которая и запускает перечисление окон верхнего уровня, то есть окон, родителем которых формально является окно Рабочего стола (листинг 10.1).

Листинг 10.1. Начало составления дерева окон

procedure TfrmMain.LoadWindowsTree();

var

desktop: TTreeNode;

//enInfo: TEnumInfo;

begin

tree.Items.Clear;

//Добавление узла для Рабочего стола

desktop := tree.Items.Add(tree.Items.GetFirstNode, \'Рабочий

стол\');

//Перечисление окон

enInfo.tree := tree;

enInfo.parent := desktop;

EnumWindows(Addr(NewWindow), Integer(Addr(enInfo)));

end;

Сразу следует привести объявление структуры, интенсивно используемой (далее это будет видно) при составлении дерева:

Type

TEnumInfo = Record

tree: TTreeView; //Компонент TreeView

parent: TTreeNode; //Элемент дерева, соответствующий

//текущему окну, дочерние

//окна которого перечисляются

end;

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

Листинг 10.2.

Добавление в дерево информации об окне и поиск дочерних окон