как узнать чем запакована программа
Как узнать чем запакована программа
Программы из данного раздела помогут определить, чем скомпилирована/упакована программа.
Анализатор DiE предназначен для определения типа пакера/протектора/компилятора у ЕХЕ-файлов. Т.е. позволяет узнать,
чем же сжат файл, что необходимо для дальнейшей распаковки. Также программа имеет ряд полезных функций, таких как просмотр импорта, просмотр секций, просмотр HEX, дизассемблирование файла, просмотр основных характеристик ЕХЕ, получение хеша MD 5, получение CRC-32, поддержка плагинов (PDK можно скачать с официального сайта программы).
Анализатор от арабских разработчиков из команды AT4RE. Часто выходят обновления сигнатур.
Анализатор, имеющий базу сигнатур по компиляторам, протекторам, упаковщикам, даже некоторым вирусам и дающий рекомендации по распаковке/декомпиляции файлов. Есть 9 встроенных плагинов.
Один из самых популярных анализаторов исполняемых файлов. Хорошо определяет многие упаковщики и протекторы. Есть три уровня глубины сканирования, возможность сканирования в памяти и по всем вложенным папкам. Официальный релиз PEiD 0.94 от 10 мая 2006, вся самая свежая база внешних сигнатур и плагинов.
Особенности программы: написана на Ассемблере; точность определения упаковщика/протектора/компилятора 95-99%; при сканировании проходят сразу три фазы: normal scan, deep scan, hard scan; может сканировать директории; с помощью Entropy.dll можно выяснить запакован ли файл (demo-версия); может отыскать OEP файла (demo-версия).
Хорошая программа для определения протекторов и упаковщиков. Умеет определять некоторые популярные защиты игр от копирования (Safedisc, CD Lock, Starforce и др.).
Достаточно хороший определитель компиляторов/упаковщиков/протекторов.
Реверсинг малвари для начинающих. Вскрываем упаковщики, ломаем протекторы
Содержание статьи
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Сага о протекторах и упаковщиках
Один из излюбленных приемов зловредописателей — использование упаковщиков (packers) и протекторов (protectors) исполняемых файлов (хотя это также относится и к DLL). Изначально эти инструменты считались весьма банальными и были призваны, по сути, уменьшать размер скомпилированного файла, а в случае протекторов — позволять модифицировать авторам свои программы, превращая их, к примеру, в demo- или trial-версию, и не заморачиваться с защитой в основном коде. Но позднее вирусописатели приспособили эти инструменты в корыстных целях.
Создатели вредоносов успешно стали применять их, чтобы усложнить антивирусный и эвристический анализ, защитить свои детища от запуска в виртуальной среде, отладки, дизассемблирования и последующего анализа. Поэтому с тех пор навыки и умения распаковывать исполняемые файлы вошли в обязательные требования как для начинающего, так и для опытного реверс-инженера. Наиболее популярные сегодня упаковщики — UPX, ASPack, FSG, PeShield, VMProtect. Это, так сказать, джентльменский набор, с которым аналитику приходится сталкиваться каждый день.
Протекторы, в отличие от упаковщиков, призваны защитить исходный файл от обратной разработки, соответственно, при этом они используют более изощренные методы, чем просто упаковщики: обфускацию, шифрование с использованием самописного либо популярного криптоалгоритма, такого, например, как RSA-1024, встраивание антиотладочных функций.
Как мы понимаем, чтобы добраться до нужного нам кода, который мы будем анализировать, сначала требуется распаковать файл, то есть снять все навесные защиты, восстановить оригинальную OEP и таблицу импорта, это как минимум. Частенько распаковка — это задача, укладывающаяся в стандартный набор действий, но иногда она становится творческой и выливается в целое хакерское исследование — с ящиками пива, блоками сигарет и сантиметрами сожженных нервных волокон :).
Ликбез по теории
Итак, как мы понимаем, использование упаковщиков/протекторов/крипторов значительно усложняет реверсинг. Помимо этого, писатели зловредов могут использовать многократную упаковку (так называемый послойный пак), применять малоизвестные или вовсе самописные тулзы (для тех, кто хочет накодить что-то свое, небольшой ликбез), сигнатуры которых будут отсутствовать, к примеру, в том же PEiD. Интересно, что любой пакер, не созданный специально для шифрования малвари, оставляет свою уникальную сигнатуру в бинарнике, а соответственно, умея пользоваться Hex-редакторами, можно определить его сигнатуру и без PE-анализатора.
Общий принцип рассматриваемых инструментов упаковки/защиты таков: после клика на EXE-файле и его запуска выполнение основного кода программы начинается с так называемой точки входа (Entry Point) — адреса, по которому передается управление после загрузки программы в оперативную память. Когда программа запакована, алгоритм работы несколько изменится. Упаковщик запоминает точку входа EP, потом, используя алгоритмы архивирования, сжимает содержимое файла (как правило, это секция кода и данных), после чего дописывает свою сигнатуру после либо до сжатого кода программы и перенаправляет ее не в основной код программы, а в код упаковщика (точнее сказать — распаковщика). Сам же код распаковщика, находящийся теперь внутри файла, получает управление первым и распаковывает упакованные секции кода/данных в памяти! На диске исходный файл остается нетронутым, то есть упакованным, неизменным. После того как код и данные программы распакованы, код распаковщика восстанавливает таблицу импорта и передает управление основному коду программы, на бывшую точку входа, которая в упакованных программах называется оригинальной точкой входа (Original Entry Point). Если кратко, то это все основные моменты.
Схема упаковки исполняемого файла
Xakep #217. Сценарий для взлома
Сжатие данных (упаковка) основывается на свойстве энтропии информации, а алгоритмы по своей сути очень схожи с теми, что применяются в архиваторах, только в отличие от первых упаковщики для исполняемых файлов распаковывают данные в оперативную память.
Протекторы, как и некоторые упаковщики, используют ряд приемов борьбы с динамической распаковкой, например расшифровывают код не полностью, а лишь по мере исполнения или создают образ и распаковывают его в память только на момент запуска. Протекторы, используя API-функции, могут определять, что их код запущен под отладчиком, после чего прекращают свою работу. Причиной тому — результат вызова функции API IsDebuggerPresent(), которая определяет, отлаживается программа или нет. Помимо этого, протекторы внедряют процедуры проверки целостности исходного файла, шифруют таблицу импорта, запрещают снятие дампа с определенных адресов виртуальной памяти и иногда используют малодокументированные и недокументированные API-функции, защищающие от трассировки и установки аппаратных точек останова.
Ручная и автоматическая распаковка
С большой долей вероятности все рабочие экземпляры малвари будут запакованы тем или иным упаковщиком/протектором. Но чтобы все-таки убедиться, что файл запакован, запускаем PEiD или любой другой PE-анализатор. В 90% случаев этого будет достаточно, PEiD имеет большую базу данных сигнатур и плагинов, что позволяет обойтись без лишних хлопот.
Дальнейшим шагом станет распаковка файла (восстановление) в его исходный (wild source) вид. И тут есть несколько сценариев действий. Первый — это использовать автораспаковщики, тулзы, специально заточенные под автоматическую распаковку файла, основываясь на уже известном алгоритме упаковщика/протектора. Например, UN-PACK — это анпакер для UPX, ACKiller — для программ, защищенных протектором ACProtect, Stripper — для файлов, запакованных ASProtect, ASPack unp — для накрытых упаковщиком ASPack.
Второй вариант — использовать универсальные распаковщики, например QuickUnpack, RL!dePacker или Dr.Web FLY-CODE Unpacker, основанный на движке FLY-CODE антивируса Dr.Web. Фича программ в том, что они сами автоматически анализируют файл и ищут в нем ОЕР, а после дампят программу (в том числе и импорт восстанавливают). Однако часты случаи, когда сдампленный файл оказывается неработоспособным из-за некорректности его обработки универсальным распаковщиком или из-за изменения алгоритма пакера, который несовместим с тем, что использует универсальный распаковщик. Но есть и плюс: иногда, если файл не удается распаковать до рабочего состояния, секция кода в любом случае получается распакованной, а этого вполне достаточно для анализа.
И третий сценарий, более длительный, но в перспективе более успешный, — ручная пошаговая распаковка с помощью OllyDbg. Если файл запакован чем-то неизвестным, это легко определить по наличию в таблице импорта защищаемого приложения WinAPI-функций из библиотеки kernel, таких как GetProcAddressA, LoadLibraryA или GetModuleHandle.
Рекомендую прочесть статью с подробным описанием всех существующих на сегодня анализаторов, в ней можно ознакомиться с кратким описанием каждого и даже их скачать.
А вот аналогичная страница, но только на этот раз про распаковщики (на всякий случай зеркало тут).
Авторы вредоносного ПО широко используют упаковщики и протекторы для усложнения его детектирования и для противодействия анализу. Большинство из них анализируются стандартным арсеналом инструментов реверс-аналитика, но некоторые требуют нестандартного подхода и глубокого знания PE-архитектуры.
Учимся скрывать присутствие отладчика и обходить методы противодействия
В одной из статей нашего журнала были описаны наиболее интересные плагины для OllyDbg. Нам обязательно понадобятся:
Все самые нужные плагины OllyDbg 2.xx Plugins можно забрать с файлового архива Tuts4you тут и тут. Набор плагинов для IDA Pro с подробным описанием доступен на GitHub или на Tuts4you. Тем же, кто готов написать свой плагин, могу рекомендовать интересную статью.
Шифрование кода
При анализе различных защит нередко приходится определять, какой алгоритм был использован для шифрования данных. Часто зловредописатели не изобретают велосипедов, а используют уже готовые алгоритмы шифрования. К примеру, если алгоритмы стандартные, то их можно идентифицировать по некоторым характерным константам-полиномам, таблицам преобразований или по последовательности выполняемых операций. Для поиска криптоалгоритмов в исполняемых файлах созданы специальные программы, которые можно посмотреть и скачать тут.
Наиболее популярен плагин Krypto ANALyzer для PEiD. Найденные значения можно просто посмотреть или экспортировать в скрипт для дизассемблера IDA Pro.
Краткое руководство по анализу
Типовой набор действий банален: определение сигнатуры упаковщика, поиск OEP, дамп программы на диск, восстановление таблицы импорта, восстановление релоков, пересборка. А если же файл не просто был запакован, а еще и обработан протектором, то могут потребоваться дополнительные действия, такие, например, как удаление мусорных инструкций, обход антиотладочных приемов, изоляции функций проверки целостности кода CRC.
Несколько слов о динамических библиотеках. Распаковка DLL практически не отличается от распаковки EXE-файла. У DLL, как и у EXE, есть точка входа в код программы — Entry Point, созданная пакером, и оригинальная OEP. Таким образом, нужно остановиться на DLL в Entry Point, распарсить и оттуда идти к единственно верной OEP нашей DLL. Дальше можно стандартно дампить. И еще пара коротких абзацев из матчасти, которая сегодня нам пригодится.
Несколько слов о breakpoints (точках останова)
Точки останова — часто используемый и незаменимый прием любого реверс-аналитика. Основные режимы — это:
OllyDbg поддерживает несколько видов брейк-пойнтов:
Шпаргалка: способы адресации
Немного о том, как передать управление в другую часть кода.
Как узнать чем запакована программа
Программы для анализа исполняемых файлов
Перед атакой на любую навесную защиту полезно узнать какой упаковщик или протектор был использован. С опытом вы сможете определять на глаз большинство протекторов, но для более точной проверки используются анализаторы исполняемых файлов. Кроме информации об упаковщике или протекторе они также предоставляют много других полезных данных: каким компилятором был создан файл, размеры и названия секций, коэффициент сжатия, точку входа и дизассемблированный фрагмента кода на ней, и др. В разных программах список возможностей может различаться.
PEiD, последняя версия 0.95 от ноября 2008 года. Самый популярный анализатор исполняемых файлов. Анализ производится по внутренней и внешней базе сигнатур, есть несколько уровней сканирования от быстрого до глубокого, можно обрабатывать целые каталоги. Функционал легко расширяется внешними плагинами, сигнатуры хранятся в отдельном текстовом файле, так что вы легко можете добавлять туда свои собственные. Для работы с базой сигнатур написана специальная программа PEiDSO. Разработчикам плагинов в комплекте прилагается SDK с примерами на разных языках программирования и описанием API. Скачать PEiD можно с офсайта, но в этом случае нужный набор плагинов и сигнатур вам придется собирать самим. Поэтому я выкладываю тут свою сборку, которой сам пользуюсь. На глобальность она не претендует, так что и критика тоже не принимается.
PEiD 0.95 с плагинами и сигнатурами (pass: manhunter.ru)
Detect it Easy (DiE), отечественная разработка, последняя версия 0.64 от мая 2007 года. Похожа на PEiD, но основной упор делается на собственные эвристические анализаторы, а уже потом на сигнатурный анализ. Также программа предоставляет некоторые полезные функции: просмотр импорта, секций, просмотр файла в hex-режиме, дизассемблер, просмотр основных характеристик PE, получение хеша MD5 и CRC-32. Функционал расширяется при помощи плагинов. Скачать DiE можно с офсайта.
Detect it Easy 0.65
ExeInfo PE также очень похожа на PEiD, последняя версия 0.0.3.3 от апреля 2013 года. Сигнатуры встроенные (470 штук) и не расширяются. В программе есть интересная функция: если протектор определен, то она дает информацию, при помощи какого инструмента его можно попытаться распаковать. Для новичков эта информация будет очень полезна. Также из полезных инструментов есть риппер архивов из SFX-модулей, поиск текстовых строк, обращений к реестру, корректировка OEP и другие. Скачать можно с офсайта. Также с офсайта можно скачать плагин-переходник для PEiD и DiE, который позволяет выполнять сканирование файлов через ExeInfo PE. Утилита вполне имеет место быть в списке рабочих инструментов.
ExeInfo PE 0.0.5.0
ExeScan 1.05.03.2004
Pe-Scan от snyper, последняя версия 3.31, офсайт прекратил свое существование. При минимальном размере программа обладает большими возможностями. Это эвристический и сигнатурный анализатор исполняемых файлов, распаковщик некоторых пакеров, динамический поиск OEP. Кроме перечисленных инструментов в Pe-Scan есть уникальный вероятностный анализатор для незнакомых упаковщиков и шифровщиков файлов (кнопка «adv.scan»). Он показывает в процентном отношении на какой из известных ему упаковщиков похож исследуемый неизвестный. Помогает определять обычные пакеры типа UPX, обработанные различными скрэмблерами и модификаторами.
PE-Scan 3.31
Stud_PE, последняя версия 2.4.0.1 от апреля 2008 года. Очень неплохая программа, кроме анализа чем упакован файл, показывает еще много другой полезной информации: секции, ресурсы, таблицы импорта и экспорта, DOS-заголовок. Встроеный в Stud_PE HEX-редактор подсвечивает выбранные поля заголовка файла, что бывает очень удобно при анализе его структуры. Также есть менеджер процессов со встроенным дампером. Функционал расширяется при помощи плагинов, причем подходят плагины от PEiD. Описание API и SDK для разработчиков прилагается в комплекте. Скачать Stud_PE можно с офсайта.
File Format Identifier 1.4
Protection ID, последняя версия 0.6.1.6 от января 2009 года. Неплохая программа, используемая в основном для анализа защищенных CD/DVD дисков. Кроме этого определяет около 350 упаковщиков, донглов, инсталляторов исполняемых файлов. Не требует для работы дополнительных файлов, но при этом нет возможности добавлять свои сигнатуры. В последних версиях замечена нехорошая тенденция автора заталкивать в утилиту кучу ненужного барахла, типа индикатора загрузки системы, менеджера процессов, оптимизатора памяти и прочих излишеств. Скачать можно с офсайта.
Protection ID 0.6.7.0
RDG Packer Detector, последняя версия 0.7.3 от 2014 года. Хорошая задумка, но чудовищная реализация, еще один пример разработчикам во что НЕ надо превращать свои программы. Если разберетесь в уродливом интерфейсе, то в придачу к анализатору получите еще несколько инструментов типа OEP Detector, Cryptographic Analyzer, которые у меня так нормально и не заработали. Скачать можно с офсайта, но больше для коллекции, постоянно использовать это убожество нереально.
FastScanner от крякерской команды AT4RE, последняя версия 3.0 beta от октября 2009 года. Сканер работает с сигнатурами от PEiD, поддерживает плагины. Красивый интерфейс, но результат проверки файлов часто бывает ошибочным. Из полезных функций есть неплохой редактор PE-файлов в виде плагина. Скачать можно с офсайта.
Bit Detector 2.8.5.6
MiTeC EXE Explorer 1.4
The Ultimate Hellspawn’s EXE Analyzer 0.6
file insPEctor XL
SCANiT 1.85b
PEPirate 0.51
gAPE 1.01
PeStudio 3.45
InspectExe добавляет в окно свойств исполняемых файлов дополнительные вкладки для просмотра секций, таблицы импорта, ресурсов, манифеста и других данных. Скачать можно с офсайта.
DNiD 1.0
A-Ray Scanner, проект давно не обновлялся, последняя версия 2.0.2.2 от 2005 года. Программа предназначена только для сканирования CD/DVD-дисков и определяет несколько десятков защит дисков от копирования. Также определяет некоторые упаковщики и протекторы исполняемых файлов.
A-Ray Scanner 2.0.2.2
ClonyXXL 2.0.1.5
Кроме универсальных анализаторов есть несколько утилит для определенных протекторов. Наиболее полезные из них ASPrINF, VerA, Armadillo Find Protected, Armadillo Informant и Detemida.
ASPrINF от nik0g0r из команды TLG, еще одна отечественная разработка, последняя версия 1.6 beta. Небольшая утилита для точного определения версии протектора ASProtect, которым накрыт файл. Используется динамический анализ, а не сигнатурный, поэтому версия определяется безошибочно. Кроме точной версии ASProtect утилита показывает информацию на кого зарегистрирован протектор, так что шароварщики, использующие для своих поделок ломаные варезные протекторы, могут быть легко выведены на чистую воду 🙂
ASPrINF 1.6 beta
VerA 2.0.3
Armadillo Find Protected от vel, последняя публичная версия 1.9. Эта утилита позволяет определить наличие в файле защиты Armadillo, узнать все опции, с которыми был установлен протектор, а также узнать версию самого протектора. Поддерживаются версии Armadillo до 6.40. Кроме анализа утилита позволяет подменять HWID для защищенных программ (версия 1.8), очищать триальные счетчики (версия 1.9) и делать detach дочернего процесса.
Armadillo Find Protected 1.8
Armadillo Find Protected 1.9
Armadillo Find Protected 2.0
Armadillo Find Protected 2.1
Armadillo Informant 0.9.6 beta
Detemida 1.0.0.5
RDG Themida-Winlicense Version Finder с традиционным для RDG чудо-интерфейсом также предназначена для определения версии Themida и WinLicense, однако делает это среди уже запущенных процессов. Может куда и сгодится.
RDG Themida-Winlicense Version Finder 1.0
EnigmaInfo 0.11
Если у вас есть еще интересные программы для анализа исполняемых файлов, то сообщите в комментариях. Самые полезные будут обязательно добавлены.
Распаковка исполняемых файлов
Привет, хабровчане. В рамках курса «Reverse-Engineering. Basic» Александр Колесников (специалист по комплексной защите объектов информатизации) подготовил авторскую статью.
Также приглашаем всех желающих на открытый вебинар по теме «Эксплуатация уязвимостей в драйвере. Часть 1». Участники вебинара вместе с экспертом разберут уязвимости переполнения в драйверах и особенности разработки эксплойтов в режиме ядра.
Статья расскажет о подходах к анализу запакованных исполняемых файлов с помощью простых средств для обратной разработки. Будут рассмотрены некоторые пакеры, которые применяются для упаковки исполняемых файлов. Все примеры будут проведены в ОС Windows, однако изучаемые подходы можно легко портировать на любую ОС.
Инструментарий и настройка ОС
Для тестов будем использовать виртуальную машину под управлением ОС Windows. Инструментарий будет содержать следующие приложения:
установленный по умолчанию плагин x64dbg Scylla;
Самый быстрый и простой способ провести распаковку любого исполняемого файла — применить отладчик. Но так как мы будем также рассматривать язык программирования Python, то может понадобится проект:
uncompile6 проект, который позволяет разобрать байткод виртуальной машины Python;
pyinstallerExtractor инструмент для распаковки архива pyInstaller.
Общие методы снятия паковки
Разберемся, что же такое паковка. В большинстве случаев исполняемые файлы современных языков программирования имеют довольно большой размер при минимальном наборе функций. Чтобы оптимизировать данную величину, можно применить паковку или сжатие. Наиболее распространенный на сегодняшний день пакер — UPX. Ниже приведен пример того, как пакер проводит сжатие исполняемого файла.
На картинке может показаться, что файл стал по размеру больше, однако это не всегда так. Большинство файлов за счет такой модификации могут уменьшить свой размер до 1.5 раз от исходного объема.
Что же от этого реверс-инженеру? Почему надо знать и уметь определять, что файл упакован? Приведу наглядный пример. Ниже приведен снимок файла, который не запакован:
И файл, который был пропущен через алгоритм UPX:
Изменения коснулись в этом случае двух основных точек исполняемого файла:
Точка входа — в случае с упакованным файлом это начало алгоритма распаковки, настоящий алгоритм программы будет работать только после того, как будет распакован оригинальный файл;
Код оригинального файла: теперь не найти паттернов, которые можно сразу разбирать как команды.
Итак, чтобы снова анализировать оригинальный файл, нужно найти настоящую или оригинальную точку входа. Для этого нужно разбить алгоритм на основные этапы:
Этап подготовки исполнения файла — загрузчик ОС настраивает окружение, загружает файл в оперативную память;
Сохранение контекста — упаковщик сохраняет контекст исполнения файла (набор значений регистров общего назначения, которые были установлены загрузчиком ОС);
Распаковка оригинального файла;
Передача управления оригинальному файлу.
Пример UPX
Попробуем с помощью отладчика найти оригинальную точку входа для приложения. Запечатлим оригинальную точку входа до упаковки UPX:
Как та же точка входа выглядит после упаковки:
Запустим отладчик и попробуем найти место сохранения контекста:
Ждем первого использования ESP — в отладчике при этом значение регистра подсветится красным цветом. Затем устанавливаем точку останова на адрес и просто запускаем приложение:
В результате попадаем на оригинальную точку входа:
Вот так просто, теперь используя плагин Scylla Hide можно сохранить результирующий файл на жесткий диск и продолжить его анализ.
Подобный метод можно применять для любого упаковщика, который сохраняет контекст на стек.
Пример PyInstaller
Не всегда подобный подход работает для приложений, которые используют более сложную структуру исполняемого файла. Рассмотрим файл, который был создан с помощью PyInstaller — пакет, который позволяет преобразовать Python скрипт в исполняемый файл. При генерации исполняемого файла создается архив, который содержит виртуальную машину Python и все необходимые библиотеки. Сам исходный код приложения при этом преобразуется в байт код и его нельзя дезассемблировать.
Попробуем все же получить что-то читаемое. Создадим простое приложение на Python и упакуем с помощью PyInstaller. Исходный код приложения:
Установим пакет pyInstaller и создадим exe файл:
Итак, проведем сбор информации о том, что в итоге получилось. У нас есть архив, который должен запустить виртуальную машину, и код, который мы записали в виде скрипта. Попробуем восстановить исходник и просто его прочесть даже без запуска.
Таким образом можно снова получить исходный код.
Смотреть открытый вебинар по теме «Эксплуатация уязвимостей в драйвере. Часть 1».