Что такое упаковщики exe и com файлов

Обновлено: 15.01.2025

Рекомендации по использованию этого средства для UWP см. в статье Создание пакета приложения с помощью средства MakeAppx.exe.

Упаковщик приложений (MakeAppx.exe) создает пакет приложения из файлов на диске или извлекает файлы из пакета приложения на диск. Начиная с Windows 8.1, упаковщик приложений также создает набор пакетов приложений из пакетов приложений на диске или извлекает пакеты приложений из пакета приложений на диск. Он включен в Microsoft Visual Studio и пакет средств разработки программного обеспечения Windows (SDK) для Windows 8 или пакета средств разработки программного обеспечения Windows (SDK) для Windows 8.1. Посетите страницу downloads для разработчиков , чтобы получить их.

Средство MakeAppx.exe обычно находится в следующих расположениях:

На x86: C: \ Program Files (x86) \ Windows Kit \ 8,0 \ bin \ x86 \makeappx.exe или C: \ Program files (x86) \ Windows Kit \ 8,1 \ bin \ x86 \makeappx.exe
На x64 в двух местах:
- C: \ Program Files (x86) \ Windows Kit \ 8,0 \ bin \ x86 \makeappx.exe или C: \ Program files (x86) \ Windows Kits \ 8,1 \ bin \ x86 \makeappx.exe
- C: \ Program Files (x86) \ Windows Kit \ 8,0 \ bin \ x64 \makeappx.exe или C: \ Program files (x86) \ Windows Kits \ 8,1 \ bin \ x64 \makeappx.exe
Версия ARM средства отсутствует.

Использование упаковщика приложений

Относительные пути поддерживаются во всем средстве.

Создание пакета с помощью структуры каталогов

Поместите AppxManifest.xml в корневой каталог каталога, содержащего все полезные файлы приложения. Для пакета приложения создается идентичная структура каталога, которая будет доступна при извлечении пакета во время развертывания.

Разместите все файлы в одной структуре каталогов, создавая нужные подкаталоги.

Создайте допустимый манифест пакета, AppxManifest.xml и поместите его в корневой каталог.

Выполните следующую команду:

Создание пакета с помощью файла сопоставления

Создайте допустимый манифест пакета, AppxManifest.xml.

Создайте файл сопоставления. В первой строке содержатся [ файлы ] строк, а в строках, следующих за ними, указываются пути к источнику (диску) и месту назначения (пакетов) в строках в кавычках.

Выполните следующую команду:

Программе makeappx Pack/f сопоставление _ FilePath /p FilePath. appx

Подпись пакета с помощью средства SignTool

Создайте сертификат. Издатель, указанный в манифесте, должен соответствовать сведениям о субъекте издателя сертификата подписи. Дополнительные сведения о создании сертификата для подписи см. в разделе Создание сертификата для подписи пакета приложения.

Запустите SignTool.exe, чтобы подписать пакет:

Подписывание SignTool/a/v/FD hashAlgorithm /f цертфиленаме FilePath. appx

HashAlgorithm должен соответствовать хэш-алгоритму, используемому для создания блоккмап при упаковке приложения. С помощью служебной программы упаковки программе makeappx по умолчанию алгоритм хеширования appx блоккмап имеет значение SHA256. Запустите SignTool.exe указав SHA256 в качестве алгоритма файлового дайджеста (/FD):

Подписывание SignTool/a/v/FD SHA256/F цертфиленаме FilePath. appx

Извлечение файлов из пакета

Выполните следующую команду:

Программе makeappx распаковки, параметр/p File. appx/d выходной _ Каталог

Распакованный пакет имеет ту же структуру, что и установленный пакет.

Создание пакета пакетов с помощью структуры каталогов

Мы используем команду пакета для создания пакета приложений в путем добавления всех пакетов (включая вложенные папки). Если содержит манифест пакета, AppxBundleManifest.xml, он игнорируется.

Разместите все пакеты в одной структуре каталогов, создавая нужные подкаталоги.

Выполните следующую команду:

Создание пакета пакетов с помощью файла сопоставления

Мы используем команду пакета для создания пакета приложений в путем добавления всех пакетов из списка пакетов в . Если содержит манифест пакета, AppxBundleManifest.xml, он игнорируется.

Создайте таблицу . Первая строка содержит [ файлы ] строк, а следующие строки указывают пакеты для добавления в пакет. Каждый пакет описывается парой путей в кавычках, разделенных пробелами или символами табуляции. Пара путей представляет источник пакета (на диске) и назначение (в пакете). Все имена целевых пакетов должны иметь расширение Appx.

Выполните следующую команду:

Программе makeappx пакет/f сопоставление _ FilePath /p FilePath. appxbundle

Извлечение пакетов из пакета

Выполните следующую команду:

Программе makeappx unbundle/p _ имя пакета. appxbundle/d выходной _ Каталог

Распакованный пакет имеет ту же структуру, что и установленный пакет пакетов.

Шифрование пакета с помощью файла ключа

Создайте файл ключа. Файлы ключей должны начинаться со строки "Keys", содержащей строку " [ ключи ] ", за которой следуют строки, описывающие ключи для шифрования пакета. Каждый ключ описывается парой строк в кавычках, разделенных пробелами или символами табуляции. Первая строка представляет идентификатор ключа, а вторая — ключ шифрования в шестнадцатеричном формате.

Выполните следующую команду:

MakeAppx.exe Encrypt/p _ имя пакета. appx/EP имя зашифрованного _ _ пакета. еаппкс/КФ keyfile _ Name. txt

Шифрование пакета с помощью глобального тестового ключа

Выполните следующую команду:

MakeAppx.exe Encrypt/p _ имя пакета. appx/EP _ _ имя зашифрованного пакета. еаппкс/КТ

Расшифровка пакета с помощью файла ключа

Создайте файл ключа. Файлы ключей должны начинаться со строки "Keys", содержащей строку " [ ключи ] ", за которой следуют строки, описывающие ключи для шифрования пакета. Каждый ключ описывается парой строк в кавычках, разделенных пробелами или символами табуляции. Первая строка представляет идентификатор ключа в кодировке Base64 (32-байт), а вторая строка представляет ключ шифрования 32-байт в кодировке Base64.

Выполните следующую команду:

MakeAppx.exe расшифровка/p _ имя пакета. appx/EP незашифрованное _ _ имя пакета. еаппкс/КФ keyfile _ Name. txt

Расшифровка пакета с помощью глобального тестового ключа

Выполните следующую команду:

MakeAppx.exe расшифровка/p _ имя пакета. appx/EP незашифрованное _ _ имя пакета. еаппкс/КТ

Использование

Аргумент командной строки /p всегда является обязательным и имеет значение /d, /f или /EP. Обратите внимание, что /d, /f и /EP являются взаимоисключающими.

[ Параметры ] пакета программе makeappx /p <output package name> /d*<content directory>*

[ Параметры ] пакета программе makeappx /p <output package name> /f*<mapping file>*

Программе makeappx распаковки [ параметров ] /p <input package name> /d*<output directory>*

[ Параметры ] пакета программе makeappx /p <output bundle name> /d*<content directory>*

[ Параметры ] пакета программе makeappx /p <output bundle name> /f*<mapping file>*

Программе makeappx [ Параметры ] разпакета /p <input bundle name> /d*<output directory>*

[ Параметры ] шифрования программе makeappx /p <input package name> /EP*<output package name>*

[ Параметры ] расшифровки программе makeappx /p <input package name> /EP*<output package name>*

Синтаксис для командной строки

Ниже приведен пример общего синтаксиса использования для программе makeappx в командной строке.

Программе makeappx [ пакет распаковки | | | unpackть | Encrypt | ] [ /h /КФ /КТ /l /o /но /НВ /v /ПФН /?]

Программе makeappx пакеты или распаковать файлы в пакете, упаковывает или раз пакеты в пакете, либо шифрует или расшифровывает пакет приложения или набор в указанном входном каталоге или файле сопоставления. Ниже приведен список параметров, которые применяются к пакету программе makeappx, программе makeappx распаковки, пакету программе makeappx, программе makeappx unpack, программе makeappx Encrypt или программе makeappx дешифровки.

/l

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

/o

Перезапишите выходной файл, если он существует. Если вы не укажете этот параметр или параметр /но , пользователь получит запрос на перезапись файла.

Этот параметр нельзя использовать с /но.

/но

Предотвращает перезапись выходного файла, если он существует. Если не указать этот параметр или параметр /o , пользователь получит запрос на перезапись файла.

Этот параметр нельзя использовать с /o.

/нв

Пропустить семантическую проверку. Если не указать этот параметр, средство выполняет полную проверку пакета.

/v

Включите подробный вывод журнала в консоль.

Отображение текста справки.

Программе makeappx Pack , программе makeappx, распаковка , программе makeappx, программе makeappx unpack, программе makeappx Encrypt и программе makeappx дешифровки являются взаимоисключающими командами. Ниже приведены параметры командной строки, которые применяются специально для каждой команды:

Пакет программе makeappx [ з]

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

SHA256 (по умолчанию) SHA384 SHA512

Этот параметр нельзя использовать с командой unpack .

Программе makeappx распаковать [ PFN]

Извлекает все файлы в указанном пакете в указанный выходной каталог. Выходные данные имеют ту же структуру каталогов, что и пакет.

/пфн

Указывает каталог с именем с полным именем пакета. Этот каталог создается в указанном расположении выходных данных. Этот параметр нельзя использовать с командой Pack .

Программе makeappx распакетировать [ PFN]

Распаковать все пакеты в подкаталог с указанным выходным путем, названный после полного имени пакета. Выходные данные имеют ту же структуру каталогов, что и установленный пакет пакетов.

/пфн

Указывает каталог с именем с полным именем пакета пакетов. Этот каталог создается в указанном расположении выходных данных. Этот параметр нельзя использовать с командой пакета .

Программе makeappx шифрование [ КФ, kt]

Создает зашифрованный пакет приложения из указанного входного пакета приложения в указанном выходном пакете.

/КФ**

Шифрует пакет или набор с помощью ключа из указанного файла ключей. Этот параметр нельзя использовать с kt.

/кт

Шифрует пакет или набор с помощью глобального тестового ключа. Этот параметр нельзя использовать с КФ.

Программе makeappx расшифровку [ КФ, kt]

Создает незашифрованный пакет приложения из указанного входного пакета приложения в указанном выходном пакете.

/КФ**

Расшифровывает пакет или набор с помощью ключа из указанного файла ключей. Этот параметр нельзя использовать с kt.

/кт

Расшифровывает пакет или набор с помощью глобального тестового ключа. Этот параметр нельзя использовать с КФ.

Семантическая проверка, выполняемая программе makeappx

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

Эта проверка гарантирует следующее:
- все файлы, ссылки на которые присутствуют в манифесте пакета, входят в состав пакета приложения;
- в приложении нет двух идентичных ключей;
- Приложение не регистрируется для запрещенного протокола из этого списка: SMB, FILE, MS-ВВА-WEB, MS-ВВА.
Эта семантическая проверка не завершена, и пакеты, созданные программе makeappx, не гарантированно будут устанавливаться.

Программы-упаковщики - это разновидность архиваторов, которые сжимают исполняемые файлы (.exe), динамически подсоединяемые библиотеки (.dll) и др. с сохранением их полной работоспособности в упакованном состоянии. Другими словами, если вы запакуете "экзешник", то он уменьшится в размере и, что немаловажно, не перестанет быть "экзешником". Т.е. его можно будет запускать на выполнение, как если бы он вообще не подвергался действиям подобных утилит.

