Skip to content

Latest commit

 

History

History
183 lines (122 loc) · 15.5 KB

12_utils.md

File metadata and controls

183 lines (122 loc) · 15.5 KB

12. Полезные утилиты и скрипты Natch

Помимо создания проекта, записи и воспроизведения сценариев пользователям доступен еще ряд действий. Часть из них включена в командный интерфейс Natch, другая на данный момент существует в виде отдельных скриптов.

Во время подготовки объекта оценки для анализа часто возникает необходимость извлечь бинарные файлы из образа в хостовую систему. Для этого есть разные способы, одним из которых является скрипт copy_files.py (находится в папке guest_system).

Скрипт принимает ряд параметров:

copy_files.py [-h] [-l LOG] [-d] img dest paths [paths ...]
  • img Путь к образу гостевой операционной системы (обязательный).

  • dest Путь к директории, в которую будут сохранены копируемые файлы (обязательный).

  • paths Список, содержащий пути до файлов/директорий (обязательный).

  • -l, --log Путь к файлу, в который будет записан журнал работы.

  • -d, --debug Флаг включения диагностических сообщений.

Пример запуска скрипта:

sudo ./copy_files.py <path_to_img> <path_to_dest_folder> <list_paths_to_copy>

Обратите внимание на необходимость запуска скрипта с правами суперпользователя.

12.2. Автоматическая загрузка отладочной информации для разделяемых библиотек

В поставку инструмента входит скрипт debug_info.py (находится в папке guest_system/debuginfo_collector), позволяющий получить символьную информацию из системных библиотек, работавших с исследуемыми приложениями. В процессе выполнения скрипта для каждого исполняемого файла происходит поиск необходимых для него разделяемых библиотек. Для всех найденных библиотек загружается отладочная информация, если она доступна. На выходе получается новый конфигурационный файл module.cfg, дополненный найденными библиотеками с отладочной информацией.

Для запуска данного скрипта, потребуется заранее сгенерированный конфигурационный файл debug_info.cfg, содержащий в себе следующие секции:

Секция Common

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

  • Поле attempts: является обязательным и определяет число итераций, в ходе которых скрипт пытается получить доступ к различным интернет-ресурсам. В случае временной недоступности указанных ресурсов скрипт ожидает определенный промежуток времени перед повторной попыткой обращения к ним.

  • Поле mount: определяет необходимость монтирования гостевой системы и, по умолчанию, имеет значение True. В случае, если гостевой образ не может быть смонтирован по каким-либо причинам, можно запустить данный скрипт в Лёгком режиме, установив данный параметр в значение False. При этом дальнейший анализ ограничивается исключительно поиском отладочных символов для модулей, указанных в конфигурационном файле хостовой системы. Этот поиск происходит либо в пользовательской директории, либо с использованием сервиса DebugInfoD, при условии, что пользователь дал на это согласие. Указание параметра False препятствует автоматическому определению типа гостевой операционной системы. Рекомендуется указать сервера для сервиса DebugInfoD, соответствующие вашей операционной системе.

  • Поле debug: флаг включения диагностических сообщений, по умолчанию, имеет значение False.

Секция Configs

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

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

  • Поле guest: содержит путь к конфигурационному файлу, в котором перечислены пути до модулей, которые находятся в гостевой ОС.

Секция Symbols

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

  • Поле kernel: флаг разрешения загрузки символьной информации для ядра. При установке соответствующего флага, скрипт позволяет выкачивать из образа ядро вместе с его символьной информацией. Если не удалось определить, какое ядро используется, то выкачивается информация для всех ядер, найденных в каталоге \boot.

  • Поле python: флаг разрешения загрузки символьной информации для Python интерпретаторов.

  • Поле csharp: флаг разрешения загрузки символьной информации для C#.

  • Поле java: флаг разрешения загрузки символьной информации для Java.

Секция UserFolder

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

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

Секция DebugInfoD

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

  • Поле servers: содержит пользовательский список серверов, специфических для конкретных операционных систем. Сервера по умолчанию установлены для операционных систем Ubuntu, Fedora, Alt и Debian. Формат поля: servers=['https://example1.com', 'https://example2.com'].

Секция PackageAnalysis

При активации данной секции перечень доступных методов для поиска отладочных символов будет дополнен методом пакетного анализа гостевой операционной системы, если он был реализован для вашей гостевой ОС. На данный момент это: Ubuntu, Fedora, Alt 10 и Alpine (работает с последними версиями пакетов). Оставьте эту секцию закомментированной или удалите её, если этого не требуется.

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

В дополнение к описанным выше методам поиска отладочных символов, если гостевая система была смонтирована, автоматически происходит поиск уже установленных отладочных символов в директории по умолчанию (/usr/lib/debug) для всех типов гостевых операционных систем.

Скрипт принимает ряд параметров:

sudo debug_info.py [-h] cfg_path img workdir
  • cfg_path Путь к конфигурационному файлу (обязательный).

  • img Путь к образу гостевой операционной системы (обязательный).

  • workdir Рабочая директория скрипта (обязательный).

В результате выполнения скрипта в рабочей директории будет создана директория debug_info. Внутри нее создаются поддиректории guest_libs и host_libs, где будут храниться файлы, найденные в гостевом и хостовом конфигурационных файлах соответственно. В каждой из этих поддиректорий будут находиться директории libs и dwz (если были обнаружены дополнительные отладочные символы). Каждая из этих директорий будет содержать поддиректории с md5-хешем файла, находящегося в этой директории. Отладочные символы будут располагаться в директории с тем же хешем, что и модуль, к которому они относятся.

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

В случае возникновения ошибки монтирования, следует выполнить следующие действия:

  • Проверьте, не используется ли данный образ другими программами или не был ли он смонтирован ранее.
  • Проверьте, не запущена ли виртуальная машина, например, VirtualBox.
  • Убедитесь, что все требуемые зависимости установлены: выполните команду sudo pip3 install -r guest_system/requirements.txt.
  • Попробуйте смонтировать образ вручную с использованием команды sudo guestmount -a img_path -i mount_point --rw. Исправьте ошибки, если это возможно. Для размонтирования образа используйте команду sudo guestunmount mount_point.

Пример запуска скрипта:

sudo ./debug_info.py <path_to_debug_info_config> <path_to_system_img> <path_to_workdir>

Обратите внимание на необходимость запуска скрипта с правами суперпользователя.

Важно заметить, что выполнения только debug_info.py недостаточно. Необходимо завершить настройку запуском еще одного скрипта symbol_info.py. Он предназначен для получения символьной информации из исполняемых файлов и записи ее в специальный каталог vmidb.

Скрипт принимает ряд параметров:

symbol_info.py [-h] [-d] cfg_path workdir
  • cfg_path Путь к конфигурационному файлу module.cfg (обязательный).

  • workdir Рабочая директория проекта (обязательный).

  • -d, --debug Флаг включения диагностических сообщений.

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