Особенности анализа графических программ Windows

Консольные программы имеют всего одну точку входа. С момента запуска программы и до момента ее завершения управление никогда не передается другим программам (за исключением системных вызовов и параллельных потоков). Программа возвращает управление операционной системе только после завершения. Графическая программа Windows возвращает управление в Windows сразу же по окончании инициализации и создания главного окна. В дальнейшем программа получает управление лишь тогда, когда в одно из ее окон приходит сообщение. При этом управление передается в ту точку входа программы, которая связана с данным окном, — в оконную или диалоговую функцию. С помощью классической схемы метода Step-Trace, описанной выше, можно трассировать только главную точку входа в программу (функцию WinMain) и функции, непосредственно вызываемые из нее. Для того чтобы применить этот метод к оконным и диалоговым функциям, а также функциям программы, вызываемым из оконных или диалоговых функций, метод Step-Trace необходимо модифицировать. При использовании модифицированного метода Step-Trace для анализа оконных функций и функций, вызываемых из них, следует вначале выбрать точку входа в программу, из которой имеется прямая передача управления в интересующую нас функцию х. Другими словами,

нужно получить адрес оконной функции окна, в котором пользователь дает команду выполнить действие, ведущее к вызову функции х. Проще всего сделать это, воспользовавшись утилитой Spy++, поставляемой в составе пакета Microsoft Visual Studio. Данная утилита позволяют, указав мышью окно, получить практически полную информацию об этом окне, в том числе и адрес его оконной функции. Использование утилиты Spy++ иллюстрирует рис. 7. В данном случае утилита Spy++ применена для получения адреса оконной функции главного окна калькулятора Windows. Этот адрес

указан в строке Window Ргос и равен 01006118. После того как адрес оконной функции получен, нужно поставить в нее точку останова. Не следует ставить точку останова в самое начало функции — в этом случае программа будет останавливаться на

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

Обычно оконная функция начинает свою работу с анализа идентификатора

пришедшего сообщения (это второй параметр оконной

Рисунок. 7 Окно свойств окна, выдаваемое утилитой Spy++

функции, он располагается в стеке по адресу [ebp + 0Сh]). В подавляющем большинстве случаев аналитика интересует лишь реакция оконной функции на сообщение WM_COMMAND (111h), приходящего в окно, когда пользователь выбирает пункт меню, нажимает специальную комбинацию клавиш, например [Ctrl-Ins], или выполняет

какое-то действие с одним из контрольных элементов окна (например, нажимает кнопку ОК). Для того чтобы точка останова срабатывала только при приходе сообщения WM_COMMAND, нужно просмотреть код оконной функции, найти там команды типа

mov еах, [ebp + ОС]

cmp еах,lllh

jne. . .

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

После того как в нужную оконную функцию установлена точка

останова, можно начинать трассировку программы. В качестве исходной точки для трассировки берется эта точка останова. В остальном применение метода Step-Trace в этом случае ничем не отличается от его применения в консольных приложениях.

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

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

Один из возможных подходов заключается в следующем. Вначале устанавливается точка останова на системную функцию Windows, с помощью которой создается интересующее нас диалоговое окно. Всего в Windows имеется около десяти системных функций (точное

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

Предположим, что интересующее нас диалоговое окно создано с помощью функции DialogBoxParamW. Мы запускаем анализируемую программу под отладчиком, устанавливаем точку останова на функцию DialogBoxParamW и даем программе команду на создание диалогового окна. Программа останавливается на только что установленной точке останова. Четвертым параметром функции DialogBoxParamW является указатель на диалоговую функцию создаваемого окна, этот адрес размещается в стеке по адресу [ebp + 14h]. После того как адрес диалоговой функции окна стал известен, нам остается лишь поставить точку останова в диалоговую функцию и дальше действовать так же, как в случае, когда функция х относится ко второму классу.

Особым случаем является анализ диалоговых функций программ, написанных в среде MFC. Для этих программ не только оконная функция диалогового окна, но и диалоговая функция являются стандартными системными функциями, не имеющими никакого отношения к анализируемой программе. Как правило, программа получает данные, введенные пользователем в диалоговое окно, непосредственно из полей объекта C + + , соответствующего диалоговому окну (этот объект принадлежит дочернему классу класса CDialog). Если диалоговое окно является модальным, оно вначале создается как немодальное, а затем для окна вызывается функция CDialog :: DoModal, преобразующая его в модальное диалоговое окно.

Для анализа того, какие данные поступают из диалогового окна в программу, необходимо найти в программе вызовы соответствующих методов класса CDialog, а затем внимательно изучить код, следующий за интересующими аналитика вызовами. Следует иметь в виду, что хотя по возвращении управления из функции CDialog :: DoModal

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