Идея создания курса родилась из-за того, что многие туториалы в «Новом курсе от CracksLations» оказывались слишком сложными для новичков, и те, не сумев достигнуть нужного уровня, оказывались разочарованными и во многих случаях отказывались продолжать. Поэтому целью данного «Введения...» является не повторение прекрасных туториалов из «Нового курса...», число которых уже перевалило за 500, но заложить основу, чтобы те, кто закончит данный курс, смогли читать более сложные пособия. Это, как и всё в нашем ремесле, требует значительных усилий, и главной задачей является сократить их количество, дав базовые знания и позволив в дальнейшем понимать более сложный материал.

Почему OLLYDBG? Мы не будем здесь рассуждать о вечном противостоянии Soft-Ice против OllyDbg, думаю, что даже фанатики от Soft-Ice признают, что проще начать с OllyDbg, так как о нём много информации и его проще изучать. Нам нужно войти в мир крэкинга через дверь под названием «OllyDbg», а уже потом тот, кому нужно, сможет перейти на любой другой отладчик, который потребуется, так как меняются лишь их способы использования, но суть остаётся неизменной. Начнём с начала

Сначала нужно вооружиться инструментом, который мы собираемся в основном использовать, для чего кликните тут и скачайте его.

Поскольку мы начинаем с нуля, то для начала нам нужно распаковать скачанный архив в такую папку на жёстком диске, до которой можно легко добраться. Хорошей идеей будет создать папку на диске C:/. Хотя будет работать и в любом другом месте, я буду исходить из того, что выбран диск C:/.

После того, как файл был распакован, заходим в созданную папку и видим:

В ней находится исполняемый файл OLLYDBG.exe, который нам и нужно запустить и ярлык которого я для удобства сделал на своём рабочем столе.

Ок, всё готово к запуску. Кликаем на OllyDbg:

Перед нами повляется сообщение о том, что DLL, находящаяся в библиотеке, старше, чем такая же системная DLL, и если выберем «Да», то тогда старая DLL будет стёрта из папки, а использоваться будет системная. Хотя я не вижу особых различий между этими двумя, тем не менее, предпочитаю ту, которая идёт с дистрибутивом, и поэтому всегда нажимаю «Нет».

Это чистый OllyDbg, и первой программой, которую мы откроем только для того, чтобы ознакомиться с OllyDbg, станет знаменитый CrackMe (находится в архиве wasm_files.zip: files/0419/ollydbg01-Crackme.zip) CrueHead’а, который приложен к данному туториалу.

Чтобы открыть файл в OllyDbg, идём в File -> Open или нажимаем на иконку:

Откроется окно, с помощью которого можно найти нужный файл, в данном случае это crackme CrueHead’а.

Откроется вышеупомянутый crackme, и на данный момент неважно, что совершенно непонятно, что означает открывшийся нам вид – пока мы только пройдёмся по различным частям и функциям OllyDbg и некоторым настройкам, чтобы когда в последующих туториалах будет написано, скажем, «зайдите в DUMP», вы, по крайней мере, знали, где находится эта опция.

Здесь мы рассмотрим четыре части главного окна OllyDbg:

1) Дизассемблированный код

Также называется листингом. Тут Олли показывает нам дизассемблированный код программы, которую мы собираемся отлаживать; по умолчанию Олли сконфигурирована так, чтобы анализировать программу при её открытии. Это можно изменить в Options -> DEBUGGING OPTIONS.

То есть, если отмечена галочка «AUTO START ANALISIS OF MAIN MODULE», OllyDbg проанализирует программу и покажет о ней дополнительную информацию.

Это начало проанализированного листинга крэкми CrueHead’а, и если мы откроем его без анализа, то сможем увидеть разницу.

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

Зачастую OllyDbg отображает некоторые части программы некорректно, так как ошибочно интерпретирует исполняемый код как данные, и тогда она отображает примерно следующее:

В этом случае можно вручную убрать анализ, кликнув на листинге правой кнопкой мыши и выбрав «ANALISIS -> REMOVE ANALYSIS FROM MODULE».

И тогда листинг отобразится корректно.

Другой опцией, которой вы можете воспользоваться для облегчения раобты и которая мне лично не очень нравится (но вкусы бывают разные), является подсветка jump (переходов) и call (вызовов) – кликните на листинге правой кнопкой мыши и выберите «APPEARENCE -> HIGHLIGHTING -> JUMPS AND CALLS».

Получится следующее:

Здесь мы видим, что call’ы подсвечены лазурным цветом, а переходы – жёлтым.

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

2) Регистры

Второе важное окно – это окно регистров.

Вспомним, что окно регистров находится в самой правой части OllyDbg, и там отображается значительное количество информации.

Есть значительно больше информации, которую мы не видим, но можно устанавливать режим отображения в три состояния («VIEW FPU REGISTERS» – отображать FPU-регистры, «VIEW 3D NOW REGISTERS» – отображать “3D NOW”-регистры и «VIEW DEBUG REGISTERS» – отображать отладочные регистры). По умолчанию отображаются первые.

3) Стек или «куча»

Теперь переходим к «стеку или куче». Здесь не слишком много конфигурационных опций – разве что возможность отобразить информацию, касающуюся регистров ESP и EBP.

По умолчанию стоить режим отображения информации, связанной с ESP (и он же является самым полезным), но его можно сменить на режим отображения информации, связанной с EBP, для чего необходим кликнуть в этом окне правой кнопкой мыши и выбрать пункт «GO TO EBP», а дальнейшее использование пункта «GO TO ESP» вернёт нас в прежний режим.

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

4) Дамп

У окно дампа есть много режимов отображения, которые можно менять, кликнув правую кнопку мыши в окне дампа и выбрав тот, который нужен. По умолчанию используется используется режим 8-ми байтовый Hex/ASCII.

Режим, используемый по умолчанию, также является и чаще всего используемым, но вместе с тем, у нас есть возможность изменять его на показ дизассемблированного кода (DISASSEMBLE), текста (TEXT) и других форматов (SHORT, LONG, FLOAT).

И, накоец, опция SPECIAL -> PE HEADER, которая, как мы это увидим в ближайших главах, может быть очень полезной.

Теперь мы знаем основные части главного окна OllyDbg, но есть ещё окна, которые недоступны напрямую, но могут быть вызваны как через меню, так и через кнопки на панели управления.

Рассмотрим каждую из них.

Кнопка L или VIEW->LOG показывает нам то, что OllyDbg пишет в окне лога. Его можно сконфигурировать на отображение различного рода информации, а по умолчанию в окне лога сохраняется вся информация о запуске, а также информация, связанная с «BREAKPOINTS CONDICIONAL LOGS» (условными логами точек останова). С последней мы встретимся гораздо позднее, а пока давайте посмотрим информацию о запущенном процессе (в нашем случае это крэкми CrueHead’а) и библиотеках, которые он загружает.

Одна из самых главных опций данного окна – это ведение лога в файле на тот случай, если мы хотим сохранять информацию в текстовом файле. Чтобы активировать эту опцию, нажмите на правую кнопку мыши и выберите «LOG TO FILE».

Кнопка E или VIEW->EXECUTABLES показывает нам список модулей, которые использует программа: exe, dll, ocx и прочие.

Здесь также правая кнопка мыши вызывает множество опций, которые пока мы смотреть не будем, но которые мы уже видели при исследовании главного окна OllyDbg.

Кнопка M или VIEW->MEMORY отображает память, занятую нашей программой. Здесь мы видим секции приложения, библиотеки, использующиеся процессом, стек и различные секции, занятые системой, и зачастую программы в процессе выполнения занимают новые секции памяти.

Кликнув правой кнопкой мыши можем сделать SEARCH в памяти, чтобы найти в ней строки различных родов (текстовые, шестнадцатиричные, юникодовые), также есть возможность подстветить точки останова в секциях, равно как и возможность изменить права доступа к последним (выберите SET ACCESS).

Кнопка T или VIEW->THREADS показывает нам список нитей (потоков) программы.

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

Кнопка W или VIEW->WINDOWS отображает нам окна программы, но поскольку она ещё не выполняется, то и список окон остаётся пустым.

Кнопка H или VIEW->HANDLES отображает хэндлы, позже я объясню, для чего они служат.

Кнопка C или VIEW->CPU возвращает нас к главному окно OllyDbg.

Кнопка / или VIEW->PATCHES показывает список наложенных патчей, если программа была изменена. Поскольку пока никаких изменений не вносилось, сейчас окно остаётся пустым.

Кнопка K или VIEW->CALL STACK отображает «call stack», списко вызовов, которые нам встретились до того места, где программа остановилась.

Кнопка B или VIEW->BREAKPOINTS вызывает список обычных точек останова, расположенных в программе. Здесь нет ни точек останова аппаратного обеспечения, ни точек останова памяти, только обычные.

Кнопка R или VIEW->REFERENCES показывает окно ссылок, полученных нами в результате поиска ссылок в Олли.

Кнопка «…» или VIEW->RUN TRACE отображает результат выполнения команды RUN TRACE. Здесь мы также можем выбрать опцию LOG TO FILE), чтобы сохраненить результаты трассировки в текстовом файле.

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

Как сконфигуровать OllyDbg стала JIT (JUST IN TIME DEBUGGER)

Конечно, мы не будем всё время использовать JIT, а только в специальных случаях, так как если случится ошибка с какой-либо запущенной программой на нашей машине, то нам совсем не нужно, чтобы использовалась Олли (по умолчанию в качестве JIT используется dr.watson).

Чтобы сделать OllyDbg JIT-отладчиком, нужно перейти в OPTIONS->JUST IN TIME DEBUGGING

и нажать последовательно кнопки MAKE OLLYDBG JUST IN TIME DEBUGGER y DONE

Чтобы убрать эту функцию, нужно в том же месте нажать на RESTORE JUST IN TIME DEBUGGER и DONE.

Подключение плагинов в OllyDbg

OllyDbg позволяет подключать плагины, которые могут оказаться полезными для решения той или иной задачи. Пока мы ограничимся подключением плагина COMMAND BAR, чтобы научиться как это делать.

Скачиваем данный плагин отсюда (находится в архиве wasm_files.zip: files/0419/cmdbar310109c.zip) (ссылка, указанная в оригинальной статье, умерла, поэтому я скачал плагин из инета и разместил её на wasm.ru - прим.пер.).

После этого распаковываем плагин и смотрим содержимое папки, где это было сделано:

Прежде всего нужно создать папку для плагинов. Я создам её на C:/ и назову PLUGINS.

Разумеется, плагины могут находиться где угодно, но мне нравится размещать всё на C. Как бы то ни было, теперь мы должны сконфигурировать OllyDbg, чтобы она распознавала эту папку как местонахождение всех плагинов.

Для этого идём в OPTIONS->APPEARANCE.

И в открывшемся окне открываем вкладку DIRECTORIES.

Видим, что в качестве пути к плагинам указана директория, где находится сам OllyDbg.exe, и можно было бы помещать плагины туда, но мне нравится держать их отдельно, и тогда нажимем на PLAGIN PATH->BROWSE, чтобы найти созданную нами папку.

Выбираем папку PLUGINS и сохраняем изменения.

То есть нужно перезапустить Олли, чтобы она признала новую папку с плагинам, но сначала следует скопировать в последнюю скачанный плагин.

Копируем всё содержимое архива в папку PLUGINS.

Теперь все файлы плагина «Command Bar» находятся в папке PLUGINS, в неё же следует помещать и остальные (зачастую можно копировать не все файлы в архиве, а только dll).

Теперь закрываем OllyDbg, если она всё ещё была закрыта, и запускаем по новой. Видим, что в меню PLUGINS появился COMMAND BAR и его опции.

В нижней части OllyDbg видим установленный COMMAND BAR.

Это текстовое поле для ввода команд, которые нам могут пригодиться во многих случаях, и позднее мы увидим их применение, а пока важно научиться подключать плагины.

Чтобы деинсталлировать PLUGIN достаточно просто стереть соответствующую dll из папки PLUGINS и перезапустить OllyDbg, и плагин исчезнет. Вместе с тем, благоразумно всегда держать COMMAND BAR включённым.

Снова открываем крэкми CrueHead’в в OllyDbg.

Наиболее полезные клавиши в OllyDbg следующие:

F7: Выполняет одну строку кода (если находимся на CALL, то переходим внутрь вызванного участка кода)

F8: Выполняет одну строку кода (если находимся на CALL, то просто выполняет вызов без перехода внутрь и переходит на следующую за CALL строку).

Это два вида ручной трассировки очень разные и в каких случаях использовать каждую из них мы рассмотрим позже.

F2: устанавливает обычную точку останова на отмеченной линии. Чтобы убрать эту точку останова, надо ещё раз нажать F2.

Например:

Хотим установить точку установа в позиции 40101A, поэтому отмечаем эту линию с помощью мыши.

С помощью одного клика мыши она помечается и становится серого цвета как на картинке. Затем нажимаем F2.

Видим, что соответствующая позиция в первой колонке становится красной, что говорит о том, что здесь есть точка останова. Нажав F2 ещё раз можно её убрать.

F9: Запускает программу, которая будет выполняться до тех пор, пока не встретить точку останова, не совершиться какое-либо исключение или же просто прекратит работу по каким-либо причинам. Когда программа запущена, в нижнем правом угле OllyDbg отображается слово RUNNING.

Запустив крэкми CrueHead’а, мы увидим следующее:

Чтобы временно прекратить выполнение программы, нужно нажать F12 или DEBUG->PAUSE.

Видим, что OllyDbg отображает слово PAUSED (пауза). Продолжить выполнение программы можно нажав F9 или DEBUG->RUN.

Чтобы закрыть отлаживаемую программу выберите DEBUG->CLOSE.

Это был краткий обзор OllyDbg, более глубокое изучение множества опций и возможностей которой мы продолжим изучать в последующих главах. Главное, чтобы вы скачали программу, сконфигурировали, ещё раз посмотрели всё, о чём было рассказано в этом туториале, так же подключили плагин, позапускали и поостанавливали крэкми CrueHead’а, попробовали поставить точки останова, чтобы в следующей главе все эти вещи не вызывали у вас колебаний и сомнений.

Наиболее часто используемыми системами счисления являются двоичная, десятеричная и шестнадцатеричная.

Основное, что о них нужно знать:

• ДВОИЧНАЯ: представляется символами 0 и 1, и поэтому называется двоичной.

• ДЕСЯТЕРИЧНАЯ: представляется десятью символами (от 0 до 9), и поэтому называется десятеричной.

• ШЕСТНАДЦАТЕРИЧНАЯ: представляется символами от 0 до F (0-9, а также A, B, C, D, E и F, то есть 16 символов в итоге).

Обычно, если будет упоминаться какое-то число, то будет считаться, что оно в шестнадцатеричной системе, если иное не указано явно.

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

Открывает калькулятор и подготавливаем его для работы.

Теперь идём в меню «View», чтобы включить научный режим.

Здесь мы видим, что по умолчанию стоит десятеричная система счисления. Сбоку можно изменить её на одну из трёх: шестнадцатеричную (HEX), восьмиричную (OCT) и двоичную (BIN).

Восьмеричная система, использующую 8 символов, не слишком используется в крэкинге, но если потребуется, то в калькуляторе такая опция есть.

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

Теперь переводим калькулятор в шестнадцатеричную систему счисления, и введённое число автоматически конвертируется в него.

Таким образом, видимо, что 55 в десятеричной системе – это 37 в шестнадцатеричной.

При этом появились неиспользованные в десятеричной системе счисления клавиши с символами A, B, C, D, E, F, чтобы мы могли их вводить.

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

Это понять гораздо сложнее, поэтому начнём издалека. Как в шестнадцатеричной системе можно представить отрицательное число, если мы не можем использовать для это цели минус как в трационной десятеричной системе? Как представить в шестнадцатеричном формате, например, -1?

Рассмотрим эту проблему, и надеюсь, что всё станет понятно.

Если у нас есть возможность писать шестнадцатеричные числа от 00000000 до FFFFFFFF, то как нам представлять отрицательные числа?

Мы можем использовать половину этого диапазона для положительных чисел, а половину – для отрицательных.

Положительные числа будут идти от 00000000 до 7FFFFFFF, а отрицательные – до 80000000.

Положительные

000000000 всё равно, что 0 в десятеричной

000000001 всё равно, что 1 в десятеричной

...

...

7FFFFFFF всё равно, что 2147483647 в десятеричной ( и это максимальное положительно е число)

Отрицательные

FFFFFFFF всё равно, что -1 в десятеричной

FFFFFFFE всё равно, что -2 в десятеричной

...

...

80000000 всё равно, что -2147483648 в десятеричной (и это максимальное отрицательное число)

Можно попробовать узнать в Command Bar значение 7FFFFFFF в десятеричной системе, для чего используется вопросительный знак, после которого идёт собственно само значение.

Справа видим, что получили соответствующее десятеричное значение, которое равно 2147483647, то есть всё в порядке.

Теперь когда хотим выяснить, является ли значение 80000000 отрицательным, видим, что не показываются результаты для значений после 7FFFFFFF (это баг в Command Bar), поэтому как же нам выяснить его значение в OllyDbg?

Для этого есть маленький трюк.

Идём в регистры и выделяем EAX.

Теперь нажимаем на правую кнопку мыши и выбираем “MODIFY”.

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

В данном случае видим, что 80000000 соответствует десятеричному -214783648.

Если хотим убедиться, что FFFFFFFF это десятеричное -1.

Таким образом, в окне модификации регистра мы можем легко проверять значение отрицательных числе, после чего можем выйти, нажав “Cancel”, не изменив на самом деле регистр никаким образом.

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

В таблице, скопированной (хе-хе) из «Теории ассемблера» (Caos Reptante), можно видеть десятеричное значение и соответствующие ему шестнадцатеричное и символьные значения. Например, если нужно использовать символ пробела в Олли, то можем применить 20 (hex) или 32 (dec).

В остальных случаях мы можем узнать символьное значение шестнадцатеричного числа с помощью Command Bar:

? 45

Видим, что 45 соответствует заглавное букве “E”, и если поищем число 45 в средней колонке вышеприведённой таблицы, то убедимся, что это и есть шестнадцатеричное значение буквы “E”.

Также в OllyDbg есть окно DUMP, где находится колонка с ASCII-символами. Давайте посмотрим, увидим ли мы какие-нибудь из них в крэкми CrueHead’а.

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

Стек или «куча» - это зона памяти, где сохраняются данные, которые должны быть восстановлены в ближайшее время.

Слово «куча» напоминает о пачках или кучах писем или игральных карт, встречающихся на столах. В этих пачках самое новое письмо помещается сверху, а если письмо берётся из такой пачки, то также сверху.

Это и есть основная черта стека. Письмо помещается на верх кучи, и оно же будет тем, которое уйдёт самым первым.

В дальнейшем мы рассмотрим, как работать в OllyDbg со стеком.

Хорошо, думаю, что на этот раз достаточно. В третьей главе мы рассмотрим, что такое регистры и флаги, и для чего они предназначаются.

Процессору нужны помощники для выполнения программ. Таковыми и являются

регистры: когда необходимо выполнить какую-либо инструкцию, например, которая

складывает содержимое двух ячеек памяти, процессору нужно разместить содержимое

одной из них в регистре, а затем сложить то, что в нём находится с содержимым

другой ячейки. Это один из примеров использования регистров.

ESP указывает на самое верхнее значение стека, посмотрим это на примере

крэкми от Cruehead'а.

ESP равняется 12FFC4, и если посмотрим в OllyDbg на стек,

то увидим, что регистр указывает на верхнее значение нашего стека или, говоря

образно, на верхнее письмо в пачке.

EIP - это другой очень важный регистр, который указывает на инструкцию,

выполняющуюся в данный момент.

Видим в листинге, что при загрузке крэкми адресом первой выполняемой инструкции

является 401000, и очевидно, что именно это значение и содержится в EIP.

Если нажать на F7, то выполнится первая инструкцию и наступит очередь второй.

Теперь EIP равен 401002, и в листинге видим, что первая инструкция

выполнилась и находимся сейчас на второй.

Другие регистры могут содержать различные значения и служить для помощи

процессору в выполнении инструкций.

Вспомним, где OllyDbg показывает значения регистров:

Взгланув туда, узнаём, что существуют EAX, ECX, EDX, EBX, ESP, EBP,

ESI, EDI y EIP.

Они называются 32-х битными регистрами.

OllyDbg отображает их содержимое в шестнадцатеричной форме. Например,

минимальное значение EAX может быть равно 00000000, а максимальное -

FFFFFFFF, что в двоичной системе счисления будет

11111111111111111111111111111111.

Видим, что есть 32 бита, каждый из которых может быть равен 0 или 1, поэтому

регистры и называются 32-х битными.

В ассемблере можно обращаться к частям этих 32-х битных регистров.

Рассмотрим пример работы с регистрами, чтобы немного попрактиковаться в OllyDbg.

Изменим значение EAX на то, которое нужно нам, в данном случае это 12345678.

Открываем OllyDbg, где загружен крэкми Cruehead'а (хотя там может быть и что-то

другое).

В открывшемся окне пишем в поле “Hexdecimal” 12345678.

Вот так:

Потом нажимаем OK.

Видимо, что теперь в регистре нужное значение. OllyDbg выделяет изменённые

значения красным цветом.

При желании можно использовать часть EAX, в данном случае AX будет 16-ти

битным регистром, например, в примере выше в нём будет находится 5678, в чём

можно убедиться, напечатав в Command Bar:

(знак вопроса также служит для нахождения значения выражения или регистра).

После нажатия клавиши ENTER.

видим пресловутые 5678, т.е. AX содержит последние четыре цифры EAX. Также

существуют AL и AH, значения которых также можно посмотреть в OllyDbg.

Или если EAX = 12345678, то AX - это последние 4 цифры.

AH - это 5 и 6 цифры, а AL - это две последние.

Таким же образом EBX делится на BX, BH и BL, равно как подобное деление

существует и почти для всех остальных регистров.

Как мы увидели, в OllyDbg можно изменять значения регистров. Всё, что мы сделали

с регистром EAX применимо и к другим регистрам: отметьте регистр, значение

которого вы хотите изменить, затем кликните по правой кнопке и нажмите “Modify”.

Единственное исключение - это EIP, указывающий на инструкцию, которая должна

выполнится.

Чтобы изменить его, сделайте следующее: поскольку EIP всегда указывает на

инструкцию, которая должна выполниться, то просто выбираем новую инструкцию в

листниге.

После того, как отметили, например, 40101A, кликаем правую кнопку мыши ->

“New origin here”, и EIP изменится на 40101A, и таким образом, программа

продолжит выполнение именно с этго места.

Как видим, EIP содержит 40101A.

Как мы увидели в первой главе, в OllyDbg под регистрами находятся флаги.

Видим, что флаги бывают C, P, A, Z, S, T, D y O.

Видим, что они могут иметь только два значения: ноль или один. Определённые

инструкции при выполнении могут изменять их значение.

Мы собираем рассмотреть следующие флаги:

Этот флаг активируется, когда в результате операции изменяется знак и

возвращается неправильное значение.

Рассмотрим в OllyDbg следующий пример, как обычно используя крэкми Cruehead'а.

Меняем таким же, как и раньше, образом значение EAX на 7FFFFFFF, которое

является максимальным положительным.

Теперь прибавим 1, из-за чего сумма превысит максимальное позитивное число,

потому что, как мы знаем, 80000000 соответствует числу отрицательному.

Для этого вызовем окно, где можно писать инструкции.

В нём пишем ADD EAX, 1.

После нажатия на кнопку “ASSEMBLE” увидим, что инструкция по адресу 401000

изменится на ту, которая была введена.

ADD EAX, 1, как мы узнаем, когда будут перечисляться и объясняться инструкции,

прибавляет к EAX число 1 и сохраняет в этом же регистре полученное значение.

До выполнения этой строки с помощью F7 флаг “O” равен нулю.

Если выполнить данную строку с помощью F7, чтобы увидеть, что произойдёт, то в

EAX окажется 80000000 и знак числа будет изменён.

Флаг “O” станет активным и будет показывать 1, то есть, что результат

выполненной инструкции превзошёл максимально возможный результат. Назначения

этого флага - показывать, когда это происходит.

Имеет схожее назначение при выполнении операция с другими форматом, поэтому

сейчас он нам не интересен.

Данный флаг активируется, когда результат выполнения инструкция в двоичной форме

содержит чётное количество единиц, например, 1010, 1100 или 1111000.

Чтобы опробовать его, у нас уже есть заданная в OllyDbg инструкция

ADD EAX, 1, и что выполнить это строку снова, выделим строку 401000, кликнем

правую кнопку мыши и выберем “New orgin here”, чтобы вернуться назад, и теперь,

если нажмём F7, выполнится инструкция, которую мы задали - ADD EAX, 1.

Сейчас у нас в EAX содержится значения 00000000, а флаг “P” равен 1 (как

результат выполнения предыдущей инструкции), посмотрим, что случится, когда

прибавим к EAX 1.

Нажимаем F7.

Видим, что “P” стал равен 0, так как результат, содержащийся в EAX, равен в

двоичной форме 1, что в двоичной форме содержит всего лишь одну единицу, то есть

нечётное количество.

И снова кликаем на ADD EAX, 1, а потом правой кнопкой мыши и выбираем “New

origin here”, чтобы снова прибавить 1. Нажимаем F7.

Видим, что в EAX, содержавшем прежде значение 1, теперь находится 2, что в

двоичной форме равно 10. Число единиц опять нечётно и флаг “P” неактивен.

Повторим процесс с прибавлением единицы ещё раз.

Теперь в EAX содержится значение 3, что в двоичной форме равно 11, и сейчас

результат содержит чётное количество единиц, а флаг чётности стал активен.

Вот мы и познакомились с тем, как работает вышеуказанный флаг: если результат

выполнения инструкции содержит в двоичной форме чётное количество единиц, то

флаг активен.

Это один из самых известных и используемых в крэкинге флагов, который становится

активным, когда результатом выполненения инструкции является ноль.

Вернёмся к нашей инструкции ADD EAX, 1 по адресу 401000 (клик правой кнопкой

мыши - “New origin here”), но сделаем значение EAX равным FFFFFFFF, что равно

десятиричному -1, поэтому когда нажмём F7 и запустим ADD EAX, 1, результатом

-1 + 1 будет ноль и флаг “Z” должен стать активным.

Видим, что после нажатия F7 EAX содержит ноль, а раз результат - ноль, то флаг

Z активен и равен 1.

Думаю, теперь стало ясным, что данный флаг активен, когда результат инструкции

равен нулю. Различные способы достичь этого мы узнаем позже.

Этот флаг равен 1, когда результат операции отрицателен. Что посмотреть его в

действии, изменим занчение EAX на FFFFFFF8, что равно -8 в десятиричной

форме.

С помощью “New origin here” и кнопки А7 можно снова выполнить ADD EAX, 1.

Результатом будет FFFFFFF9, то есть -7 в десятиричной форме, которое является

отрицательным числом, поэтому флаг знака должен стать активным.

Нажимаем F7 и после выполнения инструкции активируется флаг “S”, который теперь

равен 1, то есть ясно, что отрицательный результат его активирует.

Активен, когда превышается максимальное значение, которое может содержать

регистр, например, если поместим в EAX значение FFFFFFFF и прибавим 1, то

увидим, что флаг переноса стал равен 1.

Я не буду объяснять их назначение сейчас, так как это достаточно сложная тема, и

пока нам они не слишком инетересны. Пока мы будем рассматривать более простые

инструкции, а эту тему оставим на потом.

Таким образом, мы получили представление о каждом регистра и в каких случаях

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

инструкций одну за другой, так как пока мы только видели инструкцию ADD.

Если вам ещё что-то осталось непонятным, попрактикуйтесь в изменении значений

флагов с помощью использованной нами инструкции ADD EAX, 1, а затем переходите

к следующей части данного «Введения...»

Очень важно, чтобы вы поняли основую суть, так что не колебайтесь

попрактиковаться и пееречитать этот материал ещё раз.

Рассмотрев в OllyDbg почти все флаги, мы перейдём к рассмотрению наиболее важных инструкций. Если вы встретите в листинге инструкцию, которой не окажется здесь, вы можете проконсультироваться с каким-нибудь более полным руководством по ассемблеру.

NOP (NO OPERATION)

Это инструкция, которая при запуске не производит никаких изменений в регистрах, стеке или памяти, поэтому по-английски её название расшифровывается "NO OPERATION", то есть у неё нет никакого специального анзначения, и поэтому её можно использовать, например, если нужно заменить одну инструкцию на другую, более короткую. Чтобы процессор не столкнулся с ошибками, лишнее место заполняется NOP'ами.

Также она служит для полного уничтожения другой инструкции, для этого нужно заменить её соответствующим количество NOP'ов, или попросту заNOPать.

Снова откроем крэкми CrueHead'а.

В самом начале видим оригинальный код. Чтобы занопать первую инструкцию PUSH 0, которая имеет размер 2 байта, отмечаем соответствую строку листинга с помощью мыши, а затем нажимаем клавишу "пробел" или же правая кнопка мышь - ASSEMBLE.

Здесь видим, что действительно можно просто нажать "пробел", после чего откроется окошко для ввода желаемой инструкции.

Пишем NOP и нажимаем ASSEMBLE.

Видим, что Олли, кроме того, что ввела NOP, будучи весьма умной программой, учла, что PUSH занимает два байта, и чтобы не оставлять неприкаянным следующий байт, ввела дополнительный NOP.

Теперь на месте, где был "PUSH 0", находятся два NOP'а, которые при исполнении ничего не делают, в чём мы можем убедиться, нажав два раза F7, чтобы стала отмеченной инструкция CALL. Увидим, что изменился только регистр EIP, содержащий адрес инструкции, которая должна выполнится следующей, но ничего больше не изменило своего значения: ни другие регистры, ни стек, ни флаги, ни память.

Теперь нам нужно посмотреть эти два новых байта в DUMP, и для того, чтобы найти их там, нам нужен их адрес в памяти, и это 401000 и 401001.

Идём в окно DUMP, правая кнопка мыши - "Go to" - "Expression", после чего нужно будет ввести адрес, где располагаются требуемые нам байты.

Вводим 401000.

Видим, что:

Красным выделены изменённые Олли байты. Первым идут два 90, а затем E8, FF и все остальные байты, относящиеся к следующей за NOP'ами инструкцией, которой является CALL.

Может Олли вернуть обратно изменённые нами байты?

Хе-хе, да, может.

В любом из двух окон - DUMP или листинге, отмечаем оба байта.

Потом кликаем на правую кнопку мыши и выбираем "UNDO SELECTION"

И затем снова появляется изначальный PUSH.

Также, если посмотрим в DUMP, увидим, что там находятся изначальные байты.

Это всё, что касается инструкции NOP.

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

Далее следуют инструкции для помещения или удаления "писем".

PUSH

Инструкция PUSH - типичная инструкция для помещения "письма" или значения на стек. Мы можем видеть, что первая инструкция в крэкми CrueHead'а - это PUSH.

В данном случае это 'PUSH 0', и, будучи выполненной, данная инструкция поместит 0 на самый верх стека, а то, что было до этого наверху, окажется под этим значением.

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

Это стек на моей машине. Адрес 12FFC4 может отличеаться у вас, так как стек каждый раз может располагаться по разному адресу, и его начальное содержимое также может отличаться, то есть у вас может быть значение, отличное от 7c816d4f. По нажатию F7 на самый верх попадёт ноль, а всё остальное окажется внизу него. Нажмём F7.

Видим, что по нажатию F7, ноль словно присоединился сверху того, что мы уже видели. Внизу по адресу 12ffc4 по-прежнему находится значение 7c816d4f, и ни одного из других значений в стеке также не изменилось.

Главным отличием является то, что самое верхнее значение стека находится теперь по адресу 12ffc0 (именно там и неаохдится ноль, который мы поместили с помощью инструкции PUSH), это действительно как положить поверх пачки писем новое, которое окажется на самом верху, а остальные - под ним, но ничего в них не изменится.

Также видим, что ESP, в котором находится адрес самого верхнего значения стека, теперь содержит 12FFc0.

Конечно, инструкция PUSH имеет несколько вариантов, позволяющих помещать в стек не только числа:

PUSH EAX помещает значение EAX на верх стека. Подобным образом мы можем поместить в стек значение любого регистра, числа и т.п.

Также можно поместить значение, находящееся в памяти по определённому адресу:

Обратите внимание, что это будет интерпретироватиться отличным образом от следующего:

(Без квадратных скобок)

Если выполним 'PUSH 401008', то в стек будет помещено число 401008.

После выполнения имеем следующее:

Если заменить на 'PUSH [401008]'

Квадратные скобки указывают на содержимое ячейки памяти по адресу 401008, то есть мы должны пойти в DUMP и посмотреть, что там содержится.

С помощью "GOTO EXPRESSION 401008" видим:

В этих четырёх байтах находятся CA 20 40 00. Запускаем PUSH с помощью F7.

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

Это одно из свойств процессора: при чтении или записи содержимого из/в память байты всегда переворачиваются. Жалуйтесь по этому поводу производителю процессора, хе-хе.

В общем, главная идея состоит в том, что без квадратных скобок задаваемый параметр является просто числом, а с ними оно является адресом ячейки памяти, где содержится помещаемое в стек значение.

Теперь видим, что Олли, когда пишем 'PUSH [401000]' интерпретирует и отображает

Это потому, что если иное не задано специально, Олли считает, что нужно читать 4 байта из памяти, то есть DWORD. Остальные варианты мы рассмотрим в других инструкциях.

POP

Инструкция POP является обратной по отношению к PUSH: она достаёт первое письмо или первое значение из стека и помещает его в указанное параметром инструкции место назначения. Например, POP EAX берёт первое значение из стека и помещает его в EAX, после чего то значение, которое шло следующим, станосится верхним.

Видимо, что в начале крэкми CrueHead'а есть следующая инструкция:

Заменим данную инструкцию на 'POP EAX', отметив первую строку и нажав "пробел":

Вот что будет содержать стек до выполнения этой инструкции:

А ESP указывает на 12FFc4, что является адресом верхнего значения, содержащегося в стеке.

И видим что в EAX содержится ноль (в моём случае).

Нажимаем F7.

Видим, что в стеке исчезло наше первое "письмо", а ESP указывает на 12ffc8.

Но куда делось наше "письмо"? Так как инструкция был 'POP EAX', то видим, что сейчас EAX содержит значение 7c816d4f - это в моём случае, а в вашем там будет то занчение, которое лежало сверху стека.

Таким же образом, если бы была инструкция 'POP ECX' то верхнее значение было бы помещено в ECX или иной регистр, который был бы указан.

Итак, мы рассмотрели инструкции, которые помещают или берут из стека значения по одному за раз.

PUSHAD

PUSHAD помещает содержимое регистров в стек в определённом порядке, то есть PUSHAD эквивалентно 'push EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI'.

Посмотрим, правда ли то, что нам говорит камрад CAOS REPTANTE в своём туториале про ассемблер, хе-хе.

Загрузим снова крэкми CrueHead'а, вызовем меню для замены инструкции и напишем PUSHAD.

Это мой начальный стек и состояние регистров до выполнения регистров.

Нажимаем F7 и видим, что теперь находится в стеке:

Видим, что все регистры были подвергнуты PUSH'у. По адресу 12ffc4 находится значение, которое лежало сверху стека до выполнения инструкции, а сейчас после него лежит ноль (PUSH EAX), затем содержимое ECX, а в 12ffb0 - то, что находилось в ECX. Дальше находится содержимое регистров от ESP до EDI.

POPAD

Обратной по отношению к PUSHAD инструкцией является POPAD, которая берёт значения из стека и помещает их в соответствующие регистры. POPAD эквивалентна 'pop EDI, ESI, EBP, ESP, EBX, EDX, ECX, EAX'.

Как и в предыдущем примере введём инструкцию POPAD:

Поскольку стек уже содержит значения регистров, то выполнение POPAD возвратит его в изначальное состояние.

Теперь он точно такой же, как и был до выполнения PUSHAD, а регистры восстановили свои значения.

Комбинация PUSHAD-POPAD часто используется, когда нужно за раз сохранить содержимое всех регистров, потом совершить какие-то другие операции, меняющие значение регистра и стека, а затем восстановить их изначальное состояние с помощью POPAD.

Существуют также следующие варианты:

• PUSHA эквивалентно 'push AX, CX, DX, BX, SP, BP, SI, DI'.

• POPA эквивалентно 'pop DI, SI, BP, SP, BX, DX, CX, AX (восстанавливаемые значения, соответствующие ESP и SP не помещаются в эти регистры, а исключаются).

PUSHA и POPA похожи на своих сестёр PUSHAD и POPAD, не считая того, что используются в 16-ти битных программах, поэтому нас они не интересуют, так как OLLYDBG - это отладчик для 32-х битных программ.

MOV

Эта инструкция перемещает второй операнд в первый, например:

Здесь идёт перемещение значения EBX в EAX. Смотрим в Олли и наше старое доброе крэкми от CrueHead'а.

Уже не буду повторять, как ввести нужную нам инструкцию, просто смотрим регистры:

На моей машине EAX содержит 0, а ECX 7c91eb94. Эти начальные значения могут у вас отличаться, но важно то, что по нажатию F7 значение EBX переместиться в EAX, так что нажмём на эту клавишу.

Понятно?

У MOV есть разные варианты, например:

Это перемещает содержимое CL в AL. Напишем эту инструкцию в Олли.

Регистры:

Помните, что AL - это две последних цифры EAX и CL - две последних цифры ECX. Нажмём F7.

Видим, что было только скопировано B0 в AL без изменения остального содержимого EAX и ECX, то есть две последние цифры EAX.

Также можем переместить содержимое какого-либо регистра в нужную ячейку памяти или наоборот.

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

Идём в DUMP и делаем GOTO EXPESSION 405000.

Видим, что содержимое ячейки памяти - 00 10 00 00. Так как в памяти содержимое хранится в перевёрнутом виде, то в EAX попадёт 00 00 10 00. Нажимаем F7 и смотрим, что получилось.

Вот значение 1000, которое было прочитано из памяти. Теперь если хотим записать значение по данному адресу:

Введём эту инструкцию.

С помощью DUMP видим по адресу 405000:

Однако по нажатию на F7 происходит облом:

Вылетает исключение, и это происходит из-за того, что хотим записать в секцию, в которую писать, то есть изменять в ней байты, запрещено.Ок, как менять права на работу с секциями мы узнаем потом, пока важно изучить инструкции. Очевидно, что если для перемещания 4 байтов испольется слово DWORD, то для перемещения двух байтов используем WORD, а слово BYTE - для перемещения одного.

Смотрим.

Здесь перемещаются два байта из памяти по адресу 405000 в AX. В данном случае мы не можем написать EAX, так как перемещаем только два байта, поэтому необходимо использовать 16-ти битный регистр.

С помощью DUMP смотрим, что находится по адресу 405000.

По нажатию F7 должны переместить только эти два байта в AX. Проверяем:

И вот в AX в обратном порядке было считано содержимое памяти, а остальная часть EAX не изменилась.

Таким же образом испольуется BYTE.

В данном случае в AL перемещается только последний байт, то есть 08.

MOVSX (Move with Sign-Extension)

Копирует содержимое второго операнда, который может быть регистром или адресом памяти, в первый (который должен быть в два раза больше, чем второй), заполняя остальные биты слева значением самого значимого бита второго операнда. Далее идёт пример.

Определение взято из туториала CAOS'а. Сейчас мы попробуем тестовый пример в OllyDbg, для чего используем нашего друга CrueHead'а.

Не буду здесь много говорить, так как хочу, чтобы вы всё сделали сами и поискали значения операнда самостоятельно, хе-хе. В OllyDbg есть окошко с поясненениям прямо снизу листинга и сверху окна DUMP.

Тут видим, что окошко с пояснениями показывает нам значение операнда нашей инструкции. В моём случае BX содержит F000.

И также видим, что EAX содержит ноль, так что OllyDbg нам всегда помогает интерпретировать инструкцию, которая будет выполнена (надеюсь, что вы освоили концепцию того, где и что нужно искать, хе-хе).

Нажимаем F7.

Видим, что в AX скопировался BX, который содержал F000, и что остальное место заполнилось FFFF, так как F000 - отрицательное 16-ти битное число. Если бы BX содержал 1234, то EAX был бы равен 00001234, то есть левые байты были бы забиты нулями, так как 1234 - положительное 16-ти битное число.

Концепция положительных и отрицательных чисел в 16-ти битах работает так же как и для 32-х битных, только в интервале от 0000 до FFFF. Числа от 0000 до 7FFF являются положительными, а все, что выше до FFFF - отрицательными. Давайте посмотрим, что будет, если мы изменим BX на 7FFF, а EAX на ноль и снова выполним инструкцию.

В AX было скопировано 7FFF, а остальное - забито нулями, так как 7FFF является положительным числом. Проделаем то же самое с BX=8000 (отрицательное).

Выполним инструкцию по-новой с помощью F7.

В BX было скопировано 8000, а в остальное FFFF, так как 8000 является отрицательным числом.

MOVZX (Move with Zero-Extend) MOVZX похож на предыдущую инструкцию, но в данном случае свободное место просто заполняется нулями и не зависит от того, является ли второй оператор положительным или нет. Не будем приводить примеры для этой инструкции, так как они похожи на те, что выше, за исключением того, что в верхней части EAX всегда будет 0000. В AX же будет копироваться BX. LEA (Load Effective Address)

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

Введём в OllyDbg следующую инструкцию:

В данном случае есть квадратные скобки, однако в них задан не адрес на прямую, а вычисления, по которым он получается.

В моём случае ECX равен 12FFb0.

И в это примере LEA прибавит к значению ECX 38 и полученное значение поместит в EAX.

В окне пояснений будут отображены оба операнда.

Оно показывает, что операнд равен 12Ffe8, что является суммой ECX+38, а EAX до выполнения инструкции содержит ноль.

Нажимаем F7.

Указанный адрес был помещён в EAX, хотя квадратные скобки могли заставить нас подумать, что туда должно было быть помещено содержимое, находящееся по этому адресу, как бы это сделала инструкция MOV, но LEA просто поместила адрес в первый операнд, а не его содержимое.

XCHG (Exchange Register/Memory with Register)

Эта инструкция обменивает содержимое двух операндов, например:

Значение EAX будет помещено в ECX и наоборот. Проверим это в Олли.

На моей машине до выполнения EAX содержал ноль, а ECX - 12FFb0.

Нажав F7, увидим, что они обменялись значениями.

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

По нажатию на F7:

Также как и в примере с MOV было сгенерировано исключение, так как у нас нет прав на запись.

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

Эти инструкции увеличивают или уменьшают значение операнда, прибавляя к нему один в случае с INC или, соответственно, отнимая один в случае с DEC.

Идём в Олли и, как обычно, открываем крэкми CrueHead'и и в первой строке пишем:

На моей машине EAX изначально равен нулю. Если у вас это не так, вы можете изменить это вручную.

Затем нажимаем F7 и выполняем инструкцию INC EAX, увеличивая его на один.

Таким же образом можем ввести DEC сразу под предыдущей инструкцией.

Нажимаем F7 и выполняем инструкцию INC EAX, которая уменьшает значение регистра на 1, после чего он принимает предыдущее значение - 0.

Также можно увеличивать или уменьшать значение ячейки памяти.

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

Что было бы, если бы у секции было выставлено разрешение на запись? Идём в DUMP по адресу 405000.

Содержимое, если его прочитать наоборот, будет равно 00001000, значит, если бы оно было увеличено, то было бы 00001001

В данном случае для DWORD прибавление 1 производилось к 4 байтам содержимого.

Для WORD суммирование будет применено только к двум последним байтам.

И при BYTE суммирование будет применено только к последнему байту.

ADD

ADD, как можно видеть, суммирует оба операнда, сохраняя результат в первом.

ADD EAX, 1 похоже на INC EAX.

Также можем складывать регистры.

Идём в Олли.

До выполнения инструкции:

На моейм машине EAX содержит 00000000, а EAX - 12FFB0. У вас данные регистры могут содержать другие значения, также вы можете, если хотите, их изменить, но когда вы нажмёте F7, оба значения будут сложены, а результат помещён в EAX. Смотрим:

Здесь EAX стал красного цвета, потому что он был модифицирован и содержит результат суммирования.

Также можем сложить регистр с содержимым ячейки памяти.

В данном случае нет проблем с правами на запись, так как меняется и сохраняет результат регистр EAX, а содержимое [405000] остаётся неизменным. Соответственно, не генерится и никакого исключения.

До нажания F7 видим, что EAX содержит 0, а по адресу 405000 находится значение 00001000.

Нажимае F7, после чего вычисляется сумма.

Так как EAX = 0, то в EAX сохраняется результат, равный 1000.

Если хотим, чтобы результат сохранился в памяти, то пишем:

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

ADC (ADD С ПЕРЕНОСОМ)

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

Здесь видим, что здесь будет суммирован EAX, содержащий 21, со числом 3, а также вычислен флаг C, который сейчас равен нулю. Нажимаем F7.

Видим, что результат равен 24. Теперь повторим эту операцию, но с флагом C равным 1, значение которого мы можем изменить, если дважды кликнем по нему мышью.

Сделав это, повторяем выполнение инструкции, изменив значение флага C.

Нажимем F7 и вуаля - результат равен 25.

Так как сумма EDX (21) с 3 и флагом C, равном 1, равна 25.

SUB

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

На моей машине регистры до выполнения инструкции содержали следующее:

По нажатию F7 инструкция вычтет от EAX, который содержит ноль, значение 2.

Результатом является -2, что в шестнадцатеричной системе выглядит как FFFFFFFE, в чём мы можем убедиться, если кликнем два раза мышью на данном значении:

Видим, что в десятеричной системе это равно -2.

Также можно отнимать значение регистров и ячеек памяти примерно таким же образом, как и при использовании инструкции ADD.

То есть EAX-ECX с сохранением результата в EAX.

И

Вычитает от EAX содержимое ячейки памяти по адресу 405000, сохраняя результат в EAX.

Обратный случай:

Так как результата сохраняется .в первый операнд, то, поскольку у нас нет прав на запись в секцию, то получим исключение.

SBB

Это операция является обратной к ADC: она вычисляет разность между операндами, отнимает от того, что получилось, значение флага переноса (флаг C) и сохраняется окончательный результат в первый операнд.

До выполнения в EDX находилось 21, а флаг переноса был равен 0.

Нажатие на F7 вычтет из EDX число 3, а затем ноль, которому равен флаг C.

Теперь повторим операцию, присвоив флагу C значение 1.

Нажимает на F7 и теперь из EDX вычитается 3, а затем единица, которой равен флаг C.

В данном случае результат равен 1D.

MUL

Ок, есть две инструкции для выполнения умножения. Первой из них является MUL, которая не учитывает знаки чисел. Она использует только один операнд, а другим всегда является EAX Результат сохраняется в EDX:EAX.

Например:

Здесь ECX умножается на EAX без учёта знаков их значений, а результат сохраняется в EDX:EAX.

Рассмотрим следующий пример с помощью OllyDbg:

Поместим в EAX число FFFFFFF7, в ECX - 9, а затем посчитаем результат с помощью стандартного калькулятора Windows:

Получится:

Это не поместится в EAX. Посмотрим, что будет в Олли и нажмём на F7.

EDX и EAX выделены красным, так как их значение было изменено, и, как видим, в EAX было сохранено то, что поместилось, а остальное в EDX. В данном случае 8-рка, которую не смог вместить EAX, попала в EDX, поэтому в таких случая говорят, что результат содержится в EDX:EAX, то есть два регистра используются как один двойного размера.

В случае с

Происходит умножение ячейки памяти по адресу 405000 на EAX, а результат, как обычно, помещается в EDX:EAX без учёта знаков операндов.

Чтобы посмотреть в Олли как выглядит какое-либо шестнадцатеричное значение без учёта знака, кликните два раза мышью на любом регистре.

Как можно видеть, во втором ряду находится значение со знаком (в данном случае FFFFFFAF это -81, если учитывать знак), но в таких операциях как MUL все числа считаются БЕЗЗНАКОВЫМИ. Третья строка как раз и содержит десятеричное значение без знака. Сейчас видим, что число FFFFFFAF - это 4294967215, если рассматривать его как положительное, то есть беззнаковое.

IMUL (умножение без знака)

Инструция IMUL - это умножение со знаком и употребляется аналогично MUL.

IMUL ECX

Данная операция производит умножение ECX на EAX, а результат сохраняется в EDX:EAX с учётом знака операндов.

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

Из туториала CAOS'а:

Несмотря на использовальние регистров EAX и EDX по умолчанию, можно указать другие источники и приёмники данных вплоть до трёх операндов. Первый - место, куда необходимо поместить результат и которое всегда должно быть регистром, второй и третий - два значения, которые нужно перемножить. В этих примерах увидим применение этой инструкции с двумя или тремя операндами.

Это первый пример, который похож на MUL, не считая того, что здесь учитываются знаки.

696E74020080FF imul ebp, dword ptr [esi+74], FF800002 [ESI+74] x FF800002 -> EBP

Это второй пример, в котором три операнда: содержимое ESI+74 умножается на FF800002, а результат сохраняется в EBP. Мы можем посмотреть его в действии с помощью Олли.

Скопируем строку "imul ebp, dword ptr [esi+74], FF800002" в Олли.

Видим, что нажатие кнопки "ASSEMBLE" выдаёт ошибку. Это происходит из-за того, что в Олли к числам, которые начинаются с букв, нужно слева приписывать ноль. Исправляем:

Теперь нажатие на ASSEMBLE проходит без ошибок.

Изменяем значение ESI на 401000, чтобы быть уверенными, что адрес ESI + 74, из котого будет происходить чтение, существует.

Видим в пояснениях:

Здесь говорится, что ESI + 74 - это адрес 401074, содержимым которого является C7000000. Идём в DUMP с помощью "GOTO EXPRESSION 401074".

Это значение, которое, если прочитать его наоборот, равно C7000000, будет умножено на FF800002, а результат данной операции будет сохранён в EBP.

Нажав F7, видим, что EBP стал красным, так как сейчас он содержит результат.

Калькулятор даёт нам следующий результат операции C7000000 * FF800002:

Но поскольку EBP не может вместить его полностью, то в нём остаётся только то, что поместилось, а остальное отбрасывается.

В третьем примере только два операнда, оба из которых перемножаются, а результат сохраняется в первый из них.

Как видим, основной способ для умножения больших чисел - использовать IMUL только с одним операндом, так как в этом случае результат сохраняется в EDX:EAX, то есть он может быть двойного размера, чего нельзя добиться при использовании двух или трёх операндах, соответственно, данную возможность следует применять для маленьких чисел.

DIV (Unsigned Divide) / IDIV (Signed Divide)

Это инструкции, обратные по отношении к MUL и IMUL соответственно.

DIV имеет только один операнд, не учитывает знаки и сохраняет результат в EDX:EAX.

IDIV всегда учитывает знаки. Если используется один операнд, то, как и DIV, сохраняет результат в EDX:EAX, в случае двух - делит один на другой и сохраняет результат в первый, а при трёх операндах делит второй на третий и сохраняет то, что получилось, в первый.

Не думаю, что нужно приводить здесь примеры, похожие на те, что были в разделе, посвящённом MUL и IMUL.

XADD (Обменять и сложить)

Как можно догадаться, это смесь XCHG и ADD, то есть если :

Видим, что ECX равен 1, а EAX - 9. По нажатию на F7 они обменяются значениям, т.е. в EAX попадёт 1, а в ECX - 9, после чего произойдёт сложение.

Видно, что результат затем был сохранён в первый операнд. Регистр ECX содержит число 9, которое находилось до выполнения операции в EAX.

NEG

Назначением данной инструкции является менять знак заданного числа на противоположный, т.е. если у нас есть число 32 в шестнадцатеричной системе, и мы применяем к ней NEG, то результатом будет его отрицательный аналог.

Пример:

Пишем в Олли NEG EAX и заносим в EAX число 32.

После нажатия на F7 в EAX окажется отрицательный вариант числа 32. Смотрим:

Во втором ряду видим, что результатом является -50 в десятеричной системе (это соответствует -32 в шестнадцатеричной).

Если напечатаем в CommandBar'е число -32 в шестнадцатеричной системе, чтобы выяснить, чему оно равно в десятеричной, то получим ответ, что это значение эквивалентно -50, а также пояснение, что это FFFFFFCE.

Так что видим, что NEG меняет знак операнда на обратный.

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

AND

Результатом этой операции над двумя битам является 1, если они оба равны 1, и 0 во всех остальных случаях.

• 1 and 1 = 1

• 1 and 0 = 0

• 0 and 1 = 0

• 0 and 0 = 0

Посмотрим пример в OllyDbg:

Делаем ECX=00001200, а EAX=3500.

Чтобы сделать эту операцию вручную, нужно перевести оба числа в двоичный вид:

• 1200 в двоичном виде будет равно 01001000000000

• 3500 в двоичном виде будет равно 11010100000000

Применим вышеприведённую таблицу операции AND побитно, например, к последней цифре:

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

Если нажмём F7 в Олли, то увидим, что в ECX находится результат 1000, что эквивалентно 01000000000000 в двоичном виде.

OR

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

Получается 1, если один или оба бита равны 1, и 0 во всех остальных случаях.

• 1 or 1 = 1

• 1 or 0 = 1

• 0 or 1 = 1

• 0 or 0 = 0

XOR

Здесь то же самое, только используем таблицу функции XOR.

Получается 1, если один и только один из двух битов равен 1, и 0 во всех остальных случаях.

• 1 xor 1 = 0

• 1 xor 0 = 1

• 0 xor 1 = 1

• 0 xor 0 = 0

NOT

Просто инвертирует значение:

• not 1 = 0

• not 0 = 1

Пример: not 0110 = 1001

Если у нас, например, EAX=1200, что в двоичном виде равно 1001000000000, то все нули превратятся в 1, а все 1 в 0.

После применения NOT получим

что в калькуляторе Windows в шестнадцатеричном виде отобразится как FFFFEDFF.

В Олли до нажатия на F7 сделаем EAX равным 1200.

Нажимаем F7.

Видим, что результат тот же самый.

Ок, здесь мы закончим пятую часть "Введения...". Пока подумайте над тем, что узнали в этой главе, а нам ещё предстоит рассмотреть инструкции сравнения, выходов, call и ret.

Шаг за шагом дорога приведёт нас к цели.

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

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

Далее мы рассмотрим подробно, как работают сравнение и переход.

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

CMP

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

Рассмотрим пример:

Пусть EAX и ECX равны, они будут вычтены друг из друга, значение их не изменится, но результатом операции станет то, что активируется флаг Z. Рассмотрим пример в OllyDbg.

Вводим инструкцию и модифицируем EAX и ECX так, чтобы они были равны.

Нажимаем F7 и видим, что значения EAX и ECX не изменились, но зато стал активным флаг Z, так как результатом вычитания одного операнда от другого был ноль, хотя мы и не можем увидеть его напрямую или сохранить куда-либо.

В реальности нам не важен точный результат вычитания, а только равен ли EAX ECX’у или нет (что чаще).

Хотя мы ещё и не дошли до самих условных переходов, есть две возможности: согласно значению флагов решить, делать переход или не делать. Самый понятный пример, который работает в сочетании с предыдущим – это инструкция JZ, которая совершает переход, если флаг Z активен, т.е. равен ЕДИНИЦЕ, и не совершает, если он не активен, т.е. равен НУЛЮ.

Таким же образом программа может вынести решение относительно двух серийных номеров, один из которых интересует вас на предмет регистрации программы и содержится, скажем, в EAX, а второй находится в EAX и является правильным серийным номером. Программа может определить с помощью CMP, являются ли они равными, и если да (флаг Z будет активным), совершить переход с помощью JZ в ту область, где происходит регистрация. А если введённый вами серийный номер, находящийся в EAX, и правильный в ECX окажутся не равны, то флаг Z будет содержать НОЛЬ, и, соответственно, никакого перехода не произойдёт.

Давайте рассмотрим более конкретные примеры условных переходов.

Точно так же флаг S или флаг знака предоставляет возможность сравнения, является ли первый операнд больше второго или наоборот.

Рассмотрим пример.

Повторим «CMP EAX, ECX», но в этот раз сделаем EAX больше ECX.

Если нажмём F7:

Видим, что флаг Z равен нулю, потому что, как мы уже знаем, значения не равны, а исходя из того, что флаг S тоже равен нулю, можно опеределить, что остаток от EAX-ECX является положительным, то есть EAX больше ECX.

Таким же образом повторим предыдущую операцию, но EAX меньшим чем ECX.

И нажимаем F7.

Здесь видим, что остаток от вычитания ECX от EAX отрицателен, то есть значение в ECX больше, что активизирует флаг S.

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

Здесь сравниваем EAX с содержимым 405000, и, как обычно, окошко с пояснениями нам даёт значение каждого из операндов. В моём случае они следующие:

EAX в данном примере меньше чем содержимое ячейки памяти по адресу 405000, которое равно 1000, что приведёт к отрицательному остатку и активирует флаг S.

Существуют похожие формы

и

В этих случая сравниваются 2 или 1 байт содержимого памяти соответственно.

TEST (Логическое сравнение)

Эта инструкция работает похожим, до некоторой степени, образом, что и CMP – производится определённая операция над двумя значениями, и результат её не сохраняется, однако могут измениться состояния определённых флагов (в данном случае SF, ZF и PF), в следствии чего программа может определить, следует или нет совершать переход. Отличие от предыдущей инструкции заключается в том, что пресловутой операцией является AND.

Это нам рассказал наш друг CAOS в своё туториале по ассемблеру. Рассмотрим несколько примеров, чтобы уяснить данное определение:

Вы спрашиваете зачем сравнивать с самим собой EAX или любой другой регистр? Для того, чтобы определить равен ли EAX нулю. Как это работает?

Пишем в Олли:

Таблица результатов для операции AND следующая:

Результать равен 1, если оба операнда равны 1, и 0 во всех остальных случаях.

Видим, что единственный случай, когда результат равен нулю, это если оба операнда равны нулю (нас не интересуют случаи, когда у операндов разные значения, так как мы сравниваем EAX с самим собой, поэтому они всегда будут равны), соответственно, если у EAX в двоичной форме какой-нибудь из битов равен 1, то результатом операции никак не может быть ноль.

Сделаем EAX равным НУЛЮ:

В OllyDbg это делается очень легко правым кликом мыши на нужном регистре и вводом НУЛЯ.

Теперь нажимаем F7.

Видим, что активен флаг Z, то есть знаем, что результатом операции AND был НОЛЬ, в виду чего он и активировался.

Если повторим эту операцию на EAX со значением, отличающимся от нуля:

Нажимем F7.

И флаг Z не является активным, так как результат отличается от нуля.