Упаковщики работают так же, как и архиваторы, за одним лишь исключением - они помещают процедуру распаковки (decompression procedure) в начало программы, которую только что сжали.

Обычно упакованная программа загружается быстрее, чем неупакованная, что объясняется уменьшением ее размера. Однако многие алгоритмы декомпрессии требуют немало оперативной памяти. Если ее в системе не хватает, то запускаемая программа может быть помещена в файл подкачки. В этом случае сжатое приложение будет открываться дольше.

Где находят применение упаковщики, или, как их часто называют, пакеры? Конечно, их используют программисты, чтобы уменьшить размер написанных файлов, ускорить их запуск и защитить от взлома. Но и крекеры (взломщики) не обходят эти программы стороной, создавая декомпрессоры для популярных упаковщиков и внося, таким образом, свою лепту в развитие технологий защиты данных. :) Что касается обычных пользователей, то упаковщик всегда поможет переслать исполняемый файл по почте, разместить в интернете или записать на информационный носитель небольшой емкости, например, дискету. Процедура распаковки занимает считанные байты, поэтому упакованные exe-файлы имеют почти такой же размер, что и заархивированные, однако, как вы понимаете, не требуют для запуска дополнительного ПО, что тоже удобно.

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

PECompact v2.76

Размер: 1,3 Mb

Распространение: shareware (14 дней опробования)

Утилита PECompact предназначена для сжатия файлов .exe, .dll, .scr с помощью многочисленных алгоритмов, которые доступны в меню Файл -> Изменить установки. -> Выбрать кодеки. В программе предусмотрена возможность выбора компонентов файлов, которых не следует подвергать компрессии (иконки, курсоры, шрифты и др.), а также функция оптимизации структуры файла, которая позволит без сжатия уменьшить его размер (опция "Trim Only"). Кроме того, PECompact имеет русскоязычный интерфейс и консольную версию - pec2.exe. Также позволяет работать с несколькими файлами сразу.

ASPack v2.12

Размер: 300 Kb

Распространение: shareware (30 дней опробования)

Упаковщик ASPack прост в использовании и, благодаря мощному алгоритму, позволяет добиться 40-70% сжатия для 32-битных приложений Windows. Поддерживаемые файлы: .exe, .dll, .ocx, .dpl, .bpl (файлы библиотек Delphi). Программа может проверить перед окончательной упаковкой функциональность exe-файла и, при нарушении его нормальной работы, отменить сжатие. Для любознательных: ASPack был написан в Borland Delphi 2.0. Русский язык поддерживается.

UpxVis v1.8

Размер: 350 Kb

Распространение: freeware

UPX (the Ultimate Packer for eXecutables) - быстрый упаковщик, работающий в консольном режиме и позволяющий достичь высоких коэффициентов сжатия. Также может выполнять декомпрессию. Поддерживаемые форматы файлов: exe, sys, com, pe (Win32), 386 (Linux) и др. Для UPX написано множество оболочек, значительно повышающих удобство работы с утилитой. Одной из них является UpxVis v1.8. В отличие от классического UPX, программа позволяет устанавливать защиту от декомпрессии и умеет упаковывать dll. Русский язык присутствует.

Подготовка к тестированию

Для качественного сравнения работы программ-упаковщиков были выбраны (случайным образом) исполняемые файлы (.exe) и динамически подсоединяемые библиотеки (.dll) известных приложений, а также мои программы, написанные в Delphi и Visual C++. Сравнение будет проходить по следующим критериям: размер упакованного файла, время компрессии и время декомпрессии, работоспособность файла после сжатия.

