Часть 17

Мы добрались до 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, загружаю заголовок и перехожу в него.