Если используем калькулятор, то можем вычислить, что результатом 390 AND 390 будет 390.

В двоичной форме 390 – это 1110010000.

Так как операция AND, если оба операнда равны НУЛЮ в качестве результата также выдаст НОЛЬ, а если они оба равны ЕДИНИЦЕ, то результатом будет НОЛЬ, то видим, что в случае с 390 результат будет 390 и флаг Z не станет активным.

Это была большая часть инструкций сравнения, а теперь настал момент перейти к переходам.

ПЕРЕХОДЫ

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

• JMP – переход

• JE, JZ – переход, если равно нулю

• JNE, JNZ – переход, если не равно нулю

• JS – переход, если знак отрицателен

• JNS – переход, если знак не отрицателен

• JP, JPE – переход, если чётно

• JNP, JOP – переход, если нечётно

• JO – переход, если произошло переполнение

• JNO – переход, если переполнения не произошло

• JB, JNAE – переход, если ниже

• JNB, JAE – переход, если выше или равно

• JBE, JNA – переход, если ниже или равно

• JNBE, JA – переход, если выше

• JL, JNGE – переход, если меньше

• JNL, JGE – переход, если больше или равно

• JLE, JNG – переход, если меньше или равно

• JNLE, JG – переход, если больше

JMP

Это безусловный переход, то есть никакого решения не делается, и всегда происходит переход по заданном адресу. Например, напишем в Олли:

При выполнении этой инструкции программа перейдёт в 401031 и продолжит выполнение уже оттуда.

В Олли есть пара опций, которые позволяют сделать переходы более наглядными.

Если зайдём в OPTIONS-DEBUGGING OPTIONS:

А там во вкладку CPU:

Ставим следующие три галочки:

Видим, что предоставляемая информация стала гораздо нагляднее.

Видим, что теперь OllyDbg показывает нам красной линией откуда и куда совершается переход, в данном случае в 401031.

Если запустим с помощью F7:

Совершается переход и EIP становится равным 401031.

Он равен этому значению, так как EIP содержит адрес инструкции, которая должна быть выполнена.

JE или JZ

И то и другое являются одним и тем же условным переходом, который можно записать двумя разными образами. JZ «прыгает» тогда, когда активен флаг Z.

Напишем в OllyDbg две инструкции, которые делают сравнение и совершают переход, если сравнение оказалось удачным.

Делаем EAX и ECX одинаковыми.

При выполнении сравнения будет произведено вычитание одного параметра из другого, и так как они оба равны, то результат будет равен нулю, а флаг Z станет активным.

Следующая инструкция – это условный переход:

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

Видим, что был совершён переход и EIP сейчас равен 401031.

Повторим пример с EAX, отличным от ECX.

При нажатии на F7, поскольку результат первой инструкции отличен от нуля, флаг Z остаётся неактивным.

И идём в Олли:

Поскольку перехода не произойдёт, то линия перехода отображается серым цветом. Ещё раз нажимаем F7.

Видим, что действительно перехода не произошло, и выполнение программы продолжается в 401004. Примерно таким образом совершаются сравнения во всех программах.

Если повторим предыдущий пример до шага с переходом, но не будем его совершать:

Мы знаем, что флаг Z равен нулю и перехода не будет. Теперь что случится, если кликнем два раза на флаге Z и изменим его значение на 1?

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

Рассмотрим коротко другие флаги на наглядных примерах.

JNE или JNZ

Эта инструкция противоположна предыдущей: переход совершается, если флаг Z неактивен, то есть если результат операции отличен от нуля.

Здесь пишем сравнение и JNZ.

Если EAX и ECX равны, то флаг Z будет активным.

И в отличии от инструкции JZ, совершавшей переход, когда флаг Z был активен, эта, напротив, переходит тогда, когда флаг Z равен нулю, то есть неактивен.

Как можно понять, если EAX отличен от ECX, то результат операции также будет отличен от нуля, что сделает флаг Z неактивным и, в свою очередь, приведёт к переходу.

JS

Как видно из таблицы выше, этот переход выполняется, если результат сравнения отрицателен, то есть если в предыдущем примере EAX меньше чем ECX.

Нажимаем F7:

Флаг S равен 1, поэтому происходит переход.

Видим, что красная линия указывает нам, куда произойдёт переход. В случае, если EAX больше ECX, флаг S будет неактивным и переход JS не сработает.

JNS Этот переход противоположен предыдущему. Переход совершается, когда флаг S равен нулю, то есть, если рассматривать предыдущий пример, когда EAX больше ECX. JP или JPE

Условный переход JP срабатывает, когда активен флаг P, а это происходит, когда результат сравнения является чётным (понимая её так, как это мы рассматривали раньше).

Имеем 20 в EAX и 18 в ECX. Нажимаем F7:

Разность между EAX и ECX равна 2, что в двоичной системе отображается как 10. В этом числе всего лишь одна единица, то есть нечётное их количество, поэтому флаг P неактивен и перехода JPE не происходит.

Теперь заменим значение в ECX на 17 и снова нажмём F7:

Видим, что результат равен 3, что в двоичной системе выглядит как 11 – в этом числе чётное количество единиц, флаг P активен, поэтому переход JPE срабатывает.

JNP или JNPE

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

JO

Срабатывает, когда происходит переполнение, в виду чего активируется флаг O.

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

Нажимем F7:

И срабатывает переход JO, так как из-за произошедшего переполнения активировался флаг O.

JNO Противоположен пердыдущему переходу и срабатывает, когда флаг или равен нулю, то есть переполнения не произошло. JB

Переход происходит, если первый операнд ниже чем второй. Смотрим пример.

Видим, что EAX ниже чем ECX, то есть должен сработать переход. Нажимем F7:

Флаг C активен, так как разность между этими двумя операндами является отрицательным числом, то есть установлен самый значимый бит, на основании чего и делается вывод, что EAX меньше ECX.

JNB Противоположен предыдущему – срабатывает, если флаг C равено нулю, то есть результат сравнения был положителен. В предыдущем примере это произошло бы, если EAX был бы больше ECX. JBE

Это переход если ниже или равно, то есть проверяются два флага – активен ли флаг C, и тогда переход срабатывает, а также активен ли флаг Z, и тогда он тоже срабатывает, то есть если EAX равен ECX или меньше.

Сделаем EAX равными друг другу.

Нажимаем F7.

Видим, что флаг Z активен.

Если EAX меньше ECX:

Нажимаем F7.

В данном случае активируется флаг C, так как результат отрицателен (установлен самый значимый бит), то есть EAX меньше ECX.

В последнем примере EAX больше ECX. Нажимаем F7.

Оба флага Z и C равны нулю, поэтому перехода не происходит.

То есть, JBE срабатывает, если в нашем примере EAX ниже или равен ECX.

JNBE Этот переход противоположен предыдущему и срабатывает, если оба флага Z и C равны нулю. В предыдущем примере переход произошёл бы только в последнем случае. JL

JL – это переход «если меньше», но в несколько другой форме. Здесь проверяется, отличается ли флаг S от флага O, и в этом случае и совершается переход.

Рассмотрим пример, когда EAX и ECX положительны и EAX больше ECX.

При нажатии на F7 перехода не произойдёт, так как EAX больше ECX и результат положителен, поэтому ни флаг O, ни флаг S не будут активны.

Повторим пример при EAX меньше ECX, но оба по-прежнему положительны:

Нажмём F7:

И так как флаги S и или отличаются друг от друга, то срабатывает переход, то есть он происходит, если первый сравниваемый операнд меньше второго и оба положительны. Рассмотрим другой пример.

В данном случае EAX меньше ECX, так как первый является отрицательным. Смотрим, что произойдёт.

Переход совершается прекрасно, а теперь попробуем эти же два значения с переходом JB.

Нажимаем F7.

Видим, что JB не срабатывает, так как JB сравнивает оба значения как если бы они были положительными, то есть считает их беззнаковыми, поэтому если переход должен учитывать знак, то нужно использовать JL – это и есть основное различие между ними.

Как видно, эти условные переходы делятся на две категории: те, в которых знаки операндов учитываются, и те, в которых нет.

Видим, что JA, JB, JBE И JAE считают оба операнда положительными, в то время как JG, JL, JLE и JGE рассматривают их как числа со знаком. JE и JNE работают в обоих случаях.

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

Следующая часть будет также посвящена ассемблеру, в ней будут рассматриваться вызовы (call) и возвраты (ret), а также режимы адресации. Потерпите ещё чуть-чуть, хе-хе.

Несмотря на кажущуюся простоту этих 2х инструкций, многие новички не до конца понимают их суть. Поэтому я их выделил в отдельную главу и хочу ещё раз подчеркнуть, что к данной теме желательно отнестись внимательно - вообще эти инструкции в крэкинге играют очень важную роль. Также желательно при возможности повторить уже пройденный материал.

Итак, давайте снова загрузим крэкми CrueHead'а в OllyDbg.

Правая кнопка мыши на любой строке листинга - "Go to" - Expression".

Во всплывшем диалоге вводим 401245

В окне дизассемблера разворачивается код по только что заданному адресу, где видим CALL, который нам и нужен для практики.

Чтобы выполнить этот CALL, подсвечиваю строчку - правая кнопка мыши - "New origin here". Теперь значение EIP указывает на 401245, а это значит, что следующей инструкцией выполнится наш CALL.

Тут можем проследить как изменяется значение EIP.

Вернёмся же к нашему CALL.

Инструкция CALL передаёт управление заданной процедуре (или просто подпрограмме), адрес которой указан в операнде. Например:

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

В данном случае, после завершения процедуры 401362, управление вернётся на адрес 40124A.

Когда мы имеем дело с инструкцией CALL, OllyDbg предоставляет несколько полезных механизмов трассирования. Если нам интересно продолжить трассировку по внутренностям данной процедуры, можно "нырнуть" в неё клавишей F7. Если же нам хочется просто глянуть на содержимое процедуры, чтобы далее принять решение трассировать её или нет, можно воспользоваться следующей опцией: правая кнопка мыши - "Follow". Наконец, если мы не хотим трассировать данную процедуру, т.к. её содержимое не сулит ничего интересного, можем выполнить её на одном дыхании клавишей F8 и продолжить трассировку по адресу следующей за CALL инструкции.

Итак, чтобы посмотреть содержимое процедуры, не переводя на неё управление, подсвечиваем CALL - правая кнопка мыши - "Follow":

Как видите, значение EIP по-прежнему 401245, т.к. FOLLOW просто подгружает в дизассемблер код по заданному адресу и ждёт дальнейших распоряжений, но ничего при этом не выполняет.

Итак, перед нами код процедуры, которая, естественно, начинается по адресу 401362, в соответствии со значением операнда CALL. Где же конец процедуры? - В данном случае конец приходится на следующую инструкцию RET, которая находится чуть ниже. OllyDbg использует мнемонику RETN вместо RET, что одно и тоже. Эта инструкция завершает процедуру, возвращая управление на адрес 40124A, где находится следующая за CALL инструкция.

Мы теперь знаем как подсмотреть код процедуры не переводя на неё управление. Вернёмся же назад - для этого достаточно нажать на клавишу (-), т.е. "минус". Эта клавиша всегда возвращает нас на один шаг назад в цепочке FOLLOW, ничего при этом не выполняя.

Вот мы снова видим изначальный CALL:

Далее мы погрузимся в процедуру, т.е. переведём на неё управление клавишей F7, но сначала обратите внимание на стек. Это очень важно, т.к. в стеке хранится адрес возврата, который использует инструкция RET, чтобы передать управление обратно.

Предыдущая картинка отображает содержимое стека на моей машине. Возможно, у Вас будут другие значения, но это несущественно.

Нажимаю на F7:

"Погружаемся" в процедуру и видим, что на этот раз, в отличие от предыдущих манипуляций с FOLLOW, значение EIP изменилось - теперь оно равно 401362 и это значит, что мы действительно начали выполнять код процедуры.

Давайте обратим внимание на стек

На предыдущей картинке я выделил жёлтым состояние стека до входа в процедуру. Как видите, в стеке появилась новая ячейка, т.е. при выполнении инструкции CALL в стек добавляется адрес возврата, чтобы RET знала, куда вернуть управление при завершении процедуры.

Значение этой новой ячейки - 40124A - соответствует адресу следующей после CALL инструкции. Если Вы вдруг успели забыть об этом, следующая картинка освежит вашу память:

Причём Olly заботливо добавляет к этой ячейке некоторую дополнительную информацию.

Сообщает нам, что это адрес возврата из 401262 в 40124A.

Т.е. Olly ещё не в курсе, где находится RET, но точно знает, что процедура начинается по адресу 401362 и заканчивается по какому-нибудь адресу, где вероятнее всего находится инструкция RET, которая вернёт управление на адрес 40124A.

Давайте ещё раз нажмём на F7, чтобы выполнить PUSH 0, и посмотрим, как этот ноль добавится в стек, сместив вниз наш адрес возврата.

Процедура может содержать тысячи стековых операций (PUSH, POP и др.), добавляя и удаляя из стека различные значения, но при завершении процедуры в верхушке стека должен снова оказаться адрес возврата. Давайте продолжим выполнять процедуру в пошаговом режиме, нажимая F8, чтобы не трассировать код внутри процедур, пока не доберёмся до инструкции RET.

Вот мы и добрались до завершающей инструкции RET, и в верхушке стека снова находится адрес возврата.

Таким образом, можно заключить, что RET обычно является прямой противоположностью CALL, т.е., если CALL вызывает процедуру, RET возвращает управление обратно. RET также удаляет за ненадобностью из стека адрес возврата.

Жмём F7.

и возвращаемся к адресу 40124A. При этом состояние стека становится таким, каким оно было до вызова процедуры.

Стоит добавить, что RET можно использовать не только для завершения текущего CALL, например:

Сначала PUSH затолкнёт в стек значение 401256. Далее, следующий за ним RET воспримет это значение как адрес возврата из текущего CALL, хотя это вовсе не так, и передаст управление на адрес 401256. Таким образом, этот код отработает точно также как JMP 401256.

Далее мы рассмотрим ещё один пример использования CALL/RET. Перезагружаем крэкми CrueHead'а. "Go to" - "Expression" - вводим 401364.

По этому адресу нажимаем F2, устанавливая таким образом точку останова (об этом мы подробно поговорим позже). Olly прервёт исполнение как только начнёт выполняться инструкция по адресу, на который установлена точка останова.

Адрес выделяется красным цветом и это значит, что точка останова (BREAKPOINT) установлена. Нажимаем на F9 (RUN), чтобы приложение запустилось...

Появилось окно крэкми. Если Вы его не видите, поищите хорошенько через Alt+Tab :)

Приложение ещё не выполнило код, на который мы поставили точку останова. В окне крэкми вызовите меню и выберите опцию "Help" - "Register".

Появилось окно, через которое нужно ввести имя и серийник.

Пишем что угодно.

Нажимаем OK.

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

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

Видим сразу несколько RETURN TO... Видимо, мы находимся внутри процедуры и самый верхний RETURN TO содержит адрес возврата, на который передаст управление ближайший RET. Этот адрес, вероятно, окажется на верхушке стека, перед выполнением RET и управление будет передано на адрес 40124A.

Если присмотреться, можно заметить также, что перед нами уже знакомый код. Но на этот раз он вызван не нами, а в ходе нормального выполнения программы.

Жмём на F8, чтобы добраться до RET, как и раньше. Только в этот раз при выполнении последнего CALL сразу перед RET должно появиться сообщение, которое нужно закрыть, чтобы продолжить трассирование.

Закрываем его.

Вот мы и добрались до инструкции RET и верхушка стека теперь содержит адрес возврата, как мы и предполагали.

В прошлый раз мы выполнили процедуру самостоятельно, принудительно изменив значение EIP. В этот раз мы попали в код процедуры в следствии нормального выполнения программы. Достаточно снова нажать на F9, чтобы программа продолжила выполняться как ни в чём не бывало.

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

Рассмотрим ещё один закрепляющий пример. Для этого нужно перезагрузить крэкми в отладчике, сразу нажать на клавишу пробела и ввести следующую инструкцию: CALL 401245.

Готово. Далее воспользуемся опцией FOLLOW, чтобы попасть во внутрь функции.

Процедура начинается по адресу 401245 и заканчивается по адресу 401288 (где находится инструкция RETN 10, которая немного отличается от знакомого нам уже RET, но об этом позже). Обратите внимание на вложенный CALL (первая инструкция процедуры является вызовом другой процедуры).

Нажмите МИНУС, чтобы выйти из FOLLOW. Теперь нажмите F7, чтобы войти в процедуру, фактически передав на неё управление.

Вот мы и внутри, о чём свидетельствует значение EIP: оно указывает на адрес 401245.

В верхушке стека хранится адрес возврата к следующей за нашим свежевписанным CALL инструкции.

Адрес возврата имеется, но OllyDbg не выделил его как RETURN TO 401005. Чтобы понять почему он в этот раз не проявил сообразительность, нужно принять во внимание, что мы вписали CALL после того, как OllyDbg выполнил предварительный анализ кода.

Представьте себе, что OllyDbg - это Чапаев, пересекающий реку верхом :-) Прямо посреди реки мы модифицируем его скакуна, чем, мягко говоря, дезориентируем Василия Ивановича. Точно также в растерянность впадает и OllyDbg.

(В общем, OllyDbg в воде не тонет, но пословица тут не при чём - прим. переводчика ;-) )

Чтоб исправить ситуацию, достаточно нажать на правую кнопку мыши в любом месте окна дизассемблера - "Analysis" - "Analyse code". Таким образом, отладчик снова пробежится по коду анализатором и скорректирует подсказки в стековом кадре.

Теперь адрес возврата в верхушке стека корректно распознан анализатором:

Адрес возврата в данном случае обозначен относительно стартовой точки программы:

MODULE ENTRY POINT + 5 = 401000 + 5 = 4010005.

В общем, не забывайте запускать анализатор после внесения изменений в код программы (это касается также изменений кода самой программой). Иногда анализ кода может оказаться ошибочным и его следует сбросить опцией "Analysis" - "Remove analysis from module".

Давайте вернёмся к нашему примеру.

Жмём F7 и "погружаемся" в следующий CALL.

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

Если Вы попадёте в подобную ситуацию, например, в результате срабатывания точки останова, не имея представления о ходе выполнения программы до останова, взглянув на стек можете сориентироваться:

Ниже в окне дизассемблера виден RET, что наталкивает на мысль о том, что мы находимся внутри процедуры.

Смотрим в стек, чтобы удостовериться:

Сверху вниз первый RETURN TO указывает на возможный адрес возврата из текущей процедуры. В данном конкретном случае - это адрес 40124A.

К тому же, ниже есть ещё один RETURN TO, а это может значить, что текущая процедура была вызвана из другой процедуры.

Второй RETURN TO говорит нам, что в конечном итоге программа должна вернуться к адресу 401005 и непосредственно над этим адресом находится CALL, который инициировал всю эту цепочку вызовов. Кстати, вот он:

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

Если что-то непонятно - спрашивайте. До следующей главы!

Циклы

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

Инициализируем счётчик повторов значением 15h. Далее следует сам цикл:

Счётчик уменьшается на 1 при каждом повторе.

Далее следуют произвольные инструкции, которые мы пытаемся зациклить - это тело цикла.

В конце нужно добавить проверку на равенство нулю или любому другому условию завершения цикла:

При первой проверке на равенство нулю, в счётчике будет значение 14h, ведь мы уже успели 1 раз выполнить DEC ECX. Т.к. 14h не равно 0, цикл повторится снова и снова, пока значение счётчика не достигнет значения 0.

Давайте перепишем наш цикл в более компактной форме с целью оптимизации по размеру:

Можно придумать ещё более компактные версии циклов, но пока ограничимся последней. Давайте впишем этот код в OllyDbg:

Жёлтым выделен код цикла, который будет повторяться пока значение ECX не достигнет нуля. Тело цикла содержит несколько инструкций NOP.

Давайте потрассируем код цикла, чтобы воочию убедиться в его функциональности. Нажимаем на F7 - видим как обнуляется счётчик ECX.

Ещё раз F7 - прибавляем к счётчику 15h, чем и задаём желаемое количество повторов.

Далее нажимаем на F7 пока не выполнится инструкция DEC ECX, которая сократит значение нашего счётчика до 14h.

Продолжаем трассировать до инструкции TEST ECX, ECX. Что делает эта инструкция в данном случае? - Правильно, проверяет значение счётчика на предмет равенства нулю.

Т.к. счётчик ещё не равен нулю, флаг Z не устанавливается и, следовательно, выполняется условный переход JNZ - он передаёт управление на адрес 401007. Далее счётчик снова уменьшается - на этот раз до 13h. Продолжаем трассировать пока он не достигнет значения 0.

При нулевом значении счётчика, сравнение на ноль устанавливает флаг Z. Поэтому JNZ более не выполняется.

Помните, раньше мы использовали инструкцию JZ, которая осуществляла переход при установленном флаге Z? JNZ работает с точностью до наоборот - переход осуществляется при сброшенном флаге Z.

Видите серую стрелочку? - это значит, что переход не будет осуществлён. Повторное нажатие на F7 выводит нас из цикла.

Мы рассмотрели простейший пример цикла с использованием уже знакомых нам инструкций. Существуют ещё и специальные инструкции для реализации циклов. Давайте рассмотрим и их.

LOOP

Инструкция LOOP берёт на себя уменьшение значения счётчика ECX, проверку на равенство нулю и переход по заданному адресу - всё в одном флаконе. (К сожалению, на большинстве современных процессоров данная инструкция отличается более низкой скоростью, чем аналог с DEC и JNZ - прим. пер.)

Подсвечиваем инструкцию DEC ECX - осуществляем правый клик мышью - Binary - Fill with NOPs. Аналогично поступаем с инструкциями TEST ECX,ECX и JNZ 401007. Все 3 инструкции можно заменить одной - LOOP 401007.

Подсвечиваем первую строчку (401000) - осуществляем правый клик мышью - New origin here. Теперь мы готовы опробовать наш новый цикл, использующий инструкцию LOOP.

Нажимаем F7 - снова видим как счётчик ECX сначала инициализируется значением 0, потом ему присваивается значение 15h. Продолжаем трассировать пока не достигнем инструкцию LOOP.

Также как и раньше, осуществляется переход на адрес 401007, т.к. счётчик ещё не равен нулю. Замечаем, что счётчик уменьшился на 1 - теперь в ECX хранится значение 14h.

Продолжаем трассировать. Когда счётчик, наконец, достигает нуля, цикл более не будет повторяться.

Существуют некоторые вариации инструкции LOOP:

• LOOPZ, LOOPE Цикл повторяется пока флаг Z установлен

• LOOPNZ, LOOPNE Цикл повторяется пока флаг Z сброшен

Обе вариации работают как обычный LOOP, т.е. повторяют тело цикла пока счётчик не достигнет нуля, уменьшая на 1 значение счётчика при каждом повторе. В добавок, LOOPZ и LOOPNZ ещё проверяют значение флага Z и прерывают цикл если Z сброшен или установлен соответственно. Таким образом, цикл можно прервать досрочно (до того как ECX достигнет нуля), используя флаг Z.

Обратите внимание на поведение цикла в том случае, если счётчик изначально равен нулю. - прим. пер.

Цепочечные инструкции Далее рассмотрим основные инструкции, относящиеся к категории цепочечных, т.е. позволяющие обрабатывать сразу цепочки байт. MOVS

Данная инструкция копирует данные из одного адреса в другой. Адрес источника хранится в регистре ESI, адрес приёмника - в EDI. Инструкция не нуждается в явном указании параметров, но OllyDbg дизассемблирует её как MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI] для наглядности. Вот как это выглядит:

Предварительно инициализируем ESI адресом ячейки, содержимое которой нужно скопировать (источник), и EDI - адресом ячейки, в которую нужно осуществить копирование (проёмник).

Давайте посмотрим содержимое обоих ячеек в окне дампа непосредственно перед копированием.

В окне дампа можно задать Go to - Expression = 40366C. Есть более простой способ: Follow in dump - Immediate constant, как показано ниже:

В дампе выделено содержимое ячейки, адрес которой указан в источнике (ESI).

А теперь посмотрим куда указывает EDI:

Это приёмник - сюда будет скопировано содержимое ячейки-источника.

Нажимаем F7 пока не выполнится MOVS - в приёмнике теперь находятся те самые 4 байта.

MOVS копирует 4x-байтные значения, т.е. DWORD, из-за чего этой инструкции соответствует ещё одна мнемоника - MOVSD. Существуют ещё инструкции MOVSW и MOVSB, копирующие 2 байта (WORD) и 1 байт (BYTE) соответственно.

Обратите внимание как изменяются значения ESI и EDI при копировании, в зависимости от флага D - прим. пер.

REP

Это префикс, который можно использовать перед некоторыми инструкциями, в частности MOVS. Данный префикс указывает, что текущую инструкцию нужно выполнить ECX количество раз. Фактически счётчик ECX уменьшается при каждом повторе, как и в обычном цикле. Таким образом, REP MOVS копирует уже не строго 4 байта, а массив размером 4 * ECX байт, ведь каждый раз указатели ESI и EDI сами увеличиваются на 4 (или уменьшаются, в зависимости от флага D - прим. пер). Полезная фишка, не так ли?

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

Давайте немного подправим наш предыдущий пример: добавим префикс REP и проинициализируем ECX.

Адрес источника теперь будет 40365C (всего лишь для наглядности), а приёмника - тот же, что и раньше, т.е. 40369C. Возвращаемся к первой строчке кода дежурным New origin here и трассируем до REP MOVS.

Обратите внимание на подсказку в OllyDbg - там отображаются адреса источника и проёмника, содержимое начальных ячеек и другая полезная информация. Нажимаем F7.

Как видите, первые 4 байта были успешно скопированы, но мы всё ещё находимся на REP, ведь цикл должен выполняться пока ECX не достигнет нуля. На данном этапе в ECX уже хранится значение 3, а указатели ESI и EDI уже увеличились на 4, указывая таким образом на следующие 4 байта, которые будут скопированы как только мы снова нажмём F7.

Нажимаем F7.

Вот и следующие 4 байта были удачно перемещены и счётчик ECX уже равен 2.

Ещё раз F7 - ECX равен 1.

И ещё раз.

Всё, цикл завершился, т.к. счётчик достиг нуля.

Подведём итог: инструкция MOVS выполнилась 4 раза, благодаря префиксу REP, тем самым переместив цепочку из 16 байт из одного массива в другой.

Имейте в виду, что MOVS, также как и обычная MOV, не может записать данные по адресу, принадлежащему странице не имеющей прав на запись. В таком случае будет вызвано исключение.

Кроме REP есть ещё 2 производных префикса REPE/REPZ и REPNE/REPNZ, которые позволяют прервать цикл досрочно по флагу Z. Т.к. MOVS никак не влияет на флаг Z, использовать REPE/REPZ или REPNE/REPNZ совместно с MOVS не имеет особого смысла, но есть и другие инструкции, которые также поддерживают префиксы повторения и, в добавок, влияют на флаги. Например, CMPS и SCAS являются таковыми. Одну из них мы рассмотрим чуть позже.

LODS

Данная инструкция загружает (от англ. LOAD) данные из источника (куда, как обычно, указывает ESI) в аккумулятор.

OllyDbg в своём репертуаре: дизассемблирует LODS как LODS DWORD PTR DS:[ESI].

Если кому-то лень посмотреть на значение ESI на панели регистров, OllyDbg заботливо дублирует его в окне подсказок.

Что у нас в дампе?

Эти 4 байта будут загружены в аккумулятор (EAX). Нажимаем F7.

Свершилось! EAX действительно содержит те самые 4 байта.

Префикс REP можно применить и перед инструкцией LODS для автоповтора, пока счётчик ECX не достигнет нуля.

При выполнении цикла REP LODS, в окне подсказки оказываются текущие значения ECX, ESI и содержимое ячеек памяти, которые будут загружены в аккумулятор при следующем повторе.

Нажимаем F7.

ECX теперь имеет значение 3 и адрес в ESI увеличился на 4 - теперь он указывает на следующие 4 байта, которые будут загружены в EAX.

Есть ещё инструкции LODSW и LODSB для загрузки 2-байтовых (WORD) и 1-байтных (BYTE) значений соответственно.

STOS

Сохраняет (от англ. STORE) значение аккумулятора по адресу приёмника EDI.

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

Вот результат в дампе:

Также как и в предыдущем случае, можно использовать префикс REP для автоповторения и существуют 2-байтовая и 1-байтная версии: STOSW и STOSB.

CMPS

Осуществляет сравнение ячеек, указанных в источнике (ESI) и приёмнике (EDI).

OllyDbg дизассемблирует данную инструкцию как CMPS DWORD PTR DS:[ESI],DWORD PTR ES:[EDI].

В окне подсказки отображаются значения, подлежащие сравнению:

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

Т.к. операция сравнения влияет на состояние флага Z, можно использовать префикс REPE или REPZ для цепочечного сравнения до тех пор пока не истощится счётчик ECX или флаг Z не окажется сброшен.

От предыдущих примеров по адресам 40365C и 40369C осталось то, что видим в дампе.

Инициализируем ECX = 10h. При использовании префикса REPE, цикл прервётся когда ECX станет равен нулю или же по состоянию флага Z - любое из этих условий приведёт к завершению цикла.

Трассируем до строчки с REPE. Значения в обоих ячейках оказываются равны, что приводит к установке флага Z.

Установленный флаг Z сигнализирует REPE, что пока не нужно прерывать цикл. Нажимаем F7.