Во время тестирования преследуется цель максимально уменьшить размер выходного файла без увеличения времени его распаковки. Для этого в PECompact был выбран алгоритм FFCE, обеспечивающий хорошее сжатие и малое время запуска упакованного файла и установлен максимальный уровень сжатия (9). Остальные настройки - по умолчанию. В настройках ASPack были включены пункты "Сжимать ресурсы" и "Максимальное сжатие", а в UpxVis вместе с упаковкой ресурсов была установлена максимальная степень компрессии (10). Помните, что в ASPack и PECompact параметры упаковки нужно задавать для каждого файла в отдельности

Результаты

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

Упаковщики также были опробованы и на обычных установочных файлах, которые каждый из нас запускает по несколько штук в день. В основном, попадались "экзешники", содержащие экстра данные с жестко заданным смещением (оверлей). UPX с такими файлами работать отказался, а для остальных упаковщиков в настройках опять была включена опция "Сохранять оверлей". PECompact с компрессией справился нормально: программы загружались, но степень сжатия была незначительная. ASPack, напротив, только угробил "экзешники". Вывод: инсталляционные файлы программ упаковывать нет смысла, т.к. они, во-первых, плохо поддаются упаковке и, во-вторых, уже сжаты разработчиками.

Выводы

Упаковщик UPX с оболочкой UpxVis показал наилучшее сжатие исполняемых файлов (.exe). Учитывая то, что программа распространяется бесплатно, можно сказать, что для упаковки "экзешников" целесообразнее применять именно ее. Если UPX что-то не сможет сделать хорошо, то он вам об этом непременно сообщит. Для сжатия dll и файлов с оверлеем (не установочных!) лучше использовать ASPack, т.к. он работает надежнее и быстрее. Я, скорее всего, выберу именно его. А PECompact подкупает лишь возможностью выбора кодеков, с которыми можно поэкспериментировать на досуге. Он сжимает почти так же, как и ASPack, только иногда тратит на это больше времени.

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

Сага о протекторах и упаковщиках

Один из излюбленных приемов зловредописателей — использование упаковщиков (packers) и протекторов (protectors) исполняемых файлов (хотя это также относится и к DLL). Изначально эти инструменты считались весьма банальными и были призваны, по сути, уменьшать размер скомпилированного файла, а в случае протекторов — позволять модифицировать авторам свои программы, превращая их, к примеру, в demo- или trial-версию, и не заморачиваться с защитой в основном коде. Но позднее вирусописатели приспособили эти инструменты в корыстных целях.

Создатели вредоносов успешно стали применять их, чтобы усложнить антивирусный и эвристический анализ, защитить свои детища от запуска в виртуальной среде, отладки, дизассемблирования и последующего анализа. Поэтому с тех пор навыки и умения распаковывать исполняемые файлы вошли в обязательные требования как для начинающего, так и для опытного реверс-инженера. Наиболее популярные сегодня упаковщики — UPX, ASPack, FSG, PeShield, VMProtect. Это, так сказать, джентльменский набор, с которым аналитику приходится сталкиваться каждый день.

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

Как мы понимаем, чтобы добраться до нужного нам кода, который мы будем анализировать, сначала требуется распаковать файл, то есть снять все навесные защиты, восстановить оригинальную OEP и таблицу импорта, это как минимум. Частенько распаковка — это задача, укладывающаяся в стандартный набор действий, но иногда она становится творческой и выливается в целое хакерское исследование — с ящиками пива, блоками сигарет и сантиметрами сожженных нервных волокон :).

Ликбез по теории

Итак, как мы понимаем, использование упаковщиков/протекторов/крипторов значительно усложняет реверсинг. Помимо этого, писатели зловредов могут использовать многократную упаковку (так называемый послойный пак), применять малоизвестные или вовсе самописные тулзы (для тех, кто хочет накодить что-то свое, небольшой ликбез), сигнатуры которых будут отсутствовать, к примеру, в том же PEiD. Интересно, что любой пакер, не созданный специально для шифрования малвари, оставляет свою уникальную сигнатуру в бинарнике, а соответственно, умея пользоваться Hex-редакторами, можно определить его сигнатуру и без PE-анализатора.

