R0 CREW

Kaspersky crackme (ZN2014)

Алго зловреда явно вытянули из малвари. Давать такое для крякми? Кхм… Я пасс.

ЗЫ: Алюшин мужик, таки решил. Интересно сколько времени только убил.

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

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

Помогите плиз, с этим таском!! После того как я восстановил этот алгоритм как и советовали ранее , с карандашом и бумагой посидел и вроде как сделал (я так думал) , но потом у меня встала проблема которую не могу обойти!! Факап в том что у меня char rleKey[20] = {0xc6, 0x16, 0xa3, 0x9f, 0x7c, 0x23, 0xfb, 0xc6, 0x8d, 0xf8, 0x1f, 0xaa, 0x24, 0x35, 0x0d, 0xfb, 0xf1, 0x2b, 0x57, 0x51}; - и все делает нормально до ACh символа , а потом я ничего не могу сделать потому что у меня закончились символы в rleKey для того что бы закодировать оставшееся. Как быть ?

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

Есть, 255 символов серийник, соответственно рле последовательность может быть максимум 159-16O байт

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

Напишите статью по зловреду. Что там за алго был? Резко +5 решивших третье задание))))

Там развернутые циклические сдвиги.

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

Ну нужно в коде этой ф-ии, найти и заменить все эти конструкции на соотвествующии инструкции rol или ror. И т.к. ф-ия линейная и все инструкции обратимы, то это всё можно обратить даже в автоматическом режими. Я написал скрипт который находит все инструкции принадлежащии тому или иному блоку еще 2 недели назад. Но потом у меня закончилось свободное время. Я не успел решить проблему инструкций находящихся между инструкциями относящихся к блоку. Нужно считать куда их перемещать до инструкции или после. Теория как это считать у меня уже была на тот мемент. Если бы я выполнил этот этап, то обращение этой ф-ии было бы самое простое.

Могу дать свой скрипт, если интересно.

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

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

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

Есть некоторые детали с эмуляцией операций OR и SHR/SHL, но если вспомнить, что они идут в паре и являются частью циклического сдвига, то всё решаемо.

На разработку теории, реализацию и отладку ушло около недели. До этого много времени потерял на разработке другой теории.

Как-то у тебя всё сложно.

Поступили запросы на скрипт и что бы не отвечать на каждоее сообщение выложу его здесь.
http://pastebin.com/2i16KRmi

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

Там много зависимостей, так просто не обратишь. Нужно делать так, как сказал Neomant.

Присоединяюсь к REU. Выложу свой скрипт для поиска циклических сдвигов (правда, определены не все шаблоны).
http://pastebin.com/Sc5KUuED

Присоединяюсь к мнению Neomant’а.

Neomant, а как ты разобрался с трёхоперандными инструкциями? Типа lea eax, [ebx + ecx].

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

Привет. В общем я для изучения темы реверса взялся за сей кракми - где надо восстановить серийник от почты. Все разобрал по кирпичикам, получил последовательность байтов, которую собственно и надо развернуть в серийник некой обратной функцией. Написал эту функцию - она анализирует последовательность байтов от последнего в начало и выдает серийник но вот беда этот серийник потом не дает точь в точь такой же последовательности байтов Получается очень близко но в 35-байтовой последовательности есть ошибки в 5-6 байтах причем так что верхняя половина норм а нижняя с ошибкой например вместо 23 21 вместо dc d5 и т.п
В общем прошу советов. Может ли быть вообще такое что кракми кривой и не выдаст серийника?

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

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

Вот так вижу главный цикл функции упаковывания серийника в байты.
Главный цикл состоит из 8 итераций чтения символов серийного номера ( чаров)
повторяется главный цикл нужное кол-во раз но на моих логинах которые я пробую кол-во чаров всегда кратно 8. Так ли это в дейтсвительности?
В цикле отмечены операции чтения и сдвига чара ( желтым) , записи в байт ( красным) и переноса верхнего байта прошлой итерации в новую в качестве операнда для logical OR (фиолетовый)
Одна итерация внутри цикла состоит из 3 элементов , прошлого результата , чара со сдвигом и текущего результата. В моей таблице следовательно 8итераций на 3 ячейки вордов = 24 ячейки по 2 байта в каждой.
Там я расписал максимально возможные значения для всех ячеек на каждый момент итерации учитывая что максимальный сдвиг чара - это 7, а максимальное значение чара - это 0x1f
Получилась эдакая таблица масок.
Если писать обратную функцию то можно видеть как подставленое последнее значение байта влияет на всю цепочку вверх. Обратно получается что из текущего результата и этих масок получаем прошлый результат и через XOR прошлого и текущего результата получаем сдвинутый чар. Дальше двигаем чар обратно, и размапливаем его через таблицу в обратном направлении. Вроде все верно. Но ошибка все равно есть.
Подскажите что я упустил.

PS. Решил проблему. В Cишном коде у меня сдвиги были через операторы >> и << . Я знал что при компиляции эти операторы превращаются из SHR в SAR к примеру порождают ошибки. Но упустил из виду пока ломал голову над алгоритмом. В итоге 0x8>>7 мог дать не 1 а F
Еще выяснил что алгоритм мой учитывает что вся длина хеша является одним сплошным стримом, где каждый следующий байт повязан на всех остальных, а это оказалось не так и все зависимости максимум на 1 байт назад находятся внутри одного цикла из 8 итераций, которые гораздо легче найти.