Продолжаем нажимать F7 до тех пор, пока операнды не окажутся разными. В данном случае это должно произойти до того как истощится счётчик ECX. Ага, вот:

Последующее нажатие на F7 сбрасывает флаг Z и цикл прерывается.

Если бы все 16 двойных слов оказались равными в обоих цепочках, цикл завершился бы по условию ECX = 0, а не раньше.

Ранее упоминался префикс REPNZ, который тоже применим к CMPS и позволяет прервать цикл досрочно, но условие в этом случае противоположно только что рассмотренному REPE/REPZ.

Мы уже изучили основную массу наиболее полезных инструкций, за исключением, пожалуй, только инструкций FPU (для операций над дробными числами), которые мы рассмотрим позже. Не лишним будет повторить пройденный материал, если у Вас остались какие-то пробелы.

СПОСОБЫ АДРЕСАЦИИ

Прямая адресация

Это самый простой способ - адрес явно указывается в одном из операндов инструкции. Например:

Не нужно производить какие-либо вычисления для разрешения адреса, т.к. его значение указано открытым текстом в листинге.

Косвенная адресация

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

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

Чтобы было нагляднее, давайте снова воспользуемся крэкми Cruehead'а. Загружаем его в отладчик.

Подмечаем пример косвенной адресации: PUSH [ebp+8]

Т.к. мы всё ещё находимся на точке входа (Entry Point), мы не можем заранее узнать значение регистра EBP к моменту выполнения того самого PUSH'а. Поэтому, нам не известно пока ещё что именно попадёт в стек. Давайте выделим данный PUSH (он находится по адресу 401009) и нажмём F2, чтобы повесить на него точку останова (бряк).

Потом нажимаем F9 (RUN) - крэкми запускается и вскоре останавливается там, где мы установили бряк.

В окне подсказки высвечивается настоящий адрес EBP+8 = 12FFF8. Кстати, у Вас адрес может отличаться - это свойственно стековым адресам! Значение EBP в данный момент у меня равно 12FFF0, на основании чего и получилось, что EBP+8 = 12FFF8.

Теперь давайте посмотрим, что хранится в дампе по адресу EBP+8 : Go to - Expression = EBP+8

И что мы там видим?

Это значение будет помещено в стек. Нажимаем F7 - так и есть.

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

Существуют другие способы адресации, но мы их частично уже рассмотрели в примерах. На данном этапе мне нечего добавить.

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

Перевод последнего абзаца получился немного вольным, но смысл сохранился. Особенно хочется подчеркнуть, что автор не спроста упоминает о серьёзных книгах - учебниках по ассемблеру, архитектуре ПК, операционных систем и т.д. Многие теоретические основы, касающиеся ассемблера вообще и крэкинга в частности, не попадают в туториалы и только лишь книги помогают до конца разобраться в тех или иных темах.

Экспериментировать мы будем, естественно, с уже знакомым нам крэкми Cruehead'а, но не ограничимся рассмотрением различных способов взлома этого несложного крэкми - по ходу мы постараемся изучить стандартные приёмы, применимые в дальнейшем к более "продвинутым" жертвам.

Итак, давайте загрузим крэкми в отладчик.

На примере данного крекми можно рассмотреть несколько общих понятий.

Точка Входа (Entry Point). Адрес инструкции, с которой стартует программа. Не путать с понятием OEP (Original Entry Point), которое мы рассмотрим чуть позже. При загрузке приложения в OllyDbg, отладчик останавливается на точке входа, анализирует код и ждёт дальнейших инструкций от пользователя.

-

В данном случае точка входа соответствует адресу 401000. Обычно в строке состояния выводится причина, по которой остановлен отладчик. Сейчас там находится сообщение о том, что мы находимся на точке входа:

-

Почти все программы на старте останавливаются на точке входа. Есть такие, которые не останавливаются, т.к. используют способы обхода отладчика. Об этих способах мы поговорим позже. Пока что примите к сведению существование подобных приёмов антиотладки.

Давайте, заодно, рассмотрим понятие DLL (динамические библиотеки) и экспортируемые ими функции.

-

Обратите внимание на выделенную инструкцию. Вместо адреса, вроде CALL 401020, в данном случае указано имя внешней функции:

В крайнем правом столбике выводится какая-то дополнительная информация, но что представляет собой LoadIconA?

Операционная система Windows поддерживает так называемые динамические библиотеки (файлы с расширением DLL), которые имеют тотже формат, что и обычные исполнимые файлы EXE. В динамических библиотеках содержатся функции, которые могут быть использованы другими исполнимыми файлами (EXE и DLL). Вместо статического копирования одной и тойже функции в несколько экзешников, её можно поместить в DLL, а в экзешниках указать ссылки на эту DLL. Если обьём подобных функций велик, получается неплохая экономия на размере экзешников и, что более существенно, расходуемой памяти. Базовые функции для работы с файлами, динамической памятью, процессами и потоками, графикой, звуком, сетью и т.д. и т.п. реализованы в стандартных динамических библиотеках. LoadIconA как раз и является одной из стандартных функций, реализованной в одной из стандартных библиотек - в USER32.DLL. Стандартные функции ещё называют API.

Давайте рассмотрим пример другой API'шной функции - MessageBoxA.

В окне Command Bar вводим: ? MessageBoxA

-

Получаем короткий отчёт, в котором первым делом указан настоящий адрес данной функции. Давайте пройдём по этому адресу, т.е. воспользуемся командой Go to - Expression и введём тот адрес, что выдал нам Command Bar.

-

Вводим тот адрес, что выдал Command Bar (у Вас этот адрес может быть другим!)

-

Если у Вас установлена Windows 9x, этот фокус не сработает, о чём мы подробнее поговорим ниже.

-

Сразу видим, что функция принадлежит USER32.DLL, но мы это уже знали, ведь имя DLL обычно указывается вместе с именем функции в дизассемблере (вроде CALL USER32.MessageBoxA). Ещё можно заметить, что MessageBoxA - это обычная функция, которая начинается по текущему адресу и завершается инструкцией RET. Код данной функции находится в библиотеке, а не в экзешнике, что позволяет сэкономить на размере и упрощает работу крэкера :)

Чтоб вернуться к текущей инструкции, достаточно нажать МИНУС. В окне Go to - Expression можно было прямо ввести MessageBoxA.

-

-

Вот, мы снова оказались внутри функции MessageBoxA из библиотеки USER32.DLL.

В имени функции важно правильно указывать строчные и прописные буквы (MessageBoxA и messageboxa - разные имена). Как же узнать правильный регистр той или иной буквы?

Нажимаем МИНУС - возвращаемся к точке входа.

-

Правая кнопка мыши в листинге: Search for - Name (label) in current module. Получаем полный список имён API'шных функций, задействованных в данном экзешнике.

-

Не нужно перечитывать весь список - чтобы найти нужную функцию, достаточно начать набирать её имя. Нажимаем M:

-

Курсор позиционируется на первой функции, имя которой начинается на M.

-

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

-

Правая кнопка мыши по имени функции вызывает меню со следующими опциями:

-

Опция Follow import in Disassembler подгружает эту функцию в дизассемблер - это ещё один способ попасть внутрь API'шной функции.

-

Часто новички ошибочно задают поиск символов (Search for - Name (lable) in current module), находясь при этом внутри какой-либо внешней функции. К примеру, если мы воспользуемся данной опцией внутри функции MessageBoxA, мы получим список имён функций, которые импортирует библиотека USER32.DLL, а вовсе не подопытный эзешник. В меню чётко сказано, что поиск осуществляется в текущем модуле (current module), а текущем в данном случае окажется USER32, ведь функция MessageBoxA находится именно в нём.

-

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

-

Даже если мы просто заглянули во внешнюю функцию в дизассемблере, а не передали управление в отладчике, т.е. функция даже не выполняется ещё, текущим модулем всё равно окажется библиотека, в которой находится внешняя функция. В таком случае нужно понажимать на МИНУС пока Вы не окажитесь в "основном" модуле, чтобы воспользоваться такими опциями как Search for - Names и т.п.

Windows NT: 2000, XP и 2003

Дальнейшее обсуждение касается операционных систем NT: 2000, XP и 2003. Если у Вас мастдай (пардон, тут автор использовал термин Windows 95/98 - прим. пер.), смею порекомендовать перейти на любую из вышеперечисленных осей, т.к. на NT OllyDbg обладает бульшими возможностями (и глючит меньше - опять прим. пер.) Если такой возможности нет, можете пропустить дальнейшее обсуждение и перейти сразу к "Приложение. Windows 9x"

-

В перечне API'шных функций, которые использует крэкми, есть ещё одна полезная опция в контекстном меню: Toggle breakpoint on import. Данная опция позволяет установить точку останова на вызове функции API.

Точку останова на вызовах конкретной API'шной функции можно установить и через Command Bar:

В отличие от bpx, bp ставит точку останова на первой инструкции внутри заданной функции, а не на самих инструкциях вызова (call или jmp) в текущем модуле. Давайте снова зайдём в функцию MessageBoxA (любым из вышеописанных способов) и удостоверимся, что на первой инструкции данной функции появилась точка останова. Так и есть:

-

Таким образом, при вызове функции MessageBoxA, должна сработать точка останова. Давайте нажмём F9, чтобы запустить крэкми.

-

Появилось главное окно крэкми. В меню выбираем Help - Register:

-

Вводим произвольные данные в поля Name и Serial; нажимаем OK. В этот момент должен произойти вызов функции MessageBoxA, который должна зафиксировать наша точка останова... Ага, отладчик прервал выполнение! В правом нижнем углу светится надпись Paused (будто нам и так непонятно, что процесс остановлен - прим. пер.).

-

Левее указана причина, по которой произошла остановка.

-

Там написано: "Breakpoint at USER32.MessageBoxA", что значит "Точка останова на USER32.MessageBoxA". Наша точка останова сработала.

-

В момент вызова функции можно посмотреть на значения аргументов данной функции. Аргументы API'шных функций обычно передаются через стек справа налево, согласно соглашению stdcall. Давайте рассмотрим их внимательно.

В самом верху стека хранится адрес возврата. В данном случае - 4013C1.

-

Когда мы проходили инструкции CALL и RET в подготовительной части этого цикла (Глава 7), мы имели возможность убедиться, что при вызове любой подпрограммы (т.е. функции) верхушка стека содержит адрес возврата - адрес, на который перейдёт управление, после завершения функции. В данном случае, после завершения MessageBoxA, управление перейдёт на адрес 4013C1.

Далее (т.е. ниже) идут аргументы функции. MessageBoxA принимает 4 аргумента (можете посмотреть описание функции API MessageBox в MSDN, чтобы убедиться): дескриптор родительского окна, текст сообщения, текст заголовка и стиль.

Текст сообщения - "No luck there, mate!" - констатирует, что Вы не угадали правильные параметры регистрации :)

Вот-вот вылезет роковое сообщение...

-

Чтобы убедиться, что текущий вызов MessageBoxA - это тот самый MessageBox, что уведомляет нас о неправильно набранном серийнике, если у Вас есть сомнения... Давайте изолируем текущий вызов, поставив точку останова на инструкции RETN 10h, которую можно найти чуть ниже. Адрес инструкции возврата у Вас, возможно, будет отличаться, но, в любом случае, это должен быть первый RET внутри функции.

-

Нажимаем F9.

-

Окно MessageBox появилось на экране. Текст заголовка и сообщения соответствует параметрам функции, которые мы только что перехватили: "Lo luck!" и "No luck there, mate!". Серийник не подошёл :)

Нажимаем "Да" - срабатывает точка останова на RETN 10h.

-

Таким образом, можно заключить, что сообщение выскочило в процессе выполнения функции MessageBoxA.

Чем отличается RETN 10h от обычного RET? Обычный RET просто вернул бы управление на адрес возврата - 4013C1.

-

Из стека извлекается адрес возврата. Указатель на верхушку стека перемещается на 4 байта вниз (точнее, в сторону старших адресов). Таким образом, ESP увеличивается на 4 в результате выполнения инструкции RET. В случае с RET 10h, в добавок к тому, что делает обычный RET, ESP увеличивается ещё на 10h. В общей сложности, к значению ESP прибавляется 10h + 4 = 14h = 20. Давайте проверим: нажимаем F7.

Дальнейшее обсуждение касается обоих семейств Windows: 9x и NT.

-

Вот мы и вернулись из API-функции обратно в код крэкми. Обратите внимание, что указатель верхушки стека сдвинулся на 20 байт вниз, как и следовало ожидать, т.е. RET N не просто извлекает из стека адрес возврата, но и очищает аргументы, переданные в функцию, как того требует соглашение stdcall.

-

В данный момент крэкми уже точно знает, что серийник не верен и даже успел нам об этом сообщить. На данном этапе уже поздно что-либо предпринимать. Нажимаем F9.

-

-

Снова срабатывает точка останова. Оказывается, крэкми решил снова вывести сообщение о неправильном серийнике, будто мы успели забыть, что серийник не подошёл :)

-

Адрес возврата на этот раз указывает на 40137D. Давайте посмотрим, что за код находится по этому адресу. Для этого можно воспользоваться опцией Go to - Expression: 40137D. Или прямо по правому щелчку в верхней ячейке стека - Follow in Disassembler.

-

Сразу над строчкой по адресу возврата (40137D) находится инструкция CALL, которая вызвала функцию MessageBox (401378).

-

Чуть выше виден другой MessageBox, но с совершенно другим текстом: Great work, mate! Похоже, что это сообщение выскакивает, если серийник оказывается правильным :) Для начала было бы неплохо попасть на тот другой MessageBox, вместо того, что вот-вот покажется на экране.

-

Предварительный анализ проделанный отладчиком показывает, что данный код входит в состав функции, о чём свидетельствует жирная скобка в колонке с машинным кодом. Таких функций несколько: одна начинается по адресу 401362 и содержит сообщение "No luck...", другая - "Great work..." и начинается по адресу 40134D.

Если выделить первую строчку функции "No luck..." (по адресу 401362), в окне подсказки покажется следующая информация:

-

Отладчик в курсе откуда вызывается данная функция, но так бывает только с прямыми вызовами! Щелчёк правой кнопкой мыши - Go to - CALL from 401245.

-

-

Занятненько... Перед нами типичный код сравнения некоторого значения, в результате которого вызывается одна из тех двух функций с сообщениями: "No luck..." и "Great work...". Такое нельзя пропускать! Ставим точку останова на условный переход.

-

За одно, убираем точки останова на MessageBox. Это можно сделать через окно [B], т.е. Breakpoints:

-

-

Правая кнопка мыши - Remove. Таким образом убираем обе точки останова на MessageBox и оставляем только свежепоставленную точку на том подозрительном условном переходе.

-

Командуем Run (F9), принимаем сообщение "No luck...", которое мы только что трассировали. Снова вводим имя и серийник (используйте те же, что и на снимке).

-

Нажимаем OK.

-

Переход не осуществляется, т.к. предварительное сравнение EAX и EBX обернулось неравенством. Таким образом, выполняется вызов CALL 401362 - там нехорошее сообщение, если кто-то уже забыл. Можете нажать правую кнопку мыши - Follow и освежить память.

-

А что будет, если повлиять на условие перехода, изменив значение флага Z? Двойной щелчёк по флагу в окне регистров меняет его текущее состояние на протовоположное.

-

Установленный флаг Z означает, что EAX = EBX, т.е. разность EAX - EBX равна нулю. Переход осуществляется.

-

Теперь вызовется другая функция. Смотрим через Follow:

-

Нажимаем Run (F9) :)))

-

Значит, то сравнение является ключевым моментом в проверке правильности серийника. Если значения EAX и EBX равны, выскакивает "хорошее" сообщение, иначе выводится "Lo luck...". Раньше мы заметили, что "нехорошие" сообщения в коде имеются в двух экземплярах, но в последний раз выскочило только одно из них. Когда крэкми замечает, что в имени есть цифры (в ricnar456 как раз они есть), сначала выводится одно сообщение, а потом, после ключевого сравнения, выводится ещё одно. Давайте проверим ещё раз.

-

Вводим имя, содержащее цифры. Нажимаем OK.

-

Появляется сообщение о неправильном серийнике и уже ПОСЛЕ этого срабатывает точка останова на условном переходе!

-

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

-

Адрес возврата соответствовал 4013C1.

-

В окне дизассемблера выделена функция (см. жирную скобку), начинающаяся по адресу 40137E и заканчивающаяся по адресу 4013C1: там находится завершающий RET сразу после вызова MessageBox.

Обратите внимание, что по адресу 4013AC есть стрелочка (>), а это значит, что данный адрес используется в каком-то прямом переходе. Давайте выделим эту строчку, чтобы узнать где находится этот переход.

-

Перед нами ещё одно сравнение и условный переход, который приводит к отображению нехорошего сообщения. Давайте поставим точку останова в этом месте.

-

Снова пускаем приложение (RUN); принимаем сообщение; опять вводим наши дежурные данные регистрации (имя содержащее цифры!) и опять нажимаем OK.

-

Данный код проверяет все буквы в имени пользователя. Злосчастный переход осуществляется, как только встретится цифра. При каждом прохождении цикла срабатывает точка останова. Нажмите F9 - остановка произойдёт уже на 2й букве.

На седьмом прохождении цикла (первая цифра в имени ricnar456 - это ‘4’ и занимает 7ую позицию) переход будет осуществлён, но мы этому воспрепятствуем :)

-

-

Условный переход JB осуществляется в зависимости от состояния флага C. Делаем двойной щелчёк по этому флагу, чтобы изменить его состояние.

-

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

-

Далее мы попадаем на сравнение EAX и EBX, где нужно повлиять на флаг Z, как в прошлый раз, чтобы переход осуществился.

-

Нажимаем F9.

-

Не будем же мы всё время ручками менять флаги C и Z?! Настало время рассмотреть каким образом это дело можно зафиксировать, чтобы крэкми безропотно принимал любой серийник, причём вне отладчика.

Выделяем первый условный переход (где мы поставили точку останова).

-

Чтоб этот переход не выполнялся никогда, независимо от состояния флага C, его можно просто и грубо забить инструкциями NOP. Нажимаем на данном переходе пробел и вводим NOP.

-

-

Точку останова уже можно убрать. Для этого достаточно нажать F2.

-

Идём ко второму ключевому условному переходу.

-

В данном случае нам нужно, чтобы переход всегда выполнялся. Для этого его можно сделать безусловным, т.е. поменять JE на JMP.

-

-

Давайте снимем и эту точку останова (F2). Пока ещё не выходим из OllyDbg! Чтобы опробовать в свободном полёте наши достижения, нажимаем F9.

-

Нажимаем OK.

-

Все изменения проделанные через опцию Assemble (пробел) улетучиваются при закрытии программы в отладчике. Эти изменения осуществляются в памяти и никак не влияют на оригинальный образ в экзешнике. Чтобы применить изменения к образу в экзешнике, делаем следующие манипуляции:

-

Правый щелчёк в любом месте листинга - Copy to executable - All modifications. Далее выводится следующий запрос:

-

Выбираем опцию Copy all чтобы перенести все изменения (в данном случае ими являются двойной NOP и один JMP).

-

Открывается новое окно, в котором нужно опять сделать правый щелчёк - Save file.

-

-

Сохраняем файл под НОВЫМ именем (старый экзешник нам ещё пригодится, да и перезаписать его всё равно не получится, т.к. он всё ещё загружен операционной системой). Назовём новый экзешник CRACKME2.EXE.

-

Вот, теперь можно, наконец, закрыть OllyDbg.

-

Запускаем новую версию крэкми (уже вне отладчика) и проверяем, что регистрация проходит успешно при указании любого серийника.

- Задаём Help - Register:

- Нажимаем OK.

-

Вот мы и пропатчили крэкми! Но этого мало - в дальнейшем попробуем реверсировать полностью алгоритм проверки серийника, чтобы получить настоящие регистрационные данные, без использования патча. Но для этого надо ещё многому научиться.

Приложение. Windows 9x

В мастдае возможности отладчика ограничены. К примеру, нельзя ставить точки останова прямо на вызовы API-функций, как было показано на примере MessageBox в NT/XP. При выполнении поиска API-функций по импорту:

-

Получаем аналогичный список импортируемых символов, но опция Toggle breakpoint on import не будет доступна, т.к. 9x не позволяет ставить точки останова прямо на внешние функции.

-

В остальном, контекстное меню будет сходным с полнофункциональным вариантом в NT.

-

Таким образом, вызовы API-функций могут идти в обход точек останова. Достаточно вызвать функцию косвенным образом, чтобы анализатор не смог его автоматически засечь, и точка останова уже не сработает. Досадное ограничение, в общем.

Вместо одной точки останова на начало функции MessageBox в данном случае Вам придётся поставить 3 точки останова (F2): по одной на каждый вызов MessageBox, которые выводятся в списке внешних символов.

-

Нажимаем Run (F9); выбираем опцию Help - Register; вводим следующие регистрационные данные:

-

Нажимаем OK - срабатывает одна из точек останова.

-

В NT/XP в этом месте мы ставили ещё одну точку останова на инструкции RET, внутри функции MessageBox. В 9х мы это не можем сделать, т.к. внутрь функции нас не пускают. Поэтому ограничимся точкой останова на следующей после CALL инструкции, т.е. уже после возвращения из функции.

-

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

Дальнейшее обсуждение касается обоих семейств Windows: 9x и NT.

Это самая обыкновенная точка останова, которую мы уже не раз использовали в предыдущих главах. Иногда она обозначается сокращённо BPX как одноимённая команда, которая используется в отладчике SoftIce для установки обычных точек останова. Справедливости ради, стоит заметить, что в OllyDbg используется сокращение BP для обозначения данного вида точек останова.

Для установки BPX достаточно выделить нужную строчку кода и нажать F2. Повторное нажатие F2 снимает BPX.

Смотрим крэкми CrueHead'а на точке входа:

Выделяем, например, строчку 401018; нажимаем F2 - адрес выделился красным цветом, чтобы показать, что тут находится обыкновенная точка останова. Данный адрес также добавляется в список точек останова в окне [B]reakpoints.

В списке появился наш BPX и видно, что он активен в данный момент.

В колонке Active отображается статус Always, а это значит, что данный BPX (должен - прим. пер.) будет выполнен всегда, т.е. он всё время активен.

Правый щелчёк мышью в списке BPX'ов - всплывает контекстное меню, через которое можно индивидуально контролировать точки останова.

• REMOVE: удалить данную точку останова из списка равносильно её снятию.

• DISABLE: отключить точку останова, не удаляя её из списка. В отключенном состоянии точка останова не будет срабатывать.

• EDIT CONDITION: задаёт условие, таким образом, превращая обычную точку останова в условную, но об этом мы поговорим позже.

• FOLLOW IN DISASSEMBLER: показать эту точку останова в листинге дизассемблера.

• DISABLE ALL / ENABLE ALL: отключить / включить все точки останова в списке. В данном случае нет опции Enable all, так как единственная точка останова в списке не отключена.

• COPY TO CLIPBOARD: помещает в буфер обмена информацию о выбранной точке останова. Давайте попробуем это сделать:

Опция Whole line помещает в буфер обмена информацию об одной (выбранной) точке останова, тогда как Whole table распространяется сразу на все точки останова, находящиеся в списке.

В буфер помещаются: инструкция, на которой висит точка останова, статус этой точки, адрес и т.д.

Нажимаем F9 (Run) - отладчик начинает выполнять крэкми, но, вскоре, достигает точки останова и, как можно догадаться, останавливается.

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

И причина, по которой произошла остановка:

Давайте попробуем разобраться, что же на самом деле представляет собой точка останова. Происходит ли какое-либо изменение в двоичном коде инструкции при установке точки останова?

Правый щелчёк: Follow in Dump – Selection

Смотрим в дампе содержимое по адресу 401018:

На первый взгляд, содержимое дампа совпадает с первоначальным кодом инструкции. И в листинге дизассемблера в колонке машинного кода мы видим то же самое:

Везде - и в дампе, и в дизассемблере - мы видим значение 0B C0, которое соответствует инструкции OR EAX,EAX. Похоже, что никаких изменений нет, но так ли это на самом деле? Перезагрузите крэкми и убедитесь, что точка останова всё ещё висит на месте (по адресу 401018).

Давайте введём следующую инструкцию, чтобы фактически прочитать из памяти машинный код инструкции OR EAX,EAX, на которой висит точка останова:

Данная инструкция помещает в EAX значение ячейки по адресу 401018. Что нам по этому поводу подсказывает отладчик?

В дампе, в листинге и теперь ещё и в окне подсказки - везде показано одно и то же значение: 0B C0. Тем не менее, давайте всё-таки нажмём F7 и проверим что окажется в EAX.

По адресу 401018 оказалось немного не то, что нам изначально показывал OllyDbg... Значение 0B C0 74 01 задом наперёд (т.е. в формате little endian) выглядит как 0174C00B, а вовсе не 0174C0CC. Итак, вместо 0B по адресу 401018 хранится CC. Каким образом это значение связано с точками останова мы детально рассмотрим позже, когда займёмся изучением исключений. Чтобы не "загрязнять" пользовательский интерфейс, отладчик скрывает от нас, что при установке обычной точки останова, первый байт инструкции заменяется на CC. Тем не менее, сама программа запросто может прочитать из памяти настоящее значение, что может использоваться для обнаручения точек останова в антиотладочных целях. Поэтому не стоит удивляться, когда обычные точки останова иногда мистическим образом не срабатывают. Быть может, сама программа их "палит" :)

Кроме F2, есть ещё способ установки обычной точки останова через CommandBar:

На NT (2000, XP и 2003) можно запросто ставить точки останова на адреса API-функций - мы это уже рассмотрели в предыдущей главе. Чтобы установить точку останова на обращения к MessageBoxA, вводим:

В данном случае нужно указывать точное имя, и это касается регистра букв. В Windows 98, напротив, точки останова прямо по адресам API не поддерживаются - вместо этого приходится довольствоваться точками останова на самих вызовах:

BPX ставит точку останова не на указанный адрес, как это делает BP, а на инструкции, которые ссылаются на данный адрес. Важно отметить, что отладчик может определить далеко не все обращения к API-функциям (вызовы могут быть "замаскированы" различными способами, чтобы сбить с толку крэкера - прим. пер.) BPX можно использовать и в NT, но обычно предпочтение отдаётся более надёжной команде BP.

Вот как выглядит список точек останова после использования BPX MessageBoxA. Как видите, отладчик обнаружил 3 вызова данной функции и поставил 3 точки останова: по одной на каждый вызов.

На протяжении всего цикла статей мы будет использовать преимущественно BP (пользователи Windows 98 будут использовать BPX - у них нет выбора). Так что, когда в тексте встречается термин BREAKPOINT или BPX, под этим следует понимать команду BP.

Ещё один способ установить точку останова: двойной щелчёк в области машинного кода (колонка с байтами) по строчке с инструкцией в окне дизассемблера. Повторный двойной щелчёк снимает точку останова.

Точки останова на обращения к памяти

Точки останова на доступ к памяти иногда также называются BPM (от англ. Breakpoint on Memory), но не нужно путать это сокращение с командой BPM в старом добром SoftIce - это совершенно разные вещи.

Данный вид точек останова модифицирует свойства страниц памяти, которым принадлежит область, на которую вешается BPM. Например: BPM on access срабатывает на любых обращениях к данной области байт (чтение, запись или выполнение кода). Ещё существует BPM on write, который срабатывает только на обращениях на запись (чтение и выполнение в этом случае не отлавливаются). Давайте рассмотрим несколько примеров:

Находясь на точке входа в крэкми CrueHead'а, давайте попробуем установить несколько BPM. В окне дампа задаём Go to - Expression: 4020CA, чтобы переместиться на данный адрес.

Тут мы и установим первый BPM ON ACCESS: на 4 байта по адресу 4020CA. В дальнейшем, после команды Run, данная точка останова должна будет сработать при попытке чтения содержимого этих байтов, записи или исполнения (если бы там вдруг оказался исполнимый код). Давайте выделим все 4 байта:

Область байт выделена, правый щелчёк мышью: Breakpoint - Memory, on access. Вовсе не обязательно использовать именно 4-байтовые BPM. Аналогично можно было выделить область меньшего или большего диапазона.

Есть у BPM'ов парочка недостатков: они не отображаются в списке [B], да и ни в каком другом месте. Поэтому приходится запоминать, где его установили. Причём нельзя одновременно использовать более одного. Если установить ещё один, старый BPM автоматически сотрётся.

Итак, даём команду Run... Остановка происходит по адресу 401007, где текущая инструкция пытается что-то записать по адресу, попадающему в диапазон нашего BPM, т.е. в 4020CA.

Внизу - в строке состояния - внятно описана причина, по которой мы остановились:

Текущая инструкция намеревается записать значение регистра EAX по адресу 4020CA, что и спровоцировало остановку. Помните, когда мы пытались что-то записать в область памяти, без свойства (W)riteable, происходило исключение? Собственно, аналогичным образом действует BPM on access: отладчик сбрасывает все свойства доступа страницы, которой принадлежит заданная область памяти. Любое обращение к данной странице провоцирует исключение, которое перехватывает отладчик.

Если нажать F7, значение EAX всё-таки запишется, так как отладчик принимает меры, чтобы исключение в данном случае лишний раз не повторилось.

Значение 400000 успешно записалось. Давайте снова дадим команду Run. Так как BPM всё ещё активен, он сработает снова, если приложение попытается что-то записать/прочитать/исполнить по заданному адресу.

