Обратите внимание на выделенные жирным шрифтом ключевые слова "если", "то" и "иначе", называемые операторами условия или условными операторами. Без них не обходится ни одна программа (вырожденные примеры наподобие "Hello, World!" - не в счет). Условные операторы - сердце любого языка программирования. Поэтому, чрезвычайно важно уметь их правильно идентифицировать.

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

Задача компилятора - преобразовать эту конструкцию в последовательность машинных команд, выполняющих оператор_1, оператор_2, если условие истинно и, соответственно - оператор_a, оператор_b; если оно ложно. Однако микропроцессоры серии 80x86 поддерживают весьма скромный набор условных команд, ограниченный фактически одними условными переходами. Программистам, знакомым лишь с IBM PC, такое ограничение не покажется чем-то неестественным, между тем, существует масса процессоров, поддерживающих префикс условного выполнения инструкции. Т.е. вместо того, чтобы писать:

там поступают так:

"IFZ" - и есть префикс условного выполнения, разрешающий выполнение следующей команды только в том случае, если установлен флаг нуля.

В этом смысле микропроцессоры 80x86 можно сравнить с ранними диалектами языка Бейсика, не разрешающими использовать в условных выражениях никакой другой оператор кроме "GOTO". Сравните:

Если вы когда-нибудь программировали на старых диалектах Бейсика, то, вероятно, помните, что гораздо выгоднее выполнять GOTO если условие ложно, а в противном случае продолжать нормальное выполнение программы. (Как видите, вопреки расхожему мнению, навыки программирования на Бейсике отнюдь не бесполезны, особенно - в дизассемблировании программ).

Большинство компиляторов (даже не оптимизирующих) инвертируют истинность условия, транслируя конструкцию

в следующий псевдокод:

Следовательно, для восстановления исходного текста программы, нам придется вновь инвертировать условие и "подцепить" блок операторов {оператор_1; оператор_2} к ключевому слову THEN. Т.е. если откомпилированный код выглядит так:

Можно с уверенностью утверждать, что в исходном тексте присутствовали следующие строки: "IF A=B THEN PRINT "A=B"". А если, программист, наоборот, проверял переменные A и B на неравенство, т.е. "IF A<>B THEN PRINT "A<>B""? Все равно компилятор инвертирует истинность условия и сгенерирует следующий код:

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

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

Рассмотрим теперь как транслируется полная конструкция

Одни компиляторы поступают так:

А другие так:

Разница межу ними в том, что вторые инвертируют истинность условия, а первые - нет. Поэтому, не зная "нрава" компилятора, определить: как выглядел подлинный исходный текст программы - невозможно! Однако это не создает проблем, ибо условие всегда можно записать так, как это удобно. Допустим, не нравится вам конструкция "IF (c<>0) THEN a=b/c ELSE PRINT "Ошибка!"" пишите ее так: "IF (c==0) THEN PRINT "Ошибка!" ELSE a=b/c" и - ни каких гвоздей!

Типы условий: Условия делятся на простые (элементарные) и сложные (составные). Пример первых - "if (a==b)...", вторых "if ((a==b) && (a!=0))...". Очевидно, что любое сложное условие можно разложить на ряд простых условий. Вот с простых условий мы и начнем.

Существуют два основных типа элементарных условий: условия отношений ("меньше", "равно", "больше", "меньше или равно", "не равно", "больше или равно", соответственно обозначаемые как: "<", "==", ">", "<=", "!=", ">=") и логические условия ("И", "ИЛИ", "НЕ", "И исключающее ИЛИ", в Си-нотации соответственно обозначаемые так: "&", "|", "!", "^"). Известный хакерский авторитет Мэтт Питрек приплетает сюда и проверку битов, однако несколько некорректно смешивать в одну кучу людей и коней, даже если они чем-то и взаимосвязаны. Поэтому, о битовых операциях мы поговорим отдельно.

Если условие истинно, оно возвращает булево значение TRUE, соответственно, если ложно - FALSE. Внутренне (физическое) представление булевых переменных зависит от конкретной реализации и может быть любым. По общепринятому соглашению, FALSE равно нулю, а TRUE не равно нулю. Часто (но не всегда) TRUE равно единице, но на это нельзя полагаться! Так, код "IF ((a>b)!=0)Е" абсолютно корректен, а: "IF ((a>b)==1)Е" привязан к конкретной реализации и потому нежелателен.

Обратите внимание: "IF ((a>b)!=0)Е" проверяет на неравенство нулю отнюдь не значения самих переменных a и b, а именно - результата их сравнения. Рассмотрим следующий пример: "IF ((666==777)==0) printf("Woozl!")" - как вы думаете, что отобразится на экране, если его запустить? Правильно - "Woozl"! Почему? Ведь ни 666, ни 777 не равно нулю! Да, но ведь 666 != 777, следовательно, условие (666==777) - ложно, следовательно равно нулю. Кстати, если записать "IF ((a=b)==0)Е" получится совсем иной результат - значение переменной b будет присвоено переменной a, и потом проверено на равенство нулю.

Логические условия чаще всего используются для связывания двух или более элементарных условий отношения в составное. Например, "IF ((a==b) && (a!=0))Е". При трансляции программы компилятор всегда выполняют развертку составных условий в простые. В данном случае это происходит так: "IF a==b THEN IF a=0 THENЕ" На втором этапе выполняется замена условных операторов на оператор GOTO:

Порядок вычисления элементарных условий в сложном выражении зависит от прихотей компилятора, гарантируется лишь, что условия, "связанные" операцией логического "И" проверяются слева направо в порядке их объявления в программе. Причем, если первое условие ложно, то следующее за ним вычислено не будет! Это дает возможность писать код наподобие следующего: "if ((filename) & (f=fopen(&filename[0],"rw")))Е" - если указатель filename указывает на невыделенную область памяти (т.е. попросту говоря содержит нуль - логическое FALSE), функция fopen не вызывается и ее краха не происходит. Такой способ вычислений получил название "быстрых булевых операций" (теперь-то вы знаете, что подразумевается под "быстротой").

Перейдем теперь к вопросу идентификации логических условий и анализу сложных выражений. Вернемся к уже облюбованному нами выражению "if ((a==b) && (a!=0))Е" и вглядимся в результат его трансляции:

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

Идентификация логической операции "ИЛИ" намного сложнее в силу неоднозначности ее трансляции. Рассмотрим это на примере выражения "if ((a==b) || (a!=0))...". Его можно разбить на элементарные операции и так:

и так:

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

Однако оптимизирующие компиляторы выкидывают безусловный переход, инвертируя проверку последнего условия в цепочке и, соответственно меняя адрес перехода. По неопытности эту конструкцию часто принимают за смесь OR и AND. Кстати, о смещенных операциях - рассмотрим результат трансляции следующего выражения: "if ((a==b) || (a==c) && a(!=0))...":

Как из непроходимого леса элементарных условий получить одно удобочитаемое составное условие? Начинаем плясать от печки, т.е. от первой операции сравнения. Смотрите, если условие a==b окажется истинно, оно "выводит из игры" проверку условия a!=c. Такая конструкция характерна для операции OR - т.е. достаточно выполнения хотя бы одного условия из двух для "срабатывания" кода. Пишем в уме или карандашом: "if ((a==b) || ...)", далее - если условие (a!=c) истинно, все дальнейшие проверки прекращаются, и происходит передача управления на метку, расположенную позади условного кода. Логично предположить, что мы имеем дело в последней операцией OR в цепочке сравнений - это ее "почерк". Значит, мы инвертируем условие выражения и продолжаем писать: "if ((a==b) || (a==c)Е)". Последний бастион - проверка условия "a==0". Выполнить условный код, миновав его не удаться, - следовательно, это не OR, а AND! А AND всегда инвертирует условие срабатывания, и поэтому, оригинальный код должен был выглядеть так: "if ((a==b) || (a==c) && (a!=0))". Ура! У нас получилось!

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

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

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

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

Выход - в использовании двухуровневой системы ретрансляции. На первом этапе элементарные условия преобразуются к некоторой промежуточной форме записи, наглядно и непротиворечиво отображающей взаимосвязь элементарных операций. Затем осуществляется окончательная трансляция в любую подходящую нотацию (например, Си, Бейсик или Pascal).

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

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

Рисунок 22. 0х015 Схематическое представление гнезда (nest)

Гнезда могут объединяться в деревья, соединясь узлами с ветками другого узла. Причем, каждый узел может соединяться только с одним гнездом, но всякое гнездо может соединяться с несколькими узлами. Непонятно? Не волнуйтесь, сейчас со всем этим мы самым внимательным образом разберемся.

Рассмотрим объединение двух элементарных условий логической операцией "AND" на примере выражения "((a==b) && (a!=0))". Извлекаем первое слева условие (a==b), "усаживаем" его в гнездо с двумя ветвями: левая соответствует случаю, когда a!=b (т.е. условие a==b - ложно), а правая, соответственно, - наоборот. Затем, то же самое делаем и со вторым условием (a!=0). У нас получаются два очень симпатичных гнездышка, - остается лишь связать их меж собой операцией логического "AND". Как известно, "AND" выполняет второе условие только в том случае, если истинно первое. Значит, гнездо (a!=0) следует прицепить к правой ветке гнезда (a==b). Тогда - правая ветка гнезда (a!=0) будет соответствовать истинности выражения "((a==b) && (a!=0))", а обе левые ветки - его ложности. Обозначим первую ситуацию меткой "do_it", а вторую - "continue". В результате дерево должно принять вид, изображенный на рис. 23.

Для наглядности отметим маршрут из вершины дерева к метке "do_it" жирной стрелкой. Как видите, в пункт "do_it" можно попасть только одним путем. Вот так графически выглядит операция "AND".

Рисунок 23. 0х016 Графическое представление операции AND в виде двоичного дерева. Обратите внимание - в пункт do_it можно попасть только одним путем!

Перейдем теперь к операции логического "OR". Рассмотрим конструкцию "((a==b) || (a!=0))". Если условие "(a==b)" истинно, то и все выражение считается истинным. Следовательно, правая ветка гнезда "(a==b)" связана с меткой "do_it". Если же условие же "(a==b)" ложно, то выполняется проверка следующего условия. Значит, левая ветка гнезда "(a==b)" связана с гнездом "(a!=b)". Очевидно, если условие "(a!=b)" истинно, то истинно и все выражение "((a==b) || (a!=0))", напротив, если условие "(a!=b)" ложно, то ложно и все выражение, т.к. проверка условия "(a!=b)" выполняется только в том случае, если условие "(a==b)" ложно. Отсюда мы заключаем, что левая ветка гнезда "(a!=b)" связана с меткой "continue", а правая - с "do_it". (см. рис. 24). Обратите внимание - в пункт "do_it" можно попасть двумя различными путями! Вот так графически выглядит операция "OR".

Рисунок 24. 0х017 Графическое представление операции OR в виде двоичного дерева. Обратите внимание - в пункт do_it можно попасть двумя различными путями!

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

Извлекаем условие (a==b) и сажаем его в "гнездо", - смотрим: если оно ложно, то выполняется проверка (a!=c), значит, гнездо (a!=c) связано с левой веткой гнезда (a==b). Если же условие (a==b) истинно, то управление передается метке check_null, проверяющей истинность условия (a==0), следовательно, гнездо (a==0) связано с правой веткой гнезда (a==b). В свою очередь, если условие (a!=с) истинно, управление получает метка "continue", в противном случае - "check_null". Значит, гнездо (a!=0) связано одновременно и с правой веткой гнезда (a==b) и с левой веткой гнезда (a!=c).

Конечно, это проще рисовать, чем описывать! Если вы все правильно зарисовали, у вас должно получится дерево очень похожее на изображенное на рисунке 25.

Смотрите: к гнезду "(a==0)" можно попасть двумя путями - либо через гнездо (a==b), либо через цепочку двух гнезд (a==b) а (a!=c). Следовательно, эти гнезда связаны операцией OR. Записываем: "if ( (a==b) || !(a!=c)Е.)". Откуда взялся NOT? Так ведь гнездо (a==0) связано с левой веткой гнезда (a!=с), т.е. проверяется ложность его истинности! (Кстати, "ложность истинности" - очень хорошо звучит). Избавляемся от NOT, инвертируя условие: "if ( (a==b) || (a==c)Е.)Е". Далее - из гнезда (a==0) до пункта do_it можно добраться только одним путем, значит, оно связано операцией AND. Записываем: "if (((a==b) || (a==c)) && !(a==0))Е". Теперь избавляемся от лишних скобок и операции NOT. В результате получается: "if ((a==b) || (a==c) && (a!=0)) {// Код условия}"

Не правда ли все просто? Причем вовсе необязательно строить деревья вручную, - при желании можно написать программу, берущую эту работу на себя.

Рисунок 25. 0х018 Графическое представление сложного выражения

Исследование конкретных реализаций. Прежде чем приступать к отображению конструкции "IF (сложное условие) THEN оператор_1:оператор_2 ELSE оператор_а:оператор_b" на машинный язык, вспомним, что, во-первых, агрегат "IF - THEN - ELSE" можно выразить через "IF - THEN", во-вторых, "THEN оператор_1:оперратор_2" можно выразить через "THEN GOTO do_it", в-третьих, любое сложное условие можно свести к последовательности элементарных условий отношения. Таким образом, на низком уровне мы будем иметь дело лишь с конструкциями "IF (простое условие отношения) THEN GOTO do_it", а уже из них, как из кирпичиков, можно сложить что угодно.

Итак, условия отношения, или другими словами, результат операции сравнения двух чисел. В микропроцессорах Intel 80x86 сравнение целочисленных значений осуществляется командой CMP, а вещественных - одной из следующих инструкций сопроцессора: FCOM, FCOMP, FCOMPP, FCOMI, FCOMIP, FUCOMI, FUCOMIP. Предполагается, что читатель уже знаком с языком ассемблера, поэтому не будем подробно останавливаться на этих инструкциях и рассмотрим их лишь вкратце.

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

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

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

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

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

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

В общем случае конструкция "IF (элементарное условие отношения) THEN do_it" транслируется в следующие команды процессора:

Между инструкциями "CMP" и "Jxx" могут находиться и другие команды, не изменяющие флагов процессора, например "MOV", "LEA".

Таблица 16. Соответствие операций отношения командам процессора

::сравнение вещественных чисел. Команды сравнения вещественных чисел FCOMxx (см. таблицу 18) в отличие от команд целочисленного сравнения воздействуют на регистры сопроцессора, а не основного процессора. На первый взгляд - логично, но весь камень преткновения в том, что инструкций условного перехода, управляемых флагами сопроцессора, не существует! К тому же, флаги сопроцессора непосредственно недоступны, - чтобы прочитать их статус необходимо выгрузить регистр состояния сопроцессора SW в память или регистр общего назначения основного процессора.

Хуже всего - анализировать флаги вручную! Если при сравнении целых чисел можно и не задумываться: какими именно флагами управляется условный переход, достаточно написать, скажем: "CMP A,B; JGE do_it". ("Jump [if] Great [or] Equal" - прыжок, если A больше или равно B), то теперь этот номер не пройдет! Правда, можно схитрить и скопировать флаги сопроцессора в регистр флагов основного процессора, а затем использовать "родные" инструкции условного перехода из серии Jxx.

Конечно, непосредственно скопировать флаги из сопроцессора в основной процессор нельзя и эту операцию приходится осуществлять в два этапа. Сначала флаги FPU выгружать в память или регистр общего назначения, а уже оттуда заталкивать в регистр флагов CPU. Непосредственно модифицировать регистр флагов CPU умеет только одна команда - POPF. Остается только выяснить - каким флагам сопроцессора, какие флаги процессора соответствуют. И вот что удивительно - флаги 8й, 10й и 14й сопроцессора совпадают с 0ым, 2ым и 6ым флагами процессора - CF, PF и ZF соответственно (см. таблицу 17). То есть - старшей байт регистра флагов сопроцессора можно безо всяких преобразований затолкать в младший байт регистра флагов процессора и это будет работать, ноЕ при этом исказятся 1й, 3й и 5й биты флагов CPU, никак не используемые в текущих версиях процессора, но зарезервированные на будущее. Менять значение зарезервированных битов нельзя! Кто знает, вдруг завтра один из них будут отвечать за самоуничтожение процессора? Шутка, конечно, но в ней есть своя доля истины.

К счастью, никаких сложных манипуляций нам проделывать не придется - разработчики процессора предусмотрели специальную команду - SAHF, копирующую 8й, 10й, 12й, 14й и 15й бит регистра AX в 0й, 2й, 4й, 6й и 7й бит регистра флагов CPU соответственно. Сверяясь по таблице 17 мы видим, что 7й бит регистра флагов CPU содержит флаг знака, а соответствующий ему флаг FPU - признак занятости сопроцессора!

Отсюда следует, что для анализа результата сравнения вещественных чисел использовать знаковые условные переходы (JL, JG, JLE, JNL, JNLE, JGE, JNGE) нельзя! Они работают с флагами знака и переполнения, - естественно, если вместо флага знака им подсовывают флаг занятости сопроцессора, а флаг переполнения оставляют в "подвешенном" состоянии, условный переход будет срабатывать не так, как вам бы этого хотелось! Применяйте лишь беззнаковые инструкции перехода - JE, JB, JA и др. (см. таблицу 16)

Разумеется, это не означает, что сравнивать знаковые вещественные значения нельзя, - можно, еще как! Но для анализа результатов сравнения обязательно всегда использовать только беззнаковые условные переходы!

Таким образом, вещественная конструкция "IF (элементарное условие отношения) THEN do_it" транслируется в одну из двух следующих последовательностей инструкций процессора:

Первый вариант более нагляден, зато второй работает быстрее. Однако, такой код (из всех известных мне компиляторов) умеет генерировать один лишь Microsoft Visual C++. Borland C++ и хваленый WATCOM C испытывают неопределимую тягу к инструкции SAHF, чем вызывают небольшие тормоза, но чрезвычайно упрощают анализ кода, - ибо, встретив команду наподобие JNA, мы и спросонок скажем, что переход выполняется когда a <= b, а вот проверка битвой маски "TEST AH, 0x41/JNZ do_it" заставит нас крепко задуматься или машинально потянуться к справочнику за разъяснениями (см. таблицу 16)

Команды семейства FUCOMIxx в этом смысле гораздо удобнее в обращении, т.к. возвращают результат сравнения непосредственно в регистры основного процессора, но - увы - их "понимает" только Pentium Pro, а в более ранних микропроцессорах они отсутствуют. Поэтому, вряд ли читателю доведется встретиться с ними в реальных программах, так что не имеет никакого смысла останавливаться на этом вопросе. Во всяком случае, всегда можно обратится к странице 3-112 руководства "Instruction Set Reference", где эти команды подробно описаны.

Таблица 18. Команды сравнения вещественных значений

Таблица 19. Назначение и битовые маски флагов сопроцессора

Таблица 20. Состояние регистров флагов для различных операций отношения. 'a' - левый, а 'b' правый операнд команды сравнения вещественных значений

Таблица 21. "Характер" некоторых компиляторов

Условные команды булевой установки. Начиная с 80386 чипа, язык микропроцессоров Intel обогатился командой условной установки байта - SETxx, устанавливающей свой единственный операнд в единицу (булево TRUE), если условие "xx" равно и, соответственно, сбрасывающую его в нуль (булево FALSE), если условие "xx" - ложно.

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

Таблица 22. Условные команды булевой установки

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

::Команды условного перехода. Помимо описанных в таблице 16, существует еще восемь других условных переходов - JCXZ, JECXZ, JO, JNO, JP (он же JPE), JNP (он же JPO), JS и JNS. Из них только JCXZ и JECXZ имеют непосредственное отношение к операциям сравнения. Оптимизирующие компиляторы могут заменять конструкцию "CMP [...]CX, 0\JZ do_it" на более короткий эквивалент "J[...]CX do_it", однако, чаще всего они (в силу ограниченности интеллекта и лени своих разработчиков) этого не делают.

Условные переходы JO и JNS используются в основном в математических библиотеках для обработки чисел большой разрядности (например, 1024 битых целых).

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

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

Таблица 23. Вспомогательные условные переходы

::Команды условной пересылки. Старшие процессоры семейства Pentium (Pentium Pro, Pentium II, CLERION) поддерживают команду условной пересылки CMOVxx, пересылающей значение из источника в приемник, если условие xx - истинно. Это позволяет писать намного более эффективный код, не содержащий ветвлений и укладывающийся в меньшее число инструкций.

Рассмотрим конструкцию "IF a<b THEN a=b". Сравните: как она транслируется с использованием условных переходов (1) и команды условной пересылки (2).

К сожалению, ни один из известных мне компиляторов на момент написания этих строк, никогда не использовал CMOVxx при генерации кода, однако, выигрыш от нее настолько очевиден, что появления усовершенствованных оптимизирующих компиляторов следует ожидать в самом ближайшем будущем. Вот почему эта команда включена в настоящий обзор. В таблице 24 дана ее краткое, но вполне достаточное для дизассемблирования программ, описание. За более подробными разъяснениями обращайтесь к странице 3-59 справочного руководства "Instruction Set Reference" от Intel.

Таблица 24. Основные команды условной пересылки

Булевы сравнения. Логической лжи (FALSE) соответствует значение ноль, а логической истине (TRUE) - любое ненулевое значение. Таким образом, булевы отношения сводятся к операции сравнения значения переменной с нулем. Конструкция "IF (a) THEN do_it" транслируется в "IF (a!=0) THEN do_it".

Практически все компиляторы заменяют инструкцию "CMP A, 0" более короткой командой "TEST A,A" или "OR A,A". Во всех случаях, если A==0, устанавливается флаг нуля и, соответственно, наоборот.

Поэтому, встретив к дизассемблером тексте конструкцию a la "TEST EAX, EAX\ JZ do_it" можно с уверенностью утверждать, что мы имеем дело с булевым сравнением.

Идентификация условного оператора "(условие)?do_it:continue" Конструкция "a=(условие)?do_it:continue" языка Си в общем случае транслируется так: "IF (условие) THEN a=do_it ELSE a=continue", однако результат компиляции обоих конструкций вопреки распространенному мнению, не всегда идентичен.

В силу ряда обстоятельств оператор "?" значительно легче поддается оптимизации, чем ветвление "IF - THEN - ELSE". Покажем это на следующем примере:

Если пропустить эту программу сквозь компилятор Microsoft Visual C++, на выходе мы получим такой код:

Таким образом, мы видим, что нельзя апории утверждать, будто бы результат трансляции условного оператора "?" всегда эквивалентен результату трансляции конструкции "IF-THEN-ELSE". Однако тот же Microsoft Visual C++ в режиме агрессивной оптимизации в обоих случаях генерирует идентичный код. Смотрите:

Компилятор некоторым образом перемешал команды, относящиеся к условному оператору "?", с командами ветвления "IF-THEN-ELSE" (это было сделано для лучшего спаривания инструкций), однако, если их сравнить, то выяснится - реализации обеих конструкций абсолютно идентичны друг другу!

Однако с точки зрения языка условный оператор "?" выгодно отличается от ветвления тем, что может непосредственно использоваться в выражениях, например:

Попробуйте так же компактно реализовать это с помощью ветвлений! Но на самом деле, это удобство лишь внешнее, а компилятор транслирует приведенный пример так:

Откомпилируйте оба листинга и дизассемблируйте полученные файлы, - они должны быть идентичны. Таким образом, при декомпиляции Си/Си++ программ в общем случае невозможно сказать использовалось ли в них ветвление или условный оператор, однако, все же есть некоторые зацепки, помогающие восстановить истинный вид исходного текста в некоторых частных случаях.

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

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

Идентификация типов. Условные команды - ключ к идентификации типов. Поскольку, анализ результата сравнения знаковых и беззнаковых переменных осуществляется различными группами инструкций, можно уверенно и однозначно отличить signed int от unsigned int.

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

16 разрядный режим. Одна из неприятных особенностей 16-разрядного режима - ограниченная "дальнобойность" команд условного перехода. Разработчики микропроцессора в стремлении добиться высокой компактности кода, отвели на целевой адрес всего один байт, ограничив тем самым длину прыжка интервалом в 255 байт. Это, так называемый, короткий (short) переход, адресуемый относительным знаковым смещением, отсчитываемым от начала следующий за инструкцией перехода командой (см. рис 26). Такая схема адресации ограничивает длину прыжка "вперед" (т.е. "вниз") всего 128 байтами, а "назад" (т.е. "вверх") и того меньше - 127! (Прыжок вперед короче потому, что ему требуется "пересечь" и саму команду перехода). Этих ограничений лишен ближний (near) безусловный переход, адресуемый двумя байтами и действующий в пределах всего сегмента.

Рисунок 26. 0х019 Внутреннее представление короткого (short) перехода

Короткие переходы усложняют трансляцию ветвлений - ведь не всякий целевой адрес находится в пределах 128 байт! Существует множество путей обойти это ограничение. Наиболее популярен следующий примем: если транслятор видит, что целевой адрес выходит за пределы досягаемости условного перехода, он инвертирует условие срабатывания и совершает короткий (short) переход на метку continue, а на do_it передает управление ближним (near) переходом, действующим в пределах одного сегмента (см. рис. 27)

Рисунок 27. 0х01A Трансляция коротких переходов

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

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

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

Результат компиляции этого примера компилятором Microsoft Visual C+ должен выглядеть так:

А теперь сравним этот, 32-разрядный код, с 16-разрядным кодом, сгенерированном компилятором Microsoft C++ 7.0 (ниже, для экономии места приведен лишь фрагмент):

А теперь заменим тип сравниваемых переменных с int на float и посмотрим, как это повлияет на сгенерированный код. Результат компиляции Microsoft Visual C++ должен выглядеть так (ниже приведен лишь фрагмент):

Гораздо нагляднее код, сгенерированный компилятором Borland C++ или WATCOM C. Смотрите:

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

Результат его компиляции должен выглядеть приблизительно так:

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

Рисунок 28. 0х01В Логическое древо

Сразу же бросается в глаза, что все пути проходят точку "Z", сплетающую все ветви воедино. Это значит, что мы имеем дело с двумя самостоятельными деревьями, представленными собственными конструкциями "IF". Замечательно! Такой поворот событий весьма упрощает анализ - раз деревья независимые, то и анализироваться они могут независимо! Итак, начинаем с верхнего из них...

От гнезда "var_d !=0" отходят две ветки - правая ведет к "printf("OK")" и далее к завершению конструкции "IF - THEN [ELSE]", а левая, прежде чем выйти к точке "Z", минует целое полчище гнезд. В переводе на русский язык ситуация выглядит так: "если переменная var_d не равна нулю, то печатаем "OK" и сваливаем, иначе выполняем дополнительные проверки". Проще говоря: "IF (var_d !=0) THEN printf("OK") ELSE Е". Т.е. левая ветка гнезда (var_d != 0) есть ветка "ELSE". Изучим ее?

От гнезда (var_a <= var_b) к узлу "printf("OK")" ведут два пути: !(var_a <= var_b) а !(var_a ==0 ) и !(var_a != var_c) а !(var_c == 0). Где есть альтернатива - там всегда есть OR. Т.е. либо первый путь, либо второй. В то же время, узлы обоих путей последовательно связаны друг с другом, - значит, они объедены операций AND. Таким, образом, эта ветка должна выглядеть так: "IF (( var_a > var_b) && (var_0 != 0)) || (var_a == var_c) && (var_c != 0)) printf("OK")", прививаем "ELSE" к первому IF и получаем. "IF (var_d !=0) THEN printf("OK") ELSE IF(( var_a > var_b) && (var_0 != 0)) || (var_a == var_c) && (var_c != 0)) printf("OK")"

Ну, а разбор второго дерева вообще тривиален: "IF (var_c==var_d) printf("+++")". Итак, исходный текст дизассемблируемой программы выглядел так:

Тип переменных a и b мы определили как unsigned int, т.к. они результат сравнения анализировался беззнаковой условной командой - jnb. А вот тип переменных c и d, увы, определить так и не удалось. Однако это не умоляет значимости того факта, что мы смогли ретранслировать сложное условие, в котором без деревьев было бы немудрено и запутаться...

- Больше всего следует опасаться идей, которые переходят в дела.

Френк Херберт "Мессия дюны"

Оптимизация ветвлений: Какое коварство - под флагом оптимизации сделать каждую строчку кода головоломкой. Тьфу-ты, тут ящика пива не хватит, чтобы с этим справиться (а с этим лучше справляться вообще без пива - на трезвую голову). Итак, предположим, встретился вам код следующего содержания. На всякий случай, чтобы избавить вас от копания по справочникам (хотя, покопаться в них лишний раз - только на пользу) отмечу, что команда SETGE устанавливает выходной операнд в 1, если флаги состояния SF и OF равны (т.е. SF==OF). Иначе выходной операнд устанавливается в ноль.

На первый взгляд этот фрагмент заимствован из какого-то хитро-запутанного защитного механизма, но нет. Перед вами результат компиляции следующего тривиального выражения: if (a<0x666) zzz=0x200 else zzz=0x300, которое в не оптимизированном виде выглядит так:

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

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

Получилось! Мы разобрались с этим алгоритмом и успешно реверсировали его! Теперь видно, что это довольно простой пример (в жизни будут нередко попадаться и более сложные). Но основная идея ясна, - если встречаются команда SETxx - держите нос по ветру: пахнет условными переходами! В вырожденных случаях SETxx может быть заменена на SBB (вычитание с заемом). По этому поводу решим вторую задачу:

Что этот код делает? Какие-то сложные арифметические действия? Посмотрим...

Раскрывая скобки в последнем выражении (мы ведь не забыли, что от EBX отняли EAX?) получаем: if (EBX<EAX) EAX=EBX, - т.е. это классический алгоритм поиск минимума среди двух знаковых чисел. А вот еще один пример:

Попробуйте решить его сами и только потом загляните в ответ:

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

Легко показать, что switch эквивалентен конструкции "IF (a == x1) THEN оператор1 ELSE IF (a == x2) THEN оператор2 IF (a == x2) THEN оператор2 IF (a == x2) THEN оператор2 ELSE …. оператор по умолчанию". Если изобразить это ветвление в виде логического дерева, то образуется характерная "косичка", прозванная так за сходство с завитой в косу прядью волос – см. рис. 29

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

Рисунок 29 0х01С Трансляция оператора switch в общем случае

Однако в реальной жизни все происходит совсем не так. Компиляторы (даже не оптимизирующие) транслируют switch в настоящий "мясной рулет", доверху нашпигованных всевозможными операциями отношений. Давайте, откомпилируем приведенный выше пример компилятором Microsoft Visual C++ и посмотрим, что из этого выйдет:

Построив логическое дерево (см. "Идентификация IF – THEN – ELSE"), мы получим следующую картину (см. рис. 30). При ее изучении бросается в глаза, во-первых, условие "a >2", которого не было в исходной программе, а во-вторых, изменение порядка обработки case. В то же время, вызовы функций printf следуют один за другим строго согласно их объявлению. Зачем же компилятор так чудит? Чего он рассчитывает этим добиться?

Рисунок 30 0x01D Пример трансляция оператора switch компилятором Microsoft Visual C

Назначение гнезда (a > 2) объясняется очень просто – последовательная обработка всех операторов case крайне непроизводительная. Хорошо, если их всего четыре-пять штук, а если программист натолкает в switch сотню - другую case? Процессор совсем запарится, пока их все проверит (а по закону бутерброда нужный case будет в самом конце). Вот компилятор и "утрамбовывает" дерево, уменьшая его высоту. Вместо одной ветви, изображенной на рис. 30, транслятор в нашем случае построил две, поместив в левую только числа не большие двух, а в правую – все остальные. Благодаря этому, ветвь "666h" из конца дерева была перенесена в его начало. Данный метод оптимизации поиска значений называют "методом вилки", но не будет сейчас на нем останавливаться, а лучше разберем его в главе "Обрезка длинных деревьев".

Изменение порядка сравнений – право компилятора. Стандарт ничего об этот не говорит и каждая реализация вольна поступать так, как ей это заблагорассудится. Другое дело – case-обработчики (т.е. тот код, которому case передает управление в случае истинности отношения). Они обязаны располагаться так, как были объявлены в программе, т.к. при отсутствии закрывающего оператора break они должны выполняться строго в порядке, замышленном программистом, хотя эта возможность языка Си используется крайне редко.

Таким образом, идентификация оператора switch не сильно усложняется: если после уничтожения узлового гнезда и прививки правой ветки к левой (или наоборот) мы получаем эквивалентное дерево, и это дерево образует характерную "косичку" – мы имеем дело с оператором множественного выбора или его аналогом.

Весь вопрос в том: правомерны ли мы удалять гнездо, не нарушит ли эта операция структуры дерева? Смотрим – на левой ветке узлового гнезда расположены гнезда (a == 2), (a == 0) и (a == 1), а на левом – (a==0x666) Очевидно, если a == 0x666, то a != 0 и a != 1! Следовательно, прививка правой ветки к левой вполне безопасна и после такого преобразования дерево принимает вид типичный для конструкции switch (см. рис. 31)

Рисунок 31 0x01E Усечение логического дерева

Увы, такой простой прием идентификации срабатывает не всегда! Иные компиляторы такого наворотят, что волосы в разных местах дыбом встанут! Если откомпилировать наш пример компилятором Borland C++ 5.0, то код будет выглядеть так:

Код, сгенерированный компилятором, модифицирует сравниваемую переменную в процессе сравнения! Оптимизатор посчитал, что DEC EAX короче, чем сравнение с константой, да и работает шустрее. Вот только нам, хакером, от этого утешения ничуть не легче! Ведь прямая ретрансляция кода (см. "Идентификация IF - THEN - ELSE") дает конструкцию вроде: "if (a-- == 0) printf("a == 0"); else if (a==0) printf("a == 1"); else if (--a == 0) printf("a == 2"); else if ((a-=0x664)==0) printf("a == 666h); else printf("Default")", - в которой совсем не угадывается оператор switch! Впрочем, почему это "не угадывается"?! Угадывается, еще как! Где есть длинная цепочка "IF-THEN-ELSE-IF-THEN-ELSE…" там и до switch-а недалеко! Узнать оператор множественного выбора будет еще легче, если изобразить его в виде дерева - смотрите (см. рис. 32) вот она, характерная "косичка"!

Рисунок 32 0x01F Построение логического дерева с гнездами, модифицирующими саму сравниваемую переменную

Другая характерная деталь - case-обработчики, точнее оператор break традиционно замыкающий каждый из них. Они-то и образуют правую половину "косички", сходясь все вместе с точке "Z". Правда, многие программисты питают паралогическую любовь к case-обработчикам размером в два-три экрана, включая в них помимо всего прочего и циклы (о них речь еще впереди - см. "Идентификация for\while"), и ветвления, и даже вложенные операторы множественно выбора! В результате правая часть "косички" превращается в непроходимый таежный лес, сквозь который не проберется и стадо слонопотамов. Но даже если и так - левая часть "косички", все равно останется достаточно простой и легко распознаваемой!

В заключение темы рассмотрим последний компилятор - WATCOM C. Как и следует ожидать, здесь нас подстерегают свои тонкости и "вкусности". Итак, откомпилированный им код предыдущего примера должен выглядеть так:

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

::Отличия switch от оператора case языка Pascal. Оператор CASE языка Pascal практически идентичен своему Си собрату - оператору switch, хотя и близнецами их не назовешь: оператор CASE выгодно отличается поддержкой наборов и диапазонов значений. Ну, если обработку наборов можно реализовать и посредством switch, правда не так элегантно как на Pascal (см. листинг 176), то проверка вхождения значения в диапазон на Си организуется исключительно с помощью конструкции "IF-THEN-ELSE". Зато в Паскале каждый case-обработчик принудительно завершается неявным break, а Си-программист волен ставить (или не ставить) его по своему усмотрению.

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

Представляет интерес посмотреть: как Pascal транслирует проверку диапазонов и сравнить его с компиляторами Си. Рассмотрим следующий пример:

Результат его компиляции компилятором Free Pascal должен выглядеть так (для экономии места приведена лишь левая часть "косички"):

Как видно, Free Pascal генерирует практически тот же самый код, что и компилятор Borland C++ 5.х, поэтому его анализ не должен вызвать никаких сложностей.

__::IDA распознает switch

::Обрезка (балансировка) длинных деревьев. В некоторых (хотя и редких) случаях, операторы множественного выбора содержат сотни (а то и тысячи) наборов значений, и если решать задачу сравнения "в лоб", то высота логического дерева окажется гигантской до неприличия, а его прохождение займет весьма длительное время, что не лучшим образом скажется на производительности программы.

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

Пусть, например, исходный текст программы выглядел так:

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

Исправить "перекос" можно разрезав одну ветку на две и привив образовавшиеся половинки к новому гнезду, содержащему условие, определяющее в какой из веток следует искать сравниваемую переменную. Например, левая ветка может содержать гнезда с четными значениями, а правая - с нечетными. Но это плохой критерий: четных и нечетных значений редко бывает поровну и вновь образуется перекос. Гораздо надежнее поступить так: берем наименьшее из всех значений и бросаем его в кучу А, затем берем наибольшее из всех значений и бросаем его в кучу B. Так повторяем до тех пор, пока не рассортируем все, имеющиеся значения.

Поскольку оператор множественного выбора требует уникальности каждого значения, т.е. каждое число может встречаться в наборе (диапазоне) значений лишь однажды, легко показать, что: а) в обеих кучах будет содержаться равное количество чисел (в худшем случае - в одной куче окажется на число больше); б) все числа кучи A меньше наименьшего из чисел кучи B. Следовательно, достаточно выполнить только одно сравнение, чтобы определить в какой из двух куч следует искать сравниваемое значения.

Высота нового дерева будет равна ((N+1/2)+1), где N - количество гнезд старого дерева. Действительно, мы же ветвь дерева надвое и добавляем новое гнездо - отсюда и берется N/2 и +1, а (N+1) необходимо для округления результата деления в большую сторону. Т.е. если высота не оптимизированного дерева достигала 100 гнезд, то теперь она уменьшилась до 51. Что? Говорите, 51 все равно много? А что нам мешает разбить каждую из двух ветвей еще на две? Это уменьшит высоту дерева до 27 гнезд! Аналогично, последующее уплотнение даст 16 ' 12 ' 11 ' 9 ' 8… и все! Более плотная упаковка дерева невозможна (подумайте почему - на худой конец постройте само дерево). Но, согласитесь, восемь гнезд - это не сто! Полное прохождение оптимизированного дерева потребует менее девяти сравнений!

Рисунок 33 0х21 Логическое дерево до утрамбовки (слева) и после (справа)

"Трамбовать" логические деревья оператора множественного выбора умеют практически все компиляторы - даже не оптимизирующие! Это увеличивает производительность, но затрудняет анализ откомпилированной программы. Взгляните еще раз на рис. 33 - левое несбалансированное дерево наглядно и интуитивно - понятно. После же балансировки (правое дерево) в нем Тиггер хвост обломит.

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

Рассуждая от противного - все узлы логического дерева, правая ветка которых содержит одно или более гнезд, могут быть замещены на эту самую правую ветку без потери функциональности дерева, то данная конструкция представляет собой оператор switch. Почему именно правая ветка? Так ведь оператор множественного выбора в "развернутом" состоянии представляет цепочку гнезд, соединенных левыми ветвями друг с другом, а на правых держащих case-обработчики, - вот мы и пытаемся подцепить все правые гнезда на левую ветвь. Если это удается, мы имеем дело с оператором множественного выбора, а нет - с чем-то другим.

Рассмотрим обращение балансировки на примере следующего дерева (см. рис. 34 слева). Двигаясь от левой нижней ветви, мы будем продолжать взбираться на дерево до тех пор, пока не встретим узел, держащий на своей правой ветви одно или более гнезд. В нашем случае - это узел (a > 5). Смотрите: если данный узел заменить его гнездами (a==7) и (a == 9) функциональность дерева не нарушиться! (см. рис. 34 посередине). Аналогично узел (a > 10) может быть безболезненно заменен гнездами (a > 96), (a == 96), (a == 22) и (a == 11), а узел (a > 96) в свою очередь - гнездами (a == 98), (a == 666) и (a == 777). В конце -концов образуется классическое switch-дерево, в котором оператор множественного выбора распознается с первого взгляда.

Рисунок 34 0x22 Обращение балансировки логического дерева

Сложные случаи балансировки или оптимизирующая балансировка. Для уменьшения высоты "утрамбовываемого" дерева хитрый трансляторы стремятся замещать уже существующие гнезда балансировочными узлами. Рассмотрим следующий пример: (см. рис. 35). Для уменьшения высоты дерева транслятор разбивает его на две половины - в левую идут гнезда со значениями меньшие или равные единицы, а в правую - все остальные. Казалось бы, на правой ветке узла (a > 1) должно висеть гнездо (a == 2), ан нет! Здесь мы видим узел (a >2), к левой ветки которого прицеплен case-обработчик :2! А что, вполне логично - если (a > 1) и !(a > 2), то a == 2!

Легко видеть, что узел (a > 2) жестко связан с узлом (a > 1) и работает на пару с последним. Нельзя выкинуть один из них, не нарушив работоспособности другого! Обратить балансировку дерева по описанному выше алгоритму без нарушения его функциональности невозможно! Отсюда может создаться мнение, что мы имеем дело вовсе не с оператором множественного выбора, а чем-то другим.

Чтобы развеять это заблуждение придется предпринять ряд дополнительных шагов. Первое - у switch-дерева все case-обработчики всегда находятся на правой ветви. Смотрим - можно ли трансформировать наше дерево так, чтобы case-обработчик 2 оказался на левой ветви балансировочного узла? Да, можно: заменив (a > 2) на (a < 3) и поменяв ветви местами (другими словами выполнив инверсию). Второе - все гнезда switch-дерева содержат в себе условия равенства, - смотрим: можем ли мы заменить неравенство (a < 3) на аналогичное ему равенство? Ну, конечно же, можем - (a == 2)!

Вот, после всех этих преобразований, обращение балансировки дерева удается выполнить без труда!

Рисунок 35 0x23 Хитрый случай балансировки

Ветвления в case-обработчиках. В реальной жизни case-обработчики прямо-таки кишат ветвлениями, циклами и прочими условными переходами всех мастей. Как следствие - логическое дерево приобретает вид ничуть не напоминающий оператор множественного выбора, а скорее смахивающий на заросли чертополоха, так любимые И-i. Понятное дело - идентифицировав case-обработчики, мы могли бы решить эту проблему, но как их идентифицировать?!

Очень просто - за редкими клиническими исключениями, case-обработчики не содержат ветвлений относительно сравниваемой переменной. Действительно, конструкции "switch(a) …. case 666 : if (a == 666) …." или "switch(a) …. case 666 : if (a > 66) …." абсолютно лишены смысла. Таким образом, мы можем смело удалить из логического дерева все гнезда с условиями, не касающимися сравниваемой переменной (переменной коневого гнезда).

Хорошо, а если программист в порыве собственной глупости или стремлении затруднить анализ программы "впаяет" в case-обработчики ветвления относительно сравниваемой переменной?! Оказывается, это ничуть не затруднит анализ! "Впаянные" ветвления элементарно распознаются и обрезаются либо как избыточные, либо как никогда не выполняющиеся. Например, если к правой ветке гнезда (a == 3) прицепить гнездо (a > 0) - его можно удалить, как не несущее в себе никакой информации. Если же к правой ветке того же самого гнезда прицепить гнездо (a == 2) его можно удалить, как никогда не выполняющееся - если a == 3, то заведомо a != 2!

Существуют три основных типа цикла: циклы с условием вначале , циклы с условием в конце (см. рис. 36 в центре) и циклы с условием в середине (см. рис. 36 справа). Комбинированные циклы имеют несколько условий в разных местах, например, в начале и в конце одновременно.

Рисунок 36.0х024 Логическое дерево цикла с условием вначале (слева) и условием в конец (справа).

В свою очередь условия бывают двух типов: условия завершения цикла и условия продолжения цикла . В первом случае:если условие завершения истинно происходит переход в конец цикла, иначе - его продолжение.Во втором: если условие продолжения цикла ложно происходит переход в конец цикла, в противном случае - его продолжения. Легко показать, что условия продолжения цикла представляют собой инвертированные условия завершения. Таким образом, со стороны транслятора вполне достаточно поддержки условий одного типа. И действительно, операторы циклов while,do и for языка Си работают исключительно с условиями продолжения цикла. Оператор while языка Pascal так же работает с условием продолжения цикла, и исключение составляет один лишь repeat-until ожидающий условие завершения цикла.

::Циклы с условиями в начале (так же называемые циклами с преусловием). В языках Си и Pascal поддержка циклов с преусловием обеспечивается оператором "while (условие)", где "условие" - условие продолжения цикла. Т.е. цикл "while (a <10) a++;" выполняется до тех пор, пока условие (a > 10) остается истинным. Однако транслятор при желании может инвертировать условие продолжение цикла на условие завершения цикла. На платформе Intel 80x86 такой трюк экономит от одной до двух машинных команд. Смотрите: на листинге 180 слева приведен цикл с условием завершения, а справа - с условием продолжения. Как видно, цикл с условием завершения на одну команду короче! Поэтому, практически все компиляторы (даже не оптимизирующие) всегда генерируют левый вариант. (А некоторые, особо одаренные, даже умеют превращать циклы с предусловием в еще более эффективные циклы с пост-условием - см. "Циклы с условием в конце").

Листинг 180.Слева показан цикл с условием завершения цикла, а справа - тот же цикл, но с условием продолжения цикла. Как видно, цикл с условием завершения на одну команду короче.

Цикл с условием завершения не может быть непосредственно отображен на оператор while. Кстати, об этом часто забывают начинающие, допуская ошибку "что вижу, то пишу": "while (a >= 10) a++". С таким условием данный цикл вообще не выполниться ни разу! Но как выполнить инверсию условия и при этом гарантированно не ошибиться? Казалось бы, что может быть проще, - а вот попросите знакомого хакера назвать операцию, обратную "больше". Очень может быть (даже наверняка!) ответом будет... "меньше". А вот и нет, - правильный ответ "меньше или равно". Полный перечень обратных операций отношений можно найти в таблице 25, приведенной ниже

Таблица 25 Обратные операции отношения

::Циклы с условием в конце (так же называемые циклами с пост-условием). В языке Си поддержка циклов с пост-условием обеспечивается парой операторов do - while, а в языке Pascal - repeat\until. Циклы с пост-условием без каких либо проблем непосредственно отображаются с языка высокого уровня на машинный код и, соответственно, наоборот. Т.е. в отличие от циклов с предусловием, инверсии условия не происходит.

Например: "do a++; while (a<10)" в общем случае компилируется в следующий код (обратите внимание: в переходе использовалась та же самая операция отношения, что и в исходном цикле, - красота и никаких ошибок при декомпиляции):

Листинг 181

Вернувшись страницей назад, сравним код цикла с пост-условием с кодом цикла с предусловием. Не правда ли, цикл с условием в конце компактнее и быстрее? Некоторые компиляторы (например, Microsoft Visual C++) умеют транслировать циклы с предусловием в циклы с пост-условием. На первый взгляд - это вопиющая самодеятельность компилятора, - если программист хочет проверять условие в начале, то какое право имеет транслятор ставить его в конце?! На самом же деле, разница между "до" или "после" не столь велика и значительна. Если компилятор уверен, что цикл выполняется хотя бы один раз, то он вправе выполнять проверку когда угодно. Разумеется, при этом необходимо несколько скорректировать условие проверки: "while (a<b)" не эквивалентно "do ... while (a<b)", т.к. в первом случае при (a == b) уже происходит выход из цикла, а во втором цикл выполняется еще одну итерацию. Однако этой беде легко помочь: увеличим а на единицу ("do ... while ((a+1)<b)") или вычтем эту единицу из b ("do ... while (a<(b-1))") и... теперь все будет работать!

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

::Циклы со счетчиком. Циклы со счетчиком (for) не являются самостоятельным типом циклов, а представляют собой всего лишь синтаксическую разновидность циклов с предусловием. В самом деле, "for (a = 0; a < 10; a++)" в первом приближении это то же самое, что и: "a = 0; while (a < 10) {...;a++;}". Однако, результаты компиляции двух этих конструкций не обязательно должны быть идентичны друг другу!

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

Листинг 182

Непосредственный прыжок вниз может быть результат компиляции и цикла for, и оператора GOTO, но GOTO сейчас не в моде и используется крайне редко, а без него оператор условного перехода "IF - THEN" не может прыгнуть непосредственно в середину цикла while! Выходит, изо всех "кандидатов" остается только цикл for.

Некоторые, особо продвинутые компиляторы (Microsoft Visual C++, Borland C++, но не WATCOM C), поступают хитрее: анализируя код они еще на стадии компиляции пытаются определить: выполняется ли данный цикл хотя бы один раз и, если видят, что он действительно выполняется, превращают for в типичный цикл с постусловием:

Листинг 183

Наконец, самые крутые компиляторы (из которых автор на вскидку может назвать один лишь Microsoft Visual C++ 6.0) могут даже заменять циклы с приращением на циклы с убыванием при условии, что параметр цикла не используется операторами цикла, а лишь прокручивает цикл определенное число раз. Зачем это компилятору? Оказывается, циклы с убыванием гораздо короче - однобайтовая инструкция DEC не только уменьшает операнд, но и выставляет Zero-флаг при достижении нуля. В результате, в команде CMP A, xxx отпадает всякая необходимость.

Листинг 184

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

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

Скажем так: если логика исследуемого цикла синтаксически удобнее выражается через оператор for, то и выражайте ее через for! В противном случае используйте while или do (repeat\until) для циклов с пред- и пост- условием соответственно.

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

::Циклы с условием в середине. Популярные языки высокого уровня непосредственно не поддерживают циклы с условием в середине, хотя необходимость в них возникает достаточно часто. Поэтому, программисты их реализуют на основе уже имеющихся циклов while (while\do) и оператора выхода из цикла break. Например:

Листинг 185

Компилятор (если он не совсем Осел - Иi в смысле) разворачивает бесконечный цикл в безусловный переход JMP, направленный, естественно назад (ослы генерируют код like - "MOV EAX, 1\CMP EAX,1\JZ repeat"). Безусловный переход, направленный назад, весьма характерен - за исключением бесконечного цикла его может порождать один лишь оператор GOTO, но GOTO уже давно не в моде. А раз у нас есть бесконечный цикл, то условие его завершения может находиться лишь в середине этого цикла (сложные случаи многопоточных защит, модифицирующих из соседнего потока безусловный переход в NOP, мы пока не рассматриваем).

Сделать это будет нетрудно - оператор break транслируется в переход на первую команду, следующую на JMP repeat, а сам break получает управление от ветки IF (условие) - THEN - [ELSE]. Условие ее срабатывания и будет искомым условием завершения цикла. Вот, собственно, и все.

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

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

::Циклы с несколькими счетчиками. Оператор "запятая" языка Си позволяет осуществлять множественную инициализацию и модификацию счетчиков цикла for. Например: "for (a=0, b=10; a != b; a++, b--)". А как насчет нескольких условий завершения? И "ветхий" и "новый " заветы (первое и второе издание K&R соответственно), и стандарт ANSI C, и руководства по С, прилагаемые к компиляторам Microsoft Visual C, Borland C, WATCOM C на этот счет хранят "партизанское" гробовое молчание.

Если попробовать скомпилировать следующий код "for (a=0, b=10; a >0, b <10 ; a++, b--)" он будет благополучно "проглочен" практически всеми компиляторами без малейших ругательств с их стороны, но ни один их них не откомпилирует данный пример правильно. Логическое условие (a1,a2,a3,...an) лишено смысла и компиляторы без малейших колебаний и зазрений совести отбросяст все, кроме самого правого выражения an. Оно-то и будет единолично пределять условие продолжение цикла. Один лишь WATCOM вяло ворчит по этому поводу: "Warning! W111: Meaningless use of an expression: the line contains an expression that does nothing useful. In the example "i = (1,5);", the expression "1," is meaningless. This message is also generated for a comparison that is useless"

Если условие продолжения цикла зависит от нескольких переменных, то их сравнения следует объединить в одно выражение посредством логических операций OR, AND и др. Например: "for (a=0, b=10; (a >0 && b <10) ; a++, b--)" - цикл прерывается сразу же, как только одно из двух условий станет ложно; "for (a=0, b=10; (a >0 || b <10); a++, b--)" - цикл продолжается до тех пор, пока истинно хотя бы одно условие из двух.

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

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

Например: "while (a++ < 10) if (a == 2) continue;..." компилируется приблизительно так:

Листинг 186

::Сложные условия. До сих пор, говоря об условиях завершения и продолжения цикла, мы рассматривали лишь элементарные условия отношения, в то время как практически все языки высокого уровня допускают использование составных условий. Однако составные условия можно схематично изобразить в виде абстрактного "черного ящика" с входом/выходом и логическим двоичными деревом внутри. Построение и реконструкция логических деревьев подробно рассматриваются в главе "Идентификация IF - THEN - ELSE" здесь же нас интересует не сами условия, а организация циклов.

::Вложенные циклы. Циклы - понятное дело - могут быть и вложенными. Казалось бы, какие проблемы? Начало каждого цикла надежно определяется по перекрестной ссылке, направленной вниз. Конец цикла - условный или безусловный переход на его начало. У каждого цикла только одно начло и только один конец (хотя условий выхода может быть сколько угодно, но это - другое дело). Причем, циклы не могут пересекаться - если между началом и концом одного цикла встречается начало другого цикла, то этот цикл - вложенный.

Но не все так просто: тут есть два подводных камня. Первый: оператор continue в циклах с предусловием, второй - сложные условия продолжения цикла с постусловием. Рассмотрим их подробнее.

Поскольку, continue в циклах с предусловием, транслируется в безусловный переход, направленный "вверх", он становится практически неотличим от конца цикла. Смотрите:

Два конца и два начала вполне напоминают два цикла, из которых один вложен в другой. Правда, начала обоих циклов совмещены, но ведь может же такое быть, если в цикл с пост условием вложен цикл с предусловием? На первый взгляд да, но если подумать, то... ай-ай-ай! А ведь условие1 выхода из цикла прыгает аж за второй конец! Если это предусловие вложенного цикла, то оно прыгало бы за первый конец. А если условие1 - это предусловие материнского цикла, то конец вложенного цикла не смог бы передать на него управление. Выходит, это не два цикла, а один. А первый "конец" - результат трансляции оператора continue.

С разбором сложных условий продолжения цикла с постусловием дела обстоят еще лучше. Рассмотрим такой пример:

Строго говоря, предложенный вариант является логически верным, но синтаксически некрасивым. Материнский цикл крутит в своем теле один лишь вложенный цикл и не содержит никаких других операторов. Так зачем он тогда, спрашивается, нужен? Объединить его с вложенным циклом в один!

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

Начнем с самого простого - с циклов while\do:

Листинг 187 Демонстрация идентификации циклов while\do

Результат компиляции этого примера компилятором Microsoft Visual C++ 6.0 с настройками по умолчанию должен выглядеть так:

Листинг 188

Совсем другой результат получится если включить оптимизацию. Откомпилируем тот же самый пример с ключом "/Ox" (максимальная оптимизация) и посмотрим на результат, выданный компилятором:

Листинг 189

Несколько иначе оптимизирует циклы компилятор Borland C++ 5.x. Смотрите:

Листинг 190

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

Компилятор Free Pascal 1.x ведет себя аналогично компилятору Borland C++ 5.0, всегда помещая условие в конец цикла и начиная с него выполнение while-циклов.

Компилятор WATCOM C не умеет преобразовывать циклы с предусловием в циклы с постусловием, вследствие чего располагает условие выхода из цикла в начале while-циклов, а в их конец вставляет безусловный jump. (Классика!)

Компилятор GCC вообще не оптимизирует циклы с предусловием, генерируя самый неоптимальный код. Смотрите:

Листинг 191

Разобравшись с while\do, перейдем к циклам for. Рассмотрим следующий пример:

Листинг 192 Демонстрация идентификации циклов for

Результат компиляции Microsoft Visual C++ 6.0 с настройками по умолчанию будет выглядеть так:

Листинг 193

А теперь задействуем оптимизацию и посмотрим, как видоизмениться наш цикл:

Листинг 194

А что скажет нам товарищ Borland C++ 5.0? Компилируем и смотрим:

Листинг 195

Видно, что Borland C++ 5.0 не дотягивает до Microsoft Visual C++ 6.0 - понять, что цикл выполняется один раз он понял, а вот реверс счетчика ума уже не хватило. Аналогичным образом поступает и большинство других компиляторов, в частности WATCOM C.

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

Листинг 196 Демонстрация идентификации break

Результат компиляции Microsoft Visual C++ 6.0 с настройками по умолчанию должен выглядеть так:

Листинг 197

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

Давайте откомпилируем тот же самый пример компилятором Microsoft Visual C++ 6.0 с ключом "/Ox" и посмотрим:

Листинг 198

Компиляторы Borland C++ и WATCOM при трансляции бесконечных циклов заменяют код проверки условия продолжения цикла на безусловный переход, но вот, увы, оптимизировать ветвления, вынося их в конец цикла так, как это делает Microsoft Visual C++ 6.0 они не умеют...

Теперь, после break, рассмотрим: как компиляторы транслирует его "астральный антипод", - оператор continue. Возьмем следующий пример:

Листинг 199 Демонстрация идентификации continue

Результат его компиляции компилятором Microsoft Visual C++ 6.0 с настройками по умолчанию будет выглядеть так:

Листинг 200

А теперь посмотрим, как повлияла оптимизация ("/Ox") на вид циклов:

Листинг 201

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

Наконец, настала очередь циклов for, вращающих несколько счетчиков одновременно. Рассмотрим следующий пример:

Листинг 202 Демонстрация идентификации циклов for с несколькими счетчиками

Результат его компиляции компилятором Microsoft Visual C++ 6.0 должен выглядеть так:

Листинг 203

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

pkzip -s protect.zip my_file.txt

После этого pkzip запросит у Вас пароль(дважды) и после всех подтверждений файл будет упакован с установленной защтой. При последующих попытках открыть файл protect.zip pkunzip будет предлагать ввести пароль, и если тот окажется неверен, то Вы (или кто-то другой) вместо содержимого файла скорее всего получите сообщение "PKUNZIP: (W14) Warning! Incorrect password for file: MY_FILE.TXT".

Примечание: речь идет о dos-версии 2.06 ("PKUNZIP (R) FAST! Extract Utility Version 2.06 01-24-94"). Однако методы, изложенные в данном документе, применимы с минимальными ограничениями и к файлам, созданным WinZip.

Методика исследования защиты

Для анализа защиты pkzip-а будем использовать как программные средства (отладчик), так и некий документ APPNOTE.TXT - в нем содержится очень подробное описание (видимо, от авторов) алгоритмов pkzip и pkunzip (на английском языке). Я нашел этот документ по адресу http://www.halyava.ru/document/txt_form.htm. Сразу скажу, что многое о защите pkzip можно почерпнуть из этого файла, но некоторые тонкости и непосредственную реализацию алгоритмов - только путем анализа выполнимого кода. Поэтому сначала приводится исследование pkunzip без помощи APPNOTE.TXT, и только после того, как будут обнаружены все базовые процедуры защиты, будет приведен конспект из этого документа. Наименования процедур, данных будут сопоставлены с наименованиями, данными авторами APPNOTE.TXT.

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

Поскольку pkzip является dos-программой, то будем "играть по правилам" и выберем в качестве инструмента исследования dos-отладчик td.exe.

Разумно также будет привести поверхностный анализ защиты вообще без каких-либо инструментов (отладчиков, дизассемблеров...).

Предварительный анализ (без отладчика)

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

Создадим файл из одного символа. Упакуем его как с паролем, так и без него. Сразу обратим внимание на тот факт, что файлы различаются по размеру ровно на 12 байт (у меня размеры файлов составили 115 и 127 байт). Сравнив побайтно содержимое обоих файлов, обнаруживаем, что они отличаются наличием в защищенном файле блока из 12 байт, находящихся сразу после имени упакованного файла (имя файла находится по смещению 001Eh), тогда как в незащищенном файле следом за именем следует символ из упакованного файла. Естественно, что в защищенном файле нет этого символа, по крайней мере после 12-ти байтного блока (предполагаем, что файлы отличаются только вставкой 12-ти байт).

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

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

Итак, мы получили некий ориентир при анализе защиты - это 12 байт Hash. Если при разборе pkzip/pkunzip нам встретится код, работающий с ними, то можно с большой вероятностью отнести его к блоку за/расшифровки.

Исследования с помощью отладчика

Будем исследовать как программа pkunzip расшифровывает информацию и на основании чего выдает сообщение о неверном пароле при помощи отладчика td.exe. Однако нам придется выполнить некоторые подготовительные действия, прежде чем мы сможем работать в отладчике обычным способом: ставить точки останова и т.д., поскольку pkunzip обработан утилитой сжатия PKLITE (в этом можно убедиться, если посмотреть на первые байты pkunzip в редакторе) а также содержит некий цикл расшифровки кода распаковщика PKLITE.

Если загрузить распаковщик в отладчике ("td pkunzip -s protect.zip"), и протрассировать несколько первых его команд, то довольно скоро можно увидеть некий цикл расшифровки блока кода:

Итак, этот цикл расшифровывает код, находящийся в интервале начальный сегмент:[0178h..03E4h]. Причем пока его работа не закончена полностью, мы не можем ставить точки останова (F4) в этом интервале, поскольку цикл расшифровки уничтожит эти точки, и мы будем вынуждены трассировать этот довольно значительный цикл пошагово F7(F8). Также мы не сможем ставить точки останова прямо в оригинальный код pkunzip, поскольку он станет доступен только после его распаковки подпрограммой PKLITE. Рассмотрим более детально, как это происходит: дождемся сначала расшифровки кода от адреса 0178:

Таким образом, мы видим, как стартовый цикл расшифровки декриптует код PKLITE, который в свою очередь перебрасывает свое тело в сегмент после упакованного оригинального кода pkunzip и переходит на него. Поскольку при исследовании pkunzip предполагается многократная его загрузка в отладчике, то проще не выполнять каждый раз процедуру декриптования, а сразу (небольшой программкой, повторяющей действия декриптора) расшифровать код, не забыв удалить код декриптора (он исказит нам расшифрованный код). Алгоритм примерно следующий: найти в pkunzip начало зашифрованного кода (байты E6h,59h,BCh,.. по смещению в файле 00D8), декриптовать их аналогично оригинальному декриптору, дезактивировать код декриптора (например, заменить команду декриптора mov [si],ax на два nop'а: 89h,04h->90h,90h).

Если после такого изменения pkunzip'а загрузить его в отладчик, то можно сразу ставить breakpoint на любую команду PKLITE с адреса 0178 кроме модифицирцуемой команды retf 8CFD - например, на rep movsw.

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

Трассировать код PKLITE также довольно утомительное занятие. Хотелось бы сразу установить прерывание в то место, когда его код полностью отработал и осталось только перейти на распакованный код pkunzip. Как правило, межсегментный переход реализуется с помощью команд retf, jmp far, причем он должен располагаться сразу после всех циклов распаковки PKLITE. Действительно, пролистав вниз код, обнаруживаем такой переход:

Теперь достаточно устанавливать breakpoint на этот retf, чтобы разом пропускать всю работу PKLITE.

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

Так, например, нас интересует код проверки пароля. Делаем предположение, что он находится между кодом, получающим пароль от пользователя и выдачей сообщения о неверном пароле (если специально ввести таковой). Так, к примеру, после перехода на распакованный PKLITE'ом код pkunzip мы видим следующий порядок вызовов процедур:

Как видно, перед нами серия call-ов, видимо отвечающих стартовому коду программы. Пройдем все вызовы командой F8 (Step over - не заходя в код подпрограммы). Оказывается, подпрограммы 5718, 558E и 4DB0 "ничего" не делают, в то время как 20B6 запрашивает у нас пароль, выдает сообщение о неверном пароле и проч. Поэтому мы можем на данном этапе локализовать область исследований подпрограммой 20B6 и в следующей итерации исследовать только ее код. Далее аналогично исследуя набор вызовов этой подпрограммы:

Обнаруживаем, что процедура 071E запрашивает пароль - в первом приближении интересующий нас код находится внутри 071E или далее. Установить способ получения пароля можно следующим способом: простая резидентная программа, перехватившая некий набор функций прерывания int 21h или int 16h должна "всплыть", если pkunzip будет использовать одну или несколько функций из этого набора. В данном случае pkunzip'ом используется функция 08h int 21h. Сжимая далее круг поиска, обнаруживаем следующий интересный кусок кода:

Процедура 0136 выдает сообщение в случае неверного пароля, в то время как в случае верного пароля выполняется переход на метку 18B2. Анализируя условный переход, делаем вывод, что после подпрограммы 7566 инициализируется дальний указатель на некоторую структуру (es:bx) и выполняется сравнение между элементом этой структуры (либо +0F, либо +15h) и некоторой глобальной переменной [BCA9]. Что же представляют собой используемые в данном месте программы элементы структуры ? Простейшим действием является проверка на наличие в zip-файле элементов этой структуры. Действительно, байты структуры со смещением 0F и 15h совпадают с байтами файла по смещению 11h и 17h соответственно ! А в элементе со смещением 0Ah, похоже, находится какой-то битовый флаг, управляющий выбором тестового байта.

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

Итак, из документа следует, что для проверки пароля необходимо сравнить последний байт(слово) некоего расшифрованного буфера с старшим байтом(словом) crc, содержащимся в заголовке файла. Однако мы видим, что в зависимости от некоторго бита (по всей видимости, находящимся в элементе "general purpose bit flag" заголовка) сравнение может быть проведено совсем не с crc, а с старшим байтом времени ("last mod file time")...

Остается найти код, формирующий "второй параметр" сравнения - байт в ячейке [BCA9]. В отладчике td нет возможности установить "breakpoint at memory access" (точку прерывания при обращении к памяти), но можно применить все тот же метод "последовательной локализации", только индикатором будет служить изменение (визуальное) ячейки [BCA9]. Для этого необходимо указать отладчику в окне "data" отображать указанную ячейку и, сделав это в момент начала выполнения кода pkunzip'а, следить за ней во время трассировки. Разумным предположением в смысле экономии усилий будет начать поиск с "близлежащего" от места проверки правильности пароля - а именно, подпрограммы 7566. Именно в ней мы и находим сначала следующий код, использующий пароль:

Грубо говоря, каждый символ пароля последовательно передается на вход процедуре add_seg:082A, которая использует его для последовательного изменения трех двойных слов в буфере [0BDF4]. К моменту начала добавления пароля буфер инициализируется значениями 12345678h, 23456789h и 34567890h (оригинальный код не приводится). Мы назовем эти три двойные слова "buff12". При этом используется добавочная таблица размером в 100h двойных слов (см. команды типа xor eax,cs:[edx*4+ecx], размер следует из того, что индекс (edx) всегда меньше 256). Небольшой промах компилятора (xor ecx,ecx, use ecx как базу) не помешает нам понять расположение этой таблицы в памяти - а именно, в сегменте кода дополнительного модуля. Видимо, к основной программе был подключен модуль с функциями криптования, выполненными в far call стиле и активно использующими инструкции 386 процессора. Действуя так же, как и при поиске вышеприведенного кода, пытаемся обнаружить процедуру инициализации добавочной таблицы (назовем ее XOR-таблицей) - хотя бы ориентируясь на факт ее заполнения. Если проявить чрезмерную осторожность и начать следить за ее изменением с самого начала работы программы, то можно обнаружить любопытный факт: таблица заполняется дважды и оба раза ... неодинаково ! Первый раз (оригинальный код пропущен) это делается на базе инструкций 8086 процессора, далее следует проверка текущего типа CPU и таблица переинициализируется с использованием инструкций 386 процессора:

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

Чтож, любопытно, однако перейдем к финальной части проверки пароля. Нам осталось выяснить, как формируется байт в [BCA9] и как при этом используется вышеприведенный набор из трех двойных слов, измененных паролем. Прежде всего замечаем, что немного ранее кода изменения двойных слов buff12 (метка 7554) в буфер [BCA9-(0Ch-1)] заносятся те самые двенадцать байт из zip-файла (Hash), которые после изменения двойных слов паролем также модифицируются подпрограммой 2938:

Таким образом Hash преобразуется (дешифруется) и последний байт его сравнивается либо с старшим байтом crc, либо со старшим байтом временем файла.

Последнее, что осталось рассмотреть - это способ расшифровки потока данных. При его поиске можно, например, опираться на следующие предположения: вероятно, код расшифровки начинает работать после проверки правильности пароля (условный переход на метку 18B2), вероятно, что расшифровкой занимаются подпрограммы дополнительного модуля, аналогичные или совпадающие с приведенными выше - как только в программе встретится дальний вызов подпрограммы из этого модуля, это должно вызвать подозрения. Собственно говоря, процедура расшифровки Hash сама по себе уже является кандидатом на "расшифровщик" потока данных. Действительно, если "на всякий случай" установить breakpoint в ее начало , то он сработает ! Дампируя содержимое памяти по адресу в es:di (адрес дешифруемых байт), идентифицируем их с байтами файла, лежащими следом за Hash файла: процедура дешифровки данных - это тот код, который ранее расшифровал Hash.

Итоговое описание алгоритма проверки пароля с выдержками из авторского описания (APPNOTE.TXT)

Итак, приводим описание алгоритма проверки пароля и дешифровки данных.

Сначала программа запрашивает пароль. Это осуществляется при помощи функции 08h прерывания 21h. Для нас важно то, что эта функция не позволяет вводить символы с следующими кодами: 0,3,8,13,16,19,27.

Инициализируются три двойных слова следующими значениями: 12345678h, 23456789h и 34567890h:

При рассмотрении защиты под отладчиком Keys мы назвали buff12.

Используя пароль, изменяем эти Keys (оригинальный код приведен выше и носит название "Подпрограмма использования пароля для изменения им 12 байтного буфера (buff12)" и "Подпрограмма модификации байтом 12 байтного буфера (buff12)"):

Способ получения crc32(XOR-таблицы) приведен выше и носит название "Подпрограмма инициализации XOR-таблицы".

Дешифруется буфер из 12 байт, расположенных в zip-файле сразу за именем упакованного файла (ранее мы дали ему название Hash):

Далее осуществляется проверка правильности пароля. Для этого осуществляется сравнение последнего, 12-го расшифрованного байта и старшего байта crc32 (лежит по смещению 14 в файле) упакованного файла, если третий бит байта ("general purpose bit flag", лежит по смещению 6 в файле) сброшен, иначе берется страший байт времени (смещение 10).

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

Словарная атака

Обсудим возможность нахождения неизвестного пароля к произвольному защищеному zip-файлу.

Итак, перед нами следующая последовательность действий pkunzip'а при расшифровке файла:

- Получение пароля от пользователя;

- Инициализация Key, изменение Key паролем;

- Использование Key для расшифровки "12-byte encryption header";

- Сравнение последнего расшифрованного байта и crc(времени) файла. Если они совпадают, пароль признается pkunzip'ом верным.

- Использование Key для расшифровки данных в файле.

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

Здесь возможны два варианта, зависящие от нашего знания о шифруемой информации. Если мы не обладаем никакими данными о информации, то тут мы зашли в тупик. Допустим, однако, мы имеем некоторое представление о том, что зашифровано в файле. Откуда мы его можем получить ? Сначала необходимо понять, что она представляет собой. Вспомним, что основная функция pkunzip - это упаковка файлов и информация может быть сначала упакована и затем закриптована, либо наоборот. Оказывается, pkunzip криптует упакованные данные ! В случае значительного по объему входного файла первыми байтами упакованных данных будет что-то вроде начала таблицы символов для распаковки. В общем случае pkunzip может использовать до восьми методов сжатия ! Интерес представляет метод stored - сохранение информации без сжатия. Этот метод может быть применен в случае небольшого объема информации либо принудительно по желанию пользователя. Метод упаковки можно получить из поля "compression method" заголовка файла (0 - The file is stored). Не будем подробно рассматривать алгоритм атаки в этом маловероятном случае и перейдем к рассмотрению возможности получения пароля.

Прежде всего замечаем, что все множество различных шифровок любой информации совпадает количественно с множеством состояний 12 байт Key, которые можно получить, используя все множество доступных для ввода паролей. Максимальная длина пароля составляет примерно 64 символа, что, несмотря на некоторое количество запрещенных для ввода символов, дает огромное в сравнении с числом всех возможных вообще состояний Key (256^12). Интуитивно ясно, что если алгоритм изменения Key паролем не содержит явных ошибок, то множество возможных состояний Key по порядку величины совпадает с числом комбинаций 12 байт (256^12). Даже если число возможных состояний Key, полученных от всего множества возможных паролей составит 256^8 ~ 10^19, то, даже имея однозначное правило проверки пароля (или соответствующего ему состояния Key), невозможно за приемлимое время перебором всех вариантов обнаружить верный пароль. Если же число возможных состояний состовляет, например, 256^5 ~ 10^12 вариантов, то при скорости проверки паролей в 10^5 паролей в секунду имеет смысл выполнять такой подбор. Необходимо только знать критерий проверки пароля, оставляющий конечное число кандидатов в пароли (чтобы можно было проверить их вручную за конечное время) - например, 10000 или немногим более.

Вряд ли, однако, число состояний Key состовляет менее 256^6, что делает бессмысленным полный перебор всех возможных паролей (Key) даже при наличии критерия проверки пароля. Косвенным доказательством служит следующий опыт. Будем подавать на вход процедуре update_keys различные пароли и следить за выпадением первых четырех байт (двойное слово) в интервале от 0 до 255 (или любом другом). Например, в моем опыте подавались пароли из символов от "A" и до конца таблицы длиной от единицы и выше. В результате после подачи ~7*10^8 таких паролей выпало не менее ~40 Key со значением первого двойного слова в интервале 0..255, из чего можно сделать оценку (очень грубо), что существует не менее 40/256 ~1/8 состояний Key от максимально возможного (256^12).

Альтернативой алгоритму перебора является получение пароля по следам его использования. В нашем случае пароль используется единожды при изменении начального состояния Key и единственное место, если не считать расшифровку данных, где он проявляет свои свойства - это заданное значение последнего байта расшифрованного "encryption header".

Поток состояний Key, сформированных множеством возможных паролей, способен образовать практически псведосучайные последовательности в виде расшифровки encryption header, следовательно, примерно на каждые 256 входящих паролей один окажется верным с точки зрения алгоритма проверки. Следовательно, даже если бы число возможных состояний Key было конечным, порядка 256^5, мы бы смогли уменьшить число возможных Key не более чем в 256 раз. Вот если бы мы знали исходное состояние encryption header, то мы бы могли практически однозначно проверить любой пароль, либо попытаться получить пароль по результату шифрования исходного состояния. Авторами подчеркивается, что исходное состояние encryption header - это псевдосучайный набор байт.

Так ли это на самом деле ? Проверим это утверждение и найдем отладчиком код, формирующий случайные байты encryption header. Для этого нам придется трассировать уже pkzip (модуль упаковки), правда, по сходной схеме с pkunzip. Вот этот код:

В чем смысл этого кода ? header представляется в виде шести слов, изначально равных нулю, каждое из которых командами sbb или adc модифицируется 86 раз. Команды sbb(adc) вычитают(добавляют) с учетом флага переноса содержимое памяти в регионе 0000h...0800h. В этом регионе памяти находится таблица векторов прерываний (первые 400h байт), затем идут области данных BIOS и DOS). Значения слов региона зависят от установленных драйверов, версии OS. Но самое главное, что в этой области находится счетчик тиков системного таймера и буфер клавиатуры, которые используются примерно в 50% случаев. Правда, существует выделенный случай, когда в точности известна конфигурация машины, на которой была осуществлена упаковка.

Таким образом, в общем случае невозможно обращение пароля по следам его использования и невозможен полный перебор всех вариантов паролей (Key). Разумеется, необходимо проверить выделенные случаи: например, первый зашифрованный файл в архиве - распространенный read.me и т.д. Следовательно, следует вывод о том, что единственным возможным путем атаки является перебор ограниченного числа паролей с расчетом на то, что искомый пароль окажется среди рассматриваемых - атака по словарю.

Как организовать словарную атаку ?

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

Но что же произойдет, если мы перебором возможных паролей найдем такой "верный" пароль ? Достаточно перебрать пароли числом >> 256, чтобы найти пароль, удовлетворяющий критерию программы. Попытаемся расшифровать им защищенный файл. Сообщения о неверном пароле не появилось, но зато pkunzip выдаст сообщение о неверном crc распакованного файла ! В ряде случаев может появиться сообщение о том, что разрушена таблица символов или еще что-то в этом роде. Оказывается, распаковав файл, pkunzip проверит его crc. Причем используется crc32. Вероятность совпадения для такого crc составляет 1/2^32, что практически однозначно при проверке паролей числом 256^4 определит нужный. Плюс стандартный критерий уменьшит число паролей в 256 раз, но и это еще не все ! Что будет, если pkunzip начнет распаковывать неверно расшифрованные данные ? Наверняка в их структуре будет что-то не так, и это тоже является критерием проверки пароля ! Так, например, при методе упаковки "deflating" первый бит упакованных данных - признак последнего блока, а если следующие два бита равны единице, то это является признаком разрушенного блока.

Итак, алгоритм словарной атаки примерно ясен: получаем очередной пароль, изменяем им key, расшифровываем encryption header, сверяем последний байт. Если сравнение успешно, то распаковываем файл так же, как это делает pkunzip, при ошибках отбрасываем пароль. Считаем crc файла и сверяем его с эталонным. Этим методом мы из каждых 256^5 или более паролей оставим примерно один "верный".

Осталась реализация. Очевидно, что универсальный алгоритм подбора должен включить в себя все методы распаковки, которые может использовать pkunzip. Это довольно утомитльно, в результате мы напишем еще один распаковщик. Единственным его достоинством будет относительно большая скорость распаковки, достигаемая за счет буферизации данных. А если шифрованный файл более 64K, то будет необходимо держать несколько буферов (речь идет о DOS) и на этом пути pkunzip постепенно догоняет нас. Так не лучше ли задачу распаковки и проверки crc возложить на него, а пароли подбирать только с точки зрения стандартнго критерия ?

Действительно, pkunzip поддерживает возможность передать пароль в командной строке ! Например, текущий проверяемый пароль - "TEST". Для его проверки необходимо запустить pkunzip следующим образом:

pkunzip -sTEST -o test.zip

"-o" означает записывать распаковываемый файл поверх старого, если таковой уже имеется, символы после "-s" трактуются как пароль. Правда, нельзя передавть принципиально возможные пароли с символами " " (пробел) или "-". Следовательно, необходимо выполнять запуск pkunzip'а из подборщика, например с помощью функции ax=4B00h прерывания int 21h. Ну а как же получить результат проверки от работающего pkunzip'а ? Понятно, что он выдаст предупреждение на дисплей, но ведь речь идет о массовых запусках. Оказывается, в случае ошибочной распаковки pkunzip устанавливает значение errorlevel (код возврата) в отличное от нуля значение. Получить код возврата после выполнения программы можно через функцию ah=4Dh прерывания int 21h.

Быстродействие ? На компьютере P-120 составляет около 3000 вариантов в секунду, что позволит просмотреть словарь объемом 3 миллиона слов всего за 1000 секунд или 20 минут.

Небольшие тонкости. В ряде случаев в архиве лежит более одного файла. В этом случае можно применять ключ "-x", позволяющий отбирать нужные. Также в случае работы под dos архивы, содержащие файлы с длинными именами, вызывают проблемы с оценкой кода возврата. В этом случае достаточно сократить имена вручную прямо в файле (в двух местах), не сдвигая остальные данные. Увеличить скорость перебора более чем в два раза можно перенаправлением вывода pkunzip'а с экрана на фиктивное устройство ("> nul").

Исходник здесь.

(C) Chingachguk /HI-TECH

• Язык программирования

• Спецификации языка

• Среда выполнения и API

Вот небольшое пояснение к вышесказанному: после многочисленных экспериментов по созданию языка программирования для своих инженеров SUN решила изобрести современный (по ее утверждению) язык, основанный на принципах объектно-ориентированного программирования, очень модному в то время. В архитектуру ООП входят (среди прочих) такие концепции как наследование и полиморфизм.

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

В то время, как SUN выпускала спецификации языка, она решила, что компиляция программы, написанной на Java, будет происходить в байткод, который будет выполняться специальным интерпретатор. Этот интерпретатор называется виртуальной JAVA-машиной (JVM).

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

Что представляет из себя JAVA?

Каждый объект в JAVA находится в отдельном файле. Один или более объектов можно сгруппировать в пакет (pakage'и). Файлы группируются в Java-архив (JAR) или в архив, сходный по формату с ZIP.

Каждый класс объявляется определенным образом. Например:

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

У каждого класса может быть (а может и не быть) один или больше методов.

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

Класс может расширять функциональность другого.

Базовые типы аргументов методов и переменных могут быть следующие: boolean, char, byte, short, int, long, float, double. Эти типы являются системными. Им соответствуют следующие классы: java.lang.Integer, java.lang.String, java.net.ContentHandler, java.rmi.NotBoundException, ...

Важным классом является java.lang.Class. Экземпляры класса Class представляют классы и интерфейсов Java-приложения. JVM предоставляет механизм установки каждого объекта, как экземпляра класса Class.

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

Первые шаги

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

Вызываем

Он запускается следующим образом:

На выходе получаем файл 'MiClase.class', который содержит Java-байткод.

Теперь, чтобы эта программа была переведена в машинные коды и выполнена, необходим Java-интерпретатор (который также включен в JDK). Код, генерируемый интерпретатором, зависит от процессора, на котором выполняется программа.

Запустить программу можно следующим образом:

Введение в суть дела

Всю необходимую информацию относительно спецификации JavaTM Virtual Machine, можно получить на сайте java.sun.com.

Архив каждого класса начинается со структуры типа ClassFile

Например, поле 'magic' занимает 4 байта и всегда равно 0xCAFEBABE. В общем случае данные этой структуры представляют массивы элементов размером в слово, при этом каждому массиву предшествует поле, указывающее размер этого массива. Например, methods_count содержит в себе количество методов (функций или подпрограмм), которые содержит класс, в то время как methods[methods_count] является массивом структур типа method_info. Эта информация генерируется компилятором и предназначается для JVM.

Поскольку эта информация показывает, сколько класс занимает места в памяти, JVM имеет механизм верификации классов.

Этот процесс выполняется следующим образом:

Фаза 1:

- поле magic верно

Фаза 2:

- у класса с типом final (финальный) не может быть наследников

- класс наследуется от другого, хотя бы java.lang.Class или java.lang.Object

- область констант непрерывна

- у всех поля и методы принадлежат верным классам, имена и типы полей и методов также верны.

Фаза 3:

- запук программы возможно только, если:

• присутствуют все необходимые операторы

• куча содержит данные верных типов

• переменные имеют определенное значение (включая void и null)

• вызовы методов используют правильные аргументы

• у всех опкодов верные аргументы

Фаза 4:

- некоторые проверки фазы 3 выполняются во время запуска класса.

Как и все языки, основывающиеся на байткодах, JVM имеет ряд регистров и структур для внутреннего использования. Например, программный счетчик (pc) содержит адрес выполняющейся JVM инструкции для каждого треда. Помните, что по определению при выполнении JAVA-программы создается несколько тредов, выполняющихся одновременно. Также существуют различные кучи данных (стек) по одной для каждого из выполняющихся тредов. Существует одна уникальная куча, использующаяся для хранения объектов.

Другой важной зоной является область методов, в которой хранятся байткоды классов. И еще одна зона с константами. И еще одна с "родными"(native)-методами (процедуры, написанные не на JAVA, а на другом языке, как правило C, и предназначающиеся для вызовов в Java и вызовов методов DLL; соответственно, эти процедуры хранятся не в байткодах).

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

Более подробное рассмотрение

Опкоды организованы по типам:

• Присвоение и чтение

• Арифметические инструкции

• Конвертирование типов

• Создание объектов и манипулирование ими

• Управление кучей

• Контроль передачи данных

• Вызов методов

• Исключения

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

Чтобы байткоды могли быть интерпретированы какой-либо JVA, они должны соответствовать определенным спецификациям (также установленным SUN'ом), в которых задаются возможные инструкции и их операнды.

Вот таблица возможных опкодов:

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

Установленные факты:

- Некоторые опкоды не используются. Их обработка, если они встретятся в каком-то классе, будет зависеть от реализации JVM.

- В общем случае каждый опкод имеет форму ixxxx, dxxxx, lxxxx, fxxxx, в зависимости от типа данных, с которым он работает (целые числа, двойные, длинные или плавающие).

- Для сохранения значения в куче используется aload_n, где 0 <= n <= 3. Хочу сказатель, что хотя существует опкод для сохранения числа 2, но для сохранения номера отдельный опкод aload отсутствует. Отдельные опкоды были выделены для наиболее часто используемых значений: 0, 1, 2, 3.

Инструменты

Первым и основным является JAVA-компилятор. Легче всего достать JDK от SUN и, хотя у него не слишком много возможностей и сервисов по сравнению с другими компиляторами, генерируемый им код более-менее приемлем.

Где: java.sun.com

Для того, чтобы совершать путешествия внутрь ява-программ, следует ознакомиться с соответствующими спецификацими на http://java.sun.com/docs/books/vmspec/2nd-edition/html/.

Поскольку мы предполагаем, что у вас установлен JAVA-компилятор, по-видимому, у вас установлен и декомпилятор. Он называется javap и вызывается с помощью команды 'javap -c MiClase', что отобразит на экране дизассемблированный код.

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

И, поскольку мы находимся в андерграундном мире, необходимо найти инструмент, умеющий декомпилировать Java-программы. Наиболее часто используемый - это JAD, а лично мне нравится DJ Java Decompiler, который можно найти на http://members.fortunecity.com/neshkov/dj.html.

Генерируемый декомпилятором код выдается на языке JAVA, а не опкоды, хотя если встречаются невалидные опкоды или какое-нибудь другое несоответствие с языком Java, скомпилировать декомпилированный код не получится.

Задачу декомпиляции затрудняет то, что существуют программы для усложнения скомпилированного кода насколько это возможно. Найти такие программы можно, например, на www.zelix.com или www.condensity.com.

Jasmin - компилятор опкодов. Он трансформирует опкоды в классы. На вход он принимает то, что мы получили с помощью javap.

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

D-java - это еще один JAVA-дизассемблер, написанный на языке C (доступны исходники). Он так же прост, как и javac, но он несколько более устойчив.

Больше информации вы можете получить здесь: http://www.meurrens.org/ip-Links/java/codeEngineering/#tocDecompilersToJava

Практика

Теперь, когда вам известна основные теоретические сведения, мы можем начать с простого примера. Жертвой будет программа под названием BEA-WebLogic. Это приложение работает в Windows так же как и в UNIX, так как полностью написано на JAVA, и представляет собой JAR-архив, в котором упакованны все соответствующие классы. В своей основе это сервер веб-приложений, поэтому в него включен веб-сервер, сервлеты и EJB. Загрузить BEA-WebLogic можно с www.bea.com или www.beasys.com. Использовалась версия 5.1. Уже вышла 6.0, но для того, чтобы понять технику, хватит и 5.1.

Будучи проинсталлированной в c:\weblogic, система лицензий устанавливает в c:\weblogic\WebLogicLicense.xml типа XML (т.е. текстовый) со примерно следующими строками

Игра с приложением

Модифицирование KEY приводит к LicenseKeyInvalidException, которое находится в классе, располагающемся в файле c:\weblogic\classes\weblogic\common\LicenseKeyInvalidException.class

Сейчас мы должны найти все файлы, которые обращаются к этому классу, то есть содержать строку LicenseKeyInvalidException, что дает нам c:\weblogic\classes\weblogic\t3\svr\T3Srvr.class.

Декомпилируем его с помощью DJ Java Decompiler и получаем

после чего вызывается

после чего вызывается

Также в c:\weblogic\classes\weblogic\common\internal\FileInfo.class встречаем

Пачкаем руки

Хоть и не очень сильно.

Один из наиболее часто применяемых методов - это не вызывать checkAccess в main, хотя также можно не вызывать исключение LicenseException в fileinfo.checkAccess или узнать, какой метод сохраняет KEY.

Благодаря JAD'у мы можем отредактировать полученный исходный код: удаляем вызов checkAccess и компилируем новый T3Srvr.java.

Делайте так:

Запускаем программу.

И вуаля! Код работает.

Если, в силу какой-либо причины, сгенерированный JAD'ом код нельзя скомпилировать, остается другой способ: дизассемблирование вручную. Нам нужно избежать вызова checkAccess.

Дизассемблирование с помощью D-java или javap дает:

Вызов, который нам нужно избежать, находится в строке 44. У инструкции invokespecial опкод 0xB7, а 485=0x01E5. Посему загружаем T3Srvr.class в наш любимый шестнадцатиричный редактор, ищем последовательность B701E5, которая оказывается по смещению 8B27 и заменяем ее на 000000 (три NOP'а). И остается перекомпилировать.

Другой пример

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

Одной из таких программ является Jindent, который можно получить на www.jindent.de. Шароварная версия неудобна, так как не форматирует файлы объемом более 400 строк. Мы попытаемся убрать это ограничение.

Программа вызывается следующим образом:

но так как в MiClase.java больше 400 строк, то получаем ошибку

Это весьма огорчительно.

Код находится в файле Jindent.jar, который, как нам хорошо известно, является не более чем Java ARchive, поэтому мы можем использовать jar -xvf Jindent.jar. Переходив в директорию jindent\, где находятся все архивы. Ищем строку "exceeds 400 lines of code", но не находим. Ищем "exceeds" и снова не находим.

В чем же дело? По-видимому, код был прогнан через обфускатор. У нас есть архивы под названием a.class, b.class, c.class, ..., чье название нам никак не помогает, а просмотр каждого класса будет весьма утомительным.

Распаковываем файлы и пишем

Чтобы получить немного больше информации пишем

Похоже, что m.class отвечает за загрузку файла, а класс y.class жалуется на превышение лимита. С помощью нашего друга JAD'а декомпилируем m.class. У нас есть некоторое количество функций с разными именами. Например, у нас есть 15 функций с именем a, но с различным количеством и типом аргументов. Это так называемые перегруженные методы, что для нас не слишком хорошо. В частности, последняя функция:

Как видим, опкоды невозможно перекомпилировать с помощью простого вызова javac. Но так как они закоментированы, это не важно. Просто изменяем последнюю функцию в файле m.java следующим образом:

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

И помещаем в каждый методод следующую строку

в каждый метод.

Запускаем программу и видим, что последние строки выполняются вместе с методом o() и после метода b().

Похоже, что очищаются какие-то указатели. Ничего особенного.

С другой стороны

Запускаем программу и в результатет получаем

Случайно в нашем файле оказывается 2000 строк. Все становится ясным: функция o() возвращает количество строк в файле.

В редких случаях эта функция не вызывается из этого модуля. Тогда делаем printStackTrace(), пока не будет возвращен i1, получаем:

До того, как пропатчить, исследуем программу еще немного.

Дизассемблируем JindentParser.class и ищем, где происходит первый вызов o().

В цикле переменной i1 присваивается результат o(). Пока лучше не патчить o() (В любом случае, мы несколько смущены. Откуда мы знаем, что k1 - это объект типа m?).

второй вызов:

Это очень интересно. cA - это один экземпляр объекта типа m, и где-то в конце вызывается m.o().

где bi равно ?

Переходим к определению переменных и (нам везет) находим константу bi:

Ах, теперь все понятно: bi - 512 = 912 - 512 = 400, все просто!

третий вызов (строка 8158):

Теперь просто необходимо пропатчить значение bi JindentParset.class, чтобы утилита принимала файлы размером до 65535-512.

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

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

Стоит упомянуть о SUN'овском Hotspot'е, прекрасой JVM с JIT'овским компилятором с прилагающимся исходным кодом. Он может не просто выполнять инструкции, но создавать файл, который затем запустит.

Туда включен графический пошаговый отладчик.

Есть еще много тем, касающихся Java, которых было бы интересно коснуться.

Например:

• реализация JVM для новичков

• функционирование Sandbox и как подгружать классы с помощью другого ClassLoader'а

• генерация java-кода на лету для повышения безопасности

• вызовы DLL и библиотек S.O. с помощью jni

• сервлеты, RMI, EJB

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

Если предсказания известных аналитиков софтверного рынка оправдаются, 90% процентов приложений будут интегрированы с Web, а это значит, что они будут переведены на Java (автор статьи не подозревал, что Miscrosoft замутит .Net и связанную с ней ересь :) - прим.пер.). Как бы то ни было, можно назвать такие примеры как Oracle, SmartCard, Vantive, Lotus и IBM.

Итак, я предполагаю, что читатель имеет твердое представление об ассемблере, неплохо владеет Си, прекрасно разбирается в том, как компилировать и линковать программы. Также, очевидно, необходимо уметь пользоваться Visual Studio.

Данная статья написана как довесок к моей основной статье о профилировщиках. Здесь рассказывается, как устранить некоторые проблемы инсталляции и работы программ , использующих для своего функционирования набор API-функций, предоставляемых пакетом FlexLm. Так уж получилось, что подавляющее большинство профилировщиков, средств покрытия кода (т.е. средств, показывающих, сколько веток if и других циклов выполняется при нормальном течении хода проги, это очень полезно, т.к. показывает, насколько ваша прога "готова" к нестандартным изменениям ситуации, как тщательно вы подготовились к неприятностям, т.к. если ветки, которые получают управление редко, небрежно написаны, то в результате можно получить ой-ой-ой!) и выявления утечек памяти используют именно FlexLm. Среди них – Intel Compiler/Vtune environment, все продукты семейства DevPartner от Numega, и все опробованные мной продукты от Rational.

Рассмотрим сперва Intel Compiler, единственный реальный конкурент MS cl.exe. Закачать его можно с <ftp://download.intel.com/software/products/>. Последняя версия на момент написания -W_CC_P_7.0.073.exe. «Вес» пакета – 74 Мб.

Итак, закачиваем и инсталлируем (помните, в обязательном порядке должно иметь место наличие присутствия Visual Studio 6/Net). При попытке инсталляции получаем что-то вроде FlexLm license error. Теперь мы и подобрались к сути проблемы.

Итак, FlexLm – это творчество компании GLOBEtrotter Software. Фиговина эта требует присутствия .lic файла (действие которого может быть ограниченным во времени), без которого работать не хочет ну никак. Компания, как это модно сейчас, выпускает FlexLm SDK, где имеются API-функции для работы с lic-файлом, которые надо втиснуть в исходный код, скомпилировать с соответствующими .h-файлами и слинковать с соответствующими библиотеками.

Только в качестве иллюстрации:

Библиотеки для разных случаев используются разные. Скажем, для линковки мультипоточного варианта (multithread) будут использоваться одни библиотеки, если приложение представлено одним единственным процессом – другие. Ниже дан пример из FlexLm SDK версии 8.0:

FLEXlm Object File — FLEXlm Client Libraries — MSVC++ Libraries

Standard — lm_new.obj — lmgr.lib — libcmt.lib(/MT) oldnames.lib kernel32.lib user32.lib netapi32.lib advapi32.lib gdi32.lib comdlg32.lib comctl32.lib wsock32.lib

Add for CRO — libcrvs.lib libsb.lib

Add for static FLEXlock — flock.lib

For /MD — Replace lm_new.obj with lm_new_md. obj — Replace Standard lmgr.lib with lmgr_md.lib — Replace Standard libcmt.lib with msvcrt.lib (/MD)

For CRO /MD — Add to Standard: libcrvs_md.lib libsb_md.lib — Replace Standard libcmt.lib with msvcrt.lib (/MD)

Видно, что здесь есть много интересного. Сразу появляется желание скачать этот самый SDK и маленько с ним разобраться. Ничего невозможного - http://linux20368.dn.net/crackz/Flexlm.htm, т.к. с родного сайта компании вы уже ничего не скачаете - доступ закрыт, однако.

Теперь о том, как это ломать. Варианта два – 1-й - разобраться с форматом .lic файла, подправить оригинальные API-функции, словом вдумчиво ковырять FlexLm SDK (это уже и было проделано и в сети есть много англоязычных статей на эту тему), 2-й – лично мне больше по душе – ковырять конкретное приложение, которое неумело использует функции FlexLm. Есть идиоты, которые вообще выносят эти API-функции в отдельную .dll, вместо статической линковки, и это несмотря на предупреждения, красным по белому:

Caution: Use of the FLEX lm DLL on Windows remains strongly discouraged

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

Итак, теперь к делу.

Выкачиваем компилятор. Пробуем запустить – ругается, нужен lic-файл. Его, ессно, нет. Начинаем копать. Существует достаточно много подходов ко взлому конкретного приложения. Кто к каким привык. Стандартом, как правило, считается постановка bpx на что-нибудь вроде MessageBoxExW или DialogBoxIndirectParamA, затем исследуется дизассемблированный код ВЫШЕ точки «всплыва» отладчика и определяется, какой из условных переходов, привел к таким ругательствам со стороны проги.

Еще один вариант – это прогонять программу под каким-нибудь API-монитором, вроде BoundsChecker от NuMega. Реальных конкурентов у него нет, одни слишком медленные и тупые, вторые, может и быстрые, но для хакера совершенно непригодны. На этом этапе, если приложение использует какие-то API-функции из определенного рода библиотек (например, flexlm-библиотек ), то это все станет очевидным.

Можно даже и не пользоваться API-монитором, т.е. динамическим анализом программы. Вполне хватит и статического, если не используется явное связывание (explicit linking). Для статического анализа лучше всего использовать dumbin или dependency walker. Оба от MS.

Очевидно, что любой из видов анализа рано или поздно приведет вас к анализу дизассемблированного кода. Лучше всего использовать IDA. Аналогов ей нет все равно. Вообще, я лично с презрением отношусь ко всяким заявлениям типа «следует юзать только HIEW, потому что настоящие кульные хацкеры юзают только HIEW и ничего больше». Надо уметь пользоваться всем, что под руку попадается.

Так вот, не важно, какой из вышеперечисленных методов используется, так или иначе, мы с вами вышли на файл ChkLic.dll, который экспортирует одну, ну жутко интересную функцию - _CheckValidLicense. Дальше выбора два – либо делать патч непосредственно в dll, либо в зовущем файле – setup.exe. Код выглядит так:

Можно считать, что с первой линией обороны мы справились. Заметьте, что защита flexlm пакету не помогла вообще, мы даже и не узнали, есть ли она там. Авторам надо было хоть немного читать то, что написано в SDK. А ведь ситуация могла бы и изменится, если бы использовалась статическая линковка. Но на каждую хитрую жопу есть хрен с винтом. Выход очень прост. Далее, в файлах icl.exe (интеловский компилятор для IA-32) и ecl.exe (IA-64 вариант) уже никакие dll не используются, и, все равно, это ничем не помогло разработчикам. Здесь можно работать по следующей методике. Сперва нам надо узнать, какая версия flexlm используется, использовать технологию IDA FLAIR, исследовать код вблизи мест проверки lic-файла и взломать прогу.

Для определения версии flexlm можно использовать любой текстовый фильтр, либо тот, который найдет требуемое слово в бинарнике (Search and Replace – kickme.to/FOSI), либо тот, который вывалит все текстовые строки бинарника (мой собственный, например – wasm.ru – filter, "исходники").

Так или иначе:

Верхняя строчка оставлена для хохмы, это вообще одуреть. Строки отчета cvs попали в бинарник! Это ж какое качество компилятора! Ладно, зато теперь нам точно известно, какая версия использовалась. Это дает возможность использовать средства FLAIR для получения файла сигнатур, который поможет элементарно найти нужные строки кода в дизассемблированном листинге. Ниже приведен пример создания файла сигнатур для FlexLM SDK 8.0.

В первой строке запускается парсер для lib-файлов coff-формата (elf-формат идет под Linux). В результате имеем pat-файл. В данном случае запускаем парсер второй раз для получения мультипоточного варианта библиотеки. Потом используется утилита sigmake для объединения полученных pat-файлов в один sig-файл, ключ –n дает файлу название, под которым его видит конечный пользователь. Процесс опознавания библиотечных функций не безупречен, часто появляется файл коллизий. Опять таки, отсылаю к статье Ильфака. Файл коллизий редактируется очень просто. В этом файле представлены функции, которые имеют сходные CRC. Теперь уже нам с вами нужно решать, что с ними делать (ставить "-" для появления имени функции в виде комментария, "+" для обычного вида, не ставить ничего для полного исключения функции из файла сигнатур). Я предпочитаю включать ту, что выполняет более общее действие. Пример:

Здесь поставлен знак «+» перед функцией _l_swap, так как думается мне, что эта функция более напоминает при анализе бинарника функцию flexlm SDK. Аналогично расставляются знаки и для других пар (или большего количества) функций, вызвавших коллизии.

После редактирования .exc файла просто повторите:

Утилита сама поймет, что делать с файлом коллизий на этот раз. В завершение процесса нужно сжать файл сигнатур утилитой zipsig и поместить его в директорию /sig папки IDA.

Дизассемблируем файл icl.exe и ecl.exe. Применяем полученный файл сигнатур (я приложил sig-файлы для FlexLM SDK v6.0/7.2i/8.0). У меня было опознано свыше девятисот(!) библиотечных функций. Теперь мы сравнительно легко придем к нужному результату:

Теперь у нас есть компилятор. Самое время взломать профилировщик.

Используя методы, описанные выше, мы легко сможем обнаружить, что ругательство при запуске VTune выдает AnProdInfo.dll, опираясь на ресурсы из AnProdInfoRes.dll. Дополнительно, чтобы облегчить себе жизнь, нужно использовать команду Soft-Ice – stack – она покажет последовательность вызовов функций и мы сможем вычислить искомую.

STACK – проход стека, FPO и т.п.

Кадр стека (т.е. адресация по ebp либо инструкции enter/leave) - великая вещь, своим появлением он обязан относительно "скудным" возможностям адресации процессоров до 386-го (тогда с адресацией было туговато, не всякий регистр подходил), где в качестве индексного регистра разрешалось использовать только si,di,bx,bp. Теперь в качестве индексного можно использовать любой 32-разрядный регистр, например esp. Тогда кадр стека становится ненужным (т.к. используется адресация переменных по esp ± xxh - такой подход называется frame pointer omission (FPO)), а это есть хорошо для прикладных программистов и не есть хорошо для нас с Вами, т.к. при esp-подходе теряется большая часть символьной информации (например, команда S-Ice stack становится бесполезной, если в функции отсутствует кадр стека). Если разработчик программы - лопух и забыл убрать отладочную информацию, то мы сможем выловить с помощью dumpbin /FPO информацию о количестве переданных параметров и т.п. Пример: с помощью Search&Replace я задал искать слово .debug (есть иногда такая секция в PE-файле) в директории Windows\system. Нашлось файлов 5. Вот часть дампа со случайно взятого файла: Уже сейчас мы можем выяснить размер процедуры, количество переданных параметров, количество локальных переменных и т.п. Если Вы не очень уютно себя чувствуете с кадром стека - почитайте Рэндалла Хайда и проиграйтесь с отладчиком - многое прояснится. Может (и справедливо!) возникнуть еще один вопрос: "Хорошо, я знаю адрес процедуры, количество параметров и прочую ерунду. А КАК мне сделать, чтобы это узнал и Soft-Ice?" Ответ см. ниже - он есть, а пока методику поняли? Ищем секцию отладки в PE-файле (F8,F6 в HIEW) - если есть, она будет называться как-нибудь вроде .debug. Далее извлекаем ее (см. ниже), переводим в понятный S-Ice'у формат (см. ниже ) и работаем дальше.

Результат:

«Однако за время пути собака могла подрасти». Пока писалась эта статья, я совершенно случайно накопал еще один update от Intel на тему Vtune –

<ftp://download.intel.com/software/products/vtune/downloads/>.

Что он делает, в двух словах и не рассказать. В своей статье о профилировщиках я его не описываю тоже, отчасти потому, что работать с ним страшновато. Это надстройка над JavaMachine, да еще к ней прибабахан MySQL-сервер. Для чего все это нужно, мне сказать сложновато. Естественно, все это дело тормозит жутко, а потому вдумчиво его ковырять на предмет радостных сообщений защиты мне было недосуг.

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

Итак, немного поиграв с пакетом, имеем стандартный MessageBox со стандартными фразами. Что здесь можно сделать?

Вещь первая. Если строки сообщения защиты находятся в ресурсах PE-файла, то надо воспользоваться редактором ресурсов (например, Restorator 2.52 – wasm.ru), чтобы узнать их порядковый номер. Пример:

Здесь, "123" – это произвольный (т.е. разработчик брал от фонаря) порядковый номер ресурса, который в дальнейшем будет использован функцией LoadString. Номер этот будет передан функции через стек (таков закон ). Т.е. будет использоваться инструкция push + шестнадцатеричное представление "123" (0x7B). Такой шаблон легко найти в HIEW – в режиме ассемблерного поиска надо ввести push ?7B (отметьте знак вопроса – он означает, что перед 7В может идти что угодно). Чаще всего, вхождений будет несколько, однако что стоит найти правильное?

А дальше, опять таки нужно воспользоваться командой stack в Soft-Ice, чтобы понять, какая последовательность вызовов функций привела к столь плачевному результату.

Вещь вторая. Коль уж вхождение найдено, часто оказывается необходимым ставить bpx не на MessageBox и ему подобные, а на конкретные адреса. Т.к. VTune – продукт, содержащий множество .dll, это автоматически означает, что будет производится перерасчет адресов загрузки .dll (подробнее – моя статья о профилировщиках или многочисленные статьи Мэтта Питрека и Джона Робинса в сети). А это, в свою очередь, означает, что адреса, которые мы увидим в IDA/WDasm/HIEW и т.п. НЕ будут соответствовать адресам в памяти, а предсказать адрес, по которому dll будет загружена, достаточно сложно, т.к. точно не известен порядок, в котором приложение загружает эти dll. Однако выход здесь прост. Старый кракерский трюк с int 3. int 3 имеет опкод 0CCh. Влепите этот опкод в требуемое место программы (не забыв выровнять количество байт и выписать эти самые байты, потому что потом их придется восстанавливать в Soft-Ice). Теперь для того, чтобы Sof-Ice отловил этот опкод, надо активировать опцию i3here on.

После срабатывания точки останова и «всплыва» Soft-Ice необходимо поправить EIP (r eip = требуемое значение) так, чтобы он показывал ПРЯМО на int 3, а не на инструкцию ПОСЛЕ нее (там, где, собственно, и произошел всплыв). После того как поправили EIP, с помощью инструкции "a" или "e" поправьте байты по тому адресу (на те самые, которые выписывали, помните?).

Рано или поздно, исследуя внутренности VTune Enterprise можно наткнуться на функцию ?IsJavaEnabled@CTahoeLicenseMgr@@QAE_NXZ. Это одна из функций защиты приложения. Функция экспортируется библиотекой VTEGUIShared.dll и "спускается" к

Вроде все методики расписаны. Единственная вещь, которая может вызвать легкое смущение – это странный вид имени импортируемой функции. Это – наглядный пример искажения ("замангления") имен.

Теперь можно поговорить о взломе продуктов компании Rational Software (www.rational.com). Это ближайшие конкуренты фирмы NuMega, однако продукты их подходят только для программиста, а не для хакера. Но ведь и мы с вами не только тем занимаемся, что программы ломаем?

Основной пакет – PurifyPlus. Состоит из Purify/Quantify/PureCoverage. Все они тесно интегрируются с VS.NET. Purify – средство выявления утечек памяти и других мелких гадостей, Quantify – весьма неплохой профилировщик, PureCoverage – средство покрытия кода. Всем этим программам есть аналоги от NuMega (TrueTime, TrueCoverage и т.п.), однако в последнее время нужный инструмент от NuMegaне всегда легко найти. С сайта скачать невозможно ничего (в отличие от rational.com, пока!), в сети выловить тоже тяжеловато.

PurifyPlus активно использует flexlm (на момент написания статьи – версия 7.0f), о чем сам и говорит. Взломать эту защиту не составляет никакой сложности. Нетрудно установить, что ругательство ведется из rscommonui.dll. Вообще забавно наблюдать, как все FlexAPI-функции засовываются в одну-единственную на всю программу несчастную функцию, да еще и возвращающую результат типа bool. А потом еще говорят, что flex криво написан. Он-то, может, и криво написан, но используют его еще кривее! Что ж стоит подделать ответ функции, поменять нолик на единичку или наоборот? Да ничего! И никаких больше проверок! А ведь метод, который я предлагаю здесь, неверен в принципе! Здесь мы боремся со следствием, а причина (.lic-файл) остается нетронутой. А борьба со следствием чревата тем, что всегда есть риск проворонить где-нибудь какой-нибудь подлый call и получить уже полные старания фантазии разработчика, вплоть до самоуничтожения программы. Однако сейчас код код пишется настолько неаккуратно, что многие защиты можно взломать, не прилагая особых умственных усилий. В самом деле, все чаще встречаются программы, использующие для защиты либо примитивнейшие самопальные алгоритмы, возвращающие 1 или 0 в результате, либо использующие пакеры/криптовщики, но это уже совсем другая песня…

Патч:

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

Volodya

wasm team.

P.S. Автор выражает искреннею благодарность всем членам wasm team за пинки по делу и вылавливание мелких и крупных блох. Персональное спасибо alexela и cybermaniac.

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

Немного грустных новостей для начала. Приобрести легальную версию данного компилятора для жителей России оказывается чрезвычайно затруднительно. И вопрос упирается даже не в то "сколько он стоит" (а стоит он, если мне не изменяет память что-то в районе тысячи долларов), - компания Intel просто игнорирует данный сегмент рынка. Обращения в российское представительство компании с просьбой предоставить (за деньги!) данный компилятор для его же описания (читай - рекламы и продвижения) в книге "Техника оптимизации программ" положительных результатов не дали, - даже после того, как к этому вопросу подключились прямо-таки скажем не мелкие отечественные издательства BHV и Солон - Р. Ладно, не хотят продавать - ну и не надо! Благо хоть с сервера компании можно свободно утянуть 30-дневный триал. Негусто конечно, но для сравнительного тестирования - вполне достаточно (а для других целей мне этот компилятор и не нужен!).

Впрочем, все оказалось не так просто! С web-сервера компилятор за просто так не отдался, - после заполнения регистрационной формы меня вежливо поблагодарили и сообщили, что сейчас ко мне на мыло упадет письмо с триальной лицензией и инструкцией по ее установке. Это "сейчас" заняло у севера аж несколько дней (такое впечатление, что анкеты просматриваются вручную). ОК! Лицензия получена! Начинаем скачивать файл…. Как это так докачка не поддерживается?! А вот не поддерживается и все! Учитывая, что у меня лишь хлипкий Dial-Up по каналу в 19.200 (да и тот по межгороду) скачать полста мегабайт без единого разрыва просто нереально. К тому же, работа над книгой уже близиться к завершению и вносить в нее еще один компилятор (а, значит, - переписывать кучу текста заново) мне становится просто в лом. Да и Intel C++ это далеко не самый популярный в кругах российских программистов компилятор и книга без него как ни будь уж переживет (хотя, посмотреть как Intel оптимизирует код под свои процессоры очень хотелось, да и документация по компилятору вдохновляла) .

Разозлившись на весь свет (и на парней из Intel в частности) я отправился на ftp-сервер компании, откуда наскоро, всего за каких-то три дня, слил полнофункциональную (хотя и шибко несвежую) версию компилятора, находящуюся по следующему адресу: ftp://download.intel.com/software/products/downloads/C5.0.1-15.exe. (приятно, что ftp докачку исправно поддерживал и многократные разрывы никаких проблем не вызывали). Польстившись на размер, я скачал именно пятую версию компилятора, которая была в полтора раза легче шестой (под которую у меня имелась неиспользованная триальная лицензия) и аж в два раза компактнее седьмой - новейшей на момент написания этих строк - версии, ломать которую из "политических" соображений я все равно бы не рискнул, так зачем же ее зря качать?

Теперь, собственно, мы и подходим к известному философскому вопросу: этично ли ломать программный продукт уважаемой тобой компании или без этого можно обойтись? Да если бы без этого было возможно обойтись, я бы - честное слово - без тени сожаления выложил за этот замечательный продукт пачку вечнозеленых, но, увы… компания не проявляет ко мне как покупателю никакого интереса и, кроме как ломать, ничего другого просто не остается!

Итак, инсталлируем Intel C++ и, предварительно скопировав в просроченную лицензию от шестой версии в папку \Intel\Licenses, запускаем головной файл программы:

Как и следовало ожидать "could not checkout FLEX lm license" ("не могу проверить FLEX lm лицензию") - компилятор ругается и прекращает свою работу. Ага, стало быть, программа защищена FLEX'ом, - достаточно известным в хакерских кругах менеджером лицензий от компании Globetrotter Inc, представляющим собой достаточно продвинутую защиту интегрированного типа. Разработчик защищаемого приложения получает в свое распоряжение SDK, содержащее как тривиальные функции проверки валидности ключевого файла (лицензии), так и развитые средства динамической шифровки файла. При грамотном подходе к защите запустить защищенную программу без наличия соответствующей ей лицензии доподлинно невозможно. Если часть программы зашифрована, - пытаться расшифровать ее без ключа - дохлое дело. Правда не факт, что парни из Intel действительно использовали шифрование, к тому же, зашифрованные фрагменты иногда удается восстановить по косвенным данным. Это смотря, что еще зашифровано!

Разумеется, при наличии триальной лицензии шифровка снимается без труда, но в том-то все и дело, что триальной лицензии у меня не было! Тем не менее надежда меня не покидала и, перекусив для смелости батоном докторской колбасы, сдобренной значительным количеством кетчупа, я запустил свой любимый дизассемблер IDA, и… не знаю у кого как, а у меня вид консольной IDA, распахнутой на весь экран, всегда вызывает чувство благоговения. ОК, ну-ка посмотрим где скрываются те текстовые строки, которые выводятся при отсутствии лицензии на экран. Результат: ни "No such feature exists", ни "could not checkout" в ASCII-строках (т. е. тех строках, что сумел распознать автоматический анализатор IDA) не найдено. Хорошо, зайдем с другого конца: нажимам \<F4> для переключения в hex-режим и давим \<ALT-T> для поиска текстовых строк в "сыром" виде. Что ж, на этот раз поиск "could not checkout" увенчался успехом!

Нажимаем \<F4> еще один раз для возврата в режим дизассемблера, подводим курсор к адресу 42D9C0h и нажимаем A для преобразования цепочки байт в ASCII-строку. В результате мы получаем:

А как узнать: кто же выводит строку-ругательство на экран? Нет ничего проще! Вновь переключившись в режим дизассемблера по \<F4>, давим \<ALT-T> для поиска последовательности "C0 D9 40 00" - адрес строки, представленный в обратном (с учетом порядка следования старших байтов) виде. Опа! Мы видим код наподобие следующего:

Косвенный вызов строки! Ну, собственного, этого и следовало ожидать (иначе с чего бы это автоматических анализатор IDA их не распознал?). Хорошо, преобразуем двойные слова в смещения, руководствуясь при этом тем, что число "42h" должно выпадать на младший байт старшего слова (иначе, адрес ссылки уйдет за диапазон предельно допустимых значений) и получаем:

Попробуем теперь найти ту су…, в общем тот код, что обращается к указателю на ругательную строку, расположенному по адресу 420CE8h? Не надо спешить! По виду полученной таблицы смещений можно с уверенностью заключить, что прямого обращения к ее элементам не будет. Можно предположить, что числа, стоящие возле ссылок на строки - это коды ошибок, а сами строки - соответствующие тексты сообщений. Если так, то с вероятностью близкой к единице, разработчиками программы использовалась относительная адресация, т. е. для вычисления эффективного адреса элемента ее смещение в таблицы суммируются с базовым адресом таблицы, - единственным адресом, который загружается явно.

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

Ага! Есть две перекрестных ссылки! Это хорошо! Теперь поднимемся по ним вверх, - прямиком к вызывающему их коду? Можно, конечно, поступить и так, но есть и более универсальное решение: запустив Soft-Ice, мы устанавливаем точку останова на чтение ячейки 420DE8h (если вы еще не забыли - это адрес элемента таблицы, ссылающийся на искомую ругательную строку). Теперь - кто бы к ней не обращался, Soft-Ice обязательно всплывет, и ведь действительно он всплывает! Пару раз отдав команду "P RET", поднимающую нас из дебрей глубоко вложенных процедур поближе к свету. Наконец, мы взбирается на вершину стека и очередной "P RET" приводит к завершению программы. ОК, повторяем все заново, делая на этот раз на один "P RET" меньше. Записываем любой из близлежащих адресов (пусть это будет для определенности адрес 4031C4h) и натравливаем на него IDA.

Вот это да! - восклицаем мы, пришибленно уставившись на экран. Многое мы ожидали от IDA, но вот чтобы она так запросто представила символьные имена защитных функций, все говорящие за себя: lc_chekout, lc_perror, lc_auth_data… Черт, возьми, как? Вдохновленные смутной надеждой мы неуверенно подгоняем курсор к lc_chekout и нажимаем на \<ENTER>.

Святой Кондратий! И это они еще называют защитой?! Все защитные функции вынесены в отдельную динамическую библиотеку (наверное, чтобы взломщику разбираться было легче?) - LMGR327A.DLL, в названии которой угадывается "Library ManaGeR", причем, это штатные функции FLEX lm, описание которых можно найти в его же SDK (хоть SDK на FLEX ln с компилятором и не поставляется, найти его в Сети - плевое дело).

Отыскав в текущем каталоге этот самый LMGR327A.DLL, мы открываем его HIEW'ов на предмет полного переписывания функции lc_checkout. Ну, насчет "переписывания" автор, ясное дело, загнул. Всего-то и требуется, - заставить lc_checkout всегда возвращать нуль, для чего первые две команды ее тела должны выглядеть приблизительно так: "XOR EAX, EAX / RETN". Записываемся и с дрожью в сердце, запускам icl.exe на выполнение. Критическая ошибка приложения? А чего мы хотели?! Ведь теперь функция lc_auth_data получает неверные данные и гробит все к черту. Впрочем, не будет спешить. Беглое исследование процедуры sub_40A6F8 как будто не выявляет никаких следов шифрования и поэтому ее можно смело удалить, не забыв тоже самое "на всякий пожарный" случай проделать и с lc_auth_data (самое простое - впихнуть в ее начало RETN). Сохраняемся, запускам icl.exe и… компилятор работает! Все! Больше тут нечего ломать!

Самое забавное, что размер защитного механизма (413 Кб) в два с половиной раза превышает размер защищенной с его помощью программы (176 Кб)! Как говорится - no comment.

Ситуация с этим компилятором вкратце такова. В процессе работы над третьим томом "Образа мышления IDA" я исследовал большое количество компиляторов на предмет особенностей их кодогенерации и вытекающих отсюда трудностей восстановления исходного кода. Не избежал этой участи и "Intel Fortran Compiler", обнаруженный на диске "Научись сам программировать на FORTRAN". Краткая аннотация на буклете гласила "Intel FORTRAN Compiler 4.5 - новейшая версия знаменитого компилятора. Для регистрации программы смотрите поддиректорию CRACK". Ну, на счет "новейшего" составили диска явно приврали, т .к. на тот момент уже вышла седьмая версия, да и CRACK оказался некорректным. Вместо того, чтобы ломать защиту, он ломал сам компилятор, необратимо его гробя. К счастью, оригинальный ifl.exe на диске все-таки имелся и это давало возможность заставить работать компилятор мне самому. В конце концов использовать в коммерческих целях этот, бесспорно, замечательный программный продукт я все равно не собирался, а для серии тестовых прогонов не то, что месяца (положенного мне по праву) даже нескольких дней было вполне предостаточно, поэтому с этической точки зрения ничего кощунственного я не совершал (просто мне очень уж не хотелось тянуть ~160 метров из Интернета, с моим междугородним Интернетом это действительно проблематично).

Итак, запускаем оригинальный файл компилятора на выполнение и лицезрим как он спускает на нас Полкана (ругается в смысле):

Ни слова о FLEX lm! (см. "Компилятор Intel С++ 5.0.1") и файл LMGxxx.DLL отсутствует. Странно! Похоже, что Fortran Compiler защищен иначе, что, собственно и не удивительно, поскольку их делали разные группы.

Что ж, запускаем IDA и натравливаем на нее исполняемый файл, который, кстати, занимает всего 176,128 Кб, что с точностью до байта соответствует размеру Intel C++ 5.1 Compiler. Странно! Но, как бы там ни было, ASCII-строки "The evaluation period has expired" автоматический анализатор IDA в тексте дизассемблируемого файла так и не нашел. Что ж, тогда мы сделаем это сами. <F4>, <ALT-T>, "The evaluation period" и…

Теперь, вновь нажимаем <ALT-T> для поиска последовательности "20 A2 42 00" - адрес начала строки, заданный в обратном виде. Результат не заставляет себя долго ждать:

Переключаемся обратно в дизассемблер, трижды жмем <D> для преобразования цепочки байт в двойное слово, затем <O> для перевода его в смещение и… в результате таких манипуляций получаем приблизительно такую же таблицу, как и в нашем предыдущем случае с Intel C++

А посему и действовать мы будем точно так же: поставим бряк на адрес 0419390h и дождемся пока отладчик не получит управления. Кстати, на счет отладчика. В момент написания этих строк у автора как раз закачивалась седьмая версия компилятора Intel C++ и от использования soft-ice пришлось воздержаться (в момент своей активации soft-ice полностью "замораживает" операционную систему, что пагубно влияет на Интернет, а точнее на установленные TCP/IP соединения). И вместо soft-ice автор решил для разнообразия использовать Microsoft WDB, который кстати, справился со своей задачей ничуть не хуже.

Запускам WDB на выполнение, нажимаем <Ctrl?E>, указываем имя загружаемого файла, переходим в окно команд ("Command Window") и устанавливаем точку остановка на адрес 0419398h для чего отдаем команду "BA r4 0x0419398" (что расшифровывается как: "Break on Access of Read 4 bytes long"). Затем для продолжения выполнения программы пишем "G" и с полсекунды ждем…

Внешний вид отладчика MS WBD в процессе ломания программы

Ага, отладчик говорит "Hard coded breakpoint hit" ("сработала аппаратная точка останова") и приостанавливает выполнение отлаживаемой программы. Сама же отлаживаемая программа к этому моменту уже успела вывести на экран:

Обратите внимание на строки, выделенные жирным шрифтом! Очевидно, они свидетельствуют о том, что мы попали не в самое начало защитной процедуры, а где-то в ее середину. Кстати, а что у нас там лежит на стеке? Смотрим (~Viewа Stack, см. рис. 0х003). Всего три адреса, - довольно неглубокий уровень вложения не так ли? Причем (обратив свой взор к окну дизассемблера), сейчас уровень вложения еще понизится, т. к. следующей командой мы выходим из этой процедуры:

Теперь неспешно трассируем код, попеременно поглядывая то на дизассемблированный листинг, то на консоль отлаживаемой программы. Следующая трассируемая функция (внутрь которой мы не заходим, а "заглатываем" ее одним нажатием <F10>) выводит на экран "The evolution period has expired", но не завершает программу, а продолжает ее выполнение. Что ж! Тогда и мы продолжим (трассировку)! Вызов функции 040F5FEh проходит без каких либо внешних проявлений и, так и не поняв, зачем она собственно нужна, мы поднимается на еще один уровень вверх, куда нас забрасывает завершающий функцию RET.

что в ней необычного? А то, что это первая встретившаяся нам материнская процедура, которая анализирует код возврата дочерней функции. В нашем случае регистр EAX содержит значение "ноль" и, стало быть, следующий условный переход выполняется. Но не тот ли это переход который нам нужен? Что ж, сейчас мы это узнаем - нажимаем клавишу <F10> еще несколько раз… Опля! Наш условный переход перебрасывает нас на ту ветку программы, которая спустя несколько команд скоропостижно сдыхает, захлопывая окно программы. А что произойдет, если команду "JE" в строке 401064h заменить на противоположную (или, как вариант, просто удалить этот условный переход)? Пробуем…

Компилятор по прежнему смачно ругается на "evaluation expired", но… он работает! Работает!! Работает!!! По соображением экономии экранного места (в самом деле, ругательство занимает чуть ли не половину экрана и смотрится крайне некрасиво) мы забиваем вызов процедуры 0409140h командами NOP. Проверяем - сработало ли? Ну… это смотря как посмотреть. Трехэтажный мат действительно исчез, но вот лаконичная строка "Evaluation Copy" так и осталась. Найдем что за код ее выводит? Зачем? - лучше найти саму эту строку и тем же HIEW'ом ее переписать во что ни будь более привычное, например: "hacked by mother-fucker guy". Переписываем, и… пользуемся компилятором в свое удовольствие, не забывая, однако о том, что по истечении 30-дневного срока вы будете должны его стереть, в противном случае вы поступите очень и очень нехорошо, да и незаконно.

Как выглядит защита? При каждом запуске программа выводит противный nag-screen, напоминающий сколько дней ей еще "жить" осталось, и тем самым страшно нервирующий: Хорошо, ищем фразу "Number of days remaining in evaluation" во всех файлах программы и, если наша искалка поддерживает уникод, быстро выясняется, что данный текст содержится в файле lockers.dll, открыв который любым редактором ресурсов, мы обнаруживаем в нем тот самый заветный диалог! Остается выяснить: кто же выводит этот диалог на экран? Ищем строку "lockres.dll" во всех файлах программы. ОК, это lockout.dll. Да… и эти разработчики не в ладах с юмором. Запускам dumpbin и смотрим список экспортируемых функций:

Сурово! Во-первых, обращает на себя пара функция DES Encrypt/DES Decrypt, что-то (как и следует из ее названия) зашифровывающая/расшифровывающая. Во-вторых, тройственный подход к наименованию функций, наводит на мысль, что мы имеем дело с "конвертной" защитой, разработанной независимо от защищенной с ее помощью программы, и поддерживающий все основные языки программирования: Си/Си++, Дельфи и конечно же, Visual Basic, узнаваемый по суффиксу VB. В-третьих, такое обилие всевозможных проверочных функций предвещает, что исследование защиты и защищенной программы окажется делом отнюдь не легким! Причем, в те три сотни килобайт, которые занимает файл lockout.dll можно много всяких ловушек и хитростей понапхать, так что на скорый успех нам рассчитывать не приходится. Но… глаза страшатся, а руки делают. Начнем с того, что посмотрим: какие именно функции защитной библиотеки использует программа.

…вот тебе и раз! Защищенная-то программа состряпана на Визуальном Бейсике, о чем красноречиво свидетельствует единственная явно загружаемая ею библиотека MSVBVM60.DLL! Ах, так?! Хорошо, пойдем напролом. Просто удаляем lockout.dll из каталога программы и подсовываем ей любую другую DLL, предварительно переименованную в данную. Запускаем программу. На экране незамедлительно появляется сообщение об ошибке: среда Visual Basic'а ругается, что не может найти функцию EvalModeTestVB. Что ж, это уже кое-что! Загружаем lockout.dll в дизассемблер, находим в нем эту самую "Eval", быстро выясняем, что она является "переходником" к EvalModeTest, которая… которая… Ой-ой-ой, которая занимает до черта килобайт и содержит в себе крайне запутанный с большим количеством глубоко вложенных друг в друга процедур программный код. Да чтобы проанализировать все это и месяца не хватит! А кто сказал, что этот код вообще следует анализировать?! Достаточно просто подсунуть нужный код возврата и все! Весь вопрос в том: какой именно код нужный. Бегло просмотр содержимого функции показал, что существуют как минимум три различных кода возврата: "0", "2" и "3". Если это так, то скорее всего одному из них соответствует состояние "программа не зарегистрирована, но лицензия еще не истекала", "программа не зарегистрирована и лицензия уже истекла", и, наконец, "программа зарегистрирована". Что ж, на перебор трех вариантов не уйдет много времени! Взяв в руки HIEW, переписываем код защитной функции "с нуля": XOR EAX, EAX/RETN.

Возвращаем lockout.dll на ее прежнее место, запускаем Record NOW и… не можем поверить свои глазам, - программа исправно работает! "Исправно" - в том смысле, что nag?screen уже не выводится и по истечении положенных тридцати дней писец по-прежнему живет, а не умирает.

Хорошо, а если бы разработчик защищенного приложения, не поленился бы воткнуть проверку на успешность загрузки функции EvalModeTestVB и при ее отсутствии немотивированно прекращал свою работу? Смогли бы мы тогда узнать: какие функции библиотеки lockout используется, а какие нет? Уговорили! Взломаем программу другим путем! Погоняем курсор к MyCDPro.exe и, нажав на <F3>, пытаемся найти lockout.dll прямым контекстным поиском. Вот, пожалуйста:

Поиск ссылки на lockout.dll в защищенной программе

Прямым текстом: "lockout.dll" и рядышком с ней EvalModeTestVB. Имена остальных защитных функций в исследуемой программе отсутствуют. Самое забавное, что в модуле lockout.dll присутствует огромное количество строк типа: "'User has turned back their clock, so calculating days based on last and init", "The CRC file is valid", "Failed to update the Last Accessed time", - т. е. защита составлена довольно грамотно и в состоянии как следует за себя постоять. Если, конечно, разработчик защищаемого приложения использовал все, предоставленные ей возможности, сполна. Увы, этого не произошло и на этот раз…

Несмотря на бесплатность линкера, Харон очень неплохо его защитил. Во всяком случае у меня на полный анализ защиты (включая развернутое описания взлома и отвлечения на повседневную текучку) ушла добрая неделя! Сейчас, когда пишутся эти строки, даже жалко, что защита так быстро сломалась и то интересное, во что еще можно вонзить свои зубы, закончилось. Впрочем, лучше отложим всю эту ностальгию до лучших времен в сторону, и вспомним, как эта неделя "эротических развлечений с защитой" собственно и начиналась…

…привычным движением руки загружаем исполняемый файл линкера в свою любимую IDA и… IDA грязно ругается по поводу того, что… "can't find translation for virtual address 00000000, continue?". Хм, ну что нам еще остается делать, - покорно жмем "Yes", чтобы сделать "continue". Увы! Наш фокус не увенчался успехом - на экране возникает еще одно ругательство "File read error at 0004C7AC (may be bad PE structure), continue?". Обречено жмем "Yes" и… …IDA просто исчезает. Да-да! Именно исчезает, даже не успев перед смертью выдать сообщение о критической ошибке!!!

Интересный формат файла, однако! Пытаясь выяснить что же в нем содержится такое нехорошее, что так не понравилось IDA, мы решаем натравить на него утилиту dumpbin. Щас! Разбежались - при попытке вывести таблицу импорта, dumpbin выдает сообщение о внутренней ошибке "DUMPBIN: error: Internal error during DumpImports", и только что успев скинуть контекст аварийно прекращает свою работу. Вот, значит, как?! Ну, защита, держись! Сейчас мы заглянем внутрь тебя "вручную", - каким ни будь низкоуровневым инструментом, ну, например, HIEW'ом…

Облом-с! При попытке сделать "prepare import data" HIEW скручивает дулю и, выдав нам на прощание трогательно красное окошко с надписью "Import name No free memory" банально виснет. Конкурирующий с ним QVIEW умирает и вовсе без каких либо пояснений. Утилита "PEDUMP" от Мэта Питтрека (известнейшего исследователя недр Windows) хоть и не виснет, но выдает сообщение о критической ошибке приложения и автоматически прибивается операционной системой. Так, чем еще можно исследовать внутренний формат PE-файла? На ум приходит efd (Executable File Dumper) от Ильфака, но даже эта утилита не справляется - выдав сообщение "Can't find translation for 000002F6 (758.)" она просто прекращает свою работу. Dump PE от Clive Turvey поступает аналогично. Дизассемблер De Win от Милюкова - виснет. Win DASM не виснет, но и не дизассемблирует. Даже знаменитый PROCDUMP распаковывать этот файл отказывается, правда позволяет сделать rebuild PE-заголовка, однако, после такой операции полученный файл становится неработоспособным. В, общем, этот список можно продолжать бесконечно…

Кошмар! Защиты, срывающие крышу отладчику, - это я еще понимаю, но вот чтобы так агрессивно сопротивляется дизассемблеру! Причем, не какой-то одному, конкретно взятому дизассемблеру, а всем дизассемблерам сразу. И в это же самое время защита ухитряется работать в любой Windows-совестимой операционной системе, включая NT и w2k, а, значит, никаких грязных хаков не использует. Харон по определению гений!

Вот мы и столкнулись с тем самым случаем, когда приходится дизассемблировать не готовым дизассемблером, а своими собственными руками и головой! Тяпнув для храбрости пивка, запускаем Иду и загружаем нашего подопытного в бинарном режиме, то есть без анализа заголовков файла. Файл, естественно, успешно загружается. Теперь, открываем свой MSDN на странице "Microsoft Portable Executable and Common Object File Format Specification" и вдумчиво читаем все, что в там написано. Без четкого представления о структуре и порядке загрузке PE-файлов Харонову защиту нам ни за что не сломать. Если чтение фирменных спецификаций вызывает проблемы, попробуйте обратится к сторонним источникам. В том же MSDN содержится масса статей, посвященных исследованию PE?формата, в частности: "The Portable Executable File Format from Top to Bottom" by Randy Kath, русский перевод которой ("Исследование переносимого формата исполнимых файлов сверху вниз") легко найти в Сети. На худой конец можно обойтись и одним лишь заголовочным файлом WINNT.H, входящим в штатный комплект поставки любого windows-компилятора (но разобраться с "голым" WINNT.H сумеет лишь гений!)

Наша задача состоит в том, чтобы вручную проанализировать все заголовки, все секции и все поля исследуемого файла, пытаясь определить: что же такого необычного есть в каждом из них. Спрашиваете: "необычное" - это вообще как? Навскидку можно предположить по крайней мере три варианта: а) защита использует документированные, но малоизвестные возможности PE?файлов, не поддерживаемые распространенными дизассемблерами; б) защита использует недокументированные особенности (и/или поля) PE?файлов, не поддерживаемые дизассемблерами, но корректно обрабатываемые операционной системой; в) разночтения спецификаций PE?формата привели к тому, что разработчики ОС трактовали отдельные поля заголовков по-своему, а разработчики дизассемблеров - по-своему, в результате чего появилась возможность создать такой извращенный файл, корректно загрузить который сумеет одна лишь система, а все остальные исследовательские программы конкретно обломаются на его анализе.

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

С пунктом "б" справится сложнее. Допустим, в фирменной спецификации такое-то поле помечено как неиспользуемое, а в защищенном файле здесь прописано некоторое значение. Как быть? (Дизассемблировать загрузчик операционной системы не предлагать). Да очень просто! Берем hiew старой версии - той, которая ничего не знает о PE и никак его не анализирует - и перебиваем "неиспользуемое" поле нулями или любым другим значением, пришедшимся нам по вкусу. Если это не нарушит работоспособности защищенного файла, - по всей видимости это поле действительно не используется и, соответственно, наоборот.

Пункт "в" еще более сложен. Никакие прямолинейные решения тут не действуют и все, что нам остается - вдумчиво читать каждую букву исходной спецификации и… нет! не стремиться "понять" ее, а пытаться представить себе: как она вообще должна быть понята, чтобы загрузчик операционной системы работал, а дизассемблер - нет. Дайте волю своему воображению, напрягите интуицию - весь многих тонкостей PE-форматов составители документации просто не описали. С другой стороны, сами разработчики ОС данный формат не с потолка брали и по тем же самым спецификациям его и реализовывали. Задумайтесь: а как бы вы реализовали загрузку PE-файла в память? Какие бы комбинации свойств PE-файла вы могли бы использовать для его защиты?

Первое, что нам приходит в голову: инициализация некоторых критических ячеек памяти посредством добавления их адреса в таблицу перемещаемых элементов. А что, это мысль! Особенно привлекательной в этом плане выглядит таблица перемещаемых элементов из old exe - заглушки, расположенной перед PE-файлов и большинством дизассемблеров просто игнорируемой. Но обращает ли системный загрузчик внимание на эти элементы или нет, - вот ведь в чем вопрос! Хорошо, давайте посмотрим на восстановленный old exe заголовок, извлеченный нами из защищенного файла.

Баста карапузики! Нас обломали! Никаких перемещаемых элементов в DOS-заглушке нет, о чем поле e_ovno красноречиво и свидетельствует (в дизассемблерном листинге оно выделено жирным шрифтом). Да и во всех остальных отношениях, old exe заголовок выглядит вполне корректным и приличным. Ладно, лиха беда начало! Отталкиваясь от значения поля e_lfanew, переходим по содержащемуся в нем смещению на заголовок PE-файла.

Вот мы и выяснили, что PE-заголовок защищенного файла не содержит абсолютно ничего интересно, и если кто и завешивает HIEW и срывает IDA крышу, то уж точно не он. Что ж, сделав короткий перерыв (для "пивка"), продолжим наше утомительное исследование формата PE-файла, на сей раз взявшись за так называемый опциональный заголовок (optional header), следующий за концом PE-заголовка.

…и опциональный заголовок не содержит ничего интересного, но вот IMAGE DATA DIRECTORY, расположенная за ним следом, - дело другое и буквально с третий по счету строки мы выходим на след защиты:

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

Пошла вода в хату! Оказывается, в таблице импорта вместо нормальных полей содержится какой-то голимый "мусор", который кое-что проясняет. С такой таблицей импорта дизассемблеры работать просто не могут и… если проверка корректности содержимого таблицы импорта отсутствует, они - виснут, в противном же случае, - аварийно прерывают свою работу с сообщением об ошибке.

Но это совершенно не объясняет как с такой защитой ухитряется работать загрузчик операционной системы? Уж не имеем ли мы дело с некоторыми недокументированными особенностями? Или, быть может, по этим "мусорным" адресам в оперативной памяти расположено что-то особенное? Последнее навряд ли! Поскольку защита успешно функционирует во всех windows-подобных системах, представляется сомнительным, что содержимое данных адресов всегда и везде одно и то же (кстати, беглая проверка отладчиком, это допущение с треском опровергает). Недокументированные возможности? Хм, непохоже… да если так - где прикажите искать реально импортируемые адреса?! Ладно, двигаемся дальше, может быть нам и повезет…

Ага! Держи Тигру за хвост! Защита использует документированное, но малоизвестное поле bound import, - представляющее собой альтернативный механизм импорта функций из DLL. Смотрим, что у нас там…

Вот это уже явно не мусор, а вполне удобоваримая таблица импорта, загружающая динамическую библиотеку kernel32.dll, и импортирующая…. Как это так - никаких функций?! Странно… Но ведь защита все-таки работает (пусть час от часу становится все менее и менее понятно как). Хорошо, давайте рассуждать логически. Программ, не импортирующих никаких функций, под Windows NT существовать в принципе не может. Даже если защита использует native API (т. е. обращается к системным функциям напрямую через прерывание 2Eh), операционный загрузчик окажется не в состоянии загрузить такое приложение, поскольку ему необходимо, чтобы на адресное пространство загружаемого процесса была спроецирована библиотека kernel32.dll. Это в Windows 9x, где системные библиотеки автоматически отображаются на адресные пространства процессов, "голые" файлы работают безо всяких проблем, а в NT, отображающий только явно загруженные библиотеки, такой фокус уже не проходит. А, знаете, это многое объясняет! Теперь становится понятно в частности почему таблица импорта не содержит в себе ни одной функции, - они просто не нужны! Ссылка на kernel32.dll присутствует лишь затем, чтобы спроецировать эту библиотеку на адресное пространство процесса, как этого требует системный загрузчик. Хорошо, но как быть с "мусором" в стандартной таблице импорта? Как ни крути, а такие извращения системный загрузчик скорее удавится, чем обработает… Увы, нам нечего ответить на этот вопрос и, скрепя сердце, его вновь приходится откладывать, надеясь, что последующий анализ отделит свет от тьмы и все расставит по своим местам…

Вот мы и добрались до каталога сегментов! IMAGE HEADER секции ".text" выглядит вполне типично и никаких подозрений у нас не вызывает, но вот следующая за ним секция ".data" очень многое прояснеет…

Ну и что здесь интересного? - спросит иной читатель. А вот что - присмотритесь повнимательнее куда именно грузится содержимое данной секции. Если верить выделенной жирным шрифтом строке, - то по адресу IMAGE_BASE + 0x4B000. Ничего не напоминает? Во-первых, адрес 0x4B000 "волшебным" образом совпадает с адресом "мусорной" таблицы импорта (те, кто поимел сект с защитой этот адрес надолго запомнят, кстати Харону не мешало бы его немножко замаскировать, чтобы он не так бросался в глаза). Во-вторых, изобразив процесс проецирования секций графически (см. рис. 0x05) мы с удивлением обнаружим, что секция .data расположена не следом за секцией .text (как это обычно и бывает), а находится внутри нее. Действительно, давайте подсчитаем: виртуальный адрес секции .text равен 0x1000, а ее размер - 0x49817, и последний байт секции приходится на адрес 0x59817, что превышает виртуальный адрес секции .data, равный 0x4B000.

Так вот оно что! Поскольку, секции отображаются на память в порядке их перечисления в каталоге (недокументированно, но факт!), то содержимое секции .data затирает область адресов 0x4B000 - 0x4E008! А что там у нас расположено?! ТАБЛИЦА ИМПОРТА!!! В дисковом файле по смещению 0x4B000 действительно расположен чистейшей воды мусор (и это косвенно подтверждается тем, что изменения первых 0x14 байт работу программы не нарушают), а истинная таблица импорта расположена непосредственно в секции .data, которой соответствует смещение 0x49E00 дискового файла. Заглянем: что у нас там?!

Вот, это действительно похожее на таблицу импорта со ссылкой на IAT. Кстати, не мешает посмотреть, что за функции импортирует IAT. Подгоняем курсор к "IAT" и, нажав, на смотрим:

Мать родная! Ну почему ты не родишь меня обратно?! Опять вместо символических имен или на худой конец - ординалов, нам попадается этот проклятый мусор! Хотя, - подождите минуточку - давайте попробуем определить что будет расположено по данному адресу после загрузки программы. Возвращаясь к описанию секции .data, мы обнаруживаем, что упустили один очень важный момент. Виртуальный размер секции .data (0x3008 байт) намного больше ее физического размера (0x14 байт) и потому, регион 0x4B014 - 49E008 будет заполнен нулями, а ведь "мусорная" IAT как раз и расположена по адресу 0x4B014! Следовательно, после загрузки ее содержимое окажется заполнено одними нулями, что соответствует пустой таблице импорта функций. Фу-х! Невероятно, но мы действительно в этом разобрались!!! Кстати, подобный прием и широко используется авторами упаковщиков исполняемых файлов.

Аналогичным образом поступает и секция .rsrc, внедрясь в середину секции .text (но секцию .data она не перекрывает), причем, для ослепления некоторых дизассемблеров тут используется еще один хитрый примем: указанный "физический" размер секции .rsrc "вылетает" за пределы дискового файла. Системному загрузчику - хоть бы что, а вот некоторые исследовательские утилиты от этого и крышей поехать могут.

Динамическое замещение таблицы импорта в процессе загрузки PE-файла

Настало время проверить наши предположения на практике. Давайте загрузим эту извращенную программу отладчиком и посмотрим что содержится в памяти по адресу IMAGE_BASE + 0x4B000 = 0x44B000: мусор или нормальная таблица импорта? Отладчик soft-ice (как это и следовало ожидать) обламывается с отладкой этого извращенного файла, просто проскакивая точку входа, а вот WDB сполна оправдывая репутацию фирмы Microsoft (это не ирония!), пусть и не без ругательств, но все-таки загружает наш подопытный файл и послушно останавливается в точке входа.

Обратите внимание на выделенную жирным шрифтом строку: отладчику показалось, что отлаживаемая программа импортирует некоторые функции… из самой себя! Но мы-то, излазившие защищенный файл вдоль и поперек, хорошо знаем, что за исключением kernel32.dll, никаких других экспортируемых и/или импортируемых библиотек здесь нет и такое поведение отладчика, судя по всему, объясняется все тем же самым "мусором". ОК, переключаем свое внимание на окно с дампом памяти, заставляя ее отобразить содержимое таблицы импорта:

Ура! Открываем на радостях пиво! Содержимое памяти доказательно подтверждает, что загрузка файла действительно происходит именно так, как мы и предполагали! Хорошо, но что же нам теперь делать? То бишь, найти-то причину помешательства дизассемблеров мы нашли, но вот как ее нейтрализовать? Ну, это не вопрос! Достаточно лишь скопировать 0x14 байт памяти с адреса 0x49E00 по адресу 0x4B000 и скорректировать ссылку на IAT, направив ее на любое, заполненное нулями, место.

…HIEW теперь заглатывает защищенную программу и даже не пикает! А IDA… а IDA по прежнему отказываться обрабатывать этот файл и с завидным упорством слетает. В чем же причина? Вы, конечно, будете смеяться, но истинный виновник есть ни кто иной как Microsoft! Если бы не ее жутко прогрессивная платформа NET… А, впрочем, чего это я разворчался? Сами смотрите:

Вот это да! С роду такого не было! Чтобы IDA да не правильно опознала формат файла!!! Перемещаем радио-кнопку на одну позицию вниз (ведь мы имеем дело отнюдь не с Microsoft Net assembly, а с PE!) и… IDA успешно открывает файл. Причем, с восстановлением таблицы импорта можно было и не возиться, - IDA просто ругнулась на мусор и все! Но кто ж знал?! Задним умом все мы крепки…

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

Не очень-то это похоже на осмысленный код программы! Может быть, это снова мусор? Маловероятно, - ведь отладчик использует штатный системный загрузчик PE-файлов и потому показывает образ файла таким, какой он в действительности есть, ну… если, конечно, защита тем или иным образом не противостоит отладке. Ладно, отставив разговорчики в строю, начинам трассировать код и… с первых же строк впадаем в некоторое замешательство. Защита опрашивает начальное значение регистра EAX, которое (если верить отладчику!) как будто бы равно нулю, но полной уверенности в этом у нас нет, - еще со времен старушки MS-DOS многие отладчики славились тем, что самостоятельно инициализировали регистры после загрузки, чем и выдавали себя (в частности, при нормальной загрузке файла регистр SI содержал в себе адрес первой исполняемой команды, а при загрузке под отладчиком Turbo Debugger и иже с ним, был равен нулю). Вообще-то, закладываться на "предопределенные" значения регистров - дурной тон. Никто не гарантирует, что в следующих версиях Windows что ни будь не изменится, и если такое вдруг произойдет, то защита откажет в работе, обломав не только хакеров, но и легальных пользователей. Впрочем, начальное значение регистра EAX (AX) по жизни равно нулю, и с некоторой натяжной за это можно зацепиться.

Далее защита непонятно зачем увеличивает старшее слово, только что закинутое в стек, на единицу и вызывает абсолютно бесполезные команды XLAT, DAA, ADD, SBB и… загружает регистр флагов в EAX. Уж не пытает ли она этим самым обнаружить флаг трассировки? Затем делает RETN для передачи управления по адресу: (0x42CFAE + 0x10000) + 0x9753 == 0x446701

…отладчик доходит лишь до RETF и после этого сразу же "дохнет". К тому же, остается совершенно непонятным, что же собственно делает этот запутанный и витиеватый код? При желании, конечно, с ним можно разобраться, но… нужно ли? Ведь отладить нашу подопытную мы все равного не сможем, во всяком случае в WDB.

Хорошо, зайдем с другого конца. Предположим, что программа работает с операционной системой не напрямую (через native API), а через подсистему win32 (win32 API). Тогда, установив точку останова на любую API-функцию, вызываемому программой, мы автоматически попадем в гущу "нормального" программного кода, уже распакованного (расшифрованного?) защитой. Весь вопрос в том: какие именно API-функции вызывает программа. Ну, пусть это будет GetVersion, - с вызова которой начинается стартовый код практически любой программы. Запускаем soft-ice, нажимаем , даем команду "bpx GetVersion", выходим из отладчика, вызываем unlink.exe и… ничего не происходит! - Отладчик не всплывает! Выходит, исследуемая нами программа не использует GetVersion! Что ж, удаляем предыдущую точку останова и пытаемся "забрейкать" CreateFileA (ну должен ли линкер как-то открывать файлы!!!). Так, , bpx CreateFileA, x… Ура! Это срабатывает! Отладчик перехватывает вызов защищенной программы и, после выхода из тела CreateFileA по команде P RET (в CreateFileA для нас действительно нет ничего интересного), мы оказывается в следующем коде:

Обратите внимание: несмотря на отсутствие таблицы импорта, программа каким-то загадочным образом все-таки импортирует из kernell32.dll все, необходимые ей API-функции. Очень хорошо! Секс с native API и прочими извратами программистской хитрости отменяется! И мы остаемся в среде привычной нам подсистемы win32 API. Как именно осуществляется импорт - вот это уже другой вопрос! Кстати, давайте заглянем в одну такую функцию дизассемблером:

Смотрите! В дисковом файле адресов импортируемых функций просто нет и таблица импорта судя по всему заполняется защитой динамически. А это значит, что в дизассемблере мы просто не сможем разобраться: какая именно функция в какой точке программы вызывается. Или… все-таки сможем?! Достаточно просто скинуть импорт работающей программы в дамп, а затем просто загрузить его в IDA! Затем, отталкиваясь от адресов экспорта, выданных "dumpbin /EXPORTS kernel32.dll", мы без труда приведем таблицу импорта в нормальный вид. Итак, прокручивая экран дизассемблера вверх, находим где у этой таблицы расположено ее начало или нечто на него похожее (если мы ошибемся - ничего странного не произойдет, просто часть функций останется нераспознанными и когда мы с ними столкнемся лицом к лицу, эту операцию придется повторять вновь). Вот, кажется, мы нашли, что искали, смотрите:

Условимся считать адрес 0044CC14h началом. Используя точку останова на CreateFileA вновь вламываемся в программу и, отключив окно "data" командой wd, скидываем таблицу импорта в хистори: "d 44CC14". Выходим из Айса, запускаем NuMega Symbol Loader и записываем историю команд в файл winice.log (или любой другой по вашему вкусу). И как со всем этим нам теперь работать? Рассмотрим это на примере функции "call dword_44CC78". Прежде всего мы должны выяснить, какое значение находится в загруженной программе по адресу: 0x44CC87. Открываем winice.log по и смотрим:

Теперь, обратившись к таблице экспорта kernel32.dll, определяем: а) базовый адрес ее загрузки (в данном случае: 0x77E80000); б) имя функции, сумма RVA и IMAGE BASE которой совпадает со значением 0x77E8668C. Вычитаем из 0x77E8668C базовый адрес загрузки - 0x77E80000 и получаем: 0x668C. Ищем строку 0x668C простым контекстным поиском и…

…это оказывается ни кто иной, как GetLastError, что и требовалось доказать. Конечно, восстанавливать весь импорт вручную - крайне скучно и утомительно. Но кто нам сказал, что мы должны это делать именно вручную?! Ведь дизассемблер IDA поддерживает скрипты, что позволяет автоматизировать всю рутинную работу (подробнее о языке скрпитов можно прочитать в книге "Образ мышления - дизассемблер IDA" от Криса Касперски, то есть, собственно, меня).

ОК, еще один барьер успешно взять. Воодушевленные успехом и доверху наполненные выпитым во время хака пивом, мы продолжаем! В плане возвращения к нашим баранам, сосредоточим свои усилия на загрузчике таблице импорта, расположенном по всей видимости где-то недалеко от точки входа. Несмотря на то, что soft-ice по-прежнему упорно проскакивает Entry Point, обламываясь с загрузкой защищенного файла (впрочем, другие версии soft-ice с этим справляются на ура), мы можем легко обхитрить защиту просто воткнув в точку входа бряк поинт. Поскольку, бряк поиск должен устанавливаться во вполне определенном контексте, используем уже известную нам нычку с CreateFileA. Итак, "bpx CreateFileA", , запускаем unlink и, когда soft-ice "всплывает" даем: "bpx 0x446673" (адрес точки входа), выходим из soft-ice и… запускаем ulink вновь. Отладчик тут же всплывает:

Знакомые места! Трассируем код до тех пор пока на не встретится подозрительный RETF (от RET FAR - далекий возврат), передающий управление по следующему адресу:

Судя по адресу, этот код принадлежит непосредственно самой операционной системе (а точнее - NTDLL.DLL) и представляет собой функцию KiUserExceptionDispatcher. Но что это за функция? Ее описание отсутствует в SDK, но поиск по MSDN обнаруживает пару статей Мета Питтрека, посвященных механизмам функционирования SEH и функции KiUserExceptionDispatcher в частности.

Структурные исключения! Ну конечно же! Какая защита обходится без них! Ладно, разберемся, ворчим мы себе под нос, продолжая трассировку защиты дальше. Увы! В той же точке, где WDB терял над программой контроль, soft-ice просто слетает. Ах, вот значит как!!! Ну, защита, держись!!!

(продолжение следует)

Инструменты : Soft-Ice (под '98), немного мозгов

Цель : изучение win32-программ, обладающих защитой от отладки

Примечание : ничего особо нового, простая техника, SEH, etc...

Ниже я собираюсь исследовать защиту этой проги, которая позволяет пользователю использовать ее функциональность только в течении календарного месяца (30 дней) или купить возможность ее использования неограниченно во времени (вид входного окошка после инсталляции, инсталлятор UC3D35TBYB_E.exe):

Что она вообще делает ? Примерно - это какой-то графический редактор (вид после нажатия кнопки "TRY"):

Таким образом в первом приближении сразу после инсталляции данная программа позволяет полноценно работать, но в стартовом окошке напоминает о том, что до конца использования осталось 30 дней ("Remaining Days - 30") и предлагает, видимо, купить разрешение на полное использование ("BUY").

Поисследуем реакцию программы на изменение системной даты. Поменяем текущую дату на один день вперед:

Ага, программа предупреждает нас, что осталось на 1 день меньше. Если перевести дату ровно на месяц вперед, то кнопка "TRY" становится недоступна и число оставшихся дней равно 0:

Кнопка "TRY" недоступна. Попробуем поймать программу на том, как она закрывает для доступа кнопку и поисследовать, чем она при этом руководствуется. Win32-приложение обычно делает это при помощи API-функции EnableWindow:

EnableWindow(Id_Объекта_Окна,0/1-закрыть/открыть Объект)

Устанавливаем на машине дату таковой, чтобы программа решила, что осталось 0 дней для использования, устанавливаем breakpoint в SoftIce:

bpx EnableWindow

запускаем программу, получаем break и видим в отладчике место вызова (оказалось, код принадлежит некоей xsystem.dll, которую можно найти в том каталоге, куда инсталлировалась программа Ulead COOL 3D):

Итак, программа анализирует первый байт некоторой структуры (lea esi,[ebp+2C63h], lodsb, cmp al,90h), сравнивает его с 90h, если он оказывается таковым, то кнопка "TRY" становится недоступной (переход на метку 026D7F8A). Попробуем проверить гипотезу о том, что все, что нужно для "освобождения" программы от проверки даты - это сделать прямо здесь достпуной кнопку "TRY". Попробуем сделать это прямо в отладчике: установим break на адрес 026D7F5F:

bpx LoadLibraryA ; Ждем загрузки xsystem.dll

...

bc 0 ; clear breakpoint at LoadLibraryA

bpx 026D7F5F ; Set breakpoint

Ctrl+D...

и попытаемся дождаться срабатывания break'а и "руками" поменять в отладчике значение регистра al сразу после lodsb: но вместо того, чтобы получить break на этом (026D7F5F) адресе, мы получаем GPF... Видно (в Sice'е), что машина пытается исполнять какой-то мусор в xsystem.dll.

...Так мы выяснили, что программа не только контролирует системную дату, но и сопротивляется нашим попыткам ее трейсить ;) Наверное, программа как-то динамически модифицирует свой код - например по адресу 026D7F5F - и break, который мы пытаемся установить, мы устанавливаем в то место, которое впоследствии будет изменено. Скажем, самораспаковывающийся или саморасшифровывающийся код может быть причиной тому. Попробуем как-то обойти это ограничение и вспоминаем про то, что программа неминуемо должна узнать системную дату - ведь ей необходимо ее сравнить с чем-то типа даты инсталляции. Win32-приложение обычно делает это при помощи API-функции GetSystemTime:

GetSystemTime(offset структуры типа SYSTEMTIME)

Устанавливаем break на эту API-функцию:

bpx GetSystemTime

И обнаруживаем, что вызов произошел из следующего места (опять xsystem.dll):

Уже видно, как программа работает с датой: код по адресу ~026D6DE3 получает косвенным call'ом дату от Win, собирает в 32 битах edx год (07D3h=2003), месяц (03) и день (1Ch=28) - 28 марта 2003 года в данном случае, делает что-то еще и управление попадает к коду в ~026D7F5F, который уже знает, в валидном ли интервале дат мы находимся и закрывает кнопку "TRY", если это не так. Но мы помним, что нужно все же попробовать подменить результат манипуляций с датой прямо перед принятием решения о disable кнопки "TRY". Ранее нам сделать это не удалось - видимо, после загрузки dll в память ее (?-пока не знаем) код самомодифицируется и мешает ставить полноценные break'и. Однако есть надежда, что в момент выполнения кода по адресу ~026D6DE3 - кода, спрашивающего дату у Win - код в ~026D7F5F расшифрован и доступен для отладки. Повторяем попытку установить break на 026D7F5F, но уже после того, как мы попали в 026D6DE3 и опять получаем GPF ! Почему, ведь код уже явно виден в отладчике ? Может, дело в том, что адрес API EnableWindow прописывается динамически прямо в команду mov edi,const_addr ? Пробуем установить break на команду загрузки регистра esi адресом структуры (lea esi,[ebp+2C63h]) и ... оказываемся в нужном месте:

Ура !? Что ж, проверим: модифицируем (в отладчике) регистр al после лодсб и отпускаем программу...

...Так, кнопка "TRY" доступна (хотя Remaining Days = 0). Жмем ее и видим всего лишь вот этот MessageBox:

Вот и познакомились ;) Оказывается, защиту зовут "xLok". А разрешить жать на кнопку - не значит получить доступ к функциональности ;(

Но что если данными для проверки валидности даты для кода в ~026D7F5F является не байт, а слово или даже что-то большее ? На такую мысль может навести пара команд "lea esi,[ebp+2C63h], lodsb" вместо "cmp byte ptr [ebp+2C63h],90h", хотя это может быть "приколом" компиллятора. Внимательнее поизучаем байты в структуре, адресуемой по [ebp+2C63h] для двух дат: для даты в интервале работы и вне ее:

Установим дату вне интервала работы, опять остановимся в отладчике в точке 026D7F68, поменяем "неверные" байты на "верные" (90 90 FF ... -> 6A 01 FF ... ) и "отпустим" программу. MessageBox'а от xLok'а больше нет, но есть банальный GPF...

Следовательно, с большой вероятностью можно заключить, что защита выполняет (динамически) расшифровку какой-то части рабочего кода и снятие всех ее проверок после расшифровки приводит к неизбежному краху, так как этот код расшифровывается неверно вне интервала работы программы. Видимо, защита использует дату (точнее, не саму дату, а некоторую функцию от нее, которая постоянна на интервале работы программы) как ключ шифрования части своего кода. Проверим это: в этом случае будет достаточно подменить системную дату, которую защита спрашивает у Win. В отладчике это легко сделать: опять устанавливаем break на GetSystemTime, возвращаемся в xsystem.dll к коду в 026D6DEE и "патчим" значение структуры SYSTEMTIME (или значение edx чуть ниже) датой инсталляции... Все OK, программа отлично работает и ничего не запрещает.

Здорово, вроде бы осталось поменять команды инициализации edx (код в 026D6DEE и ниже) на что-то вроде таких:

и все будет работать ? Пробуем найти опкоды оригинальных инструкций в DLL:

и не находим их ! Этого следовало ожидать еще тогда, когда стало ясно, что код самомодифицирующийся. Что делать дальше ? Может быть, имеет смысл попробовать найти расшифровшик, проанализировать его алгоритм и "пропатчить" нужные байты в соответствии с алгоритмом ? Пусть алгоритм дешифровщика состоит в наложении xor-последовательности на байты DLL:

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

Помещаем в файл xsystem.DLL по смещению (в файле) 6DEE подготовленные таким образом байты и пытаемся смотреть, что же сделал с ними расшифровщик - а в результате видим такой вот MessageBox:

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

bpm 026D6DEE

и, действительно, наблюдаем следующий код:

Очень интересный код ! Похоже на подсчет CRC (возвращает в eax), причем регион подсчета CRC включает и критичные для нас адреса в ~026D6DEE. Следовательно, прежде чем воевать с их расшифровщиком, нам нужно победить подсчет контрольной суммы. Открыты ли байты подпрограммы подсчета CRC в DLL ?

Ищем их в файле DLL по смещению 510Ch и находим ! Следовательно, мы можем без особой боязни заменить оригинальную подпрограмму подсчета CRC на что-то вроде:

При этом мы вернем нужное где-то дальше CRC (в eax) без всякого подсчета - что зря процессор гонять, хитро вернемся назад (add dword ptr [esp],5) и забьем все остальное место nop'ами. Патчим таким образом DLL и получаем ... GPF ! Оба-на, защита перестала детектировать сосбтвенную модификацию но и программа "рухнула" ;( Неужели мы неправильно составили новый код подсчета CRC ?... Стоп, а ведь мы еще раньше поменяли байты, относящиеся к получению даты (в ~026D6DEE) ! Установим break на API GetSystemTime, вернемся к коду получения даты в DLL и видим, что расшифровщик явно сделал не то, что мы ожидали:

Следовательно, алгоритм расшифровщика производит расшифровку байт в ~026D6DEE в зависимости от исходных байт. Т.е. это не простое наложение XOR-последовательности; расшифровка каждого байта зависит от того, как был расшифрованы все предидущие. Алгоритм расшифровщика нам по-прежнему неизвестен и мы не можем даже пытаться осуществлять атаку на его шифр. Откатим пока эти изменения, оставив лишь получение CRC и продолжим следить в отладчике за ходом выполнения программы защиты после возврата из подпрограммы подсчета CRC:

Если продолжить в отладчике пошагово трассировать код с 026D53A2, то налетаешь на GPF. Но сразу бросаются в глаза явно вычурные для win32-кода команды работы с сегментными регистрами (mov fs:[0],esp). Если уж приложение взялось за это, то явно не с добрыми намерениями ;) На самом деле таким образом в windows пользовательским программам дозволяется установить свой обработчик исключительных ситуаций и в случае таковых получить управление и попытаться их обработать (интересно, кому-нибудь удавалось обрабатывать их инчае как выдать сообщение "Программа выполнила ... и будет закрыта" ?...). Далее мы увидим, что иногда такой обработчик может выполнять некоторые "полезные" действия.

В двух словах о таких обработчиках. Эта штука называется "SEH" - structure exeption handler. Для того, чтобы обработчик правильно получил управление, необходимо:

• поместить в стек смещение обработчика;

• сохранить смещение старого обработчика на том же стеке;

• записать по селектору из FS, смещению 0 содержимое esp

Сам обработчик вызвается в C-формате, при этом получая кучу параметров - указатель на структуру регистров в момент исключения и т.п.:

Но самое главное - это то, что он может вернуться в достаточно произвольное место кода (включая и вызвавшее исключение), при этом уведомив диспечер о том, что исключение им обработано (например, mov eax, ExceptionContinueExecution перед выходом) и то, что он имеет право записи в сегмент команд (это необходимо для исправления "дефектного" кода). Таким образом, обработчик исключения защиты явно собирается именно этим заниматься: подать управление на неверный опкод, поймать expeption, дешифровать некоторые байты, вернуться опять на неверный опкод (не обязательно первый), и так до тех пор, пока необходимый код не будет полностью расшифрован.

Где же защита разместила свой обработчик ? Нет нужды копаться в командах, предшествующих коду установки SEH (~026D5382), можно просто посмотреть стек в этот момент (скажем, после выполнения mov fs:[0],esp):

d esp

Оказыватся, адрес у обработчика равен 026D5040, а вот и он сам:

Итак, обработчик SEH сразу после получения управления начинает что-то расшифровывать с адреса 026D5078 и ниже довольно незамысловатым алгоритмом, немного странно реализованным (вместо add eax,0AB358CDFh достаточно add al,0DFh). Размер байт для дешифровки невелик (mov ecx,94h). Дожидаемся возможности установить break в 026D5078 - после первого же stosb там появлется pop esi и после срабатывания break'а видим весь расшифрованный код:

Что же любопытного в раскрывшемся коде ? Прежде всего обратим внимание на характерный код в 026D5081 - push ebp, mov ebp,esp. Это явно оформлено начало какой-то процедуры, и она заканчивается в 026D510B. Командами

декриптор определил адрес нового обработчика SEH - теперь это будет код в 026D5081. При следующих исключениях всегда будет вызываться именно эта процедура, что-то расшифровывающая командами:

Но в данный момент код получения даты (в ~026D6DEE) еще не расшифрован. Может быть, только что расшифрованная SEH-подпрограмма 026D5081 и есть ее декриптор ? Устанавливаем break на начало 026D5081:

bpx 026D5081

и наблюдаем, как раз за разом управление переходит к SEH-обработчику. Он явно расшифровывает какой-то код и хотелось бы остановить программу в тот момент, когда он полностью закончит свою работу. Довольно утомительно было бы жать Ctrl-D столько раз, поэтому я написал небольшой код, заменяющий собой распаковщик SEH-обработчика:

Новый код в отличии от старого не декриптует SEH-обработчик (это можно сделать прямо в файле xsystem.dll и не обременять код графического редактора дешифрацией), а устанавливает новый адрес SEH-обработчика - это будет подпрогрммка @@ArtBytes, которая только лишь вычисляет число call'ов SEH'а и передает jmp'ом управление на старый адрес 026D5081. Теперь в Sice'е можно ставить условный break на команде mov ax,word ptr [eax+(offset CounterCalls - offset @@GetOfs)]:

bpx IF (AX==0x100)

Заранее, конечно, число call'ов SEH'а неизвестно, но простым методом деления "отрезка" пополам можно довольно быстро добраться до конца работы SEH-обработчика. Трейсим последний вызов по SEH-обработчика и видим, что:

- Даже когда он закончил свою работу, код получения даты (в ~026D6DEE) нерасшифрован;

- Последний свой xor SEH-обработчик выполнил с адресом 026D540Ch:

Таким образом, SEH-обработчик-дешифровщик не расшифровал код получения даты. Но что за байты появились по адресу 026D540Ch ?...

О, старые знакомые ! :) Опять переносимый (call 026D5412, pop esi) код дешифрует нижележащие байты. Ставим break в конец цикла, дожидаемся его окончания и с нетерпением смотрим ... нет, не байты после 026D5440, а байты получения даты - ~026D6DEE. Они расшифрованы, теперь - ура - мы знаем кто их декриптует и этот кто-то (026D540C - последний дешифровщик) крайне мал, чтобы возится с его расшифровщиком (обработчик SEH'а) - проще вбить его, уже нам известный на то же место, где сейчас лежит его зашифрованный собрат. Только тогда нужно будет дезактивировать его расшифровщик (обработчик SEH'а) - а то он все испортит ;) Как же это сделать ? Вернемся к моменту инсталляции SEH'а:

Что будет, если вместо invalid-команды, намеренно сделанной для генерации исключения, сделать переход на дешифровщик в 026D540C, который теперь, как мы планируем, будет записан нами в открытом виде прямо в DLL ? SEH-обработчик явно не вызовется, осталось опасность потерять стек при таком прыжке. Но парная команда к pushfd - последняя команда перед вызовом SEH-обработчика через исключение - popfd:

как будто бы явно написана разработчиками защиты с целью восстановить состояние процесса после отработки SEH'а. Так и поступим. Остался последний момент: где разместить код, который поменяет пресловутые команды получения даты на одну спокойную mov edx,Const_Valid_Date и парочку nop'ов ?

Ниже привожу свое решение, возможно немного надуманное. Поскольку этот код хотелось бы разместить после отработки расшифровщика 026D540C, т.е. тогда, когда уже код от 026D5440 и далее расшифрован, то он должен быть после последней команды расшифровывающего цикла:

Вместо двух байт короткого jmp'а сложновато сделать такое, но если немного пооптимизировать код расшифровщика и вспомнить, что после удаления старого кода подсчета CRC осталась куча места, то можно написать следующее:

Этой командой мы закроем выполнение SEH'а:

Это код нового, открытого декриптора по адресу 026D540C:

Это новый код подсчета CRC вместе с подпрограммой модификации кода получения даты в 026D6DEE:

Вот вроде бы и все ;) Хотя далее есть еще несколько пугающих кусков типа:

которые заставили меня лишний раз заглянуть в Ральфа Брауна, но особой опасности они не представляют ;)

Немного извращений или граффити

После реализации подмены системной даты и многократных смен системной даты в целях выяснинения особенностей защиты программы можно наблюдать интересный эффект:

xsystem.dll уже изменена, все работает, но вот с числом оставшихся дней что-то не то. Как бы не мешает, но некрасиво... Любопытен тот факт, что обратная замена исходной DLL дела не меняет: число оставшихся дней меняется, но как-то "криво". Есть и такой "баг": если даже взять нетронутую версию программы, перевести дату на некоторое число дней вперед, запустить программу, а следом вернуть дату на место, то при первом запуске программа не позволяет работать (число оставшихся дней равно 0, кнопка "TRY" недоступна).

Анализ кода xsystem.dll показал, что после того, как системная дата получена программой, выполняется следующий код:

- из некоторой области памяти достатется число, которое "расшифровывается" xor-ом и далее (код здесь не приводится) трактуется как дата начала работы программы (инсталляции). Поэтому для завершенности изменений в программе можно поменять команду "xor eax,7895ADEBh" на "mov eax,Const_Valid_Date". В этом случае программа будет выдавать 30 дней до конца trial'а. Но можно немного поизвращаться и оставить число Remaining Days вот таким:

Исходный текст патчера

Ниже приводится текст почти полный текст программы, выполняющей описанные выше действия. Некоторые вспомогательные подпрограммы типа GetCL пропущены.

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

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

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

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

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

Рассмотрим простую реализацию данного механизма защиты на примере программы file://CD/SRC/CRACK04/Crack04.exe

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

Самым популярным на сегодняшний день отладчиком является Soft-Ice от NuMega. Это очень мощный профессиональный инструмент. Новички часто испытывают большие трудности при его настройке, поэтому в приложении подробно описывается, как это сделать.

Разумеется, никто не ограничивает свободу читателя в выборе отладчика, однако в настоящее время не существует программ, которые могли бы составить реальную конкуренцию Софт-Айсу. Это вовсе не означает, что другие программы не пригодны для взлома. Большинство из них могут решать рядовые задачи с не меньшим успехом, а узкоспециализированные - в своей области заметно обгоняют Айс. Но уникальность Айса в том, что он покрывает рекордно широкий круг задач и платформ. Кроме того, очень приятен и удобен. Я не знаю ни одного другого отладчика, поддерживающего командную строку.

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

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

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

Хорошая задачка! Откуда же узнать этот адрес? Неужели придется утомительно анализирать код? Разумеется, нет. Существуют гораздо более оригинальные приемы. Начнем с того, что содержимое окна редактирования надо как-то считать. Для этого нужно послать окну сообщение WM_GETTEXT и адрес буфера, куда этот текст следует принять. Однако этот способ не снискал популярности, и программисты обычно используют функции API. В SDK можно найти по крайней мере две функции, пригодные для этой цели, - GetWindowText и GetDlgItemText. Причем первая используется гораздо чаще.

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

Итак, нам нужно установить точку останова на вызываемую функцию. Чтобы узнать, какую, вновь заглянем в список импорта crack04.exe Как мы помним, это приложение использует MFC, а следовательно, крайне маловерятно, чтобы программист, писавший его, воспользовался напрямую Win32 API, а не библиотечной функцией.Вероятнее всего CWnd::GetWindowText, Попробуем найти ее среди списка импортируемых функций. Для этого можно воспользоваться любой утилитой (например IDA) или даже действовать вручную. Так или иначе, мы обнаружим, что ординал этой функции 0xF22. Этого достаточно, чтобы установить точку останова и перехватить чтение введенной строки.

Однако легко видеть, что CWnd::GetWindowText это всего лишь "переходник" от Win32 API GetWindowTextA. Поскольку нам нужно выяснить только сам адрес строки, то все равно перехватом какой функции мы это сделаем, т.к. и та и другая работают с одним и тем же буфером. Это применимо не только к MFC, но и к другим библиотекам. В любом случае на самом низком уровне приложений находятся вызовы Win32 API, поэтому нет никакой нужды досконально изучать все существующие библиотеки, достаточно иметь под рукой SDK. Однако это никак еще не означает, что можно вообще не интересоваться архитектурой высокоуровневых библиотек. Приведенный пример оказался "прозрачен" только потому, что GetWindowTextA передавался указатель на тот же самый буфер, в котором и возвращалась введенная строка. Но разве не может быть иначе? GetWindowTextA передается указатель локального буфера, который затем копируется в результирующий. Поэтому полезно хотя бы бегло ознакомиться с архитектурой популярных библиотек.

Но давайте, наконец, перейдем к делу. Для этого вызовем отладчик и (если это Софт_Айс) дадим команду bpx GetWindowTextA. Попутно укажем, откуда взялась буква 'A'. Она позволяет отличить 32-разрядные функции, работающие с unicode строками (W), от функций, работающих с ANSI строками (A). Нам это помогает отличать новые 32-разрядные фуккции от одноименных 16-разрядных. Подробности можно найти в SDK.

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

Сейчас мы находимся в точке входа в функцию GetWindowTextA. Как узнать адрес переданного ей буфера? Разумеется, через стек. Рассмотрим ее прототип:

Следовательно, стек будет выглядить так:

Переведем окно дампа для отображения двойных слов командой DD и командой d ss:esp+8 выведем искомый адрес. Запомним его (запишем на бумажке) или выделим мышью и скопируем в буфер. Теперь дождемся выхода из процедуры (p ret) и убедимся, что прочитанная строка соответствует введеному имени. (Вполне возможно, что программа сперва читает регистрационный номер и только потом имя).

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

Двойное слово lpString это указатель на строку. Однако это только 32-битное смещение. Но относительно какого сегмента? Разумеется, DS. Поэтому установка точки останова может выгядеть так: bpx ds:xxxxx r. Первый код, читающий строку, на самом деле не принадлежит к отлаживаемой программе. В этом можно убедиться, если несколько раз дать команду p ret, - до тех пор, пока мы не выйдем из функции MFC42!0F22. Как мы помним это ординал CWnd::GetWindowText. Теперь любой обращающийся к строке код будет принадлежать непосредственно защите. Мы, вероятно, уже находимся в непосредственной близости от защитного механизма, но иногда бывает так, что программист читает строку в одном месте программы, а использует результат совсем в другом. Поэтому дождемся повторного отладочного исключения. Рассмотрим код, вызвавший его:

Используемая адресация наталкивает нас на мысль, что eax, возможно, параметр цикла, а вся эта конструкция посимвольно читает строку. Очень похоже, что в самом центре генератора серийного номера. Если мы посмотрим чуть-чуть ниже, то в глаза бросится очень любопытная строка:

Вероятно, она сравнивает введенный нами и сгенерированный регистрационный номер! Переведем курсор на нее и дадим команду here. И последовательно дадим команды d ds:ecx и d ds:edx. В одном случае мы увидим свою строку, а во втором - истинный регистрационный номер. Выйдем из отладчика и попытаемся ввести его в программу. Получилось! Нас признали зарегистрированным пользователем!

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

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

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

Однако мы не закончили взлом программы. Да, мы узнали регистрационный код для нашего имени, но понравится ли это остальным пользователям? Ведь каждый из них хочет зарегистрировать программу на СЕБЯ. Кому будет приятно видеть чужое имя?

Вернемся к коду, сравнивающему эти строки:

Давайте заменим в строке 0040164C 0х52 на 0x51, тогда защита будет сравнивать строку с ней самой. Разумеется, сама с собой строка не совпадать никак не может. Конечно, можно заменить JNZ на JMP или JZ, но это будет не так оригинально.

Замечу, что этот способ срабатывает очень редко. Чаще всего проверка будет не одна и в самых неожиданных местах. Достаточно вспомнить, что регистрационные данные запоминаются защитой в реестре или внешнем файле. Блокировав первую проверку, мы добьемся того, что позволим защите сохранить неверные данные. Очень вероятно, что при их загрузке автор предусмотрел проверку на валидность. Ее можно отследить аналогичным образом, перехватив вызовы функций, манипулирующих с реестром, однако это было бы очень утомительно. Впрочем, не так утомительно, как может показаться на первый взгляд. В самом деле, не интересуясь механизмом ввода данных, можно отследить все вызовы процедуры генерации. Возможны по крайней мере два варианта. Автор либо использовал вызов одной и той же процедуры из разных мест, либо дублировал ее по необходимости. В первом случае нас выручат перекрестные ссылки (наиболее полно их умеет отслеживать sourcer), во втором - сигнатурный поиск. Крайне маловероятно, что автор использовал не один, а несколько вариантов процедуры генератора. Но даже в этом случае не гарантировано отсутствие совпадающих фрагментов. И уж тем более на языках высокого уровня. Далеко не каждый программист знает, что (! a) ? b=0 : b=1 и if (!a) b=0; else b=1 генерируют идентичный код. Поэтому написать одну и ту же процедуру, но так, чтобы ни в одном из вариантов не было повторяющихся фрагментов кода, представляется очень нетривиальной задачей.

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

Вернемся немного назад:

Если мы попытаемся заглянуть в процедуру 0x040192E, то вероятнее всего утонем в условных переходах и вложенных вызовах. Сложность и витиеватость кода наталкивают на мысль, что это библиотечная процедура. Но какая? Дело в том, что отладчик не был правильно настроен и экспортировал только системные функции. Исследуемое приложение активно использует MFC42.DLL, поэтому для загрузки символьной информации о функциях последнего необходимо его явно загрузить. Это делается директивой EXP в файле winice.dat Посмотрим, что у нас получилось:

^^^^^^^^^^^^^^^^^^^^^^

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

Однако отладчики не предназначены для подробного анализа кода. Гораздо удобнее изучать логику программы с помощью дизассемблера. Найти же требуемый фрагмент очень просто. Достаточно вспомнить, что адрес уже известен. Переместим курсор на строку .text:0040161B, для чего в IDA дадим с консоли команду Jump(MK_FP(0,0x40161B)) и прокрутим экран немного вверх, пока не встретим следующие строки:

Очевидно, последний условный переход выполняется, когда длина введенной строки больше девяти символов. Для понимания этого необходимо знать, что CString хранит свою длину в двойном слове, находящемся до начала строки. Итак, непосредственно относящийся к защите код начинается с адреса 0x4015EF. Рассмотрим его:

Это типичный цикл for. Заглянем в его телo:

Загрузка очередного символа строки. Поскольку eax - содержит базовый адрес, то очевидно, что esi - смещение в строке. Выше видно, что начальное значение его равно нулю. Логично, что строка обрабатывается от первого до последнего символа, хотя часто бывает и наоборот.

MOVe and Sign eXtension (пересылка со знаковым расширением) загружает байт в регистр AX, автоматически расширяя его до слова.

Обратим внимание на несовершенство компилятора. Эту команду можно было записать более экономно как movsx cx, [esi+eax]

Подставим всесто регистров их смысловые значения и получим String[idx]*String[idx+1].

Преобразуем eax к машинному слову.

CDQ - Convert Double word to Quad word - Преобразование двойного слова в счетверенное слово

Поскольку 0x41 - это код символа 'A', то, вновь выполнив смысловую подстановку, получим: dl = (String[idx]*String[idx+1]) % 0x20 + 'A'. Т.е автор вычисляет хеш-сумму строки. Обратим внимание, что она будет инъективна для интервала 'A'-'' и, более того, нечувствительна к регистру!

Этот код можно назвать "кодом черной магии". С первого взгляда не понятно как он работает и чем обусловлена нечувствительность к регистру. Обычно для этого программист сначала переводит все буквы в заглавные и только потом начинает разбор строки. Или делает это на лету явным сравнением типа cmp xx, 'a'.

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

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

Перемещаем указатеь idx на следующий символ в строке.

Очевидно, что эти строки также относятся к циклу for. Поэтому уже можно восстановить исходный код генератора.

Теперь нетрудно написать собственный генератор регистрационных номеров. Это можно сделать на любом симпатичном вам языке, например на ассемблере. На диске находится один вариант (file://CD/SRC/CRACK04/key_gen.asm). Без текстовых строк исполняемый файл занимает менее пятидесяти байт и еще оставляет простор для оптимизации. Ключевая процедура может выглядеть так:

Испытаем написанный генератор. Заметим, что в key_gen.asm есть одно несущественное упущение. Он не проверяет минимальную длину строки. Но на деле это не вызывает больших неудобств, зато экономит пяток байт кода.

Генератор успешно работает и вычисляет правильные регистрационные номера. Теперь можно начинать его публичное распространение. Отметим, что последнее совершенно не запрещено законом. И ничьих прав не ущемляет. Использование же генераторов все же вызывает конфликтную ситуацию, т.к. пользователь вводит поддельный регистрационный номер. С другой стороны, это недоказуемо, т.к. сгенерированные номера ничем не отличаются от настоящих. Тем не менее я категорически не советую уповать на это. Лицензиозные соглашения пишутся не для того, чтобы их нарушать. Точно так же и создание собственного генератора не должно побуждать к его использованию, отличному от познавательного. Перечислите автору требуемую сумму или откажитесь от использования программы. Истинный хакер так и поступит. В этом и заключается его отличие от кракеров. Хакер по определению первоклассный специалист, который всегда заработает на необходимое программное обеспечение (или, если он действительно хакер, то напишет свое).

Я понимаю, что такая трактовка может встретить возражение. Действительно, зачем что-то ломать, если хакер все равно должен приобретать лицензиозный софт? Но разве в этом есть что-то нелогичное? Хакер - это взрослый ребенок, удовлетворяющий свое любопытство. Конечно, очень трудно, обладая такими знаниями и навыками, удержаться от соблазна нарушить закон. Более того, я не знаю ни одного человека, который поступал бы именно так. Увы, хакерство действительно оказывается тесно связанным с криминалом. Это, к сожалению, так.

Мир давно привык к тому, что популярные технологии далеко не всегда оказываются хорошими. Вот и в сфере условно-бесплатного программного обеспечения наибольшее распространение получили защиты, генерирующие регистрационный номер на основе имени пользователя (регистрационные защиты). Суть этого механизма заключается в том, что на основе некоторой функции f(name) разработчик преобразует регистрационное имя клиента в регистрационный номер и за некоторую плату отсылает его клиенту. Защита же в свою очередь проделывает с регистрационным именем ту же самую операцию, а затем сравнивает сгенерированный регистрационный номер с регистрационным номером, введенным пользователем. Если эти номера совпадают, то все ОК и, соответственно, wrong reg num в противном случае (см. рис. 0x00F).

Таким образом, защитный механизм содержит в себе полноценный генератор регистрационного кода и все, что требуется хакеру: найти процедуру генерации и, подсунув ей свое собственное имя, просто подсмотреть возращенный результат! Другая слабая точка: компаратор, т. е. процедура, сравнивающая введенный и эталонный регистрационный номера. Если на оба плеча компаратора подать один и тот же регистрационный номер (не важно введенный пользователем или сгенерированный защитой), он, со всей очевидностью, скажет "ОК" и защита примет любого пользователя как родного. Еще один способ взлома: проанализировав алгоритм генератора отладчиком и/или дизассемблером, хакер сможет создать свой собственный генератор регистрационных номеров.

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

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

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

Рисунок 2 0х00F принцип работы регистрационной защиты

Рассмотрим простую реализацию данного защитного механизма на примере программы crackme.58DD2D69h. До сих пор для изучения защитного кода мы пользовались одним лишь дизассемблером, но это не единственный возможный подход к задаче. Не меньшим успехом у хакеров пользуются и отладчики. Отметим, что отладка - более агрессивный способ исследования: в этом случае взлом программы осуществляется "в живую" и со стороны защиты возможны любые "подлянки". Антиотладочный код может запросто "завесить" вашу систему и вообще, выкинуть то, чего вы от него никак не ожидаете. С другой стороны, отладчик обладает многими замечательными (в плане взлома) возможностями, о реализации которых в дизассемблерах пока приходится только мечтать. В первую очередь это относится к точкам останова (по-английски break point), с которыми мы чуть позже с успехом и воспользуемся.

Самым популярным среди хакеров отладчиком был, есть и остается отладчик Soft-Ice от компании NuMega, представляющий собой профессионально-ориентированный инструмент, и потому вызывающий большие трудности у новичков в его освоении. Однако потраченные усилия стоят того! Разумеется, никто не ограничивает свободу читателя в выборе инструментария, - вы можете использовать Microsoft Windows Debugger, Borland Turbo Debugger, Intel Enhanced Debugger, DeGlucker или любой другой отладчик по своему вкусу . Рядовые задачи они решают не хуже айса, а узкоспециализированные отладчики (такие, например, как CUP и Exe Hack) в своих областях даже обгоняют soft-ice. Но уникальность "Айса" как раз и заключается в том, что он покрывает рекордно широкий круг задач и платформ. Существуют его реализации для MS-DOS (ну вдруг кому ни будь понадобится старушка!), Windows 3.1, Windows 9x и Windows NT. Все эти версии Айса несколько различаются межу собой по набору и синтаксису команд, однако эти отличия не столь принципиальны, чтобы вызывать какие либо проблемы. На всякий случай: здесь описывается soft-ice 2.54 под Windows NT.

Итак, загружаем отладчик (под NT это можно сделать в любое время, а в Windows 9x только на стадии загрузки компьютера) и запускаем ломаемое приложение, которое немедленно запрашивает у нас имя и регистрационный номер. Поскольку, регистрационный номер нам доподлинно не известен, приходится набрать что-нибудь "от балды".

Рисунок 3 0х00A реакция защиты на неверно введенный регистрационный номер

Защита, обложив нас матом, сообщает, что "regnum" есть "wrong" и никакой регистрации нам не видать! А чего мы ждали?! Угадать регистрационный номер ни с первой, ни со второй, ни даже с тысячной попытки нереально (регистрационные номера по обыкновению до безобразия длинны) и тупым перебором взломать программу нам не удастся. На это, собственно, и рассчитывал автор защиты. Однако у нас есть преимущество: знание ассемблера позволяет нам заглянуть внутрь кода и проанализировать алгоритм генерации регистрационных номеров. То есть, атаковать защиту не в лоб, а, обойдя укрепленные позиции, напасть с тыла.

Сразу же возникает вопрос: как определить местонахождение генератора, не прибегая к полному анализу исследуемой программы? Давайте представим себе, что генератор это взяточник, а мы - ОБХСС. Роль денег будет играть регистрационное имя, вводимое пользователем. Код, позарившийся на взятку, очевидно и будет самим генератором! То есть, в основе взлома по сути своей лежит перехват обращения к исходным регистрационным данным, избежать которого защита в принципе не может (телепатических возможностей существующие процессоры увы лишены).

Для осуществления такого перехвата нам потребуется всего лишь установить на регистрационное имя так называемую точку останова (break point). Процессор на аппаратном уровне будет контролировать этот регион памяти и при первой же попытке обращения к нему, прервет выполнение программы, сообщая отладчику адреса машинной команды, рискнувшей осуществить такой доступ. Естественно, для установки точки останова требуется знать точное расположение искомой строки в памяти. Спрашиваете, как мы его найдем? Начнем с того, что содержимое окна редактирования надо как-то считать. В Windows это осуществляется посылкой окну сообщения WM_GETTEXT с указанием адреса буфера-приемника. Однако, низкоуровневая работа с сообщениями - занятие муторное и непопулярное. Гораздо чаще программисты используют API-функции, предоставляющие приятный и удобный в обращении высокоуровневый интерфейс. В Platform SDK можно найти по крайней мере две таких функции: GetWindowText и GetDlgItemText. Статистика показывает, что первая из них встречается чуть ли не на порядок чаще, что и не удивительно, т. к. она более универсальна чем ее "коллега".

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

Спрашиваете, как мы сможем перехватить вызов функции? Да все с помощью той же самой точки останова! Единственное, что нам для этого потребуется - адрес самой функции. Но вот какой именно функции? Как уже было сказано выше, функций, пригодных для чтения текста из окна редактирования, существует по меньшей мере две. Программист мог использовать либо ту, либо другую, либо вообще третью…

Поскольку исследуемое нами приложения написано на Microsoft Visual C++ с применением библиотеки MFC (что видно по копирайтам, содержащимся в теле файла, и содержимому таблицы импорта), то представляется достаточно маловероятным, чтобы программист, разрабатывающий его, использовал прямые вызовы win32 API. Скорее всего, он, как истинный поклонник объективно ориентированного программирования, сосредоточился исключительно на MFC-функциях, и употребил CWnd::GetWinowText или производные от него методы. К сожалению, неприятной особенностью библиотеки MFC является отсутствие символических имен функций в таблице экспорта и она экспортирует их лишь по порядковому номеру (так же называемому ординалом - от английского ordinal). При наличии сопутствующих библиотек мы без труда определим какому именно ординалу соответствует то или иное имя, однако, вся проблема как раз и заключается в том, что далеко не всегда такие библиотеки у нас есть. Ведь не можем же мы устанавливать на свой компьютер все версии всех компиляторов без разбора?!

Зацепку дает тот факт, что CWnd::GetWindowText по сути своей является сквозным "переходником" от win32 API функции GetWindowTextA. Поскольку все, что нам сейчас требуемся, - это выяснить адрес регистрационной строки, то не все ли равно перехватом какой именно функции это делать? Материнская функция-обертка работает с тем же самым буфером, что и дочь. Это типичное не только для MFC, но и для подавляющего большинства других библиотек. В любом случае на нижнем уровне приложений находятся вызовы win32 API и поэтому нет никакой нужды досконально изучать все существующие библиотеки. Достаточно иметь под рукой SDK! Однако не стоит так же бросаться и в другую крайность, отвергая идею изучения архитектуры высокоуровневых библиотек вообще. Приведенный пример оказался "прозрачен" лишь благодаря тому, что функции GetWindowTextA передается указатель на тот же самый буфер, в котором и возвращалась введенная строка. Но в некоторых случаях функции GetWindowTextA передается указатель на промежуточный буфер, который впоследствии копируется в целевой. Так что ознакомление (хотя бы поверхностное) с архитектурой популярных библиотек очень полезно. [врезка] как узнать имя функции по ординалу

Если динамическая библиотека экспортирует свои функции по ориналу и только по ординалу, то непосредственно определить имена функций невозможно, поскольку их там нет. Однако при наличии соответствующей библиотеки (обычно поставляющейся вместе со средой разработки) наша задача значительно упрощается. Ведь как-то же определяют линкеры ординалы функций по их именам! Так почему же нам не проделать обратную операцию? Давайте воспользуемся уже полюбившейся нам утилитой DUMPBIN из комплекта поставки Platform SDK, запустив ее с ключом /HEADERS и, естественно, именем анализируемой библиотеки. В частности, для определения ординала функции CWnd::GetWindowText мы должны найти в каталоге \Microsoft Visual Studio\VC98\MFC\Lib файл MFC42.lib и натравить на него DUMPBIN:

…затем в образовавшемся файле находим нужное нам имя и смотрим всю информацию по нему и, среди всего прочего - ординал (в данном случае: 3874h)

Но вернемся к нашим баранам. Нажатием вызываем soft-ice и даем ему команду "bpx GetWindowTextA" Откуда, спрашиваете взялась буква 'A'? Это суффикс, указывающий на ее принадлежность к ANSI-строкам. Функции, обрабатывающие Unicode-строки, имеют префикс 'W' (в Windows 9x они не реализованы и представляют собой лишь "заглушки", а ядро Windows NT, наоборот, работает исключительно с уникодом и уже ANSI - функции представляют собой переходники; более подробно об этом можно прочитать в Platform SDK), выходим из отладчика повторным нажатием или аналогичной по действию командой "x" и вводим в ломаемое приложение свое имя и произвольный регистрационный номер, подтверждая серьезность своих намерений нажатием . Если отладчик был правильно настроен, то он тут же "всплывает". В противном случае вам следует внимательно изучить прилагаемое к нему руководство или на худой конец его русский перевод, который без труда можно найти в сети.

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

Поскольку, все win32 API функции придерживаются соглашения stdcall и передают свои аргументы слева направо, то стек, на момент вызова функции, будет выглядеть так:

Рисунок 4 0x00B состояние стека на момент вызова функции GetWindowText

Переведем окно дампа в режим отображения двойных слов командой "DD" и командой "d ss:esp + 8" заставим его отобразить искомый адрес. Запомним его (запишем на бумажке) или выделим мышью и скопируем в буфер (последние версии soft-ice поддерживают мышь). В частности, на компьютере автора содержимое стека выглядело так:

Выделенное жирным шрифтом число и есть адрес буфера, готового принять прочитанную из окна строку. Посмотрим, что у нас там? Переключившись из режима двойных слов в режим байтов командой "DB", мы говорим отладчику "D SS:2F4018" и… ну конечно же видим вокруг себя один мусор, что и не удивительно, ведь функция GetWindowTextA еще и начинала своего выполнения! Что ж, приказываем Айсу выйти из функции ("P RET") и… вот она, наша строка!

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

Уничтожив ставшей ненужной точку останова на GetWindowText (команда "bc *") мы устанавливаем новую точку останова "bpm ss:2F4018" (разумеется, на вашем компьютере адрес строки может быть и другим) и покидаем отладчик нажатием . Не желая коротать свои дни в одиночестве, отладчик тут же всплывает, сигнализируя нам о том, что некий код попытался обратиться к нашей строке:

Судя по адресу, мы имеем дело с некоторой системной функцией (ибо они традиционно размешаются в верхних адресах), но вот с какой именно? Сейчас выясним! Долго ли умеючи! Наскоро набив на клавиатуре трехбуквенное сочетание "mod" мы заставляем отладчик вывести список всех модулей системы на экран:

Очевидно, что адрес 77E9736Dh принадлежит динамической библиотеке kernel32.dll, а точнее, - функции lstrlenA, которая, как и следует из ее названия определяет длину строки. Поскольку, в определении длины для нас нет ничего интересного, мы безо всякого зазрения совести оставляем этот код жить на бозе и вновь выходим из отладчика, позволяя ему продолжить поиски защитного кода.

Следующее всплытие отладчика оказывается более информативным, смотрите (внимание: в силу архитектурных особенностей x86 процессоров, отладочное исключение возникает не до, а после выполнения команды, "зацепившей" точку останова, а потому отладчик подсвечивает не ее саму, а следующую за ней команду):

Используемая адресация наталкивает нас на мысль, что EAX, возможно, параметр цикла, а вся эта конструкция посимвольно читает строку. Очень похоже, что в мы находимся самом "сердце" защитного механизма - генераторе серийного номера. Если мы посмотрим чуть-чуть ниже, то в глаза бросится очень любопытная строка (в тексте она выделена жирным шрифтом) :

Вероятно, здесь-то защита и сравнивает введенный пользователем регистрационный номер с только что сгенерированным эталоном! Переведем курсор на строку 401650h и дадим команду "HERE", обозначающую буквально "сюда!" Теперь последовательно дадим команды "D DS:ECX" и "D DS:EDX", посредством которых мы сможем подсмотреть содержимое указателей, передаваемых функции в качестве аргументов. Скорее всего, один из них принадлежит введенной нами строки, а другой - сгенерированному защитой регистрационному номеру.

Итак, наше предположение на счет "введенного регистрационного номера" полностью подтверждается, и шансы на то, что абракадабра "GCLAALTQQ[WRT" и есть эталонный регистрационный номер весьма велики (обратите внимание на завершающий ее нуль, отсекающий остаток строки "…58DD2D69", который по невнимательности можно принять за саму строку.

Выйдем из отладчика и попытаемся ввести "GCLAALTQQ[WRT" в программу… Защита, благополучно проглотив регистрационный номер, выводит диалог с победной надписью "ОК". Получилось! Нас признали зарегистрированным пользователем! Вся операция не должна была занять порядка пары-тройки минут. Обычно для подобных защит большего и не требуется. С другой стороны, на их написание автор потратил как минимум полчаса. Это очень плохой баланс между накладными расходами на создание защиты и ее стойкостью. Тем не менее, использование таких защит вовсе не лишено смысла (ведь не все же пользователи - хакеры). Нельзя сказать, что создатели защит совсем уж не представляют насколько их легко вскрыть. Косвенным это подтверждением этого являются убедительные просьбы не ломать защиту, а зарегистрироваться и способствовать развитию отечественного рынка (что особенно характерно для российских программистов). Иной раз они бывают настолько красноречивы и длинны, что за время, потраченное на сочинение подобных опусов, можно было бы значительно усилить защиту.

Вышеописанная технология взлома доступна невероятно широкому кругу людей и не требует даже поверхностного знания ассемблера и операционной системы. Просто ставим точку останова на GetWindowText, затем еще одну на строковой буфер и, дождавшись всплытия отладчика, пытаемся найти в каком месте происходит сравнение введенного регистрационного номера со сгенерированным на основе имени эталоном. Любопытно, но большинство кракеров довольно смутно представляют себе "внутренности" операционной системы и знают API куда хуже прикладных программистов. Воистину "умение снять защиту еще не означает умения ее поставить". Чего греха таить! И автор этой книги сначала научился ломать и лишь затем программировать.

Однако мы не закончили взлом программы. Да, мы узнали регистрационный код для нашего имени, но понравится ли это остальным пользователям? Ведь каждый из них хочет зарегистрировать программу на себя. Кому приятно видеть чужое имя?! Вернемся к коду, сравнивающему строки введенного и эталонного регистрационного номера. Если мы заменим в строке 0040164Eh команду PUSH ECX (опкод 52h) на команду PUSH EDX (опкод 51h), то защита станет сравнивать эталонный регистрационный номер с… самим эталонным регистрационным номером! Разумеется, не совпадать с самим собой регистрационный номер просто не может и какие бы строки мы не вводили, защита воспримет их как правильные. Другой путь - заменить условный переход JNZ в строке 401660h (в тексте он выделен квадратиком) на безусловный переход JZ (тогда защита будет "проглатывать" любые регистрационные номера, кроме правильных), или же забить его любой незначащей командой подходящего размера, например SUB EAX, EAX (тогда будут "проглатываться" любые регистрационные номера, включая правильные), хотя последнее и неоригинально. Запускаем HIEW, переводим его в ASM-режим двойным нажатием , переходим по адресу 401660h (, ".401660") и меняем "jne 1669" на "je 1669", скидываем изменения в файл и запускаем программу. Вводим в нее любую понравившуюся вам комбинации и… это работает!!!

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

Блокировав первую проверку, мы добьемся лишь того, что позволим защите сохранить неверные данные, но наш обман будет немедленно раскрыт как только программа попытается загрузить поддельные данные! Конечно, второй "укрепрайон" защитного механизма можно разбить тем же самым способом, которым мы воспользовались для захвата первого (только на этот раз вместо перехвата функции GetWindowText следует установить точки останова на функции, манипулирующие с файлом и реестром), однако это очень утомительно. Другой, и все такой же утомительный, путь - отследить все вызовы процедуры генерации регистрационного номера по перекрестным ссылкам (если одна и та же процедура вызывалась из разных мест защитного механизма), либо же по ее сигнатуре (если создатель защиты дублировал процедуру генерации). Действительно, крайне маловероятно, чтобы разработчик использовал не один, а несколько независимых вариантов генератора. Но даже в последнем случае очень трудно избежать отсутствия совпадающих фрагментов (во всяком случае на языках высокого уровня). Далеко не каждый программист знает, что "(!a) ? b = 0 : b = 1" и "if (a) b=1; els b=0" в общем случае компилируются в идентичный код. Реализовать один и тот же алгоритм так, чтобы ни в одном из вариантов не присутствовало повторяющихся фрагментов кода, представляется достаточно нетривиальной задачей! Тем не менее, выделение уникальной последовательности, присущей одному лишь защитному коду, - задача ничуть не менее нетривиальная, особенно если в защите присутствует множество проверок, расположенных в самых неожиданных местах.

К счастью, помимо изменения двоичного кода программы (которое, кстати, не очень-то приветствуется законом), существует и другая стратегия взлома: создание собственного генератора регистрационных номеров или, в просторечии, ключеделки. Для осуществления своего замысла хакеру необходимо проанализировать алгоритм оригинального генератора и затем написать аналогичный самостоятельно. Преимущества такого подхода очевидны: во-первых, ключеделка вычисляет действительно правильный регистрационный номер и сколько бы раз защита его ни проверяла - менее правильным он все равно не станет. Во-вторых, с юридической точки зрения создание собственного генератора регистрационных номеров более мягкое преступление, чем модификация защитного кода программы. Правда, возможность наказания за нелегальное использование ПО у законников все равно остается, так что, право же, не стоит так рисковать. Но не будем углубляться в дебри юриспруденции, - пусть трактовкой законов занимаются судьи и адвокаты, нам же - хакерам - лучше сосредоточить свои усилия на машинном коде. Вернемся немного назад, в то самое место, где отладчик зафиксировал обращение к первому байту строки, содержащей имя пользователя, и прокрутим экран дизассемблера немного вверх, до тех пор, пока не встретим начало цикла генератора, определяющееся наименьшим адресом условного (безусловного) перехода, направленного назад (подробнее см. "Фундаментальные основы хакерства" by me главы "Идентификация циклов" и "Идентификация условных операторов").

Прежде нем приступать к восстановлению алгоритма генерации регистрационных номеров, отметим, что отладчики вообще-то не предназначены для декомпиляции кода и нам лучше прибегнуть к помощи дизассемблера. Найти же в дизассемблерном листинге требуемый фрагмент очень просто, - ведь адрес процедуры генератора нам уже известен. Для быстрого перемещения к исследуемому коду в IDA достаточно отдать к консоли команду Jump(0x4015EF) , а в HIEW'e - , ".4015EF". Так или иначе мы встретим следующие строки (а еще лучше, если из мазохистских соображений, мы будем анализировать этот код под отладчиком, поскольку дизассемблер - особенно IDA - доступен не всем):

Регистр ESI здесь инициализируется явно (ESI ^ ESI := 0), а вот чему равен ECX?! Прокручиваем экран отладчика вверх до тех пор, пока не встретим машинную команду, присваивающую ECX то или иное значение:

Ага, здесь в ECX пересылается значение ячейки по адресу [EAX-08], но что это за ячейка и куда указывает сам EAX? Что ж, под отладчиком (в отличии от дизассемблера) его содержимое очень просто подсмотреть! Достаточно дать команду "D EAX" и область памяти на которую указывает EAX немедленно отобразится в окне дампа:

Да это же только что введенная нами строка! А в регистр ECX тогда загружается что? Смотрим: так, значение ECX равно 0Eh или 14 в десятичной системе исчисления. Очень похоже на длину этой строки (как известно, MFC -строки, точнее объекты класса CString хранят свою длину в специальном 32-разрядном поле, родимым пятном которого как раз и является смещение на 8 байт влево относительно начала самой строки). Действительно, имя "Kris Kaspersky" как раз и насчитывает ровно 14 символов (считая вместе с пробелом). Тогда становятся понятными две следующие машинные команды: CMP ECX,0Ah/JGE 4015EFh, осуществляющие контроль строк на соответствие минимально допустимой длине. При попытке ввода имени, состоящего из девяти или менее символов, программа откинет его как непригодное для регистрации. Это важный момент! Многие хакеры игнорируют подобные тонкости алгоритма и создают не вполне корректные генераторы, не осуществляющие таких проверок вообще. Как следствие - пользователь вводит свое короткое имя в генератор (например, "KPNC"), получает регистрационный код, подсовывает его защите и… обложив матом хакера, вводит в генератор другое имя - на сей раз подлиннее. А если защита имеет ограничение на предельно допустимую длину? Сколько так пользователю придется мотаться между защитой и генератором?

Ладно, оставим вопросы профессиональной этики и вернемся к коду генератора, черкнув в лежащем справа от Клавы листке белой бумаги, что EAX указывает на имя пользователя, а ECX содержит его длину.

Здесь: мотаем цикл до тех пор, пока не будут обработаны все символы строки (читатели, знакомые с "Фундаментальными основами хакерства" уже наверняка распознали в этой конструкции цикл for).

Теперь заглянем в тело цикла, спустившись еще на одну строчку вниз:

Здесь происходит загрузка очередного символа строки (и именно этот код вызвал всплытие отладчика при установленной точке останова, так что, надеюсь, вы его все еще помните). Поскольку, EAX - указатель на имя, то ESI с большой степени вероятности - параметр цикла. Правда, немного странно, что очередной символ строки помешается в младший байт регистра ECX, который судя по всему представляет собой счетчик цикла, но это все потом… Пока же мы нам известно лишь то, что начальное значение ESI равно нулю, а потому строка скорее всего обрабатывается от первого до последнего символа (хотя некоторые защиты поступают и наоборот).

MOVe whith Signed eXtension (пересылка со знаковым расширением) загружает следующий байт строки в регистр AX, автоматически расширяя его до слова и загаживая тем самым указатель на саму строку с именем. На редкость уродливый код! Но дальше - больше.

Преобразуем первый прочитанный символ строки к слову (обратим внимание, что здесь и далее под "первым" и "вторым" символом мы будем понимать отнюдь не NameString[0] и NameString[0], а NameString[ESI] и NameString[ESI + 1] соответственно, а сам ESI условно обозначим как index или, сокращенно, idx). Обратим внимание на несовершенство компилятора. Эту команду можно было записать более экономно как MOVSX CX, [ESI+EAX]

Подставим вместо регистров их смысловые значения, мы получаем: EDX:EAX := NameString[idx] * String[idx + 1]

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

Выделяем пять младших бит от оставшегося слова (почему именно пять? просто переведите 1Fh в двоичную форму и сами увидите). Так же, выделяется и старший, знаковый, бит слова, однако, он всегда равен нулю, так как его принудительно сбрасывает предыдущая команда. Зачем же тогда его компилятор так старательно выделает? Осел он - вот почему. Программист присваивает результат беззнаковой переменной, вот компилятор и понимает его буквально!

Если знаковый бит не установлен (ха! а с какой такой радости ему быть установленным?!), то прыгаем на 401618h. Ну что ж! Прыгаем, так прыгаем, избавляя себя от "радости" анализа нескольких никогда не исполняющихся команд защитного кода:

Первая машинная команда добавляет к содержимому регистра AL константу 41h (литера 'А' в символьном представлении) и полученная сумма перегоняется в регистр EDX, минуя по пути локальную переменную [ESP + 14].

С конструкцией LEA ECX, [ESP + 0Ch] разобраться несколько сложнее. Во-первых, ячейка [ESP +0Ch] явным образом не инициализируется в программе, а, во-вторых, значение регистра ECX ни здесь, ни далее не используются. Если бы оптимизирующие компиляторы не выкидывали все лишние операции присвоения (т .е. такие, чей результат не используется), мы бы просто списали эту команду на ляп разработчика защитного механизма, но сейчас такая стратегия уже не проходит. К тому же это удачный повод для знакомства с плавающими фреймами, без умения работать с которыми невозможно побороть практически ни одну современную защиту.

Для начала давайте вспомним устройство "классического" кадра стека. При выходе в функцию компилятор сохраняет в стеке прежнее значение регистра EBP (а так же при желании и всех остальных регистров общего назначения, если они действительно должны быть сохранены), а затем приподнимает регистр ESP немного "вверх", резервируя тем самым то или иное количество памяти для локальных переменных. Область памяти, расположенная между сохраненным значением регистра EBP и новой вершиной стека, и называется кадром. Начальный адрес только что созданного кадра копируется в регистр EBP, и этот регистр используется в качестве опорной точки для доступа ко всем локальным переменным. По мере разбухания стека поверх кадра могут громоздиться и другие данные, заталкиваемые туда машинными командами PUSH и PUSHF (например: аргументы функций, временные переменные, сохраняемые регистры и т. д.). Достоинство этой системы заключается в том, что для доступа к локальным переменным нам достаточно знать всего лишь одно число - смещение переменной относительно вершины кадра стека. Благодаря этому, машинные команды, обращающиеся к одной и той же локальной переменной, из какой бы точки функции они ни шли, выглядят одинаково. То есть, нам не требуется никаких усилий, чтобы догадаться, что MOV EAX, [EBP + 69h] и MOV [EBP + 69h], ECX в действительности обрабатывают одну локальную переменную, а не две. Между прочим, вы зря смеетесь! Хотите получить кукурузный початок в зад? Ну так получайте! (Знаю, что больно, но ведь я же предупреждал!).

Поскольку регистров общего назначения в архитектуре IA-32 всего семь, то отдавать даже один из них на организацию поддержки фиксированного кадра стека по меньшей мере не логично, тем более, что локальные переменные можно адресовать и через ESP. Ну и в чем же разница? - спросите вы. А разница между тем принципиальна! В отличии от EBP, жестко держащего верхушку кадра за хвост, значение ESP изменяется всякий раз, когда в стек что-то вложат или, наоборот, что-то вытащат оттуда. Рассмотрим это на следующем примере: MOV EAX, [ESP+10h]/PUSH EAX/MOV ECX, [ESP + 10h]/PUSH ECX/MOV [ESP + 18h], EBP, - как вы думаете, к каким локальным переменным здесь происходит обращение? На первый взгляд, значение ячейки [ESP + 10h] дважды засылается в стек, а затем в ячейку [ESP +18h] копируется содержимое регистра EBP. На самом же деле тут все не так! После засылки в стек содержимого регистра EAX, указатель вершины стека приподнимается на одно двойное слово вверх и дистанция между ним и локальными переменными неотвратимо увеличивается! Следующая машинная команда - MOV ECX, [ESP + 10h] на самом деле копирует в регистр ECX содержимое совсем другой ячейки! А вот [ESP + 18h] после засылки ECX указывает на ту же самую ячейку, что вначале копировалась в регистр EAX. Ну и как теперь насчет "посмеяться"?

Такие оптимизированные кадры стека по-русски называются "плавающими", а в англоязычной литературе обычно обозначаются аббревиатурой FPO - Frame Pointer Omission. Это едва ли не самое страшное проклятие для хакеров. Основной камень преткновения заключается в том, что для определения смещения переменной в кадре мы должны знать текущее состояние регистра ESP, а узнать его можно лишь путем отслеживания всех предшествующих ему машинных команд, манипулирующих с указателем верхушки стека и, если мы случайно упустим хоть одну из них, вычисленный таким трудом адрес локальной переменной окажется неверным! Следовательно, неверным окажется и результат дизассемблирования!!! Вернемся к нашему примеру LEA ECX, [ESP + 0Ch]. Будем прокручивать экран "CODE" отладчика вверх до тех пор, пока не обнаружим пролог функции или не накопим по меньшей мере 0Ch байт, закинутых на стек командами PUSH (в квадратных скобках показано смещение соответствующих ячеек относительно вершины стека на момент вызова нашего LEA).

Ну, что Шура, я Вам могу сказать, - если считать, что SUB ESP, 10h открывает фрейм функции, то LEA ECX, [ESP + 0Ch] лежит по смещению 04h от его начала, - аккурат посередине. А что у нас здесь? Листаем код ниже (в квадратных скобках показано смещение соответствующих ячеек относительно начала кадра стека):

Ага! Вот теперь мы видим, что указатель на локальную переменную, расположенную по смещению 04h от начала кадра стека (далее просто var_04h) передается функции 40190Ah очевидно для ее, переменной, инициализации. Но вот что делает эта загадочная функция? Если, находясь в отладчике, нажать для входа в ее тело, мы обнаружим следующий код:

Узнаете? Ну да, это характерный способ вызова функций из динамических библиотек. Но вот какая функция какой именно библиотеки сейчас вызывается? Ответ хранит ячейка 402164h, содержащая непосредственно сам вызываемый адрес. Посмотрим ее содержимое?

Остается только узнать какому модулю принадлежит адрес 6C9198Eh. Не выходя из soft-ice даем ему команду "mod" и смотрим (протокол, приведенный ниже по понятным соображениям сильно сокращен):

Легко видеть, что адрес 6C29199Eh принадлежит модулю MFC42.DLL, что совершенно неудивительно ввиду того, что данная программа действительно интенсивно использует библиотечку MFC. Чтобы не вычислять принадлежность всех остальных функций вручную давайте просто загрузим символьную информацию из MFC42.DLL в отладчик. Запустив NuMega "Symbol Loader" (если только вы еще не сделали этого ранее), выберите команду "Load Exports" в меню "File", а затем, перейдя в папку "\WINNT\System32\" дважды щелкните по строке с именем "MFC42.DLL". Теперь, тот же самый код под отладчиком будет выглядеть так:

Умница soft-ice определил не только название динамической библиотеки, экспортирующей вызываемую функцию, но и ее ординал! Что же касается имени функции, его можно вычислить с помощью DUMPBIN и библиотеки MFC42.lib. Даем команду "DUMPBIN /HEADRES MFC42.LIB >MFC42.headrs.txt" и затем в образовавшемся файле простым контекстным поиском ищем строку "Ordinal : 539", где "539" наш ординал 021Bh записанный в десятичном виде (именно так выдает оридиналы этот dumpbin). Если все идет пучком, мы должны получить следующую информацию:

Так, это конструктор объекта типа CString, а указатель, передаваемый ему, стало быть и есть тот самый this, что указывает на свой экземпляр CString! Следовательно, var_4 - это локальная переменная типа "MFC-строка". Теперь, не грех вернуться к изучению прерванной темы (а прервали мы ее на строке 40161Ah, где осуществлялась загрузка указателя на var_4 в регистр ECX посредством машинной команды LEA; регистр же EDX, как мы помним, содержит в себе результат умножения двух символов исходной строки, преобразованный в литерал):

Следующими двумя командами мы заталкиваем полученный литерал в стек, передавая его в качестве второго аргумента функции MFC42!ORD_03AB (первый аргумент функций типа __thiscall передается через регистр ECX, содержащий указатель на экземпляр соответствующего объекта, с которым мы сейчас и манипулируем). Преобразовав ординал в символьное имя функции, мы получаем "оператор +=", что очень хорошо вписывается в обстановку окружающей действительности. Другими словами, здесь осуществляется посимвольное наращивание строки var_4 генерируемыми налету литералами.

Что у нас в [ESP + 8]? Прокручивая экран с дизассемблерным листингом вверх, находим, что здесь лежит самая первая ячейка из принадлежащих кадру стека. Условимся называть ее var_0. Давайте определим, что же за информация в ней находится?

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

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

Первая машинная команда из четырех загружает длину регистрационной MFC-строки в регистр ECX, команда "DEC" уменьшает ее на единицу, а "CMP ESI, ECX" сравнивает полученное значение с индексом текущего обрабатываемого символа регистрационной строки. И, до тех пор, пока индекс не достигнет предпоследнего символа строки, условный переход "JL" прыгает на адрес 4015F7h, мотая цикл.

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

Брр! Вы еще не запутались?! Что ж, тогда давайте подытожим все вышесказанное краткими комментариями к защитному коду:

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

Остается лишь написать собственный генератор регистрационных номеров. Это можно сделать на любом симпатичном вам языке, например на ассемблере. На диске находится один вариант (file://CD/SRC/crackme.58DD2D69h/HACKGEN/KeyGen.asm). Ключевая процедура может выглядеть так:

Испытаем написанный генератор. Запустив откомпилированный файл KeyGen.exe на выполнение, введем в качестве регистрационного имени какую ни будь текстовую строку (например, свое собственное имя или псевдоним), - не пройдет и секунды как генератор выдаст подходящий regnum в ответ. В частности, имени "Kris Kaspersky" соответствует следующий регистрационный код: "GCLAALTQQ[WRT"

Рисунок 5 0х00С демонстрация работы ключеделки

Генератор успешно работает и вычисляет правильные регистрационные номера. Однако, вводить регистрационный номер вручную не только утомительно, но и неэлегантно. Да, можно скопировать его и через буфер обмена, но все равно возня будет еще та. В конечном итоге, компьютер на то и придуман, чтобы служить пользователю, но не наоборот. Идеальный crack - это такой crack который не докучает пользователю теми вопросами, ответ на которые знает сам, равно как и не требует от последнего никаких действий, которые он может выполнить и самостоятельно. Единственное, что требует такой crack - своего запуска. Короче, хорошая программа должна заботиться о себе сама!

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

Во времена старушки MS-DOS эта проблема решалась перехватом прерывания int 16h с целью эмуляции ввода с клавиатуры. Ломалка, грубо говоря, прикидывалась пользователем и подсовывала защищенной программе сначала имя, а затем и сгенерированный регистрационный номер. От самого же пользователя не требовалось ничего, кроме запуска такой программы. Ну разве не красота? К сожалению, с переходом на Windows прямой контроль над прерываниями оказался безвозвратно утерян и все трюки старой Лисы перестали работать…

Но, "мало того, что их сосед в жилом доме свинью держит, так он еще и круглосуточно над ней измывается..." . Незадачливого музыканта подвела хорошая межквартирная слышимость (читай: хреновая звукоизоляция). Так вот, Windows с точки зрения безопасности - та же хрущоба и слышимость в ней о-го-го! Архитектура подсистемы пользовательского интерфейса, достающаяся NT/9x в наследство от незаконно рожденной Windows 1.0, неотделима от концепции сообщений (messages) - эдакой собачей будке, перенесенной с заднего двора на самое видное место. Любой процесс в системе может посылать сообщения окнам любого другого процесса, что позволяет ему управлять этими окнами по своему усмотрению. Хотите "подсмотреть" содержимое чужого окна? Пожалуйста! Пошлите ему SendMessage с WM_GETTEXT и все дела! Хотите послать окну свою строку с приветствием? Нет проблем, - SendMessage в купе с WM_SETTEXT спасут отца русской демократии! Аналогичным образам вы можете нажимать на кнопки, двигать мышь, раскрывать пункты меню, словом полностью контролировать работу приложения. Самое интересное, что уровень привилегий при этом никак не проверяется, - процесс с гостевыми правами может свободно манипулировать окнами, принадлежащими процессу-администратору. Знаете, в NT/w2k есть такое забавное окошко "запуск программы от имени другого пользователя", обычно используемое для запуска привилегированных приложений из сеанса непривилегированного пользователя? Ну вот например захотели проверить вы свой жесткий диск на предмет целостности файловой структуры, а перезапускать систему под "Администратором" вам лень (точнее, просто не хочется закрывать все активные приложения). На первый взгляд никакой угрозы для безопасности в этом нет, ведь "запуск программы от имени другого пользователя" требует явного ввода пароля! А вот получи треска гранату, - любое злопакостное приложение сможет перехватить ваш пароль только так! Причем, речь идет не о какой-то непринципиальной недоработке, которая легко устранима простой заплаткой (в просторечии называемой "падчем").

Нет! Все так специально и задумывалось. Не верите? Откроем Рихтера "…система отслеживает сообщения WM_SETTEXT и обрабатывает их не так, как большинство других сообщений. При вызове SendMessage внутренний код функции проверяет, не пытаетесь ли вы послать сообщение WM_SETTEXT. Если это так, функция копирует строку из вашего адресного пространства в блок памяти и делает его доступным другим процессам. Затем сообщение посылается потоку другого процесса. Когда поток-приемник готов к обработке WM_SETTEXT, он определяет адрес общего блока памяти (содержащего новый текст окна) в адресном пространстве своего процесса. Параметру lParam пристраивается значение именного этого адреса, и WM_SETTEXT направляется нужной оконной процедуре. Не слишком ли накручено, а?" Выходит, разработчики оконной подсистемы искусственно и крайне неэлегантно обошли подсистему защиты Windows, разделяющую процессы по их адресным пространствам. Естественно, это делалось отнюдь не с целью диверсии, - просто запрети Microsoft посылку сообщений между процессами куча существующих приложений (написанных большей частью под Windows 3.x) тут же перестала бы работать! А значит, эмуляция ввода с клавиатуры жила, жива и будет жить!

Единственное, что нужно знать - так это дескриптор (handle) окна, которого вы хотите "осчастливить" своим сообщением. Существует множество путей получить эту информацию. Можно например воспользоваться API-функцией FindWindow, которая возвращает дескриптор окна по его названию (текстовой строке, красующейся в заголовке) или тупо переворошить все окна одно за другим, в надежде что рано или поздно среди них встретиться подходящее. Перечисление окон верхнего уровня осуществляется функцией EnumWindows, а дочерних окон (к которым диалоговые элементы управления как раз и принадлежат) - EnumChildWindows.

Собственно, получить дескриптор главного окна ломаемого приложения - не проблема, ведь мы знаем его имя, которое в большинстве случаев однозначно идентифицирует данное окно среди прочих запущенных приложений. С дочерними окнами справиться не в пример сложнее. Ладно, кнопки еще можно распознать по их надписи (получаем дескрипторы всех дочерних окон вызовом EnumChildWindows, а затем посылаем каждому из них сообщение WM_GETTEXT с требованием сказать как кого зовут, после чего нам останется лишь сопоставить дескрипторы кнопок с их названиями). К сожалению с окнами редактирования такой фокус не пройдет, ибо по умолчанию они вообще не содержат в себе никакой информации, - вот и разбирайся это окно для ввода регистрационного имени или номера?

На помощь приходит тот факт, что порядок перечисления окон всегда постоянен и не меняется от одной операционной системе к другой. То есть, определив назначения каждого из дочерних окон экспериментально (или с помощью шпионских средств типа Spyxx из комплекта SDK) мы можем жестко прописать их номера в своей программе. Например, применительно к crackme.58DD2D69h это может выглядеть так: запускаем наш любимый soft-ice и даем команду "HWND" для выдачи списка всех окон, включая дочерние, зарегистрированных в системе.

Ага! Вот они окна редактирования (см. текст выделенный жирным шрифтом), - третье и пятое по счету дочернее окно в списке перечисления. Одно из них наверняка принадлежит строке регистрационного имени, а другое - регистрационного номера. Но как узнать какое кому? Воспользовавшись ключом xc, заставим sof-ice выдать более подробную информацию по каждому из окон:

Как легко установить по координатам вершин окон, первое из них находится на 26 пикселей выше другого (546 против 572), следовательно первое окно - окно регистрационного имени, а второе - окно регистрационного номера.

Теперь, когда порядковые номера окон редактирования известны можно накрапать следующую несложную программку:

}

Теперь перейдем непосредственно к технике эмуляции ввода. Ну, ввод/вывод текста в окна редактирования больших проблем не вызывает: WM_SETTEXT/WM_GETTEXT и все пучком, а вот "программно" нажать на кнопку несколько сложнее. Но ведь вам же хочется, чтобы программа не только ввела в соответствующие поля всю необходимую регистрационную информацию, но и самостоятельно долбанула по , чтобы закончить ввод?!

Как показывает практика, посылка сообщения BM_SETSTATE элементу управления типа "кнопка" не приводит к ее нажатию. Почему? Наша ошибка заключается в том, что для корректной эмуляции ввода мы во-первых, должны установить фокус (WM_SETFOCUS), а после перевода кнопки в состояние "нажато" этот фокус убить (WM_KILLFOCUS), ведь, как известно даже желторотым пользователям, кнопки срабатывают не в момент их нажатия, но в момент отпускания. Не верите? Поэкспериментируйте с любым приложениям и убедитесь в справедливости сказанного. Кстати, забавный трюк: если под NT/w2k в сообщение WM_KILLFOCUS передать недействительный дескриптор окна, получающего на себя бразды правления, то операционная система по понятным соображениям не передаст фокус несуществующему окну, но у активного окна фокус все-таки отберет. Windows 9x, напротив, оставляет фокус активного окна неизменным! Вот такая разница между двумя операционными системами. Еще одна делать на последок. Если в роли убийцы фокуса выступает функция SendMessage по поток, эмулирующий ввод, блокируется вплоть до того момента, пока обработчик нажатия кнопки не возвратит циклу выборки сообщений своего управления. Чтобы этого не произошло, - используйте функцию PostMessage, которая посылает убийцу фокуса и, не дожидаясь от него ответа, как ни в чем не бывало продолжает выполнение.

Рисунок 6 0х00D "автоматическое" считывание имени пользователя, ввод регистрационного номера и эмуляция нажатия на клавишу "ввод"

Испытаем наш автоматический регистратор? (file://CD/SRC/crack-me58DD2D69h/HACKGEN2/autocrack.c). Запустив защищенную программу и при желании заполнив поле имени пользователя (если его оставить пустым, автоматический регистратор использует имя по умолчанию), мы дрожащей от волнения рукой запускаем autocrack.exe… Держите нас! Это сработало! Вот это автоматизация! Вот это хакерство! Вот это мы понимаем! [врезка] как сделать исполняемые файлы меньше

Даже будучи написанным на чистом ассемблере, исполняемый файл генератора регистрационных номеров занимает целых 16 килобайт! Хорошенький монстр, нечего сказать! Хакерам, чей первый компьютер был IBM PC с процессором Pentium-4, может показаться, что 16 килобайт это просто фантастически мало, однако еще в восьмидесятых годах существовали компьютеры с объемом памяти равным этому числу! Впрочем, зачем нам так далеко ходить, - откроем первое издание настоящей книги: "Без текстовых строк исполняемый файл [генератора] занимает менее пятидесяти байт и еще оставляет простор для оптимизации". Сравните пятьдесят байт и шестнадцать килобайт, - переход с MS-DOS на Windows увеличил аппетит к памяти без малого в триста раз!

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

С чисто же эстетической точки зрения держать у себя такой файл действительно нехорошо. Обиднее всего, что на 99% генератор состоит из воздуха и воды, - нулей, пошедших на вырывание секций по адресам, кратным 4Кб. Три секции (кодовая секция .text, секция данных .data и таблица импорта .itable) плюс PE-заголовок, - вместе они эти самые 16 Кб и создают. Полезного же кода в исполняемом файле просто пшик - немногим менее двухсот байт. Конечно, двести это не пятьдесят и с переходом на Windows мы все равно проигрываем и в компактности, и в скорости, но все-таки кое-какой простор для оптимизации у нас имеется.

Начнем с того, что прикажем линкеру использовать минимальную кратность выравнивания из всех имеющихся, - составляющую всего четыре байта. Указывав в командной строке ключ "/ALIGN:4" мы сократим размер исполняемого файла с 16.384 до 1.032 байт! Согласитесь, что с таким размером уже можно жить!

Причем, это далеко не предел оптимизации! При желании можно: а) выкинуть MS-DOS stub, который все равно бесполезен; б) подчистить IMAGE_DIRECTORY; в) использовать незадействованные поля OLD EXE/PE-заголовков для хранения глобальных переменных; г) объединить секции .text, .data, .rdata в одну общую секцию, сведя тем самым эффективную кратность выравнивая к одному и высвободив еще трохи места за счет ликвидации двух секций. Словом, возможности для самовыражения под Windows все-таки имеются!

Прежде всего, как распознать наличие защиты SLM? Обычно, пресловутые клиенты Sentinel поставляются вместе с комплектом драйверов Rainbow под названием вроде lserv.XXX, ldriv.XXX и т.п. Правда, наиболее бросающимся в глаза отличием можно считать присутствие электронного ключа для внешнего подключения (LPT, USB). Ключ (он же -- dongle) зачастую пугает новичков. Его всё-таки стоит бояться в серьёзных и грамотно построенных защитах (есть и такие!), но в случаях подобных тому, который мы в дальнейшем рассмотрим, гн. Донгл -- безобидный кусок электронно-пластикового лома размером 5,5 на 4 см. Ещё одна важная особенность SLM и её основная уязвимость -- это наличие текстового файла с лицензионной информацией. Имя файла произвольное, а содержимое примерно следующего типа:

После version "n" может идти expires и другие подробности лицензируемой фичи. На самом деле, парсер SLM воспринимает символ '#' как начало комментариев, т.е. он просто игнорирует всё остальное до конца строки.

Примечание: лицензионный файл может и отсутствовать.

Итак, настало время назвать почётного таргета нашего исследования. Пора рискнуть привлечь внимание антипиратских организаций... Сегодня на операционном столе побывает один из самых популярных IDE для VLSI дизайнеров на букву 'L'. Больше не скажу -- не камикадзе я :-) Так вот, для тех кто в танке: CD с 30-дневной полнофункциональной демо можно заказать на сайте TR. Если мой таргет не совпадает с вашим, не отчаивайтесь -- данное руководство применительно к большинству клиентов SLM (уже проверил на 5-и различных таргетах).

• Внимание! Перечень операционного инвентаря:

• SentinelLM SDK 7.1 (где достать -- писали в форуме wasm.ru)

• Сигнатуры SentinelLM для IDA Pro (лежат в разделе "инструменты")

• IDA Pro собственной персоной (даже не спрашивайте ;-)

• SoftIce (куда же без него?)

• MASM32

• Hiew

• ... удобное кресло перед компом!

Перед тем как приступить к делу, предлагаю разделить процесс на 5 этапов:

1. Получение Vendor Id нашей жертвы.

2. Генерация S/N для Vendor Id из предыдущего пункта.

3. Долгое и нудное -- но одноразовое -- кряканье над SDK.

4. Успешное получение новой постоянной плавающей лицензии.

5. Осторожное проделывание отверстия в донгле для последующего превращение оного в стильный брелок.

Вот, собственно, и всё. Качайте SDK и прочий инструментарий, внимательно изучайте лицензионный файл, читайте доки о внутреннем устройстве донгла (для общего развития)... Дописываю первую главу о Vendor Id. Жду комменты и пожелания.

Сентинельная защита, как такова, распространяется Reinbow Technologies ввиде оболочки API, т.е. комплекса драйверов, DLL, документации и прочих любимых программистами мелочей. Таким образом, пользовательская программа может вызвать некоторую API-функцию для проверки наличия донгла, запросить целостность лицензионной информации через другую API-функцию и т.д. и т.п. Для доступа ко всем этим функциям, т.е. для подключения к API, Reinbow предлагает два-три способа:

1. прямое использование lsapiw32.dll (распространяется вместе с дистрибутивом);

2. статическая линковка lsapiw32.lib (lsapiw32.dll НЕ фигурирует в дистрибутиве);

3. нездоровые комбинации из 1 и 2.

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

Анализируем дистрибутив нашей жертвы на предмет наличия lsapiw32 или подобной DLL. Нашли? Если да, то грузите её в IDA. В противном случае имеет смысл предположить, что lsapiw32 статически прилинкована к главному исполнимому модулю программы. Как бы то ни было, наложение сигнатуры W32MCST1 (sentinel static lib) в IDE должно обнаружить БОЛЬШОЕ количество сентинельных функций. Если не обнаружит, попробуйте загрузить другой модуль и т.д. Терпение постепенно превращается в опыт.

Далее, жмите на Ctrl+L и удивляйтесь: зачем SLM столько вспомогательных функций? Попытаемся угадать функцию, возвращающую VId. Первый, но не единственный, кандидат -- _computeVendorCode. Далее приводится примерное содержание функции:

Обратите внимание на то, что _computeVendorCode является враппером к _DencVendId, которая, в свою очередь, вызывает _VLM_deMorphId. Особого внимания заслуживают и строковые константы, так? ;-)

Пора перейти к софтайсу... Создаём MAP-файл (если хотите, можете убрать все символы кроме _computeVendorCode или _DencVendId). Ищем утилиту msym.exe в softice_path/util16 и перегоняем наш MAP в SYM ("MSYM file.MAP"). Полученный SYM транслируем в NMS с помощью nmsym.exe в softice_path/ ("NMSYM file.sym") и загружаем в Symbol Loader ("NMSYM /SYM:file.NMS"). Далее, если _computeVendorCode находится в DLL, загружаем её в Symbol Loader ("Open module...") и смело жмём на "Load". Потом заходим в SoftIce (Ctrl+D) и ставим бряк на _computeVendorCode (bpx _computeVendorCode). Запускаем наше подопытное приложение (*.EXE) обычным способом и терпеливо ждём появления дружелюбного отладчика. Дождались? F12 и записываем содержимое EAX на бумажку!!!

А что если _computeVendorCode находится в EXE? Тогда чуть сложнее... После загрузки NMS, грузим *.EXE через Symbol Loader (!) и жмём на "Load". При появлении окна отладчика клацаем по F8 для попадания в код приложения. Задаём команду TASK и находим имя нашего подопытного процесса. Передаём полученное имя в качестве параметра команде MAP32 (вроде "MAP32 myprog") и смотрим на поля "Obj Name" и "Address". Например:

С полученными данными можете приступать к релокации символов NMS:

'1' в SYMLOC обозначает порядковый номер сегмента кода в MAP-файле. "1AF 401000" соответствует адресу "01AF:00401000". В данном случае, имеется ввиду именно сегмент CODE (aka .text), так-как в коде находится _computeVendorCode (не среди данных или ресурсов). Команда SYM показывает местоположение нашей функции, тем самым подтверждая успешную релокацию символов. Далее, ставим бряк на _computeVendorCode и закрываем окно отладчика. При повторном появлении оного жмём на F12 и записываем VId.

Как и прежде, жду ваши комментарии. До следующей главы. Отдыхайте.

Примечание

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

1. Инсталлятор разжимает библиотеку MODBIN.DLL

2. Введённый серийник передаётся функции MODBIN!GetVendorId (не смейтесь :-)

3. Функция возвращает VId соответствующий серийнику или -1, если таковой не найден.

Мммда... таким образом VId косвенно передаётся инсталлеру. Значит, если хотите играть по правилам, тогда соизвольте подобрать серийник для нашего VId. В противном случае можете попробовать обойти стадию с MODBIN и насильно запихнуть VId прямо в SDK. Я, честно говоря, такого делать не пробовал и вам не советую! Итак, приступим к написанию ключегенератора для SentinelLM SDK 7.1.

Внимание! Не спешите компилировать прилагаемые исходники, сначала дочитайте главу!

Во-первых, покопайтесь над установщиком и вытяните из него MODBIN.DLL. При желании можете дизассемблировать библиотеку и постараться понять принцип хеширования (серийник -> VId). Таким образом вы убедитесь в сложности построения обратной функции (VId -> серийник). Гораздо проще обойтись прямым перебором всех возможных комбинаций до получения искомого VId. На самом деле время перебора не так уж и велико (1,5 - 2 часа на среднестатистическом компе), но я предлагаю несколько иной подход, а именно: сгенерировать файл со всеми ВАЛИДНЫМИ парами (VId, серийник) для использования в ключегенераторе в качестве словаря. Размер такого файла, в зависимости от формата, может составить около 382Кб. Далее приводится исходник первой стадии генератора:

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

Ну всё, компилируем вместе с RC-скриптом и наш новый генератор серийных номеров для SentinelLM SDK готов к употреблению!

Попробуйте задать ему 2A0A (это последний VId в нашем словаре) и получите целых ДВА результата (8561314 и 8430250). Почему два? Видимо SDK разделяет все VId на две категории:

1. [0000 - 7FFF] для обычных клиентов

2. [8000 - FFFF] для крутых разработчиков (вроде нас с вами)

Первый серийник соответсвует обычному VId (2A0A) а второй наделяет SDK дополнительными фичами. Так как большинству клиентским программам (например, нашей жертве) совершенно безразличен MSB (старший бит) её VId, вам будет всё равно какой из этих серийников использовать. Кстати, иногда может быть вплоть до восьми серийных номеров на один VId (больше восьми я ещё не встречал).

Далее, просто ставим SDK и проверяем, что VId соответствует нами заданному. Только не спрашивайте: "А как это проверить?" Медитируйте над первой главой. Обратите внимание на то, что SDK отказывается на нас работать... Не переживайте -- в следующей главе мы его уломаем :-)

Пока я усердно работал над этой главой, вы уже прочитали объёмные PDF'ы из документации и узнали, что генератор лицензий SLM (он же WlscGen.exe) так просто нас не наградит халявными лицензиями для нашей жертвы. Оказывается, что он сам защищён SLM и требует наличия донгла! Смешно и обидно... Но не отчаивайтесь -- сегодняшний практикум многому вас научит и поможет устранить защиту SLM даже в патологически сложных случаях, в которых кроме ратификации лицензионного файла программа активно использует EEPROM-память донгла. У меня даже есть готовый патч для "исправления" WlscGen, но я настаиваю на необходимости хотя бы один раз поработать над этим вручную. Чем не ритуал посвящения в Sentinel? :-)

Кроме двух PDF'ов, входящих в комплект поставки SDK, вам нужно прочитать ещё один ОЧЕНЬ важный документ: "SentinelSuperPro 6.0 Developers Guide" (6,4 Мб), который можно скачать на сайте www.rainbow.com. Документ посвящён API Sentinel SuperPro, с помощью которой SLM "общается" с донглами семейства SuperPro. Особого внимания заслуживает глава 14: "API Function Reference".

Перед штурмом WlscGen, хочу добавить пару слов о принципе работы этой программы (особенно для тех лентяев, которые -- как и я в своё время -- не прочитали документацию ;-) Маркетинговая политика радужной компании основана вовсе не на продаже CD с SentinelLM SDK в красивых упаковках. Эти капиталисты взимают дань со своих клиентов за КАЖДУЮ выпущенную лицензию. Справедливости ради стоит заметить, что многие другие компании тоже так поступают... В общем, вместе с SDK компания выдаёт (вроде, первый раз бесплатно) своеобразный электронный счётчик, который автодекрементируется при каждом употреблении. При создании постоянных лицензий для одного PC, счётчик уменьшается на определённое количество единиц; при выпуске корпоративных лицензий для нескольких PC -- теряется соответственно большее количество единиц. Всё зависит от типа лицензии, срока годности и т.д. Эти единицы теряются безвозвратно, даже если пользователь по ошибке создаст бракованную лицензию. При полном истощении счётчика, приходится идти к Rainbow и покупать новый. Вам это не напоминает картриджи для принтеров HP? Так вот, счётчик этот реализован в виде нескольких ячеек памяти в ранее упомянутом донгле и WlscGen "видит" эти ячейки через API, которая общается с донглом через драйвер.

На следующем изображении упрощённо показана зависимость WlscGen от донгла. На большее у нас с Paint'ом не хватило воображения :-)

Обратите внимание на ячейку "Vendor Id" (или "Developer Id") -- это тот самый VId!!! Таким образом, каждый лицензионный донгл "привязан" к своему хозяину и отказывается работать на "чужих" владельцев. Так, по крайней мере, считают в Rainbow. Ячейка "Уникальный S/N" -- это вовсе не то, о чём вы сразу подумали. Нам данный S/N абсолютно безразличен (не путать с серийником для SDK). Область "N/A" не доступна приложениям и, в основном, представляет собой зарезервированные ячейки. В области "Произвольные данные" находится, например, вышеупомянутый счётчик.

SLM API в данном случае реализована статически, т.е. нужные функции внедрены в WlscGen.exe. Наличие lsapiw32.dll не должно сбивать вас с толку. Наша задача -- пропатчить генератор лицензий, вернее пропатчить SLM API для того, чтобы генератор "видел" несуществующий донгл и признавал его своим. Потом мы "заполним" счётчик и получим неистощимый запас лицензий на зависть всем клиентам Rainbow!

Единственный известный мне рабочий метод взлома WlscGen -- это метод описанный в статье CyberHeg "Removing need for dongle in Sentinel LM Wlscgen". Вообще, SentinelLM!WlscGen_CRK_1 можно считать частичным переводом статьи CyberHeg.

Итак, запускаем WlscGen.exe и убеждаемся в его неработоспособности без донгла. Я настоятельно рекомендую вам сделать паузу в чтении этой статьи и помедитировать над кодом программы как в IDA (не забудьте наложить сигнатуру статической SLM API), так и под софтайсом. Можете запомнить текст сообщения об ошибке и попытаться оттрассировать его под отладчиком. Попробуйте угадать какие функции из SLM API могут/должны вызываться для обнаружения донгла.

Сдаётесь? Так быстро? Ладно... в IDA > Names ищем те самые функции из "SentinelSuperPro 6.0 Developer's Guide". При помощи дизассемблера, отладчика и хекс-редактора мы постепенно заставим некоторые из этих функций работать с несуществующим донглом :-) По мере необходимости мы будем заглядывать в SoftIce (как обычно, MAP > SYM > NMS и т.д.)

RNBOsproFindFirstUnit(packet, VendorID)

Первым делом ставим BPX на RNBOsproFindFirstUnit(), так-как эта функция предназначена для поиска донгла с заданным VId. Для большей уверенности можете поставить бряк сразу на все 16 функций из этой API. Наше предположение оказывается верным и SoftIce выскакивает на входе в RNBOsproFindFirstUnit(). Трассируем до RETN и получаем 3 в аккумуляторе (EAX = 3), что означает отсутствие донгла и объясняет сообщение об ошибке. Не теряя времени, идём в IDA и правим это безобразие:

При успешном выполнении RNBOsproFindFirstUnit возвращает SP_SUCCESS, т.е. ноль. Блиц-патч:

Элементарно, не правда ли? Вместо исправления кода внутри функции RNBOsproFindFirstUnit можно поправить условные переходы после каждого её вызова, но гораздо проще и быстрее поступить вышеописанным образом. По ходу дела, не забывайте осуществлять изменения в самом файле WlscGen.exe при помощи HIEW, WinHex или подобной утилиты.

После успешного "обнаружения" донгла с помощью RNBOsproFindFirstUnit, WlscGen пытается прочитать 16-битные ячейки донгловой памяти через RNBOsproRead. Второй параметр функции задаёт относительное местоположение запрашиваемой ячейки. Полученное значение возвращается через указатель в третьем параметре. Так-как данная функция возвращает принципиально различные значения через указатель, нам её так просто не пропатчить. Опираясь на статьи Goatass и CrackZ, CyberHeg предложил внедрить в конец RNBOsproRead массив из 128 байт для эмуляции памяти донгла. Естественно, код самой функции нужно исправить и заменить вызов драйвера донгла на чтение локального, так сказать, массива. "Правильные" значения ячеек в данном массиве определяются путём долгих мучений с отладчиком. В большинстве случаев, WlscGen проверяет значение считанной ячейки вскоре после возврата из RNBOsproRead и вы можете его перехватить и добавить в массив. Правда, иногда проверка значений происходит иным, менее элементарным образом. Далее представлен исправленный вариант RNBOsproRead:

Обратите внимание на 4 ячейки с 0FFFFh и одну с 0700h. Эти значения были получены путём трассирования каждого вызова RNBOsproRead.

Если снова запустить WlscGen, программа должна заметно тормознуть (!) и показать окно с приглашением "Please Login". Эта задержка при запуске служит явным признаком того, что нам ещё рано праздновать. Действительно, пора заняться RNBOsproQuery, RNBOsproFindNextUnit и RNBOsproDecrement. Хотя, стоп!!! Я по себе чувствую, что вы подустали :-) Поэтому оставим эти три API для следующей главы. Я вам даже больше скажу: с RNBOsproFindNextUnit и RNBOsproDecrement вы должны быть в состоянии разобраться сами! Это будет своеобразным домашним заданием :-) Отдыхайте.

Решено было разбить эту статью на две-три части. Первая часть собственно теоретическая. Она дает абсолютно необходимый минимум теории, который позволит успешно распаковывать файлы. В статье также описывается формат XML, который затем переводится в CSS-HTML при помощи XSLT-процессора. Таким образом, наряду со знанием структуры PE-файла вы, по прочтении статьи, будете иметь самые базовые представления о XML/CSS/XSLT, Perl/Java и других страшных технологиях. Мы достаточно неплохо осознем, что тема уже достаточно замусолена, поэтому нудного пересказа PE-документации здесь не будет. Скорее, вам стоит воспринимать эту статью как некий коллектор, попытку обобщения и анализа всей доступной информации о пакерах, PE-файлах, антиотладке и т.п. А поскольку есть возможность перевода статей с испанского и французского языков (помимо стандартного английского), то должно получится что-то неплохое. Вторая часть будет чисто практической. Мы рассмотрим UPX, Aspack, Asprotect, Crunch, Armadillo и вскользь упомянем о других, менее популярных пакерах. Все опыты, приведенные в первой части проводились на calc.exe – стандартном калькуляторе из поставки Windows 2000. Вторая часть тоже будет проходить вместе с calc.exe. Реальные случаи будете рассматривать сами. Последнее, но немаловажное замечание – ВСЕ, что здесь обсуждается, валидно ТОЛЬКО для Windows 2k/XP/2003 (последняя – с натяжкой!). 9x НЕ рассматривается как анахронизм. Замечание важно, т.к. 9x и NT по-разному трактуют оперативную память, загружают библиотеки, работают с процессами, обрабатывают исключения и т.п.

Для того чтобы понимать, что здесь написано, введем пару допущений. Допущение номер раз: вы знаете ассемблер; №2: вы знаете, что такое исполняемый файл, т.е. файл загружается с диска в оперативную память с помощью механизмов ОС, при этом ОС определенным образом может при загрузке корректировать информацию внутри файла, если это необходимо; №3: вы слышали о языке программирования Perl; №4 – вы имеете очень приличное представление о базовых типах языка С – структурах, массивах и т.п., последнее – пятое – вы имеете хоть и очень смутное, но все же какое-то представление о том, что такое PE-формат исполняемого файла.

Теперь, наконец, давайте рассмотрим формат PE -файла. Скажем сразу, что в наши намерения не входило давать здесь пересказ технической документации MS. Файл со спецификациями PE/COFF при-ложен, на wheaty.net есть статьи Питрека на эту тему. Полагаем, в русской части Интернета сравнительно просто найти саму книгу Питрека. Из русской литературы можно предложить Румянцева, где неплохо описаны поля, и даже есть исходники, хотя их качество нам не нравится, и статью о загрузчике PE -файлов на RSDN.ru – там все расписано очень неплохо, есть и исходники, но они на Delphi, а этот язык мы не знаем и не любим. Однако алгоритм, по справедливому замечанию автора, везде одинаков.

Да, чуть не забыли. Для хорошо знающих английский, есть абсолютно великолепная вещь, совершенно свободно распространяемая - http://www.iecc.com/linker/ - слейте ее целиком, и обязательно прочтите, просто изумительно! Книга будет продублирована и на WASM.RU, ибо вполне стоит того! Практическим примером к этой книге может служить техническая документация с сайта http://www.cs.virginia.edu/~lcc-win32/ - Якоб Навия очень неплохо расписывает многие тонкости по созданию компилятора и линкера. Еще дополнительно прилагается англоязычное описание PE -формата (версия 1.7) от Lumnificer , где подробно расписываются все поля, и даже объясняется, как создавать PE -файл ручками, т.е. расписывается работа примитивного линкера!

Так же, посоветуем изучить исходный код программы Wine – эмулятора Windows для Linux. Wine умеет загружать pe -файлы под Linux , причем код pe_image.c написан очень развернуто. А там еще мно-о-го примеров есть… Сайт - http://www.winehq.com.

Теперь очень быстренько пробежимся по списку литературы, описывающего работу NTDLL.dll – Windows loader'а.

Нашими маяками в этом бушующем море станут статьи Питрека.

А также, основанная на этом статья Russell Osterlund с сайта http://www.smidgeonsoft.com, название статьи – "Windows 2000 Loader: What Happens Inside Windows 2000: Solving the Mysteries of the Loader " – лежит на MSDN. Лучше пока еще ничего не написано. Примеры для статьи скачивайте только с MS , родной сайт лучше не трогать. Причем после слива можно смело удалить все dsp/dsw/ncb/suo/sln файлы, оставив только vcproj. Причина в том, что все файлы проектов повреждены, во всяком случае, VS.NET 2003 их открыть не смогла. Другое дело vcproj , который, по сути, является простым xml -файлом. Подредактируйте их немного (неправильно прописаны пути Output Directory и т.п.), и держите в уме, что проект Forwarder требует lib -файл проекта Forwarded , поэтому второй должен собираться раньше.

Во всей остальной части статьи мы будем жестко придерживаться терминов, принятых Microsoft. Все определения структур взяты из winnt.h. Эта мера кажется очень разумной, т.к. на данный момент существует дикая неразбериха в терминах - существует целая куча слов, для которых нет четких определений, например, секция импорта, таблица импорта, IAT и т.п. Каждый писатель под этими словами понимает что-то свое, в результате чего имеем полный беспредел.

Теперь взгляните на рисунок ниже:

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

Единственное что, стоит объяснить несколько нюансов.

RVA переводится как Relative Virtual Address - относительный виртуальный адрес. Его относительность заключается в том, что он отсчитывается от адреса загрузки, который может быть, а может и не быть, равен ImageBase.

Обязательно учтите, что RVA имеет РАЗНЫЙ смысл для бинарных файлов (exe, dll, sys) и объектных файлов (obj , lib). Вторые мы здесь не рассматриваем, а для первых – файл загружается в память и RVA какого-либо элемента вычисляется так:

где VA (Virtual Address) – виртуальный адрес элемента в памяти, а адрес загрузки берется из поля Op-tionalHeader.ImageBase, в том случае, если он равен ImageBase, либо вычисляется лоадером.

Обратите внимание на то, что элементарные просмотрщики файла, например, QVIEW/WinHEX и т.п. отображают абсолютные offset-ы, HIEW способен переключаться (Alt+F1) между показом VA и внутрифайловых смещений (local/global mode), а IDA вообще частично эмулирует работу ntdll.dll – Windows-loader'a, поэтому показывает только VA (если вы не укажете иное, например, загрузив файл как "binary").

Давайте рассмотрим пример для практического усвоения материала. Точка входа calc.exe (также часто называемая EP – entry point) выглядит так:

А в виде абсолютных внутрифайловых смещений – вот так:

Давайте попытаемся разобраться, какой же механизм пересчета VA во внутрифайловые смещения.

Алгоритм примерно выглядит так:

1) По VA рассчитать RVA

2) Для RVA найти секцию, в которой мы находимся (о секциях мы поговорим чуть ниже).

3) Пересчитать RVA во внутрифайловый offset по формуле:

Теперь давайте посчитаем ручками. В качестве примера возьмем адрес точки входа calc.exe - 0x01012420.

Сразу смотрим в HIEW на значение ImageBase -

Теперь определяемся, где же у нас лежит этот RVA. Ага, RVA лежит в секции .text. Обратите вни-мание на то, что лежит он ближе к концу секции:

Number — Name — VirtSize — RVA — PhysSize — Offset — Flag

1 — .text — 000124EE — 00001000 — 00012600 — 00000600 — 60000020

Теперь VA во внутрифайловое смещение:

Заметим, что процесс этот уже давным-давно автоматизирован. Есть такие утилиты как LordPE и PE Tools , а в них есть такая вещь как FLC (File Location Calculator), который по данному VA отобразит RVA и внутрифайловый offset.

Имея на руках некоторые API -функции - GetModuleHandle , ImageRvaToVa и ImageRvaToSection , несложно написать программу, которая быстренько переведет любой VA во внутрифайловый оффсет. Например, аналог функции от MS ImageRvaToSection может выглядеть где-то так:

Примеры функций RtlImageRvaToVa /RtlImageRvaToSection /RtlImageDirectoryEntryToData есть в файле loader.c из wine.

Например, есть у вас есть dll , загруженная по адресу, отличному от ImageBase. Вы нашли защиту в Soft-Ice , и хотите пропатчить это место HIEW'вом - тут-то и пригодится умение.

PE-файлы были спроектированы для работы в ОС со страничной адресацией памяти. Известно, что Windows делит память на страницы различного размера, поэтому и PE-файл разбит на секции. Это очень важно понимать, поскольку секции PE-файла в памяти и на диске - это вовсе не одно и то же! В том случае, если сами данные в секции имеют общий объем менее размера кластера - секция на диске выравнивается (т.е., дополняется нулями, int3 - CCh или nop – 90h) под размер кластера (не путать с сек-тором – кластеры состоят из многих секторов диска!), который обычно равен 512 байтам (или другое значение – поле OptionalHeader.FileAlignment).

Когда файл загружается, то секция попадает в страницу памяти большего размера – 4 кб (или дру-гое значение - OptionalHeader.SectionAlignment), и выравнивается вновь, если это необходимо, уже только нулями. Обратите вниманиме, мы говорим "секция" – т.е., секция .text , CODE , .data , DATA , .aspack или что-либо еще. Каждая секция будет проецироваться на одну или несколько страниц памяти.

Не путайте понятие "Секция " (section) и "Директория " (directory). Директории (импорта, экспорта, ресурсов, исключений или чего-то еще) находятся ВНУТРИ секций. Заметьте, секция определяет разбиение PE -файла на части, но секции глубоко все равно, какой тип данных будет находится внутри нее. Для того, чтобы охарактеризовать тип, у нас есть директории! Директории характеризуют данные, содержащиеся в PE , по их типу и функциональности. Таким образом, можно говорить, что секция является физическим разбиением PE файла на состовляющие, а директория - логическим.

Иногда размер секции может занимать много кластеров, и отображаться Windows на несколько страниц памяти. Общее количество секций должно в точности соответствовать полю FileHeader.NumberOfSections. Теоретически, с этим шутить не стоит, так как шаг в сторону – стреляю. Такой файл не будет опознан ntdll.dll , поэтому на поле NumberOfSections можно смело(?) опираться. Однако и здесь нам уже радость испортили! Некоторые крипторы, например, telock , заменяют это значение в ПАМЯТИ , например, на 0xFFA4. Угадайте, что случится, когда вы попытаетесь запустить дамп с такого файла? А что будет, если утилита, просматривающая содержимое полей секций в цикле, будет ориентироваться на такую переменную как на счетчик цикла, нечто вроде такого:

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

LordPE , HIEW на этот трюк покупаются! Все версии IDA - тоже! PE Tools – нет! Прекрасная защита от сброса дампа на диск (имеется в виду, дамп сбросить можно, а вот заставить его заработать потом.... тоже можно, но чуть посложнее)! Хотя, с другой стороны, такой файл не будет загружен самой Windows. Цитирую Евгения Сусликова: "не должно быть хиеву умнее виндов ". Что ж, вполне справедливо.

Для каждой секции в заголовке PE-файла указан ее размер на диске и в памяти. Структура выглядит так:

Особый интерес в этой структуре вызывают два поля – VirtualAddress и SizeOfRawData. Все остальные тоже очень интересны, но эти два широко используются протекторами для сокрытия от наших глаз того, что должно быть скрыто. К примеру, вам, вероятно, часто доводилось видеть нечто вроде такого в IDA :

в то время как самый обычный hex-редактор выдавал вполне осмысленные цифры. Проблема и ее решение достаточно просты. Обратите пристальное внимание на поля VirtualSize и SizeOfRawData той секции, где есть такой подарочек. Значение SizeOfRawData должно быть меньше значения поля VirtualSize :

Number — Name — VirtSize — RVA — PhysSize — Offset — Flag

1 — .text — 00195C5C — 00001000 — 00000000 — 00000000 — 60000020

2 — .data — 00008DD4 — 00197000 — 00000000 — 00000000 — C0000040

3 — .text1 — 00010000 — 001A0000 — 0000F000 — 00001000 — 60000020

4 — .data1 — 00020000 — 001B0000 — 00007000 — 00010000 — C0000040

5 — .pdata — 000B0000 — 001D0000 — 000B0000 — 00017000 — C0000040

6 — .rsrc — 00001000 — 00280000 — 00001000 — 000C7000 — 40000040

Именно поэтому и появляются знаки вопроса – IDA ориентируется только на raw-байты (хотя, в случае секции кода с этим можно поспорить). Чтобы исправить положение, надо просто приравнять значение SizeOfRawData значению VirtualSize. И, вуаля:

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

Возможен и еще, например, такого рода трюк. Положим, есть файл, у которого ручками создана несуществующая директория отладки (Debug Directory):

Структура директории выглядит так:

Положим, мы задали заведомо огромные значения полей SizeOfData , AddressOfRawData и PointerToRawData. Лоадера эти поля абсолютно не интересуют (ему важна лишь валидность параметров в IMAGE_DATA_DIRECTORY). Прямо сказано, что эти поля касаются только отладчика (или дизассемблера). Так вот, IDA на таком файле (до версии 4.3 включительно) слетит наглухо! Такого рода трюк (© Dr. Golova) был применен в программе, которую рассматривал Sten в своей статье – "Исследование подаруночка " на reversing.net, если кто помнит.

Популярны также трюки с директориями импорта-экспорта. Некоторые поля (OriginalFirstThunk , например) забивают 0xFFFFFFFF или чем-нибудь не менее гадким - RVA OriginalFirstThunk должно, согласно действиям лоадера (Win2k SP4), укладываться в диапазон

если это не так – файл загружен не будет. В этих случаях IDA говорит "Can't find a translation for virtual address… ", и … раньше слетала, а теперь продолжает работу. HIEW в своей работе на winnt.h не опирается вообще, он был создан раньше. Валидность адресов директории импорта/экспорта проверяется валидностью VA. Мы поговорим о подобных приемах немного позднее.

Флаги секции – тоже вещь небезынтересная! Здесь мы не будем углубляться в детали. Скажем лишь, что флаги секции могут преобразовываться лоадером в атрибуты страниц и сегментов, биты CR-регистров и т.д. Это достаточно сложная тема, требующая неплохого понимания принципов работы защищенного режима. Мы бы порекомендовали Рендалла Хайда "Art of Assembly " и Михаила Гука. Заодно можно почитать Фроловых, а также ознакомится со статьями Broken Sword на WASM.RU. После этого можно смело утверждать, что вы будете является одним из очень твердых специалистов по защищенному режиму процессоров х86 :). Такое знание не будет бесполезным. Например, понимание принципов защиты страниц виртуальной памяти помогает практически однозначно идентифицировать Aspack. Сбросьте флаг разрешения записи у секции кода в программе, предположительно запакованной Aspack , и взгляните на результаты. Почему такое происходит – мы поясним во второй части. Обязательно обратите внимание - это поле НИКОГДА не должно быть равным нулю. Как это можно использовать - см. ниже.

Сейчас уместным было бы посоветовать на какое-то время отвлечься от статьи, и попробовать поэкспериментировать с секциями файла. Да, мы сделаем это немного позднее, во второй и третьей частях, когда будем чистить файл от мусора, оставленного крипторами, однако, то, что сделано собственными руками, едва ли когда-нибудь забудется. Например, попробуйте поставить поле VirtualSize какой-нибудь секции в ноль (как, например, это делает линкер от Watcom). Также учтите, что количество страниц в памяти не обязательно будет соответствовать количеству секций в PE -файле. Во-первых, размер, во-вторых – сама Windows просто не загрузит страницу памяти до тех пор, пока она не нужна. Только если страница нужна, тогда она будет подгружена.

Еще нюанс. Все упаковщики, пакеры и крипторы очень нежно относятся к секции .rsrc. Секция кода, директрия импорта – все это безжалостно калечится, однако секцию ресурсов трогать боятся. При-чина проста. В исходном коде UPX можно найти следующие комментарии:

И действительно. В файле oleaut32.dll можно найти следующие строки, сохранившиеся там со времен 95-го по 2k и выше:

И из-за откровенно неумного, недальновидного, …, не будем перечислять, поведения программиста, кракеры получили большой подарок, а авторы пакеров – подарок поменьше. Спасибо, Microsoft! И абсолютно без всякой иронии! Так что, если автор хочет, чтобы его файл имел красивую иконку, то он должен предоставить ресурсы файла в наглядном виде. Конечно, не все так просто, секция ресурсов то-же безжалостно калечится, однако, вероятность того, что название секции будет сохранено наряду с иконкой, очень велика. Что до остального.… Разберемся с этим чуточку попозже.

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

В заключение, рассмотрим алгоритм подсчета количества секций PE-файла. Как уже упоминалось, поле FileHeader.NumberOfSections не может служить достаточно надежным проводником. Тогда что? Пока мы используем этот алгоритм (к слову, тоже ненадежный), но, возможно, после выхода статьи, он уже не будет работать в силу вполне определенных причин. Тогда нам с вами останется последний верный и надежный способ – считать значение из файла диске. Многие утилиты это позволяют. Итак, производим подсчет секций, и смотрим на поля PointerToRelocations , PointerToLinenumbers , NumberOfRelocations , NumberOfLinenumbers. Если все эти поля равны нулю, а поле Characteristics - НЕТ , значит - это секция.

Алгоритм прост:

Уже упоминалось, что линкер Watcom устанавливает значение поля VirtualSize в нуль. Тогда возникает вопрос - откуда брать VirualSize? Рекомендуется использовать значение поля SizeOfRawData , выровненное по SectionAlignment. Ниже указан макрос на C++ для выравнивания секции по SectionAlignment :

Используется так: VirtualSize = RALIGN(VirtualSize , SectionAlignment);

Eще немного об ImageBase. Понятия « директория кода » не существует. Есть только секция кода , которая может называться, как душе угодно. Начало секции вычисляется из IMAGE_OPTIONAL_HEADER.BaseOfCode. В случае, если значение поля AddressOfEntryPoint не укладывается в диапазон,

то это внимательному человеку может говорить о многом. Во-первых, файл, вероятно, запакован (почему так – см. часть вторую). Во-вторых, теперь вам придется сушить мозги с его распаковкой. Некоторые утилиты, например, OllyDbg , это дело подмечают, о чем вежливо предупреждают. Мало ли что?

Теперь перейдем к директории импорта.

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

Однако перед тем как перейти к прикладным аспектам, давайте немного разберемся с путаницей в терминологии. Прежде всего, массив из структур IMAGE_IMPORT_DESCRIPTOR иначе как директорией импорта называть некорректно. Структура эта содержит ряд полей, среди которых есть OriginalFirstThunk и FirstThunk. Очень важно понимать состояние структур, на которые эти поля показывают. Структуры называются IMAGE_THUNK_DATA – их две!

До загрузки образа в память OriginalFirstThunk и FirstThunk содержат RVA (которые, естественно, тоже различаются) на эти структуры, являющиеся ни чем иным, как таблицами адресов импорта (IAT – import address table). Но и здесь уже тоже наизобретали велосипедов! IMAGE_THUNK_DATA на которую указывает OriginalFirstThunk ntdll.dll при загрузке в нормальных условиях не обрабатывается (хотя внутренняя функция ntdll.dll LdrpSnapIAT может читать и оттуда, см. ниже), а адреса в структуре, на которую указывает FirstThunk действительно меняются (патчатся лоадером), поэтому OriginalFirstThunk называют еще import lookup table (import name table), а FirstThunk – вот это уже настоящая IAT , для которой есть свой #define :

Была когда-то и СЕКЦИЯ импорта, звали .idata , но сейчас она, пожалуй, издохла. Во всяком случае, сейчас этот зверь – редкий. Разве что линкер специально попросите...

Забавно, что даже LordPE , написанный действительно талантливым программистом, и тот не избежал этого бага. Поглядите потом, что вытворяет! Кнопочка – Directories , а директорию импорта называет IAT , а offset вообще обалденный выдает! PETools зато отображает корректно и термины корректные.

Теперь рассмотрим саму структуру и манипуляции с полями. Итак:

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

NTDLL.dll (функция LdrpWalkImportDescriptor) может читать IAT из:

Есть и 4-й #define :

NTDLL.dll это не патчит, т.к. здесь уже используется совсем другой механизм. Фактически, это аналог LoadLibrary /GetProcAddress в одной упаковке. Более подробно - как всегда, Мэтт Питрек.

Здесь тоже понаворочено более, чем достаточно. Внутри Delay Load Directory Table есть стандартная таблица импорта, может выполняться привязка, т.е. возникать Bound Delay Import Table , есть Unload Delay Import Table и т.п. Мало не покажется!

LordPE понимает, что такое директория отложенного импорта. PE Tools пока выдает только VirtualAddress и Size (т.е. стандартные описания директории), HIEW (включая 6.85) вообще не умеет работать с директориями, IDA , хм.., IDA знает все.

Теперь у лоадера есть выбор – из какого же поля, собственно читать? Сначала обрабатывается цепочка директорий. Функция LdrpWalkImportDescriptor обрабатывает ТОЛЬКО директорию привязанного импорта, если VirtualAddress директории IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT не равен нулю, и временные пометки (TimeDateStamp), зашитые внутри модуля при его создании, соответствуют таковым в библиотеках, к которым этот модуль привязан (системные библиотеки Windows , dll приложения и т.п.).

В случае отсутствия IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (или невыполнения некоторых условий, например, загрузки экспортируемого модуля не по адресу ImageBase) читается уже стандартный IMAGE_IMPORT_DESCRIPTOR.

Так же уже не вполне ясна роль поля IMAGE_IMPORT_DESCRIPTOR.TimeDateStamp , которое может иметь три значения:

1. 0 – стандартный IMAGE_DIRECTORY_ENTRY_IMPORT.

2. ххххххххh – из IMAGE_IMPORT_DESCRIPTOR. FirstThunk , но с некоторыми оговорками, см. ниже.

3. -1 – лоадер читает из IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT. Как уже говорилось, в этом случае лоадеру совершенно безразлично (при соблюдении определенных условий), есть ли IMAGE_DIRECTORY_ENTRY_IMPORT вообще или нет! Если попытка чтения BOUND_IMPORT проваливается в силу, например, несовпадения TimeDateStamp у exe файла и dll , к которым он привязан, то тогда читается стандартная IMAGE_DIRECTORY_ENTRY_IMPORT , но как при этом обрабатывается –1 – неясно. Во всяком случае, в коде LdrpWalkImportDescriptor НЕТ сравнения TimeDateStamp с -1, поэтому можно предположить, что достаточно существования IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT.

Теперь продолжим исследование. Начнем с поля Name. Это RVA на ASCIIZ -строку нужной библиотеки. Совершенно неоправданно на нее опираются во многих алгоритмах, где массив из структур IMAGE_IMPORT_DESCRIPTOR обрабатывается в цикле. С одной стороны да, если имя библиотеки не указано, то откуда изволите функцию импортировать, а с другой стороны – есть поле TimeDateStamp , которое может быть равно –1 , точнее, есть директория BIAT (есть и такое название у директории привязанного импорта), и, если она присутствует, о старой директории импорта можно забыть! И можно вытворять, что душе угодно с массивом из IMAGE_IMPORT_DESCRIPTOR , лоадера это нисколько не волнует! Т.е. утилита, обрабатывающая такой файл, это дело должна учитывать, т.е. частично эмулировать работу лоадера. PE Tools это умеет. LordPE - тоже.

При TimeDateStamp == 0 мы имеем дело со старой доброй стандартной IAT. До загрузки OriginalFirstThunk и FirstThunk имеют одинаковую структуру (IMAGE_THUNK_DATA), которая физически продублирована в разных местах РЕ -файла. После загрузки FirstThunk содержит реальные адреса функций, OriginalFirstThunk остается такой же. Лоадер патчит адреса в FirstThunk , меняя атрибуты страницы на время выполнения этой операции.

При TimeDateStamp равном ххххххххh имеем интересный случай со «старой привязкой». Важно понимать, что в этом случае лоадер не делает ничего! Пара проверок на валидность и образ можно запускать! Добиться эффекта можно, запустив утилиту bind с ключом –o.

Поле OriginalFirstThunk не затрагивается, а поле FirstThunk содержит настоящие адреса API -функций. Т.е. IMAGE_IMPORT_BY_NAME смысла более не имеет, т.к. DWORD в IMAGE_THUNK_DATA теперь, по сути, представляет адрес API -функции в памяти, а не ссылку на IMAGE_IMPORT_BY_NAME.

Импорт может просто привязываться, а может и происходить так называемый “ API forwarding ”, что можно перевести как "перенаправление API". Это очень изящная штука, которая помогает MS скрывать разницу между OS. Классический пример с HeapAlloc. Определена в kernel32.dll , но в действительности КОДА ее там и близко нет! Вместо этого вызов сразу перенаправляется на ntdll.dll , где упирается в функцию RtlAllocateHeap! Т.е. где-то так:

calc.exe - > — kernel32.dll -> — ntdll.dll

(call HeapAlloc) — (немедленный форвард) — (RtlAllocateHeap)

(NTDLL.RtlAllocateHeap)

Этого эффекта можно добиться, употребляя следующее выражение при компиляции dll:

Аналогичного эффекта можно добиться и с помощью def -файла:

Exe -файл, использующий dll c таким редиректом, должен загружать ее динамически – через LoadLibrary /GetProcAddress(“ HeapAlloc ”) - если импорт по имени, либо по ординалу с помощью макроса MAKEINTRESOURCE. Если хотите линковать статически - тоже нет проблем. Код dll :

def -файл для dll (можно обойтись и без него, если использовать директиву pragma):

И, наконец, код exe , который будет использовать такую хитрую dll :

Обратите внимание, в самой dll нет и следа кода форварда, это не является необходимым. Директива Hi = User32.MessageBoxA @2 NONAME предписывает компилятору перенаправить вызов Hi , присвоить этой функции ординал номер два, и сделать так, чтобы в результирующей dll имени функции НЕ было (заметьте, имя функции сохранится в lib, но не будет существовать в dll). В exe файле две директивы extern "C" и __stdcall помогут нам избежать проблем с манглингом функций.

Файл с API-forwarding будет иметь таблицу экспорта с функцией, имеющей нестандартный RVA , значение которого не будет укладываться в лимит размера директории. Алгоритм обработки таких форвардов заложен в функцию LdrpSnapIAT и, как нам кажется, Russell в своей статье здесь допустил ошибку. Смотрите:

Реальный кусочек кода из лоадера (Windows 2000, SP4):

Т.е. не деление, а умножение! Для каждого IMAGE_IMPORT_DESCRIPTOR такой код вызывается единожды. ForwarderChain здесь является индексом первого форварда.

Продолжаем. Если файл привязан к dll , которая загружена по адресу, отличному от ImageBase , привязка перестает быть валидной. В этом случае лоадер будет читать IAT , если не валидна и она – образ загружен не будет.

Время загрузки файла немного уменьшается – это происходит за счет того, что NTDLL.dll уже не патчит адреса внутри модуля, все уже сделано.

При TimeDateStamp равном –1 (т.е. 0xFFFFFFFF) имеем новый стиль привязки.

Лоадер сначала проверяет IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT , а только уж потом обращается к IMAGE_IMPORT_DESCRIPTOR (если обращается!). Проведите простой эксперимент: привяжите файл – утилита bind –u filename , потом удалите ВСЕ содержимое IMAGE_IMPORT_DESCRIPTOR , или наполните его мусором. Запустите файл. Ну как? Еще раз повторим. Если не выполняется строгое равенство TimeDateStamp , если файл загружен не на ImageBase , если API адрес не найден и т.п, то мы опять читаем IAT. Поэтому bind отказывается производить привязку образов, не имеющих OriginalFirstThunk – если что-то пойдет не так, мы ведь не сможем восстановиться!

IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT имеет свою структуру:

Обратите внимание, что структуры IMAGE_BOUND_IMPORT_DESCRIPTOR и IMAGE_BOUND_FORWARDER_REF в файле перемешаны. Форвард означает, что API как бы «перенаправляется» в другую dll. В ту самую, где, собственно и определен. В этом случае первая dll служит как бы переходником, не более того.

«Живой» пример на нашем неизменном calc.exe выглядит так:

Также обязательно необходимо учитывать, что перебазирование dll , к которой привязан данный исполняемый файл (приложение можно "привязать " и к своим библиотекам, bind это позволяет), также повлечет за собой чтение из "старой " директории импорта.

Теперь остановимся на одной грустной-грустной для нас с вами вещи. Положим, мы сдампили программу каким-нибудь дампером, например, LordPE. Положим, также, что некоторые опции утилиты были отключены. Что в этом случае у нас будет с директорией импорта? Предположим, имен и ординалов у нас нет!

Очевидно, файл будет рабочим только при соблюдении одного-единственного непреложного условия – все API -адреса в IAT (FirstThunk) должны быть строго валидными. Шаг в сторону – и такой файл можно просто выбросить. Или нет? Здесь мы подходим к понятию "восстановление таблицы импорта ".

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

Заметим, что данный алгоритм будет работать только на самых простых пакерах (например PECompact), с более продвинутыми, работать уже НЕ будет. Пошла сейчас мода коверкать директорию импорта. И здесь пакеры потихоньку выигрывают, т.к. искалечить всегда легче, чем восстановить. Никаких новых алгоритмов и идей здесь более обсуждаться не будет, т.к. это знание пойдет только во вред ибо может быть использовано авторами пакеров. К нашему глубокому сожалению в сети существуют некоторые проекты по восстановлению директории импорта с открытым исходным кодом, однако это большой недостаток. Уж лучше иметь работающий ImpRec , который худо-бедно но обновляется, чем открытый исходный код с устаревшей, бесполезной идеей.

Теперь рассмотрим, как работать со структурами PE -файла в IDA.

Простите за банальность – IDA – это очень мощный дизассемблер. Практически все операции идут под «капотом». Дизассемблировав PE -файл, вы даже не увидите его заголовков, IDA автоматически прогуляется по всей таблице импорта, все сделано за вас. Это и хорошо, и плохо. Хорошо это тогда, когда нет ни времени, ни желания ковыряться в секциях, просто быстро поломать. Плохо это тогда, когда попадается хитро подправленный файл, который IDA в автоматическом режиме взять не может.

Для примера давайте быстро вручную пробежимся по структурам секции импорта calc.exe. Для начала нам надо найти начало секции таблицы импорта. Итак, быренько запускаем какой-нибудь PE -редактор, например, PE Tools. В PE Editor давим кнопочку Directories. Как вы помните, это массив из #define , где секция импорта идет второй

Ее RVA - 12A40. ImageBase файла – OptionalHeader. ImageBase – 01000000 , следовательно, в IDA давим G , потом вводим 1012A40 (01000000 + 12A40). Вот прямо с этого места у нас и начинается массив из структур типа IMAGE_IMPORT_DESCRIPTOR.

Выглядит так:

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

Для того чтобы указать IDA , что тут у нас структура и надо бы преобразовать поля, лезем в Structures. Там создаем Ins структуру тютелька в тютельку по документации из winnt.h :

Далее остается применить эту структуру к смещению 1012A40. Примерно так:

И так до тех пор пока не попадется IMAGE_IMPORT_DESCRIPTOR , ВСЕ поля которого содержат нули. Аналогичную песню с определением новых структур придется спеть и для IMAGE_THUNK_DATA (а, в случае TimeDateStamp == 0 и для IMAGE_IMPORT_BY_NAME) и т.д., и т.п. А может и не придется! Ведь IDA хранит список стандартных структур! Поэтому, Add struct type > Add standard structure > Search. Но неплохо бы это все дело автоматизировать еще больше! Что ж, не мы с вами такие ленивые. Топаем на datarescue.com/idabаse/idadown.htm и сливаем оттуда PE utilities от Atli Mar Gudmundsson. Необходимо поместить их в %IDADIR%\idc , а потом F2 и файл pe_sections.idc. Если до этого вы не просто читали, а и пытались что-то делать ручками, то будете приятно удивлены.

Очевидно, что в этой директории программисты хранят иконки, кнопочки, и прочие маленькие радости пользователя. Уже упоминалось, что директория ресурсов обязательно должна размещаться в секции .rsrc , причем имя секции должно быть в точности таким – ".rsrc ". Причины уже объяснялись.

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

Взгляните:

Здесь хотелось бы процитировать Randy Kath с его статьей "The Portable Executable File Format from Top to Bottom": "The two fields OffsetToData and Size indicate the location and size of the actual resource data. Since this information is used primarily by functions once the application has been loaded, it makes more sense to make the OffsetToData field a relative virtual address. This is precisely the case. Interestingly enough, all other offsets, such as pointers from directory entries to other directories, are offsets relative to the location of the root node. "

Да, справедливо то, что полностью уничтожить директорию нельзя и теперь мы знаем почему. Однако, положим, вам пришлось проделать некие хитрые манипуляции с вашим конкретным файлом, например, после распаковки убрать более ненужные секции упаковщика. ОК, вы их убрали и лишились ресурсов, т.к. RVA перестал быть валидным! Значит, надо ресурсы восстановить, т.е. пересчитать смещения. Для этой цели у нас популярным средством является Resource Rebuilder v1.0 by Dr.Golova , а у зарубежных коллег, пожалуй, PE Rebuilder 0.96. О сугубо практическом применении можно почитать здесь - http://xtin.org. Статья - Отрезание секций, перемещение ресурсов, автор Hex.

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

1. Получаем из PE заголовка секцию с именем “ .rsrc ”.

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

3. Создаём новую секцию ресурсов.

1. Подсчитываем необходимый размер будущей секции.

2. Далее записываем все ресурсы (каталоги/имена/данные) в эту секцию.

3. Затем делается ещё один проход и корректируем все смещения в каталогах.

4. Корректируем PE заголовок, если это необходимо.

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

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

Словом, пакеры оставляют все сигнатуры, MZ поле e_lfanew , OptionalHeader. DataDirectory[x] и т.п., но часть жизненно важных данных может быть искажена. Поэтому лучше не играть в кошки-мышки, а просто-напросто в опциях дампера (PE Tools , LordPE) активировать режим вставки заголовка файла с диска (Full Dump: Paste header from disk).

Теперь, в довесок к изуродованию директории импорта, секции кода, директории ресурсов и т.п., появляется возможность калечить директорию перемещаемых элементов (relocations , fixups). Например, такой фокус производит UPX (но там открыт исходный код, следовательно, нужно ожидать такого подарочка от многих пакеров в скором времени).

Информация из директории перемещаемых элементов применяется тогда, когда адрес загрузки файла отличается от ImageBase. Для ехе -файлов такое встречается достаточно редко (но не так, чтобы и очень – вспомните VTune), а для dll – это норма. Так вот, директория перемещаемых элементов содержит информацию о том, как патчить данные, расположенные по указанному адресу, чтобы было возможно нормальное продолжение работы. В противном случае, операнд инструкции будет указывать в "космос".

Структура директории выглядит просто:

Давайте разберем на живом примере, ЧТО может быть подвержено перемещению и как с этим работать. Итак, создадим простейший файл:

Только попросим при этом линкер создать исполняемый файл с опцией /FIXED:NO , что означает автоматическое создание директории перемещаемых элементов (как правило, это секция .reloc , хотя и не обязательно). Теперь дизассемблируем в IDA , применяем скрипт от Atli Mar Gudmundsson и смотрим:

Итак, поле relocs_0001_page , очевидно, соответствует полю VirtualAddress (напоминаем, что релоки применяются к виртуальным страницам, отсюда и слово page), relocs_0001_size - SizeOfBlock , relocs_0001_toff - чуть поинтереснее. Как видим, это массив из word, где старшие четыре бита - это тип релока (в даном случае - #define IMAGE_REL_BASED_HIGHLOW 3), а оставшиеся 12 надо сложить с VirtualAddress , чтобы получить RVA данных для обработки. Ну-ка, давайте посмотрим, куда указывает самое первый word из массива - 3А4F. Итак, A4F + 11000:

Ба! Да прямо в центр инструкции mov , т.е. адрес начала массива &hello[0] подвержен обработке! И так много чего. Релокейшенам подвержены строковые литералы, статические переменные, ссылки на неинициализированные статические данные, абсолютные call/jmp , да мало ли что еще! Словом, кошмар!

Релоки обрабатываются лоадером при загрузке – функция - LdrRelocateImage. Обработка релоков происходит перед обработкой таблицы импорта (не всегда!). Функция LdrpMapDll зовет LdrRelocateImage , которая, в свою очередь, определяет заголовок файла, вычисляет где расположена директория релоков и зовет LdrProcessRelocationBlock.

LdrRelocateImage вызывается когда ZwMapViewOfSection (бывшая NtMapViewOfSection) возвращает STATUS_CONFLICTING_ADDRESSES. В случае загрузки по адресу, отличному от ImageBase модуль загружается полностью (обратите внимание, пакер в любом случае обязан пройтись по всем страницам, поэтому запакованный модуль действительно загружается полностью), релоки накладываются сразу, и потом секция с релоками выгружается из памяти (флаг секции IMAGE_SCN_MEM_DISCARDABLE) в своп и в дальнейшем используются только от туда, т.к. из dll Windows более ничего не читает. Что-то отдаленно похожее алгоритмически можно найти в Wine - функция map_image из файла virtual.c. Реальный код из лоадера выглядит так (Win 2000 SP4):

Как вы видите, будут обработаны все блоки перемещаемых элементов, а уж есть ли релоки во ВСЕХ секциях модуля – это совсем другая песня. Сам алгоритм LdrProcessRelocationBlock достаточно тривиален и очень хорошо расписан во многих источниках (www.RSDN.ru, http://mitglied.lycos.de/yoda2k и т.п.), где есть исходники и на C/C++ и на Delphi.

Заметим, что применение релоков чревато не только увеличением времени загрузки, а и частыми page fault - вследствие применения релоков к секции получаем ее копию в памяти - механизм copy-on-write - подробнее MSDN - Ruediger R. Asche - Rebasing Win32 DLLs: The Whole Story.

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

Восстановление relocation directory – дело непростое. Стандартной техникой со времен DOS считалась загрузка файла по двум разным базовым адресам, и поиск различий в них (например, по этому принципу работает утилита ReloX от mackT). Для загрузки одного и того же файла его достаточно переименовать, иначе лоадер откажется загружать файл повторно (LdrpCheckForLoadedDll). Заметим, что директория перемещаемых элементов все равно сохраняется под пакером, пусть и в его формате, следовательно, нет принципиальных сложностей в загрузке модуля по двум разным базовым адресам.

Однако в PE Tools используется совершенно безумный алгоритм статического анализа файла, изобретенный NEOx'ом после нескольких бутылок пива (водки?). Итак, основной принцип восстановления релоков – это поиск предположительных ссылок, которые в той или иной степени могут быть подвержены релокам. Ссылки находятся следующим образом:

1) Сканируем все секции от начала до конца (читать данные DWORD -ами, смещаясь на один байт в цикле).

2) Из полученного значения отнимаем OptionalHeader.ImageBase (это нужно для того, чтобы вычислить адрес ссылки)

3) Проверить является ли этот адрес ссылкой, а не кодом. Проверяем – если полученное значение больше OptionalHeader.BaseOfCode , но меньше OptionalHeader.SizeOfImage , значит это ссылка, если нет – читаем следующий DWORD.

4) На основе этих данных генерируем новые релоки.

Также необходимо разобраться, что же происходит при загрузке exe/dll в память. Сразу оговорюсь, что процесс этот не будет рассмотрен вообще – не любим повторов.

Для начала необходимо достаточно четко представлять себе архитектуру распределения памяти в Win NT+. Думается, что лучше, чем это сделал Джеффери Рихтер в своей книге "Windows для профессионалов " это не объяснил никто. Такое понимание сильно облегчает жизнь. Например, если вы встречаете нечто вроде адреса 7xxxxxxх, то можете не сомневаться – это адрес какой-нибудь API функции из системных библиотек. Не плохо бы представлять себе и границу стека. ПРИБЛИЗИТЕЛЬНО регион стека в любом вьювере адресного пространства легко опознать по атрибуту страницы PAGE_GUARD. Приблизительно потому, что этот атрибут страницы смещается по стеку во время выполнения.

Загляните в MSDN - статья Q147314 – описание флагов Session Manager. Среди них есть и такой, который требует от NTDLL.dll "озвучивать " свои действия, т.е. выдавать сообщения в окно отладчика (WinDBG, отладчика VS и т.п.). Для того чтобы не морочить себе голову запоминанием флагов, MS создала утилиту GFlags.exe , которая поставляется вместе с комплектом отладочных утилит с сайта MS. Скачать это дело можно совершенно свободно. Мы бы порекомендовали активировать флаг "озвучивания" действий лоадера, т.к. это будет исключительно полезно, например, в тех случаях, когда сдампленная программа не запускается, а лоадер говорит: "Application failed to initialize properly ". В этом случае вы сможете быстро найти ту функцию ntdll.dll, которая отказалась "принять " файл и, зная алгоритм ее работы, у вас уже будет какой-то ключик. Это адова работа, но в некоторых случаях такая методика помогает.

Учтите, что ntdll.dll автоматически проецируется на адресное пространство любого Windows-приложения.

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

Поверхностно алгоритм работы лоадера расписан на http://www.iecc.com/linker/. Так же алгоритм работы можно приблизительно уяснить из исходных кодов Wine и ReactOS (http://www.reactos.com - своеобразный аналог Wine , только цели чуть другие). Во всем этом деле полезным будет справочник по Native API - http://undocumented.ntinternals.net. Также многие функции лоадера, например RtlImageHeader и т.п., прокомментированы на более высоком уровне в MSDN – библиотека imagehlp.dll.

Для облегчения анализа обязательно сгрузите себе файлы символов – pdb/dbg.

Самое главное при дизассемблировании лоадера – начинать плясать от определения структур данных. При дизассемблировании файла в IDA вставьте структуры winnt.h(метод описан выше), и начинайте превращать код из неудобоваримого:

в

Удачи! :)

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

Итак, 64-bit PE файлы еще называются как PE32+. Отличить их от обычного файла можно по сигнатуре. Сигнатура расположена в поле OptionalHeader.Magic и равна

Для определения типа файла можно использовать эту функцию, которой необходимо передать адрес на проекцию файла:

Различий же в строении самих структур (т.е. секций, директорий и т.п.) нет. Естественно, что DWORD заменяется на ULONGLONG , т.е. unsigned int64 (ха-ха!). Разумеется, добавлены новые типы флагов для совместимости, например, с AMD64 и т.п. В директории импорта теперь появляется структура IMAGE_THUNK_DATA64 с типами ULONGLONG , изменения коснулись и ресурсов.

Особо останавливаться на этом не будем.

Такие модули начнут попадаться все чаще и чаще, однако особой паники, думается нам, в этом нет. IDA вполне готова, HIEW грустно говорит об "Unknown header magic " и редактировать поля более не позволяет, LordPE и PE Tools на высоте.

Единственное, что смущает во всем этом деле – так это сам тип int64 , а, вернее, его полное отсутствие на 32-битных машинах. Компиляторы просто-напросто эмулируют int64 путем помещения двух DWORD в стек, причем, понятия unsigned int64 пока нет вообще! Словом, у MS ещё не все ладно с поддержкой самого типа. А в будущем… Конечно, проблему решат. Например, переходом на Windows IA-64.

Данную главу вы можете смело пропустить на данный момент времени, т.к. создание плагина под PE Tools для генерирования XML-отчета пока только планируется. С другой стороны, данная глава дает очень краткий экскурс в эту несложную, но достаточно специфическую тему, а знание никогда не бывает бесполезным, в особенности в свете того, что имеется тенденция использовать XML -файлы в качестве файлов конфигурации.

Для того чтобы вывести само строение РЕ -файла необходим какой-то очень наглядный формат вывода. Например, такой, в котором мы сможем описывать его структуру и составляющие. Самыми известными являются XML и ASN.1. Последний имеет некоторые преимущества над XML (например, платформо-независимые правила бинарного перекодирования - BER , DER и т.п., хотя с появлением XER - правил бинарного кодирования для XML все немного изменилось), имеет куда более длинную историю развития, но не слишком понятен, громоздок, и, самое главное, многим просто НЕ симпатичен. Поэтому после работы данной программы вы получите XML -файл, описывающий структуру заголовков PE -файла (некоторые поля), и подробно раскрывающий содержание таблицы импорта.

XML – extensible markup language

Формат появился на свет не так уж и давно, однако сразу завоевал бешеную популярность. Его активно используют по всему миру как формат обмена данными между программами (различными ОС, приложениями и т.п.). Формат этот платформо-независимый, еще бы, ведь это чистый текст. От HTML внешне он отличается только тем, что название тегов в HTML жестко фиксировано (например, ТОЛЬКО тег <TITLE> и ничто другое не может стоять для вывода информации в строку титула). В XML названия тегов задаю я сам. Получается весьма наглядно и интуитивно понятно. Например: Сравните, как много информации нам дает XML, и как мало – HTML. Да, в первом случае все, быть может, чуть нагляднее представлено браузером, однако во втором – намного более информативно. На каждый XML-документ налагаются достаточно жесткие требования. Как минимум, он должен быть well-formed. Мы бы перевели это как «корректно оформленный» - нельзя делать, например, так: Далее, для каждого XML-документа должен существовать (ну, скажем, ЖЕЛАТЕЛЬНО, чтобы существовал) некий словарь, на соответствие которому мы сможем проверить, а правильно ли составлен документ XML (валидность – valid/invalid), т.е. законны или незаконны применяемые теги. Для будущего плагина, без сомнения, будет выбрана проверка в виде XML-Schemas (есть и другие, однако это – самая лучшая). XML хорош и тем, что позволяет трансформировать документ в другие типы документов при помощи xsl(xslt)-файла. Последний тоже является xml-документом, который представляет собой совокупность директив для программы – XSLT-процессора, принимающей на вход оригинальный XML-файл, и преобразующей его согласно XSLT-файлу. Вывод осуществляется в другой файл или в STDOUT. В качестве замечательного примера такой программы назову XMLSpy (www.altova.com), который позволяет не только применить XSLT к выбранному документу, но и проделать много других вещей, например, проверить на well-formness, валидность и т.п. Более подробно об этом мы поговорим ниже.

Теперь немного о самой будущей программе. NEOx дает возможность создания плагинов под PE Tools , однако, пока совершенно не предоставляет никакого API для удобства работы, а поскольку мы люди ленивые, то пока нету API, нет и плагинов.

Сама программа будет написана на С , т.е. на компилируемом языке, и для своего запуска не требует ничего (кроме Windows). Однако преобразование XML формата в XSLT , выполняемое на С либо даже С++ - занятие нетривиальное! Поэтому для преобразования с использованием XSLT (или XSLT : FO для психов) традиционно используются другие языки. Например, несравненный Perl либо богатейшая библиотека классов Java. Есть, конечно, и MS XML SDK , однако в некоторых случаях лично у нас вызывается жуткое отвращение, в особенности когда MS пытается обозвать свои разработки "стандартом ". XML специально разработан так, чтобы разработчики на разных операционных системах могли свободно обмениваться данными. Это гарантируется самой спецификацией XML. MS это пытается нарушить, вводя свои правила. Поэтому, MS XML SDK здесь рассмотрен не будет! Хотя над самой темой обработки XML на С/С++, вероятно, стоит подумать.

Для того, чтобы иметь возможность конвертировать XML в HTML при помощи Perl , вам надо скачать Win32-Perl-интерпретатор (www.activestate.com), проинсталлировать его (а иначе, зачем было качать?), сделать определенные установки и можно начинать работать.

После того, как скачали и поставили дистрибутив Perl , самое время воспользоваться PPM. PPM – это Perl Package Manager – утилита, позволяющая управлять дополнительными модулями. В данном случае нам потребуется модуль Win32API-File , который обеспечивает доступ к некоторым Win32API -функциям работы с файлами. По умолчанию PPM выполняет поиск в так называемых « репозиториях » - одна из них расположена на вашем диске, вторая – в сети на сайте http://www.activestate.com (который, кстати, сильно проигрывает по свежести многим другим зеркалам, позже, мы поговорим об этом).

Ну вот, XML -файл готов. Самое время превратить его в HTML. XSL -файл у нас есть (см. приложенный пакет), осталось найти утилиту, которая преобразует полученный XML -файл согласно инструкциям из XSL -файла. Мы возьмем три примера:

1. XMLSpy

2. VisualXSLT + command-line Perl parser

3. Saxon + command-line Java-parser. Сразу скажем, что наиболее просто и приятно использовать XMLSpy. Вес пакета ~ 30 Мб, загрузите его с http://www.altova.com.

XMLSpy – открываете два документа – полученный в результате работы утилиты xml -файл и приложенный XSLT -файл. F10 – и наслаждаетесь полученным HTML -файлом. Можете сохранить. Все. Да, если взбредет в голову проверить на валидность – F8 , на корректность – F7. Впрочем, если что-то пойдет не так, вы об этом быстро узнаете.

VisualXSLT + command-line Perl parser – немного более болезненно. VisualXSLT – это модуль к VS.NET. Т.е. у вас должна стоять Visual Studio. Сам пакет брать с activestate. В установках проекта помечаете формат выходного файла, F5 и все. Если парсер запускается из коммандной строки то тогда у вас должен быть собственно сам парсер (приложен). Для работы приложенного парсера требуется библиотека LibXSLT. Ее нужно загрузить из интернета:

http://theoryx5.uwinnipeg.ca/ppmpackages/

Есть такое себе зеркало activestate , которое ведет Randy Kobes (randy@theoryx5.uwinnipeg.ca) – хороший мужик и зеркало очень приличное. Сгружайте оттуда. Заходим в PPM -

Да, если поставили Перл в директорию, имя которой содержит пробелы – несколько приятных часов вам обеспечено %).

Если же модуль по каким-либо причинам ставиться не хочет, тогда топайте на cpan.org и сгружайте его оттуда вручную (если он там есть). Потом вручную настраивайте makefile и потом nmake -install.

Теперь вкратце пробежимся по разным XSLT -преобразователям.

Saxon + command-line Java-parser

Для этой бандуры необходим JDK – брать с java.sun.com – он называется J2SE. Сливайте, ставьте и вперед. После установки надо выставить переменную окружения CLASSPATH – для W2k это делается через окошко «Система». Сама CLASSPATH должна выглядеть так: .;C:\путь_к_JDK\lib\tools.jar. Обратите внимание на точку и точку с запятой в начале строки! Также добавьте в PATH путь к JDK. Теперь можно запускать парсер. Парсера звать Saxon – очень навороченная Java-игрушка. Запускать так:

Но Saxon большой и качать его долго. Поэтому приложен парсер поменьше и попроще – Stylizer. Скомпилированный файл называется Stylizer.class. Запускать так:

Обратите внимание на отсутствие расширения!

Существуют и другие утилиты – например, Xalan. Однако и тех, что здесь перечислены – хватит за глаза.

Единственная вещь, которая может вызывать смущение – это размер XML -файла. Хотя трудно представить себе такой PE -файл, отчет на который займет метров 50 в виде XML , однако… Тогда все xslt -преобразователи благополучно слетят либо с OutOfMemoryException , если это Ява, либо просто помрут в муках, если это С/С++ (потому что чучундры, которые их писали, просто не могли себе представить, что malloc/new может вернуть ноль, кстати, выброс исключения new введен стандартом ANSI-ISO именно поэтому – слишком мало людей озаботились проверить код возврата!). Для столь больших файлов применяется совсем другая схема – пишется разовый SAX -парсер, настроенный на конкретные цели, однако обсуждение этой темы здесь совсем не к месту. Словом, если вам не встретятся файлы отчетов свыше мегабайт, скажем, 30, то и волноваться нечего.

* * *

Ну вот, вроде и все. По идее, теперь вы должны представлять строение PE -файла, уметь играться с Perl и Java , а также приблизительно понимать XML , и уметь применять XSLT. Также, наверняка, вам очень хочется сказать нам что-то теплое, ласковое, домашнее за ваши муки при чтении.

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

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

* * *

Ну, традиционный пункт, который все авторы старательно пишут, а все читатели старательно игнорируют. Можете игнорировать и вы, кусать никто не будет.

Первым пишу я, Volodya.

Хотелось бы выразить искреннюю благодарность и признательность Евгению Сусликову за данные консультации по RVA/VA и файловым оффсетам. Я также горжусь знакомством со sla-md , который дал мне очень подробные объяснения о преобразовании флагов секций PE-файла в соответствующие атрибуты, объяснил некоторые сетевые трюки и вообще, просто является гениальным человеком. Щiре дякую Quantum'у за успешную попытку статической линковки API-forward-функций. Так же обязательно стоит поблагодарить Russell Osterlund за некоторые пояснения по работе лоадера. Самые теплые слова (эх, как звучит!) надо сказать моей любимой команде - HI-TECH (wasm.ru) - Edmond , Aquila , Broken Sword , Four-F - спасибо за ценные замечания, указания, пожелания, вылавливание мелких и крупных блох в моих рассуждениях. Спасибо!

Вторым пишу я, NEOx.

Хотелось бы выразить особую благодарность Доктору Голове за его консультацию по поводу восстановления директории ресурсов, а так же всей команде uinC.

* * *

Итак, что дальше.

Вторая часть статьи будет рассказывать об алгоритмах работы элементарного пакера, самых легких случаях нахождения OEP , распаковке ручками Aspack/UPX/telock/pelock/crunch и т.п. Будет упомянут механизм SEH и некоторые антиотладочные приемы.

Третья часть посвящена очень сложным защитным системам – Armadillo, Obsidium, Asprotect.

Засим разрешите распрощаться до следующей части. Ave.

RNBOsproQuery(packet, address, *queryData, *response, *response32, length)

address -- это номер ячейки донгла, с которой начинается алгоритм; queryData -- входной массив; response -- выходной массив; response32 -- последние 4 байта выходных данных, представленные в виде 32-битной переменной; length -- длинна (в байтах) как входного, так и выходного массивов.

Чтоб окончательно вас запутать, далее представлен "графический эквивалент" описания RNBOsproQuery:

А что всё-таки там за алгоритм кроется в недрах донгла? Каким образом выходные данные связаны со входными? Кто застрелил Дж. Ф. Кеннеди? Что было вначале: яйцо или курица? Надеюсь, вы теперь понимаете почему хак RNBOsproQuery порой представляет собой изрядную сложность даже для опытного реверсера.

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

т.е. пропатчить этот код не просто, а очень просто! Причём RNBOsproQuery вызывается всего лишь 4 раза и обработка результата почти одинакова во всех четырёх случаях. Итак, грузим WlscGen.exe в IDA, применяем соответствующие сигнатуры и задаём поиск вызовов RNBOsproQuery. Вот вам и первый результат:

Что делает этот код? Ладно, объясняю:

1. генерируем случайное число стандартным сишным методом;

2. колдуем над этим числом и переводим его в массив;

3. подсовываем этот массив в RNBOsproQuery для обработки алгоритмом 0Ch (адрес начальной ячейки алгоритма);

4. результат обработки конвертируем в ASCII-строку;

5. используем случайное число из пункта 1 для адресации фиксированного в экзешнике массива со строковыми константами;

6. сравниваем обе строки;

7. если строки совпадают, продолжаем (последний переход JZ).

Тот фиксированный массив в программе является своеобразным рангом алгоритма 0Ch, т.е. он хранит все возможные результаты данного алгоритма. Я рекомендую вам пройтись по данному участку кода под отладчиком и убедиться в тривиальности всей проблемы. Что нам мешает исправить тот последний переход? Ну, вообще говоря, правильнее будет поксорить регистр EAX на месте вызова _strncmp, как будто строки равны. Заодно можно убрать вызов RNBOsproQuery чтоб лишний раз не беспокоить драйвер. Тривиальный патч:

Остальные 3 вызова RNBOsproQuery фиксятся аналогичным образом. Справедливости ради стоит заметить что подобных глюков (иначе и не назовёшь явное сравнение через _strncmp) вы больше не увидите. RNBOsproQuery кроет в себе громадный потенциал, который по достоинству ценят лишь немногие пользователи SLM, хакеры и мы с вами. Чего только нельзя сделать используя ячейки с алгоритмами, содержание которых недоступно реверсеру?! Даже идея со случайным числом, хеш-алгоритмами и массивом строк можно было бы назвать удачной, если б не то [нецензурный эпитет] сравнение сразу после RNBOsproQuery.

Ну вот и всё: WlscGen.exe к употреблению готов! Попробуйте создать пробную лицензию (задайте параметры по вашему усмотрению) и убедитесь в работоспособности генератора. Получилось? Тогда достаньте ваш любимый патчегенератор (Patch Creation Wizard, например) и сделайте универсальный патч для WlscGen.exe (не фиксить же его вручную при каждой смене VId?!). Не распространяйте ваш патч потом в сети, ладно?

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

1. SentinelSuperPro API

Пример: WlscGen.exe.

Документация: "SentinelSuperPro 6.0 Developer's Guide".

Приложение использует функции работы с донглом: RNBOsproRead, RNBOsproWrite, RNBOsproQuery и т.д. Задача исследователя заключается в обнаружении и последующем обезвреживании данных функций, как мы и поступили с WlscGen. Данный случай можно назвать низкоуровневой защитой (приложение явно опирается на архитектуру донгла).

2. SLM Client API и иже с ним

Пример: мой таргет и все-все-все.

Документация: "SentinelLM Programmer's Reference Manual", "SentinelLM Developer's Guide".

Приложение использует высокоуровневые функции, вроде LSRequest. Всю грязную работу (чтение лицензионного файла, общение с донглом и т.д.) выполняет API. Обратите внимание на то, что API может и не обращаться к донглу если лицензионный файл того не требует. Типичный подход к решению проблемы требует получения VId жертвы и некоторой информации о самой лицензии (тип лицензии, версия лицензируемой фичи, наименование фичи и т.д.) Полученная информация передаётся в WlscGen и создаётся новая лицензия (без триального срока... без донгла... :-) Стоп! А откуда взять эту дополнительную информацию о самой лицензии? В самом простом случае её можно выудить из оригинального лицензионного файла. Имя по умолчанию для лиц. файлов -- lservrc (без расширения). Вот, например, демо-версия моей жертвы досталась мне с файлом следующего содержания (некоторая информация удалена по понятным причинам):

Итого: 4 лицензии. Вся необходимая WlscGen'у информация любезно предоставлена в каждой строчке после '#'. А что если файла нет? Или он есть но без полной информации? Тогда чуть сложнее... Придётся задействовать IDA + SoftIce и перехватить вызовы LSRequest. Вот вам типичный пример использования LSRequest (фрагмент взят из первой попавшейся под руку демки):

Параметры LSRequest напоминают искомую нами информацию... Да, так оно и есть:

LSRequest(licsystem,publisher,feature name,feature version, tokens,log comment,challenge,*handle)

В вышеописанном фрагменте не фигурируют прямые указатели на строковые константы, передаваемые в LSRequest. Проще всего будет перехватить эти параметры в SoftIce. Ловим LSRequest примерно также как и computeVendorCode в первой главе. Потом извлекаем интересующие нас параметры из стека и радуемся жизни.

Теперь вы скажете: "А какого @#% мы столько возились с WlscGen, ведь можно было просто найти и пофиксить LSRequest в коде нашей жертвы?!". Хмм... Я предпочитаю оставить этот вопрос вам на засыпку. Помедитируйте над ним :-)

Существуют и другие вариации SLM, как-то: сетевой сервер SLM, новомодный SentinelLM Shell (тоже входит в SDK). Но это уже темы для отдельных статей. Короче, бросайте всё и бегите добивать ваш таргет!

Неужели это всё?!

Наверное я не затронул и десятой доли того, что входит в теорию взлома SentinelLM. Вы дочитываете последнюю главу вступления в SLM! Если вы смогли удачно воплотить в код то, что я тут описал, плюс поняли суть самой защиты и её снятия, значит я не зря потратил время. Как говаривал Фокс Мольдер, "Я хочу верить" :-)

Для дальнейшего изучения рекомендую кучу / уйму туториалов по взлому конкретных таргетов под защитой Sentinel. Особенно хороши статьи CyberHeg, CrackZ и Goatass, которые можно найти... в сети. Нет, всё это добро конечно лежит на сайте CrackZ, но сам сайт CrackZ постоянно кочует. Тут (http://66.98.132.48/krobar/collections/crackz.zip) можно качнуть оффлайновую версию всего сайта. На Krobars (http://krobars.reverse-engineering.info/) можно найти многие статьи по SLM и донглам вообще. Ещё эти статьи прозеркалены на других сайтах, даже в переводе. На испанском, например, это добро можно скачать с сайта Karpoff (http://hackindex.com/~karpoff/Manuales.htm#Dongles).

Теперь о главном...

Премного благодарствую всем писателям статей по Sentinel (too many и всех не перечислить), а также коллективу WASM.RU, включая уважаемых членов форума. Отдельной благодарности заслуживают volodya (щедрый поощритель начинающих писателей) и главные редакторы (вы их и сами знаете :-). Большое спасибо и вам, дорогой читатель и коллега. Да пребудет с вами сила Дзена и свобода мысли!

В некоторых защитных механизмах используется контроль целостности программного кода на предмет выявления его изменений. Теперь, если хакер подправит несколько байтиков в программе, защита немедленно обнаружит это и взбунтуется. Святая простота! – воскликнет хакер, – и отключит самоконтроль защиты, действуя тем же самым способом, что описан выше. По наблюдениям автора, типичный самоконтроль выявляется и нейтрализуется за несколько минут. Наиболее сильный алгоритм защиты: использовать контрольную сумму критических участков защитного механизма для динамической расшифровки некоторых веток программы ломаются уже не за минуты, а за часы (в редчайших случаях – дни). Алгоритм взлома выглядит приблизительно так: а) подсмотрев контрольную сумму в оригинальной программе, хакер переписывает код функции CalculateCRC, заставляя ее всегда возвращать это значение, не выполняя реальной проверки; б) если защита осуществляет подсчет контрольной суммы различных участков программы и/или разработчик использовал запутанный самомодифицирующийся код, трудно предсказуемым способом меняющий свою контрольную сумму, то хакер может изменить защиту так, чтобы она автоматически само, восстанавливалась после того, как все критические участки будут пройдены; в) отследив все вызовы CalculateCRC, хакер может просто снять динамическую шифровку, расшифровав ее вручную, после чего надобность в CalculateCRC пропадает. Стоит отметить, что независимо от способа своей реализации любой самоконтроль элементарно обнаруживается установкой точек останова на те участки защитного механизма, которые были изменены. Остальное – дело техники. Можно сколь угодно усложнять алгоритм подсчета контрольной суммы, – напичкивать его антиатладочными приемами, реализовать его на базе собственных виртуальных машин (то есть интерпретаторов), некоторые из которых, такие, например, как Стрелка Пирса, достаточно трудно проанализировать. Но… если такие меры и остановят взломщика, то ненадолго.

Техника неявного контроля Ошибка традиционного подхода заключается в его предсказуемости. Любая явная проверка чего бы то ни было, независимо от ее алгоритма – это зацепка! Если хакер локализует защитный код, то все – пиши пропало. Единственный надежный способ отвадить его от взлома – "размазать" защитный код по всей программе с таким расчетом, чтобы нейтрализовать защиту без полного анализа всей программы целиком – было заведомо невозможным. К сожалению, существующие методики "размазывания" либо многократно усложняют реализацию программы, либо крайне неэффективны. Некоторые программисты вставляют в программу большое количество вызовов одной и той же защитной функции, идущих из различных мест, наивно полагая тем самым, что хакер будет искать и анализировать их все. Да как бы не так! Хакер ищет ту самую защитную функцию и правит ее. К тому же, зная смещение вызываемой функции, найти, отследить ее вызовы можно без труда! Даже если встраивать защитную функцию непосредственно в место ее вызова, – хакер сможет найти все такие места тупым поиском по сигнатуре. Пускай, оптимизирующие компиляторы, несколько меняют тело inline-функций с учетом контекста конкретного вызова – эти изменения не принципиальны. Реализовать же несколько десятков различных защитных функций – слишком накладно, да и фантазии у разработчика не хватит и хакер, обнаружив и проанализировав пару – тройку защитных функций, настолько проникнется "духом" и ходом мысли разработчика, что все остальные найдет без труда.

Между тем существует и другая возможность – неявная проверка целостности своего кода. Рассмотрим следующий алгоритм защиты: пусть у нас имеется зашифрованная (а еще лучше упакованная) программа. Мы, предварительно скопировав ее в стековый буфер, расшифровываем (распаковываем) ее и… используем освободившийся буфер под локальные переменные защищенной программы. С точки зрения хакера, анализирующего дизассемблерный код, равно как и гуляющего по защите отладчиком, все выглядит типично и "законно". Обнаружив защитный механизм (пусть для определенности это будет тривиальная парольная проверка), хакер правит соответствующий условный переход и с удовлетворением убеждается, что защита больше не ругается и программа работает.

Как будто бы работает! – через некоторое время выясняется, что после взлома работа программы стала неустойчивой, – то она неожиданно виснет, то делает из чисел "винегрет", то… Почесав репу, хакер озадаченно думает: а как это вообще ломать? На что ставить точки останова? Ведь не анализировать же весь код целиком! Весь фокус в том, что некоторые из ячеек буфера, ранее занятого зашифрованной (упакованной) программой при передаче их локальным переменным не были проинициализированы! Точнее, они были проинициализированы теми значениями, что находились в соответствующих ячейках оригинальной программы. Как нетрудно догадаться, именно эти ячейки и хранили критичный к изменениям защитный код, а потому и неявно контролируемый нашей программой. Теперь я готов объяснить зачем вся эта котовасия с шифровкой (упаковкой) нам вообще понадобилась: если бы мы просто скопировали часть кода программы в буфер, а затем "наложили" на него наши локальные переменные, то хакер сразу бы заинтересовался происходящим и, бормоча под нос "что.то здесь не так", вышел бы непосредственно на след защиты. Расшифровка нам понадобилась лишь для усыпления бдительности хакера. Вот он видит, что код программы копируется в буфер. Спрашивает себя "а зачем?" и сам же себе отвечает: "для расшифровки!". Затем, дождавшись освобождения буфера с последующим затиранием его содержимого локальными переменными, хакер (даже проницательный!) теряет к этому буферу всякий интерес. Далее – если хакер поставит контрольную точку останова на модифицированный им защитный код, то он вообще не обнаружит к ней обращения, т. к. защита контролирует именно зашифрованный (упакованный) код, содержащийся в нашем буфере. Даже если хакер поставит точку останова на буфер, он быстро выяснит, что: а) ни до, ни в процессе, ни после расшифровки (распаковки) программы содержимое модифицированных им ячеек не контролируется (что подтверждает анализ кода расшифровщика/распаковщика – проверок целостности там действительно нет); б) обращение к точке останова происходит лишь тогда, когда буфер затерт локальными переменными и (по идее!) содержит другие данные.

Правда, ушлый хакер может обратить внимание, что после "затирания" значение этих ячеек осталось неизменным. Совпадение? Проанализировав код, он сможет убедиться, что они вообще не были инициализированы и тогда защита падет! Однако, мы можем усилить свои позиции: достаточно лишь добиться, чтобы контролируемые байты попали в "дырки", образующиеся при выравнивании структуры (этим мы отвечает хакеру на вопрос: а чего это они не инициализированы?), а затем скопировать эту структуру целиком (вместе с контролируемыми "дырками"!) в десяток-другой буферов, живописно разбросанных по всей программе. Следить за всеми окажется не так-то просто: во-первых, не хватит контрольных точек, а, во-вторых, это просто не придет в голову.

Рисунок 1

Практическая реализация

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

Стоп! Ведь выше мы говорили как раз об обратном. Единственный путь сде. лать защиту трудно ломаемой, – не выдавая никаких ругательных сообщений, по которым нас можно засечь, молчаливо делать "винегрет" из обрабатываемых дан. ных. А теперь, выясняется, что делать этого по этическим (и юридическим!) сооб. ражением нельзя. На самом деле, если хорошо подумать, то все эти ограничения легко обойти. Что нам мешает оснастить защиту явной проверкой целостности своего кода? Хакер найдет и нейтрализует ее без труда, но это и не страшно, по. скольку истинная защита находится совершенно в другом месте, а вся эта бутафо. рия нужна лишь затем, чтобы предотвратить последствия непредумышленного ис. кажения кода программы и поставить пользователя в известность, что все данные нами гарантии (как явные, так и предполагаемые) ввиду нарушения целостности оригинального кода, аннулируются. Правда, при обсуждении защиты данного ти. па, некоторые коллеги мне резонно возразили, а что, если в результате случайного сбоя окажутся изменены и контролируемые ячейки, и сама контрольная сумма? Защита сработает у легального пользователя!!! Ну что мне на это ответить? Случай. но таких "волшебных" искажений просто не бывает, их вероятность настолько близка к нулю, что… К тому же, в случае срабатывания защиты мы ведь не форма. тируем легальному пользователю диск, а просто нарушаем нормальную работу про. граммы. Путь и предумышленно, все равно, если в результате того или иного сбоя был искажен исполняемый файл, то о корректности его работы более говорить не приходится. Ну хорошо, если вы так боитесь сбоев, можно встроить в защиту хоть десяток явных проверок, – трудно нам что ли?! Ладно, оставим этические проблемы на откуп тем самым пользователям, ко. торые приобретают титул "лицензионных" исключительно через крак, и перейдем к чисто конкретным вещам. Простейший пример реализации данной защиты приве. ден в листинге 1. Для упрощения понимания и абстрагирования от всех технических деталей, здесь используется простейшая схема аутентификации, "ломать" которую совершенно необязательно: достаточно лишь подсмотреть оригинальный пароль, хранящийся в защищенном файле прямым текстом. Для демонстрационного приме. ра такой прием с некоторой натяжкой допустим, но в реальной жизни, вам следует быть более изощренными. По крайней мере следует добиться того, чтобы ваша защи. та не ломалась изменением одного единственного байта, поскольку в этом случае да. же неявный контроль будет легко выявить. Следует так же отметить, что контроли. ровать все критические байты защиты – не очень.то хорошая идея, т. к. хакер сможет это легко обнаружить. Если защита требует для своего снятия хотя бы десяти моди. фикаций в различных местах, три из которых контролируются, то с вероятностью ~70% факт контроля не будет обнаружен. Действительно, среднестатистический ха. кер следить за всеми модифицированными им байтами просто не будет. Вместо это. го он, в надежде что тупая защита контролирует целостность своего кода целиком, будет следить за обращениями к одной, ну максимум двум.трем, измененным им ячейкам и… с удивлением обнаружит, что защита их вообще не контролирует. После того, как контрольные точки выбраны, вы должны определить их сме. щение в откомпилированном файле. К сожалению, языки высокого уровня не по. зволяют определять адреса отдельных машинных инструкций и, если только вы не пишите защиту на ассемблерных вставках, то у вас остается один.единственный путь – воспользоваться каким ни будь дизассемблером (например, IDA).

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

}

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

Как нетрудно сообразить, условный переход, расположенный по адресу 0x401067 и есть тот самый "if", который нам нужен. Однако, это не весь if, а только малая чего часть. Хакер может и не трогать условного перехода, а заменить инструкцию test eax, eax на любую другую инструкцию, сбрасывающую флаг нуля. Так же он может модифицировать защитную функцию sub_401000, которая и осуществляет проверку пароля. Словом, тут много разных вариантов и на этом несчастном условном переходе свет клином не сошелся, а потому для надежного распознавания взлома нам потребуются дополнительные проверки. Впрочем, это уже детали. Главное, что мы определили смещение контролируемого байта. Кстати, а почему именно байта?! Ведь мы можем контролировать хоть целое двойное слово, расположенное по данному смещению! Особого смысла в этом нет, просто так проще.

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

Массив buf – это тот самый буфер, в который загружается оригинальный код программы для его последующей расшифровки (распаковки). Поверх массива накладываются две структуры: local_val, содержащая в себе локальные переменные, которые в процессе своей инициализации затирают соответствующие им ячейки buf'a и тем самым создают впечатление, что прежнее содержимое буфера стало теперь ненужным и более уже не используется. Количество локальных переменных может быть любым, главное – следить за тем, чтобы они не перекрывали контрольные точки программы, изменять содержимое которых нельзя. В приведенном выше примере, по соображениям наглядности, контрольные точки выне. сены в отдельную структуру code_control, два массива которой gag_1 и gag_2 используются лишь для того, чтобы переменные x_val_1 и x_val_2 были размещены компилятором по необходимым нам адресам. Как нетрудно долгаться: константа OFFSET_1 задает смещение первой контрольной точки, а OFFSET_2 – второй. Достоинство такой схемы заключается в том, что при добавлении или удалении локальных переменных в структуру local_var, структура code_contorl остается неизменной. Напротив, если объединить локальные переменные и контрольные точки одной общей крышей, то размеры массивов gag_1 и gag_2 станут зависеть от количества и размера используемых нами локальных переменных:

Код, выделенный жирным шрифтом, как раз и отвечает за то, чтобы размер массива.пустышки gag_1, компенсировал пространство, занятое локальными пе. ременными. Такая ручная "синхронизация" крайне ненадежна и служит источни. ком потенциальных ошибок. С другой стороны, теперь мы можем не беспокоить. ся, что локальные переменные случайно затрут контрольные точки, т. к. если такое произойдет, длина массива gag_1 станет отрицательной и компилятор тут же выска. жет нам все, что он о нас думает. Поэтому, окончательный выбор используемой конструкции остается за вами.

Теперь – пару слов о расшифровке (распаковке) нашей программы. Во.пер. вых, нет нужды расшифровывать всю программу целиком, – достаточно расши. фровать лишь сам защитный механизм, а то и его критическую часть. Причем, са. ма процедура расшифровки должна быть написано максимально просто и незамы. словато. Поверьте, лишние уровни защиты здесь совершенно ни к чему. Хакер все равно их вскроет за очень короткое время, и, самое главное, чем круче окажется за. щита, тем внимательнее будет вести себя хакер. Мы же, напротив, должны убедить его, что шифровка это – так, защита от детишек, и "настоящая" защита спрятана где-то совсем в другом месте (пусть ищет то, чего нет!).

Правда, тут есть одна проблема. По умолчанию Windows запрещает модификацию кодовой секции PE.файла и потому непосредственная расшифровка кода невозможна! Первая же попытка записи ячейки, принадлежащей секции .text, вызовет аварийное завершение программы. Можно, конечно, обхитрить Windows, создав свою собственную секцию, разрешающую операции чтения, исполнения и записи одновременно, или, как еще более изощренный вариант, исполнять расшифрованный код непосредственно в стеке, однако, мы пойдем другим путем и просто отключим защиту кодового сегмента от его непредумышленной модификации. Достоинство этого приема в том, что он очень просто реализуется, а недостаток – ослабление контроля за поведением программы. Если в результате тех или иных ошибок, наша программа пойдет в разнос и начнет затирать свой собственный код, операционная система будет бессильна ее остановить, поскольку мы сами отключили защиту! С другой стороны, в тщательно протестированной программе вероятность возникновения подобной ситуации исчезающе мала и в ряде случаев ею можно смело пренебречь. Во всяком случае, в примере, приведенном ниже, мы поступим именно так (речь ведь все равно идет не о технике расшифровке, а о неявном контроле за модификацией кода).

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

Теперь, разобравшись с расшифровкой, переходим к самому интересному – неявному контролю за критическими точками нашего защитного механизма. Пусть у нас имеется контрольная точка x_val_1, содержащая значение x_original_1, тогда для его неявной проверки можно "обвязать" некоторые вычислительные выражения следующим кодом: some_var = some_var + (x_val_1 – x_original_1). Если кон. трольная ячейка x_val_1 действительно содержит свое эталонное значение x_original_1, то разность двух этих чисел равна нулю, а добавление нуля к чему бы то ни было, никак не изменяет его значения. Грубо говоря, x_val_1 уравновешивается противоположным ему по знаку x_origial_1 и за это данный алгоритм называют "алгоритмом коромысла" или "алгоритмом весов". Можно ли быстро обнаружить такие "весы" беглым просмотром листинга программы? Не спешите отвечать "нет", поскольку правильный ответ – "да". Давайте рассуждать не как разработчики защитного механизма, а как хакеры: вот в процессе взлома мы изменили такие-то и такие.то ячейки программы, после чего она отказала в работе. Существует два "тупых" способа контроля своей целостности: контроль по адресам и контроль по содержимому. Для выявления первого хакер просто ищет адрес "хакнутой" им ячейки в коде программы. Если его нет (а в данном случае его и нет!), он предпринимает попытку обнаружить ее содержимое! А вот содержимое контролируемой ячейки в точности равно x_original_1 и тривиальный контекстный поиск за доли секунды выявит все вхождения! Чтобы этого не произошло и наша защита так просто не сдалась, следует либо уменьшить протяженность контролируемых точек до байта (байт – слишком короткая сигнатура для контекстного поиска), либо не хранить x_original_1 в прямом виде, а получать его на основе некоторых математических вычислений. Только не забываете, что оптимизирующие компиляторы все кон. стантные вычисления выполняют еще на стадии компиляции и: (#define x_orginal_1 0xBBBBBA; some_var += (x_val_1 – 1 – x_original_1);) на самом деле не усилит защиту! Поэтому, лучше вообще отказаться от алгоритма "весов", тем более, что он элементарно "вырезается" в случае его обнаружения. Надежнее изначально спроектировать алгоритм программы так, чтобы она осмысленно использовала x_original, а не уравновешивала его "противовесом". Приведенный ниже пример умышленно ослаблен в целях демонстрации как можно использовать эту уязвимость для облегчения взлома.

Исходный текст

Как это ломают?

Если все сделано правильно, то полученный исполняемый файл не рушиться при его запуске, а победоносно выводит на экран: "crackeme.0xh by Kris Kaspersky\nenter password:" и ждет ввода пароля. Договоримся не обращать внимание на пароль, прямым текстом хранящийся в программе и попробуем взломать защиту другим, более универсальным путем, а именно: изучением алгоритма ее работы под дизассемблером. Запускаем нашу любимую ИДУ и, дождавшись окончания процесса дизассемблирования, смотрим что у нас там. Ага, текстовые строки "passwd ok" и "wrong passwd" в сегменте данных действительно есть, но вот перекрестных ссылок, ведущих к коду, выводящему их, что-то не видно. Странно, ну да лиха беда начало! Запускам любой отладчик (например, WDB) и устанавливаем на адрес строки "wrong passwd" точку останова: "BA r4 407054". Даем команду "GO" для продолжения выполнения программы, вводим любой, пришедший нам на ум пароль, и… отладчик тут же всплывает, показывая адрес машинной команды, обращающейся к первому символу строки. Но что нам это дает? Ведь мы, судя по всему, находится в теле библиотечной функции out, осуществляющей вывод на консоль и в ее коде для нас нет ничего интересного. С другой стороны – эту функцию кто-то вызывает! Кто именно? Ну мало ли! Функция printf к примеру, код которой для нас ничуть не более интересен… Конечно, поднимаясь по цепочке вызовов вверх (окно call stack вам в помощь!), мы рано или поздно достигнем защитного кода, вызвавшего эту функцию, но вот как нам быстро определить где защитный код, а где библиотечные функции? Да очень просто! Та функция, один из аргументов которой представляет собой непосредственное смещение нашей строки, очевидно, и есть функция защитного кода! Последовательно щелкая мышкой по адресам возврата, перечисленных в окне "call stack", мы наконец находим:

Смещение, выделенное жирным шрифтом, – есть ни что иное, как смещение искомой строки, соответственно, адрес 0x40106E (так же выделенный жирным шрифтом) лежит где-то в гуще защитного кода. А ну-ка, глянем сюда дизассемблером – чего это вдруг ИДА не создала перекрестную ссылку к строке?

Вот это номер! Она вообще не посчитала это за код, объявив его массивом! Хорошо, заставим ее дизассемблировать этот фрагмент вручную. Переместив курсор к самому началу массива, нажимаем <U> для его удаления, а затем <C> для превращения байтовой цепочки в код.

Хм! Что за ерунда у нас получается?! Вновь переключившись на отладчик, мы убеждаемся, что тот же самый код в нем выглядит вполне нормально:

Такое впечатление, что защитный механизм зашифрован… А почему бы в самом деле и нет? Возвращаясь к дизассемблеру, щелкаем по перекрестной ссылке и видим:

Теперь, когда алгоритм расшифровки установлен (см. выделенную жирным шрифтом строку), мы можем самостоятельно расшифровать его. Для этого нажимаем <F2> в окне IDA и вводим следующий скрипт:

Нажав <Ctrl.Enter> для его выполнения, мы становится свидетелями успешной расшифровки кода защитного механизма. Теперь с ним можно беспрепятственно работать без всяких преград. Кстати, посмотрим, создала ли IDA перекрестные ссылки к строкам "passwd ok" и "wrong passwd"…

Держи нас за хвост! Перекрестные ссылки действительно созданы и ведут к приведенному выше коду, который слишком прост, чтобы его комментировать. Смотрите: подпрограмма loc_40106E, выводящая надпись "wrong passwd" на экран и прерывающая выполнение программы вызовом функции _exit, имеет перекрестную ссылку, sub_401050+7, ведущую к условному переходу jz short loc_401064 (в листинге он выделен жирным шрифтом), который, судя по всему, и есть тот самый условный переход, что нам нужен! Забив его машинными командами NOP, мы, очевидно, добьемся того, что защита перестанет "ругаться" на неверные пароли и любой введенный пароль воспримет как правильный.

Ну что, запустим HIEW и запишем по адресу .401057 последовательность "90h 90h"? Не спешите, не все так просто! Ведь исходная программа зашифрована и записанные нами команды NOP после расшифровки превратятся неизвестно во что. Какой из этого выход? Да очень простой: записав последовательность 90h 90h в HIEW'е мы тем же самым HIEW'ом ее и зашифруем! ОК, приступаем. Итак, <Enter> для перевода HIEW'a в hex.режим, <F5> и ".401057" для перехода по требуемому адресу, <F3> для входа в режим редактирования, 90, 90 – забивает условный переход, <Left Arrow> (четыре раза) для перемещения курсора на начало редактируемого фрагмента, <F8>, <"66"> и еще раз <F8> для шифровки. Наконец, <F9> для сохранения внесенных изменений.

Победно запускаем взломанный файл и…

…и тут выясняется, что защита отнюдь не так непроходима тупа, как нам это показалось вначале! Судя по надписи она как.то контролирует целостность своего кода и прекращает работу в случае его изменения. Что ж! Открываем очередное пиво и продолжаем взлом. Можно поступить двояко: или поискать перекрестную ссылку на строку ".ERR: invalid CRC" или же установить контрольную точку на модифицированный нами условный переход. Кинем монетку, если выпадет орел – ищем перекрестную ссылку, ну а если монета упадет решкой – используем контрольную точку. Так, а где у нас монетка? Нету монетки?! Ну тогда, как истинные хакеры, мы быстренько пишем собственный генератор случайных чисел и… решка! (Если у вас выпал орел, значит, нам с вами не по пути).

Отладчик WDB сообщает, что сработала контрольная точка останова. Пропускаем ее, – это защита копирует код программы в локальный буфер для его последующей расшифровки (это следует из того, что мы всплыли на инструкции movs). Следующее всплытие отладчика соответствует обратной операции – копированию уже расшифрованного кода на место постоянного проживания. А вот третье по счету всплытие уже интересно:

Тривиальный алгоритм подсчета контрольной суммы буквально сам броса. ется в глаза. "Или автор защиты полный идиот, или же он специально хотел быть обнаруженным" – ворчим мы себе под нос, попутно размышляя, что лучше: скорректировать контрольную сумму или же просто заменить условный переход в строке 0x40111E на безусловный, так чтобы он вообще не контролировал свою целостность? Ладно, будем приучать себя к аккуратности. Подгоняем курсор к строке 0x401118 и даем команду "Run to cursor", не забыв предварительно заблокировать установленную точку останова (иначе отладчик просто зациклиться) и смотрим: какое значение содержит в себе регистр EBX. Как следует из окна "Registers" оно равно 0xd7988417, в то время как оригинальная контрольная сумма защищенного файла была – 0x4000EC80 (см. строку 0x401118 приведенного выше листинга). Запускаем HIEW и переписываем ее по живому, меняя "cmp ebx, 4000EC80h" на "cmp ebx, 0xd7988417". Проверяем! wow! Это работает! Выломанный файл успешно запускается и, молчаливо проглотив любой введенный пароль, смиренно сообщает "passwd ok" и продолжает нормальное выполнение программы. Обмыв это дело на радостях двойным количеством пива, хакер раздает выломанную программу всем, нуждающимся в ней пользователям и…

…в процессе эксплуатации взломанной программы выясняется, что ведет она себя мягко выражаясь не совсем адекватно. В частности, в нашем случае она выводит на экран: "2 * 2 = 34280". Вот это номер! Поскольку доверять такому взлому со всей очевидностью нельзя, лучше всего не испытывать судьбу, а приобрести легальную копию программы (особенно, если дело касается бухгалтерского ПО, ошибки которого зачастую несопоставимы с его стоимостью). Но все-таки, хотя бы в плане спортивного интереса, – можно ли взломать такую программу или нет? Условимся, что мы не будем анализировать код, вычисляющий дважды два, поскольку в реальном, полновесном приложении очень легко добиться, чтобы ошибка проявлялась не в месте ее возникновения, а в совсем другой ветке программы, делая тем самым обратную трассировку невозможной.

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

Сказано – сделано. Ищем… Быстро выясняется, что ничего похожего на смещение модифицированного нами перехода в защищенной программе нет, но вот его оригинальное содержимое на наше удивление все.таки обнаруживается:

Мало того! Рядом с ним валяется указатель 0x57, который "волшебным" образом совпадает с относительным смещением модифицированного нами байта, отсчитываемого от начала тела первой зашифрованной процедуры (развитие зрительной памяти невероятно ускоряет взлом программ). Так вот ты какой, северный олень! Буквально за одну-две секунды мы вышли на след защитного кода, который по замыслу автора мы ни за что не должны были обнаружить! А обнаружили мы его только "благодаря" тому обстоятельству, что и смещение, и содержимое контрольной точки хранилось в программе в открытом виде. Вот если бы оно вычислялось на лету на основе запутанных математических операций… впрочем, не будет повторяться, мы об этом уже говорили.

Хорошо, условимся считать, что поиск по содержимому не дал результатов и хакер остался с защитой один на один. Что он еще может предпринять? А вот что – аппаратная точка останова на модифицированный байт! Да, конечно, мы уже устанавливали ее, но ранее слишком быстро отсекали "лишние" срабатывания. Теперь же настало время заняться этим вопросом вплотную. Вновь запустив порядком затосковавший за это время WDB, мы даем ему уже знакомую команду "ba r4 0x401057" (не обязательно набивать ее на клавиатуре, достаточно лишь нажать стрелку вверх и отладчик сам извлечет ее из истории команд). Первое срабатывание приходится на следующий код:

Узнаете? Ну да, были мы здесь недавно и все тщательно проанализировали, так и не обнаружив ничего интересного. Идем дальше? Стоп! А точку останова на буфер.приемник кто будет ставить? ОК, отдаем отладчику следующую команду: "ba r4 (edi.4)". Почему (edi.4)? Так ведь точки останова срабатывают после выполнения соответствующей им команды, т. е. на момент всплытия отладчика, регистр EDI указывает на следующее двойное слово, а совсем не на то, которые содержит только что скопированный в буфер код.

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

Конечно, в данном демонстрационном примере алгоритм "балансировки" распознается без особого труда и серьезных умственных усилий, но как бы там ни было, аппаратные точки останова позволили выявить тот самый код, что осуществляет неявный контроль целостности защиты. Кстати, аппаратных контрольных точек всего четыре, а количество буферов, в которые можно запихать "клоны" копий оригинального кода программы – не ограничено много. Словом, если чуть-чуть постараться, можно очень сильно умерять хакерский пыл – за всеми буферами так просто не уследить, придется анализировать огромное количество кода, лишь часть из которого непосредственно относится к защитному механизму, а все остальное – мусор. Чтобы еще больше запутать хакера можно осуществлять неявный контроль целостности не при каждом запуске программы, а, скажем, на осно. ве датчика случайных чисел, – один раз, эдак, из десяти. "Плавающая" защита – что может быть хуже?! Да, теоретически можно и ее сломать, но: во-первых, даже трудно себе представить сколько на нее придется угробить времени, а, во-вторых, никто не даст и кончика хвоста на отсечение, что выявлены и нейтрализованы все уровни защиты. Ведь аппаратные точки срабатывают лишь в момент обращения к ним, а дизассемблирование бессильно выявить адреса, получаемые на основе сложных математических манипуляций с указателями.

Но все-таки давайте доломаем нашу защиту. В данном конкретном случае мы можем нейтрализовать защитный механизм, просто заменив команду xor ecx, 48681574h на xor ecx, 48689090h, т. е. просто скорректировав "балансир". Однако, при взломе реальной программы хакер должен убедиться, что корректируемый им балансир и не балансирует что-то еще.

Что же представлят собой этот самый плагин? А представляет он собой, как ни странно, обычную DLL, у которой экспортируется следующая структура под именем PLUGIN:

PLUGIN_MOD - Установка этого флага значит, что плагин меняет базу с листингом.(Честно говоря мало плагинов, которые её не меняют). Ставиться этот флаг затем, что если в модуле процессора(здесь не рассматривается) запрещается изменять базу, то плагин нельзя будет использовать. В общем в модуле x86 всё разрешается, вообще этот флаг нам не нужен, ровно как и остальные.

PLUGIN_DRAW - Установка этого флага указывает IDA на то, что после вызова плагина надо перерисовать(т.е. обновить) своё окно.

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

PLUGIN_UNL - Если установить этот флаг, то после использования плагин будет выгружаться из памяти. Это конечно хорошо для отладки, но нам не очень подходит.

Так как это флаги, то их можно комбинировать с помощью логического или(or по нашему или | в языке С), а также через простое сложение. Но проще, как я уже говорил, заполнить это поле красивым словом NULL.

Вообще то в include файле loader.hpp эта структура объявлена как класс, но для тех, кто не знает, скажу, что в C++ класс и структура в сущности одно и тоже.Ну вроде как настало время и исходник привести. Я привожу здесь простейший плагин, который в базе будет менять следующие бесполезные группы инструкций:

на "более понятные" инструкции nop. Вот и исходник:

В зависимости от возвращаемого значения IDA может загрузить и не загрузить плагин. Вот, что она может возвращать

PLUGIN_SKIP - Плагин не будет загружен.

PLUGIN_OK - Ну раз OK, то есстественно плагин будет загружен.

PLUGIN_KEEP - Плагин не только будет загружен, но и будет постоянно висеть в памяти

К примеру, чтобы плагин работал только с файлами PE формата, надо в процедуру инициализации прописать следующий код:

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

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

get_byte

get_word

get_long - Чтение байтов из базы. Принимают один параметр - адрес, который отображается в листинге.

patch_byte

patch_word

patch_long - Ну соответственно запись байтов в базу. Параметров два, первый параметр - адрес, второй - значение

Как можно догадаться, функции, у которых на конце написано byte работают(т.е. принимают и возвращают) байт, word - слово, а long - двойное слово.

get_screen_ea - Функция для получения текущего адреса, который она и возвращает.

Теперь посмотрим, как его надо компилировать. Вот bat файл:

Как я уже говорил, пример для Intel C++, если у вас VC++, то исходник менять не надо, а командную строку для компиляции придёться переделать (просто-напросто замените icl на cl). Теперь поподробнее.

-Gz говорит интеловскому компилятору, что передача параметров в функции по умолчанию будет stdcall.

/I - Путь к include директории IDA SDK.

plugin.cpp - исходник с плагином.

ida.lib - библиотека импорта из SDK, должна быть в одной папке с исходником.

После параметра /link идут опции линкера, комментировать нет необходимости. Кроме def-файла. Раз уж здесь есть исходник и bat-файл, то уж придёться приводить и def- файл.

Т.е def файл указывает, что надо экспортировать структуру PLUGIN. В общем теперь всё, плагин готов к использованию, осталось лишь добавить его в IDA. Для начала неплохо бы скопировать его в папку с plugins, которая находится в папке с IDA. Но этого мало, надо ещё его сконфигурировать. Вся конфигурация плагинов храниться в файле plugins.cfg в той же папке plugins. Обычно вначале этого файла идут комментарии, а в конце записи уже установленных плагинов. Чтобы добавить наш exp.plw(плагины для работы под Windows имеют расширение plw), надо добавить в конец файла четыре параметра в следующем порядке:

Аргумент этот передаётся в функцию run, лично мне кажеться, что толку от него никакого, поэтому установим его в 0. Горячую клавишу можно установить F11, вроде как она не используется IDA. Значит добавляемая нами строчка должна выглядеть так:

Точку с запятой впереди ставить не рекомендую, т.к. это комментарий. Ну в общем можно считать, что работа закончена. Осталось только запустить IDA, открыть какой-нибудь файл, где встречаются инструкции, которые наш плагин обрабатывает(например можно самому быстренько на асме написать и скомпилировать), и проверить. Если всё сделано правильно, то при нажатии F11 или вызова плагина через меню, инструкции должны заменяться nop'ами. Разумеется курсор должен стоять на начале этих scrambled инструкций, если их можно так назвать, всё-таки это мусорные инструкции. Вот собственно и всё.

Сорецензенты:

Four-F/HI-TECH , Quantum , Sten , Fixer

2. Вместо введения

3. Как Windows работает с секциями PE-файла

4. А запакован ли файл?

5. Тонкости PE-формата

6. OEP и иже с ним

7. Дампер процессов

8. Практический пример: UPX

9. Практический пример: Aspack

10. SEH с точки зрения кракера

11. Немного об антиотладке – в преддверии telock

12. Практический пример: teLock

13. Список литературы

14. Выводы...

Итак, мы продолжаем. Подразумевается, что вы ознакомились с первой частью статьи и теперь владеете минимумом теории. Однако мы еще более повышаем требования. Теперь, для успешного и полного понимания SEH (Structured Exception Handling) и некоторых приемов, тут продемонстрированных, вам придется иметь базовое представление о С++. Мы не будем особо далеко лезть в дебри родовых классов, виртуальных функций и т.п., но самые основы OOП , такие как наследование, вам необходимо (по крайней мере, желательно!) знать.

Предполагается, также, что вы имеете джентльменский набор знаний по защищенному режиму - т.е. знаете, что такое IDT/GDT/PDE/PTE и прочие страшные аббревиатуры.

Кроме того, вам придется хлебнуть информации о недрах Windows для чего ОЧЕНЬ предлагается прочесть какую-нибудь хорошую книжку по системному программированию под Windows – например, Марка Руссиновича или Свена Шрайбера (список рекомендуемой литературы в конце статьи). Также по ходу дела мы постараемся давать линки на статьи (к сожалению, подавляющая масса литературы подобного характера на английском языке, на русском тоже что-то есть, но не слишком много).

Как вы уже, должно быть, догадались, все статьи этого цикла будут напирать на теорию. Мы предпочтем рассмотреть вопрос "почему", а не вопрос "как". Обязательно учтите, что здесь мы не рассматриваем 9x!

Практические примеры требуют воспроизводимости. Это означает, что вы должны иметь возможность воспроизвести примеры, показанные здесь, т.к. возможны недопонимания и все следует проверять практически. Во всех примерах упаковщиков используется один-единственный файл – calc.exe из поставки Windows 2000.

написано совместно с Four-F

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

Известно, что процессоры Intel предлагают операционной системе 4 кольца защиты, из которых Windows использует только два - кольцо-0 и кольцо-3. Часть структур, сопровождающих программу, создается операционной системой в режиме ядра (ring-0) и программе ring-3 они недоступны. Другая часть создается в кольце-3 и, теоретически, доступна программе, однако документация отсутствует, примеров кода нет, словом MS постаралась, чтобы мы знали как можно меньше о внутренностях операционной системы.

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

Символы отладки и эталонный отладчик

Если вам в силу тех или иных причин необходимо исследовать Windows, то сразу же возникает необходимость в настройке среды для работы. Очевидно, одного джентельменского набора из IDA/Soft-Ice/HIEW/IceExt и дампера процессов 3-кольца типа PE Tools тут уже недостаточно. Это шаг выше. Поэтому вам потребуется обзавестись символами отладки, которые можно сгрузить с сайта MS по этому адресу: http://www.microsoft.com/whdc/ddk/debugging/symbolpkg.mspx установить и корректно настроить их. Обязательно учтите – символы должны ТОЧНО соответствовать вашей ОС и установленному SP. Для этого лучше использовать технологии MS. NuMega Symbol Retriever показал себя нестабильно работающей утилитой. Поэтому не поленитесь, если есть такая возможность, сгрузить файлы ручками, прогнать их через NMS-транслятор и проверить командной table, все ли у нас в порядке. Кстати, если по каким-то, одним разработчикам понятным причинам, Soft-Ice ну никак не желает откликаться на bpx, возможно, установка nms-символов на ntoskrnl сможет помочь. IDA, включая версию 4.5, невероятно глючно накладывает информацию из pdb файла на свою базу, поэтому соизвольте сгрузить либо с сайта datarescue, либо с wasm.ru изумительный и очень шустрый плагин - PDB Plus. Показал себя безукоризненно. Было бы неплохо также иметь какую-то утилиту, способную извлекать информацию из PDB-файла. Есть и такие – pdbdump – http://sourceforge.net/projects/pdbdump. Просто удивительно, сколько полезной информации можно извлечь из PDB. Нам с вами еще не раз предстоит в этом убедится на протяжении статьи. Наиболее полезный файл из всех – ntosrknlsym.pdb. Следующая потенциальная проблема – это выбор отладчика, который был бы способен показывать внутренности ОС с достаточно большой степенью достоверности. Разумеется, нативный отладчик должен лучше понимать "свою" ОС, чем это делают все остальные. Разработчики Soft-Ice не раз подчеркивали, что все структуры реверсированы, а это не всегда самый надежный способ. Поэтому эталонным отладчиком можно смело считать отладчик самой MS – MS kd. MS kd тоже не идеален и грешит сокрытием информации (например, об объектах - проблема была описана Шрайбером, который предложил и решение для некоторых частных случаев), но это лучше, чем подавляющее большинство утилит. Известно, что kd требует установки двух машин, соединенных между собой. Марк Руссинович разработал утилиту LiveKd (доступна на sysinternals.com и wasm.ru), которая позволяет запускать kd на одной и той же машине. Для отладки, разумеется, можно и нужно применять Soft-Ice, однако, когда возникает необходимость подглядеть какую-то структуру или адрес функции - лучше kd нет ничего (кроме, ессно, ручек и дизассемблера). kd доступен по адресу: http://www.microsoft.com/whdc/ddk/debugging/default.mspx Установка не должна вызвать проблем. Поместите LiveKd в ту же директорию, программа все сделает сама.

Очень важными структурами пользовательского режима являются TIB , TEB и PEB . Последний мы в этой статье затрагивать не будем, а касательно двух первых - Thread Environment Blockи Thread Information Block - необходимо развеять кое-какую путаницу. Здесь мы хотели бы вам сказать, что читать НЕ стоит! Не стоит читать статью Питрека - http://www.microsoft.com/msj/archive/S2CE.aspx и главы «Обработка исключений в реальном и защищенном режимах», «Как противостоять трассировке» и «Как противостоять контрольным точкам останова» и «Как обнаружить отладку средствами Windows» из книги Криса Касперски «Фундаментальные основы хакерства». Почему так? По поводу статьи Питрека – уж слишком она устарела. По поводу Касперски – автор не озаботился проверить, а соответствует ли то, что он написал, действительности, дочитайте данную статью до конца и станет ясно почему. Теперь выдержка из статьи Питрека: "The Windows 95 code calls it a Thread Information Block ( TIB ). In Windows NT, it's called the Thread Environment Block ( TEB )." Утверждение неверно. Структура TIB существует и в Windows NT+ и называется NT_TIB (полностью документирована вwinnt.h), а структура TEB(недокументирована) включает в себя структуру TIB , т.е. является ее надмножеством. Где-то так (заметьте, полные описания структур мы не приводим, для этого есть исходники к книге Шрайбера на wasm.ru и исходный код ReactOS – ссылки в конце статьи):

Ну, поскольку, рисунок всегда нагляднее, вот:

А если и рисунка мало, тогда смотрите на дамп из kd :

А теперь глянем в Шрайбера (w2k_def.h) касательно PEB. Оговоримся сразу – нас не интересует большинство полей, глянем только на два:

Теперь ReactOS (teb.h):

Видите, структуры различаются. Кто же прав? Ответ нам даст kd :

Но даже более того! Не стоит полностью доверять и kd. То, что он показывает – верно на 100%, но есть одно маленькое но – он показывает НЕ ВСЕ. Часть структур просто скромно умалчивается. Однако есть одна вещь, которая никогда не солжет – дамп pdb -файла. Мы уже упоминали о pdbdump – давайте им и воспользуемся (не забудьте слить MS DIA SDK с wasm.ru или обзавестись Visual Studio .NET 2002+):

Уходим еще глубже - в двусвязные списки LIST_ENTRY. Структура определена в winnt.h как

Указатели, в нашем случае, показывают на структуру LDR_DATA_TABLE_ENTRY :

Для чего мы заставляем вас проходить через это? Смотрите на код, он теперь должен иметь немного больше смысла:

Потрассируйте такой код и посмотрите в LordPe , что он вам покажет в поле SizeOfImage... Посмотрели? Угадайте, что будет, если дампер будет пробовать читать память, которой НЕТ? А теперь прогоните через PE Tools … Ну как результат?

Обратите внимание, что структура TEB (и входящая в нее структура TIB) создается Windows для каждого потока в момент его порождения и "сопровождает" поток до прекращения выполнения. Структура эта в кольце-3 доступна через регистр fs. Обратите внимание - мы говорим в кольце-3, т.к. содержимое, доступное через fs , РАЗЛИЧАЕТСЯ в ring-3 и ring-0. Почему так – ответ вы найдете в GDT. К Soft-Ice прилагается шикарная книженция – “Using Soft-Ice”. Есть там и глава – «Exploring Windows NT” где рассматривается, что куда и как отображается, и приведен примерчик.

В остальной части этой статьи мы будем употреблять термин "TEB " только тогда, когда смещение в fs -регистре превысит размер структуры TIB. Пример из книги Джона Роббинса "Отладка приложений": "реализация GetCurrentThreadId (из Windows 2000) получает сначала линейный адрес TIB -блока и затем, в позиции со смещением 0х24 (в TIB -блоке) - фактический идентификатор (ID) потока". Нет такого смещения в TIB -структуре! Нет и не было никогда. А вот в TEB - есть. Удивительно, как много пользы от таких простых знаний. Положим, вас заинтересовала работа функций GetCurrentThreadId , GetLastError и IsDebuggerPresent :

Продолжаем. Следующее, что мы рассмотрим здесь - это интерфейс 2Eh и таблицы системных вызовов. Мы попытаемся отследить путь вызова процедуры вплоть до ядра Windows. За теорией - к Руссиновичу. Не имеете возможность купить эту книгу - вот линк на статью по теме http://www.sysinternals.com/ntw2k/info/ntdll.shtml. Обязательно учтите, что int 2E в XP+ отсутствует! Вместо этого используется команда sysenter.

Итак, мы предполагаем - вам известно, что такое Native API. Когда, скажем, вызывается функция kernel32.dll CreateFile, что происходит потом? Управление передается в ntdll.dll, где имеем код вида:

Что происходит потом, когда выполняется int 2Eh? Поскольку это прерывание, то оно имеет свой обработчик в IDT. Обратите внимание - все функции ntdll.dll , обращающиеся к ядру, используют int 2E (в Win 2k, в XP+ используется специальная команда PII+ sysenter). Как же обработчик определяет, что делать дальше? Для этого полезем в Soft-Ice :

Т.о. обработчик называется _KiSystemService и сидит в ntoskrnl.exe. Дальше имело бы смысл привести дизассемблированный листинг этой функции, но все это уже сделано за нас - Peter Kosyh в своем замечательном сборничке очень подробно расписал что к чему - сборничек можно слить с wasm.ru. Глава - "Интерфейс системных вызовов". Там предельно подробно рассказывается, как обработчик находит нужную функцию. Единственное что, имеет смысл привести описания структур SDT /SST , в которых обработчик ее ищет, и рисуночек:

Для чего мы все это вам рассказываем? Положим, вас жутко заинтересовал механизм работы NtCreateSection (ZwCreateSection). Никаких проблем. Вы идете в ntdll.dll и находите ее вызов. Хм... Он скатывается к int 2Eh... Что дальше? Ладно, в этом случае все просто - функция экспортируется ядром - ntoskrnl.exe , следовательно, ничто не мешает прийти с дизассемблером и туда. А что вы скажете по поводу NtContinue (в eax - 1Ch)? Точно также - int 2Eh. А вот в таблице экспорта ядра такой функции нет. Тупик? Нет. Используя знания о структуре SDT можно легко отследить место расположения NtContinue в ядре, а затем найти эту функцию в ntoskrnl.exe на диске. Примерно так:

Все, описанное выше, можно сделать еще проще. Разумеется, такой мощный инструмент как Soft-Ice имеет средство для просмотра SDT - это команда ntcall (обязательно учтите, что ntcall покажет только функции, принадлежащие ntoskrnl). Единственное что, использование таких команд освобождает от необходимости знать некоторые тонкости работы, что не всегда хорошо, т.к., к примеру, SST может быть использована для антиотладочных процедур почти на самом низком из всех возможных уровней (ниже - только драйвер). Пример - статья Тима Роббинса (Tim Robbins) - http://www.wiretapped.net/~fyre/sst.html.

Также очень неплохо было бы ознакомится с

http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID=356 - Undocumented Windows NT - очень сильная книжка, хотя немного и устарела. Возможно, имеет смысл скомпоновать ее главы в виде .chm-формата и поместить на wasm.

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

Мы уже упоминали, что содержимое, доступное через fs , различно для ring-0 и ring-3. Как вы теперь понимаете, в ring-3 fs:[0] показывает на структуру TEB. А что же мы видим, к примеру, в этом случае в кольце-0:

На что показывает fs:124h при DPL = 0? На что показывает fs:0 при DPL = 0? Все это подробнейшим образом описывает Шрайбер - его книга действительно великолепна. Мы здесь описания структур приводить не будем, достаточно слить некоторые файлы из раздела инструментов на wasm.ru и обзавестить DDK. Однако, предельно кратко, в виде рисунка, показать некоторые вещи стоит. Так нагляднее:

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

Помните, что Windows отображает адрес 0xFFDFF000 на fs:[0] (гляньте в GDT!). К примеру, по fs:[50] будет лежать KPCR.DebugActive , по fs:[120] - KPRCB (0xFFDFF020), по fs:[13C] - структура CONTEXT. Единственное, что может смутить - по 0xFFDFF020 лежит указатель на KPRCB , значение которого равно 0xFFDFF120:

Еще, вероятно, вас может смутить поле NT_TIB в составе KPCR. Как же так – ведь структура NT_TIB принадлежит кольцу-3! А вот и не совсем так. И кольцо-0 и кольцо-3 владеют каждый по NT_TIB – по одной на брата. Т.о. и в кольце-0 и в кольце-3 fs:[0] показывает на TIB , только в первом случае TIB входит в KPCR и ни о каком TEB речи нет, а вот во втором случае TIB входит в TEB. Вот вам и дамп из kd в доказательство:

Учитывайте эти нюансы и все будет ОК.

Очень многое осталось за бортом этого, предельно короткого, обзора. Однако для успешного понимания оставшейся части статьи этого более чем достаточно, при условии, что все понято. Если нет - Руссинович и Шрайбер. Особенно Шрайбер! Только читая его, обязательно учитывайте ГОД написания книги. Например, цитата: "Внутреннее строение структур WIN32_PROCESS и WIN32_THREAD - это еще одна пока что непознанная область Windows 2000, исследовать которую только предстоит ". Уже не совсем так. У Шрайбера код выглядит так:

А теперь посмотрите, СКОЛЬКО информации нам дает pdbdump , написанный позже:

Мы надеемся, что это достаточно эффектный пример. Soft-Ice может использовать свои имена (чего только стоят названия KTEB и UTEB – кого угодно запутать можно), kd может скрыть часть информации (введите команду !processfields и посмотрите как мало она дает), кода ReactOS , временами, выдают ТАКОЕ... Мы можем доверять лишь pdb -файлу и дизассемблеру. Не верьте именам структур, если они недокументрованы – любой их назовет как угодно, придерживайтесь имен самой MS – pdb -файлы не соврут.

Ну, а если вы истинный, то есть, ленивый (это синонимы) программист, то уже должны думать про себя: «Неужели мне, каждый раз, когда я вижу ebx+134h , придется каждый раз делать такие комментарии в IDA (да, кстати, недокументированные функции полностью отсутствуют в этом дизассемблере!)?». Ну, разумеется, нет! Все уже сделано за вас. Озаботьтесь загрузить себе idc -скрипты, описывающие некоторые структуры нулевого кольца с http://www.alkor.ru/~00077500/kb/winnt.htm или, как всегда, с wasm.ru (в последнем случае картина более полная, т.к. Four-F создал замечательный здоровенный idc-скрипт).

Ничто также не мешает вам самим перевести .h файлы в idc -скрипты. Частично проблема решена Леонидом Лисовским (Leonid Lisovsky) в его скрипте h2enum (слить с сайта datarescue), однако более разумным кажется приспособить готовый лексический анализатор для этих целей, к примеру, lex , совместить его с перловским скриптом, который будет подставлять нужные функции IDA и все. Почитать о lex и yacc можно, например, тут: http://www.codeproject.com/cpp/introlexyacc.asp. Хм. Добровольцы?

Также обязательно ознакомьтесь с набором команд IceExt (скачать с http://stenri.pisem.net либо с wasm.ru) – уникальный плагин для Soft-Ice, способный не только выполнять анти-антиотладку, но, к примеру, могущий также показать список PTE , содержание теневой SDT и т.п.

Мы довольно прилично осознаем, что от такого введения недолго и в обморок упасть. Поэтому не торопитесь. Вы, должно быть, уже сообразили, что эту статью нельзя прочесть с наскока – это не бульварное чтиво. В помощь при разборе ассемблерщики пусть возьмут себе уникальный KmdKit by Four-F и внимательно разберутся с файлом w2kundoc.inc. Программисты на С пусть возьмут основательно подправленный Volodya файл Шрайбера w2k_def.h. Оба доступны с wasm.

написано совместно с Four-F

В первой части мы представили и должным образом дополнили работу Rustell Osterlund о работе ntdll.dll и тех проверках на валидность PE -файла, которые она выполняет. Теперь пришло время двинуться дальше и рассмотреть, какие ограничения на формат накладывает само ядро Windows. Это означает, что придется идти глубоко – в ntoskrnl.exe. В принципе, новички могут пропустить эту главу, так как она способна запросто привести в ужас кого угодно, кроме самих создателей Windows. Единственное что – в самом ее конце мы описываем практическое использование полученных знаний и реализацию оных в PE Tools.

Продвинутые читатели наверняка знают некоторые подробности об объектах Windows, поэтому смягчать выражения мы особо не будем. Единственный объект, который нас интересует – это объект «секция». Объект полностью недокументирован. Лишь в главе 7 книги Руссиновича есть легкое упоминание о такой вещи и симпатичный рисуночек.

Итак, объект "секция" не стоит путать с термином "секция" из PE-файла, это вовсе не одно и тоже. Section object создается в ЕДИНСТВЕННОМ экземпляре на файл. Доказательство: функция NtCreateSection, вызывается ОДИН раз - в коде лоадера (ntdll.dll) из LdrpCreateDllSection (эта, в свою очередь, из LdrpMapDll), и в коде CreateProcess также единожды, в последовательности:

Подробнее – Петр Косых aka gloomy. Материалы можно слить с wasm.ru. Кода ReactOS , довольно часто упоминаемые нами в этой статье, по данному поводу можно просто выбросить – там чушь. NtCreateSection является лишь тонкой прослойкой вокруг MmCreateSection , которая и выполняет всю работу по заполнению объекта «секция», работе с PTE , а, точнее, с гиперпространством, проверке валидности, переводу флагов PE-секций в атрибуты структур SUBSECTION (см. ниже) через хитрые массивы ядра и т.п. Внутри MmCreateSection могут вызываться три функции:

Сначала вызывается MiCreatePagingFileMap. Далее, Windows на основании флагов из структуры CONTROL_AREA (см. рисунок ниже) решает как ей быть дальше – либо работать с файлом как с данными через MiCreateDataFileMap , либо как с исполняемым файлом через MiCreateImageFileMap , принимающей указатель на FILE_OBJECT. Весь процесс этот достаточно сложный, но, быть может, этот рисунок поможет немного разобраться (маленько улучшенная копия оного из книги Соломона-Руссиновича):

Все семейство Mi*-функций, активно используемых в Mm-функциях, невероятно интересно. Однако целиком мы его рассматривать не будем. Внутри MiCreateImageFileMap заголовок PE-файла (ТОЛЬКО заголовок) безусловно отображается на гиперпространство по адресу 0x0С050000 (mov eax, 0C0500000h) функцией MiMapImageHeaderInHyperSpace (в функцию жестко зашито значение для отображения). После этого отображенный заголовок принимаются активно проверять – функция MiVerifyImageHeader. А вот эта функция уже безусловно интерестна для нас с вами:

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

Для вступления этого вполне достаточно. С оставшейся частью, при большом желании, наличии времени и обладании DDK и интернетом, расправиться не так уж и сложно. Код, правда, насыщен функциями для работы с IRQL и спин-блокировками, однако Соломон и Руссинович достаточно подробно осветили этот вопрос. Также рекомендуем почитать статью Matt - http://www.tuningsoft.com/documents/irql.htm - « Understanding IRQL ». Заметьте, MiVerifyImageHeader не единственное место, где MiCreateImageFileMap решает валиден ли образ или нет, однако оставшийся код активно оперирует с гиперпространством, что выводит обсуждение этого вопроса далеко за рамки данной статьи. И соваться туда стоит не раньше, чем прочтете (как следует!) главы Руссиновича о памяти, и всю доступную литературу о PTE /PDE /PFN.

Что до практического применения полученных знаний - NtCreateSection будет использоваться в качестве проверки валидности PE-файла в PE Tools (вероятно, с версии 1.6). Опция - "Validate PE". Псевдокод может выглядеть где-то так:

Если NtCreateSection вернула что-либо отличное от нуля – файл валидным не является – это невероятно надежный источник проверки валидности файла! Если неуверенно себя чувствуете с нативными приложениями (т.е. программами, использующими ntdll.dll напрямую с помощью статической линковки, или динамически, через GetProcAddress), то вот замечательный линк: http://www.osr.com/ntinsider/1996/native.htm

написано совместно с Fixer

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

Энтропия

Боже, как только это слово в термодинамике не обругали. И мера порядка системы, и мера рассеивания энергии, уж чего только там не было! Без сомнения, настоящего физика от нашего определения покоробит, а настоящий математик искренне возмутится. Тем не менее, по дилетантски определим слово "энтропия" как некоторую меру эффективности хранения информации. Для иллюстрирования понятия продемонстрируем следующий пример. Условимся считать файл всего лишь строкой байт, конец которой определяется каким-то загадочным образом самой операционной системой. Положим, у нас есть строка: abcdcdaad Подсчитаем количество вхождений каждого байта. Вот так: Таким образом, мы можем сказать, что частота (т.е. вероятность - мы лезем в статистику) появления данного байта в этой конкретной последовательности составляет: где 9 - общая длина последовательности. Определим теперь энтропию каждого символа по формуле: где log2 - логарифм по основанию 2. Таким образом, имеем: Просуммировав сумму всех энтропий, получаем: Теоретически, это означает, что данную строку мы могли бы хранить в компьютерной памяти, используя лишь 17 бит информации. Реально же используется 72 - т.е. символов у нас 9, каждый символ - это байт, а байт - 8 бит. Итого 72 = 8*9. Остается сделать последний штрих - подсчитать остаток от деления общего количества бит на "энтропийные" биты (72/17 = 4,23). Выполнив его, мы увидим, что эффективность хранения информации невысока - фактически, имеем разницу в ЧЕТЫРЕ раза. Отношение к упаковке это имеет самое прямое. Когда секция кода файла сжата, то суммарная энтропия при подсчете возрастет, т.е. приблизится к стандартной сумме всех бит - это будет говорить о повышенной эффективности хранения информации, т.е. возможном сжатии секции кода (остаток от деления уменьшится).

Алгоритм может выглядеть так:

Данный кусочек кода был любезно предоставлен Manuel Jimenez - автором BDASM (www.bdasm.com) - очень перспективного и быстрого дизассемблера, из которого в будущем может получится достойный соперник IDA! Разумеется, код нельзя просто скомпилировать, однако общий подход он даст.

А особо любознательным расскажем, что идея эта, естественно, отнюдь не нова. Давным-давно криптографы определили понятие "гаммирование" - т.е. наложение какой-либо последовательности байт на текст, чтобы исказить его до неудобочитаемости. Шифр Вернама, перестановки Цезаря - все это призвано было защитить файл от чужих глаз. Однако криптоаналитики придумали подход, который можно назвать "частотным анализом". Т.е., делается предположение о том, что зашифрованный файл содержит в себе осмысленные предложения из такого-то или такого-то языка. И зная вероятности появления символов алфавита в тексте (кстати, как вы думаете, а какая самая часто встречающаяся буква в русском алфавите?), можно попытаться примерно таким же алгоритмом угадать, а что же спрятано за маской? Доказано, что гаммирование принципиально нельзя сломать при условии равенства (и достаточно скрупулезного подбора!) длины последовательности (гаммы), длине шифруемой последовательности. Но даже если это и не так, то, ответьте, что мне мешает заархивировать файл, а уж потом наложить гамму, пусть и неустойчивую? Архивация полностью уничтожит вероятностные распределения букв под маской, делая дешифровку невозможной. Так? А вот и не так! Популярных архиваторов не так уж и много! Опытный криптоаналитик, увидев подобную белиберду, первым делом попробует сжать файл. Как, не сжимается? Ах так! Ну мы тогда...

Впрочем, кажется, мы увлеклись. Итак, определение того, что файл упакован, не займет много времени. Теперь зададим вопрос: "А ЧЕМ упакован файл?". Ответ на подобный вопрос нужен не одним нам с вами. Мировым стандартом (не побоимся этой фразы) считается составление сигнатуры и поиска этой сигнатуры в файле. С точки зрения алгоритмики имеем поиск подстроки в строке.

Приготовление сигнатуры – вещь не сложная и во многом должна определяться квалификацией того человека, который эту сигнатуру составляет. В Pe Tools для этой цели разработана утилита SignMan, следующая версия которой будет основана на очень простом принципе: побайтовом сравнении файлов, запакованных ОДНИМ И ТЕМ ЖЕ упаковщиком с разными опциями:

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

Словом, примем сигнатуру для поиска достаточно надежным средством. Осталось определится с тем, как ее искать. Мы трактуем файл как последовательность байт. PE Sniffer , по версию 1.5.х. включительно, является пока еще утилитой-ребенком и от него, ни в коем случае, пока нельзя ожидать многого. Поэтому утилита должна быть переписана с учетом быстрого и в достаточной степени надежного поиска. Итак, поиск может быть разделен на две категории:

1) Точный поиск подстроки в строке –

Байт-в-байт в точке входа – тривиальное strcmp с минимальными трюками по пропуску плавающих байт. Медленно, наивно, не всегда работает. Скажем, ничто не мешает переписать точку входа PE-файла на свой, достаточно безобидный код, который, скажем, делает не больше, чем xchg eax,eax – и этого хватит, чтобы сигнатура не была опознана. Учтите, что автоматический алгоритм детекции секции кода может быть неверным (причины см. в первой части), поэтому надежнее сначала просто спросить у пользователя, какую секцию PE он считает секцией кода. Что мы имеем здесь в более продвинутом плане? Первое - поиск по принципу бинарного дерева – реализован в IDA во FLIRT -алгоритме. Более подробно об этом можно почитать в статье Ильфака Гильфанова о FLIRT. Второе - поиск Бойера-Мура в файле. Рекомендуется прочесть некоторые документы с http://algolist.manual.ru/ или ознакомиться со статьей http://www.rsdn.ru/article/alg/textsearch.xml на RSDN. Хочется сказать спасибо автору статьи - Андрею Боровскому – за такие объяснения, какими они должны быть. Понять алгоритм можно только посидев с карандашом над ним, разрисовав палочки и черточки. Эта статья относится именно к такому классу. Приведенные в ней алгоритмы в несколько более эффективном варианте, переписанные на С, будут использованы в PE Sniffer. В этом случае с файлом работают при помощи MMF -функций.

2) Неточный поиск подстроки в строке –

Поиск Бойера-Мура достаточно быстр за счет построения таблицы смещений и делает меньше сравнений, чем тривиальное strcmp. Однако он подходит лишь для точного поиска образца (или, в улучшенных вариантах, допускает лишь минимальные отклонения, согласно простейшим регулярным выражениям). Здесь же мы ни в коей мере не можем быть уверены, что подстрока (сигнатура) не будет самым злостным образом искажена. Давайте рассмотрим пару примеров и на их основе попытаемся сформулировать ряд правил для написания движка.

Пример: libc.lib – стандартная библиотека языка С. Известно, что код программы начинается не с main, а с * mainCRTStartup (одной из четырех). Поэтому ничто не препятствует поменять код процедуры с такого, например:

на вот такой:

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

Реально же имеем следующее:

1) Для каждого пакера существует устойчивая кодовая последовательность именуемая в дальнейшем сигнатурой для которой действуют следующие правила (здесь под элементом сигнатуры подразумевается байт)

>

a) Элементы сигнатуры не могут меняться местами

b) Элементы сигнатуры не могут быть заменены на другие

2) Между отдельными элементами может присутствовать "шумовой " код (если мы для сигнатуры выберем 1, 5, 10 байты сгенерированные пакером, для уменьшения количества ложных срабатываний, необходимо учесть минимальное расстояние на котором могут встретиться эти элементы сигнатуры друг от друга), а между некоторыми такой код появиться не может (двух и более байтные команды).

Что-то наподобие такого и будет реализовано в новой, уже не совсем детской версии PE Sniffer. Хотя и здесь решение для общего случая, скорее всего, НЕ существует. Уж слишком злопакостно можно исказить сигнатуру при желании, и ни CRC, ни xor-сумма строки, ни побайтовое сравнение по хитрым правилам не помогут. Скажем, пункты 1.a/1.b явно дискуссионны, чего только стоят т.н. stolen bytes в Asprotect. Поэтому если имеете собственное суждение – не стесняйтесь его высказать.

Возможно, самые отчаянные захотят обсудить экзотические методы детекции – применение нейронных сетей, генетические алгоритмы, fuzzy logic и т.п. – это прекрасно. Дерзайте! Учтите, что и OEP (см. главу об OEP) можно искать в памяти по такому же принципу – поиском сигнатур компилятора. Так, к примеру, поступает PEiD в своем genoep.dll – просто-напросто в дампе программы выполняется поиск компиляторных сигнатур, при этом, кстати, опять таки, не учитывается понятие «украденные байты» - stolen bytes – защитный прием некоторых пакеров (Asprotect), при котором куски кода из OEP нагло утаскиваются.

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

Как правило, в открытую печать не попадает сколь-нибудь ценной технической информации... Что тут говорить. Тем не менее, мы предложим пару линков:

1. «Heuristic Techniques in AV Solutions: An Overview»

http://www.securityfocus.com/infocus/1542 - в качестве вступления смотрися неплохо.

2. «Stripping Down An Av Engine»

2. http://www.nai.com/common/media/vil/pdf/imuttik_VB_%20conf_2000.pdf – в качестве вступления к следующему линку тоже ничего.

3. http://clamav.elektrapro.com/ - попытка антивируса с открытым исходым кодом (язык С). Функция эвристики (пока только ребенок) находится в файле matcher.c и использует обобщение алгоритма Кнута-Морриса-Пратта в поиске в односвязном списке – функция cl_scanbuff. Есть и еще несколько подобных антивирусов, но у их основателей хватило ума писать их на Java … Что тут сказать... И это там, где важна скорость и низкоуровневые трюки...

4. http://www.peterszor.com/ - на удивление приличные статьи о детекции метаморфов, пара статей о Win32 высокого класса. Это достаточно хороший уровень. Очень рекомендуется!

Вы решили потратить деньги на приобретение пакера. ОК, выбор ваш. Положим, вы не уверены, что способны написать хорошую защиту, просто нет времени или еще что-то. Тогда проверьте пакер! Хороший криптор должен не только перезагружать Windows если кто-то подошел к монитору, он должен и корректно обрабатывать многие тонкости и сложности PE-формата.

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

Основной смысл такого упражнения – в создании секции .tls в результирующем PE-файле (заметьте, мы говорим о статическом tls – с tls можно работать и динамически – подробнее – Джеффери Рихтер). .tls -секция (если она существует) обрабатывается лоадером при загрузке – вызываются callback-функции и т.п. Все это достаточно подробно описано Питреком в

http://www.microsoft.com/msj/0999/hood/hood0999.aspx

и облегчать жизнь писателям пакеров у нас желания нет. Однако факт остается фактом – многие коммерческие упаковщики не учитывают инициализацию tls-цепочек лоадером, в результате чего запакованный файл падает. Среди таковых и Aspack 2.12, который такой файл даже обработать не может! А люди еще за это и деньги платят...

Более того, можно сделать еще веселее! Положим, мы имеем дело с dll (tls -цепочки используются, в основном, именно в dll) – как прикажете обрабатывать секцию tls , которая подвержена перемещению, т.е. появляются fixup -элементы? В случае exe -файла аналогичного результата можно добиться опцией MS-линкера /FIXED:NO. Так это вообще фантастика! UPX гарантировано обрабатывает такие вещи, а вот некоторые остальные, не будем показывать пальцами...

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

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

Итак, пакуем наш старый добрый calc.exe и что мы имеем:

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

Использование директории отладки является старым добрым антиотладочным приемом, мы это уже описывали и повторяться неинтерестно. Ресуры тоже уже мало кого удивляют. Любопытнее выглядит изменение RVA директории импорта в секцию пакера. Если глянуть на заголовок (Optional Header), то можно видеть, что и точка входа переориентирована в новую секцию, и количество секций, соответственно, увеличено. Разумеется, изменилось поле SizeOfImage , иначе файл валидным не будет. Кому интерестно видеть все мелочи – воспользуйтесь функцией Compare из Pe Tools. Нам же интерестнее ответить на вопрос: так почему же секция идет четвертой. Если чуточку подумать над проблемкой, то ответ ясен – так легче. Положим, можно поставить и третьей, если не лень пересчитывать ресурсы как директорию и как секцию. А вот первой – ни-ни. Так как слишком уж это дело будет хлопотное... Но если кому-то не лень, что тогда? Смотрите – теоретически невозможно поставить секцию пакера первой – это потребует коррекции ссылок в секции кода и коррекции ссылок между секциями кода и данных и т.п., да и не только. Откуда получить такую информацию? Если файл содержит IMAGE_DIRECTORY_ENTRY_BASERELOC , то тогда, используя информацию оттуда, такое дело возможно, однако методика для общего случая работать не будет.

Что в этом плане можем извлечь мы. Да очень простой, старый и почти безотказно работающий трюк. Только давайте сначала четко определимся с терминами. Итак: OEP – original entry point – это не та самая точка входа которая записана в заголовке PE файла (OptionalHeader.AddressOfEntryPoint). OEP - это VA , куда упаковщик передаст управление после полной распаковки файла. Т.е. это - оригинальная точка входа которая была в заголовке PE файла до упаковки. А точка входа в запакованном файле называется EP (Entry Point). Так вот, нетрудно заметить, что прыжок после распаковки всегда будет происходить из области больших адресов в область меньших адресов. На этом механизме и были построены многие OEP-трейсеры – revirgin и icedump в их числе. Очевидно, что если кто-нибудь (гм, например, мы) не поленится написать драйвер, который даже будет не сколько трассировать приложение, сколько просто смотреть за EIP , когда тот будет выходить за пределы секции (секций) упаковщика. Положим, протектор сможет делать ложные прыжки, положив оные в конструкцию try/catch (см. ниже) – но отчет утилиты покажет это все человеку, а уж человек элементарно разберется – какой прыжок ложный, а какой нет. С другой стороны, пакер вполне может применять засечки количество тактов процессора – rdtsc и, чуть что не так, начинать орать. Словом, тут есть над чем подумать...

Работать с dll примерно так же просто. Достаточно давно разработана методика Break & Enter. Смысл ее состоит во влеплении опкода СС (о самом опкоде см. ниже) прямо в EP программы. Известно, что Soft-Ice Symbol Loader часто просто проскакивает мимо EP. Поэтому LordPE и PE Tools лепят СС-байт прямо в EP , предварительно запоминая оригинальный. Все, что остается пользователю – ввести bpint 3 и восстановить старый байт после всплытия Soft-Ice. Скоро будет написан плагин под PE Tools в виде лоадера dll , т.к. dll , с нашей с вами точки зрения, мало чем отличается от exe.

Что до директории импорта – тоже достаточно просто понять, что оригинальная директория импорта остается нетронутой лоадером (он ее просто не видит). Вместо этого пакер сам, после расшифровки содержимого файла, находит эту директорию и в цикле, перед передачей управления на OEP , с помощью GetProcAddress , наполняет ее валидными для данной системы адресами и производит перерасчет RVA на VA (см практический пример с Aspack). Обязательно следует заметить, что и тут прогресс ушел далеко вперед. Современные крипторы уже не используют GetProcAddress. Уж слишком легко нам поставить на нее брейкпоинт и разобраться в логике пакера (см. практические примеры).

bpx на функции API

Команда bpx Soft-Ice использует зарезервированный Intel опкод CC. Интеловские талмуды говорят нам следующее: «The INT 3 instruction generates a special one byte opcode (CC) that is intended for calling the debug exception handler. (This one byte form is valuable because it can be used to replace the first byte of any instruction with a breakpoint, including other one byte instructions, without over-writing other code).». Не путайте также опкод CD 03 с CC – они используются в разных случаях – «Note that the “normal” 2-byte opcode for INT 3 (CD03) does not have these special features. Intel and Microsoft assemblers will not generate the CD03 opcode from any mnemonic, but this opcode can be created by direct numeric code definition or by self-modifying code.». Поставить точку останова на API и получить результат – это прекрасно для нас с вами, но не слишком хорошо для авторов упаковщиков. Вот пример немного наивного кода для детекции bpx в самом начале LoadLibraryA: Код прост, но хорошо отражает суть. Его можно выразить и чуть иначе, например, так: а можно и еще парой десятков вариаций. Для его обхода опытные люди используют трюк с bpx API-name + x, где х – число, которое приходится на начало другой инструкции. Важно заметить, что + х может быть не абы каким числом. Это обязательно должно быть поле операнда, иначе исключения #DB не произойдет, произойдет другое исключение :) Скажем, часто предлагается ставить нечто вроде bpx GetProcAddress + 3. В этом случае Soft-Ice превратит символьное имя GetProcAddress в VA (гм, а может и не в VA, бог его знает, что там внутри Soft-Ice происходит – ведь большинство не задумывается ПОЧЕМУ команда bpx на какую-нибудь API-функцию типа MessageBox срабатывает в любом адресном пространстве, т.е. контекстно-неспецифична – под Windows для первых двух гигабайт это попахивает черной магией!), добавит к этому адресу 3 и воткнет туда СС. Будьте готовы – авторам упаковщиков элементарно проверить каждую вызываемую функцию на наличие CC, а тогда ... Тогда можно еще использовать bpm или уходить на уровень NativeAPI. К примеру, для GetProcAddress цепочка выглядит так: Последняя основательно прокомментирована в статье о DLL-лоадере, рассмотренной нами в первой части.

Вместо этого используется более изощренная технология – прямое сканирование директории экспорта целевых dll. Более подробно об этом можно почитать в статье «Win32 Assembly Components» написанной LSD Team. Статью можно скачать с wasm.ru или с сайта команды –

http://lsd-pl.net/projects.html#windowsassembly. Что мы можем сказать по этому поводу? М-м-м... Опять таки, если время сканирования экспорта опирается на rdtsc – тут тяжелее. В общем случае – почему бы, наконец, не раскачать Sten ’a на написание нормальной bpr -команды, которую, к сожалению, убрали из Soft-Ice... Присутствие такой bpr -команды позволит ставить точки останова на большие диапазоны памяти – например, на диапазон директории экспорта, и отслеживать обращающиеся к этому диапазону инструкции. Команда должна быть контекстно-специфичной.

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

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

Программа запускается и работает абсолютно нормально, но стоит сдампить ее как раз на MessageBox – последствия не заставят себя ждать. Причина в том, что статические и глобальные переменные инициализируются КОМПИЛЯТОРОМ! Следовательно, при нормальном развитии событий переменная имеет свой нолик еще в секции PE -файла и проверка проходит нормально. В сдампленной программе переменная уже заполнена функцией HeapCreate и, следовательно, при следующем запуске будет нам с вами радость.

Так что, в общем случае, рекомендация должна звучать примерно так: секции данных лучше дампить сразу после раскриптовки/распаковки, ибо протектор может их подпортить еще до ОЕР. И это подводит нас к очень важному выводу: не надо полагаться на ImpRec , OEP - finder ’ы, TRW с его makepe или что-либо еще – с каждым пакером пока приходится работать индивидуально, т.к. общее решение проблемы пока не разработано.

Основой получения списка процессов является функция NtQuerySystemInformation. Читатель может заворчать – вот, опять Native API. Да, именно так. Только учитывайте, что бывают РАЗНЫЕ уровени недокументированности! Скажем, весьма и весьма вероятно, что реализация некоторых Mi *-функций, рассмотренная нами ранее, может и, скорее всего, будет, варьироваться от ОС к ОС и даже от SP к SP , в то время как некоторые Native API функции весьма стабильны и едва ли изменятся в будущем. Во всяком случае, прототип, название и смысл должны сохранится. А смысл этой функции настолько велик, что Шрайбер назвал ее «кладезем » информации о системе. Также Гарри Неббет (Gary Nebbet) неплохо осветил эту тему в 1 главе своей книги. Кое-что из этой информации мы повторим здесь. Приступим:

Где, SystemInformationClass – тип требуемой информации, нас интересует только информация о процессах, т.е. SystemInformationClass = 5 , SystemInformation – указатель на буфер данных, SystemInformationLength – размер буфера данных, ReturnLength – размер записанных в буфер данных. Если выделенного буфера недостаточно, то в параметр ReturnLength будет возвращён требуемый размер буфера. Рекомендуемый размер = sizeof(SYSTEM_PROCESS_INFORMATION) * 1024 , так как вряд ли у кого то будет запущенно 1024 процесса.

Далее если не произошло ошибок, в буфер SystemInformation будет передана структура SYSTEM_PROCESS_INFORMATION , описывающая отдельный процесс в списке. Первым членом структуры (NextEntryOffset) будет смещение на следующий процесс в списке, если же оно равно NULL, значит это последний процесс в списке.

Простой пример использования функции, подразумевается, что буфер выделен, и NtQuerySystemInformation вызвалась без ошибок:

Внимание: важный момент, перед вызовом NtQuerySystemInformation рекомедуется установить своему приложению привилегию отладки программ. Это нужно для получения списка системных процессов (System Idle process). Но это возможно только под правами Администратора. Всё это проделывает функция EnableDebugPrivilege. Чтобы установить привилегию, первый и единственный параметр должен быть равен TRUE , чтобы убрать FALSE.

Для получения списка модулей служит функция RtlQueryProcessDebugInformation.

где,

• hPID – идентификатор процесса (PID),

• dwInfo – код запроса требуемой информации,

• pRtlBuff – буфер куда будет передана информация о модулях процесса. Ниже приведена структура этого буфера:

Для работы с функцией RtlQueryProcessDebugInformation необходимо создать (RtlCreateQueryDebugBuffer) рабочий буфер для хранения информации о модулях. И после окончания работы, вызвать функцию RtlDestroyQueryDebugBuffer , чтобы освободить этот самый буфер.

Пример:

ImageBase и ImageSize определяются достаточно легко. Нужно сделать перечисление модулей того процесса, для которого определяются эти значения. И в СПИСКЕ МОДУЛЕЙ найти имя нужного процесса, как правило оно идёт первым. Далее взять значения из структуры DEBUGMODULEINFO :

НО! Если процесс использует антидамповые приёмы (один из которых можно посмотреть во введении – нечего было его проскакивать!), то, как правило, ImageSize имеет неправильное значение. Поэтому рекомендуется его считать из PE заголовка процесса, но можно и из файла на диске (последнее даже надежнее). Ниже приведён пример функции считывающей ImageSize из заголовка:

Однако даже наличие таких методик в PE Tools все равно не спасет от защиты-драйвера (например, Extreme-Protector). Поэтому, видно, пришло время и PE Tools переходить на драйверный движок, который мало в чем будет опираться на структуры кольца-3. Так правильнее.

написано совместно с Quantum

UPX является практически единственным исключением в своем роде - полностью открыт исходный код. Это обстоятельство пытаются использовать многие авторы упаковщиков, и распаковщиков тоже. Часть просто молча ворует исходники (GPL-лицензия таки налагает некоторые забавные ограничения, хоть исходный код и открыт), другая часть пытается использовать это знание нам во вред, забывая - что OpenSource - это палка о двух концах. В данной главе принципиально не будет приведено ни единой строчки кода дизассемблера. Зачем? Все есть в кодах UPX. Итак, скачивайте кода с http://upx.sourceforge.net и в директории stub находите файл l_w32pe.asm. Не забудьте заглянуть и в stub.asm. В самом начале данного файла есть забавное предупреждение - 5 минут смеха обеспечены! Тем не менее, ассемблерный листинг стаба проще читается под отладчиком, так как исходники набиты всякими директивами препроцессору С (невидимыми ассемблеру), которые явно мешают уловить суть алгоритма.

UPX полностью пересобирает PE -файл, меняя все, что можно, за исключением ресурсов. К ним UPX относится достаточно бережно. Все остальное программа переводит в свой внутренний формат и сжимает по алгоритму UCL (кстати, вовсе не обязательно именно UCL , есть еще прогрессивный NRV) http://www.oberhumer.com/opensource/ucl.

Как программа переводит эти данные в свой формат описано в файле p_w32pe.cpp (для каждого поддерживаемого формата - свой cpp -файл со своими методами). Масса полезной информации находится также в файлах packer.cpp , packhead.cpp и compress.ch (очень занимательное чтиво). Однако нас это интересует мало, тем более не всякий открытый исходный код - панацея, т.к. за спасибо можно получить только исходники компрессора UCL , а последняя бета-версия UPX использует компрессор NRV (не GPL , однако). Получается, что основная часть упаковщика остаётся за кадром...

В результирующем файле (сколько бы секций ни было в оригинальном) всегда будут только три секции (для версий, отличных от 1.24-1.90, правило, возможно, соблюдаться не будет – кода мы не изучали) -

1. UPX0 - кладутся tls

2. UPX1 - fixup-элементы, импорт, экспорт, код и т.п.

3. UPX2 - ресурсы, однако в действительности этой секции, как правило, нет, т.к. автор утилиты прекрасно знал о том, что имя секции .rsrc очень много значит.

Код стаба - l_w32pe.asm - разжимает секции и обрабатывает директории импорта и fixup -элементов. Заметьте, повторим еще раз - идет обработка директории импорта! Часто встречается утверждение, что, мол, UPX переводит все в свой внутренний формат и, посему, лучше использовать ImpRec и иже с ним. Переводить-то, утилита переводит, да только потом разжать-то ведь надо, и перевести назад – в валидный для ОС формат. Внимательно рассмотрим код l_w32pe.asm по обработке импортов:

То, что UPX, фактически, распространяется с открытым кодом, да ещё и для различных форматов исполнимых файлов (Win16, Win32, Posix, MS-DOS и т.д.) серьёзно ограничивает его антиотладочные возможности... Цель UPX заключается в максимальном сжатии файла, но не в противостоянии хакерским усилиям по его распаковке. UPX.EXE поддерживает модификатор -d в командной строке для распаковки своих же файлов и почти всех предыдущих версий UPX включительно. На вопрос "как распаковать UPX?" можно лениво ответить, что мол "UPX -d packed.exe" (зря вы дампер приготовили). Так даже не интересно...

Стоп! Мы забываем про утилиты для защиты UPX, так называемые скрамблеры (scramblers). Скрамблеры пытаются немного замаскировать запакованные файлы, чтобы обмануть UPX. Но мы-то знаем, что перед нами файл, запакованный UPX'ом, потому что нам об этом сообщил идентификатор (sniffer) файлов или в дизассемблере "на глаз" был подмечен стаб UPX'а.

Здесь мы НЕ будем учиться распаковывать UPX. Существуют утилиты, которые прекрасно справляются с этой задачей, без особого участия со стороны пользователя. Здесь мы попытаемся понять принципы защиты UPX от распаковки, которые активно используются скрамблерами, вроде UPX-SCRAMBLER и HidePX. Данные утилиты призваны уберечь поднаготную запакованного экзешника от посторонних глаз, но делают они это не очень эффективно. Скачайте себе любую из них, или обе, или какой-нибудь другой скрамблер и пропустите через него ваш calc.exe. Что, уже не получается распаковать через upx -d? Как уже упоминалось раньше, существуют мощные распаковщики, которым скрамблеры погоды не строят, но наша цель - преодолеть защиту скрамблеров своими руками.

Не поленитесь сравнить calc.exe до и после прохождения через скрамблер. Можете воспользоваться WinHex / File Manager / Compare или другой подобной утилитой (PE Tools и LordPE умеют сравнивать и поля PE-формата – опция – “Compare”). Внимательно изучите листинг расхождений в обоих файлах и вы скоро поймёте, что первостепенные различия связаны с именами секций и сигнатурой UPX. UPX-SCRAMBLER заменяет UPX0 на code и UPX1 на text. HidePX затирает имя UPX0 и заменяет UPX1 на .rdata.

Если бы всё дело было только в именах секций, то для восстановления calc.exe можно было бы просто восстановить имена секций в любом PE-редакторе. Имена секций восстановлены, но там ещё и с сигнатурой что-то не так... Что такое сигнатура в данном случае? Здесь есть два понятия, которые необходимо различать. Под сигнатурой, с точки зрения последовательности байт кода, сама UPX понимает следующее:

Очевидно, изменив код этого метода, несложно добится того, что для программы перестанет иметь значение имя секции (количество секций лучше не трогать), об отсутствии или неверном offset ’е сигнатуры она станет лишь предупреждать, а не бросать исключение, но это лишь малая часть айсберга, т.к. существует ВТОРАЯ сигнатура! Под второй сигнатурой понимается структура, начинающаяся с “UPX!” (см. таблицу), которую UPX помещает перед сжатой частью файла. Помните, мы говорили, что UPX полностью перестраивает формат файла и граница старого сжатого файла начинается со второй сигнатуры. И, если испорчена она (что и делают скрамблеры), то тогда UPX просто слетит с внутренним исключением. Очевидно, снятие ВТОРОЙ сигнатуры и есть самое главное препятствие. Препятствие ли?

Для нахождения/просмотра/восстановления сигнатуры UPX можно воспользоваться хекс-редактором, но лучше - плагином Uncover UPX для PE Tools. Плагин прилагается к данной главе, так что можете сразу копировать его в каталог Plugins и PE Tools автоматически поместит его в соответствующее меню.

Основная черта данной утилиты заключается в автоматическом пересчёте контрольной суммы (поле CRC) при изменении остальных полей сигнатуры. Плагин также умеет частично или даже полностью восстанавливать сигнатуру после применения скрамблера. В случае с HidePX вам потребуется ввести (исправить) некоторые значения. Итак, что там за поля такие в сигнатуре? Учтите, что все значения отображаются в обратном порядке байт, т.е. в формате little endian , например: 12345678 -> 78563412 , ABCDEF -> EFCDAB , ABCD -> CDAB , AB -> AB.

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

Сигнатура UPX для старых NE , линуксовых ELF и т.д. представлена иначе, но нам интересен только формат PE32.

Uncover UPX самостоятельно восстанавливает сигнатуру после UPX-SCRAMBLER , так как данный скрамблер уничтожает сигнатуру частично, но что делать если сигнатура утеряна полностью, как в случае с HidePX? Тогда Uncover UPX заполнит её значениями по умолчанию и нам придётся немного ему помочь, если в том возникнет нужда.

Поле magic , понятное дело, менять не стоит. Поле version обычно оставляется как есть (0C или 0D). Format оставьте со значением 09. Method в 99% случаев равен 02. В level можете поместить любое отличное от нуля значение, так-как распаковщик не обращает внимания на уровень сжатия. Тоже самое относится к полю u_file_size.

Значения в u_adler и c_adler - это контрольные суммы, рассчитанные по алгоритму Марка Адлера (http://www.cdrom.com/pub/infozip/zlib/). Можете посмотреть исходники данного алгоритма, но они нам не помогут... Предполагается, что у нас нет распакованного варианта экзешника. Значит и подсчитать его контрольную сумму, даже зная алгоритм, мы не можем... На самом деле, обе контрольные суммы не влияют на процесс распаковки, т.е. можно просто отключить проверку данных значений внутри UPX. Вы уже скачали исходники UPX и UCL? Кстати, в исходниках UCL есть пример реализации алгоритма М. Адлера, но не будем отвлекаться. В исходниках UPX , в файле packer.cpp есть код следующего содержания:

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

Правда, даже если вы сможете перекомпилировать этот код, вы получите версию UPX без поддержки NRV. Было бы куда лучше внести эти исправления в последнюю версию UPX (1.90 на данный момент), которая поддерживает сразу UCL и NRV. Где наш дизассемблер? Стоп, перед устранением этого бага в UPX, не забудьте его распаковать (он сам собой и запакован)

Распакованный UPX.EXE (около 327 Кб) грузим в HIEW и задаём поиск 56578B7C241484DB8BF1. Кстати, данная последовательность применительна и к предыдущей версии UPX. Узнаёте следующий код?

Меняем 74 на EB и первая проверка адлеров решена! Чуть дальше вы встретите вторую проверку контрольной суммы:

Исправляем на безусловный переход, как в первом случае и вторая проверка тоже решена! Осталось исправить throwCompressedDataViolation(). Для этого следуем за первым исправленным переходом и вскоре видим вызов функции с пятью параметрами - это upx_decompress :

Функции вместо new_len нужно подсунуть адрес ph.u_len. Это можно организовать заменив 8D4C 24 1C на 8D4C 26 1C. Сразу за этим вызовом видим код примерно следующего содержания:

Исправьте второй переход с условного на безусловный. Всё, теперь нам море по колено! Можете вписывать в поля u_adler и c_adler всё, что хотите (хоть FFFFFFFF , чтобы не путаться с little endian) Для полного отключения проверки валидности файла можете ещё удалить сравнение имени первой секции. Это сравнение очень просто найти в... Нет уж, ищите сами! В противном случае, будете и дальше править имена секций в PE Editor.

Что до u_len и c_len , то проверку валидности данных полей вы уже отключили но, в отличии от адлеров, выбор значений u_len и c_len налагает некоторую ответственность. Дело в том, что UPX резервирует два буфера в памяти: один размером с u_len для временного хранения распакованного файла, другой размером с c_len для чтения запакованного содержимого файла. Понятно, что если задать слишком маленькое значение для u_len , то распакованный файл просто не поместится в буфер. С другой стороны, слишком большое значение заставит UPX потреблять больше динамической памяти. Для u_len вполне подойдёт значение 000FFFFF (FFFF0F00 в little endian) для большинства упакованных экзешников.

С c_len чуть сложнее. Опять же, слишком маленькое значение вызовет конфликтную ситуацию с динамической памятью, но слишком большое, кроме излишнего расхода памяти, отрицательно воздействует на сам процесс распаковки. Иначе говоря, фокус с 000FFFFF не пройдёт. Надо подобрать более близкое значение. К счастью, в версии 1.24 выдаётся одно сообщение об ошибке, когда значение меньше правильного и другое - когда больше. В версии 1.90 эта фича отсутствует, но на данный момент HidePX не поддерживает 1.90, а UPX-SCRAMBLER не портит значение c_len. В версии 1.24 даже не нужно задавать абсолютно точное значение c_len - небольшая погрешность спокойно поглощается распаковщиком.

В заключение стоит упомянуть поле filter. В нём обычно хранится значение 260X , где X может быть 0, реже – 1, а еще реже – что-нибудь другое, например, 6, для старых версий UPX. Данное поле заслуживает особого внимания, так как неправильное значение фильтра приводит к неправильной распаковке экзешника, т.е. файл распаковывается, но не запускается! В общем, зря скрамблеры пренебрегают этой записью. Немного подправив значение фильтра можно защитить файл куда эффективнее, хотя от дамперов это всё равно не поможет, но всё-таки...

Теперь давайте проведем два практических примера. Наконец-то!

Итак, UPX-SCRAMBLER. Скачиваем с wasm специальные upx by Quantum /Volodya. Результат:

Теперь HidePX.

Поможем нашему UPX. Загружаем PE Tools , запускаем Quantum ’овский плагин. Жмем одну-единственную кнопочку – Fix. Повтор:

На тот маловероятный случай, что что-то пойдет не так... Хм, а зачем мы вам столько писали, а?

В заключение статьи надо сказать, что некоторые упаковщики довольно бездарно пытаются замаскироваться под UPX. Например, это делает telock. Только вот все они не учитывают одной маленькой тонкости - UPX 1.24+ создает ТОЛЬКО ДВЕ секции - UPX1 и UPX0 - независимо от того, сколько на самом деле секций в файле. А telock этого попросту не учитывает, создавая в некоторых случаях несколько UPX -секций, что сразу бросается в глаза. Гораздо более точным критерием в данном случае можно считать присутствие характерного стаба, ведь он действительно нужен для того, что бы экзешник мог сам себя распаковать в памяти.

В самое заключение главы. Помните, в самом начале мы говорили, что здесь не будет ни строчки дизассемблированного листинга? Так вот, мы соврали. Имеет смысл разобрать один скользкий момент с HIEW. Передача управления на OEP в UPX отображается HIEW (по 6.85 включительно) так:

Почему же jmp по адресу 0x101AFFF имеет такой странный операнд? Давайте спросим автора HIEW – SEN ’a. Ответ: «...но такого VA в файле нет, он появится потом, когда UPX память выделит для этого VA , а в файле ничего нет, поэтому hiew просто отсчитывает в глобальных адресах смещение и показывает как есть». Так что это ни в коем случае не баг утилиты. Просто автор очень не хочет включать поддержку многочисленных частных случаев, благодаря чему HIEW был и, пожалуй, так и остается одним из самых быстрых дизассемблеров на сегодяшний день. А уж эта возможность поиска по ассемблерной маске с * и ? – так это вообще фантастика...

Что делает новичок, увидев программу, запакованную Aspack? Ну, берется Soft-Ice , берется дампер процессов и, обязательно, Imprec. Потом над всем этим инструментарием начинают интенсивно издеваться – зацикливать на OEP , дампить целиком, посекционно или еще как, немедленно запускать Imprec и вставлять полученный дамп директории импорта в файл. Ну что ж. Можно и так. Работает. Только давайте усложним задание. Положим, дампер процессов не имеет никакого движка по перестройке импорта, а Imprec и иже с ним у нас просто нет. Что тогда?

А вот тут-то и надо рассматривать сам алгоритм работы упаковщика. К счастью, есть и такие статьи. Например: «Исследование алгоритма работы упаковщика ASPack v1.08.03» - довольно толковая статья (когда будете читать – хм, вы уже знаете, что такое KTEB). Несмотря на то, что рассматривается старая версия, в новой (2.12) не так уж и много изменений с нашей точки зрения. Для кросс-проверки и некоторого дополнения сведений можно также проглядеть статью «ASPack 'Spelunking'».

В связи с тем, что есть такие великолепные материалы, мы не станем рассматривать код ASPack подробно. Для начала учтите – что это не криптор, это самый обычный упаковщик. Здесь нет ни антиотладки, ни сколь-нибудь сложных приемов противостояния дизассемблерам. Лишь в самом начале есть нечто, робко напоминающее полиморфный код:

Итак, ясно, что ebp показывает на начало кода/данных. В связи с этим весь остальной код теперь достаточно четок и ясен. Полагаем, понять, что делает этот код, после фокуса с ebp , уже предельно просто:

Фокус с

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

Теперь давайте посмотрим, как правильно надо сбрасывать дамп из программ, запакованных Aspack. Здесь предельно четко нужно понимать, что нам нужен файл ДО обработки его самим упаковщиков, т.е. СРАЗУ ЖЕ после разжатия. Такой момент существует не для всех упаковщиков, однако для Aspack он проявляется предельно наглядно.

Итак, Aspack выполняет разжимание секций по LZ +Хаффман-подобному алгоритму с использованием VirualAlloc для отведения памяти под временный буфер и VirtualFree для высвобождения этого буфера. В буфер вбрасывается разжатое содержимое, которое копируется двойными словами (хорошая оптимизация!) (и докопируется побайтно при необходимости) на то место, что принадлежит ему по праву – на оригинальный RVA секции. После полного разжатия и копирования Aspack принимается обрабатывать директорию импорта (см. ниже), директорию перемещаемых элементов, вычисляет и предает управление на OEP. Наша задача – сбросить дамп ДО обработки импорта, fixup -элементов и т.п. Сделаем мы это как раз здесь:

Адрес 0х010191A9 здесь как раз и является « заветным ». Зацикливая программу на этом адресе мы можем быть уверены, что дамп является полностью рабочим и не подвергнут ни обработке импорта, ни чему-либо еще. Ввести программу в бесконечный цикл можно по-разному, к примеру, введите ассемблерную команду jmp eip , воспользуйтесь командой !dump в IceExt , выберите SuspendThread , словом, вам и карты в руки. Мы же здесь, разумеется, объясним как использовать PE Tools.

Итак, после того как jnz не сработает – все секции распакованы и можно приступать. Полный дамп файла с опциями Full Dump: fix header, Full Dump: rebuild image. DumpFix, ValidatePE, RebuildPE. В дампе ручками в PE Editor: Optional Header > пересчитываем: SizeOfImage, SizeOfHeaders, Checksum (при помощи кнопки "?"). Уменьшаем размер. Делаем RebuildPE , с опциями: DumpFix , ValidatePE , RebuildPE.

Файл ПОЧТИ валиден. Осталась мелочь – параметры директории импорта и правка EP. Нам более не нужен код пакера, поэтому EP должна быть переориентирована назад – на OEP и директория импорта должна быть поправлена. Для этого залезем в алгоритм Aspack еще раз. Вспоминаем первую часть и действие функции LdrpSnapIAT , что в ntdll.dll. Все пакеры должны эмулировать ее действие, заключающееся (не только) в превращении RVA полей директории импорта в VA – взгляните на код:

Итак, RVA директории импорта ясен, осталось узнать размер. Делаем так:

Параметры директории должны выглядеть так: RVA – 0x12A40, Size – 0xAB0. Теперь OEP :

Меняем RVA OEP на 0х12420. Все. Дамп рабочий и полностью готов. В качестве домашнего задания – попытайтесь удалить секции Aspack. Если с тем, что здесь написано, есть внутренние сомнения – почитайте дополнительно очень хорошую статью: «unpacking files with a .aspr section», а мы, тем временем, рассмотрим один оригинальный, хотя и не новый, прием. Надеемся, вы еще помните, что мы советовали обратить внимание на pusha в начале этой главы. Вы уже знаете, что дампить программу нужно не на OEP , а, желательно, задолго до него. В случае Aspack , где в открытом виде остается директория импорта, перемещаемых элементов, распаковываются секции, до OEP добираться нет нужды. Однако, возможно представить ситуации, когда времени просто нет и нужно добежать. Тогда используйте трюк с bpm esp-4. Немедленно после pushad ставьте эту точку останова. Действие pushad можно глянуть в интеловских талмудах в виде псевдокода. Если лень глядеть, вот:

Точка останова сработает поблизости от OEP – на popad – при вытаскивании регистров назад. Вот здесь:

Заметим напоследок, что трюк с bpm esp-4 сейчас работает не так уж и часто. Многие крипторы специально осложняют нам жизнь. В некоторых случаях это можно обойти, к примеру, поставив точку останова еще ниже, но с некоторыми крипторами не помогает и это. К примеру, вполне возможно поставить в блок try/catch пример на исчерпание стека в бесконечном цикле, а обработчик исключения должен это дело разобрать. Для успешного понимания таких защит необходимо четко разбираться в SEН – структурных исключениях, что и рассматривается в следующей главе.

Рискуя повторится, тем не менее, скажем еще раз - для успешного отдирания криптора от файла необходимо неплохо разбираться в принципах работы операционной системы. Одним из таковых, и достаточно интересным, являются SEH - structured exception handling - обработчики исключений. Как всегда, мы не собираемся начинать здесь с азов. Также учтите, мы расписываем только исключения, пришедшие из user mode , т.е. ring-3. Если честно - сеть исключительно бедна сколь-нибудь хорошей информацией, приятное исключение, как всегда, Мэтт Питрек со своей изумительной статьей http://www.microsoft.com/msj/0197/exception/exception.aspx. Если хочется солидной теории – можно глянуть http://www.codeproject.com/cpp/exceptionhandler.asp Также немножечко об этом рассказывает Руссинович, как всегда, на высоте Gary Nebbett , да еще с миру по нитке можно найти в качестве предисловия к некоторым книгам по разработке драйверов. Информации по использованию SEH для облегчения жизни нам при отдирании пакера вообще практически нет - чуть-чуть в некоторых китайских статьях, да на форуме fravia (http://66.98.132.48/forum/) что-то проскакивало. Итак, предполагается, что вы внимательнейшим(!) образом прочли статью Питрека. Теперь взгляните на рисунок:

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

Не имеет смысла особо глубоко вдаваться в тонкости обработки исключений процессором Intel и реализацией этого дела в Win 2k+ (мы рассмотрим это в практическом примере). Достаточно сказать, что в один прекрасный момент времени управление получает функция KiDispatchException (ntoskrnl.exe), псевдокод которой можно найти в исходниках ReactOS (см. первую часть статьи) или в книге Неббета. А уж эта функция и будет решать, что делать - либо отладчику управление передавать, либо SEH -фреймам программы, либо еще что-то. Обработчики SEH , по сути, являются односвязанным списком (Windows никуда и не убегала от фундаментальных типов хранения данных). А это означает многое... Например, ничто не мешает перестроить список, добавив туда свой обработчик. Или, к примеру, слегка изменить тело узла, список это позволяет. Правда, SEH -списки контекстно-специфичны, ну да и что с того? Список SEH -обработчиков немножко нестандартный, вместо указателя на следующий узел, он содержит указатель на узел предыдущий (своего рода стек на основе списка), вот так:

Можно с полным на то основанием считать использование заведомо сбойных участков кода в SEH -кадрах самым настоящим антиотладочным приемом, который одинаково хорошо работает и как против ring-0 отладчика, и как против ring-3 отладчика. Автор упаковщика встраивает код, который заведомо даст сбой, в SEH -кадр. Примерно так (код из статьи Питрека очень нагляден):

Что произойдет, когда управление получит код во втором __asm блоке? Произойдет исключение UD - invalid opcode (которое, как известно, сопоставлено с прерыванием int 06 в IDT), и управление получит обработчик _KiTrap06 , что в ntoskrnl.exe :

Далее управление уйдет в KiDispatchException - мы не рассматриваем этот момент подробно. Потом управление уйдет к кольцо-3 - KiUserExceptionDispatcher (ntdll.dll), чтобы никогда более не вернутся в кольцо-0 (ложь, подробнее см. ниже). Функция RtlDispatchException подхватит управление дальше. Учтите, что возврат в функцию KiUserExceptionDispatcher может и не произойти (это ОЧЕНЬ важный момент, подробнее ниже). В нашем примере адрес обработчика выглядит так:

Давайте немного разберемся с тем, что здесь написано. Команду Soft-Ice xframe мы описывать не будем - для этого есть документация. В данном конкретном случае команда вывела отчет обо всех SEH -фреймах, зарегистрированных для данного контекста (не забываем, что мы имеем дело с односвязным списком). Обратите внимание, самый первый SEH начинается из TIB. В SoftIce выполните команду thread -x имя_процесса :

Поле UTEB показывает адрес памяти, по которому в ring-3 расположен TIB, а поле Except Frame показывает адрес ПОСЛЕДНЕГО узла в списке SEH (к SEH можно также подступится не только через FS:[0], но и через TIB (FS:[18]) в которой, помимо указателя на хвост списка SEH , хранится линейный адрес самой структуры TIB, который можно использовать для доступа к ее полям). Потрассируйте программу, использующую SEH, и обратите внимание на изменение адреса в этом поле.

Самый первый SEH -обработчик ставит недокументированная функция BaseProcessStart (описывается и у Питрека, и у Рихтера), а роль последнего оплота выполняет функция kernel32.dll UnhandledExceptionFilter. Таким образом мы видим, что НИ ОДНО приложение Windows не существует без обработчика исключительных ситуаций по умлочанию (xframe даже определила его тип - try/except, что точно соответствует действительности). Некоторые вирусы используют этот факт для поиска kernel32.dll в памяти. Soft-Ice ставит API-hook (т.е., просто-напросто, лепит опкод СС) на UnhandledExceptionFilter. Немного забавно то, что отладчик нулевого кольца вынужден ставить перехват функции кольца-3, но, как мы уже упоминали, исключение 3-го кольца сначала обрабатывается в ядре, а потом возвращается назад. Т.е. когда управление попадает в ring-3, и начинают вызываться последовательно обработчики SEH , то управление в ring-0 , ВОЗМОЖНО, уже не возвращается. Если ни один из обработчиков ошибку не обработал, то вызывается UnhandledExceptionFilter , которая в системе без Soft-Ice после вывода посмертного сообщения просто прибивает процесс. Некоторые пакеры (например, Ultra Protect) проверяют наличие CC в начале этой функции - вот и еще один метод поимки SoftIce (IceExt отсекает этот метод, просто запрещая ставить SoftIce СС на эту функцию).

Сам обработчик, в нашем случае может просто увеличить EIP и вернуть управление назад, так, чтобы перескочить F1. И вот теперь мы, собственно, добрались до кульминационного момента. Когда Windows вызывает обработчик исключения, ему (обработчику) становится доступной структура CONTEXT , дающая возможность менять все общедоступные регистры процессора, включая DR0-DR7.

Итак, заглянув в документацию Intel , вы теперь знаете, что единственная, доступная команда для работы с DR -регистрами - это mov. И в 3-кольце инструкция mov drx, x недоступна! Следовательно, запрос должен уйти в ядро. И этот факт путает многих. Часто встречается утверждение, что обработчик SEH работает в нулевом кольце. Чушь (9x не рассматривается)! Но вот структура CONTEXT , возможно измененная обработчиком, действительно предается в ntoskrnl , где и происходит все самое важное. Еще раз обратимся к статье Питрека:

Вопрос: когда RtlDispatchException возвратит управление, а когда нет? Ответ заключается в самом обработчике прерывания. Если обработчик имеет вид:

то, очевидно, управление будет передано назад. Если же имеем обработчик вида:

то RtlDispatchException в ntdll.dll управление не вернет! Что это означает? Да то, что если обработчик, к примеру, намеренно изменил DR -регистры через структуру CONTEXT , то и что с того? Да ничего и не произойдет. Кроме того, есть еще и другая причина. За обработчики, не возвращающие управление в ntdll , надо, в буквальном смысле слова, отрывать уши! Почему? Да потому что при таком раскладе список SEH перестанет быть сбалансированным - появятся две новые записи, а именно –

1) запись от RtlpExecuteHandlerForException , которая тоже использует try/catch ,

2) запись пользовательского обработчика. Т.е. список будет выглядеть так:

Итак, вывод. Если обработчик намеренно меняет DR -регистры, то управление должно вернуться в ntdll.dll и быть передано функции NtContinue. Теперь мы вплотную подошли к этой любопытной функции. Из функции, реально, документирован только прототип. В кодах ReactOS по поводу NtContinue наблюдается полное отсутствие всякого присутствия. Следующий псевдокод получен путем дизассемблирования и анализа, как всегда:

Если приведенный выше кусок псевдокода привел вас в ужас - ничего. Все вполне можно уложить в пару фраз. Итак, так или иначе, управление будет передано в KeContextToFrames , единственная задача которой - переложить содержимое полученной извне (это может быть и кольцо-0 в случае драйвера!) структуры CONTEXT в структуру KTRAP_FRAME. Заметьте, структура KTRAP_FRAME еще не означает DR -регистры. Код, перекладывающий содержимое KTRAP_FRAME , полученное после KeContextToFrames , расположен в NtContinue , а точнее, либо в области KiServiceExit , либо в области KiServiceExit2. Внимательнейшим образом рассмотрите инлайн-ассемблер и, самое главное, предшествующую ему проверку.

Что это означает для нас с вами? Смотрите, у пакера нет выбора. Если пакеру необходимо изменить DR -регистр, он ДОЛЖЕН передать управление в ядро, где программа кольца-3 не в силах проконтролировать установку точек останова, и момент передачи управления на код, работающий с DR -регистрами, может быть нами подправлен как нам заблагорассудится!

Очевидно, что если переделать в абсолютный jmp один условный переход, то DR -регистры останутся неискаженными, следовательно, мы свободно сможем пользоваться нашей любимой командой bpm. И все – наполнение мусором DR -регистров (как это любит делать asprotect) нам теперь до лампочки. Неужели все так просто? К сожалению, нет. Да, действительно, нет никаких принципиальных сложностей в изменении условных переходов (скажем, можно привинтить в IceExt команду, которая будет ставить подобную защиту при необходимости и снимать ее, когда отпадет надобность), но и авторы упаковщиков даже не даром свой хлеб едят. Что вы скажете о защите, которая сама ставит точки останова, используя DR -регистры, т.е. трассирует сама себя? Т.е., если DR -содержимое очищено или оставлено без изменений с помощью трюка с NtContinue , точка останова не сработает и программа узнает, что дело плохо. Вероятно, в общем случае, разработать решение этой проблемы не удастся... Подумайте, возможно, именно вы сумеете разобраться как можно проэмулировать этот трюк, если это вообще реализуемо.

Теоретическая глава почти закончена. Единственная вещь, не рассмотреная нами и представляющая определенный практический интерес, называется scope table. Как уже говорилось, Visual C++ ставит дополнительные данные в EXCEPTION_REGISTRATION - добавляются некоторые структуры (конкретнее - см. файл exsup.inc). Далее обратите внимание на код startup процедуры в crt0.c (стандартном startup-коде) - он обернут в _try/catch. Причем этот _try уже идет с дополнительными структурами, т.е. появляется scope table. Скажем, довольно несложно разработать драйвер, который будет трассировать пакер вплоть до момента появления scope table , которое должно означать, что начал исполняться пользовательский код. С другой стороны, что помешает пакеру установить ложную scope table... С третьей стороны - можно просто выдать пользователю отчет, а уж он пусть сам разбирается, что к чему... С четвертой стороны, есть еще Borland и Watcom со своей реализацией, с пятой ... И так до бесконечности.

Спешим «порадовать» еще одной «приятной» новостью – фирма MS в Windows XP ввела так называемые векторные исключения – VEH , имеющие приоритет над SЕH , т.е., выполняющиеся перед ними. Умница Питрек и тут не подкачал – читайте его статью.

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

написано совместно с Four-F

Практически в любой статье по снятию упаковщика рассказано о трюке применения int 1 в SEH-кадре и том, что это помогает обнаружить Soft-Ice. Однако ни слова не сказано о том, ПОЧЕМУ И КАК это происходит. Давайте попробуем разобраться. Хотелось бы сразу сказать, что лезть придется глубоко – в ядро Windows. Итак, поехали!

Очевидно, чтобы избежать антиотладочных фокусов, нужно понимать, что такое отладка и какие средства в нашем распоряжении есть. А это требует чертовски хорошего понимания защищенного режима и обработки прерываний защищенного режима. Значит – интеловские талмуды!

Итак, вполне понятно, что int 1 в качестве антиотладки можно использовать только в SEH -кадрах, иначе не выживет сама программа. Стандартно можно поступить так:

Более изощренный код, в котором адрес обработчика исключения уже не столь очевиден, может выглядеть так:

Так же учтите, что удаление SEH -кадра тоже можно проделывать не только через pop, а и прямыми манипуляциями со стеком – mov esp … Чтобы не поплыть во всем этом, надо четко представлять себе состояние стека в обработчике прерывания. На эту тему есть одна очень хорошая статья –

http://win32assembly.online.fr/Exceptionhandling.html - не поленитесь внимательно посмотреть картинки, или смотрите программу на С ниже в этой же главе. Кстати, переполнение стека – стандартный способ проникновения в систему – можно вызывать и из обработчика SEH. Читните http://www.peterszor.com/blended.pdf - очень познавательно.

А мы, тем временем, продолжим разбор обработчика с int 1. Очень внимательно рассмотрите этот код:

В системе БЕЗ Soft-Ice int 1 имеет DPL = 0 (если c IDT чувствуете себя неуверенно – хорошая ссылка: http://www.acm.uiuc.edu/sigops/roll_your_own/i386/idt.html):

Быстренько вспоминаем, что происходит, когда задача с меньшим DPL пытается обратится к сегменту с большим DPL? Правильно – нарушение защиты #GP! В системе БЕЗ Soft-Ice int 1 имеет DPL = 0 и, в случае намеренного (хм, или ненамеренного) сбоя в программе кольца-3 (DPL = 3), будет вызван обработчик KiTrap0D , выполняющий следующие действия:

в конечном результате которых мы имеем код 0xC0000005(!) в ExceptionRecord- >ExceptionCode! Еще раз – произошло int 1 , а имеем – access violation!

Что же произойдет в системе, где Soft-Ice установлен?

Т.о. DPL обработчика int 1 изменился. Что это значит? В системе с Soft-Ice результат будет другим. Ice меняет DPL int 1 с 0 на 3, в результате чего access violation более НЕ происходит, KiTrap0D НЕ вызывается, а имеем KiTrap01 – 0x80000004 - STATUS_SINGLE_STEP! Поведение процессора тоже будет отличаться. Теперь EIP показывает не на инструкцию, вызвавшую access violation , а на инструкцию, следующую после нее! Более подробно – интеловские мануалы – разница между trap и fault.

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

Нет нужды верить на слово. Все элементарно можно проверить. Вот программа:

Защитится от этого можно элементарно – пропатчив IDT или поставив IceExt, который восстановит DPL int 1 в прежнее состояние.

Что до int 3 – то само по себе использование int 3 в SEH -кадрах не есть антиотладка – статус будет всегда одним и тем же – STATUS_BREAKPOINT. Специфичной антиотладкой int 3 становится тогда, когда к нему добавляются переданные в ax, dx и т.п. параметры. Например, известный трюк с командой HBOOT. Если в Soft-Ice выполнить данную команду, произойдет мнгновенная перезагрузка. Того же эффекта можно достичь через backdoor интерфейс, что, к примеру, описано у Hex’a (проект xtin.org). Если помните, мы говорили, что int 3 обязательно должен иметь опкод СС и никакого другого. Windows явно рассчитывает на это. Кусок кода из KiTrap03 тому примером:

Кстати, Soft-Ice тоже лжет. Выполните команду idt и вы увидите следующее:

т.е., якобы, ничего не изменилось. В действительности же имеем:

т.е. Soft-Ice перехватывает int 1/int 3 (кстати, не только их!) на свои заглушки, а это значит - не стоит всегда верить и Soft-Ice. И вообще, начитавшись всего этого, недолго и параноиком стать. Все врут.

Эта цель отнюдь не является легкой. В качестве антиотладки очень активно используются SEH -кадры, набитые всякой гадостью. Однако, используемые приемы однотипны. Так, вся защита программы построена на одном веселом принципе. Смотрите:

Что мы можем этому противопоставить? Очевидно в ядро, наш старый добрый знакомый, нам заходить ни к чему. Поэтому имеет смысл переориентировать EIP на безопасный клочок внутри SEH -кадра и продолжать двигаться дальше. Но это только в теории. На практике, Soft-Ice очень не любит такие конструкции, поэтому проходит через SEH -фреймы пешком очень не рекомендуется. Поскольку строение и принципы работы SEH теперь понятны, постарайтесь всегда узнавать адрес обработчика ДО вхождения в кадр и сразу переориентируйте EIP на него. Только не стоит забывать о такой вещи как балансировка стека и значения регистров. Иначе очень быстро допереориентируетесь...

Мы рассмотрим пример самотрассировки в telock – это высший пилотаж на DR -регистрах, а не просто тупое заполнение их мусором. Итак, приложение третьего кольца действительно может записать что-то в DR -регистры, но только не прямо, а опосредованно - через SetThreadContext или SEН. Значит, мы должны ожидать доступа по CONTEXT.drx и возврата управления в ядро. И это не заставит себя ждать. Вперед:

int 3 вызывает исключение STATUS_BREAKPOINT. Управление переходит в ядро и возвращается на обработчик. В данном случае его адрес - 10190C5. Заглянем туда:

Если вы все еще с нами – продолжаем! Итак, обработчик int 3 записывает в DR значения ВНУТРИ ТОГО ЖЕ САМОГО кадра SEH. Управление ОПЯТЬ передается в этот же самый злополучный кадр! Четыре раза должны отработать DR-регистры. После четвертого раза происходит исключение типа деление на ноль. И тут-то получает управление ветка, которую можно назвать «на дорожку». Правится EIP , во все DR -регистры прописываются нули, ставятся маски на управляющие DR6-7 и управление идет дальше – на метку work_with_PE. И это все! Больше работы с DR -регистрами в коде telock нет!

Немножко по поводу DR -регистров и Soft-Ice , который действительно является чудом. Dr -регистры явно не отображаются и принудительно могут быть выведены командой CPU. Записать в DR-регистры что-нибудь можно лишь опосредовано – через bpm с явным указанием одного из четырех (DR0-DR3). Кроме того, умничка Soft-Ice умеет отображать модельно-специфичные регистры – MSR. Для этого есть одноименная команда и более усовершенствованный вывод сообщений при срабатывании bpm :

Читаем в интеловских талмудах – том 3 глава 15 “ Debugging and performance monitoring ”: “ The LastBranchToIP and LastBranchFromIP MSRs are 32-bit registers for recording the instruction pointers for the last branch, interrupt, or exception that the processor took prior to a debug exception being generated ”.

Так это же вообще шикарно! LastBranchFromIp – это « откуда », LastBranchToIp – это у нас «куда». Как это можно использовать? Ну... Встретите защиту вида:

и все сразу станет ясно...

Ну а что дальше? Дальше – еще веселее. Безумные SEH -кадры с инсталляцией головы списка наподобие:

и int 68h внутри. Однако, смеем надеяться, более проблем они вам не доставят! Да, они головоломны, да, код перенасыщен мусором, да, обилие зашифрованных сегментов – но дорогу осилит идущий! Самое главное – чисто пройти головоломный трюк с DR. Все. После него вы спокойно можете ставить bpm. И не слушайте всяких рассказов, что, мол, bpm в telock ставить нельзя. Можно!

Смело ставьте bpm GetProcAddress x (telock использует его напрямую, без всяких сканирований директории экспорта):

Собственно, не имеет смысла описывать этот цикл. Важно отметить – нет нужды во многочисленных плагинах под ImpRec , возьмите директорию отсюда. Остерегайтесь ставить bpx на API напрямую, используйте bpm или старый трюк с bpx API+x , т.к. telock проверяет вызываемые функции на СС в начале (разумеется, точки останова на Native API никто проверить не сможет). bpm LoadLibraryA и bpm GetProcAddress – наши отправные позиции. Используйте их просто как зацепку, т.к. нам нужна ЧИСТАЯ, НЕИЗМЕНЕННАЯ директория импорта. Куски кода можно просто дампить IceExt по ходу дела и бинарные сегменты дизассемблировать прямо в IDA. Дамп – разбор кода, дамп – разбор кода. Можно, скажем, поступить и еще оригинальнее – известно, что в один прекрасный момент времени директория (да и не только она) является полностью разжатой – просто выполните в Soft-Ice поиск имен библиотек или предполагаемых функций (например, «kernel32.dll»), в памяти и разберитесь на глаз с диапазонами директории). Словом, дорогу осилит идущий.

На вашу совесть также мы оставляем трюк с мьютексами. После прочтения Джеффери Рихтера он не должен быть источником проблем.

Эта статья никогда не была бы написана, если бы не громадный ворох литературы, который был основательно перелопачен. В подавляющем большинстве – это англоязычные книги, лишь для нескольких из них был выполнен перевод. Поэтому, как это не прискорбно, знание языка ОБЯЗАТЕЛЬНО, если хотите быть в потоке.

1. Соломон, Руссинович, “Inside Windows 2000, 3rd edition” – это теория. Но какая! Здесь есть все. И, если сочетать ее с практическими книгами, вроде 2 и 3 – то результат будет. Есть русскоязычный перевод.

2. Шрайбер “Недокументированные возможности Windows 2000” – сугубо практическая книга, ценность которой... Мама родная – там все есть. И есть русскоязычный перевод.

3. Gary Nebbett “Windows NT/2000 Native API Reference” – English only. Перевода нет. Книга описывает прототипы и очень многие структуры данных Native API. Есть практические примеры использования Native API. Опять таки – a must.

4. Джеффери Рихтер “Windows для профессионалов” – практическая книга. Очень сильная и очень полезная для любого. Есть русскоязычный перевод.

Список литературы ни в коем случае не ограничивается лишь этими 4-мя книгами. Мы старались давать как можно больше линков по ходу статьи – они стоят того, чтобы их прочесть.

Что до литературы по распаковке – такой, к сожалению, нет принципиально. Со статьями тоже напряженка. В подавляющем большинстве статей расписывается лишь как давить на кнопочки, или, что еще лучше – приводятся километровые ассемблерные листинги без комментариев, превращая статью в нечто нечитабельное. Здесь хочется похвалить Касперски, который очень удачно выбирает размер листингов в своих книгах – 10-20 очень тщательно подобранных строк – самое то!

В заключение хотелось бы сказать о третьей части. Готова она будет не скоро и при ее написании мы будем учитывать, что, наконец-то, появились две великолепнейшие статьи - по Asprotect by seeQ и по Armadillo 3.10 by dragon. Обе статьи доступны на xtin.org и являются редким исключением среди большинства статей по упаковщикам. Авторы проделали прекрасную работу. Спасибо им. Теперь вроде все. Да, если есть замечания, пожелания – или NEOx на uin.ru или я на форуме wasm’a готовы их выслушать.

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

Вещь 1 : программа исполняется не в вакууме! Windows создает и поддерживает огромное количество сложнейших структур данных, поддерживающих каждый процесс, каждый поток. Чем больше ваше понимание об этих механизмах – тем легче ломать. Применение ImpRec/PE Tools и иже с ними не освобождает от понимания принципов, лежащих в основе этих и многих других утилит.

Вещь 2 : с пакером надо РАБОТАТЬ. Наплюйте на файловые анализаторы, generic-анпакеры (например, такие как проект GUW by Christoph Gabler - http://wave.prohosting.com/mackt/main.htm) - это все хорошо, но разработать общее решение пока не удается. Уж больно много всего учитывать надо. Требуется больше времени и куда больше усилий, чтобы разработать общую схему, если она существует.

Информационное поле статьи было чудовищным и неподъемным для одиночки. Мне помогали очень многие люди и всем им я хочу сказать – без вас этой статьи бы НЕ БЫЛО! Мы с Four-F плечом к плечу прошли через структуры кольца-3 и кольца-0 и когда я начинал захлебываться в этом – меня было кому поддержать! Sten всегда откликался на призывы о помощи и мы вели долгие беседы о SEH. Dr.Golova долго и терпеливо вразумлял неуча о трюке с NtContinue , а также долго и нудно многократно вычитывал эту статью в поисках ошибок. Fixer и Alephz были со мной во время написания главы о сигнатурах. Alephz любезно предоставил исходный код СС – утилиты-поисковика сигнатур криптоалгоритмов в исполняемом файле (доступна для скачивания с wasm.ru), а Fixer выработал ряд правил для описания сигнатуры. Умничка Quantum... В одиночку UPX я бы не поднял никогда. А сколько времени он потратил, трудолюбиво переводя с испанского все турториалы Рикардо Нарвахи и сколько времени было потрачено в попытках извлечь оттуда какие-нибудь ценные методики или приемы... The Svin и мр. Хемуль Советикус вместе с masquer крепко пинали за декомпилирование. Broken Sword был моим консультантом по DR-регистрам, а Edmond сумел сверстать эти 40 страниц ужаса. Asterix пинался по поводу Aspack , вынуждая нас с NEOx ’ом снова и снова переписывать ту несчастную главу, а seeQ , гм, seeQ просто сказал много хороших слов, в которых я нуждался после пинков Asterix. Спасибо также Kai Zheng , который любезно согласился перевести китайскую статью по telock и директории импорта. Скажите этим людям спасибо! Они много сделали для вас, читатель!

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

Вообще, в крэкинге существует два пути. Первый - путь глубокого анализа, изучения и достижения понимания того, как работает программа. Этот путь весьма надежен, но для получения гарантированного результата он требует много времени, усилий и практического опыта. В наше время главным критерием является эффективность и скорость взлома, а не "правильность", которая интересна лишь "гуру" и вечно недовольным теоретикам. К тому же, если Вы только начали обучаться крэкингу, у Вас может просто не оказаться нужных знаний и опыта, чтобы знать, в каком направлении нужно двигаться. Итак - налицо парадокс: чтобы приобрести опыт, нужно ломать программы, причем ломать успешно, и чем больше - тем лучше, а ломать их не получается из-за недостатка опыта. Но существует второй путь - исследовать программы, исходя из предположений, которые, в свою очередь, строятся на наблюдении за внешними эффектами, производимыми программой. То есть Вы не начинаете сразу выяснять, что и как происходит в недрах кода программы, а сначала делаете предположения: "на что это может быть похоже", "как это может быть реализовано" и "как бы я добился такого эффекта, будь я автором программы". Как ни странно, при использовании этого метода, успех зависит не только от знаний, но и от того, насколько богато Ваше воображение. Эффективность дзен-крэкинга опирается, прежде всего, на наблюдения и смелые предположения. Поэтому не надейтесь, что авторы защит будут применять избитые приемы, которые можно аккуратно переписать на бумажку и составить "инструкцию по взлому". Ожидайте неожиданного!

Однако Вы не можете строить предположения о работе программы на пустом месте - Вам потребуется некий стартовый набор знаний. Поэтому Вы должны собрать как можно больше информации о самой программе - выяснить, упакована она или нет, какие ограничения содержатся в незарегистрированной программе и как выглядит процесс регистрации; узнать, что будет, если Вы попытаетесь использовать программу дольше, чем это предусмотрено триальными ограничениями; проанализировать, какие текстовые строки и ресурсы содержатся внутри программы; поинтересоваться, к каким файлам и ключам реестра программа обращается при запуске, и многое другое. Не поленитесь заглянуть в справочную систему программы - там Вы можете, к примеру, найти описания различий между зарегистрированной и незарегистрированной версией. Значительная часть этой информации Вам скорее всего не пригодится, но Вы не можете знать заранее, какой путь окажется наиболее удобным и какие знания о программе Вам понадобятся, а какие - нет. Более того, почти наверняка все необходимые данные о работе программы Вы с первой попытки не соберете, и уже в процессе изучения кода Вам придется возвращаться к этому этапу, чтобы узнать, например, при каких условиях программа в заданной точке вызывает функцию создания файла, куда считываются введенные серийные номера, сколько раз и откуда программа вызывает функцию проверки регистрации и т.п. А потому - собирайте информацию!

Когда Вы сгенерировали идеи о том, как именно могут работать интересующие Вас механизмы в программе, начинается этап проверки правильности Ваших предположений. А значит, следующая Ваша задача - добраться до кода, который эти предполагаемые Вами механизмы мог бы реализовывать. Для этого Вам нужно проанализировать все предполагаемые варианты и найти, к чему можно "прицепиться" в каждом случае. Иными словами, Вы должны представить, чем может отличаться интересующий Вас кусок кода от множества других кусков, и чем более явными будут эти отличия, тем легче Вам будет этот код найти. Например, если программа выводит nag-screen, можно "прицепиться" к функциям создания и отображения окон; если предполагается проверка CRC файла, результатом будет либо многократное чтение небольших блоков, либо загрузка или отображение всего файла в память; если в заголовке окна программы большими буквами написано UNREGISTERED, можно поискать эту строчку в программе и выяснить, откуда и при каких условиях происходит обращение к этой надписи.

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

Как это работает на практике? Представьте себе программу, которая делает нечто. Например, отказывается запускаться после 30 дней использования, выдавая стандартное окошко с сообщением (широко известное как MessageBox). Чтож, у нас есть первое наблюдение. Простой перевод системного времени не помогает - обмануть программу и заставить ее работать дольше, чем положено, не удается. Это второе наблюдение. Из него следует, что программа проверяет текущую дату не (или не только) на основе показаний внутренних часов Windows. Предполагаем, что программа либо уже сделала пометку "больше не запускаться" где-нибудь в реестре или на диске, либо все-таки определяет текущее время, но каким-либо хитрым способом. Например, читая дату последнего доступа или модификации какого-либо файла. У нас уже есть целых два смелых предположения, которые можно брать за основу в дальнейшем расследовании вредительской деятельности защиты. Если программа не просто "задумывается" при запуске, но еще и шуршит винчестером, вероятность второго варианта сильно повышается. Теперь начинаем проверять эти варианты. В первом случае нам однозначно проще докопаться до истины, установив точки останова на все виды MessageBox'ов и выяснять, какой из условных переходов позволяет избежать появления этого сообщения. Во втором случае в качестве отправной точки можно использовать всевозможные GetFileTime, CompareFileTime (а чем не способ - сравнить дату создания файла программы, т.е. дату инсталляции с датой последней модификации какого-либо файла) и FindFirstFile/FindNextFile (они ведь тоже способны читать временные характеристики файлов).

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

Теперь, когда мы знаем, что нам нужно искать, осталось только определить, как выглядят эти уязвимости. Наиболее "удобные" для крэкера дыры - это прежде всего глобальные переменные, в которых хранится состояние программы ("зарегистрирована - не зарегистрирована"), функции, возвращающее критичное для защиты значение (число запусков или дней до истечение триала, результат проверки серийного номера на правильность) и процедуры, выводящие сообщение об успешной или неуспешной попытке регистрации, а также об истечении триального срока программы. Одним из величайших "шедевров", встреченным мной, была глобальная переменная в секции инициализированных данных. По умолчанию ее значение было равно нулю, и менялось на единицу если серийный номер, извлекаемый из реестра, был верен. Исправление одного-единственного бита превратило программу в зарегистрированную. Другим перспективным приемом, который, правда, эффективен в основном против ограничений максимального/минимального значения какого-либо числового параметра (количества обрабатываемых документов, числа запусков и т.п.) является поиск константы, с которой производится сравнение, и модификация либо самой константы, либо условия проверки. Более подробно о том, как обращаться с переменными и константами, я расскажу в соответствующей главе.

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

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

Другая проблема для программистов защит, которая сильно облегчает жизнь крэкерам (вот уж воистину "что русскому хорошо, то немцу - смерть") это "проблема условного перехода". Эта проблема заключается в том, реализовать проверку какого-либо условия, не использовав команду условного перехода, не так уж просто. Зато если этот условный переход есть, его легко можно исправить на такой же, но с противоположным условием - обычно для этого достаточно изменить ровно один бит. Несмотря на техническую простоту, правка условных переходов все-таки менее предпочтительна, чем модификация функций. Причина этого в том, что условных переходов, имеющих отношение к защите, в программе может быть довольно много, и их поиск требует особой внимательности. К тому же, если защита вместо обычных функций использует inline-функции или макросы, разбросанные по всей программе, защитный механизм выглядит как длинный и внешне однородный кусок кода. Поиск "плохих" переходов внутри такого "монолитного" кода может быть довольно затруднителен. С другой стороны, если в таких защитных вставках используются вызовы каких-либо "нормальных" (не inline) функций, особенно функций WinAPI, найти такие идентичные куски становится не так уж сложно. В таком блоке кода почти наверняка найдутся последовательности команд, по которым такие защитные вставки можно идентифицировать - так что поможет либо поиск в двоичном файле программы с использованием маски, либо в дизассемблированном тексте - с использованием регулярных выражений. Если запастись терпением, можно даже проверить все подозрительные участки программы вручную, это вполне реально, если таких участков в программе не больше двух десятков.

Теперь Вам известны наиболее часто встречающиеся в защитах дыры, в выявлении которых заключена половина успеха крэкера. Пришло время рассмотреть трудности и "подводные камни", которые могут ожидать Вас в нелегком кэкерском труде. Прежде всего это проблема неверной интерпретации собранной информации. Например, Вы обнаружили, что программа поддерживает использование плагинов и при запуске сканирует все файлы с расширением DLL в собственной директории. Вы вполне логично предполагаете, что программа строит список плагинов для дальнейшей загрузки и подключения. А потом Вы можете очень долго искать механизм определения даты первого запуска - и не найти его. Потому что он уже отработал - как раз при поиске плагинов. Как такое может быть? Да очень просто: в комплект программы включается как минимум один плагин. Далее - обычная привязка к дате последней модификации файла этого плагина; саму дату модификации файла несложно получить в ходе поиска через FindFirst/FindNext. Вот так иногда авторы защит прячут свой вредительский код, что называется, "на самом видном месте".

Другой пример неверной интерпретации собранных данных встречается еще чаще; более того, это неизбежное следствие подхода, используемого в дзен-крэкинге. Если Вы нашли условный переход, который начисто "выключает" все сообщения о незарегистрированности программы, из этого не обязательно следует, что программа будет вести себя в точности как зарегистрированная. Убедиться в стопроцентной надежности (или принципиальной неправильности) исправления этого перехода - подчас задача много более сложная, чем найти этот самый условный переход. Что интересно, это утверждение работает и в обратную сторону: если Вы что-то сделали, но не получили немедленно желаемый результат, это совершенно не означает, что Вы ошиблись. Создатели защит не так уж редко создают многоуровневую оборону, и в этом случае для одержания победы недостаточно разрушить внешние рубежи защитного кода. Если вы что-то сделали, но не добились успеха, не стоит сразу же бросать избранный путь; возможно, что Вы абсолютно правы и необходимо двигаться тем же путем и дальше. Даже если после Ваших манипуляций подопытная программа рушится с "ужасным" GPF, этот GPF может быть всего лишь еще одной, еще не выявленной уловкой создателя защиты.

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

Итак, многие программы в настоящее время поставляются в виде инсталляционного пакета. Для установки программы, как правило, требуется либо запустить один из файлов пакета (это, в частности, отлично всем известные Setup.exe), либо открыть при помощи другой заранее установленной программы (к примеру, файлы с расширением MSI, созданные Microsoft'овским инсталлятором или RPM-пакеты в Linux). В инсталляционных пакетах кроме самих файлов, которые требуется установить на машину пользователя, содержится также описание сценария инсталляции в том или ином виде (назовем это описание сценария для простоты "инсталляционным скриптом", тем более, что чаще всего так оно и есть). Разумеется, инсталлятор может быть и обычной программой, написанной для установки конкретного приложения, но написание собственного инсталлятора - дело достаточно трудоемкое, и поэтому на практике такие инсталляторы встречаются весьма редко.

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

" !IDA DEBUGGER!

В чем новизна и удобство идеи? А в том, что можно сделать не полный, а контекстный отладчик! Что это такое? Обычный дебаpег отлаживает всю программу целиком. Это хоpошо, но чаще всего нас интересуют только выбранные фрагменты. В IDA можно подогнать куpсоp к нужному месту, задать начальные значения pегистpов и пусть на выполнение эмулятоp. Такой подход пpежде всего упоpщает задачу, т.к. тут скоpость не тpубуется. А как удобно! Можно видеть pаботу кода в динамике! И не ломать голову какие будут значения pегистpов\флагов на выходе из такого и такого фpагмента и куда метнеться условный пеpеход. Можно просто прогнать чисто локальный кусок с любой его точки."

Я понимаю, что отладчик для IDA, начиная с версии 4.5 существует, но во-первых не у всех она есть, во-вторых создать отладчик своими руками очень даже интересное дело, поможет поближе ознакомится с устройством IDA и её плагинов. Информация по написанию плагинов для дизассемблера есть в примерах SDK. Сразу надо сказать, что это будет контекстный эмулирующий отладчик 32 разрядного режима. Он будет тесно взаимодействовать с пользователем по части работы. Ну например если эмуляция какой-то команды отсутствует, то предлагается, что пользователь сам проэмулирует её и скорректирует значения регистров, стека.

Предлагаю свой проект, как один из вариантов. Писал я его из-за желания поглубже узнать IDA. Если его довести до ума, то может получится очень полезный program, который может помочь при ручной распаковке и анализе программ.

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

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

Управление ведется с консоли дизассемблера-как вызов функций. Также можно организовать "горячие" клавиши. Вывод информации на экран - посредством окна сообщений и информативных окошек. Самое интересное - эмуляция команд. После подвода курсора к нужному адресу и ввода начальных значений в регистры, начинается работа отладчика.

В качестве подопытной была взята IDA 4.5 internal (лежала на www.crackbest.com). Также необходим SDK. Без SDK в создании плагинов делать нечего. Команды управления отладчиком были введены при помощи IDC скрипта - "deb_comm.idc". Этот скрипт компилируется во время инициализации плагина (скрипт должен лежать в директории idc дизассемблера), если потерпит неудачу, то можно попытаться загрузить скрипт вручную из меню File\IDC file. Именно в этом скрипте находятся вызовы функций отладчика, можете повесить на функции "горячие клавиши", и добавить новые. Здесь показан формат вызова команды отладчика:

Которую после добавления в "deb_comm.idc" можно будет вызывать прямо с консоли, например так: MY_NEW_COMMAND(); . Только незабудьте перед этим вставить в функцию run() плагина обработчик этой команды, которая будет обрабатываться, если аргумент будет равен MY_FUNC_ID.

Для написания отладчика надо знать, об виртуальной памяти. Подробнее смотрите "Образ мышления IDA" Криса Касперски. Прошу простить меня за такое представление виртуального адресного пространства IDA и её базы данных, это упрощено, но отладчик работает именно с данными в виртуальной памяти, в которой лежит база данных. На рисунке показано соотношения между адресами (названия взяты от самого создателя IDA):

Линейный адрес (тип ea_t) - это адрес в виртуальном пространстве IDA Базовый адрес сегмента - это линейный адрес начала сегмента в виртуальном пространстве IDA Виртуальный адрес - это смещение между линейным адресом и базовым адресом сегмента: Виртуальный адрес=Линейный адрес - Базовый адрес сегмента Как вы уже , наверно, знаете, IDA работает со своим виртуальным пространством, а для дизассемблированной программы создаются сегменты со своими атрибутами (база, селектор разрядность и.т.п.), и с ним же будет работать и наш отладчик, через функции get_byte(..), get_word(), get_long, patch_byte, patch_word, patch_long - все они определены в BYTES.HPP, и там ещё много интересного есть. Линейный адрес вычисляется как

(Base <<4+смещение), где Base - база сегмента

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

Like the Intel486 CPU, integer instructions traverse a 5 stage pipe-line. The pipe-line stages are as follows:

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

Чтобы приступить к непосредственной эмуляции, давайте разберемся, как IDA хранит инструкции. Для этого имеются несколько структур, они описаны в файле INCLUDE\UA.hpp. Этот файл ОЧЕНЬ важен при написании эмулятора, т.к. в нем описывается формат данных команды, её операндов их типы.

В структуре optype_t есть следующие поля:

char specflag1;

char specflag2;

char specflag3;

char specflag4;

Эти флаги заполняются ядром ИДА (точнее процессорным модулем). Как заполняются не сказано, но, проведя эксперименты, с различными инструкциями и способами адресации, удалось выяснить вот что:

Флаг specflag1 и все остальные равен нулю если:

1. Имеется прямая адресация (OpX.type=o_mem). Т.е. например mov eax,[401000]

2. Косвенная адресация (OpX.type=o_phrase) mov eax,[eax]

3. Косвенная адресация со сдвигом (OpX.type=o_displ) mov eax,[eax+402031]

Если specflag1==1 , то в specflag2 содержится информация об составляющих операнда (например при индексной адресации с масштабированием) Если OpX.type=o_phrase , то specflag2 будет расшифровываться так:

Кодировка регистров в точности, как принята у Intel:

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

Например :

Если OpX.type=o_mem , то specflag2 будет расшифровываться так:

Если OpX.type=o_displ , то specflag2 будет расшифровываться так:

Также в этом случае, в поле OpX.addr , будет находится значение смещения

Однако здесь есть одно исключение для обращения к памяти вида: [esp+xxx] В этом случае specflag1=1; specflag2=0x24

Разберемся с сегментами IDA. Сетменты в IDA-один из её краеугольных камней. И надо ознакомится со структурами, которые их описывают: Нам они понадобятся для создания сегмента стека отладчика. Без него работать, мягко говоря некорректно. Каждый сегмент имеет базовый сегментный адрес, который определяет положение сегмента в виртуальной памяти IDA. В поле Base может находится базовый адрес, а может находится индекс селектора. Селектор содержит 32-битный базовый адрес сегмента в виртуальном пространстве IDA. Подробнее смотрите "Образ мышления IDA" Криса Касперски.

Данные и функции работающие с сегментами содержатся в заголовочном файле SEGMENT.HPP . К сегментам можно обращаться разными способами. Тип структуры, описывающею сегмент segment_t. В ней содержится вся информация о сегменте: База, начальный адрес, конечный адрес, имя сегмента, выравнивание сегмента, разрядность 16 или 32 бит, и.т.д.

Вот как примерно выглядит создание сегмента стека для отладчика. Подробное описание функций смотрите в SEGMENT.HPP

Как видите, ничего сложного нет.

В эмуляторе всю работу по исполнению инструкций выполняют обработчики команд. Было решено в обработчик передавать тип соотношения операндов (например: один операнд - регистр, один операнд в памяти, один регистр - другой в памяти). В исходниках это выполняет функция get_operand_info(OPER &), которая заполняет структуру OPER. Также она заполняет поля структуры: вычисленными значениями операндов (например, при косвенной адресации). Сам обработчик команды знает о том какие операнды и какие сочетания операндов возможны и в зависимости от этого выполняется. Покажу на примере инструкции push:

Это одна из "частных" инструкций и для других писать обработчик намного проще. Например эмуляция инструкции cmp

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

Перед написанием обработчика инструкции, неплохо бы узнать, что возвращает структура cmd , так как может отличаться для разных инструкций. Например для инструкции lea eax,[ebx] cmd.Op1.dtyp = dt_dword , а cmd.Op1.dtyp = dt_byte. Поэтому ,возможно, придется добавить обработку ситуации в функцию get_operand_info.

При написании обработчиков ОЧЕНЬ неплохо помогает справочник из книги Юрова "Ассемблер", там расписаны все типы операндов команд и алгоритм их работы.

На данный момент поддерживается:

1) Точки останова BPX,

2) BPM_R, BPM_W, BPM_RW

3) Эмулировано 122 инструкции x86 (кроме 3-х операндных imul, shld, shrd, enter, leave и др., их можете реализовать сами.)

Команды управления отладчиком можно уточнить как help(); из консоли IDA.

Надо добавить: 1) Создать нормальный показ регистров в отладчике в виде отдельного диалогового окна

2) При желании можно добавить эмуляцию FPU, MMX

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

В приложении содержится исходный код отладчика, а также скомпилированная версия плагина для IDA 4.5 Похоже, что файл plugins.cfg необязателен (ИДА 4.5), т.к. и без него плагин вызывался нормально. Подозреваю, что ИДА сканирует директорию с плагинами и узнает параметры через структуру PLUGIN. Если неполучится, то добавьте следующую строку:

CDEx86 CDEx86 F11 0

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

Первые шаги по работе:

1) Скопируйте CDEx86.plw в папку \plugins дизассемблера.

2) Запустите дизассемблер

3) Приведите курсор к куску кода, который хотите изучить, и начинаите трассировку ( по умолчанию клавиша F11)

4) Значения регистров можно посмотреть вызвав r(); из консоли (Shift+F2). В следующей версии ,возможно, будет отдельное окно с регистрами.

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

bpx();

at();

Точно так устанавливаются виртуальные бряки на чтение\запись в память bpm();

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

1) Отладчик предполагает хорошие навыки работой с IDA.

2) Не надо лезть в вызов WinAPI функции, т.к. ее кода нет в дизассемблере и соответственно нельзя ее трассировать. Лучше всего перепрыгнуть её ( cheip(); ), сбалансировав стек.

3) Отладчик получает инструкцию по адресу курсора IDA. Поэтому если вы прыгнете на середину команды, то получите сообщение Not code. Stay at code first. В этом случае надо сперва превратить в Unknown, а затем превратить в Code.

4) Необходимо создать окно, в которое выводить информацию. В первую очередь - значения регистров Т.к. неудобно каждый раз вызывать команду r();

Ненадо требовать от контекстного отладчика сверхъестественного. Я писал его лишь из-за интереса к внутреннему устройства IDA. Если чего-то нехватает, добавьте сами - исходники есть.

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

Алгоритм примерно выглядит следующим образом:

1. Загружаете файл как бинарный

2. Применяете PE_scripts by Atli Gudmundsson (есть на wasm.ru)

3. Пробуете трассировать его с точки входа

4. Сохраняете на диск заголовок и секции при помощи скрипта pe_write.

(А еще лучше написать свой. Т.к. больше шансов получить работоспособный файл)

И напоследок, хотелось бы сказать большое спасибо Крису Касперски, за его отличные книги и статьи.

, а также создателям WASM.RU за то, что есть такой замечательный ресурс

1. pilorama.com.ru

2. Юров В., Хорошенко С. Ассемблер: учебный курс

3. Зубков С.В. Ассемблер язык неограниченных возможностей

Жду поправок и более крутых решений

Исходник (находится в архиве wasm_files.zip: files/recovered/306/emul_plug_ida.zip) к статье.

- Модификация константы

- Изменение значения предварительно инициализированной переменной

- Изменение условия перехода на противоположное

- Удаление линейной, то есть не содержащей ветвлений и вызовов нетривиальных подпрограмм, последовательности команд

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

- Модификация внедренного в программу ресурса, важного для логики программы (т.е. такого, изменение которого меняет поведение программы)

- Удаление из программы логического блока (например, вызова нетривиальной функции); удаление внедренного в программу ресурса

Этот принцип, как любое другое широкое обобщение, требует достаточно осторожного отношения и в некоторых случаях может повести Вас по неоптимальному пути. Но на практике принцип минимального вмешательства обычно работает вполне успешно. Да и с точки зрения простого здравого смысла очевидно, что найти и исправить условие, которое проверяет зарегистрированность программы – прием куда более безобидный и надежный, чем вырывание с корнем nag-screen’ов и триальных ограничений при помощи глубокого патчинга.

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

Наверное, наиболее распространенным типом данных, используемым в программах, в настоящее время являются целочисленные данные. Абсолютное большинство существующих процессоров, в том числе и наши любимые x86, изначально ориентировались на работу с целыми числами определенной разрядности (в настоящее время на платформе x86 наиболее актуальны 32-разрядные целые со знаком или без). Именно в виде целых чисел чаще всего хранятся всевозможные счетчики, контрольные суммы и даже логические значения (когда я переходил от программирования под ДОС к программированию под Win32, меня сильно удивляла расточительность фирмы Microsoft, отводившей под простую булевскую переменную целых 4 байта. И только более глубокое изучение архитектуры 32-разрядных процессоров и ассемблера расставило все по своим местам).

Что Вы будете делать, если Вам потребуется найти в программе сравнение чего-либо с целочисленной константой с определенным значением? В принципе, для некоторых целых чисел достаточно обычного поиска блока двоичных данных в файле. Однако двоичный поиск хорошо работает далеко не со всеми числами: скажем, если Вы ищете число 3B9ACA00h, вероятность ложного срабатывания будет весьма небольшой, а вот если Вы попытаетесь найти в исполняемом файле число 10 или 15, Вы, скорее всего, просто устанете нажимать на кнопку «Найти далее». Кроме того, при таком способе поиска не учитывается структура исполняемого файла программы, то есть Вы ищете нужную Вам константу не только в коде программы, но и в PE-заголовке, секции данных, секции ресурсов и прочих областях, имеющих к коду программы самое отдаленное отношение.

Однако есть и другой, более эффективный метод поиска в программе известных заранее значений. Как это ни странно, но в реальных программах широко используется лишь сравнительно небольшой набор целочисленных констант: это, прежде всего, небольшие положительные числа от 0 до 7 (а также небольшие отрицательные от -3 до -1) и степени двойки: 8, 16, 32 и т.д. Другие константы в программах встречаются значительно реже. Попробуйте сами провести эксперимент – дизассемблируйте какую-нибудь достаточно большую программу и попробуйте найти в ней какое-нибудь число, например, 32h. Для демонстрации этого я написал программку на Delphi 7, вся функциональность которой концентрировался в следующем коде, имитирующем простейшее ограничение на число строк в документе:

В результате компиляции этот весьма нехитрый текст превратился в исполняемый файл размером более 350 килобайт (я намеренно использовал режим компиляции без использования runtimepackages, и потому мой собственный код составлял в исполняемом файле очень малую долю по сравнению с библиотеками Delphi). Затем я дизассемблировал откомпилированную программу при помощи W32Dasmи получил листинг текст длиной более 180 000 строк. Казалось бы, обнаружить область, где происходит сравнение с числом 50 в этом листинге ничуть не проще, чем найти иголку в стоге сена. Но я воспользовался функцией поиска в тексте строки, в качестве параметра поиска указав 00000032 (так в W32Dasmотображается число 50; заодно это позволило отсеять команды типа moveax,[ebx+50h], обычно использующиеся для доступа к элементам массивов и полям структур). Реальность превзошла самые смелые ожидания: четырехбайтное число 32hвстретилось в листинге всего два (!!!) раза:

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

Далее: Вам наверняка интересен не сам факт наличия константы где-то в недрах кода, а то, в каком контексте эта постоянная используется. Иными словами, если Вы знаете, что программа сравнивает число записей в базе данных с некоторым значением (в нашем случае - 32h), то среди всех строк, в которых присутствует эта константа, в первую очередь следует рассматривать команды сравнения (cmp) и вычисления разности (subи sbc), и лишь затем – все прочие, менее очевидные способы сравнения вроде

или

Ну и, раз уж речь зашла о сравнениях, нельзя не упомянуть об альтернативных вариантах реализации этой, казалось бы, нехитрой операции. Поразмыслим над приведенным выше примером сравнения содержимого регистра eax с числом 50. В самом деле, условия eax>50 и eax>=51 в приложении к целым числам имеют один и тот же смысл, а код

работает совершенно аналогично коду

Если же eaxнеобходимо сравнить с числом 31, проверка может выглядеть даже так:

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

Если рассматривать области возможного практического применения вышеописанного приема, то лучше всего поиск известной константы в дизассемблированном тексте работает на триальных ограничениях типа «не допускается создание больше Nэлементов в базе данных». Как правило, Nбольше 7 и является целым числом, что облегчает поиск нужной константы. Исходя из принципа минимального вмешательства, для обезвреживания таких ограничений я предпочитаю исправлять не команды сравнения, а сами константы. Действительно, если программа для проектирования интерьера комнаты не способна работать более, чем с 20 объектами, для практического применения она вряд ли будет пригодна. Но вот та же программа, где максимальное количество обрабатываемых объектов увеличено до двух с хвостиком миллиардов наверняка удовлетворит даже самого взыскательного пользователя.

Одним из наиболее частых вопросов, возникающих у начинающего крэкера, звучит так: «Программа работает 30 дней, но я так и не нашел в листинге сравнения с числом 30. Что делать?». Один из факторов я уже описал выше – там могло быть сравнение не с числом 30, а с числом 31. Однако этим список возможных причин неудачи не исчерпывается. Как мы все знаем, день состоит из 24 часов, каждый из которых состоит из 60 минут, каждая из которых состоит из 60 секунд. Более того, продолжительность секунд также может измеряться во всевозможных «условных единицах», например, в миллисекундах. Тысячные доли секунд, в частности, используются в таких функциях WinAPI, как SetTimer (таймеры Windowsчасто используются для установки ограничений на продолжительность одного сеанса работы с программой) или Sleep. А вот в функциях, возвращающих время в виде структуры типа FILETIME, используются уже другие «условные единицы», равные ста наносекундам. Так что пресловутые 30 дней – это не только 30 дней, но еще и 720 часов, 43200 минут, 2592000 секунд, ну и так далее. И каждое из этих значений может быть использовано в программе как один из аргументов операции сравнения. Надо отметить, что в «условных единицах» может быть представлено не только время, но и многие другие величины: масса, географические координаты, денежные единицы и т.д.

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

Вообще в Windowsсуществует несколько разновидностей таймеров – кроме обычного таймера, создаваемого функцией SetTimer, существует еще высокоточный мультимедийный таймер и специфические таймерные функции DirectX. Эти таймеры срабатывают с некоторой заданной частотой, вызывая функцию-обработчик (она же callback-функция), внутри которой и выполняются необходимые действия, например, тот же обратный отсчет секунд до исчезновения окна с предложением зарегистрироваться. Периодичность срабатывания таймера почти всегда является константой, однако взаимосвязь между тем, что происходит внутри программы и тем, что Вы можете видеть на экране, не всегда очевидна. Чтобы пояснить эту мысль и заодно продемонстрировать на практике, как можно обращаться с таймерами, приведу несколько примеров.

Первый пример – простейший: программа, которая при запуске в течение пяти секунд показывала баннер, при этом поверх баннера выводился обратный счетчик секунд. Регистрация в программе не предусматривалась. Дизассемблирование показало, что таймер срабатывает каждые 1000 миллисекунд, при каждом вызове callback-функции значение переменной, изначально равной пяти, уменьшалось на единицу, и результат проверялся на равенство с нулем. В той конкретной программе баннер можно было просто «выломать», убрав функцию создания и отображения рекламного окна, но в общем случае это решение было бы не лучшим (вспомните принцип минимального вмешательства). И вот почему: на последнее срабатывание таймера могло быть «подвешено» не только закрытие окна с баннером, но и инициализация каких-либо объектов внутри программы или другие критичные действия, без которых программа могла бы работать некорректно. Так что немного усложним задачу – будем считать, что полностью убирать вызов окна с рекламой нельзя. Первое, что нам приходит в голову – уменьшить число секунд, в течение которых показывается баннер. Сказано – сделано, цифру 5 исправляем на единицу. Однако баннер все равно висит целую секунду – ведь первое срабатывание таймера наступает только через секунду после его создания. Теперь уменьшим период таймера до нуля (хотя лучше все-таки до одной миллисекунды, «таймер с периодом 0 миллисекунд», согласитесь, штука довольно странная). В результате мы получили баннер, появляющийся при запуске программы лишь на мгновение и не заставляющий тратить целых пять секунд на праздное разглядывание рекламных лозунгов.

В качестве второго примера я возьму одну из старых версий TVTools. В справке к программе было четко указано, что незарегистрированная версия работает только 10 минут; дизассемблирование и анализ листинга выявили, что программа создает два таймера с периодами 60 секунд (что навело меня на мысли о защитном назначении этого таймера) и 2 секунды. Без особых сложностей обезвредив первый таймер, я запустил программу и обнаружил, что она все равно больше 10 минут не работала. Тогда я более пристально изучил callback-функцию второго таймера, и наткнулся в ней на такой код:

Нетрудно догадаться, что это увеличение некоего счетчика, который затем сравнивается с числом 310. Поскольку период таймера – 2 секунды, а 310*2=620 (т.е. чуть больше 10 минут), логично было предположить, что это и есть второй уровень защиты, дублировавший первый. Очевидно, что если бы я принял на веру, что программа перестает работать ровно через 10 минут (а не через 10 минут 20 секунд, как это оказалось в действительности) и стал бы искать сравнение с числом 300, я бы не смог обнаружить таким способом вторую проверку времени работы программы. Этот пример демонстрирует один из неочевидных приемов, который может быть использован для реализации такой, казалось бы, простой операции, как отсчет 10-минутного интервала. Также из этих примеров следует и другой, не менее важный вывод: далеко не всегда следует искать известную константу, чтобы найти код, в которой она используется. Иногда следует поступать прямо противоположным образом – сначала искать код, выполняющий нужные действия, и лишь затем выяснять, какая константа внутри этого кода ответственна за интересующие нас действия.

Поиск констант с плавающей точкой – занятие с одной стороны более сложное, чем поиск целочисленной константы, но с другой – куда более простое. В чем сложность и в чем простота этого занятия? По традиции начнем с плохого. Во-первых, формат представления чисел с плавающей точкой весьма нетривиален, и Вы вряд ли сможете в уме привести шестнадцатиричный дамп такого числа в «человеческий» вид (возьмите документацию по процессорам Intel и попробуйте перевести число 1.23 в машинное представление, а затем проделать обратную операцию – Вы сами убедитесь, насколько сложна эта задача). Более того, даже целые числа в представлении с плавающей точкой выглядят весьма неординарно: к примеру, дамп самого что ни на есть обычного числа 123, приведенного к типу Double, выглядит как 00 00 00 00 00 C0 5E 40. Если Вы способны с первого взгляда отличить число с плавающей точкой от кода программы или каких-либо иных данных и оценить величину этого числа – я рад за Вас, но большинство людей, к сожалению, такими способностями не обладают.

Во-вторых, при работе с дробными числами нередко возникают проблемы, связанные с машинным округлением и потерей точности. Самым ярким примером, наверное, может служить особенность математических программ ПЗУ некоторых моделей Spectrum: с точки зрения такого Спектрума выражение 1/2=0.5 было ложным. Это, конечно, было давно, но не следует считать, что современные компьютеры полностью свободны от этой проблемы. И вот практическое тому подтверждение.

Откомпилируйте под Delphi следующий код: i:=sin(1); i:=arcsin(i) и посмотрите, как будет меняться результат при изменении типа переменной Iот Singleдо Extended. Например, если I имеет тип single, в результате вычислений получим, что arcsin(sin(1))=0,999999940395355. Такие «спецэффекты» – следствие все той же потери точности в процессе вычислений.

В-третьих, округлением чисел процессор может заниматься не только по собственному желанию, но и по велению программы. К примеру, в большинстве бухгалтерских программ всевозможные ставки налогов выводятся с точностью до копеек. Однако из того, что Вы видите на экране число 10.26, совершенно не следует, что результат расчетов представлен в памяти ЭВМ именно как 10.26. Реальное значение соответствующей переменной может быть равно 10.258 или 10.26167, которое и участвует в реальных расчетах, и лишь при выводе на экран для удобства пользователя было произведено округление до двух знаков после запятой.

Я не случайно столько места уделил округлению и точности представления чисел – именно эти особенности чисел с плавающей точкой в наибольшей мере затрудняют поиск нужных значений в памяти программы. Программисты знают, что при работе с действительными числами для проверки условия равенства некоторой вычисляемой величины другой величине не рекомендуется использовать сравнения вида f(a)=b. Причина этого лежит все в той же проблеме округления и потери точности расчетах – вспомните вышеприведенные примеры со Спектрумом или арксинусом синуса единицы. Вместо простой проверки равенства обычно используется условие «значения считаются равными, если абсолютная величина разности между ними не превышает некоторой величины»: abs(f(a)-b)<=delta, где delta – максимально допустимая величина разности, после которой числа не считаются равными. Поэтому если Вы хотите найти в памяти некоторое число с плавающей точкой F, Вы в действительности должны искать все числа из промежутка [F-delta; F+delta], причем определить значение deltaчаще всего можно лишь опытным путем. Это утверждение распространяется и на тот случай, когда Вы знаете округленное значение переменной, но в этом случае величина deltaбудет зависеть от того, до скольки знаков округлено значение переменной. Так, если число округлено до сотых, нетрудно догадаться, что delta=0.005.

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

И, наконец, нельзя забывать, что кроме стандартных для платформы x86 типов Single, Doubleи Extended (32-, 64- и 80-битных соответственно) существует еще несколько довольно экзотических, но все еще используемых форматов. Это, к примеру, Currency (64-битные, с фиксированным положением десятичной точки) или 48-битные паскалевские Real. Возможно также использование «самодельных» форматов; особенно часто встречаются числа с фиксированным положением десятичной точки (обычно такое делается для повышения скорости работы программы и применяется в основном в процедурах кодирования/декодирования аудио- и видеоинформации). Знать о таких вещах совсем не лишне, хотя, конечно, вероятность столкнуться с такими числами в современных программах довольно низка.

Теперь немного поговорим о том хорошем, что есть в числах с плавающей точкой. Как известно, изначально в процессорах x86 встроенных аппаратных и программных средств для обработки чисел с плавающей точкой не предусматривалось. Низкая скорость расчетов, в которых использовались действительные числа, вызвала к жизни математические сопроцессоры, как традиционные x87, так и весьма экзотические девайсы Weitek. Победившая линейка сопроцессоров x87 (они с некоторых пор стали интегрироваться в ядро процессора и потому перестали существовать как отдельные устройства) имела следующую особенность: новые «математические» команды активно использовали для обмена информацией оперативную память. Посмотрите, к примеру, на важнейшие команды сопроцессора fstи fld – в качестве параметра этих команд могут выступать указатели на области памяти, которые предполагается использовать для чтения/записи данных. Более того, использование указателей в качестве одного из параметров характерно и для многих других команд сопроцессора. Поэтому ищите ссылки, используемые командами сопроцессора в качестве параметров – и Вы легко доберетесь до данных, на которые эти ссылки указывают.

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

Но и здесь не обошлось без ложки дегтя – компиляторы фирмы Borland, видимо, ради особой оригинальности, для загрузки констант в стек сопроцессора могут воспользоваться комбинациями вроде

Хотя, казалось бы, ничто не мешало положить несчастное число в секцию инициализированных данных… Тут уж не до «умного» поиска – разобраться бы, чего и куда вообще загружается. Хотя, при желании и умении обращаться с регулярными выражениями (или умении программировать) можно искать даже в таком коде.

Другим свойством действительных чисел, облегчающим автоматический поиск известной величины, является само их внутреннее устройство. Достаточно большая длина этих чисел (32 бита, а чаше всего – 64 или 80) и сложный формат хранения позволяет искать числа с плавающей точкой в любых файлах, в том числе и в исполняемых файлах программ, непосредственно в двоичном виде, причем вероятность ложного срабатывания будет незначительной. Даже существование нескольких различных форматов представления действительных чисел не представляет серьезного препятствия – соответствующая программа очень проста и пишется за считанные минуты. Народная мудрость гласит: «лучше один раз увидеть, чем сто раз услышать», поэтому в качестве практики я рекомендую Вам самим написать и отладить такую программу – это не только усовершенствует Ваши навыки в программировании, но и позволит поближе познакомиться с миром действительных чисел. Затем, если захотите, Вы сможете доработать эту программу таким образом, чтобы она могла осуществлять нечеткий поиск в файле, о котором я говорил выше, то есть поиск всех значений, подходящих под заданный пользователем интервал.

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

Хранение строк в блоках фиксированного размера имело два принципиальных недостатка: неэффективное расходование памяти при хранении большого числа строк различной длины и жесткое ограничение на максимальную длину строки. Всех этих недостатков были лишены строки с завершающим символом. Идея была проста – выбирается какой-либо малоиспользуемый символ, который интерпретируется программой как признак конца строки. В языке Си таким символом стал символ с кодом 0 (а строки, оканчивающиеся нулем, окрестили ASCIIZ-строками); некоторые системные функции MS-DOSв качестве завершающего символа использовали символ “$”. Несмотря на ряд недостатков, строки с завершающим символом претерпели ряд усовершенствований и используются до сих пор. С началом активного использования UNICODEпоявилась модификация строк с завершающим символом и для этой кодировки. Зная образ мышления программистов на Си, нетрудно догадаться, что в качестве завершающего символа была использована пара нулевых байтов: (0,0). Нужно отметить, что если возникает необходимость укоротить такую строку в тексте программы на несколько символов, то обычно для этого достаточно всего лишь вписать в нужную позицию завершающий символ. То есть, если у Вас есть программа, написанная на C/С++, в заголовке окна которой написано что-то вроде «CoolProgram - Unregistered», и Вы не хотите видеть напоминание о том, что она «Unregistered», просто замените в файле программы пробел после слова Programна символ с кодом 0. После этого слово «Unregistered» Вы почти наверняка больше не увидите. Этим же способом ненужную строку можно вообще превратить в пустую, просто поставив в ее начало завершающий символ!

Описанная техника укорачивания и «обнуления» строк пригодна не только для того, чтобы убирать неэстетичные надписи в заголовках программ, в действительности ее возможности гораздо шире. Приведу пару примеров из собственной практики. Один раз мне в руки попалась некая программа, которая очень любила при печати документов в заголовок вставлять надпись «Thisreportcreatedbydemoversion …» шрифтом аршинного размера. Разумеется, мне это не понравилось и при помощи нехитрых манипуляций в шестнадцатиричном редакторе я «обнулил» строку с надписью, оскорблявшей мои эстетические чувства. В другом случае я подобным же образом расправился с одной программой-генератором справок, которая считала, что незарегистрированность – это повод вставлять рекламный текст в каждую статью справочной системы. Небольшой memorypatch, исправлявший в программе «на лету» несколько байт, смог убедить капризную программу в ее принципиальной неправоте.

Более эффективными по сравнению с ASCIIZ-строками являются строки с указанием длины. Такие строки позволяют использовать в тексте все 256 ASCII-символов, хранить не только текстовые, но и любые другие двоичные данные, а также применять по отношению к этим данным строковые функции. Кроме того, вычисление длины строки требует лишь одной операции чтения данных по ссылке, в отличие от ASCIIZ-строк, где для определения длины необходимо последовательно сканировать все символы строки до тех пор, пока не встретится завершающий символ. Как такового, стандарта на строки с указанием длины не существует – можно лишь говорить о конкретных реализациях таких строк в различных компиляторах и библиотеках. В частности, в коде программ на Delphi 7 строковые константы хранятся следующим образом:

• 4 байта: длина строки в байтах (для UNICODE-текстов это значение в два раза больше длины строки в символах).

• Содержимое строки.

• Завершающий символ (#0 для ANSI-строк, #0#0 для UNICODE-строк). Завершающий символ никак не используется в «родных» функциях и процедурах Delphi, но значительно упрощает вызов функций WinAPI (которые используют строки с завершающим символом) и использование сторонних библиотек.

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

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

Этот код представляет собой максимально упрощенную реализацию списка сообщений и функции, получающей адрес текстовой строки по номеру сообщения. Откомпилировав этот пример, загрузим его в W32Dasmи посмотрим, что получится. Получилось следующее: дизассемблер успешно распознал строку «Line 1», но строки «Line 2» и «Line 3» не обнаружил. А вот IDAуспешно распознал все три строки, и создал для них именованные метки. Впрочем, и IDAпри большом желании можно обмануть: достаточно лишь вписать перед текстом самой строки ее длину в байтах (именно так хранит строки Delphi). После этого IDAхотя и обнаруживает сам факт наличия текстовых строк в программе (в окне Stringsэти строки видны), но в дизассемблированном тексте программы эти строки выглядят как последовательность db… , которые нужно приводить в желаемый вид вручную. Кстати, W32Dasmпосле этой модификации не увидит вообще ни одной строки. Если же Вам и этого мало, вместо «Line 1» напишите «Строка 1» - все тексты на русском языке знаменитый дизассемблер гордо проигнорирует. И это только начало. А ведь текстовые строки могут находиться не только в сегменте кода/инициализированных данных, но и в секции ресурсов программы…

Здесь могут помочь специализированные программы, сканирующие указанный файл и вычленяющие из него все текстовые строки (или то, что похоже на текстовые строки). Кроме того Вам потребуются смещения этих строк от начала файла, поэтому Ваш инструмент должен предоставлять и такой сервис. Однако использование таких программ (и самостоятельное их написание) осложняется двумя факторами: разнообразием существующих кодировок текста и существованием национальных символов в некоторых языках (классический strings.exeи многие другие подобные программы «не понимают» русскую секцию UNICODE). Те же проблемы с UNICODEи национальными кодировками характерны и для программного обеспечения, осуществляющего поиск в текстовых файлах. К тому же русские тексты в UNICODEсовершенно нечитабельны в шестнадцатиричных редакторах и просмотрщиках. Все это необходимо учитывать при выборе инструментов поиска текстовых строк, а выбранный инструмент перед использованием желательно проверить на подходящем «пробном камне».

Напоследок расскажу про весьма простой, но весьма эффективный в некоторых случаях способ поиска численных переменных в работающей программе. Этот способ основан на многократном сканировании адресного пространства программы, отслеживании и анализе всех изменений в этом пространстве. Лучше всего этот прием работает на программах, в которых установлено ограничение на количество тех или иных действий, вроде ограничения на число записей, добавляемых в документ. И используется для этого совсем не крэкерский инструментарий. Вы, наверное, знакомы с программами типа GameWizardили ArtMoney, которые позволяют искать в работающей компьютерной игре количество денег или оставшихся жизней. Для тех, кто не сталкивался с такими программами, вкратце опишу алгоритм их работы:

1. Пользователь выбирает из списка работающих в данный момент программ подопытную игру.

2. Пользователь вводит в программу поиска начальное количество денег (хитов и т.п.), которое в данный момент существует в игре.

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

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

5. В программу поиска вводится новое количество денег.

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

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

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

Проницательный читатель наверняка уже догадался, что защищенная программа ничем в принципе не отличается от компьютерной игры, а число добавленных в документ записей – это то же самое, что количество виртуальных «золотых монет». И потому, воспользовавшись соответствующей программой (например, все той же ArtMoney), можно определить адреса всех переменных, которые могут хранить счетчик добавленных в документ записей. Дальнейшие действия зависят исключительно от Вашего желания – можно поставить аппаратную точку останова на чтение из этой переменной и попытаться добраться до команды сравнения существующего числа записей с максимальным. Можно погрузиться в изучение дизассемблерного листинга в поисках команды увеличения переменной и сделать так, чтобы значение счетчика не увеличивалось. Можно даже попробовать модифицировать счетчик из ArtMoney, посмотреть, что из этого получится, и если из этого получится что-то хорошее – написать memorypatch, каждые 100 миллисекунд обнуляющий счетчик.

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

• Введение - обзор утилит и доступной информации

• MSI – ресурсы

• IS – ресурсы

• MS CAB/IS CAB/самораспаковывающиеся файлы

• Методики взлома MSI-программ

• COM-интерфейс – радость для кракера?

• Подходы к IS-программам

• Поиск строки в памяти

• Интерпретаторы

• Компиляторы

• Практические примеры

• Заключение

• Благодарности

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

В этой статье мы хотим продемонстрировать различные подходы к исследованию программ, использующих технологию Install Shield (в дальнейшем – IS). IS используется при инсталляции практически любого серьезного программного продукта – дистрибутивы Adobe, Microsoft, Intel, Compuware и т.д., и т.п. Подход, предлагаемый в этой статье – декомпиляция сценария инсталляции – трудно назвать новым. В сети уже существуют утилиты и даны некоторые описания, однако, их сложно назвать современными. Все они безнадежно устарели. В представленной на ваше рассмотрение статье мы попробуем восполнить это упущение.

Статья не рассчитана на новичков. Мы предполагаем, что вы умеете пользоваться стандартным джентльменским набором: дизассемблер + отладчик, знаете ассемблер и C++, кроме того, слышали о технологии COM (Component Object Model). Если с COM вы не дружите совсем, не волнуйтесь, линков на литературу будет достаточно. Обещаем также, что вам придется разобраться с MSI.

Перед тем, как приниматься крушить все и вся, необходимо очень четко представлять себе теоретическую базу. Что такое «инсталляция» программы и какие технологии могут быть задействованы при этом? Технологий оных великое множество, мы не имеем возможности рассмотреть их все, а сфокусируем свое внимание лишь на двух – MSI (Microsoft Installer) и IS (InstallShield).

В качестве обзорной статьи по MSI прекрасно подойдет обзор Gary Chirhart http://www.wise.com/filelib/MSIwhitepaper.pdf.

Мы предполагаем, что вы прочитали эту статью и уже знаете, что такое MSI-файл, столь часто используемый при инсталляции программы. Также, вам уже должно быть известно, что MSI-файл предоставляет возможность доступа к своим данным при помощи SQL-запросов в сочетании с MSI API-функциями. Дополнительно о структуре MSI-файла можно почитать на RSDN.ru: http://www.rsdn.ru/article/install/wininstaller.xml?print

В качестве справочника по MSI API-функциям, разумеется, нужно использовать MSDN.

Нас с вами заинтересует раздел CustomActions в MSI-файле. Почитать о том, что это такое и с чем это едят можно здесь: http://www.codeproject.com/tips/msicustomaction.asp

Самой знаменитой утилитой для работы с MSI, вероятно, является MS ORCA, входящая в состав Platform SDK. Поскольку не все имеют возможность качать 200-мегабайтный минимум из-за одной-единственной утилиты, мы продублировали ее на wasm.ru. Дополнительно стоит ознакомиться со статьей http://www.codeproject.com/file/msiconsole.asp. (обязательно скачайте файлы - для этого требуется регистрация, но она бесплатна)

Есть также продукт под названием AdminStudio от IS Corp. На момент написания статьи текущей версией была 5.5. По своим функциональным возможностям примерно равен ORCA, только занимает не 2 мегабайта как ORCA, а 200. Да, есть еще и Wise for MSI и возможности утилиты достаточно велики. Правда, и размер, опять же, не мал…

У ORCA, однако, есть большой недостаток. В ходе чтения вы увидите, что иногда бывает необходимо извлечь файл, чтобы поправить пару байт или выдрать кусок кода для кейгена. ORCA не позволяет извлекать файлы из MSI-дистрибутива. AdminStudio тоже. WinRAR способен открывать большинство MSI-дистрибутивов, однако не все. Поэтому мы написали собственную утилиту-экстрактор. Вы увидите ее действие по ходу чтения.

InstallShield – это надстройка над MSI-движком. Невероятно распространенная технология. Практически любая серьезная контора предлагает свои дистрибутивы в виде IS-обертки.

Невероятно важно четко себе представлять архитектуру IS. Вот очень хороший отрывок из книги: http://www.installsite.biz/en/products/isdbookch4.pdf

Мы не станем умолять вас прочесть ее. Скажем просто – если не прочтете, во всей остальной части статьи вам делать уже нечего. А в статье в виде симпатичных диаграммок показано взаимодействие MSI и IS-компонентов. Что такое IDriver.exe? А ISRT.dll? А для чего задействованы файлы, что лежат у вас в директории \Common Files\InstallShield\Driver? А что такое setup.inx и для чего он нужен? Что вообще такое «файл сценария»?

Итак, IS в процессе инсталляции обрабатывает т.н. файл сценария. Файл сценария содержит указания файлам (каким файлам?) IS о том, что делать с дистрибутивом. Куда какие файлы положить, какие значения в реестре прописать, какие сервисы запустить, и наконец, а не спросить ли у пользователя пароль? Разумеется, спектр возможностей setup.inx гораздо шире, однако, в первом приближении сойдет. А теперь вдумайтесь в смысл. Setup.inx говорит, что надо делать, а файлы IS выполняют эти действия, т.е. являются интерпретаторами. Значит, поняв принцип кодировки информации в IS можно сделать с инсталляцией что угодно! Программа просит пароль? Мы поправим inx-файл и программа покорно забудет о пароле!

В ранних версиях IS файл сценария имел расширение ins, в IS 6+ он стал inx. Форматы ins и inx были абсолютно недокументированны – еще бы, ведь зная формат файла и принцип кодирования информации в этом файле, вовсе нетрудно подправить его так, чтобы IS-интерпретатор посчитал, к примеру, любой введенный пароль правильным. В случае ins-файла первым Прометеем стал NaTzGuL, написав пару отличных статей и шикарную утилиту в придачу. А какой выбор был до этого? Часами сидеть в Soft-Ice, пытаясь понять, как же интерпретатор оперирует со строкой пароля и что ему надо. Теперь же стало возможным просто поменять условие в ins-файле (ведь декомпилированный файл имеет С-подобный синтаксис) и все. Вуаля. В случае inx-файла появились две утилиты - Installshield 6/7 script decompiler by sn00pee и Install Shield script decompiler 1.00 beta 15 by NEKOSUKI. Обе доступны с wasm.ru, вот только inx-файлы версий 8+ они уже не понимают (ну-у, скажем так, почти не понимают), а других утилит в сети и нет…

Формат inx-файла тоже неизвестен, документацию и принципы разбора тоже никто описать не озаботился. Авторы, естественно, свои утилиты более не поддерживают – бесплатно, кому оно нужно? Сменились интересы, жизнь скрутила, да мало ли что… Исходники утилит тоже закрыты.

Словом, как видите с ресурсами по IS дело обстоит плоховато. Но есть и пара светлых моментов. Самый главный светлый момент принадлежит некоему zeezee: http://www.woodmann.com/fravia/zeeinst.htm

И эта статья стоит очень многого. Она невероятно полезна и ее стоит прочесть также как и «The InstallShield Developer Run-Time Architecture». Мы собираемся значительно расширить работу zeezee и рассмотреть современные IS компиляторы и интерпретаторы, ведь с момента написания его статьи многое изменилось. Для этого нам потребуются знания о COM и о теории компиляции программ. Первые потребуются потому, что интерпретаторы IS – это COM-сервера, а вторые потому, что компилятор от IS – это, ну, компилятор :)

Компилятор входит в состав InstallShield DevStudio. Пакет монструозен не меньше, чем AdminStudio, но с точки зрения кракера тоже очень интересен. Последней версией на момент написания статьи была 9.0 SP1. Дополнительную информацию можно найти на сайте http://www.installsite.org

Возможно, вас заинтересует вопрос, а можно ли использовать файл сценария (setup.inx) из чистого MSI-пакета. Ответ – да, можно. Здесь нужно понимать, что MSI ничего не знает об IS и знать не желает – он лежит уровнем ниже. IS опирается на MSI, а не наоборот. IS использует специальную dll – ISScriptBridge.dll для обмена информацией с IS-файлами через RPC. Более подробно мы рассмотрим это в практических примерах.

Часто MSI-дистрибутивы хранят данные в MS CAB-файлах. Все пакеты от MS устроены именно так. MS CAB файл можно узнать по сигнатуре MSCF в самом начале файла. Утилиты от MS и WinRAR прекрасно умеют открывать такие файлы. Кроме того, формат MS CAB документирован в MSDN.

Иногда можно встретить самораспаковывающиеся exe-файлы, содержащие внутри себя здоровенный MS CAB-файл. В этом случае PE-пришлепки (самого обычного исполняемого PE-файла) входит распаковать этот файл куда-нибудь, спросит у пользователя пароль, если необходимо и т.д., и т.п. Такие файлы тоже просто распаковать WinRAR. Примерами являются инсталляционный файл от Adobe Acrobat 6.0 или дистрибутив VTune 7.1. Выглядит это так:

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

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

• к любой константе длиннее 4 байт обращаются по ее адресу

• к любой константе составного или строкового типа обращаются по ее адресу

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

Это, конечно, очень широкое обобщение (и не всегда верное - достаточно вспомнить пример с загрузкой 10-байтной вещественной константы в Delphi из предыдущей главы), но, в общем, современные компиляторы действительно используют ссылки весьма широко. И если в программе по адресу X находится строковая константа 'My text', то почти наверняка где-то в коде программы найдется команда push X, mov eax,X или что-либо подобное. Именно на этом факте наличия "указателей на все, к чему можно обратиться по указателю", а также на отсутствии путаницы с сегментами и смещениями и основана "разумность" дизассемблеров под Win32, поначалу сильно удивляющая тех, кто успел привыкнуть к маловразумительным листингам дизассемблированных 16-разрядных программ для MS DOS.

Хотя при наличии очень большого желания (и еще большего терпения, чтобы это отладить) все-таки можно обращаться к данным, не используя явные ссылки на эти данные. Не верите? Тогда попробуйте разобраться в следующем коде для платформы Win32 и найти в нем хоть одну ссылку на выводимые в MessageBox'е строки:

Такие могучие коды начисто "срывают башню" даже IDA Pro, который оказывается совершенно неспособен более или менее логично дизассемблировать это нечто. Вот уж воистину "горе от ума" - древний, по нынешним меркам, W32DAsm дизассемблировал этот код гораздо адекватнее. Разумеется, знаменитому дизассемблеру при желании можно (и даже не очень сложно) объяснить, где в действительности находятся данные, а где - код, который к этим данным обращается, но чтобы это сделать придется сначала разобраться в приведенном коде самому. Понятно, что, написать целую программу таким "высоким штилем" вряд ли у кого-то получится (да и языки высокого уровня мало приспособлены к подобным экзерсисам), но определение адреса блока данных при помощи пары команд

в защитных процедурах (в частности - в процедурах расшифровки кусков кода) встречается довольно часто.

Другим важным моментом, который необходимо помнить при "расшифровке" структур и массивов, хранимых в коде программ, является то, что популярные компиляторы не поддерживают использование структур переменного размера. То есть длина структуры жестко фиксирована и постоянна для всех структур одного и того же типа: если переменная A типа MY_TYPE занимает 100 байт, то переменная B того же типа также будет занимать 100 байт независимо от того, какие данные в ней хранятся. Возникает вполне естественный вопрос: а как же тогда хранятся строки или динамические массивы, размер которых заранее неизвестен? В действительности, в современных компиляторах строки не хранятся непосредственно внутри структур. Вместо этого хранятся лишь указатели на статически или динамически выделенные блоки памяти, а непосредственно текст строки размещается именно в этих блоках. Этим и объясняется смущающий начинающих программистов на Delphi и С++ Builder эффект, когда при попытке определить размер строки при помощи SIZEOF получается, что любая строка занимает 4 байта, а при записи структуры, содержащей поля строкового типа, в файл, вместо текстовых строк появляется странного вида "мусор" длиной в четыре байта. Исключением из этого правила являются только старые паскалевские строки фиксированной длины и массивы символов (char) в Си, но оба эти типа в настоящее время употребляются довольно редко. Кроме того, ссылки на данные вместо самих данных также используются для хранения объектов (тех, которые "экземпляры классов") и динамических массивов.

Если Вы захотите, Вы можете набросать небольшую программку для поиска всех возможных ссылок в коде программ. Базовая идея проста: код программы и статические переменные, как правило, имеют весьма небольшой объем по сравнению с максимально возможным размером адресного пространства в Win32 (4 гигабайта, если не вдаваться в тонкости устройства Windows). А потому мы можем с высокой вероятностью считать ссылками на код или данные все 32-разрядные числа в программе, которые попадают в промежутки адресов, занятые программой или данными. Чтобы проверить все это на практике, так сказать, "потрогать руками", нужна программа, извлекающая из исполняемого файла все четырехбайтные значения, которые теоретически могут быть адресами. Если Вы уже попробовали написать утилиту для поиска нецелочисленных данных и проверили ее в действии, проблем с программированием у Вас не возникнет. Самое сложное - извлечь из заголовка PE-файла адреса начала каждой секции в памяти, размеры этих секций и смещения начала каждой секции в файле. Если Вы не хотите сразу же погружаться в изучение структуры PE-заголовка (а рано или поздно этим все же придется заниматься), на первых порах Вы можете ограничиться ручным вводом этих данных.

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

Итак, предположим, что Вы знаете о структурах и массивах все, что положено знать начинающему программисту, а именно: что они есть, что в них можно хранить данные, и, самое главное, как в программах обращаются к отдельным элементам этих структур и массивов. Более того, Вы даже знаете, что массивы и структуры можно комбинировать весьма удивительными и изящными способами: создавать массивы массивов (они же двухмерные массивы), массивы структур, массивы массивов структур, ну и так далее. Абсолютное большинство компилирующих языков при хранении данных структурированных типов придерживаются принципа: поля и элементы массивов хранятся в памяти в том порядке, в каком они определены в исходных текстах программы. Ну и, разумеется, порядок полей неизменен для всех данных одного типа. Само по себе это, конечно, мало что дает - ведь исходников-то у нас нет, но тут в игру вступает психология. Да-да, программисты - тоже люди, а изучение их психологии, даже поверхностное, иногда помогает лучше понять творения программистов (то бишь программы). В частности, многим программистам свойственно стремление к логике и элементарному порядку в исходных текстах. Например, если в ходе исследования неких данных Вам удалось установить, что первое и второе поле структуры - это указатели на фамилию и имя, то третье поле структуры скорее всего окажется указателем на отчество, а не закодированным размером обуви или цветом волос. Или, если речь идет о заголовке архива, за именем файла наверняка последует смещение сжатого файла в архиве (плюс-минус некоторая константа), размер этого файла в сжатом виде и контрольная сумма. Причем именно в таком порядке - это традиция, которую программисты нарушать не любят. Если Вы кроме крэкинга занимаетесь программированием, поразмыслите о том, как бы Вы разместили информацию, будь Вы на месте автора программы - и, возможно, это будет наиболее короткий путь к пониманию структуры данных. Именно понимание программистских традиций, "неписанных законов" позволили исследователям недр Windows NT без особых сложностей разобраться с параметрами вызовов Native API - им потребовалось лишь изучить общедоступную документацию, понять, как мыслят программисты в Microsoft и немного повозиться с отладчиком.

Но вернемся к нашим структурам. Проведем небольшой эксперимент: возьмем все тот же Delphi и определим пользовательский тип my_record (в Паскале структуры принято называть записями):

А теперь попробуем подсчитать, какова длина такой записи в байтах. Если просто сложить длины полей, входящих в запись, должно получиться 1+2+4=7 байт. Но в действительности все обстоит несколько иначе: sizeof (my_record)=8! Чтобы выяснить, почему так случилось, определим в программе переменную my_var типа my_record и попытаемся присвоить полям этой переменной значения: my_var.a:=1; my_var.b:=2; my_var.c:=$ABCDEF10 (надеюсь, Вы внимательно читали предыдущую главу и уже догадались, зачем я присвоил третьему полю столь странное значение). После компиляции мы получим следующий код:

Возникает закономерный вопрос: чем так плох адрес 455С01, что по этому адресу компилятор "не захотел" хранить данные. Ответ на этот вопрос лежит в недрах архитектуры x86. С незапамятных времен процессоры x86 выбирали данные, лежащие по четным адресам, немного быстрее, по сравнению с такими же данными, лежащие по нечетным адресам. Чуть позже процессорам стали "нравиться" адреса, кратные четырем. С совершенствованием процессоров список "хороших" адресов продолжал расширяться, появились "особенные" последовательности команд, которые выполнялись быстрее "обыкновенных" и в результате предельная оптимизация программ стала занятие настолько сложным, что стало проще доверить ее компилятору. Для достижения максимальной производительности программисты старались размещать часто используемые данные именно по таким "хорошим" адресам. А чтобы программисту не приходилось раскладывать данные по нужным адресам вручную, в компиляторы была введена такая опция, как "выравнивание данных". Эта опция заставляет компилятор принудительно размещать данные по адресам, кратным величине выравнивания. В нашем случае данные выровнены по четным адресам, поэтому ячейка с адресом 455С01, находящаяся между однобайтным полем a и двухбайтным b, осталась не у дел. Однако если программисту требуется хранить в памяти достаточно большое количество записей, потери памяти из-за выравнивания могут оказаться неприемлемо большими, и в таких случаях выравнивание либо отключают вообще, либо при помощи служебных слов "объясняют" компилятору, к структурам каких типов выравнивание применять не надо.

Использование выравнивания в программах дает один интересный побочный эффект, облегчающий изучение и извлечение данных, хранящихся в программах. Хотя формально значение байтов, находящихся в "дырках" между полями константы-структуры, не определено, на практике все известные мне компиляторы записывают туда нули (что интересно, эти "дырки" при желании тоже можно использовать для хранения данных). В результате достаточно длинный массив таких структур довольно легко определить среди прочих данных "на глаз". Лучше всего для таких целей подходят редакторы, позволяющие при просмотре изменять количество байт, отображаемых в одной строке и выделять цветом характерные последовательности байт (в частности, таким свойством обладает Hex Workshop 4) - цветные пятна образуют характерный узор, который Вы начнете легко замечать после минимальной практики. Тем более, что если отформатировать дамп так, чтобы в строке умещалось столько байт, сколько занимает одна структура, "дырки" выстроятся в вертикальную полосу. Чтобы Вам было понятнее, о чем я говорю, приведу пример массива записей и продемонстрирую, какими путями можно попытаться определить размер и назначение полей структур. Вот код, присутствующий в одной из старых версий моей программы InqSoft Sign 0f Misery:

Как видите, факт структурированности данных заметен невооруженным глазом, хотя мы ничего не знаем о том, какие именно данные хранятся в этом массиве. Достаточно очевидно, что размер одного элемента массива равен тридцати двум байтам. Надо отметить, здесь нам очень повезло в том, что размер структуры совпал с числом байт, отображаемых в одной строке. Впрочем, многие шестнадцатеричные редакторы позволяют менять этот параметр и группировать байты произвольным образом (т.е. не обязательно по 4, как это сделано в примере). Попробуем рассуждать логически. Первым делом заглянем в PE-заголовок файла программы и посмотрим начальные адреса и длины (в терминологии PE Explorer'а - Virtual address и Size of Raw Data соответственно) секций. Просуммировав эти характеристики, в первом приближении мы можем считать, что наша программа после загрузки занимает в памяти адреса с 410000h по 6005FFh (хотя, в общем случае, между секциями в памяти могут быть "дыры"). Поэтому числа, попадающие в этот промежуток, с большой вероятностью являются указателями на данные.

Внимательно посмотрев на первый, второй и третий столбец, Вы можете заметить, что в этих столбцах как раз находятся числа из промежутка 410000h..6005FFh, т.е. это потенциальные указатели на данные. Нули, встречающиеся в третьем столбце - это "пустые" указатели; такие указатели широко известны в языках программирования под различными именами. В C/C++ такие указатели обозначаются как NULL, в Паскале/Delphi - nil. Попробуем посмотреть, что находится по адресам из первых трех столбцов первой строки. А находятся по этим адресам ASCIIZ-строки:

Если проверить остальные указатели, мы также обнаружим по соответствующим адресам текстовые строки. Отлично! Теперь нам известны длина и тип трех полей структуры. Теперь обратите внимание на шестую тетраду. Числа 042E0001, 04CE0001, 04C40001 мало похожи на осмысленные данные, что в шестнадцатеричной системе, что в десятичной. Но вот если четырехбайтные последовательности интерпретировать не как DWORD, а как два идущих подряд WORD'а, то данные начинают выглядеть менее странно: (1,1070), (1,1230), (1,1220). Правда, мы не можем быть уверенными (как я уже говорил, такова обратная сторона метода, базирующегося на наблюдениях и предположениях), что первые два байта - это действительно одно поле типа DWORD, а не два поля типа BYTE - имеющаяся выборка слишком мала. Чтобы проверить это, необходимо исследовать код программы, который обращается к этому массиву. Но это - тема следующей главы.

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

А пока разберем некоторые тонкости, о которых я умалчивал до этого момента. Вы, наверняка заметили, что, приведя в качестве примера некий кусок кода, я просто сказал "это массив структур", не приведя никаких объяснений, каким образом я обнаружил этот код в программе. На практике задача обычно ставится несколько иначе: по некоторым известным данным необходимо найти в программе область, где эти данные хранятся в структурированном виде, разобраться, какие еще данные, помимо уже известных, содержит эта структура, и затем извлечь то, что нам было неизвестно.

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

Кроме того, я продемонстрировал расшифровку отдельных полей, но не сказал ни слова о том, с какого из этих полей начинается описание структуры. Иными словами, мы все еще не знаем, находится ли ссылка на строку по адресу 0051AB28 в начале структуры, в середине или же вообще является последним полем записи, а следующая за ней ссылка на адрес 0051AB74 относится уже к следующему элементу массива. Если вспомнить "психологию программиста", о которой я говорил выше, и проанализировать содержимое строк, то принадлежность всех трех ссылок к одной и той же записи достаточно очевидна, но мы не будем упрощать себе задачу и попробуем честно добраться до приведенного массива. К сожалению, для полного представления о решаемой задаче необходима сама программа, привести которую в данной главе невозможно по причине ее большого объема, поэтому мне придется ограничиться только демонстрацией наиболее важных ее кусков.

Итак: у нас есть программа, которая состоит из интерпретатора байт-кода и оболочки, позволяющей писать скрипты, которые затем транслируются в байт-код. Внутри оболочки содержится массив, описывающий команды, используемые в этой программе и байт-коды, соответствующие каждой команде, и нам требуется извлечь из программы список байт-кодов и названий команд, которые этим кодам соответствуют. Сама оболочка запакована при помощи UPX, но ее распаковка никакой сложности не представляет. Названия команд известны каждому запустившему программу, поскольку полный список команд отображается в оболочке.

Возьмем любую команду, например "Ожидать появления окна с указанным текстом в заголовке и классом" и попробуем найти этот текст в коде программы. Никаких особых ухищрений для этого не потребуется, при помощи функции поиска в HexWorkshop находим, что искомая строка встречается в файле в единственном экземпляре по смещению 1154856 байт от начала файла. Далее, при помощи любого Offset->RVA конвертера (утилиты, преобразующей смещения в файле в относительные виртуальные адреса (RVA)) определяем, по какому адресу будет размещен 1154856-й байт программы после загрузки этой программы. Получаем, что эта строка в памяти располагается начиная с адреса 51AB28h. Теперь вспомните то, что говорилось о методах хранения строк внутри структур, и Вам станут очевидны наши дальнейшие действия.

Следующий этап будет заключаться в поиске по всему коду программы ссылок на нужную строку, то есть 32-битной константы 51AB28h. Такая константа нашлась сразу же, причем в единственном экземпляре по смещению 1229C0h от начала файла. 128-байтный блок, начинающийся с этой константы, я и привел в качестве примера несколькими абзацами выше. Теперь Вы имеете представление, при помощи каких приемов можно добраться до нужного массива. Как видите, здесь все достаточно просто.

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

Первый способ базируется на том, что в программе почти наверняка найдется явная ссылка на первый элемент массива, и что адрес этого элемента больше либо равен адресу одного из известных нам элементов, входящих в массив. В применении к нашему примеру это означает, что если смещение одного из найденных нами элементов структуры равно 1229C0h (RVA для этого смещения равно 522BC0h), то начало массива, очевидно, находится не ниже этого адреса. Следовательно, если выбрать из программы все константы меньше либо равные 522BC0h (а для этого нам и нужна соответствующая программа, о которой я уже упоминал), среди них окажется и ссылка на первый элемент массива. При этом, если рассортировать найденные ссылки по убыванию их величин, велика вероятность, что ссылка на начало массива окажется в числе первых.

Продемонстрирую это примером. Допустим, Вы выяснили, что ячейка по адресу 450080h входит в состав массива. Выбрав все ссылки, указывающие на адреса не ниже 450080h, Вы получили следующий набор: 450000h, 49FFD0h, 49FCD4, 49FCD0h и так далее. Из всех найденных Вами адресов теоретически наиболее вероятным адресом будет являться 450000h. Почему? Причина в том, что информация из длинных предварительно инициализированных массивов обычно (но не всегда!) считывается при помощи конструкций вида my_arr[i], где значение i явно не указано и на этапе компиляции определено быть не может. И потому, чтобы обратиться к i-му элементу массива, в общем случае программа должна вычислить адрес этого элемента по формуле адрес_элемента = начальный_адрес_массива + размер_элемента * (номер_элемента - номер_первого_элемента). Как мы видим, в этой формуле в явном виде присутствует начальный адрес массива, который мы и ищем в программе.

Кроме того, если этот массив передается в качестве аргумента в какую-либо процедуру или функцию, то весьма вероятно, что в программе встретится команда push адрес_начала_массива. Это происходит потому, что передача всего массива в процедуру через стек встречается в аккуратно написанных программах достаточно редко, обычно передается лишь ссылка на первый элемент (которая нам и нужна).

Однако "гладко было на бумаге", а в реальности существует немало "подводных камней", заметно осложняющих использование предложенного метода, а иногда даже и делающего этот метод неприменимым. Прежде всего, проблему могут создать обращения к элементам с явно указанными номерами. Допустим, что в программе кроме конструкций вроде my_arr[i] имеются обращения к конкретным элементам, например a=my_arr[2] или if b>my_arr[10] then do_something. Если адреса значений my_arr[2] и my_arr[10] могут быть вычислены на этапе компиляции, то хороший оптимизирующий компилятор их вычислит, подставит в код, а в программе, кроме начального адреса массива, появятся также адреса второго и десятого элемента массива. И тогда при поиске начала массива по предложенному методу Вы можете найти не первый элемент, а второй или десятый - это уж как повезет.

Во что хороший оптимизирующий компилятор может превратить исходный код - это вообще тема большая и интересная. Например, в Delphi допустимы массивы, начальный элемент которых может иметь любой целочисленный индекс, в том числе и отрицательный, т.е. вполне корректно использование выражений вида a:=my_arr[-10]. Да и менее экзотичный массив вроде array [10..100] of my_record не так прост, как может показаться с первого взгляда: посмотрим, как будет выглядеть приведенная выше формула адреса произвольного элемента массива для этого случая.

адрес_элемента = начальный_адрес_массива + размер_структуры_my_record * (номер_элемента - 10)

Очевидно, что эту формулу можно переписать как: адрес_элемента = (начальный_адрес_массива - размер_структуры_my_record * 10) + (размер_структуры_my_record * номер_элемента)

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

используется единственная команда mov eax, [(OFFSET my_arr-4)+ebx*4], в которой значение (OFFSET my_arr-4) вычисляется на этапе компиляции.

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

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

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

Внимательно посмотрев на приведенный кусок, Вы можете видеть, что массив начинается с восьмой тетрады второй строки. Почему? Во-первых, достаточно очевидно, что первые две строки заметно отличаются от третьей и четвертой, следовательно, границу между массивами нужно искать именно во второй либо в третьей строке. Первая и вторая тетрада второй и третьей строки похожи на указатели на текстовые строки (хотя, если копнуть чуть глубже, можно обнаружить, что только в третьей строке эти ссылки действительно указывают на названия команд). А вот четвертая, пятая, шестая и седьмая тетрады также являются указателями и внешне сильно отличаются от соответствующих тетрад третьей и четвертой строки. Очевиден вывод: все данные по седьмую тетраду второй строки включительно не принадлежат массиву. Осталось разобраться с восьмой тетрадой: она ничем не выделяется на фоне последующих двух, поэтому мы с чистой совестью можем отнести ее к нашему массиву и сказать, что массив начинается именно с нее. Дальше, если проанализировать весь массив, выяснится, что первое поле - уникально для каждого элемента массива, и его значение не превышает 255 (то есть первый элемент структуры - байт). Логично предположить, что это и есть код команды, который мы и искали.

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

Увы, и этот метод не свободен от недостатков. Во-первых, для успешного использования этого метода необходимо, чтобы элемент массива можно было легко отличить от данных, не имеющих к массиву никакого отношения. Однако так бывает далеко не всегда, например, таблица констант для реализации CRC по алгоритму WiseByte выглядит как набор из 256 псевдослучайных чисел, не имеющих каких-либо характерных признаков, видимых невооруженным глазом. Во-вторых, проблему представляют случаи, когда в одном массиве хранятся разнородные данные. Возможность хранения разнородных данных в структуре предусматривается некоторыми языками программирования ("структуры с вариантами" в Паскале и объединения (union) в Си). И в-третьих, желательно, чтобы данные, предшествующие массиву и следующие за ним, заметно отличались по внешнему виду, что совершенно не обязательно выполняется на практике. Более того, программисты, исходя из стремления к порядку в исходных текстах, очень часто располагают однотипные массивы последовательно, чем отнюдь не облегчают жизнь крэкерам.

Как видите, оба способа обладают существенными недостатками, сильно зависят от "человеческого фактора", не гарантируют стопроцентного результата (впрочем, в крэкинге результат вообще никто гарантировать не может), а область их действия - ограничена. Что еще можно сделать, чтобы поднять эффективность этих техник? Ответ прост - необходим синтез обоих методов! Результаты, полученные при помощи второго метода, могут быть проверены поиском указателя на первый элемент в коде программы. И наоборот, если Вы нашли возможную ссылку на начало массива, посмотрите, как выглядит тот участок программы, на который указывает эта ссылка, похож ли он на начало массива, или необходимо внести поправки в свои рассуждения. Вообще, крэкеру (да и не только крэкеру) стоит взять на вооружение следующий принцип: если результат, полученный одним способом, может быть проверен другим способом, эту нужно выполнить проверку. В конечном итоге следование этому принципу позволит Вам избежать ошибок, и из-под Вашей руки выйдет гораздо меньше недопатченных и криво взломанных программ.

Поэтому я сейчас поведаю Вам про третий метод исследования массивов, немного варварский, но весьма результативный. Этот метод позволяет не только обнаружить начало массива, но и выяснить действительные размеры каждого элемента структуры и определить, какой из элементов открывает определение этой структуры. Суть метода проста: добравшись до одного из элементов массива, Вы начинаете при помощи шестнадцатеричного редактора изменять отдельные байты и наблюдать, как эти изменения скажутся на работе программы. При известной наблюдательности этот метод позволяет быстро и без особых усилий понять внутреннюю логику организации данных; впрочем, изменение кода программы (значений регистров, содержимого памяти) с целью "посмотреть, что будет, если…" - один из наиболее популярных подходов в крэкинге, доказавший на практике свою эффективность.

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

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