Общий принцип рассматриваемых инструментов упаковки/защиты таков: после клика на EXE-файле и его запуска выполнение основного кода программы начинается с так называемой точки входа (Entry Point) — адреса, по которому передается управление после загрузки программы в оперативную память. Когда программа запакована, алгоритм работы несколько изменится. Упаковщик запоминает точку входа EP, потом, используя алгоритмы архивирования, сжимает содержимое файла (как правило, это секция кода и данных), после чего дописывает свою сигнатуру после либо до сжатого кода программы и перенаправляет ее не в основной код программы, а в код упаковщика (точнее сказать — распаковщика). Сам же код распаковщика, находящийся теперь внутри файла, получает управление первым и распаковывает упакованные секции кода/данных в памяти! На диске исходный файл остается нетронутым, то есть упакованным, неизменным. После того как код и данные программы распакованы, код распаковщика восстанавливает таблицу импорта и передает управление основному коду программы, на бывшую точку входа, которая в упакованных программах называется оригинальной точкой входа (Original Entry Point). Если кратко, то это все основные моменты.

Схема упаковки исполняемого файла

Сжатие данных (упаковка) основывается на свойстве энтропии информации, а алгоритмы по своей сути очень схожи с теми, что применяются в архиваторах, только в отличие от первых упаковщики для исполняемых файлов распаковывают данные в оперативную память.

Протекторы, как и некоторые упаковщики, используют ряд приемов борьбы с динамической распаковкой, например расшифровывают код не полностью, а лишь по мере исполнения или создают образ и распаковывают его в память только на момент запуска. Протекторы, используя 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. Нам обязательно понадобятся:
- OllyExt — содержит опции Anti-AntiDebug;
- OllyDumpEx — отличный дампер процессов;
- swordfish — быстрая установка точек останова;
- uberstealth — фича Anti-AntiDebug, основанная на коде IDA Stealth.
Все самые нужные плагины 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 (точках останова)

Точки останова — часто используемый и незаменимый прием любого реверс-аналитика. Основные режимы — это:
- останов при чтении;
- останов при записи;
- выполнение памяти по заданному адресу.
Команда CALL $+5 POP REG характерна для защитных механизмов, к примеру копирующих себя на стек. А часто возникающая инструкция PUSHFD присутствует в самотрассирующихся программах и антиотладочных защитных механизмах.

Содержание

Упаковщик исполнимых файлов

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

Упакованный исполнимый файл является разновидностью самораспаковывающегося архива (SFX), в котором сжимаемая информация и программа для распаковки находится в одном файле.

Примеры упаковщиков

Распаковщики

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

Многие распаковщики (например, procdump или PEiD) запускают файл и создают распакованный вариант файла из образа, загруженного в память. Однако в случае, если этот файл содержал вирус, система может быть повреждена. Кроме того, у упаковщиков существует ряд приёмов борьбы с динамической распаковкой: например, расшифровывать код не полностью, а лишь по мере исполнения, или, например, расшифровывать и запускать вирус целиком только в определённый день недели.

См. также

Ссылки

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое "Упаковка исполняемых файлов" в других словарях:

PECompact — Скри … Википедия

The Ultimate Packer for eXecutables — UPX the Ultimate Packer for eXecutables Тип Упаковка исполняемых файлов Написана на C++, Ассемблер ОС Microsoft Windows, DOS, 27 апреля 2008 Лицензия GNU GPL Сайт … Википедия

Mpress — Тип Упаковка исполняемых файлов Разработчик Matcode Software Операционная система Microsoft Windows, Mac OS Последняя версия 2.18 Лицензия Freeware Сайт … Википедия

UPX — the Ultimate Packer for eXecutables Тип Упаковка исполняемых файлов Написана на C++, Ассемблер Операционная система Microsoft Windows, Linux, MacOS, DOS, Atari Первый выпуск 26 мая 1998 год … Википедия