Как видите, теперь остановка произошла при попытке считать значение из той самой ячейки, о чём свидетельствует сообщение Memory breakpoint when reading [004020CA].

Опять же, по F7 операция всё-таки совершается, т.е. значение удачно считывается в EAX.

Снова F9... Сработает ли снова наш BPM? - Да, так и есть:

Отладчик снова засёк попытку чтения содержимого 4020CA, но на этот раз инструкцией PUSH, которая пытается скопировать это содержимое в стек.

Чтобы удалить BPM, достаточно щёлкнуть правой кнопкой мыши в дампе: Breakpoint - Remove memory breakpoint. Также можно установить новый BPM - при этом старый, как мы уже говорили, ликвидируется.

Если вместо "Memory, on access" указать "Memory, on write", BPM будет ловить только обращения на запись (чтение содержимого области PBM не будет вызывать остановку).

OllyDbg позволяет устанавливать BPM сразу на целую секцию (что приходится очень кстати при трассировании различного рода упаковщиков - прим. переводчика). Согласитесь, что выделять мышкой все байты нужной секции в дампе - мягко говоря, неудобно. Поэтому идём в закладку View [M]emory:

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

Правый щелчёк по выделенной секции: Set memory breakpoint on access.

Можно было выбрать опцию on write, т.е. обращения на запись, но в данном случае речь идёт о секции кода, поэтому логичнее задействовать BPM on access. Командуем Run.

Точка останова срабатывает буквально на следующей же инструкции, так как:

Правильно, остановка произошла when executing, т.е. при выполнении кода, ведь BPM установлен как раз на текущей секции кода и попытка выполнить любую инструкцию из этой секции приводит к срабатыванию BPM.

Давайте установим BPM на секцию кода kernel32, которую можно найти чуть ниже в списке. Вот она:

Условием по прежнему ставим on access, чтобы отлавливались все попытки чтения/записи/выполнения, проецирующиеся на данную секцию кода kernel32. Снова Run.

Судя по подсказке в стеке, остановка произошла на вызове API-функции:

Таким образом можно отловить первое обращение к заданной DLL. Адрес возврата можно посмотреть в стеке:

Правый щелчёк по адресу возврата: Follow in disassembler.

Адрес возврата указывает на 401007, сразу после вызова функции GetModuleHandleA в начале программы.

Чуть ниже находится вызов функции FindWindowA, но этот вызов не спровоцирует остановку по BPM, так как данная функция принадлежит другой DLL - user32.dll. Если снова задать Run, остановка произойдёт тут же на следующей инструкции, так как следующая инструкция тоже принадлежит секции, находящейся под влиянием BPM, ровно как и все остальные инструкции текущей функции. Иными словами, BPM будет срабатывать на каждом шагу. Поэтому мы его лучше снимем опцией Remove memory breakpoint.

Чтоб вернуться снова в код основного модуля, правый щелчёк: Execute till user code. Иногда, если этот способ не срабатывает, можно задать опцию Execute till return, чтоб перескочить на выход из текущей функции, и потом трассировать далее привычными средствами: F7 и F8.

В данном случае Execute till user code вполне справляется с задачей вывести нас обратно в код основного модуля. Позже мы рассмотрим ситуации, в которых данный способ не применим.

Теперь можно снова поставить BPM на kernel32.dll, чтобы поймать следующее обращение к этой библиотеке и т.д.

Например, если нужно поймать вызов функции MessageBoxA, но BP MessageBoxA не срабатывает, так как программа считывает первый байт этой функции и проверяет его на равенство CC, можно попробовать BPM. Давайте рассмотрим этот пример более подробно.

Адрес функции MessageBoxA на моей машине соответствует 77D504EA. Перемещаемся на соответствующий адрес через Go to - Exression. Можно указать сам адрес или точное имя функции:

Подсвечиваем первую инструкцию:

В данном случае тоже предоставляется на выбор: on access или on write. Выбираем первое и отдаём команду Run.

Выбираем Help - Register, вводим произвольные данные:

Нажимаем OK.

Происходит остановка на обращении к данной API-функции точно так же, как при использовании обычного BP. Если обычные точки останова не срабатывают, возможно, данный способ поможет обойти защиту. Этому способу тоже можно противодействовать проверкой свойств доступа к страницам памяти, но подобные антиотладочные приёмы встречаются реже.

В следующий раз мы рассмотрим аппаратные точки останова (Hardware breakpoints) и Message breakpoints. Ещё есть условные точки останова, но о них мы поговорим позже.

Процессорные точки останова (hardware breakpoints, HBP) - это возможность, предоставляемая процессором. Как это устроено на самом деле, я не знаю, но тем не менее мы можем устанавливать их, чтобы программа, когда их встречает, останавливалась и передавала управление.

Мы можем установить до 4 четырёх HBP, на пятый Ollydbg попросит нас указать, какой из четырёх уже установленных убрать.

Как обычно, для практики будем использовать крэкми CrueHead'а.

Есть три возможности: HBP ON EXECUTION, ON WRITE и ON ACCESS.

Установка HBP ON EXECUTION выполняет ту же роль, что и BPX на адрес, но HBP не изменяет код и его сложнее обнаружить, хотя есть программы, которые используют кое-какие приёмы, чтобы сбросить HBP. Эти приёмы и способы противостоять им, мы рассмотрим в следующих главах.

Если хотим установить HBP ON EXECUTION на 401013, отмечаем строку, кликаем на правую кнопку мыши и выбираем BREAKPOINT-HARDWARE ON EXECUTION.

Также можем написать в коммандной строке:

После этого HBP установлен.

У Ollydbg есть специальное окно, с помощью которого мы можем просмотреть и управлять HBP'ами. Чтобы открыть его, идём в DEBUG-HARDWARE BREAKPOINTS.

Здесь мы видим окошко с HBP, и если нажмём FOLLOW, мы окажем в листинге на той строке, где он был установлен. С помощью DELETE мы можем его удалить.

Теперь нажмём F9 для того, чтобы начать выполнение программы.

И остановимся на 401013.

Как видим, он ведёт себя как обычный BPX, если же сделаем то же, что делали и с BPX - напишем MOV EAX, DWORD PTR DS:[401013] и запустим, то увидим, что код не изменился.

Изменим EIP на 401000 с помощью NEW ORIGIN HERE и нажмём F7.

Видим, что в EAX содержатся E8 A6 04 00 (в обратной форме, поэтому мы видим 00004A6E8), то есть никаких изменений в коде не было.

Если мы перезапустим Ollydbg, то увидим, что HBP остался установленным.

Убираем его и устанавливаем HBP на MessageBoxA таким же образом, как и BPX.

Теперь смотрим список HBP.

Не будем повторять снова, но знаем, что если запустим программу и введём юзера и пароль, и мы согласимся, то выполнение остановится на API MessageBoxA, т.е. примерно так же, как если бы мы использовали обычный BPX.

HBP ON ACCESS и ON WRITE могут охватывать только 1, 2 или 4 байта, если же мы выберем в DUMP зону большего размера, то будут иметь значение только первые четыре байта.

Сбросим все HBP, установленные нами ранее, и попытаемся установить HBP ON ACCESS на адрес 4020CA.

Посмотрим в DUMP'е, что находится по этому адресу.

А теперь отметим первые 4 байта.

Нажимаем правую кнопку мыши.

Видим, что для отмеченной нами зоны было предложен HBP на байт или два байта (WORD), выбор четырёх байтов предлагается только для адресов, которые кратны 4. В данном случае это условие не соблюдается.

Проделаем ту же операцию для следующего байта и выберем HARDWARE ON ACCESS, и теперь есть только возможность выбора BYTE.

А на следующем появилась, наконец-то, опция DWORD, то есть HBP на четыре байта.

Идея в том, что если нам нужно контролировать сохранение или чтение по адресу 4020CA, то для этой цели достаточно поставить HBP на один байт.

Возвратимся к 4020CA и поставим HBP ON ACCESS - BYTE.

Видим, что поставленный нами HBP в списке имеет разме 1, т.е. байт (BYTE).

Делаем RUN.

Здесь OLLY говорит нам, что сработал HBP 1, т.е. тот, который идёт первым в списке HBP.

Видим, что выполнение программы прекращается на строке, следующей за той, где производилось сохранение или чтение. Это верно как для HBP ON ACCESS, так и для ON WRITE - инструкция, на которой срабатывает HBP, выполняется, а программа останавливается на следующей.

Как вы можете видеть, отличие от MEMORY BREAKPOINT заключается в том, что программа остановилась бы на 401007 - непосредственно на той инструкции, которая вызвала срабатывание точки останова.

Как вы можете догадаться, HBP ON WRITE срабатывает, когда происходить сохранение, а не чтение, и остановка программы происходит на инструкции, следующей за той, которая вызвала срабатывание HBP.

В действительности это вариант обычных BPX, отличающийся тем, что при активации такого BPX OllyDbg проверяет, верно ли некое условие, и если да, то останавливает выполнение программы, а если нет, то продолжает выполнение программы, как будто BP не существует.

Рассмотрим пример.

Сбросим всё, что мы делали ранее, и установим BREAKPOINT CONDICIONAL на 40100E, для чего выделим строку, нажмём правую кнопку мыши и выберем BREAKPOINT CONDICIONAL.

Открывается окошко, в котором нужно задать условие.

Например, если хотим задать, чтобы останов происходил, когда EAX равен 400000, то условие должно быть таким: "EAX==400000".

В хелпах, прилагаемых к OllyDbg, написано, какие символы мы можем использовать и каким условиям они соответствуют.

Видим, что в случае с BPX CONDICIONAL используется розовый цвет. Нажимаем F9:

Видим, что произошёл останов, и OllyDbg нам сообщает:

Раз EAX равен 400000, значит сработало заданное условие.

Начнём выполнение заново, сотрём BPX CONDICIONAL и поставим другой, где, например, EAX==500000.

И сделаем RUN.

Видим, что крэкми выполнился и останова не произошло, т.к. EAX всегда был равен 400000 и условие не выполнялось.

Если откроем HELP-CONTENTS.

Вот BREAKPOINTS и место, где объясняются выражения:

Также в хелпе есть примеры выражений, которые можно использовать для условий.

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

Установим BPX CONDICIONAL LOG на адрес, где находится API, перезапустив предварительно OllyDbg.

Идем к нужному адресу, где находится api, и уже знаем, как это сделать: CLICK DERECHO-GOTO EXPRESSION.

Находясь здесь, нажимаем CLICK DERECHO- BREAKPOINT- CONDICIONAL LOG.

Видим окошко с множеством опций.

В данном случае нам нужно только, чтобы сохранялись требуемые нам данные.

Так как мы не хотим, чтобы происходил останов, то не задаём никакого условия, а в опции PAUSE PROGRAM выбираем, чтобы этого не происходило, то есть отмечаем NEVER. Потом в LOG VALUE OF EXPRESSION можем сделать так, чтобы сохранялось значение [esp], которое мы написали в поле EXPRESSION, в котором, как мы знаем, будет адрес возврата в основное тело программы после выполнения api, то есть самое верхнее значение стека, поэтому во второй строке LOG VALUE OF EXPRESSION выбираем ALWAYS, то есть логировать всегда. В третьей строке находится опция, задающая хотим ли мы логировать аргументы/параметры функции/api, и поскольку их немного, можем поставить ALWAYS.

Идём в окно LOG или L.

И очищаем его, чтобы ясно видеть, что сохраняет программа. Кликаем CLICK DERECHO-CLEAR WINDOW.

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

Теперь запускаем выполнение программы с помощью F9.

Идём в окошко крэкми и пока в LOG’е ничего нет, так как заданное нами api не вызывалось.

Идём в REGISTER, где можем задать имя и пароль пользователя.

Когда нажимаем OK

Видим, что в окошке лога отобразилась информация о MessageBoxA, самое верхнее значение стека (которое равно 40137D и является адресом возврата из api), а затем параметры api, в данном случае это адрес, из которого оно было вызвано, текст, заголовок и т.п.

В данном случае нам отобразилась информация только об одном вызове, но если api вызывается, скажем, 100 раз, то можем сохранять лог в текстовый файл. Если же нам нужно, чтобы отображались только некоторые из этих вызовов, то можем задать определённое условие.

Если у нас есть список с информацией о 100 различных вызовах данного api, выполненных программой, то можно задать какие-нибудь данные в поле условия, например, адрес возврата. В этом случае из всех 100 случаев вызова отобразятся только те, которые возвращаются на 40137D, а остальные нет.

Для этого перегрузим крэкми, снова найдём api и установим на неё BPX CONDICIONAL LOG.

Изменим опции, так чтобы точка останова срабатывала только тогда, когда выполняется условие и зададим его, чтобы проверялось, равен ли [esp] 40137D.

Запускаем программу, и когда появится окошко регистрации, введём имя пользователя ‘ricnar456’ и пароль ‘989898’.

Помните, что когда вводится имя пользователя, в котором есть цифры, messageboxa вызывается 2 раза? Нажимаем ОК.

Видим, что на первый MessageBoxA Олли никак не отреагировала. В логах показано, что адрес возврата был равен 4013C1, поэтому условие не выполнялось.

Когда нажимаем кнопку OK

Это второй раз, когда вызывается api. Здесь условие выполняется и срабатывает точка останова.

Видим, что верхнее элемент стека содержит значение 40137d, которое активирует BPX CONDICIONAL LOG.

В обоих случая OllyDbg сохранил информацию об обоих вызовах.

Во втором случае адресом возврата было 40137D, и мы видим, что в этот раз условная точка останова сработала.

Ок, думаю, что этого достаточно, чтобы вам в чём попрактиковаться некоторое время. Ещё остались MESSAGE BREAKPOINTS, но я не хочу вас уморить, так что ждите 12 часть, а после того, как рассмотрим последний вид точек останова, обещаю, что продолжим крэкать по-немногу, так, чтобы не заскучать.

Следующая цитата вкратце описывает назначение сообщений Windows:

Сообщения в Windows широко используются для уведомления о различных событиях. Если Вы хотите заставить какое-либо окно или контрол (элемент пользовательского интерфейса, на самом деле тоже являющийся окном, как то: кнопка, edit, Toolbar, Tree view и т.д.) совершить определённое действие, отправьте ему соответствующее сообщение. Сообщения также могут исходить от других приложений. Система уведомляет о таких событиях как передвижение мыши, нажатие клавиши на клавиатуре и т.д. также посредством сообщений.

Как мы уже рассмотрели ранее, в OllyDbg можно расставлять точки останова BPX на вызовах различных API-функций. Зачастую более эффективным способом "отловить" интересующие нас участки кода являются точки останова на сообщениях. Их ещё называют BMSG в честь одноимённой команды в ядерном отладчике SoftIce.

Оконные приложения имеют по крайней мере один так называемый цикл обработки сообений (англ. - message loop). Этот цикл являет собой вызов определеённых API-функций (чаще всего используются функции GetMessage и DispatchMessage, но встречаются и другие варианты воплощения message loop). Для более глубокого ознакомления с циклом обработки сообщений автор рекомендует статью "Understanding the Message Loop" (C) Brook Miles:

http://winprog.org/tutorial/messageloop.html

На русском и гораздо более подробно про цикл сообщений можно почитать у братьев Фроловых:

http://www.frolov-lib.ru/books/bsp/v11/ch1.htm#ch14

Правда, там речь идёт о Win16, но именно по данной теме особых разногласий с Win32 в тексте не наблюдается. Спасибо IceStudent’у за ссылку!

Давайте рассмотрим простой пример: для того, чтобы выудить серийник из крэкми, мы установим BMSG на сообщение о нажатии кнопки, ведь именно это сообщение должно инициировать проверку введенных данных. Итак, загружаем крэкми CrueHead'а в OllyDbg.

Но сначала попробуем выудить серийник классическим способом, а потом через BMSG и сравним. Для начала проанализируем API-функции, которые импортирует программа, чтобы найти ту, которой скорее всего считывается введенный текст для последующей проверки.

Правый щелчёк в ассемблерном листинге - Search for - Name (label) in current module.

Чаще всего для считывания текста из edit'а используются функции GetDlgItemTextA и GetWindowTextA. Конечно, могут использоваться и юникодовые версии данных функций (с суффиксом W), либо сообщение может посылаться напрямую (тут тоже есть несколько способов различного уровня сложности), либо более экзотический вариант с прямым считыванием буфера edit'а. Короче, и не надейтесь, что в продвинутых крэкми текст из edit'а будет извлекаться банальным вызовом GetDlgItemTextA или GetWindowTextA, но для начала мы рассмотрим именно этот вариант.

В списке видна функция GetDlgItemTextA. Это вовсе не значит, что данная функция используется именно для считывания имени пользователя и серийника (в программе могут быть и другие поля ввода), если вообще используется. Автор крэкми мог намеренно добавить данную функцию в импорт, чтобы ввести нас в заблуждение. Между прочим, функции API можно подгружать динамически (и даже разными способами), т.е. не через импорт. Таким образом, крэкми может на самом деле использовать GetDlgItemTextA, но в списке импорта функции не будет. Не будем пока усложнять и без того нелёгкий материал и предположим, что крэкми действительно использует GetDlgItemTextA для считывания текста из edit'а ;)

Ставим BP на вызов данной функции:

Или так:

После установки BPX, запускаем программу на выполнение, вводим имя пользователя и серийник:

Нажимаем OK - "брякаемся" в коде:

Обратите внимание на стек.

Видим, что один из параметров функции является указателем на буфер, в который будет скопировано содержимое edit'а.

Давайте загрузим данный буфер в дамп посредством команды Follow in dump или через Go to - Expression: 40218E.

Сейчас в буфере пусто, ведь функция ещё не выполнилась.

Давайте дадим этой функции возможность выполниться: Debug - Execute till return.

Теперь в дампе буфера находится имя, которое Вы ввели для регистрации.

Снова задаём команду Run (F9) - опять срабатывает наша точка останова.

Теперь параметр буфера указывает на адрес 40217E. Давайте посмотрим в дампе:

Задаём Execute till return.

А вот и наш серийник!

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

Снимаем все действующие BPX в окне [B] командой Remove.

Снова запускаем приложение, вводим имя и серийник, но пока ещё НЕ нажимаем OK.

Одна из особенностей использования BMSG по сравнению с BPX на API-функции заключается в том, что BPX можно расставлять заранее, ещё до запуска процесса, тогда как BMSG имеет смысл устанавливать только после создания окна, чьи сообщения нужно перехватить.

Открываем окно [W]indows в процессе отладки (не нужно предварительно останавливать процесс, т.е. статус процесса вполне может быть Running).

Если в списке [W]indows пусто, нужно сделать правый щелчёк мышью и выбрать пункт Actualize.

Ищем в списке контрол "кнопка"... В колонке Class должно быть значение Button, а в Title - OK. Есть такой контрол!

Правый щелчёк в строчке данного контрола - выбираем Message breakpoint on ClassProc.

В открывшемся окне нужно указать сообщение, которое мы собираемся поймать. Во всплывающем списке:

Есть тут и стандартные сообщения для статических текстовых контролов и кнопок, и мышиные сообщения, и для буфера обмена и т.д. Если Вы не знаете точно какое сообщение нужно ловить, можете попробовать стандартные группы сообщений (в начале списка). При нажатии левой кнопки мыши система посылает сообщение WM_LBUTTONDOWN (L означает LEFT, т.е. левая). При отжатии посылается сообщение WM_LBUTTONUP. На это последнее сообщение мы и повесим BMSG - оно имеет номер 202.

Вот как это должно выглядеть:

Мы выбрали сообщение 202 WM_LBUTTONUP. Щёлкаем по "Break on any window" и по "Pause program: On message" чтобы отлаживаемый процесс останавливался при поимке указанного сообщения. Ниже выбираем "Log WinProc arguments: On message" ибо регистрация каких-либо аргументов в логе не бывает лишней.

Данный BMSG будет срабатывать как при нажатии OK, так и Cancel, ведь мы указали, что BMSG вешается на все окна. Щёлкаем левой кнопкой мыши по кнопке OK.

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

Как мы уже знаем, основной код находится в секции, которая начинается по адресу 401000. Ставим BPM on access на данную секцию, чтобы остановиться как только управление попадёт в диапазон адресов этой секции.

Жмём на Run и вскоре останавливаемся уже в коде программы.

Не снимая BPM on access продолжаем нажимать F9 - получается пошаговое выполнение инструкций, но только в пределах текущей секции.

Сразу после выхода по 2м RET, попадаем на участок кода с вызовами GetDlgItemTextA, которые считывают имя пользователя и серийник. Таким образом, мы снова очутились на интересующем нас участке кода, но в этот раз мы не использовали BPX на обращения к API.

Если бы приложение не использовало вызовы API для чтения серийника, методом BMSG мы бы всё равно отыскали данный участок. В этом и заключается преимущество последнего.

Если мы хотим отловить нажатие кнопки OK но не мышью, а через клавиатуру, первым делом снимаем BPM on access: правый щелчёк - Remove memory breakpoint.

Открываем список точек останова в окне [B] и удаляем все BMSG опцией Remove.

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

Открываем закладку [W].

Повторяем уже знакомые действия, но в этот раз выбираем:

Сообщение WM_KEYUP под номером 101 - это сообщение генерируется при отжатии клавиши.

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

Можно ли заставить отладчик показывать сообщения "в живую", при этом не останавливаясь, чтобы потом поставить BMSG на те из них, которые представляют интерес?

Для этого нужно сначала установить BMSG на какое-либо сообщение. В данном случае можно снова использовать сообщение под номером 202, предварительно удалив лишние точки останова в списке [B], потом спровоцировать его срабатывание нажав и отпустив левую кнопку мыши.

Устанавливаем BMSG, нажимаем мышью кнопку OK (в окне регистрации крэкми).

Срабатывает наш BMSG. Теперь мы его немного переделаем, чтобы ловить все сообщения и сбрасывать в лог.

Открываем список точек останова по закладке [B].

В списке находится наш BMSG: правый щелчёк - Edit condition.

Кстати, обратите внимание на то, что BMSG - это всего лишь условная точка останова, условием которой является значение параметра [ESP+8] - оно должно равняться 202, т.е. WM_LBUTTONUP. Давайте посмотрим на стек:

Там хранится значение 202 по адресу ESP+8, чем и вызвано срабатывание BMSG.

Если Вы уже забыли что собой представляет [ESP+8], сделайте двойной щелчёк:

По самой верхней ячейке стека.

Адресация теперь показана относительно ESP: $+8 в данном случае означает ESP+8.

В общем, в ячейке [ESP+8] находится номер текущего сообщения, которое нам нужно сбрасывать в лог. Изменяем параметры условной точки останова:

В настройках указываем, что значение в выражении, т.е. [ESP+8], нужно записывать в лог вместе с другими параметрами функции; чтоб выполнение не останавливалось при срабатывании условного BPX ставим Never в Pause program.

Подтверждаем изменения кнопкой OK, дописываем имя пользователя и серийник, нажимаем OK, смотрим LOG сообщений:

Как видно в логе, сначала приходит сообщение 201 WM_LBUTTONDOWN, а потом - 202 WM_LBUTTONUP. Клавиатурные сообщения WM_KEYDOWN и WM_KEYUP не обрабатываются, как мы уже заметили.

Чтобы отловить и записать в лог все сообщения, которые получает программа (кнопки, поля ввода текста и т.д.) можно установить условные точки останова на функции обработки сообщений: TranslateMessage и/или DefWindowProcA.

Для более полной картины можете развесить условные BPX на обе функции. Вот как это делается:

Чтобы побыстрее установить оба BPX, давайте воспользуемся плагином CommandBar: BP TranslateMessage, BP DefWindowProcA.

и

Таким образом мы установили 2 обыкновенных BPX на функции API. Давайте переделаем их в условные. Для этого открываем закладку [B], правый щелчёк по первому BPX - Follow in disassembler.

Уже "на месте" точки останова задаём Breakpoint - Conditional log.

В качестве выражения, которое нужно записывать в лог, указываем MSG - это номер сообщения (например, для WM_LBUTTONUP, MSG = 202).

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

Итак, оба BPX уже превратились в условные.

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

Закладка [L] - правый щелчёк - Log to file.

Задаём имя текстового файла. Жмём Run.

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

Владение различными техниками BMSG бывает очень кстати при снятии NAG'ов и других типичных для реверсинга задач - вот увидите!

В следующей главе мы наконец получим правильный серийник для крэкми CrueHead'а.

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

Ок, эта часть будет посвящена работе с так называемыми HARDCODED-серийниками (жёстко заданными), которые не высчитываются на основе имени пользователя, то есть являющиеся текстом или числом, которые всегда одни и те же, и зачастую так просты, как никакие другие, и считаются наиболее лёгкими для поиска, поэтому мы и начнём с этого типа. Мы рассмотрим как совсем несложные, так и потруднее.

Для практики у нас есть четыре экземпляра, двое из которых приходятся на эту главу и два посложнее на 14-ую.

Первый из этих крэкми называется “LECCION 13 HARDCODED 1”, и он - самый простой. Откроем его в OllyDbg.

Здесь, как в самом простом случае с жёстко заданными серийными номерами правильный ответ находится в строках, используемых программой, которые мы можем посмотреть.

Чтобы найти строки, используемые программой, кликнем на правой кнопке мыши и выберем SEARCH FOR - ALL REFERENCED TEXT STRINGS.

Результаты будут следующие:

Здесь мы видим слово «FIACA», которое может быть ключом, и если мы не хотим работать, то можем просто перебирать встречающиеся в этом списке строки, чтобы найти верный, но этот метод не рекомендуется по следующим причинам:

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

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

Сначала посмотрим, какие API-функции используются, с помощью клика правой кнопкой мыши и выбора SEARCH FOR- NAME (LABEL) IN CURRENT MODULE.

Выводятся API-функции, используемые программой, и видим, что среди них есть нам известные.

Видим, что используется GetDllItemTextA для получения серийного номера, введённого пользователем, и MessageBoxA для вывода сообщений, является ли серийным номер верным или нет. Установим точку останова на каждую из этих API-функций.

Кликаем на обоих правой кнопкой мыши - TOGGLE BREAKPOINT ON IMPORT или то же самое с помощью commandbar’а.

Хорошо, нажимаем F9, чтобы запустить крэкми.

Появляется окошко для ввода серийного номера, давайте введём что-нибудь, например «narvajita», хе-хе (фамилия автора «Narvaja» - прим.пер.).

Нажимаем на «Verificar» (проверить) и видим, что сработал BPX:

Если посмотрим стек, то увидим, что остановка произошла на GetDlgItemTextA, получающая введённый пользователем серийный номер, а в параметрах функции находится адрес буфера, куда он сохраняется, в данном случае - 403010.

Посмотрим, что находится по этому адресу через DUMP. Правая кнопка мыши - FOLLOW IN DUMP.

Видим буфер, но в нём ничего нет, так как API-функция ещё не выполнялась.

Выберем EXECUTE TILL RETURN, чтобы она выполнилась до инструкции RET.

Стоим на RET’е.

А в буфере - то, что мы ввели.

С этим понятно.

Если нажмём F7 и вернёмся в программу.

Увидим, что начинается сравнение и условный переход, который переходит либо на MessageBoxA, показывающий надпись “Mal Muy MAL” («плохо, очень плохо» - прим. пер.), либо на MessageBoxA, показывающий надпись “Muy BIEN” («очень хорошо» - прим.пер.) соответственно. Очевидно, что если мы исправим этот переход на JMP 401087, то будет всегда выполняться переход на вывод сообщения “MUY BIEN”, но в данном случае я хочу найти серийный номер, поэтому будем смотреть, что сравнивается.

В 401066 в EBX перемещается содержимое памяти по адресу 403010, которое является DWORD’ом. Посмотрим, что находится по адресу 403010 через DUMP.

Отметим нужную строку, через правую кнопку мыши выберем FOLLOW IN DUMP-MEMORY ADDRESS и увидим, что там находится.

В пояснении видим, что там находится 7672616E, являющееся перевёрнутыми 4-мя байтами содержимого 403010, и это первые 4 байта неправильного серийного номера, который мы ввели. Они-то и были перемещены в EBX.

Нажимаем F7 и переходим к следующей строке.

Здесь видим, что EBX, содержащий первые 4 байта неправильного серийного номера, сравнивается с содержимым ячейк памяти по адресу 403008. Посмотрим через DUMP, что там находится, так же как мы делали это в прошлый раз.

Видим, что там находятся первые четыре байта слова “FIACA”, которые и сравниваются с первыми четыремя байтами введённого серийного номера, из чего мы можем заключить, что если бы они были одинаковы, то активировался бы флаг Z, так как между ними не было было разницы, выполнился бы переход JE и вывелось бы сообщение “MUY BIEN”, но так как они не одинаковы, то нас ждёт суровое наказание, хе-хе.

Раз они не одинаков, то перехода не происходит и выполнение идёт к окошку “MAL MUY MAL”. Нажимаем F9.

Мы стоим на другом вызове MessageBoxA.

И уже в параметрах функции видим, что она нам покажет.

Продолжаем выполнение программы.

Как видим, было показано окошко с сообщением, что мы ошиблись, жмём на “OK” и вводим правильный код “FIACA”.

Нажимаем на “Verificar” и повторяем процесс, пока не доходим до сравнения.

Как и в прошлый раз, содержимое EBX сравненивается с содержимым 403008.

В пояснении видим, что они оба одинаковы, поэтому в результате их вычитания друг от друга получится ноль и активируется флаг Z. Выполним сравнение с помощью F7.

Видим, что всё так и есть, поэтому выполнится JE.

