Что такое дамп exe файла
Терминология
Дамп падения (в дальнейшем дамп) – специальный файл, собираемый с помощью библиотеки dbghelp.dll, содержащий в себе информацию о стеке приложения в момент падения. Также содержит в себе информацию о загруженных модулях, хендлах (handles), потоках, участках памяти и т. д. В подавляющем большинстве случаев помогает разобрать стек падения приложения.
Release-версия файла (сокращенно release) – бинарный исполняемый файл, собираемый из исходников проекта. Довольно сильно отличается от отладочной версии (например, наличием оптимизации и отсутствием инициализации данных специальными отладочными значениями) . Существует заблуждение, что release-файлы отлаживать нельзя. На самом деле их отлаживать можно, просто по умолчанию MS Visual Studio не включает поддержку символов в release-версиях. В документации Microsoft сказано, что включение поддержки символов незначительно увеличивает размер бинарных файлов. Однако, по моему личному опыту, размер файла увеличивается (и значительно) . В среднем файл увеличивается на 100 килобайт. На больших проектах это не заметно, но маленькие проекты после этого сильно увеличиваются в размерах.
СОВЕТ
Для включения генерации символов в release-версиях нужно в настройках компилятора выбрать значение «Generate Program Database» для опции «Debug Information Format» (опция компилятора /Zi). Если вы забудете сделать это, файл символов будет построен не полностью и отлаживаться по нему будет невозможно.
PDB-файл (файл символов или просто символы) . При компиляции проекта компоновщик строит исполняемый модуль. Фирмы-производители программного обеспечения уже давно разработали разные методы сохранения информации о строках исходных файлов в модулях символов. В настоящее время наиболее широко (речь идет о Microsoft) используется формат PDB версии 2 (MS Visual Studio 6.0) и PDB 7.0 (MS Visual Studio 7.0+). Данные форматы обеспечивают возможность получения расширенной информации об исполняемых модулях, в том числе возможность разбора стека, получения локальных переменных и т. д.
WinDBG. Один из отладчиков приложений Microsoft. Мое мнение заключается в том, что небольшие системы у себя на компьютере очень удобно отлаживать в Visual Studio, однако как только приложение становится распределенным и сложным, или необходима удаленная отладка в сложных условиях, самое удобное средство – это WinDBG. Повторюсь, что это мое личное мнение. Кроме того, в состав WinDBG входят различные утилиты для облегчения процесса отладки.
Дампы это счтитай резервные копии, самому можно удалять, только оставь три четыре последних на случай восстановления.Это образ куска памяти, который создается при непредвиденном падении программы. Нужен для разработчиков, для того чтобы понять где произошла ошибка. Создание дамп-файлов можно вообще отключить.
На синем экране смерти содержится информация о причинах, вызвавших исключение (в виде кода STOP-ошибки вида 0x0000007b), адреса в памяти, при обращении к которым произошло исключение и прочая полезная информация. Такая информация называется STOP-ошибкой, переменными параметрами которой как раз являются адреса памяти. Иногда там же содержится имя файла, вызвавшего исключение.
Что такое дамп
- dump (англ.) – мусорная куча; свалка; дыра; трущоба.
- dump (memory dump) – 1) дамп, вывод содержимого оперативной памяти на печать или экран; 2) «снимок» оперативной памяти; данные, получаемые в результате дампинга; 3) аварийное снятие, выключение, сброс.
- dumping – дампинг, снятие дампа.
Настройки для сохранения дампа памяти хранятся в системном реестре Windows.
Информация о дампе памяти в системном Реестре:
В разделе Реестра Windows [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl] аварийный дамп памяти определяется следующими параметрами:
– REG_DWORD-параметр AutoReboot со значением 0x1 (опция Выполнить автоматическую перезагрузку вспомогательного окна Загрузка и восстановление диалогового окна Свойства системы);
– REG_DWORD-параметр CrashDumpEnabled со значением 0x0, если дамп памяти не создается; 0x1 – Полный дамп памяти; 0x2 – Дамп памяти ядра; 0x3 – Малый дамп памяти (64КБ);
– REG_EXPAND_SZ-параметр DumpFile со значением по умолчанию %SystemRoot%\MEMORY.DMP (место хранения файла дампа);
– REG_DWORD-параметр LogEvent со значением по умолчанию 0x1 (опция Записать событие в системный журнал окна Загрузка и восстановление);
– REG_EXPAND_SZ-параметр MinidumpDir со значением по умолчанию %SystemRoot%\Minidump (опция Папка малого дампа окна Загрузка и восстановление);
– REG_DWORD-параметр Overwrite со значением по умолчанию 0x1 (опция Заменять существующий файл дампа окна Загрузка и восстановление);
Как система создает файл аварийного дампа памяти
Во время загрузки операционная система проверяет параметры создания аварийного дампа в разделе реестра [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]. Если указан хотя бы один параметр, то система генерирует карту блоков диска, занимаемых файлом подкачки на загрузочном томе, и сохраняет ее в памяти. Система также определяет, какой драйвер дискового устройства управляет загрузочным томом, вычисляет контрольные суммы для образа драйвера в памяти и для структур данных, которые должны быть целыми, чтобы драйвер мог выполнять операции ввода/вывода.
После сбоя ядро системы проверяет целостность карты страничного файла, дискового драйвера и управляющих структур дискового драйвера. Если целостность этих структур не нарушена, то ядро системы вызывает специальные функции ввода/вывода дискового драйвера, предназначенные для сохранения образа памяти после системного сбоя. Эти функции ввода/вывода самодостаточны и не полагаются на службы ядра системы, поскольку в программах, отвечающих за запись аварийного дампа, нельзя делать никаких предположений о том, какие части ядра системы или драйверы устройств при сбое были повреждены. Ядро системы записывает данные из памяти по карте секторов файла подкачки (при этом ему не приходится использовать драйверы файловой системы).
Сначала ядро системы проверяет состояние каждого компонента, задействованного в процессе сохранения дампа. Это делается для того, чтобы при прямой записи в секторы диска не повредить данные, лежащие вне страничного файла. Размер страничного файла должен быть на 1МБ больше размера физической памяти, потому что при записи информации в дамп создается заголовок, в котором содержатся сигнатура аварийного дампа и значения нескольких важнейших переменных ядра системы. Заголовок занимает меньше 1МБ, но операционная система может увеличивать (или уменьшать) размер файла подкачки не менее чем на 1МБ.
После загрузки системы Session Manager (Диспетчер сеанса Windows NT; дисковый адрес – \WINDOWS\system32\smss.exe) инициализирует страничные файлы системы, используя для создания каждого файла собственную функцию NtCreatePagingFile. NtCreatePagingFile определяет, существует ли инициализируемый страничный файл, и если да, то имеется ли в нем заголовок дампа. Если заголовок есть, то NtCreatePagingFile посылает в Session Manager специальный код. После этого Session Manager запускает процесс Winlogon (Программа входа в систему Windows NT; дисковый адрес – \WINDOWS\system32\winlogon.exe), который извещается о существовании аварийного дампа. Winlogon запускает программу SaveDump (Программа сохранения копии памяти Windows NT; дисковый адрес – \WINDOWS\system32\savedump.exe), которая анализирует заголовок дампа и определяет дальнейшие действия в аварийной ситуации.
Сохранив файл дампа, программа SaveDump делает запись о создании аварийного дампа в журнале событий Система, например: «Компьютер был перезагружен после критической ошибки: 0x100000d1 (0xc84d90a6, 0x00000010, 0x00000000, 0xc84d90a6). Копия памяти сохранена: C:\WINDOWS\Minidump\Mini060309-01.dmp».
Разновидности дампов
- Полный дамп памяти записывает всё содержимое системной памяти при возникновении неустранимой ошибки. Для этого варианта необходимо иметь на загрузочном томе файл подкачки, размер которого равен объему всей физической оперативной памяти плюс 1МБ. По умолчанию полный дамп памяти записывается в файл %SystemRoot%\Memory.dmp. При возникновении новой ошибки и создании нового файла полного дампа памяти (или дампа памяти ядра) предыдущий файл заменяется (перезаписывается). Параметр Полный дамп памяти недоступен на ПК, на которых установлена 32-битная операционная система и 2 или более гигабайта оперативной памяти.
При возникновении новой ошибки и создании нового файла полного дампа памяти предыдущий файл заменяется.
- Дамп памяти ядра записывает только память ядра, благодаря чему процесс записи данных в журнал при внезапной остановке системы протекает быстрее. В зависимости от объема физической памяти ПК в этом случае для файла подкачки требуется от 50 до 800МБ или одна треть физической памяти компьютера на загрузочном томе. По умолчанию дамп памяти ядра записывается в файл %SystemRoot%\Memory.dmp.
Этот дамп не включает нераспределенную память или память, выделенную для программ пользовательского режима. Он включает только память, выделенную для ядра и аппаратно-зависимого уровня (HAL) в Windows 2000 и более поздних версиях системы, а также память, выделенную для драйверов режима ядра и других программ режима ядра. В большинстве случаев такой дамп является наиболее предпочтительным вариантом. Он занимает намного меньше места по сравнению с полным дампом памяти, при этом исключая только те сектора памяти, которые, скорее всего, не связаны с ошибкой.
При возникновении новой ошибки и создании нового файла дампа памяти ядра предыдущий файл заменяется.
- Малый дамп памяти записывает наименьший объем полезной информации, необходимых для определения причины неполадок. Для создания малого дампа памяти необходимо, чтобы размер файла подкачки составлял как минимум 2МБ на загрузочном томе.
Файлы малого дампа памяти содержат следующие сведения:
Файл малого дампа памяти используется при ограниченном пространстве жесткого диска. Однако из-за ограниченности содержащихся в нем сведений в результате анализа этого файла не всегда удается обнаружить ошибки, которые не были непосредственно вызваны потоком, выполнявшимся в момент ее возникновения.
При возникновении следующей ошибки и создании второго файла малого дампа памяти предыдущий файл сохраняется. Каждому дополнительному файлу дается уникальное имя. Дата закодирована в имени файла. Например, Mini051509-01.dmp — это первый файл дампа памяти, созданный 15 мая 2009 г. Список всех файлов малого дампа памяти хранится в папке %SystemRoot%\Minidump.
Операционная система Windows XP, несомненно, значительно надежнее предыдущих версий, – благодаря усилиям как разработчиков Microsoft, так и разработчиков драйверов аппаратного обеспечения, так и разработчиков прикладного программного обеспечения. Однако аварийные ситуации – всевозможные сбои и крахи системы – неизбежны, и от того, владеет ли пользователь ПК знаниями и навыками в их устранении, зависит, придется ему затратить несколько минут на поиск и устранение неисправности (например, на обновление/отладку драйвера или переустановку прикладной программы, вызывающей системный сбой), – или несколько часов на переустановку/настройку операционной системы и прикладного программного обеспечения (что не гарантирует отсутствия сбоев и крахов в дальнейшем!).
Многие системные администраторы всё еще пренебрегают анализом аварийных дампов Windows, считая, что работать с ними слишком трудно. Трудно, но можно: даже если, например, анализ одного дампа из десяти окажется успешным, – усилия, потраченные на освоение простейших приемов анализа аварийных дампов, будут не напрасны.
Приведу примеры из своей «сисадминской» практики.
В локальной сети без видимой причины («железо» в порядке, отсутствие вирусов гарантировано, пользователи – с «нормальными руками») «полегли» несколько рабочих станций с Windows XP SP1/SP2 «на борту». Компьютеры загрузить в нормальном режиме не удавалось, – доходило до «Приветствия» – и на перезагрузку до бесконечности. При этом, в Безопасном режиме ПК загружались.
Изучение дампов памяти позволило выявить причину неисправности: виновником оказался антивирус Касперского, точнее, свежие антивирусные базы (если еще точнее, то два модуля баз – base372c.avc, base032c.avc).
В обоих указанных случаях изучение аварийного дампа памяти позволило до минимума (несколько минут!) свести время для диагностирования и устранения неисправности.
Анализ дампа памяти
Для анализа аварийных дампов памяти существует множество программ, например, DumpChk, Kanalyze, WinDbg. Рассмотрим анализ аварийных дампов памяти с помощью программы WinDbg (входит в состав Debugging Tools for Windows).
Установка средств отладки
Использование программы WinDbg для анализа аварийных дампов памяти
Например, на следующем скриншоте причина неисправности – файл nv4_disp.dll драйвера видеокарты:
Итак Господа, начнём.
Предложение Сэра Solenij и да сподвигло меня накатать этот небольшой мануал для самых маленьких , в смысле начинающих русификаторщиков.
Что бы они знали чем отличается Дамп от Домкрата.
Предисловие:
Не буду здесь писать о многочисленных видах переводов на основе файлов ресурсов с расширениями типа *INI, *LNG, *DAT и других.
Итак:
Начну с того что объясню что существует два основных вида русификаторов.
Это собственно перевод исполняемого файла с расширением *EXE
и файла ресурса с расширением *RU.
Ну как переводится *EXE я полагаю всем известно
- распаковка (если упакован) ну и собственно
- перевод кому чем нравится.
Основная масса программ написана на языках программирования - "Microsoft Visual C++" и "Borland Delphi".
Ресурсы программ написанных на Microsoft Visual C++ состоят из "Меню" и "Диалоги".
Ресурсы программ написанных на Delphi состоят из: "Формы" и "Строки" по этому признаку можно их определить любым редактором ресурсов без анализаторов типа PEID и т.п.
Так вот напомню что файлы *RU (Дампы) поддерживаются только программами написанными на Delphi.
При запуске программа загружает данные файла *RU в память и мы видим русский интерфейс.
Кто использовал Multilizer, мог заметить что там есть выбор какой делать файл локализации "Файлы локализации (*EXE)" или "Файлы ресурса (*RU)"
Собственно файл *RU является файлом идентичным *EXE только не содержит кода программы, а только ресурсы.
Но здесь мы рассмотрим перевод файла с расширением *RU сделанного на основе Дампа.
Это даёт возможность не распаковывать упакованную программу.
На этом собственно вводный экскурс заканчивается и дальше начинается самая сласть.
Изготовление Дампа:
Для изготовления Дампа нам потребуется программа PETools 1.5. Взять можно здесь
Пример с созданием Дампа программы "DVD Creator":
Шаг первый:
Запускаем упакованную программу и тут же сворачиваем её в панель бастрого запуска чтобы не мешалась.
Шаг второй:
Запускаем PETools и находим в её верхнем окне процесс нашей программы. Щёлкаем по её значку и он перемещается в нижнее окно.
Шаг третий:
Щёлкаем правой кнопкой мыши на процессе нашей программы в нижнем окне и выбираем "Dump Full. "
В появившемся диалоговом окне, выбираем папку куда хотим сохранить наш "Дамп" и жмём "Сохранить".
Всё наш "Дамп" готов!
Итак, представим для начала, что у нас на руках зараженная машина. Первым делом нужно выполнить три основных действия: изолировать компьютер от других в сети, сделать дамп памяти и снять образ диска.
При отключении зараженного компьютера от сети стоит помнить, что если мы имеем дело с вирусом-шифровальщиком, то есть шанс потерять пользовательские данные. Малварь может начать шифровать их, когда прервется соединение с сетью, поэтому первым делом оцени, насколько важны данные на зараженном ПК и стоит ли рисковать.
Лучше всего будет создать для карантина виртуальную сеть (VLAN) с выходом в интернет и переместить туда зараженные ПК. В крупной компании это потребует слаженных действий сотрудников службы кибербезопасности и сетевых администраторов, в мелкой — разноплановых навыков единственного сисадмина.
Дальше необходимо снять дамп памяти. Делается это с самого начала, потому что при копировании жесткого диска потребуется выключить компьютер и содержимое оперативной памяти будет потеряно. Программу, снимающую дамп, лучше всего запускать с внешнего носителя, чтобы не оставлять лишних следов на жестком диске — данные с него понадобятся нам в неизмененном виде.
Чтобы малварь не успела среагировать на выключение системы, проще всего выдернуть кабель питания. Метод, конечно, варварский, зато гарантирует моментальное отключение. Сохранить данные на жестком диске нетронутыми для нас важнее, чем беспокоиться об исправности других компонентов.
Дальше запустим ПК, используя загрузочный носитель с любой операционной системой в режиме forensic и ПО для получения образа жесткого диска. Чаще всего используется образ диска в формате E01 (Encase Image File Format). Его поддерживает большое число приложений как для Windows, так и для Linux.
Режим forensic — это загрузка без монтирования физических дисков. Это позволяет исключить внесение любых изменений в исследуемый диск. Профессиональные криминалисты также используют устройства, позволяющие заблокировать любые попытки обращения к диску для записи.
Изучение дампов
Дампы памяти и диска, скорее всего, содержат всё, что нам необходимо, — тело вредоносной программы и оставленные ей следы. Можем приступать к поиску.
Я рекомендую начинать с изучения копии диска, а дамп памяти использовать, если на диске не удастся обнаружить никаких следов либо как дополнительный источник. При анализе содержимого диска в первую очередь обращаем внимание на автозагрузку, планировщик задач и начальный сектор загрузки диска.
На сайте Microsoft есть документация по автозагрузке сервисов и библиотек.
Чтобы понять, каким путем малварь проникла на компьютер, стоит исследовать время создания и изменения файлов на диске, историю браузера и почтовый архив пользователя. Если получится установить хотя бы примерное время заражения, то это будет плюсом. В интернете есть неплохие подборки путей в файловой системе и реестре, на которые стоит обращать внимание в первую очередь (вот, например, неплохая статья Group-IB об этом).
Из дампа памяти ты тоже можешь извлечь некоторую уникальную информацию, например какие были открыты документы и вкладки браузера в момент заражения, какие были активные сетевые подключения, рабочие процессы (в том числе скрытые).
Анализ файла
Также нельзя исключать, что ты столкнулся с угрозой нулевого дня (0-day) — той, о которой еще никому не известно (и у разработчиков есть ноль дней на ее устранение — отсюда и название). Малварь, которая эксплуатирует зиродеи и имеет статус FUD, представляет серьезную угрозу не только для отдельных компьютеров, но и для целых компаний.
Перед началом анализа подозрительного файла необходимо сделать следующее.
- Подготовить стенд для исследования — виртуальную машину с установленной операционной системой, подходящей для запуска исследуемого файла.
- Настроить выход в интернет, желательно обеспечив скрытие своего реального IP-адреса, чтобы не потерять связь с серверами управления малвари (тебя могут распознать как вирусного аналитика и ограничить доступ, чтобы скрыть какие-то функции).
- Сделать снимок (snapshot) первичного состояния виртуальной машины.
Ни в коем случае не подключай стенд в корпоративную сеть — это может вызвать массовое заражение других компьютеров.
Существует два подхода к анализу ПО — динамический и статический. Как правило, для лучшего эффекта используют более подходящий для ситуации метод или оба метода одновременно. Например, может быть необходимо изучить поведение вредоносной программы, чтобы выявить характерные маркеры без анализа алгоритмов. Поэтому выбор методов и инструментов может меняться в ходе анализа.
Статический анализ
Начнем со статического анализа, поскольку он не требует запускать вредоносный код и точно не вызовет заражения на твоем компьютере.
Рассмотрим начальные заголовки исполняемого файла для Windows.
- DOS-заголовок файла, также известный как DOS-заглушка. Благодаря ему возможен запуск программы в DOS (обычно всего лишь выводится надпись This program cannot be run in DOS mode). Можно увидеть начало заголовка по характерным буквам MZ .
- Сразу же за первым идет используемый современными ОС заголовок со всеми необходимыми параметрами для исполняемого файла (например, смещение до таблицы импорта/экспорта, начало секции исполняемого кода). Начало заголовка можно найти по характерным буквам PE, а описание формата есть на сайте Microsoft.
Можно сказать, что заголовок исполняемого файла содержит справочник о том, где и что именно находится внутри самого файла, какие разрешения должны быть выданы секциям, все настройки для корректной работы, поэтому анализ заголовка может дать ценную первоначальную информацию.
Кроме этого, необходимо просмотреть, нет ли в файлах строковых данных. По ним можно впоследствии определять подобные файлы или даже получить важную информацию вроде адресов серверов управления.
Перед разработчиками малвари всегда стоит задача как можно сильнее маскировать свое творение и всячески усложнять обнаружение и анализ. Поэтому очень часто используются упаковщики для исполняемых файлов.
Упаковщики ― утилиты для сжатия и шифрования исполняемых файлов. Используются не только создателями малвари, но и разработчиками легитимного ПО для защиты от взлома своих программ. Самописные упаковщики, специально созданные для затруднения анализа, не всегда детектируются программами и потребуют от аналитика дополнительных действий, чтобы снять упаковку.
Более глубокий (и в то же время сложный) анализ любых исполняемых файлов ― это применение дизассемблеров. Ассемблерный код понятнее для человека, чем машинный, но из-за объемов разобраться в нем бывает далеко не так просто. В отдельных случаях возможно восстановить исходный код программ на языке высокого уровня путем декомпиляции — если удастся определить, какой использовался компилятор и алгоритм обфускации.
Словарь терминов
- Дизассемблеры ― программы для перевода машинного кода в относительно удобочитаемый и понятный язык ассемблера.
- Декомпиляция — восстановление исходного кода программы на изначальном языке программирования.
- Обфускация ― изменение исходного кода программы так, что его функциональность сохраняется, но сам он усложняется и в нем появляется ничего не добавляющий мусор.
- Обфускаторы ― программы для автоматизации обфускации.
- Псевдокод ― как правило, так называют неформальный язык описания алгоритмов, который позволяет представить исследуемый код на ассемблере в более читаемом виде. При переводе в псевдокод малозначимые элементы алгоритма отбрасываются.
Анализ кода на ассемблере ― трудоемкий процесс, который требует больших затрат времени и хороших навыков низкоуровневого программирования, поэтому для быстрого анализа можно преобразовать полученный код в псевдокод. Читать псевдокод более удобно, чем ассемблер, это можно увидеть по следующему примеру, где слева оригинальный код на ассемблере, а справа — псевдокод.
Код на ассемблере
Псевдокод
Динамический анализ
Чтение псевдокода или кода на ассемблере подобно распутыванию клубка ниток — кропотливо и трудоемко. Поэтому можно воспользоваться другим видом анализа — динамическим. Динамический анализ подразумевает запуск исполняемого файла и отслеживание выполняемых им действий, таких как обращение к веткам реестра, отправка и получение данных по сети, работа с файлами.
WARNING
Динамический анализ предполагает запуск исследуемого файла. Это необходимо делать на виртуальной машине, изолированной от других компьютеров, чтобы избежать возможности распространения вредоноса по сети.
Анализировать поведение программы можно, отслеживая и перехватывая запуск приложений на уровне ОС либо подключившись к работающему процессу и перехватывая вызовы библиотек и API. А чтобы детально разобрать процесс выполнения программы, лучше всего воспользоваться одним из отладчиков.
Отладчик ― утилита или набор утилит, который используется для тестирования и отладки целевого приложения. Отладчик может имитировать работу процессора, а не запускать программу на настоящем железе. Это дает более высокий уровень контроля над выполнением и позволяет останавливать программу при заданных условиях. Большинство отладчиков также способны запускать выполнение исследуемого кода в пошаговом режиме.
Неважно, используешь ты отладчик или какую-то программу, которая позволяет контролировать вызовы API, — работать придется в ручном режиме. А это значит, что потребуются углубленные знания операционной системы, зато ты получишь самые полные данные об объекте исследования.
Однако анализ можно и автоматизировать. Для этого используются так называемые песочницы (sandbox) — тестовые среды для запуска ПО.
Песочницы делятся на два типа: офлайновые и онлайновые. Для получения наиболее полной картины я рекомендую использовать сразу несколько источников данных и не исключать какой-то из типов песочниц. Чем больше информации ты соберешь, тем лучше.
Пример анализа
Поскольку анализ малвари всегда упирается в практические навыки, эта статья была бы неполной без демонстрации его на примере. Проведем экспресс-анализ и установим природу исполняемого файла.
Для начала определимся с последовательностью действий. Вот что нам нужно сделать:
- получить хеш-сумму с файла;
- воспользоваться онлайновым сервисом для проверки файла;
- собрать статические данные из файла;
- проверить файл в песочнице (локальной или в интернете);
- запустить файл в виртуальной среде для отслеживания выполняемых действий;
- снять оболочки и получить развернутый в памяти вредонос;
- проанализировать код в дизассемблере.
Допустим, нам необходимо исследовать неизвестный файл Sample.exe .
Для хранения файла рекомендую первым делом изменить расширение, например на Sample._exe , чтобы избежать случайного запуска.
Делаем снимок (snapshot) виртуальной машины, на которой и будем запускать исполняемый файл (изначальное состояние системы нам еще пригодится), и считаем хеш-сумму файла.
Получение хеш-суммы файла
Видим, что он выдает схожий результат (смотри в правом нижнем углу). Кроме того, можно собрать дополнительные данные о том, что делала программа. А именно:
- после старта продублировала себя в памяти;
- обратилась к серверу 208.91.199.224 по порту 587. На платформе можно посмотреть сетевой дамп взаимодействия с сервером управления малварью (их часто называют Command & Control, C2 или C&C);
- добавила запрет на запуск диспетчера задач;
- скопировала себя в отдельную пользовательскую директорию;
- добавила себя в автозагрузку.
Даже если бы вердикт не указал на возможную угрозу, отключение диспетчера задач и добавление в автозагрузку не сулит ничего хорошего для пользователя, особенно если учесть, что все это было сделано сразу же после запуска.
Итак, уже два сервиса подтвердили, что это малварь. Продолжаем. Воспользуемся инструментом под названием DIE.
Открываем файл с помощью DIE
Detect it easy (DIE) ― утилита, позволяющая импортировать и экспортировать список ресурсов, извлекать манифест и версию ПО, просматривать вычисления энтропии. Есть возможность добавить свои собственные алгоритмы обнаружения или изменить существующие. Это делается с помощью скриптов на языке, напоминающем JavaScript.
Как можно видеть на скриншоте, малварь написана на Visual Basic. Ты легко нагуглишь структуру программ на Visual Basic 6.0 и описание принципов их работы. Если коротко, то запускаются они в виртуальной среде, а значит, нам нужно поймать момент, когда этот код будет распакован в памяти. Также можно проанализировать структуру файла и получить название проекта, использованные формы и прочие данные.
Другой способ узнать, что малварь написана на Visual Basic, — использовать CFF Explorer.
CFF Explorer ― набор инструментов с единым минималистичным интерфейсом, который позволяет просматривать и при необходимости редактировать все секции заголовка исполняемого файла. Здесь же можно увидеть импорты и экспорты функций из библиотек, перечень самих библиотек и адресацию секций.
В этом случае мы увидим характерную импортированную библиотеку — ее наличие говорит о том, что используются функции Visual Basic.
Следующим шагом запускаем Hiew и, перейдя на начало исполняемого кода, обнаруживаем вызов функции из библиотеки.
Hiew ― редактор двоичного кода со встроенным дизассемблером для x86, x86-64 и ARM. Также им можно открывать физические и логические диски как файл. Hiew ― «легковесная» (в отличие от IDA) и при этом очень мощная программа, которая позволяет составить первое впечатление об исследуемом объекте.
На данном этапе нам достаточно знать, что при запуске будет исполняться код на Visual Basic.
Пришло время попробовать вытащить код и зафиксировать поведение при запуске. Для этого нам потребуется приготовленная виртуальная машина с Windows, Process Dump и API Monitor.
API Monitor ― программа, которая позволяет контролировать вызовы функций API приложениями и сервисами в Windows, перехватывает информацию о запуске приложений или подключается к выполняемому процессу, чтобы просмотреть используемые библиотеки и вызовы API.
В API Monitor запускаем Sample.exe и получаем следующую картину: стартует еще один процесс, после чего первый завершается, далее программа добавляется в автозагрузку.
Просмотр API-вызовов файла при помощи API Monitor
Находим указанный исполняемый файл, это первоначальный файл, записанный в директорию пользователя.
Обнаружили копию в автозагрузке, на диске, открываем файл в DIE
Программа еще и отключает возможность вызвать диспетчер задач.
Просмотр API-вызовов файла при помощи API Monitor
Этого уже вполне достаточно, чтобы с уверенностью сказать, что файл вредоносный.
Выгрузим из оперативной памяти работающий процесс. Воспользуемся утилитой для выгрузки дампа процесса ― Process Dump. PID берем из данных API Monitor, он отображается рядом с именем процесса.
Использование утилиты Process Dump
В результате будут выгружены все библиотеки, которые использует приложение. Также обнаруживаем, что в адресном пространстве, кроме основного исполняемого файла, есть еще и спрятанные, это можно увидеть ниже, в имени файла есть слово hiddenmodule.
Результат работы утилиты Process Dump
Проверяем каждый полученный исполняемый файл в DIE.
Открываем каждый файл в DIE
Просмотр кода в dnSpy
Для анализа двух оставшихся файлов воспользуемся дизассемблером IDA.
IDA ― популярный интерактивный дизассемблер компании Hex-Rays. Имеет бесплатную и пробную версии, чего вполне достаточно для первичного знакомства. Также компания выпускает версию Pro. Основная задача программы ― это перевод исполняемых файлов из бинарного вида в читаемый код на ассемблере.
Как видно из примера, IDA позволяет получить код программы на ассемблере, но для более удобного просмотра и первоначальной оценки можно воспользоваться плагином Snowman и получить псевдокод.
Просмотр псевдокода в IDA
Использование псевдокода упрощает анализ, но не всегда дает ожидаемый результат. Дизассемблирование и создание псевдокода выполняются автоматически, и у вирусописателей есть техники для их усложнения. Такое вот вечное противостояние меча и щита, интеллекта создателя малвари и интеллекта вирусного аналитика.
Мы, когда использовали API Monitor, уже выявили вредоносную сущность этого файла по совершаемым действиям. Но пока что не знаем, каков потенциал этой малвари. Чтобы получить полный алгоритм работы этого исполняемого файла, необходимо углубляться в анализ как ассемблерного кода, так и программы на Visual Basic, но это выходит за рамки статьи.
Заключение
Если у тебя создалось впечатление, что мы бросили исследование в самом начале пути, то оно отчасти справедливо: здесь мы проделали лишь те действия, которые не требуют знания ассемблера. Однако, как видишь, провести экспресс-анализ и установить, чего можно ждать от малвари, вполне реально и без этого.
При полноценном же разборе потребуется глубокое понимание принципов работы операционной системы и, конечно, знание ассемблера.
Читайте также: