Читать онлайн «Delphi. Трюки и эффекты». Страница 44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используемая в листинге 10.3 функция AddWindowToTree добавляет элемент, соответствующий найденному окну, в дерево (определяет текст заголовка окна и имя оконного класса):

Вот, собственно, и все, что требуется для построения полного дерева окон, показанного на рис. 10.3.

Получение информации об окне

Следующей функцией «оконного шпиона» является определение более-менее полной информации об окне, выбранном в дереве. Форма с информацией о выделенном в дереве окне (в данном случае это пресловутая кнопка Пуск) показана на рис. 10.4.

Рис. 10.4. Форма свойств окна

Начинается все с того, что по команде меню Правка → Свойства вызывается метод ShowWindowProp созданного при запуске программы объекта f rmWindowProp. Этот метод принимает в качестве параметра дескриптор окна, информацию о котором нужно отобразить (дескриптор сохраняется в поле Data каждого элемента при построении дерева) (листинг 10.4).

Переменная wnd, в которой сохраняется переданный BShowWindowProp дескриптор окна, является членом класса Tf rmWindowProp. Она нужна для того, чтобы другие методы формы Tf rmWindowProp могли получать доступ к дескриптору окна.

Определение заголовка, имени класса, идентификатора окна, а также области экрана, занимаемой окном, осуществляется в процедуре LoadWindowInf о (листинг 10.5).

Если вы внимательно просмотрели листинг 10.5, то могли заметить вызовы двух процедур в двух последних строках кода. Процедура LoadWindowStyle заполняет списки используемых и доступных оконных стилей (см. рис. 10.4), а процедура LoadWindowExStyle соответственно заполняет списки используемых и доступных дополнительных (или расширенных) стилей окна.

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

Вместо громоздкой проверки наличия в значении, возвращенном API-функцией GetWindowLong, битов каждого возможного стиля при помощи, например, case здесь используется глобальный массив styles структур Styleinf о. Объявление типа структуры (записи) Styleinf о выглядит следующим образом:

Каждый элемент массива styles хранит информацию об определенном оконном стиле. Объявление этого массива, так же, как структуры Stylelnfo и прочих рассмотренных в этом разделе типов данных, находится в модуле WindowData, расположенном на диске в папке с номером главы.