Видим, что переход произойдёт на MessageBoxA c MUY BIEN. Посмотрим с помощью F9.

Здесь видим стек API-функции, которая отобразит нам правильное окошко.

Хотя создатель крэкми очевидно забыл поменять название окошка, это не важно, так как мы нашли правильный серийный номер, который был жёстко и очень просто задан.

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

Abramos el LECCION 13 HARDCODED 2 en el OLLYDBG

Открываем «LECCION 13 HARDCODED 2» в OllyDbg.

Как видим, всё очень похоже, но в используемых строках нет правильного кода.

Нет ни “FIACA”, ни чего-либо другого похожего, хехе.

Да и верный код вовсе не “FIACA”, хехе.

Раз уже знаем, что здесь примерно происходит, идём сразу к сравнению.

Устанавливаем на 401064 BPX и делаем RUN.

Введём неправильный серийный номер (в данном случае LUCKY).

Нажимаем на “Verificar”.

И при срабатывании BPX видим, что в EBX помещается содержимое памяти по адресу 40300C. Смотрим через DUMP.

Попсле выполнения этой строки в EBX перемещаются 4 байта, которые меняют порядок при перемещении в регистр.

Нажимаем на F7 и оказываемся на EBX. MOV EBX, DWORD PTR DS: [40300C] перемещает только четыре байта.

В этом примере, который почти ничем не отличается, в EDX помещается содержимое 40204B, смотрим, что там.

Там находятся четыре байта, соответствующие строке 9898 и являющиеся правильным серийным номер. Они сравниваются с четырьмя байтами введённого нами серийного номера, и если они одинаковы, то совершается переход в область MUY BIEN, но в данном случае этого не происходит, поэтому нам нужно вернуться и ввести 9898.

Нажимаем “Verificar”.

При сравнении EBX с EDX оба равны 38393839, что соответствует строке 9898, поэтому совершается переход на вывод окна MUY BIEN.

Видим, что в этом крэкми мой друг сделал заголовок окна “BRAVO”, ха-ха! Но главное, что мы выяснили правильный серийный номер - 9898.

Далее мы увеличим сложность - у нас осталось два более трудных жёстко заданных серийных номера, на которых мы рассмотрим техники, применямые в более запутаннх случаях.

Если вы думаете, что я один буду работать, а вы нет, то вот вам третий крэкми (mielecrackme1.zip).

В качестве подсказки скажу, что API-функция lstrcmpA, встречающаяся в этом крэкми, используется напрямую для сравнивания строк. Когда встретите её, посмотрите на параметры в стеке.

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

Прежде всего я собираюсь объяснить, как решается крэкми, над которым мы начали работать в главе 13.

Это mielecrackme, загруженный в OllyDbg, и его точка входа. Посмотрим, какие функции API используются с помощью SEARCH FOR-NAME (LABEL) IN CURRENT MODULE.

Вот список найденных api-функций.

Среди них указаны самые важные: GetWindowTextA, использующаяся при вводе серийного номера, lstrcmpA, которая встречалась в предыдущей главе и используется для сравнения строк, и MessageBoxA, отображающая сообщение о том, верен ли серийный номер или нет.

Мы можем установить BPX на эти функции, чтобы произошла остановка, когда будет введён неверный серийный номер, но в данном случае, который весьма прост, можно сделать всё гораздо быстрее, если посмотреть СТРОКИ, используемые программой.

Выполнение SEARCH FOR – ALL REFERENCED TEXT STRINGS даёт нам список строк, которые использует крэкми.

Здесь видим как строку, отображающуюся как в успешном случае, так и строку, показывающуюся в случае неудачи. Если сделаем на какой-нибудь из них двойной клик мышью, то окажемся в окрестностях MessageBoxA. Попробуем сделать двойной клик на “YOU ENTERED THE RIGHT PASSWORD” («Вы ввели правильный пароль»).

Оказались в соответствующем месте.

Сначала идёт GetWindowTextA, считывающая серийный номер, который мы напечатали, затем lstrcmpA, сравнивающая считанный номер с правильным, а затем, если они верны, MessageBoxA показывает «YOU ENTERED THE RIGHT PASSWORD», а если нет, то происходит переход к другому MessageBoxA, отображающему «YOU SHOULD TRY AGAIN, IT'S SO EASY» («Попробуй ещё раз, это же так просто»).

Установи BPX на вызове lstrcmpA, чтобы посмотреть, что она сравнивает.

Запустим программу с помощью F9.

Выскочило окно ввода серийного номера. Введём в него что-нибудь вроде 989898.

Нажмём кнопку CHECK, чтобы сработал установленный нами BPX.

Видим, что OLLY показывает и параметры функции, которые являются двумя сравниваемыми строками, в данном случае сравниваются строки «989898» и «cannabis».

Чтобы выполнить вызов этой API-функции, нажмём F8.

В EAX помещается результат, равный FFFFFFFF или -1, а это означает, что строки не одинаковые.

В результате этого сравнения флаг Z неактивен и инструкция JNZ выполняет переход, т.к. флаг Z равен нулю (вспомним, что JNZ совершает переход, если флаг Z равен нулю, а JZ, наоборот, если флаг Z активен, т.к. равен 1).

Раз мы делаем переход, то получаем сообщение с ошибкой, но зато теперь мы знаем, что сравнение происходит со словом «cannabis», то есть это и есть верный серийный номер. Снова продолжим выполнение программы.

Нажав на «ОК», снова вернёмся в окно ввода серийного номера и напечатаем правильный – «cannabis».

Нажмём кнопку CHECK, и срабатывает BPX.

Видим, что будут сравниваться две одинаковые строки. Жмём F8, чтобы выполнить вызов API-функции..

Обе строки были равны, и в EAX был сохранён результат функции – ноль, что активирует флаг Z.

И поэтому JNZ не будет совершать переход.

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

Это и есть решение крэкми из главы 13. Хе-хе, серийным номером является слово «каннабис».

Продолжим дальше и рассмотрим более сложный случаи жёстко заданных серийных номером, чем те, что мы рассматривали ранее.

В следующем случае уже не производится прямого сравнения серийного номера с введённой строкой. Откроем крэкми crackmeeasy в OllyDbg.

Мы уже знаем, как посмотреть используемые API-функции. В списке также есть GetDlgItemTextA, на который мы и установим BPX.

В commandbar’е напечатаем:

Теперь запустим программу с помощью F9, и откроется окно ввода серийного номера.

Напечатаем неверный серийный номер.

Кликнем по кнопке “Check” и попадём на вызов нужной нам функции.

Посмотрим, какие параметры в стеке.

Здесь видим буфер, в котором сохраняется неправильный серийный номер, отметим эту строку, затем правый клик мышью и FOLLOW IN DUMP.

Буфер пуст, так как функция ещё не запустилась, поэтому выберем DEBUG-EXECUTE TILL RETURN.

Это приведёт к выполнению функции, которое остановится на инструкции RET.

Нажмём F7, чтобы вернуться в программу.

И видим, что в буфере окажется введенный нами неверный серийный номер.

Здесь мы также видим большую процедуру, делающую что-то с какой-то строкой в виде числа. Кому-нибудь пришла мысль, что это правильный серийный номер? Я знаю, что нет, хе-хе.

Здесь в EAX помещается число 401222, которое является адресом, указывающем на строку, содержащую число-константу.

На следующей строке, где EAX равен 401222:

MOV EDX,DWORD PTR DS:[EAX]

Это, на самом деле, всё равно, что:

MOV EDX,DWORD PTR DS:[401222]

То есть содержимое памяти по адресу 401222 перемещается в 401222.

Олли показывает, что это первые 4 байта числа 10445678951.

Выполнение строки с помощью F7 перемещает их в EDX (они всегда перемещаются в регистр в порядке, обратном тому, как они располагались в памяти).

На следующей строке байты, находящиеся в EDX, перемещаются в [EBP-30].

Из пояснений Олли видно, что [EBP-30] на моей машине – это 240f9e4. Поищем это значение в DUMP’е.

F7 копирует байты, находящиеся в EDX.

После чего

в EDX перемещаются следующие 4 байта числа-константы.

Пояснения Олли показывают, что [eax+4] содержат 401226, и выполнение инструкции с помощью F7 перемещает следующие 4 байта в EDX.

И копируется продолжение того, что копировалось ранее.

В действительности происходит вот что: этот номер копируется по 4 байта в другую часть памяти.

И наконец копируются последние 4 байта.

Наконец-то номер скопирован полностью.

Видим, что чуть ниже находится вызов функции memset. Посмотрим её параметры с помощью OllyDbg.

Здесь три значение (n, c и s).

s – начальный адрес

n – количество байтов, которых нужно заполнить требуемым значением

c – значение, которым будет заполняться указанная область памяти

В стеке находятся вышеуказанные параметры: область памяти по адресу 240f9f0 продолжительностью в 8 байт должна быть заполнена нулями.

Выполнив эту функцию с помощью F8, мы видим, что указанная нами область памяти действительно была заполнена нулями.

Ещё ниже находится вызов lstrlen, которая считает длину строки, адрес которой задаётся непосредственно до вызова самой функции.

В стеке находятся следующие параметры:

То есть будет вычислена длина строки, которая начинается по адресу 240f9E4, что является адресом уже известного нам числа, хех.

F8, и происходит выполнение strlen, а в EAX возвращается длина строки.

Видим, что размер равен 0B, то есть 11 в десятиричной системе, что является длиной нашего номера.

Здесь LEA перемещает в EDX значение EAX минус 1, то есть 0A.

На следующей строке происходит сравнение 0A с содержимым [EBX-10], то есть с нулём.

И раз ноль меньше чем 0A, то переходим на 40135C.

На следующей строке в EAX помещается указатель на наш неверный серийный номер, и поэтому когда нажмём на F7, то EAX будет указывать на “98989898”.

На следующей строке перемещаем в EDX ноль.

На следующей строке

Так как EAX указывает на начало неверного серийного номер, прибавляем к нему EDX (который изначально равен нулю) для создания цикла, каждый увеличивая значение EDX на 1 (1, 2, 3 и т.п.), чтобы получить все байты неверного серийного номера по одном в указанном цикле.

Как мы уже знаем, MOVSX переместит байт в EDX и если он положителен, то заполняет остаток регистра нулями, а если отрицателен – ‘F’.

В данном случае первый байт неверного серийного номера переместится в EDX и выполнение строки покажет, что EDX стал равным 39.

Следующая строка с LEA.

EDX равен 39, вычитаем из него 14 и с помощью LEA помещаем результат непосредственно в EAX.

То есть в результате произведённых операций получили 39 (шестнадцатиричное значение первого символа моего серийного номера), отняли от него 14 и результат, равный 25, поместили в EAX.

Следующая строка перемещает значение, находящееся по адресу EBP-30 (на моей машине равное 240f9E4, и оно указывает на начало номера-константы), в EDX.

Нажмём F7.

EDX указывает на начало номера-константы.

Далее видим, что в ECX перемещается сначала значение равное нулю, а затем при каждом новом проходе оно увеличивается, чтобы ECX+EDX указываели на разные байты номера-константы.

Здесь видим, что ECX теперь содержит ноль, а EDX указывает на начало номер, поэтому в данном случае в EDX будет помещён первый байт номера, дополнительная информация о котором выводится в пояснении OllyDbg.

Пояснение говорит, что 31 соответствует ‘1’ в кодировке ASCII, что является первой цифрой номера-константы.

Здесь мы дошли до сравнение, где участвуют:

В EAX находится значение 25 (значение первого байта неверного серийного номера (39), от которого было отнято значение 14), а в EDX первый байт номера-константы или 31.

А потому видим, что

CMP EAX,EDX

на самом деле является

CMP (ПЕРВЫЙ БАЙТ НЕПРАВИЛЬНОГО СЕРИЙНИКА– 14), ПЕРВЫЙ БАЙТ НОМЕРА-КОНСТАНТЫ

CMP 25,31

И поскольку разность между этими двумя операндами равна нулю, то флаг Z не активируется и выхолняется переход JNZ.

Мы вводили неверный серийный номер, а сравнение может дать верный результат, если будет введён правильный серийный номер, чтобы сравниваемые значения были верны.

CMP (ПЕРВЫЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА– 14), 31

Это и есть условие, при котором сравниваемые значения будут равны.

ПЕРВЫЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА-14 = ПЕРВЫЙ БАЙТ НОМЕРА-КОНСТАНТЫ

Поэтому

ПЕРВЫЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА = ПЕРВЫЙ БАЙТ НОМЕРА-КОНСТАНТЫ + 14

ПЕРВЫЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА = 31 + 14

ПЕРВЫЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА = 45, что соответствует “E” в ASCII.

То есть первая буква серийного номера равна E.

Эта побайтовая проверка повторяется в цикле до конца.

ПЕРВЫЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА = ПЕРВЫЙ БАЙТ НОМЕРА-КОНСТАНТЫ + 14

ВТОРОЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА = ВТОРОЙ БАЙТ НОМЕРА-КОНСТАНТЫ +14

ТРЕТИЙ БАЙТ ПРАВИЛЬНОГО СЕРИЙНИКА = ТРЕТИЙ БАЙТ НОМЕРА-КОНСТАНТЫ +14

Вот таким образом.

Применим этот алгоритм для каждого байта, прибавляя 14 и получая значение байта, соответствующее верному серийному номеру.

31 + 14 = 45 это буква E в ASCII

30 + 14 = 44 это буква D в ASCII

34 + 14 = 48 это буква H в ASCII

34 + 14 = 48 это буква H в ASCII

35 + 14 = 49 это буква I в ASCII

36 + 14 = 4A это буква J в ASCII

37 + 14 = 4B это буква K в ASCII

38 + 14 = 4C это буква L в ASCII

39 + 14 = 4D это буква M в ASCII

35 + 14 = 48 это буква I в ASCII

31 + 14 = 45 это буква E в ASCII

Поэтому правильный серийный номер следующий:

EDHHIJKLMIE

Введём его в окне серийного номера, убрав предварительно все точки останова.

Нажмём “Check”.

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

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

Ок, прилагаю к этой части крэкми «Splish», попробуйте найти серийный номер, захардкоженный в нём.

Прежде, чем перейти к последнему из крэкми с жёстко-заданными серийными номерами, рассмотрим тот, который я оставил вам в прошлый раз для самостоятельной работы. Он назывался SPLISH.

Откроем его в OllyDbg.

Он открывается на точке входа (ENTRY POINT).

Смотрим используемые API-функции (правая кнопка мыши - SEARCH FOR-NAME (LABEL) IN CURRENT MODULE).

Видим список используемых API-функций.

Видим, что используется GetWindowTextA при вводе серийного номера и MessageBoxA для отображения сообщения, правилен ли он или нет. Можем установить BPX на обе функции, но сначала ещё глянем, что покажет список строк, используемых программой.

Кликаем правой кнопкой мыши на листинге и выбираем SEARCH FOR-ALL REFERENCED TEXT STRING.

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

Попадаем в область, где ведётся работа с серийным номером.

Видим ввод текста с помощью функции GetWindowTextA и два MessageBoxA с разным текстом: правилен ли серийный номер или нет.

Ставим здесь на вызов API-функции GetWindowTextA BPX, чтобы начать с того места, где вводится серийный номер.

Запускаем крэкми с помощью F9 или RUN.

Так как пока что мы можем решить только ту часть, которая относится к жёстко-заданным серийным номерам, пишем в поле HARDCODED, которое находится наверху, неверный серийник или нажимаем на кнопку CHECK HARDCODED.

Останавливаемся на BPX, установленный ранее.

Пояснения показывают нам, что находится в стеке, и это даёт нам сразу понять, что буфер, в котором будет сохранён введенный серийный номер находится по адресу 403215.

Посмотрим через DUMP, что находится в буфере.

Вот этот буфер, куда будет сохранён введённый серийный номер. Нажимаем F8, чтобы выполнить вызов API-функции.

Так как использовали F8, выполняется вся функция, так что неправильный серийник уже находится в буфере.

Ок, следующая строка переместит 401353 в EAX (помните, что LEA не перемещает содержимое ячейки памяти по заданному адресу, а только результат того, что находится в квадратных скобках; в данном случае это будет 401353). Видим в DUMP’е, что по вышеуказанному адресу (кликаем на строке правой кнопкой мыши и выбираем FOLLOW IN DUMP-MEMORY ADDRESS, и это нам покажет, что находится по адресу 401353).

По адресу 401353 находится строка “HARDCODED”; нажимаем F7, чтобы выполнилась LEA.

После выполнения в EAX остаётся 401353, а с правой стороны появляется пояснение, что данный адресу указывает на строку “HARDCODED”.

Следующая строка загружает в EBX другой адрес, в данному случае это 403215.

После нажатия F7 EBX содержит значение 403215.

И справа Олли показывает нам, что этот адрес указывает на строку “98989898”, являющуюся введёнными нами неправильным серийным номером, который мы посмотрим в DUMP’е так же, как сделали это для предыдущей инструкции.

Здесь 403215 указывает на наш неправильный серийный номер.

Следующая строка проверяет, равен ли нулю первый байт содержимого EAX, который равен 401353.

Так как мы уже смотрели содержимое по этому адресу через DUMP, то уже знаем, что там находятся байты строки “HARDCODED”.

Первый байт в данном случае равен 48, пояснения OllyDbg нам также говорят, что это соответствует символу “H” в кодировке ASCII, а это первая буква слова “HARDCODED”. Так как это не ноль, то продолжаем.

Так как сравнение не активирует флаг Z (операнды не равны друг другу), JE не совершает перехода (помните, что JE срабатывает только тогда, когда активируется флаг Z),

Нажимаем на F7 и продолжаем.

Здесь очень хорошо видно, что сначала будет перемещён первый байт [EAX], равный 48, что соотвтествует слову “HARDCODED”, а на следующей строке перемещается [EBX], являющийся первым байтом неправильного серийного номера, после чего оба сравниваются и если они не равны, то происходит переход на 4013D2, где выводится сообщение “SORRY, PLEASE TRY AGAIN”.

Проверим это следующим образом.

Нажмём F7 и переместим в CL значение 48.

CL, как мы помним, это регистр, соответствующий двум последним цифрам ECX, здесь перемещаем 48, и вот, что получится в результате.

Затем в DL перемещается первый байт неправильного серийного номера.

Выполним строку с помощью F7, видим, что в DL находится значение 39.

Теперь CL сравнивается с DL.

Пояснение OllyDbg не оставляет сомнение: сравнивается 39 (что есть 9, т.е. первый символ введённого мной серийного номера с H, являющейся первым символом строки “HARDCODED”).

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

Теперь Z равен 1, как если бы в сравнении двух байтов они были равны и их вычитание друг от друга дало бы ноль, активировав данный флаг.

Видим, что в этом случае происходит увеличение EAX и EBX и переход с помощью JMP на начало цикла.

Теперь EAX указывает на второй байт строки “HARDCODED” и видим, что цикл повторяет побайтовое сравнение, пока [EAX] не будет указывать на ноль, то есть пока не завершится строка “HARDCODED” (в конце строки за последним символом находится ноль).

Тогда после увеличения значения EAX и EBX на 1 будут считаны и сравнены друг с другом вторые байты, если равны, то цикл повторится, но уже будут рассматриваться третьи байты, а когда слово “HARDCODED” закончится, то если все сравнения на равенство CL с DL прошли успешно, перехода на окошко с ошибкой не произойдёт, и попадём вот куда:

Здесь EAX указывает не на какой-либо из байтов слова “HARDCODED”, а на ноль, так как строка уже закончилась.

Вот и тот самый ноль, а это значит, что сработает соответствующая проверка.

Срабатывает JE, и мы выходим из цикла.

И попадаем в то место, где отображается сообщение о правильно введённом номере (так как поменяли значение флага Z при побайтовом сравнении, хе-хе).

Очевидно, что менять значение флага Z пришлось при каждом сравнении CL с DL, чтобы программа поверила в одинаковость обоих серийников и не перешла на сообщение об ошибке и не вышла, но в любом случае мы теперь знаем, что правильный серийный номер – это слово “HardCoded” (с соблюдением прописных и строчных букв, так как у них разный ASCII-код).

Уберём все точки останова, введём найденный серийный номер и нажмём кнопку “CHECK HARDCODED”.

Ещё одна победа, поздравляю.

Хорошо, тогда переходим к последнему крэкми с жёстко заданным серийным номером и заканчиваем на этом с ними, а в главе 16 перейдём к следующей теме.

Алгоритм следующего крэкми, который назвается SAMBO, отличается от предыдущих. Откроем его в OllyDbg.

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

Соглашаемся с предупреждением OllyDbg и прибываем в EP.

С помощью ещё одного окошка OllyDbg сообщает нам, что программа, возможно, запакована или зашифрована, поэтому анализ её будет настолько же неэффективным, как пепельница в мотоцикле, так как программа будет распаковывать себя во время выполнения, поэтому пока что выберем “Нет”.

Уже на первых строках листинга мы можем заметить, что этот крэкми выполняется не так, как его незапакованные сородичи, чья первая секция начинается с 401000.

Здесь точка входа равна 4d4001.

Посмотрим, является ли секция исполняемой, для этого идём VIEW-MEMORY или нажмём клавишу M.

Видим, что программа стартует в секции, начинающейся с 4D4000, размер которой равен 2000 (в шестнадцатеричной системе), и поэтому 4d4001 – это адрес, который относится к данной секции.

Это и есть то, о чём говорила OllyDbg – точка входа находится за пределами секции code.

Секция CODE начинается с 401000, а выполнение начинается с адреса 4D4001, который относится к другой секции. OllyDbg нам сообщила, что это характеристика многих запакованных программ.

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

А раз так, нажимаем F9.

Мы уже знаем, что когда появится окошко крэкми для ввода серийника, программа уже распакована в памяти и выполняется в секции code, поэтому можем установить на эту секцию BPM ON ACCESS , чтобы остановить выполнение на её первой строке.

При попытке вернуться в окошко крэкми OllyDbg остановится в секции code (т.е. первой секции после PE-заголовка).

Видим, что теперь программа распакована в памяти, можем её анализировать. Кликнем правую кнопку мыши в листинге.

Видим, что OllyDbg прекрасно показывает нам проанализированный код.

Теперь, когда мы находимся в секции code, можем посмотреть, какие api используются программой – то, что мы не могли посмотреть в начале, так как в тот момент нам показывались только API-функции, используемые распаковщиком, а не те, которые используются программой; сейчас же никаких проблем нет.

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

Ещё один ужасный список.

“YOU DID IT” – одна из строк с поздравлением.

Хорошо, есть сравнение и переход, где мы видим строки с поздравлением и ошибкой, хотя здесь и нет MessageBoxA.

Устанавливаем BPX на условный переход, чтобы проверить, решающий ли это переход, и убираем BPM ON ACCESS щелчком правой кнопки мыши.

И делаем RUN.

В окне крэкми вводим “Narvajita” или любой другой неправильный серийный номер.

Нажимаем кнопку “Test-o-Doom”.

Видим, что произошёл переход, нажимаем F9.

Тогда соглашаемся с окошком с поздравлением, что у нас получилось.

Оно говорит, что это была шутка, и ничего не вышло на самом деле, ха ха! Делаем RUN по-новой и снова прибываем к переходу, связанному с кнопкой “Test-o-Doom”.

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

После двойного щелчка на флаге Z и изменения его значения, делаем RUN.

И отображается окошко с поздравлением, значит, это и есть то место, где решается правильность или неправильность серийного номера. Посмотрим сравнение до перехода.

Это TEST CL, CL, где проверяется, равен ли CL нулю или единице, что задаётся где-то до этого, возможно в CALL, вызываемый ранее, на который мы можем поставить BPX.

Делаем RUN, возвращаемся в окно и снова нажимаем кнопку Test, чтобы остановиться на CALL.

Остановившись, осмотримся любопытным взором вокруг, хе-хе.

Если посмотрим в стек, то увидим введённый неправильный серийный номер, заглянем в DUMP (через FOLLOW IN DUMP).

Мой глаз крэкера видит здесь строку, которая, возможно, является верным серийником; могли бы посмотреть, так ли это, но пока делать этого не будем и продолжим поиск серьёзным образом.

Если внутри данного CALL производятся какие-либо сравнения или операции с неправильным серийником, то можно установить BPX ON ACCESS на него, чтобы программа остановилась, когда с ним будет что-нибудь делаться, то есть на какой-либо операции или сравнении.

Выделим неправильный серийный номер, нажмём правую кнопку мыши и выберем BREAKPOINT-MEMORY ON ACCESS.

После этого, когда продолжим выполнение, то если внутри call происходит какая-либо работа с этим серийником, OllyDbg остановится.

Нажимаем F9.

Видим, что остановки не произошло, возможно, сравнение происходит раньше, так что мы можем поставить точки останова на CALL'ы, находящиеся ещё выше, и повторить то, что делали прежде, но лучше пустим в ход другой способ остановиться на том месте, где вводится серийный номер: здесь не используется API-функция GetWindowTextA, но у нас есть сообщения Windows, которые послужат нам не хуже.

Убираем BPM ON ACCESS.

Ставим быстрым способом BP TranslateMessage.

А теперь RUN.

Остановшись на API-функции, нажимаем на правую кнопку мыши и выбираем:

И в окошке печатаем условие MSG==202, которое является значением WM_LBUTTONUP.

И устанавливаем переключатели так, чтобы остановка происходила по ON CONDITION, и чтобы логгировалось всё.

Здесь розовым цветом обозначен BPX CONDICIONAL. Делаем RUN.

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

И по нажатию на кнопку срабатывает BPX CONDICIONAL.

Остановка произошла на WM_LBUTTONUP.

Возвращаемся в программу с помощью EXECUTE TILL RETURN.

Нажимаем F7 и возвращаемся в программу.

Здесь у меня появляется две возможности. Установить BPM ON ACCESS в первой секции, чтобы сделать переход с помощью F9 и посмотреть, куда ведёт процедура сравнения серийного номера, что мне кажется сложноватым, так как я уже видел, что эта процедура весьма большая.

Другая возможность – это посмотреть, находится ли уже в памяти введённый нами серийный номер, так что идём в окно M.

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

В появившемся окне в поле ASCII введём наш неправильный серийник.

Нажимаем OK, чтобы начать поиск в памяти.

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

Устанавливаем BPM ON ACCESS на этот неправильный серийник, , чтобы найти момент, когда с ним производятся какие-либо операции, чтение или сравнение.

И нажимаем F9.

Останавливаемся там, где он копируется в то место, которое мы видели в последнем CALL’е.

Мы знаем, что REP MOVS копирует содержимое из ESI в EDI, так что посмотрим EDI в DUMP (правая кнопка мыши на EDI-FOLLOW IN DUMP).

Сюда REP MOVS скопирует серийник, нажмём F8, чтобы он это сделал.

Оказались после этого на RET, серийник полностью скопировался, и устанавливаем на него BPM ON ACCESS.

Выполнив RUN, останавливаемся здесь.

Точнёхонько на сравнение, хех.

ESI указывает на мой неправильный серийник, а EDI на правильный, который равен «1556555».

Убираем все BPX.

Появляется окошко с поздравлением.

В следующей главе мы начнём разбор крэкми, в который используются не только серийный номер, но и имя пользователя.

Способ его решения очень похож, но рассмотрим несколько примеров, чтобы всё стало понятным.

Начнём с поиска правильного серийного номера в крэкми CrueHead’а.

Откроем его в OllyDbg.

Мы находимся на точке входа.

Смотрим, какие API-функции используются для получения введённого серийного номера.

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

Делаем RUN.

После нажатия на OK оказываемся на api-функции и в стеке видим параметры.

Буфер, в котором сохраняется введённый текст, начинается с 40218E, посмотрим через DUMP, что там находится – правый клик мыши и FOLLOW IN DUMP на строке, где приводится информация о буфере.

Здесь ничего нет, потому что API-функция ещё не выполнилась, так что выполняем DEBUG-EXECUTE TILL RETURN, и когда оказываемся на RET, нажимаем F7, чтобы вернуться в программу.

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

Встречаем ту же API-функцию во второй раз. Здесь используется новый буфер, куда помещается введённый серийник. Посмотрим его через дамп.

То же самое, что и в прошлый раз; выполняем API-функцию с помощью EXECUTE TILL RETURN, а чтобы вернуться в программу, нажмём F7.

Теперь здесь наш неправильный серийный номер, начиная с этого места программа будет сравнивать его с правильным, который высчитывается на основании имени, поэтому можем установить BPM ON ACCESS на неверном серийнике, чтобы узнать, что с ним делает программа.

Отметим нужные байты, правый клик – BREAKPOINT – MEMORY ON ACCESS, и RUN.

Видим, что остановка произошла там, где программа считывает первый байт неправильного серийного номера и перемещает его в BL. Нажимаем F7.

В BL находится 39 – значение первого байта. Нам нужно отловить, что программа делает с ним и, по возможности, записать, какие математические действия программа над ним совершает.

Здесь делается проверка на то, равен ли он нулю, если да – это конец строки и произойдёт выход из цикла.

Так как нулю первый байт не равен, то перехода не происходит и попадаем на SUB BL, 30.

После того, как было вычтено 30, в BL осталось 9.

На следующей строке EDI умножается на EAX.

s

Эти регистры были инициализированы следующими значениями: в начале процедуры в EAX было помещено 0A, а EDI до входа в цикл приравнен к нулю с помощью инструкции XOR EDI, EDI.

По нажатию F7, как мы помним, исходя из определения инструкции IMUL с двумя операндами, в данном случае, они будут умножены с учётом знака, а результат сохранён в первый операнд, т.е. в EDI.

Таким образом, в EDI остаётся ноль, ставший результатом выполнения предыдущей операции.

Дальше идёт сложение EDI со значением в EBX.

В результате в EDI остаётся 9, а на следующей строке выполняется инструкция INC ESI, что увеличивает ESI, чтобы затем вернуться на начало цикла и прочитать следующий байт неправильного серийника.

После это в AL снова помещается значение 0A, прочитывается следующий байт неправильного серийного номера (это будет 38), проверяется, равно ли оно нулю, из него вычитается 30 и прибываем в IMUL.

Видим, что умножается EDI, в котором осталось значение ещё с прошлого пробега цикла, на 0A, а результат помещается в EDI же.

Теперь EDI содержит 5A, а на следующей строке он складывается с EBX.

То есть результат всех производящихся операций накапливается в EDI; тем, кто усерден и прилежен на ниве крэкинга, уже ясно, что происходит. Объясним.

Достаточно установить точку останова на выход из цикла: нажимаем F9 и, когда происходит остановка, видим, чему равен EDI.

Если кликнем два раза на EDI.

Значение EDI – значение шестнадцатеричное, во втором поле видим его же в десятеричной системе счисления, и это значение соответствует серийному номеру, введённому мной, т.е. после выхода из цикла в EDI содержится серийник в шестнадцатеричном виде.

Т.е. резюмируя кратко: если напечатаем слово 98989898, оно будет трансформировано в десятеричное число 98989898 или шестнадцатеричное 5E6774A.

На следующей строке EDI xor’ится с 1234.

В результате получается 5E6657E, которое перемещается в EBX, а затем мы прибываем в RET.

Видим, что выйдя через RET, мы оказались у сравнения EAX с EBX, то есть туда, где находится переход, решающий, правилен или нет серийный номер.

И видим, что сравнивается вычисленное значение, находящееся в EBX с EAX, который содержит 547B.

Так как EAX определяется программой, а EBX – высчитывается, то очевидно, что поскольку мой серийный номер неверен, то и значения этих регистров не будет равно.

Если EBX был бы равен EAX, то программа сделала бы нужный переход, поэтому нам нужно проанализировать, отчего произошло неравенство регистров.

Смотрим сделанные нами заметки.

EBX= (Шестнадцатиричное значение неверного серийного номера) XOR 1234

Мне нужно, чтобы EBX был равен EAX, тогда проверка на равенство выдаст нужный результат.

Если EAX=EBX

Reemplazo EBX por EAX ya que son iguales

Заменим EBX на EAX, то есть чтобы они были равны.

EAX=(Шестнадцатиричное значение правильного серийного номера) XOR 1234

При выполнении этого условия введенный серийный номер будет верным.

Переформулируем.

EAX XOR 1234= (Шестнадцатиричное значение правильного серийного номера)

И поскольку в EAX есть значение (547B), то можем заменить на него EAX.

547B XOR 1234 = (Шестнадцатеричное значение правильного серийника)

Если посчитаем результат операции XOR:

464F = (Шестнадцатеричное значение правильного серийника)

Если 464F – это шестнадцатеричное значение, то соответствующее десятеричное, которое нужно ввести, будет:

Переводим в десятеричную систему.

Это и есть правильный серийный номер для имени “narvaja”. Убираем все BPM и BP.

Нажимаем OK.

Так мы получили серийник для моего имени.

Это один способ решения. Можно прибегнуть и к другому ходу мысли, чтобы придти к тому же результату.

Если над моим неправильным серийным номером выполняются некие операции, трансформирующие его, то эти операции назовём функцией F.

F (неправильный серийный номер) =EBX

То есть над неправильным серийником производятся операции, называемые функцией F, результат чего сохраняется в EBX, с которым и происходит сравнение.

Другим членом сравнения является EAX, что приводит нас к следующему равенству:

F (правильный серийный номер)=EAX

Применение вышеуказанных операций над правильным серийным номером в данном случае даст то же значение, что и в EAX, поэтому если у нас есть EAX, то мы также имеем на руках данные для сравнения и производимые операции.

Чтобы получить правильный серийный номер, нужно применить над EAX операции, обратные используемым при проверке введённого серийника.

Правильный серийный номер = (операции, обратные F)EAX

То есть, если неправильный серийный номер перед сравнением складывается с каким-то значением, то мы должны это значение отнять от EAX, таким образом применяя обратную операцию.

В данном случае операцией, обратной XOR, является тот же самый XOR, так как эта операция инвертируемая.

Поэтому XOR EAX будет функцией обратной F и даст мне шестнадцатеричное значение правильного серийного номера, из которого, если переведём его в десятеричную систему, получится собственно серийник.

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

Теперь снова вернёмся к SPLISH. Мы решили ту часть, которая касалась жёстко заданного серийника, а теперь решим вторую с вводом имени пользователя.

Загрузим SPLISH в OllyDbg и окажемся на точке входа.

Смотрим используемые API-функции.

Ставим BPX на уже знакомую нам GetWindowTextA.

И запускаем программу с помощью F9.

Вводим имя и неверный серийник, после чего нажимаем кнопку NAME/SERIAL CHECK.

Остановившись на вызове API-функции, смотрим буфер.

Ищем буфер в DUMP’е.

Так как здесь ничего нет, выполним EXECUTE TILL RETURN, чтобы остановиться на RET, а заме нажмём F7 для возврата в программу.

Видим, что сначала получили неправильный серийный номер, поэтому отмечаем его и устанавливаем BPM ON ACCESS.

Делаем RUN.

Снова останавливаемся на вызове той же функции, которая в этот раз получает из формы имя, но поскольку нам это сейчас не интересно, снова нажимаем RUN.

Останавливаемся на этой процедуре.

Первая строка перемещает первый байт неправильного серийник. Если выполним её:

Дальше следует инструкция CDQ. Посмотрим, что о ней говорит наш друг Google.

CDQ

IDIV ESI

Инструкция IDIV ESI делит содержимое EDX:EAX на ESI, сохраняя результат деления в EAX, а остаток в EDX. Чтобы быть это деление было эффективным, содержимое EDX должно быть равно нулю, что можно сделать с помощью CDQ или XOR EDX, EDX. В этом случае не нужно помещать ноль в регистр EDX, потому что результат предыдущей инструкции уже делает это.

В этом случае EDX подготавливается перед делением для получения остатка, а поскольку у нас здесь цикл, то каждый раз для этой цели перед выполнением команды IDIV используется CDQ.

EDX:EAX делится на ECX, результат помещается в EAX, а остаток в EDX. Ок, это посмотрим, как это работает. Первый байт равен 39, он делится на ECX, который содержит 0A.

Видим, что получилось.

Здесь результат деления (5) оказывается в EAX, а остаток (7) – в EDX.

Видим, что следующая строка сохраняет результат деления в 40324D. Посмотрим через DUMP, что там.

Продолжаем выполнение с помощью F7.

Здесь сохраняется 7.

Видим, что EBX, равный нулю, увеличивается на 1 и сравнивается с 6, и так как эти значения не равны, то цикл повторяется.

Теперь посмотрим, что происходит со вторым байтом.

Снова происходит деление на 0A и сохранение остатка.

Сохраняем…

Ок, одна и та же операция производится над всеми байтами.

И выходим из цикла, так как не происходит перехода с помощью JNZ, возвращавшего нас раньше.

Попадаем сюда и видим сообщения о правильном и неправильном вводе серийного номера, так что похоже, что находимся рядом с тем, что нам нужно.

Здесь два LEA, которые помещают адреса в ESI и EDI.

ESI указывает туда, где сохраняются остатки, а EDI, возможно, на что-то интересное?

Продолжаем.

Видим, что EBX содержит ноль, который сравнивается с 7, и если бы они были равны…

Перешли бы на окошко с сообщением о правильном вводе. В середине находится другой JNZ, который перемещает на другое окошко с сообщением о вводе неправильном.

Ок, видим, что сравнивается.

В EAX переместится первый байт, на который указывает EDI, то есть 02, а в ECX будет перемещён первый байт наших остатков, то есть 7.

И если остаток первого байта был бы равен 02, то был бы совершён переход.

В моём случае найти остаток можно было бы следующим образом.

39= 5 .0A + 7

То есть результатом деления 39 на 0A является 5 с остатком 7. Переформулируя, можно сказать, что умножив 0A на 5, получим 32 и прибавление 7 даст 39.

39= 5 x 0A + 7

Правильный остаток должен быть равен двум в случае правильного серийного номера.

BYTE CORRECTO= 5 x 0A + 2

BYTE CORRECTO= 32 +2 = 34

34 это цифра ‘4’ в ASCII.

Мы можем также увидеть, что

BYTE CORRECTO= 5 x 0A + 2

Даёт нам одно из цифровых значений (от 30 до 39). В случае, если результат выходит за эту границу, то нужно сделать понижение и считать так:

BYTE CORRECTO= 4 x 0A + RESTO

Ок, посчитали, что первый байт равен 34 или ‘4’ в ASCII.

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

C 02 уже посчитали.

Продолжаем с 08.

ПРАВИЛЬНЫЙ БАЙТ = 5 x 0A + 8

ПРАВИЛЬНЫЙ БАЙТ = 32 + 8

Получилось 40, что перевышаем максимальное установленное нами значение 39 (‘9’ в ASCII), поэтому понижаем и пересчитываем заново:

ПРАВИЛЬНЫЙ БАЙТ = 4 x 0A + 8

ПРАВИЛЬНЫЙ БАЙТ = 28 + 8 = 30 que es 0 en ASCII

Если хотите доказательство, то смотрим, что 30, делённое на 0A, даёт 4 с остатком 8.

Поэтому у нас есть второй правильный байт, равный 30, то есть ‘0’ в ASCII.

Посчитаем всё остальное байт за байтом.

Следующий опять 08, то есть результатом будет 30 или ‘0’ в ASCII.

Потом 03.

ПРАВИЛЬНЫЙ БАЙТ = 5 x 0A + 3

ПРАВИЛЬНЫЙ БАЙТ = 32+ 3= 35, то есть ‘5’ в ASCII.

Затем 05.

ПРАВИЛЬНЫЙ БАЙТ = 5 x 0A + 5

ПРАВИЛЬНЫЙ БАЙТ = 32+ 5= 37, то есть ‘7‘ в ASCII

Потом снова идёт 5, то есть повторяется 37 или ‘7’ в ASCII.

Последним идёт 3, который, как мы уже знаем, даёт 35 или ‘5’ в ASCII.

Таким образом, правильным серийным номером для имени ‘narvaja’ будет 4005775. Убираем все BPM и BPX и запускаем RUN.

Нажимаем кнопку NAME/SERIAL CHECK.

Ещё одна победа.

К этой главе прилагаетcz крэкми для практики под названием MEXCRK1.ZIP (находится в архиве wasm_files.zip: files/0470/mexcrk1.zip).

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

Но эту тему мы начнём в 19-ой главе, так как среди тех, кто изучает этот курс, нашлись люди, написавшие мне на почту и попросившие разобрать пример крэкми без кнопок как в прошлой части, и рассмотреть применение другой техники, использующей WM_KEYUP.

Хорошо, используем для этого крэкми, предоставленный мне Stzwei’ем (спасибо ему), который называется _4stz.exe. Его мы и рассмотрим в данном туториале.

Откроем крэкми в OllyDbg.

Находимся на точке входа. Посмотрим, какие здесь есть незапакованные строки.

Отображается список строк, используемых программой.

Здесь нет ничего интересного, посмотрим API-функции.

Уфф, так много.. Ок, запустим программу и окажемся в окошке, где вводится серийный номер.

Видим, что кнопки регистрации нет. Введём полное имя.

И установим BPX CONDITIONAL LOG на TranslateMessage – сначала обычный BPX.

А когда вернёмся в крэкми, отредактируем установленный BP.

Если кто-то не помнит значение WM-сообщения, которое собираемся использовать, то нужно перейти в окно W, которое показывает, какие окна используются программой.

И отображается список окон, осталось только узнать числовое значение, поэтому кликаем правой кнопкой мыши.

И мы попадаем в окно точек останова на сообщения с раскрываемым меню с WM-значениями.

Поищем в списке WM_KEYUP.

Видим, что это 101, поэтому уберём всё, что мы делали только для того, чтобы узнать это значение, и вернёмся к BREAKPOINT CONDITIONAL LOG в TranslateMessage.

И устанавливаем здесь MSG==1 (обратите внимание на двойной знак равенства), также, если бы не нашли значение, могли бы написать MSG==WM_KEYUP и это бы сработало, но мне больше нравятся числовые значения. Здесь каждый волен поступать так, как ему это нравится.

Хорошо, точка останова трансформировалась в условную (розовый цвет).

Делаем RUN и вводим первый символ неправильного серийного номера.

И тут срабатывает условная точка останова.

Смотрим параметры API-функции, по адресу 12ff78 находится структура, в которой сохранены значения нажатой клавиши, в данном случае это 39, что соответствует цифре 9.

Смотрим через DUMP указанную область памяти – нажимаем правую кнопку мыши на указанном адресе и выбираем FOLLOW IN DUMP.

Видим, что мы удалось узнать, куда помещается байт. Проблема в том, что это программа на Delphi (что мы рассмотрим в другой раз), и если мы установим на него BPM ON ACCESS, программа будет ходить сто раз туда-сюда, прежде чем дойдёт до сравнения, поэтому метод, который мы рассматривали в прошлый раз, работает здесь гораздо лучше, так что его мы и используем. В любом случае, вы уже знаете, как остановить программу по нажатию клавиши и как установить местонахождение байта. Разумеется, в крэкми, не написанном на Delphi, гораздо проще использовать BPM ON ACCESS.

И запускаем.

Вводим 9898, идём в окно M и ищем по всей памяти.

Нажимаем правую кнопку мыши и выбираем SEARCH.

И ищем строку 9898.

Первое вхождение обнаруживается в стеке. Нажимаем CTRL+L несколько раз, чтобы увидеть, сколько раз оно в нём встречается.

Как только нам внизу отобразится жёлтым цветом слово ITEM NOT FOUND, выходим и возвращаемся в окно M.

Оказываемся там, откуда искали, так что идём дальше вниз с помощью CTRL + L.

Первый раз в этой секции, нажимаем CTRL + L, чтобы посмотреть, найдётся ли здесь что-либо.

Нет, ничего, нет, если посмотрим область, находится вхождение чего-то подозрительного.

Видим возможный серийный номер 418507, установим на это место BMP on ACCESS, чтобы посмотреть, не с ним ли происходит сравнение.

Делаем RUN.

Останавливаемся здесь и видим, что копируется моё имя.

Видим, что каждый раз, когда печатаем, по новой копируется мой неправильный серийный номер, и с каждым следующим символом по новой копируется правильный серийный номер. Как только введём 6 символов, то установим на них BPM (помните, в предполагаемом серийном номере как раз 6 символов? – прим. пер.).

Останавливаемся прямо на сравнении.

Тут видим, что ESI и EDI указывают на неправильный и правильный серийные номера.

Они сравниваются по четыре байта за оборот цикла. Проверим, является ли найденный серийник действительно верным.

(Сообщение гласит: «Поздравляю, победитель!» - прим. пер.)

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

Есть и другая возможность. Видим, что в памяти появляются 4 байта неправильного серийного номера.

Он же, но уже из 5-ти первых байтов, чуть ниже.

Соответственно, можем установить BPM ON WRITE на область, находящуюся ниже, где будет записан следующий символ.

Отметим место, куда будет помещён следующий символ, а затем делаем RUN.

Здесь записываю наиболее возможный серийный номер.

Делаем RUN.

И далее программа останавливается на том месте, где копируется неправильный серийный номер, и прежде, чем это произойдёт, можем установить на него BPM ON ACCESS, а затем выполнить RUN и снова остановиться точно на сравнении.

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

Ладно, оставляю домашнее упражнение – крэкми CrueHead’а 2, а со следующей главы мы переходим к новой теме.

Обнаружение OllyDbg - IsDebuggerPresent

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

Эта часть посвящена способу обнаружения отладчика с помощью API-функции IsDebuggerPresent, которая наиболее часто используется.

Для этого используем Crackme1.exe, который идёт вместе с данной лекцией. Загрузим его в OllyDbg.

Помните, что у моей OllyDbg пока что установлен только COMMAND BAR, а значит и нет никакого плагина, который мог бы избежать обнаружения с помощью IsDebuggerPresent, но как вообще работает эта функция?

Если запустим крэкми с помощью F9, то увидим, что не только не открылось окошко крэкми, но и программа не запустилась.

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

Перезагрузим крэкми и посмотрим, находится ли она в списке API, используемых жертвой. Жмём на правую кномку мыши на листинге и выберем..

Видим список используемых API-функций.

И смотрите, что мы нашли, хе-хе.

Устанавливаем BP на эту функцию, чтобы выяснить, где она применяется программой.

Нажимаем RUN и останавливаемся на вызове этой функции.

Из стека видно, что это API-функция без параметров, единственное, что она делает, это проверяет, отлаживается ли сейчас программа или нет, а если у вас есть какие-либо сомнения относительно данной функции или того, как она работает, то проконсультируйтесь со справочником по API-функциям.

Вот страница руководства, которым пользуюсь я.

Это разъяснение функции. Переведём его.

API-функция IsDebuggerPresent показывает, находится ли процесс, который её вызывает, в контексте отладчика, то есть отлаживается ли он.

Далее говорится, что функция экспортируется из KERNEL32.dll, у которой, как видим, нет параметров, и если программа находится под отладкой, то возвращаемое значение равно единице, а если нет, то нулю.

Это очень важная информация, выполняем API-функцию до RET, чтобы посмотреть, куда возвращается интересующая нас информация.

Доходим до RET, где смотрим регистры.

Выделенное розовым цветом – это место, где изменяется EAX. Как практически все API-функции, IsDebbuggerPresent помещает возвращаемое значение в EAX, тогда если в нём 1, то это говорит о том, что программа находится под отладкой.

Попробуем, что случится, если вручную сделать EAX равным 0, как если бы программа не отлаживалась.

Делаем RUN.

Снова останавливаемся на API-функции, поэтому снова доходим до RET и меняем EAX на ноль.

Видим, что программа запустилась, то есть вся её система обнаружения отладки основывалась на рассматриваемой API-функции. Перезапустим крэкми, и когда он остановится на IsDebuggerPresent, посмотрим, что происходит с возвращаемым значением.

Снова доходим до RET, теперь можем перейти к пошаговой отладке с помощью F8.

Когда доходим до RET, EAX равен 1, вернёмся в программу, нажав на F8.

Здесь мы, прежде всего, видим, что если нет DLL uxtheme, то вызова не произойдёт. Делаем RUN и теперь происходит остановка на API-функции.

Там останавливаемся во второй раз, доходим до RET и возвращаемся в программу с помощью F8.

Оказываемся у JE, где происходит тестирование, равен ли EAX нулю или нет. Идём дальше.

Видим, что если EAX отличается от нуля, то перехода не происходит, также замечаем, что если переход происходит, то выполнение программы продолжается функцией GetDlgItem, которая считывает информацию из окна крэкми.

После невыполнившегося перехода находится JMP, миновать который нельзя.

Продолжим трассировку, чтобы узнать, куда попадём.

Новая API-функция – PostQuitMessage, посмотрим её описание.

В переводе это означает, что данная API-функция посылает сообщение для закрытия окна WM_QUIT, то есть указание на то, что выполнение скоро будет завершено.

По возвращению оттуда:

И если у нас будет терпение оттрассировать достаточно до того момента, когда всё закрывается, то обнаружим, что вызывается API-функция ExitProcess, которая и завершает процесс (если терпения нет, то установите на неё ExitProcess и остановитесь прямо на ней).

Так что теперь видим, что переход, который находится после возвращения из API-функции IsDebuggerPresent, отвечает за принятие решения о том, продолжать выполнение программы или нет. Одним из решений может быть патч, перезапустим программу и выполним её до пресловутого перехода.

Останавливаемся там и изменим JE на JMP 4011b2 (для этого нажмите пробел).

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

Сохраним программу с внесёнными нами изменениями под каким-нибудь другим именем. Нажимаем правую кнопку мыши.

И в открывшемся окне снова нажимаем правую кнопку.

Сохраняем под именем crackme1p, так что теперь у нас исходная программа и пропатченная.

Теперь откроем пропатченную программу в OllyDbg, чтобы проверить, выполнится ли она в отладчике. Никаких BP устанавливать не будем.

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

С этим крэкми у нас нет проблем – пропатчили и работает, но, конечно, существуют более простые способы, использующие плагины, которые позволяют нам избежать всех этих хлопот. Тем не менее, полезно знать, как это делать самим.

А сейчас загрузим исходный файл и рассмотрим API-функцию поподробнее.

Здесь три невзрачных инструкции MOV, с помощью которых данная API-функция каким-то образом определяет, отлаживается ли программа или нет. Первое, что мне пришло в голову – это то, что если программа отлаживается, то они не может выполнить эти три строки, и в EAX попадает значение 1. Попробуем перезагрузить исходный файл крэкми и добавить в точку входа следующие строки:

Можем их просто скопировать их по очереди.

Итак, добавили три строки.

Видим, что после выполнения последней из них, в EAX содержится значение 1, также, как после выполнения API-функции, из которой мы и взяли эти строки.

Естественно, что программа не остановилась на IsDebuggerPresent, потому что мы её не вызывали, но тем не менее, мы определили, что программа отлаживается точно с таким же успехом.

Поэтому очень важно определить, что же действительно считывается и что именно говорят эти три строки.

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

Как мы можем найти этот байт? Давайте взглянем на первую строку из указанных трёх, и шаг за шагом их проанализируем.

Первая строка:

В OllyDbg идём сюда:

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

Эта структура называется TEB или TIB и хранить полезную информацию, которая нам может быть нам очень полезной. Например, в TIB хранится, откуда начинается и где заканчивается стек программы.

Посмотрим в окне M секцию стека.

Видим, что начинается в 12d000 и заканчивается там, где начинается следующая секция (130000).

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

Поищем его в стеке.

Видим, что оно помечено как END OF SEH CHAIN (конец SEH-цепочки). Пока что это нам мало что говорит, но это связано с исключениями.

Интересно то, что следуя определённому алгоритму можно достать из него любое значение, например, которое находится после Fs:[0].

Это Fs:[0], если поищем в command bar’е значение fs:[1], то получим:

Поэтому:

То есть, это значение, которое, как мы помним, было на первой строке API-функции.

То есть видим содержимое 77ffdf018 (оно же FS:[18]).

Вот это значение, которое сохранено в TIB в FS:[18] – значение, которое отображается в регистрах, указывающее на начало TIB.

Таким образом, первая строка загружает в EAX указатель на начало TIB, конкретное значение может отличаться на разных машинах. Нажав F8, мы переместим это значение в EAX.

Хорошо, теперь в EAX находится указатель на TIB.

Теперь следующая строка.

К EAX прибавляется 30, на моей машине в результате получается 7ffdf000 + 30 =7ffdf030.

Это fs:[30].

То есть в EAX помещается содержимое 7ffdf030 или fs:[30], на моей машине это содержимое равно 7ffdc000, не спутайте это с началом TIB, эти значения различаются.

Это указатель на что-то другое, посмотрим на что именно через DUMP:

Последняя строка:

Сумма 2 и EAX равна:

И в EAX перемещается байт, адрес которого получился в результате, а он и есть искомый байт. На моей машине он находится по адресу 7FFDC002.

Система сохраняет 1 в этом байт, который считывается API-функцией IsDebuggerPresent. У вас адрес этого байта может отличаться, но вы сможете легко его найти, используя вышеуказанный метод. Загрузим заново крэкми в OllyDbg.

Вот краткое изложение того, как найти искомый байт, используемый в IsDebuggerPresent.

Ищем начало TIB в окне регистров.

Смотрим TIB через DUMP (он уже не будет располагаться по тому адресу, что в прошлый раз).

Ищем fs:[30], то есть к адресу, указывающему на TIB, прибавляем 30 и смотрим содержимое, находящееся по получившемуся адресу.

Его содержимое (7ffde000) также является адресом, смотрим через DUMP.

И прибавляем 2 – вот и искомый байт. (Многие обращают внимание, что когда программа запускается, в EBX уже находится указатель на эту область, так вот, EBX=fs:[30]).

Ок, это и есть весь метод целиком, который можно использовать, если не находимся в начале программы и не знаем значения, которое имел EBX при старте. Теперь поместим ноль в найденный байт.

Теперь установим BP на функцию IsDebuggerPresent, чтобы посмотреть, работает ли данный подход.

Трассируем до RET.

Видим, что возвращённое в EAX значение равно нулю, так как поменяли значение байта, из которого берётся значение, и программа верит, что она не находится под отладкой.

И поэтому выполняется без проблем.

Разумеется, есть множество плагинов, которые делают то же самое, один из них – это HideDebugger 1.24.

Сначала скачиваем его, затем копируем dll в директорию с плагинами.

Копируем, хехе.

Теперь перезапускаем OllyDbg.

Смотрим настройки плагина.

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

Нажимаем SAVE.

Запускаем по новой крэкми . Обратите внимание, что EBX указывает на область, где находится тот самый байт.

Теперь EBX-FOLLOW IN DUMP.

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

Если перейдём в DEBUGGING OPTIONS-SECURITY:

Здесь находится три галочки. Если мы их все отметим, то увидим, что установив BPX на API-функцию и если переинициализируем OllyDbg (Restart), то BPX останутся установленными, что позволяет нам избежать повторение всего процесса каждый раз, когда мы делаем рестарт.

Строго говоря, я не знаю, как именно работает OllyDbg «внутри», но на практике достаточно просто отметить эти три галочки, чтобы установленные на API-функции BPX оставались установленными после перезапуска.

Именно так, как мне кажется, без особых проблем и хлопот, мы и начинаем изучение темы антиотладки по имени процесса.

Обнаружение OllyDbg по имени процесса

Запустив OllyDbg, мы можем посмотреть список процессов с помощью CTRL + ALT + SUPR.

Видим, что имя процесса находится среди остальных, что позволяет программе пробежаться по их списку, и если она встретит называющийся OllyDbg, она закрывается, оставив противника ни с чем, ха-ха!

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

Приложенный к статье крэкми (находится в архиве wasm_files.zip: files/0474/daxxor.zip) называется DAXXOR. Если запустим его и OllyDbg по отдельности, то увидим, что крэкми запускается, но закрывает отладчик, а если загрузим программу в OllyDbg, то закроются оба.

Изучим, как это происходит. Откроем крэкми в OllyDbg.

Оказавшись в точке входа, посмотрим, какие API-функции используются.

Ок, их тут немало, но дело в том, что они используются защитой, а не самим крэкми, который сам в начале не грузится, поэтому API-функции, используемые для обнаружения OllyDbg, мы сможем посмотреть только в середине выполнения. Заодно я объясню этот способ защиты, который не позволяет нам увидеть список API-функций. С другой стороны, теперь мы точно знаем, что эти среди них есть важные API-функции, раз программа их скрывает и они не появляются в списке.

Почти в каждом таком случае, когда программа не запакована, как здесь, используется API-функция GetProcAddress.

Она используется программой, чтобы загружать другие API-функции, которые не находятся в списке используемых. Мы более подробно рассмотрим GetProcAddress в главе, посвящённой распаковке, но пока просто установим на неё BP.

И делаем RUN.

Каждый раз, останавливаясь на ней, видим, что именно запрашивается, в данном случае первой запрашивается функция __CPPdebugHook, не связанная с защитой, которую мы изучаем, поэтому снова жмём RUN.

Таким образом, с помощью F9 доходим до API-функций, относящихся к защите. Здесь видим, что используется функция EnumProcesses, так что после того, как дойдём до RET в GetProcAddress, в EAX будет возвращен адрес функции, действительный для конкретной машины, и туда мы установим BPX, после чего выполним RET с помощью EXECUTE TILL RETURN.

Здесь в EAX возвращается адрес указанной функции для конкретной машины, в моём случае это 76BB3A9A (он может отличаться у вас).

С другой стороны, видим, что OllyDbg не обнаружила эту API-функцию, и её нет в списке NAMES, поэтому мы не можем установить BP напрямую по имени функции, и поэтому устанавливаем точку останова на адрес.

Вот она установилась.

Итак, мы установили BP на подозрительную API-функцию, продолжаем выполнять программу в OllyDbg, чтобы увидеть, загружается ли ещё что-нибудь.

Хм, перебираются модули процесса, дойдём до RET и установим BPX на адрес, который будет возвращён в EAX.

Чтобы много не печатать, то находясь на RET, можем сделать так:

Так я устанавливаю BPX на все API-функции, когда нахожусь на RET.

Ещё одна подозрительная API-фукнция, устанавливаем на неё BP таким же образом, что и в прошлые разы, делаем и останавливаемся на EnumProcesses.

Комментарий справа, содержащий имя API, был добавлен мной. Комментарии можно добавлять с помощью двойного щелчка на нужной области.

Все эти функции, загруженные программой, не были увидены OllyDbg и не были отражены в списке, также она не даёт по ним какую-либо информацию.

Поищем в гугле, что это за функция “EnumProcess”.

Находим её на сайте Микрософта, адрес страницы:

http://msdn2.microsoft.com/en-us/library/ms682629.aspx

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

Каждому запущенному процессу присвоен идентификатор – число, меняющееся каждый раз при запуске процесса. Посмотрим на список процессов.

Видим, что в данном случае OllyDbg присвоен PID 724 – в десятеричной системе счисления, так как программа просмотра процессов работает именно с ней. Переведём вышеуказанное число в шестнадцатиричную систему с помощью калькулятора Windows.