APLib — Тип Упаковка исполняемых файлов Разработчик Joergen Ibsen Написана на С Операционная система Microsoft Windows Языки интерфейса Английский Последняя версия 1.01 ( … Википедия

JCALG1 — Тип Упаковка исполняемых файлов Разработчик Bitsum Technologies Jeremy Collake Написана на Ассемблер Операционная система Microsoft Windows Языки интерфейса Английский … Википедия

ASPack — Вид главного окна Тип Упаковка исполняемых файлов Разработчик Алексей Солодовников (ASPack Software) … Википедия

EXPressor — Тип Упаковка исполняемых файлов Разработчик CGSoftLabs Написана на … Википедия

Исполняемые сжатия любые средства сжатия в исполняемый файл и объединения сжатых данных с декомпрессионной кода в единый исполняемый файл. Когда этот сжатый исполняемый файл выполняется, код распаковки воссоздает исходный код из сжатого кода перед его выполнением. В большинстве случаев это происходит прозрачно, поэтому сжатый исполняемый файл может использоваться точно так же, как оригинал. Исполняемые компрессоры часто называют «упаковщиками времени выполнения», «упаковщиками программного обеспечения», «средствами защиты программного обеспечения» (или даже « полиморфными упаковщиками » и « средствами запутывания »).

Сжатый исполняемый файл можно рассматривать как самораспаковывающийся архив , в котором сжатый исполняемый файл упаковывается вместе с соответствующим кодом распаковки в исполняемый файл. Некоторые сжатые исполняемые файлы можно распаковать для восстановления исходного файла программы без непосредственного выполнения. Для этого можно использовать две программы: CUP386 и UNP.

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

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

Содержание

Преимущества и недостатки

Дистрибьюторы программного обеспечения используют сжатие исполняемых файлов по разным причинам, в первую очередь для уменьшения требований к вторичному хранилищу своего программного обеспечения; поскольку исполняемые компрессоры специально разработаны для сжатия исполняемого кода, они часто обеспечивают лучшую степень сжатия, чем стандартные средства сжатия данных, такие как gzip , zip или bzip2 . Это позволяет дистрибьюторам программного обеспечения не выходить за рамки выбранных ими средств распространения (таких как CD-ROM , DVD-ROM или гибкий диск ) или сокращать время и полосу пропускания, необходимые клиентам для доступа к программному обеспечению, распространяемому через Интернет .

Сжатие исполняемых файлов также часто используется для предотвращения обратного проектирования или для обфускации содержимого исполняемого файла (например, чтобы скрыть присутствие вредоносных программ от антивирусных сканеров ) с помощью специальных методов сжатия и / или дополнительного шифрования . Исполняемое сжатие может использоваться для предотвращения прямой разборки , маскирования строковых литералов и изменения подписей. Хотя это не исключает возможности обратного проектирования, это может сделать процесс более дорогостоящим.

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

В операционных системах, которые читают исполняемые образы по запросу с диска (см. Виртуальную память ), сжатые исполняемые файлы делают этот процесс менее эффективным. Заглушка декомпрессора выделяет блок памяти для хранения распакованных данных, который остается выделенным, пока исполняемый файл остается загруженным, независимо от того, используется он или нет, все время конкурируя за ресурсы памяти с другими приложениями. Если операционная система использует файл подкачки, распакованные данные должны быть записаны в него, чтобы освободить память, вместо того, чтобы просто отбрасывать неиспользуемые блоки данных и при необходимости повторно загружать их из исполняемого образа. Обычно это незаметно, но становится проблемой, когда исполняемый файл загружается более одного раза одновременно - операционная система не может повторно использовать блоки данных, которые она уже загрузила, данные должны быть распакованы в новый блок памяти и будут заменяться самостоятельно, если не используется. Дополнительные требования к хранилищу и времени означают, что необходимо тщательно взвесить, следует ли сжимать исполняемые файлы, которые обычно запускаются более одного раза одновременно.

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

Кроме того, некоторые старые антивирусные сканеры просто сообщают обо всех сжатых исполняемых файлах как о вирусах, потому что заглушки декомпрессора имеют с ними общие характеристики. Большинство современных антивирусных сканеров могут распаковывать несколько различных исполняемых уровней сжатия для проверки фактического исполняемого файла внутри, но некоторые популярные антивирусные и антивирусные сканеры имеют проблемы с ложными срабатываниями тревожных сигналов для сжатых исполняемых файлов. В попытке решить проблему вредоносного обфусцированную с помощью упаковщики IEEE Industry Connections Security Group представила программную метку , систему.

Сжатие исполняемых файлов было более популярным, когда объем памяти компьютеров ограничивался дискетами , которые были как медленными, так и носителями малой емкости, а также маленькими жесткими дисками ; это позволяло компьютеру хранить больше программного обеспечения в том же объеме пространства без неудобств, связанных с необходимостью вручную распаковывать архивный файл каждый раз, когда пользователь хотел использовать программное обеспечение. Однако сжатие исполняемых файлов стало менее популярным из-за увеличения емкости хранилища на компьютерах. Он используется в демосцене, где демоверсии должны оставаться в пределах размера, например 64 килобайта, для участия в некоторых соревнованиях. Только очень сложные форматы сжатия, увеличивающие время загрузки, позволяют сохранять исполняемый файл достаточно маленьким, чтобы участвовать в этих соревнованиях.

Список исполняемых упаковщиков

Исполняемый файл CP / M и MSX-DOS

Исполняемый файл DOS

Исполняемый файл OS / 2

Известные компрессоры исполняемых файлов под OS / 2 :

Новый исполняемый файл

Известные компрессоры исполняемых файлов для новых исполняемых файлов :
- PackWin
- PKWare PKLite (с версии 2.01)
- WinLite
Переносимый исполняемый файл

Известные компрессоры исполняемых файлов для переносимых исполняемых файлов :

Примечание: клиенты, отмеченные фиолетовым цветом, больше не находятся в разработке.

Файлы ELF

Известные исполняемые компрессоры для файлов ELF :
- gzexe (использует заглушку сценария оболочки и gzip , работает в большинстве Unix-подобных систем)
- Конверт HASP
- 624 (для Linux / 386)
Файлы сборки CLI

Известные исполняемые компрессоры для файлов сборки CLI :

Файлы приложения Mac OS Classic

Известные исполняемые компрессоры для файлов приложений Mac OS Classic :
- Приложение VISE
- StuffIt InstallerMaker
Файлы Mach-O (Apple Mac OS X)

Известные исполняемые компрессоры для файлов Mach-O (Apple Mac OS X):

Commodore 64 и VIC 20

Известные компрессоры исполняемых файлов для исполняемых файлов на Commodore 64 и VIC 20 :
- PuCrunch
- Exomizer
- ByteBoozer
Коммодор Амига

Известные компрессоры исполняемых файлов для исполняемых файлов серии Commodore Amiga :
- powerpacker
- Титаникс кранчер
- взрыватель
- TNM cruncher
- Термоусадочная машина
- PackFire
Известные исполняемые компрессоры для Java :

Скрипты JavaScript

К скриптам JavaScript можно применить два типа сжатия :
- Уменьшите избыточность в скрипте (удалив комментарии, пробелы и сократите имена переменных и функций). Это не меняет поведения сценария.
- Сожмите исходный сценарий и создайте новый сценарий, содержащий код распаковки и сжатые данные. Это похоже на сжатие двоичных исполняемых файлов.
Компрессоры с самораспакованием

Они сжимают исходный сценарий и выводят новый сценарий с декомпрессором и сжатыми данными.

Компрессоры с уменьшением избыточности

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

Читайте также: