R0 CREW

Malware Analysis Tutorial 12: Debug the Debugger - Fix Module Information and UDD File (Перевод: coldfire)

Перейти к содержанию

Цели урока:

  1. Понять, как отладчик сохраняет отладочную информацию.
  2. Узнать, как использовать двоичные редакторы для исследования содержимого файлов.
  3. Поиск и устранение неисправностей в отладчиках, когда это необходимо.

1. Введение

В Уроке 11 был изучен трюк, используемый Мах++, для загрузки собственного вредоносного исполняемого кода, используя «тело» другой DLL называемой «lz32.dll». Основная идея состоит в том, что бы внедриться в функцию LdrLoadDll и установить новый базовый адрес и другую важную информацию модуля, без загрузки исполняемой библиотеки lz32.dll из своего файла (пока исполняемый PE будет скопирован в память). Это достигается путем установки аппаратной точки останова внутри LdrLoadDll и «хирургия» осуществляется обработчиком векторных исключений, который был заранее настроен Max++.

Теперь один побочный эффект «хирургии» Max++ при работе с Lz32.dll заключается в том, что мы не может больше делать комментарии в области «lz32.dll». Когда вы пытаетесь разместить в коде комментарии (начиная с 0x003C24FB – стартовый адрес lz32.dll), они не будут сохранены должны образом отладчиком IMM. В следующий раз когда вы будете загружать Max++ в IMM, все комментарии, относящиеся к lz32, будут потеряны. Причина в том, что «хирургии» Max++ незавершенная – она не исправляет структуры ядра lz32.dll и неправильно отформатированные структуры данных не позволяет сделать внутренний анализ отладчику IMM. Когда IMM пытается создать UDD файл (файл, который хранит отладочную информацию для каждого модуля в исполняемом файле), ему это не удается.

Существует 2 способа решения этой проблемы:

  1. быть уверенным, что все данные ядра, относящиеся к lz32.dll, должным образом сброшены (что может быть тяжелой задачей), или
  2. отладить сам IMM и настроить его поток выполнения таким образом, чтобы он мог корректно работать с плохо сформированными данными.

Мы выберем второй подход и покажем, как отлаживать IMM отладчик и устранять проблемы на месте.

2. Настройка рабочей среды
2.1. Необходимое ПО

Нам понадобится следующее ПО. Его можно легко найти в Интернете: (1) двоичный редактор HxD и (2) NotePad++.

2.2 Настройка компьютера

Вы можете либо продолжить с настройками с Урока 10, либо следуйте инструкциям указанным ниже для настройки. Сейчас проделаем шаги необходимые для этого урока:

INDENT Важно сделать снимок (SNAPSHOT) после установки HxD и NotePad. На этот момент ОС - чистая. После шага (3), ОС будет инфицирована, позже, после того как вы перегрузите ОС, вы можете восстановить снимок для старта чистой системы!!!

(0.5) восстановить снимок как рассказано в шаге (0).
(1) В IMM, убрать все аппаратные и программные точки останова.
(2) Перейти по адресу 0x4012DC и установить там аппаратную точку останова (инструкция по адресу 0x4012DC должна быть следующая - CALL 0x413652). Нажмите F9 для того, что бы попасть на адрес 0x4012DC.

[INDENT]Это место прямо перед трюками описанным в Уроке 11 (в котором устанавливалась аппаратная точка останова внутри zwMapViewSection и потом вызывалась LdrLoadDLL

В этом момент, вы наверно хотите привести в порядок ассемблерный код, показанный в IMM (т.к. идет много непонятных DB инструкций). Выделите и выберите одну или две странички DB инструкций, правый клик на них и затем выберите Analysis -> During Next Analysis Treat Selection As -> Command, затем правый клик и выбрать Analysis -> Code Analysis.[/INDENT]

(3) Теперь по адресу 0x401419 (соответствует инструкции MOV [ESP-2E8]: ESI) поставьте программную точку останова (нажав F2) и затем нажмите Shift+F9 (пока крайне мере дважды) пока не попадете в 0x401419.

[INDENT]Shift+F9 используется для запуска отладки (но проходя все исключения пользовательского кода). Этот путь позволяет обработчику векторных прерываний Max++ быть эффективным. Следовательно, вредоносный код будет находиться в «теле» lz32.dll. Отметьте, что когда вы попадаете в 0x401419, код lz32.dll будет уже выполнен (который заражает файлы драйверов и модифицирует системные регистры и т.д.). Мы проведем анализ этого кода в будущих уроках. На данный момент, мы хотим узнать как делать комментарии работая в IMM.[/INDENT]

(4) Если на этом месте в IMM вы нажмете View->Executable Modules (как показано на рис.1, первая строчка), вы можете увидеть новый модуль, который загружен для «lz32.dll». Его базовый адрес – 0x3C0000 (может зависеть от поведения системы во время выполнения). Используя трюк, изученный в уроке 9, мы можем найти точку входу модуля, она равна – [B]0x3C24FB[/B].

Рис. 1. Новый модуль «lz32.dll»

(5) Теперь в панели «Код» сделайте правый клик и перейдите по адресу 0x3C24FB. Первая инструкция должна быть «CMP [ESP+8], -2». Вы можете установить комментарии для любой строчки кода ниже этой инструкции. Для сохранения комментариев, перейдите в «View -> Executable Modules», сделайте правый клик на lz32.dll и выберите «Actualize», а потом «save UDD files now». Остановите процесс отладки и выйдете с IMM. Перезапустите снова IMM и повторите шаги (1)-(5), вы должны заметить, что все все комментарии, оставленные в предидущей сессии IMM исчезли![/INDENT]

3. Введение в UDD формат

Отсутствие комментариев эта проблема вызванная IMM’ом. Когда структура модуля неверна, то IMM не будет вести себя корректно, когда будет анализировать его участок кода, и, следовательно, не будет создавать соответствующие UDD файлы для lz32.dll (по этой причине все ваши комментарии будут потеряны). IMM создает файлы для записи отладочной информации (например, комментариев, созданных пользователем). Эта секция даст небольшое представление о формате UDD файлов.

Рис. 2. UDD файлы

Несколько фактов про UDD файлы:

  1. Все UDD файлы находятся в папке Immunity Debugger (например, c:\Program files\Imm Inc\Immunity Debugger), как показано на рис. 2.
  2. Для каждого модуля, анализируемого IMM’ом (т.е. Его код показан хотя бы раз в панели кода IMM»а), IMM создаст соответствующий UDD файл. Например, посмотрите на рис. 2 (для анализа Max++, мы однажды остановились в ntdll и соответственно появился ntdll.idd). Файлы «.bak» являются временными для UDD файлов.

Рис. 3. Снимок Max++ _Downloader.udd (в NotePad)

UDD файл представляет собой набор записей, в то время как каждая запись занимает линию. Каждая запись начинается с двоичных данных и продолжается соответствующим комментарием пользователя. Например, на рис. 3, мы видим фрагмент Max++_download.udd, Вы можете видеть, что файл (открытый в NotePad++) соответствует комментариям в окне отладчика IMM.

Рис. 4. Тоже самый UDD-файл в двоичном редакторе HxD

До сих пор нет полной документации формата UDD, тем не менее, легко сделать заключение о бинарных данных в начале каждой записи. Посмотрите на комментарий «ENTRY PC!», показанный на рис. 4 и его последующий комментарий «Standard stack protection for function call».

Двоичные данные перед «ENTRY PC!» - 0x55 73 36 13 00 00 00 C8 3B 01 00…00 0A. Ясно, что тег «55 73 36» отвечает за тип записи (пользовательский комментарий) – тоже самое для следующего комментария «Standard stack protection». Следующие 4 байта «13 00 00 00» показывают, что длина записи равна 0х13 байт, а «C8 3B 01 00» показывает соответствующее ему расположение (начиная от базового адреса модуля) – вы можете это проверить на рис. 3.(расположения комментария находится по адресу 0x413BC8 – отметим, что байты идут в обратном порядке). Ясно, что «00 0A» используется для обозначения конца записи.

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

4. Отладка отлачика

Сейчас мы покажем трюки по отладке в отладчике IMM и решению проблем. Наша цель перенаправить поток выполнения IMM, так что бы он заработал нормально. Следуйте инструкциям указанным ниже:

  1. Запустите IMM и потом откройте исполняемый файл IMM (расположенный в c:\Program Files\Imm Inc\Immunity Debugger). Нажмите F9, что бы запустить его. В этом случаи, у нас есть 2 экземпляра IMM, первый из них будем называть IMM1, второй – IMM2.

Рис. 5. Установка точки останова на IMM

  1. В IMM2 откройте исполняемый файл Max++.
  2. Теперь в IMM1 выберите View -> Executable Modules и сделайте правый клик в IMM и выберите View -> Names. Вы увидите список экспортируемых функций. Вы могли бы сразу заметить, что есть нечто, что нас может заинтересовать в: функция Analyzecode по адресу 0x00411020 (см. Рисунок 5).

Рис. 6. Python Script to Trigger Analyzecode

  1. Мы бы хотели бы вызвать функцию Analyzecode() в отладчике IMM2 и потом проанализировать ее логику работы в IMM1, В IMM2, повторить шаги (1) – (3) в секции 2.2 пока не попадете на адрес 0x401419.
  2. Теперь в отладчике IMM2, нажмите что бы открыть окно Python script (это вторая кнопка на панели инструментов, сразу после кнопки «open file»). Напишите первые две команды: mod = getModule(‘ntdll.dll’); mod.Analyse() (см. Рис. 6). Вы остановитесь на точке останова в IMM1!

Пройдитесь по инструкциям в IMM1 и запомните их. Когда дойдете до конца функции Analyzecode(), нажмите F9 для того что бы запустить IMM1 и вы вернетесь к IMM2.

Теперь сделайте тоже самое для lz32.dll. Заметили ли вы, что что-то изменилось?

5. Задачи дня

  1. Поток исполнения программы, из двух сессий анализа функции analyzecode(), начинает отличаться с инструкции CMP EDX, 7. Определите ее место нахождение.
  2. Значение, содержащееся в EDX, является важным атрибутом DLL-модуля. Можете ли вы определить его значение? (Подсказка: codeSize. Докажите это)
  3. Можете ли вы изменить поток исполнения программы таким образом, чтобы функция analyzecode() была успешно выполнена? После этого, вы можете повторить шаги (4) и (5) из Раздела 2.2 и сделать комментарии. Затем, вы можете убедиться, что в папке «c:\program…\immunity debugger\» был создан файл lz32.udd и ваши комментарии были сохранены.

© Translated by coldfire from r0 Crew