Бесспорно, среди существующих на сегодняшний день дизассемблеров лучшим является IDA. Особенно идеально он подходит для взлома и изучения защищенных программ. Очевидно, что BreakOO не является таковой в полном смысле этого слова. В нем нет ни шифрованного кода, ни "ловушек" для дизассемблеров. SOURCER или любой другой справился бы с этой задачей не хуже. Поэтому окончательный выбор я оставляю за читателем.
После того как дизассемблер завершит свою работу и выдаст километровый листинг, неопытный читатель может испугаться: как войти в эти дебри непонятного и запутанного кода? Сотни вызовов функций, множество условных переходов... Как во всем этом разобраться? И сколько времени потребуется на анализ? К счастью, нет никакой нужды разбираться во всем диз.ассемблированном листинге.
Достаточно изучить и понять алгоритм защитного механизма, ответственного за сверку паролей. Нужно только найти этот механизм. Можно ли это сделать как-то иначе, чем полным анализом всей программы? Разумеется, можно! Для этого нужно найти ссылки на строки "неверный пароль", "пароль ОК". "введите пароль". Ожидается, что защитный механизм будет где-то поблизости. Сами строки находятся в сегменте данных. (В старых программах под DOS это правило часто не соблюдалось. В частности, компилятор Turbo Pascal любил располагать константы непосредственно в кодовом сегменте.)
Для перехода в сегмент данных в IDA надо в меню "View" выбрать "Segment Windows" и среди перечисленных в появившемся окне отыскать сегмент типа "DATA". Искомые строки бросаются в глаза даже при беглом просмотре. Перевести их в удобочитаемый вид можно перемещением курсора на начало строки и нажатием "А" (от слова ASCII).
Популярные руководства по взлому рекомендуют теперь найти по перекрестным ссылкам код, который эти строки выводит. Но, увы, нас постигает глубокое разочарование. Ни одной ссылки на код нет. На самом деле, просто IDA не сумел их самостоятельно найти. Нет никакой возможности автоматически отличить константы от смещений, ни один дизассемблер не может делать это безупречно. SOURCER, возможно, показал бы куда больше интересного, но на этом его достоинства и кончаются. Кроме воистину магической способности определять перекрестные ссылки, поклонники SOURCER не могут привести ни одного аргумента в его пользу.
Но IDA позволяет найти перекрестные ссылки и самостоятельно. Для этого нужно нажать Alt-T и ввести адрес интересующей нас строки. Попробуем найти код, который выводит 'Enter password'. Нажимаем Alt-T и вводим '403048' (без кавычек) — адрес, по которому расположена эта строка. Теперь IDA обычным контекстным поиском будет искать все идентичные вхождения по всему дизассемблированному тексту.
Мы должны быть готовы к тому, что получим множество "ложных" срабатываний (просто констант, или смещений, но в другом сегменте), а то и ничего не получим. Возможно, адрес строки задается не через константу, а хитрыми математическими вычислениями и манипуляциями. Это действительно не самый лучший метод, но неоправданно популярный и рекомендуемый многими руководствами.
Не то чтобы я был против такого подхода, но боюсь, что новичков он может только запутать. Существуют гораздо более красивые и быстрые методы, которые будут рассмотрены ниже. Но идеология их схожа — они всегда пытаются "поймать" защитный код на основе известных или предсказуемых данных.
Если у нас есть строка, которая выводится, значит есть тот, кто ее выводит. Естественно предполагать, что он находится где-то в окрестностях сравнивающего механизма или непосредственно к нему относится.
Цель автора защиты — построить код так, чтобы не оставить хакеру никакой избыточной информации о работе последнего, по которой его можно вычислить. Данный пример ничего подобного не содержит, и IDA нам показывает следующий фрагмент:
004010С0 mov еsi, ds;??6std@@YAAAV?$basic_ostream@...
……………………………………………………………
004010E7 mov eax, ds: ?cout@std@@3V?$basic_ostream@
004010ЕС push 403048h
004010F1 push eax
004010F2 call esi
Но чем является в данном случае 403048h — смещением или константой? Это можно узнать из прототипа функции basic_ostream<E, Т> *tie(basic_ostre-am<E,T> *str). Пусть читателя не смущает небольшая разница в написании имен: причина в двух словах объяснена быть не может, и мне остается лишь отослать интересующихся этим вопросом к MSDN, который не только по-прежнему доступен в Он-Лайне, но и распространяется вместе с MS VC. Без MSDN и глубоких знаний Win32 говорить о хаке под Windows просто неэтично! Это, конечно, не означает, что каждый кракер обладает глубокими знаниями платформы, на которой он ломает. Большинство защит вскрываются стандартными приемами, которые вовсе не требуют понимания "как это работает".
Мой тезка (широко известный среди спектрумистов уже едва ли не десяток лет) однажды сказал "Умение снимать защиту, еще не означает умения ее ставить". Это типично для кракера, которому, судя по всему, ничто не мешает ломать и крушить. Хакер же не ставит целью взлом (т.е. способ любой ценой заставить программу работать), а интересуется именномеханизмом: "как оно работает". Взлом для него вторичен.
Однако мы отвлеклись. Вернемся к прототипу функции basic_ostrearn. Компилятор языка Си заносит в стек все аргументы справа налево. Поэтому 0х403048 будет указателем на строку (*str), которую затем функция и выводит. Таким образом, мы находимся в непосредственной близости от защитного механизма. Сделаем еще один шаг.
004010D8 mov edi, ds: ??5std@@YAAAV?Sbasic_istream@DU?
……………………………………………………………………………………
004010F4 mov edx, ds: ?cin@std@@3v?$basic_istrearn@DU?
004010FA lea ecx, [esp+ICh]
004010FE push ecx
004010FF push edx
00401100 call edi
Теперь вызывается функция basic_istream, считывающая пароль со стандартного устройства ввода (клавиатуры). Прототип ее аналогичен, за исключением того что вместо выводимой строки ей передается указатель на буфер.
Я умышленно взял сложный для понимания пример. Вероятно, вы думаете, что буфер расположен по адресу [esp+ICh]? И чтобы сравнить введенную строку с эталонной, необходимо передать указатель на [esp+IChl? Как бы не так! Коварный оптимизирующий компилятор использовал не регистр ЕВР, значение которого неизменно на протяжении всей процедуры, а указатель на верхушку стека esp! Занесение параметров в стек приводит к изменению esp, и нет никакой возможности предугадать его значение в произвольной точке кода. Приходиться отслеживать все операции со стеком и вычислять новое значение esp в уме (или с помощью хитрых скриптов для IDA, о которых мы поговорим в следующий раз).
Рассмотрим нижеследующий фрагмент. После того как [esp+ICh] указал на буфер, содержащий введенную строку, в стек были переданы два двойных слова (см. выше). Заметим, что стек растет "снизу вверх", т.е. от старших адресов к младшим.
Команда add очищает стек от локальных параметров отработанной функции. Тогда новое значение esp равно -2*4+0х10 == +8; Ох1С - 0х8 = 0х14. Следовательно, теперь уже [esp+0xl4l указывает на наш буфер!
00401102 add esp, 10h
00401105lea eах, [esp+14h]
00401109 lea ecx, [esp+10h]
0040110D push eax