Данная статья рассчитана на начинающих, интересующихся обратной разработкой, и имеющих базовые представления о работе ЦП, языке ассемблера. Этот crackme относительно старый и простой, но при его решении применяются в основном те же приемы, что и при решении более сложных. На просторах Сети можно найти несколько статей с его разбором такие как эта, а еще он здесь упоминается(crackme то с историей), однако те решения не такие подробные как это. В свое время мне сильно не хватало такого построчного разбора, куда можно было бы заглянуть, когда запутался и не понимаешь что делает тот или иной участок кода. Если этот пост окажется полезным хотя бы для одного человека, значит я не зря старался. Все скрины(кроме первого) кликабельны. Приятного прочтения.

Итак, перед нами простой crackme, запустим его и посмотрим как он работает.


Ага, все довольно просто, мы должны ввести правильный серийник. Теперь откроем программу в дизассемблере. Как правило дизассемблерные листинги, даже относительно простых программ, довольно объемны. Для определения той части кода, которая проверяет ввод серийника, найдем где в памяти программы хранится строка с сообщением об ошибке «Fail, Serial is invalid !!!» и какой код к этой строке обращается.



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



Loc_140001191 это метка для перехода, ниже видим строку «call cs:MessageBoxA». Предположим, так вызывается функция, которая отрисовывает окошко с текстом «Fail, Serial is invalid !!!». Получается, если мы вводим неправильный серийник, то управление передается именно по метке Loc_140001191. Отлично, продолжим копать и разберемся, где еще есть обращение по этой же метке, для чего перейдем по ссылке справа от нее, которую там заботливо разместил для нас, дизассемблер.



Это очень важный участок кода, приглядимся к нему внимательно. Мы видим вызов функции «GetDlgItemTextA», в названии есть слова get и text, очевидно эта функция читает введенный серийник. После того как функция отработала, команда «lea rcx, [rsp+78h+String]» загружает в регистр rcx, адрес чего то из стека. Затем записывает в edx значение из eax и вызывает функцию sub_140001000. Манипуляции с регистрами перед вызовом не случайны, таким образом осуществляется передача аргументов в функцию, а после того как функция отработала, командой «test eax, eax» выполняется проверка содержимого eax, если в нем не 0, то подгружаются адреса строк, рапортующих, что все ок. Затем запускается отрисовка окошка с соответствующим оповещением. Если же после работы sub_140001000 в еax будет 0, то управление передается на ранее рассмотренную метку, где мы получим сообщение об ошибке. Делаем вывод: sub_140001000 возвращает значение в регистр eax. Теперь мы можем восстановить логику работы этого crackme: вызывается функция GetDlgItemTextA, напомню, она предположительно считывает наш серийник, затем вызывается функция sub_140001000 которая в качестве аргументов получает адрес чего-то из стека и значение регистра eax через регистр edx, если же функция возвращает «не ноль», то был введен правильный серийник, если «ноль», то не правильный. Предположим, что именно sub_140001000 проверяет наш ввод, переименуем метки и функции в нашем листинге для удобства и наглядности. Теперь наш листинг выглядит примерно так.



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



Я ввел 12345. Выполнение остановилось на вызове функции проверки. Смотрим регистры, в rcx лежит число 12F660, как мы знаем это адрес, посмотрим дапм памяти по нему в окне внизу, ага там лежит наш ввод, теперь глянем на edx(он же младшая часть rdx) там лежит число 5, а это длинна нашего серийника. Вот мы и выяснили, какие аргументы и что возвращает функция проверки, теперь мы можем предположить как мог выглядеть ее прототип: int check_func(* char, int). Самое время ее изучить. Откроем функцию проверки в дизассемблере. Она довольно большая, поэтому разберем по частям.



Здесь все относительно просто. Напомню, регистр edx хранит в себе размер введенного серийника, а rcx его адрес в памяти. Видно, что в первую очередь функция check_func проверяет длину введенного номера. Она должна быть равна 19(13 в шестнадцатеричной системе), если это так, то продолжается проверка(переход на метку good_size), если же нет, то управление переходит по метке bad_serial, где командой “xor eax, eax” регистр eax обнуляется и происходит выход из функции. Делаем вывод: в валидном серийнике 19 знаков, а каких именно, разберемся далее. Обращаем внимание, что практически сразу адрес введенного номера помещается в регистр R8.

Продолжим исследовать механизмы проверки.



Мы помним, что R8 указывает на первый элемент серийника, значит по адресу R8+4 будет храниться адрес 5-го элемента, он записывается в RAX. Дальше видим очень странный набор команд, который встретится нам еще не раз:

        xchg    ax, ax
	db      66h, 66h
	xchg    ax, ax

Теперь подробнее:

“xchg ax,ax” — это эквивалент команды “nop” в платформе х86.
Следующая строка — это так называемый префикс, он используется для указания разрядности следующей инструкции. Этот код мы можем его игнорировать. После этих инструкций идет проверка следующего рода: то что находится по адресу RAX(а там адрес 5-го элемента серийника) должно быть равно числу 2D (в шестнадцатиричной системе). 2D это ASCII код знака «-», делаем выводы:

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

Если 5-й символ не «-», то серийный номер не правильный, происходит переход на метку bad_serial и выход из функции со значением 0, но если на 5-й позиции дефис, тогда RAX увеличивается на 5, теперь когда он указывает на 10 элемент проверяется какой символ на этой позиции. Всего такая проверка проводится 3 раза, каждый 5-й символ серийника это «-», и в нем всего 19 знаков, значит он имеет форму: XXXX-XXXX-XXXX-XXXX. Если формат ввода соответствующий, то проверка продолжается.

Следующий участок функции не представляет для нас особого интереса.



Идем дальше.



Обращаем внимание на следующее: R9 всегда указывает на первый элемент блока, а RCX хранит смещение внутри блока, поэтому после проверки, R9 увеличивается на 5, чтобы попасть в следующий блок, а RCX обнуляется после проверки блока, помним, что в RDX лежит ноль, поэтому по метке zero_to_rcx происходит обнуление. Строчка «add eax, 0FFFFFFD0h» не так проста как кажется. На самом деле здесь происходит не сложение, а вычитание. Да-да, не верь глазам своим, 0FFFFFFD0h для компьютера это число -30h, видимо дело в том, что команда «add eax, 0FFFFFFD0h» оптимальнее с точки зрения компилятора чем “sub eax, 30h”. В eax хранится ASCII код элемента, из него вычитают 30h и сравнивают с 9. Смысл тут такой: ASCII коды цифр от 0 до 9 это 30h – 39h соответственно, поэтому если из кода цифры вычесть 30h, то результат не превысит 9, если же превысит, значит в eax лежал код не цифры, а какого то другого знака и тогда мы переходим по метке wrong_serial. Наш серийник должен состоять из цифр и дефисов. Далее суммируется коды всех 4-х элементов блока, 3 раза плюсуется код 4-го элемента и вычитается 150h. Результат пушится в стек, суммы всех блоков мы складываются в R10 и результат делится на 4.



Теперь проверяются суммы для всех 4-блоков. Значение для каждого блока должно быть равно из сумме деленной на 4, иными словами сумма ASCII кода первого знака плюс код второго, третьего плюс 3 раза код четвертого и минус 150h должна быть одинаковой для всех блоков.
Остался последний этап проверки.



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

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