Нажимаем на кнопку HEX, чтобы перейди в шестнадцатеричную систему.

PID OllyDbg в шестнадцатеричной системе равен 2D4. Можем закрыть и запустить по новой OllyDbg, и увидим, что PID изменился. Каждый раз, когда процесс запускается заново – PID меняется.

Также нам не повезло с отображением параметров функции, так как для OllyDbg она не существует.

Из страницы на сайте Микрософта, знаем, что у неё три параметра.

То есть в 12EDE4 сохраняется список PID’ов всех процессов, запущенных на моей машине, делаем EXECUTE TILL RETURN, чтобы вернуться из API-функции и смотрим через DUMP, что там лежит.

Там находится список PID’ов, а среди них и PID OllyDbg, хнык, хнык.

Ставим здесь BPM ON ACCESS, чтобы посмотреть, где он используется.

Теперь делаем RUN.

Видим, что остановились там, где будет применена функция OpenProcess, которая проверяет, работает ли процесс, и если да, то возвращает его хэндл (логический номер).

Какая разница между PID и хэндлом? Это очень просто – PID – это общий идендификатор – на всей машине, в какой угодно программе PID OllyDbg остаётся одним и тем же, пока процесс не будет перезапущена, в моём случае это 2d4, а хэндл – это номер, который позволяет позволяет вашей программе управлять процессом и который будет отличаться в другой программе. Это своего рода заявка на контролирование процесса, без номера не сможете им управлять, а чтобы получить номер, нужно попросить систему, которая вернёт вам хэндл. Тогда сможете и управлять и подстроить какую-нибудь гадость, хе-хе.

Вот более подробное определение OpenProcess в WinApis32, у неё тоже много параметров, но нам они не интересны.

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

Трассируем с помощью F8, пока не остановимся на API-функции.

Y en EAX devuelve el handle o manejador del OLLYDBG que en mi caso es 58.

В EAX возвращается логический номер OllyDbg, который в моём случае равен 58.

El mismo OLLYDBG nos muestra los HANDLES con los cuales esta trabajando el programa en la ventana H.

Тот же OllyDbg умеет показывать логические номера, с которыми программа работает в настоящее время, с помощью окна H.

Видим, что здесь есть 58 и TYPE или тип является PROCESS, т.е. процесс, таким образом, у программы есть логический номер 58, действительный в процессе OllyDbg.

Если другой процесс использует EnumProcess, чтобы получить PID, то для OllyDbg, если она не будет перезапущена, он будет равен 2d4, а если потом попросить логический номер данного процесса, то он будет каким-нибудь другим, так как хэндлы для каждого процесса, их запрашивающих, уникальны.

В данном случае, опасность для OllyDbg заключается в том, что у программы уже есть логический номер, с которым она может делать всё, что хочет. Хотя она и не знает, что выполняется из под OllyDbg, она может проверить имя процесса, чтобы определить, не называется ли он OllyDbg, и очевидно, что для этого будут перебираться все PID’ы, полученные в списке процессов, поэтому бросаем всё и отправляемся туда, где это будет происходить, для чего установим BPM ON ACCESS на соответствующий PID.

Продолжаем трассировать с помощью F8.

Дошли до ещё одной API-функции, которую от нас пытались скрыть, – EnumProcessModules. Посмотрим её описание на том же сайте, что и ранее.

То есть будет проводиться поиск в исследуемом процессе, получаем список модулей, используемых им. Продолжаем трассировать с помощью F7.

В стеке видим параметры:

Список хэндлов всех модулей сохранён по выделенному адресу, а первым параметром, как мы видим, является логический номер процесса OllyDbg.

Здесь нужно прояснить одну вещь: когда запрашиваем логические номера модулей, система возвращает нам адресную базу, или откуда начинается указанный процесс в памяти. В данном случае нам было возвращёно 400000, так как именного отсюда начинается процесс OllyDbg.

Продолжаем трассировать и находим ещё одну API-функцию.

GetModuleBaseNameA

Т.е., что с помощью этой функции ходим найти имя модуля, так как эта API-функция помещает в буфер по адресу lpBaseName имя модуля, соответствующего адресу, выясненному ранее.

В стеке следующие параметры:

58 – это логический номер OllyDbg, 400000 – это база главного модуля, а буфер располагается по адресу 12ECE0, так что смотрим эту область памяти через дамп.

Хе-хе, уже понятно, что эта операция будет проведена для каждого процесса, который запущен в машине, чтобы узнать, не является ли его именем ‘OLLYDBG.exe’.

Доходим до CloseHandle, где закрывается логический номер, то есть 58 исчезает из их списка.

Ну да, теперь мы не можем делать никаких шалостей, так как логический номер закрыт, и мы больше не можем полагаться на него.

Дошли до CALL, входим в него, нажав F7.

Здесь считывается первая буква “OLLYDBG” (4F) и помещается в стек с помощью PUSH, затем идёт новый CALL, в который мы также заходим.

Видим, что в этом вызове не происходит ничего особенно важного, поэтому выходим и оказываемся рядом со следующим CALL'ом.

Заходим в него.

Ах, где-то здесь сравнивается полученное имя процесса с ‘OLLYDBG.EXE’, и если они равны, то всё, капут.. хе-хе, сейчас они равны, посмотрим, что случится. Возвращаемся через RET.

Если бы они не были равны, то EAX должен был бы отличаться от нуля, и был бы совершён переход, чего не происходит, если EAX равен нулю, как в данном случае.

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

Если выполним с помощью F8.

Система возвращает номер 58, так что продолжаем.

Как видим, API-функция TerminateProcess, которой передаётся логический номер 58, служит для того, чтобы убить OllyDbg.

И по нажатию F8 – до свиданья, Олли. Всё закрывается. Вот так мы и исследовали, как работает обнаружение по имени.

Ладно, я слегка устал от роли убийцы, хе-хе, перезапускаем OllyDbg и устанавливаем BP на OpenProcess.

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

Вот так, теперь эта API-функция всегда возвращает ноль. Теперь убираем все точки останова, и так как программа генерирует кучу исключений, то, хотя мы ещё и не рассматривали данную тему, чтобы она нормально выполнялась, отметим все опции в DEBUGGING OPTIONS-EXCEPTION следующим образом:

Пока что просто отметьте все опции, чтобы программы перепрыгивала через все исключения, так как их очень много (для прохождения через них надо нажимать SHIFT+F9, а вышеуказанная конфигурация позволяет миновать их автоматически). Делаем RUN.

И вот, она выполняется без проблем, но вот ещё, что можно сделать:

Меняем JNZ на JMP, чтобы избежать выполнения кода защиты.

Программа запускается и показывает нам окно, которое исчезает после нажатия на TRY.

Выскакивает сообщение об ошибке. Прекрасно, потому что это говорит о том, что защита против отладки была побеждена.

Всё это не обязательно делать, чтобы обойти подобную защиту, достаточно скопировать OLLYDBG.exe под другим название, скажем, PIRULO.exe, работать отладчик после этого будет также, а вот отлаживаемая в нём программа не найдёт ни одного процесса под имени OLLYDBG, так как теперь он называется PIRULO.

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

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

Это крэкми buggers3 (находится в архиве wasm_files.zip: files/0475/buggers3.zip), в котором были сделаны некоторые изменения, чтобы можно было объяснить нахождение имени процесса с помощью других API-функций, использующихся в этом крэкми, и обнаружение OllyDbg по имени окна или его класса, которое также применяется здесь.

Откроем крэкми в оригинальном OllyDbg, не переименованном, потому что также будем изучать разновидность метода, применённого в 20-й главе, и поэтому необходимо, чтобы файл OllyDbg назывался ollydbg.exe. Тогда защита сработает, и мы сможем её изучить.

После того, как загрузили его в OllyDbg, настроим HideDebugger 1.23f против использования программой API-функции IsDebuggerPresent.

Посмотрим текущую конфигурацию плагина HideDebugger:

Пусть он защищает только от IsDebuggerPresent. Также откроем список процессов и убедимся, что используем непереименованный файл, то есть имя процесса ‘OLLYDBG.exe’.

Ок, возвращаемся к buggers3. Посмотрим, какие API-функции он использует.

Опа! Единственная функция в списке – это ExitProcess, всё остальное грузится через GetProcAddress, но и сама она в списке не присутствует.

Поставим BP, и что будет, если сделаем RUN?

Видим загружающиеся API-функции, конечно, если находим такую, что нам интересна, идём до RET, чтобы узнать её адрес, и также можем сделать BP EAX, так как именно в EAX будет находится возвращаемый GetProcAddress адрес.

В данном случае ничего интересного нет, поэтому продолжаем, нажав F9.

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

Ок, делаем EXECUTE TILL RETURN, чтобы дойти до RET.

Доходим до RET, и конечно, в EAX находится адрес загружаемой API-функции на моей машине, в данном случае это CreateToolhelp32SnapShot. Чтобы узнать, когда эта функция используется, установим точку останова с помощью BP EAX.

Здесь осталось установить BP на API-функцию.

Снова делаем RUN, чтобы посмотреть, будут ли загружаться ещё какие-нибудь подозрительные функции.

Хорошо, уже знаем, чем это рискованно – для того, чтобы принудительного завершить процесс нужно получить логический номер (о чём мы говорили в главе 20), а это делается с помощью OpenProcess, так что дойдём до RET и установим BP EAX также и на эту функцию.

Другая подозреваемая в убийстве процессов, хе-хе, пока что таким же образом установим на неё и её сестрёнку Process32Next.

Дальше идёт TerminateProcess.

Мы уже знаем, что эта функция закрывает OllyDbg. Пока что не будем устанавливать BP, но эта функция всегда является кандидатом на точку останова, хе-хе.

Другая преступница, хе-хе, устанавливаем на неё BP вышеописанном способом.

В следующий раз мы останавливаемся на API-функции CreateToolhelp32SnapShot.

Стек:

Посмотрим описание этой функции.

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

И в EAX получаем логический номер.

Который в моём случае равен 2C. Мы можем посмотреть информацию о нём с помощью Олли.

Нажмём кнопку H, что откроет окно логических номеров.

Не слишком понятно, что такое 2C, но ладно, программа получала этот номер, сделаем RUN, чтобы посмотреть, как его получить с его помощью доступ к указанному списку процессов.

Останавливаемся на API-функции Process32First, которая вместе c Process32Next служит для чтения полученного моментального снимка, извлекая информацию о выполняющихся процессах.

Ок, вот описание этой функции.

Здесь говорится, что функция получает информацию о первом процессе, записанном в моментальном снимке, чей логический номер передаётся в первом параметре (в моём случае это 2C). Вторым параметром является адрес буфера, куда собственно помещается информация.

Эта API-функция возвращает информацию только о первом процессе в списке, а для остальных надо использовать Process32Next.

Буфер, куда сохраняется информация о первом процессе, виден через DUMP, так что делаем «Execute till RET», чтобы она там появилась.

Видим имя первого процесса, которое всегда будет «SYSTEM PROCESS». Делаем RUN и продолжаем.

Ха-ха, а здесь другой трюк, использующий FindWindowA. Окно OllyDbg относится к одноимённому классу, так что можно искать отладчик по имени окна. В данном случае запрашивается класс окна, являющимся главным по отношению к текущему, которым, очевидно, является OllyDbg.

Класс окна можно узнать с помощью следующей утилиты.

http://www.ricnar456.dyndns.org/HERRAMIENTAS/V-W-X-Y-Z/WindowseGREATIS5setup.exe

Я знаю, что существуют плагины для OllyDbg, которые позволяют выяснить класс и другую информацию об окне, но, по правде говоря, эта программа предоставляет куда более подробные сведения, так что установим и запустим её.

Видим, что во вкладке «Window» выводится имя окна OllyDbg, а во вкладе «Class» - его класс.

Как видим это OllyDbg.

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

То есть нет необходимости передавать оба параметра - и имя и класс, можно искать только по одному из них, а вместо другого передать ноль.

Хорошо, доходим до RET в API-функции, чтобы посмотреть, вернёт ли она логический номер окна.

Конечно, он совпадает с тем, который отображается в Windowse.

Ладно, трассируем дальше, чтобы посмотреть, что программа делает с окном.

То есть, сравнивает полученный номер с нулём, и если он ему равен, то значит, нет окна с классом OllyDbg, а значит и такого процесса нет. Если же было возвращено значение отличное от нуля, то значит, существует окно с таким классом, и программа вызывает ExitProcess.

Переход сразу ведёт к выходу программ без отображения каких-либо сообщений.

То есть суть в том, что нам нужно, чтобы FindWindowA вернула в EAX ноль.

Ок, плагин HideDebugger 1.23f позволяет не делать это вручную. Откроем его настройки.

Если отметим вторую опцию, то плагин станет защищать нас от обнаружения с помощью FindWindow и EnumWindows (это другая функция, с помощью которой можно узнать имя окна), но нам нужно научиться избегать этих функции вручную и понимать, как это работает, поэтому пока что галочку ставить не будем, так как надо будет перезапустить OllyDbg, чтобы это оказало необходимый эффект. Сделаем так, чтобы переход, который отправляет нас к функции ExitProcess, не был совершён, и выполнение программы продолжилось.

Кликаем два раза на флаге Z, меняем его значение на 1, после чего JNZ не должен совершить переход.

И правда, JNZ не срабатывает.

И доходим до JMP, перепрыгивающего через вызов ExitProcess.

Ок, продолжаем, мы изучили, как предотвратить приём с FindWindowA, а теперь продолжим изучать метод, использующий имена процессов. Делаем RUN.

Видим, что вызывается Process32Next, чтобы получить информацию о втором процессе из моментального снимка, которая сохраняется в 403134.

Делаем EXECUTE TILL RETURN и смотрим, что было сохранено.

Здесь находится имя «System» и его PID, равный 4. Посмотрим список процессов.

Здесь видим, что программа делает с каждым процессом. Трассируем.

Видим, что здесь вызывается API-функция lstrcmpA, с помощью которой сравнивается строка «System», являющейся именем процесса, с «buggers3.exe», т.е. именем процесса самого крэкми. Если они равны, то вызывается MessageBoxA, сообщающий «NOT DEBUGGED». Но в данном случае мы сюда не попадём, так что продолжаем трассировать.

Если строки не равны, то результатом сравнения является FFFFFFFF.

И так как это не ноль, то переходим в 40119f.

Здесь видим насыщенную действием часть программы: сравнивается имя первого процесса с «OLLYDBG.EXE», и если они равны, тогда результатом является ноль и перехода не происходит, в следствии чего вызывается OpenProcess, чтобы узнать логический номер процесса, а потом – TerminateProcess, закрывающий его, как это мы уже видели в главе 20-ой.

Видим, что первый процесс не является OllyDbg.exe, поэтому переходим на Process32Next, чтобы найти второй процесс.

В то же место сохраняется имя второго процесса. Делаем EXECUTE TILL RETURN.

Второй процесс – это smss.exe, чей PID равен 026C. Заглянем в список процессов.

Вот PID, равный 620 в десятеричной системе, то есть 026C в шестнадцатеричной.

Хорошо, похоже, что все выполняющиеся процессы сравниваются один за другим c «OLLYDBG.EXE».

И каждый раз условный переход будет переносить нас на 4011B1, до тех пор, пока не встретиться процесс OLLYDBG.exe. Тогда перехода не произойдёт и Олли будет закрыта, так что если мы заменим JNZ на JMP, то избежим этого.

Теперь убираем все точки останова и делаем RUN.

Таким образом, защита была побеждена. Сейчас мы уже знаем, что плагин HideDebugger позволяет спрятать окно OllyDbg от обнаружения с помощью FindWindowA. Также можно попробовать избежать обнаружения процесса и выполнить программу, используя упомянутый ранее способ переименования OllyDbg в PIRULO.exe.

Откроем PIRULO.exe.

Отметим галочкой опцию, включающей защиту от FindWindowA, и нажмём SAVE.

Потом перезапустим OllyDbg.

И откроем buggers3, но прежде я хочу избавиться от сомнений, поэтому посмотрю, что сделал плагин с окном Олли, чтобы оно не было обнаружено.

Видим, что имя OLLYDBG не отображается в заголовке окна, а класс?

Видим, что от нахождения по классу плагин нас не защитил, поэтому надо искать другой способ.

Утилита, которая должна помочь нам с тем, что не смог сделать плагин, называется Repair 0.6. Это патчер OllyDbg, и его можно скачать отсюда.

http://www.ricnar456.dyndns.org/HERRAMIENTAS/Q-R-S-T-U/repair0.6.zip

Скачаем, а потом закроем OllyDbg и запустим патчер.

Так что теперь у нас есть третий файл OllyDbg, который называется NVP11.exe. Заглянем в папку, где он находится.

Запустим его и посмотрим, какой у него класс окна.

Видим, что класс окна – это «Nvp11», так же как и имя процесса, а значит, buggers3 теперь должен выполняться превосходно, не требуя каких-либо изменений в нём. Пробуем.

Делаем RUN и…

Хочу сказать, что наш пропатченный OllyDbg с каждым днём становится всё менее подверженным обнаружению, теперь его нельзя найти ни по имени процесса, ни по имени или классу окна, хе-хе, в главе 22 продолжим укреплять отладчик и изучать, как работают другие методы и способы антиотладки, как их понять, как победить вручную и, наконец, какой плагин применить, чтобы не слишком перетрудиться, хе-хе.

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

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

Эти два флага показывают, что процесс находится под отладкой, их легко найти. Если вы не можете вспомнить, как найти область, где находится байт IsDebuggerPresent, то прочитайте главу 19, в которой объясняется как найти её врунчную, так как эти флаги располагаются неподалёку.

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

Чтобы попрактиковаться с этими флагами, будем использовать крэкми Cruehead'а I, в котором и отыщем оба из них.

Откроем его в OllyDbg, предварительно убедившись, что настройка, указанная на картинке выше, отключена.

Хорошо, теперь посмотрим, как найти и изменить оба эти флага вручную.

Их можно найти в той же области, где находится и байт IsDebuggerPresent, о котором рассказывалось в 19-ой главе. Простой способ заключается в том, чтобы прямо на точке входа отметить EBX и выбрать FOLLOW IN DUMP, а о полном варианте, если вы его забыли, прочитайте в вышеуказанной главе.

Находим на точке входа.

Отмечаем EBX-FOLLOW IN DUMP.

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

Разумеется, мы помним, что этот байт заполняется API-функцией IsDebuggerPresent, а NTGlobalFlag находится по соседству - надо прибавить 68 к адресу, который находился в EBX, в моём случае EBX содержал 7ffda000, прибавляем 68 и получается 7ffda068.

Это и есть знаменитый NTGlobalFlag, значение которого отличается от нуля, если есть отладчик и ноль, если нет, так что можем вручную выставить его значение в ноль.

Помещаем сюда ноль.

Так мы нашли флаг NtGlobalFlag и поместили в него ноль.

Теперь нужно найти другой флаг ProcessHeap, что также нетрудно сделать.

К значение, которое содержится в EBX на точке входа, надо прибавить 18, это адрес, по которому в моём случае лежит 014000, это тоже адрес - адрес "кучи", то есть область памяти, созданная при запуске программы, куда та может помещать какие-то свои данные, не будем заострять на этом много внимания.

Идём посмотреть, что находится в "куче".

Отмечаем байти и выбираем FOLLOW DWORD IN DUMP, что перенесёт нас в область памяти, зарезервированной под "кучу".

И прибавляем 10 к исходному адресу кучи, это отмеченный на картинке dword, в котором содержится ноль, если отладчика нет, значит сейчас там ноль из-за установленных плагинов, поэтому откроем крэкми в OllyDbg без плагинов.

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

Теперь вернёмся, чтобы включить настройки в HideOdb.

И перезапустим крэкми cruehead'а.

Видим, что остановились на точке входа, флаги IsDebbuggerPresent, как и NtGlobalFlag равны нулю, и поищем ProcessHeapFlag.

Он также равен нулю, то есть плагин работает правильно. Кроме того, мы научились искать и менять эти флаг вручную.

Последний противооллиный приём также предотвращается установленными плагинами.

И

Текст на картинке гласит:

"Хорошо, таким же образом я понял, что проблема связана с противооллиным приёмом, основанный на OutputDebugString и использованный данной программой. Этот приём заключается в передаче Олли специально подготовленной строки, которую та не может обработать, и происходит ошибка, закрывающая OllyDbg. В реальности я никогда не встречался с этим, так как плагин HideDebugger нейтрализует данный антиотладочный метод и выдаёт следующее сообщение:

Способ реализации очень прост: вызывается OutputDebugStringA, которой передаётся строка, состоящая из множества символов %s, я насчитал 100d:"

Это описание из прекрасного туториала. Плагины позаботятся об этом баге OllyDbg в лучшем виде.

Чтобы попрактиковаться, вот крэкми (находится в архиве wasm_files.zip: files/0479/antisocial1.zip), где применяются все приёмы, о которых рассказывалось в главах, посвящённых антиотладке, плюс пара других, хе-хе. Идея в том, чтобы запустить его в OllyDbg с отключенными плагинами, и вручную обезвредить антиотладочные приёмы. Для этого вам потребуется немного воображения, например, там есть приём, который можно победить, забив строку нопами. Чтобы обнаружить такие места, нужно зайти в DEBUGGIN OPTION-EXCEPTIONS и убрать все галочки, так как при использовании INT68 генерируется ошибка, которая, если эти настройки включены, приведёт к тому, что Olly не выдаст нам предупреждение об исключении и просто закроется.

То есть, знайте, что если остановились на каком-то исключении (которое не было отмечено в настройках), то нужно нажать SHIFT+F9, чтобы миновать его. Мы рассмотрим это подробнее в следующей главе. Но если исключение генерируется через INT68, то надо забить NOPами это место и сделать RUN, чтобы пройти его без каких-либо проблем.

И в качестве развлечения, можете попробовать запустить крэкми со всеми плагинами, помотреть, как действует INT68 и выполнится ли программа, а во второй раз уже откройте в OllyDbg без плагинов и попытаться избежать все приёмы вручную, хе-хе.

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

Сначала загрузим её в переименованную OllyDbg со всеми плагинами, чтобы посмотреть, почему не крэкми не выполняется и попытаться это исправить.

Итак, запускаем antisocial в переименованном и пропатченном OllyDbg со всеми доступными плагинами.

Это уже даёт нам идею о том, что программа может быть запакована. Оказываемся на точке входа.

Здесь видим что-то странное, а именно инструкцию POPAD, которая служит для получения значений из стека, помещённых туда ранее с помощью PUSHAD, а никаких PUSHAD до этого нет, что весьма подозрительно.

Запускаем, чтобы посмотреть, до куда дойдёт.

Досюда.

То есть, когда крэкми пытается сделать PUSH, выдётся ошибка, что нет прав писать в стек, но права писать в стек должны быть всегда. Взглянем на стек.

То есть, значение наверху стека равно 130000, и если рестартуем программу:

Посмотрим секции и увидим, что стек на моей машине идёт с 12c000 до 12ffff, ошибка возникает, потому что стек выше за пределы своей секции на другую, которая начинается с 130000, а туда-то писать как раз прав и нет.

Вернёмся обратно в место, где произошла ошибка.

Видим, что программа выполняет ещё один popad и совершает JNZ-переход на PUSH, который также вызывает ошибку. Установим BPX на этот popad до того, как произойдёт ошибка.

Теперь перезагрузим программу, сделаем RUN и остановимся здесь.

Смотрим стек.

Находимся в правильной секции. Запускается POPAD.

Здесь заканчивается секция, так что проблему можно решить, забив POPAD NOP’ами, но вообще, POPAD должен предшествоваться PUSHAD, которая сохраняет начальные значения регистров в стек, а этот POPAD тогда будет получать их обратно, поэтому давайте посмотрим, что будет, если заменить POPAD на PUSHAD. Рестартуем программу.

Нажимаем пробел.

Пишем PUSHAD.

Теперь нажимаем RUN и останавливаемся на второй POPAD.

Но в этот раз стек в порядке.

Поэтому POPAD не выходит за границу секции стека, и мы можем миновать это место с помощью F8.

Видим, что всё прошло без проблем.

Доходим до PUSH и RET, трассируем и, нажимая на F8, доходим до RET.

Хорошо, здесь есть проблема с анализированием.

Здесь это особенно видно.

Посмотрим, что случится, если сделаем RUN.

Так как программа завершилась, посмотрим в LOG’е OllyDbg, есть ли там что-нибудь интересное.

Видим, что возникло исключение после точки останова на POPAD. Рестартуем и повторим все шаги, чтобы оказаться там, где были.

Уберём галочки со всех опций, которые относятся к исключениям.

Делаем RUN.

Останавливаемся на исключении, что отображается в LOG’е.

INT68 – одно из немногих исключений, которое OllyDbg не может избежать, но можем забить его NOP’ами.

С другой стороны, знаем, что могут быть ещё INT68, которые будут мешать, поэтому поищем их и также забьём NOP’ами.

Видим, что нашлось ещё одно исключение, забиваем его NOP’ами.

Ищем заново, находим, забиваем NOP’ами.

Если нажмём CTRL + L, то продолжим искать то, что искали в последний раз.

Когда ничего больше не находим, делаем RUN.

Как видим, это всё, что нужно сделать, чтобы запустить крэкми из-под OllyDbg с плагинами, а теперь попытаемся сделать тоже самое, но без плагинов, переименования и патчевания.

Я распаковал OllyDbg без плагинов, всё, что есть – это command bar, так что никакой защиты. Для этого используем другую директорию и другой путь, указывающий на плагины.

Как видим, здесь только один плагин. Запускаем OllyDbg.

Повторяем операции по замене popad.

Устанавливаем BPX на POPAd, нажимаем RUN и смотрим, куда попадём.

Прибываем туда, где распаковывается код программы.

Можем забить INT68 или снять галочки с исключений, и каждый раз, останавливаясь на INT68, забивать его NOP’ами, а не идти дальше с помощью SHIFT+F9, как это мы обычно делаем с другими исключениями.

Посмотрим, какие API-функции используются в программе, для чего нужно вспомнить следующую настройку:

Необходимо отметить её, чтобы отображалась информация о секции, в которой мы сейчас находимся.

Отлично, видим, что подозрительных API-функций нет, но их используется очень мало, а также есть GetProcAddress для загрузки новых, поэтому ставим на неё BPX.

Жмём RUN.

Ничего подозрительного нет, продолжаем нажимать RUN, пока не встретится что-нибудь странное.

Здесь нам повстречалась первая странность: API-функция, которая делает снимок состояния всех выполняющихся процессов. Доходим до RET и ставим BP EAX, так как EAX будет содержать адрес функции.

Там, где находится BP, оставим комментарий, чтобы не забыть, к какой API-функции это относится.

Список продолжается.

Ещё что-то похожее на прошлый случай, на всякий случай поставим BP и сюда.

Жмём RUN.

Ставим BP на неё.

То же самое.

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

Видим пустые пробелы (NOP’ы), так что можем сделать EAX равным нулю, до того как его значение будет возвращено.

Так мы возвращаем ноль, и у программы нет логического номера, с помощью которого она могла бы обработать снимок или что-то узнать о процессах. Это один способ, а другой состоит в изменении кода самой программы. Выполним неизменённый RET функции.

Чуть пониже есть JNZ-переходы, а ещё чуть ниже их – вызов TerminateProcess, который закрывает OllyDbg, и перед которым есть OpenProcess, получающая логический номер программы.

Если заменить все JNZ на JMP, можно избежать перехода на TerminateProcess и закрытия OllyDbg.

Первая часть защиты преодолена, теперь переходим ко второй части. Жмём RUN.

Забиваем NOP’ами, запускаем выполнение программы, но она всё равно закрывается. Если поставить плагин HideDebugger, который защищает от FindeWindows/EnumWindows, то выполнится нормально, если повторить сделанные до этого шаги.

Место, где происходит закрытие, следующее:

Выполняем программу и когда останавливаемся на верхнем вызове,

Видим, что здесь сравнивается.

Вопрос в том, как избежать сравнения этих нехороших вещей, хе-хе, можно сделать это, заменив JNZ, который стоит после первого CALL, на JMP.

Этот загадочный переход заменяется на JMP.

Избегаем второго CALL, внутри которого находится следующее.

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

Конечно, если спросите меня, как найти этот JNZ, то это легко.

Как только прошли первую часть защиты, устанавливаем BPX на PostQuitMessage.

Останавливаемся на API, смотрим на стек, чтобы узнать, откуда вызывается.

Идём в 4532d7, так что стек расскажет, откуда происходит вызов.

Конечно, я попробовал изменить JE, стоящий перед PostQuitMessage, на обратный и не смог избежать закрытия окна, так что идём ко втором RETURN TO, который есть в стеке.

Он ведёт в 4532СС.

Как видим, этот call можно избежать, обратив JNZ, и тогда не будет вызван и PostQuitMessage, и изменив JNZ на JMP видим, что крэкми выполняется без помощи каких-либо плагинов.

К статье приложен (находится в архиве wasm_files.zip: files/recovered/480/muysocial.rar) распакованный крэкми, выполняющийся под OllyDbg без каких-либо ухищрений. В этом курсе вы не будете учиться распаковке, но если вам интересен этот крэкми, то вы можете использовать приложенный файл, чтобы посмотреть, как он работает. С него уже снята распаковка и внесены необходимые изменения, чтобы он запускался под Олли без плагинов.

До встречи в 25-ой главе, где мы будем изучать исключения.