Flare-On 2019. Решение. Задача №9.

Подробнее про Flare-On.

Flare-On - ежегодный конкурс, который проводит компания Fire-eye. Конкурс включает в себя 12 задач на обратную разработку (reverse) и чаще всего в нём принимают участия ревёрс-инженеры/вирусные аналитики/исследователи и все остальные специалисты, кто так или иначе связан с ковырянием в бинарном коде.

Конкурс проводится с 2014 года. В этом году он также проводился (в конце августа-начале сентября). И хотелось бы разобрать задания с данного конкурса поочерёдно. Официальный разбор есть на сайте компании Fire-eye (https://www.fireeye.com/blog/threat-research/2019/09/2019-flare-on-challenge-solutions.html), а также разбор на русском от a1exdandy на хабре (https://habr.com/ru/company/dsec/blog/469393/)

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

Предыдущие решения.

Задача №1 - ссылка

Задача №2 - ссылка

Задача №3 - ссылка

Задача №4 - ссылка

Задача №5 - ссылка

Задача №6 - ссылка

Задача №7 - ссылка

Задача №8 - ссылка

Задача №9 - reloadered

Распаковываем архив и получаем два файла (бинарный + описание).

Снова у нас исполняемый файл под Windows 32bit. Посмотрим на описание.

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

Загрузим исполняемый файл в ID'у.

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

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

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

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

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

Самый просто способ это сдампить всё с помощью idaapi и после пропатчить оригинальный бинарь с последующей перегрузкой его в IDA.

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

Момент инициализации

Момент преобразования блоба.

Код в начале функции активно проверяет запущен ли он на реальном оборудовании а не на виртуальной машине. Также есть проверки находится ли он под отладкой.

После всех проверок происходит преобразование выше описанного буфера и происходит запрос ввода ключа с клавиатуры.

После ввода вычисляется размер введённого буфера. Далее происходит XOR с преобразованным буфером.

И после XOR-а проверяется что в флаге есть подстрока с "@flare-on.com". Таким образом мы можем повторить этот код и про-XOR-ить необходимую строку с последними 13 символами блоба из памяти (блоб имеет размер 52 байта и делится на 4 нацело, что означает при циклическом наложении ключа, что мы можем получить ключ по последним 13-байтам блоба).

Сделаем небольшой скрипт и запустим его.

В итоге получим флаг.

Вот такой довольно простой но интересный таск.