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

http://ricardonarvaja.info/WEB/INTRODUCCION AL REVERSING CON IDA PRO DESDE CERO/EJERCICIOS/

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

В этой главе мы будем действовать немного по другому. Я буду распаковывать файл удаленно на виртуальную машину VMWARE WORKSTATION с установленной системой WINDOWS 10.

Главная машина для удаленной отладки, это та, где запущенна IDA. В данном случае, это машина с WINDOWS 7. Но это могут быть любые системы, а не только WINDOWS. Например LINUX, IOS и т.д. где есть установленная IDA.

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

Чтобы было быстрее читать и понимать, отсюда и далее, главную машину, где установлена IDA, я буду называть “ОСНОВНОЙ”, а образ системы WINDOWS 10, который запускаю в VMWARE буду называть “ЦЕЛЕВОЙ”.



В ЦЕЛЕВОЙ системе находится упакованный файл. Я также должен скопировать из каталога, где у меня установленна IDA в ОСНОВНОЙ системе, сам сервер. Так как моя система WINDOWS 10 - 64-битная, а упакованная программа – 32-битная, то я должен запустить 32-битый сервер. Он называется WIN32_REMOTE.EXE.



Копируем также исполняемый файл PACKED_PRACTICA_1.EXE в ОСНОВНУЮ систему, чтобы выполнить ЛОКАЛЬНЫЙ анализ и открываем этот файл в ЗАГРУЗЧИКЕ. Я устанавливаю галочку в MANUAL LOAD, для того, чтобы IDA проанализировала файл и загрузила все его секции.

Сейчас мы находимся в ЗАГРУЗЧИКЕ, который показывает мне EP упакованной программы. Пока мы ещё не запускали ОТЛАДЧИК.



Очень важно не переименовывать IDB файл. Другими словами, это означает, что если исполняемый файл называется PACKED_PRACTICA_1.EXE в ОСНОВНОЙ системе, то при анализе он будет сохранять IDB файл в ту же самую папку, и он должен называться PACKED_PRACTICA_1.IDB, и никак по другому, потому что так начнутся проблемы с распознаванием какой удаленный процесс принадлежит исполняемому файлу анализируемого локально.

Сейчас, давайте запустим удаленный сервер WIN32_REMOTE.EXE в ЦЕЛЕВОЙ системе.



Этот файл запускает удаленный сервер IDA и будет слушать IP адрес и порт, который мы ему назначим. В моём случае, IP равен 10.80.65.157, а порт 23946. Скопируйте данные, которые сервер показывает для Вас.

Теперь поменяем тип отладчика на REMOTE WINDOWS DEBUGGER.



В PROCESS OPTIONS я устанавливаю IP адрес и ПОРТ сервера IDA. Т.к. процесс ещё не создан, то мы не сможет подсоединиться к нему с помощью отладчика. Также, нам нужно отлаживать файл с самого начала. Мы должны исправить пути, которые IDA показывает здесь, чтобы они совпадали с расположением исполняемого файла в ЦЕЛЕВОЙ системе.



В моём случае, распакованный файл в ЦЕЛЕВОЙ системе находится на РАБОЧЕМ СТОЛЕ и полный путь для моей системы будет - C:\USERS\ADMIN\DESKTOP\PACKED_PRACTICA_1.EXE



Поэтому давайте отредактируем эти три поля для ввода пути.


Сейчас, если нажмём кнопку START PROCESS, то IDA остановится на EP упакованного файла в РЕЖИМЕ ОТЛАДЧИКА.

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



Сейчас, в СЕГМЕНТАХ давайте посмотрим на первую секцию кода после заголовка.

В моём случае, я вижу, что она начинается по адресу 0x231000 и заканчивается по адресу 0x238000.



Если мы просто сделаем SEARCH FOR TEXT, чтобы найти инструкцию POPAD или POPA, в этом случае, найдём ту инструкцию, которая выполняется до перехода в OEP.




Здесь, мы уже знаем, что OEP находится по адресу 0x23146E, но я могу найти её по другому. Я устанавливаю BP на ВЫПОЛНЕНИЕ, который охватывает всю первую секцию.

Теперь иду в начало секции по адресу 0x231000.


Здесь я вижу данные, которые принадлежат заголовку. Очевидно, адреса не совпадают из-за рандомизации. IB не равна 0x400000, но VIRTUAL SIZE такой же, как и был, и равен 0x7000 байт, т.е. размер секции в памяти совпадает, так как она начинается по адресу 0x231000, а заканчивается по адресу 0x238000. Это разница и составляет 0x7000 байт.



Теперь, в начале секции, я устанавливаю BP с помощью F2. В моём случае, это адрес 0x231000 или соответствующий адрес, который на Вашем компьютере имеет размер 0x7000.



Я удаляю все другие BP. Но оставляю только один этот и нажимая F9, для того, чтобы запустился отладчик.



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



Теперь, делаю правый щелчок в левом нижнем(верхнем?) углу, чтобы ПОВТОРИТЬ АНАЛИЗ.



В этом случае, отладчик оставляет этот блок таким, как будто это блок того же СТАБА. Поэтому отладчик не поместил префикс SUB_, а оставил префикс как LOC_.

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



Другими словами, IB в моём случае, находится по адресу 0x230000, а её конец 0x23B000.



Здесь, я меняю значения в скрипте и запускаю его через FILE → SCRIPT → FILE.



Отладчик сохраняет дамп в этой папке, так как скрипт запускается на ОСНОВНОЙ машине.

Я открываю этот файл с помощью PEEDITOR и выбираю пункт DUMPFIXER.



Теперь меняю расширение файла на EXE.



Вот у него появляется такая же иконка, как и у сжатого файла. Сейчас, открываю SCYLLA в ЦЕЛЕВОЙ системе и копирую туда сдампленный файл PACKED.EXE.



Пришло время нажать на кнопку IAT AUTOSEARCH.



Я меняю поле OEP на значение 0x23146E, которое мы нашли.

И вижу, что после нажатия IAT AUTOSEARCH и GET IMPORTS, остаётся только одна НЕДЕЙСТВИТЕЛЬНАЯ запись.

Складывая IB с адресом недействительной записи, получаю

Python>hex(0x230000+0x20D4)
0x2320D4



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

Видим, что этот указатель имеет ссылки.





Теперь посмотрим куда он ведёт.



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

Для нас, настоящих хакеров, это не проблема. Так как указатель ведёт в фиксированное значение программы, которое равно RET, то это не API функция, поэтому на неправильной записи делаю ПРАВЫЙ ЩЕЛЧОК → CUT THUNK для удаления записи из IAT.



Сейчас, я нажимаю FIX DUMP на PACKED.EXE и у меня получается файл PACKED_SCY.EXE, однако он не запускается. Это происходит потому, что в дампе не перераспределены адреса, которые были созданы во время выполнения, которые не принадлежат IAT и всегда меняются при запуске. Поэтому, я буду удалять рандомизацию. Я открываю PACKED_SCY.EXE в IDA с помощью MANUAL LOAD, загружаю заголовок и перехожу в него.



В заголовке есть поле DLL CHARACTERISTICS. У Вас значение будет отличаться от нуля, потому что я уже изменил его.



Из меню EDIT → PATCH PROGRAM → CHANGE WORD меняем этот байт на нуль.



И потом сохраняем изменения с помощью APPLY PATCHES TO INPUT FILE.

Вот и всё ребята.



Наш файл из примера теперь распакован. В 18-той части мы начнём его реверсить.

До встрече в 18-той части.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Автор текста: Рикардо Нарваха - Ricardo Narvaja (@ricnar456)
Перевод на английский: IvinsonCLS (@IvinsonCLS)
Перевод на русский с испанского+английского: Яша_Добрый_Хакер(Ростовский фанат Нарвахи).
Перевод специально для форума системного и низкоуровневого программирования - WASM.IN
08.10.2017
Версия 1.0