Техника отладки

Крис Касперски ака мыщъх

Спецвыпуск: Хакер, номер #057, стр. 057-020-5

Открываем MSDN, смотрим прототип функции GetWindowText. Ага: указатель на возвращаемую строку находится во втором аргументе слева, значит, на момент вызова GetWindowTextA он будет располагаться по адресу ESP + 8 (четыре байта на hWnd и еще четыре на адрес возврата).

Говорим "bpx GetWindowTextA", выходим из отладчика, вводим серийный номер в окно редактирования, нажимаем ОК - дебаггер всплывает (ну, будем считать, что всплывает, в действительности этого может и не произойти; все зависит от того, какую API-функцию использовал программист). Даем команду "d esp->8" (если окно дампа отключено, перед этим необходимо дать команду "wd"), а затем "p ret" - в окне появляется введенная нами строка.

Все, что нам нужно - это ее адрес, который в данном случае равен 2F46E0. Логично: чтобы сравнить пароль с оригиналом, защита должна считать его из памяти. В этот момент она себя и выдаст. Команда "bpm 2F46E0" установит точку останова на адрес 2F46E0, заставляя SoftIce всплывать при каждом чтении/записи этой ячейки памяти. Звучит прекрасно, но на практике срабатывает далеко не всегда. Вовсе не факт, что первое же всплытие отладчика выведет нас к защитному коду. Скорее всего, здесь будет библиотечная функция, копирующая пароль в локальный буфер, передаваемый по цепочке другим функциям. И хорошо если по ссылке! Часто буфер передается по значению, то есть копируется в другой буфер целиком. На каждый из таких буферов приходится ставить точку останова, а максимальное количество бряков на память равно четырем. И это не ограничение отладчика - просто у Пня такая архитектура.

Отсюда еще не следует, что точки останова на данные бесполезны - они сильны совсем в другой области. Вот, например, мы выяснили, что в переменной x содержится флаг регистрации. Каким образом выяснили, не суть важно. Допустим, встретили код типа: cmp [x],0/jz nag_screen (если переменная x равна нулю, вывести ругательный диалог). Как определить, где именно инициализируется этот x? В большинстве случаев перекрестные ссылки автоматически восстанавливаются ИДОЙ, однако разработчик защитного механизма может легко ослепить ее. Но едва ли он справится с командой "bpm x"!

А вот другой вариант: мы изменили пару байтиков в программе, а она, обнаружив факт своего взлома, отказалась работать. Чтобы найти процедуру проверки целостности кода, достаточно установить одну или несколько точек останова на модифицированные ячейки. Да много чего можно придумать, главное - фантазию иметь!

Раскрутка стека

Внешние проявления защитного механизма засечь очень легко. Как правило, это либо окошко с надписью "trial expired", либо форма для ввода серийного номера. Установить точку останова на WM_COMMAND легко, но какая польза от этого? Мы окажемся внутри оконной процедуры, в недрах которой зарыт защитный код. Можно, конечно, и потрассировать, но сколько времени уйдет на это! Вот бы узнать, какие команды исполнялись до этого! Обратить выполнение программы вспять и посмотреть, какой именно код определяет факт регистрации программы. Некоторые отладчики поддерживают механизм обратной трассировки (back trace), запоминая все выполняемые команды и складывая их в специальный буфер, однако это сильно замедляет выполнение программы и выводит антиотладочные приемы на оперативный простор. Мы поступим иначе. SoftIce поддерживает шикарную команду STACK, раскручивающую стек и выводящую адреса всех материнских функций. Не совсем равноценная замена обратной трассировки, но, как правило, ее вполне хватает.