Программы для упаковки файлов в exe
Сегодня мы поговорим о разработке своего собственного упаковщика исполняемых файлов под Windows на С++.
Давным-давном, когда Windows XP еще не было, в поисках информации о пакерах мы забирались в самые дебри исходников тогда еще молодого UPX. Но то ли ацетилхолина у нас в мозгах синтезировалось меньше нужного, то ли UPX уже тогда был очень занудным — в общем, мы почти ничего из тех сорцов не извлекли. Мэтт Питрек, и тот помог больше. Сейчас с инфой значительно проще стало. Почти всё есть. Даже сорцы вполне себе нормального банковского троя можно скачать (Zeus 2.0.8.9). Да чего уж там, сорцы винды уже давно в паблике (Windows 2000).
Об упаковщиках информация тоже есть, но в основном исследовательская, непосредственно разработки касающаяся не с той стороны, с которой нам бы хотелось. Отличным примером тому является статья «Об упаковщиках в последний раз» в двух частях, написанная небезызвестными гуру Volodya и NEOx.
Мы, в свою очередь, постараемся максимально конкретно и последовательно дать информацию именно о разработке простейшего, но легко модифицируемого под любые свои нужды PE-пакера.
Алгоритм
- считать PE-файл в массив;
- сжать массив каким-нибудь алгоритмом сжатия без потерь;
- в соответствии с форматом PE дописать сжатый массив к шаблону-загрузчику.
- найти в конце себя массив со сжатым PE-файлом;
- разжать его;
- распарсить заголовки PE-файла, расставить все права, выделить память и в итоге запустить.
Загрузчик
Итак, первое, что должен сделать наш загрузчик, — это найти в своем теле адрес массива со сжатым образом PE-файла. Способы поиска зависят от того, как упаковщик имплантировал этот массив в загрузчик.
Например, если бы он просто добавил новую секцию с данными, то поиск выглядел бы так:
Поиск сжатого образа в последней секции
Но, на наш взгляд, этим кодом в загрузчике можно пожертвовать. Вообще, всё, что может сделать упаковщик, пусть он и только он и делает. Адрес образа в адресном пространстве загрузчика можно вычислить заранее, при упаковке, а потом просто вписать в нужное место. Для этого оставляем в нашей программе две метки:
Когда упаковщик будет имплантировать в загрузчик массив со сжатым образом, он пройдется сигнатурным поиском по телу загрузчика и заменит 0xDEADBEEF на адрес массива, а 0xBEEFCACE — на его размер.
Теперь, когда мы определились, как искать адрес, можно выбрать готовую реализацию алгоритма сжатия для использования в нашем упаковщике.
Неплохой вариант — использовать aplib, маленькую библиотеку с аккуратным и очень компактным кодом, реализующую сжатие на базе алгоритма Лемпеля-Зива (LZ). И мы обязательно его выбрали бы в любой другой день, однако сегодня у нас настроение для еще более простого и компактного решения — встроенных в Windows функций!
Начиная с XP, наша любимая ntdll.dll начала экспортировать две прекрасные функции:
Названия их говорят сами за себя — одна функция для компрессии, другая для декомпрессии. Конечно, если бы мы разрабатывали действительно серьезный продукт, мы бы эти функции не трогали, ведь остались еще компьютеры и с Windows 2000, и даже с NT 4.0, ;) но для наших скромных целей RtlCompressBuffer\RtlDecompressBuffer вполне подойдут.
В хедерах Platform SDK этих функций нет, статически мы их прилинковать не сможем, поэтому придется воспользоваться GetProcAddress:
Определение адреса функции для распаковки
Когда есть чем распаковать и есть что распаковать, можно уже, наконец, это сделать. Для этого мы выделим память с запасом (так как не знаем объем распакованного файла) и запустим определенную выше функцию:
- Разместить начало образа (хедеры) по адресу, указанному в поле Image Base опционального заголовка (OPTIONAL_HEADER).
- Разместить секции PE-файла по адресам, указанным в таблице секций.
- Распарсить таблицу импорта, найти все адреса функций и вписать в соответствующие им ячейки.
Она принимает указатель на наш распакованный образ и возвращает дескриптор загруженного модуля (эквивалент адреса, по которому загружен PE-файл) и адрес точки входа (по указателю AddressOfEntryPoint). Эта функция делает всё, чтобы правильно разместить образ в памяти, но не всё, чтобы можно было, наконец, передать туда управление.
Дело в том, что система по-прежнему ничего не знает о загруженном нами модуле. Если мы прямо сейчас вызовем точку входа, с которой сжатая программа начнет выполнение, то может возникнуть ряд проблем. Работать программа будет, но криво.
Например, GetModuleHandle(NULL) будет возвращать Image Base модуля загрузчика, а не распакованной программы. Функции FindResource и LoadResource будут рыться в нашем загрузчике, в котором никаких ресурсов нет и в помине. Могут быть и более специфические глюки. Чтобы всего этого не происходило, нужно в системных структурах процесса по возможности везде обновить информацию, заменив адреса модуля загрузчика на адреса загруженного модуля.
В первую очередь нужно пофиксить PEB (Process Enviroment Block), в котором указан старый Image Base. Адрес PEB очень легко получить, в юзермоде он всегда лежит по смещению 0x30 в сегменте FS.
- InLoadOrderModuleList — cписок модулей в порядке загрузки;
- InMemoryOrderModuleList — cписок модулей в порядке расположения в памяти;
- InInitializationOrderModuleList — cписок модулей в порядке инициализации.
Вот теперь можно смело вызывать точку входа загруженного модуля. Он будет функционировать так, словно был вызван самым обычным образом.
AddressOfEntryPoint — это относительный виртуальный адрес (RVA, Relative Virtual Address) точки входа, взятый из optional header в функции LoadExecutable. Для получения абсолютного адреса мы просто прибавили к RVA адрес базы (то есть свежезагруженного модуля).
Уменьшение размера загрузчика
- В разделе «Оптимизация» выбираем «Минимальный размер (/O1)», чтобы компилятор старался сделать все функции более компактными.
- Там же указываем приоритет размера над скоростью (флаг /Os).
- В разделе «Создание кода» выключаем исключения С++, мы их не используем.
- Проверка переполнения буфера нам тоже не нужна (/GS-). Это штука хорошая, но не в нашем случае.
- Отключаем к чертям «Манифест». Он большой, и из-за него в загрузчике создается секция .rsrc, которая нам совершенно не нужна. Вообще, каждая лишняя секция в PE-файле — это минимум 512 совершенно ненужных байт, спасибо выравниванию.
- Отключаем создание отладочной информации.
- Лезем во вкладку «Дополнительно». Выключаем «Внесение случайности в базовый адрес» (/DYNAMICBASE:NO), иначе линкер создаст секцию релоков (.reloc).
- Указываем базовый адрес. Выберем какой-нибудь нестандартный повыше, например 0x02000000. Именно это значение будет возвращать GetModuleHandle(NULL) в загрузчике. Можно его даже захардкодить.
- Указываем нашу точку входа, а не CRT-шную: /ENTRY:WinMain. Вообще, мы привыкли это делать директивой pragma прямо из кода, но раз уж залезли в свойства, то можно и тут.
Здесь мы объединили секцию .rdata, в которой содержатся данные, доступные только для чтения (строки, таблица импорта и т. п.), с секцией кода .text. Если бы мы использовали глобальные переменные, то нам также надо было бы объединить с кодом секцию .data.
Всего перечисленного хватит, чтобы получить лоадер размером в 1,5 Кб.
Упаковщик
Нам остается разработать консольную утилиту, которая будет сжимать отданные ей файлы и прицеплять к лоадеру. Первое, что она должна делать по описанному в начале статьи алгоритму, — это считывать файл в массив. Задача, с которой справится и школьник:
Далее наш пакер должен сжать полученный файл. Мы не будем проверять, действительно ли это PE-файл, корректные ли у него заголовки и т. п., — всё оставляем на совести пользователя, сразу сжимаем. Для этого воспользуемся функциями RtlCompressBuffer и RtlGetCompressionWorkSpaceSize. Первую мы уже описали выше — она сжимает буфер, вторая же нужна, чтобы вычислить объем памяти, необходимой для работы сжимающего движка. Будем считать, что обе функции мы уже динамически подключили (как и в загрузчике), остается только их запустить:
В результате у нас есть сжатый буфер и его размер, можно прикрутить их к загрузчику. Чтобы это сделать, нужно для начала скомпилированный код нашего загрузчика встроить в упаковщик. Самый удобный способ засунуть его в программу — это воспользоваться утилитой bin2h. Она конвертнет любой бинарник в удобный сишный хедер, все данные в нем будут выглядеть как-то так:
Создание хедера с помощью bin2h можно автоматизировать
- Находим единственную секцию (.text) в загрузчике.
- Изменяем ее физический размер, то есть размер на диске (SizeOfRawData). Он должен быть равен сумме старого размера и размера сжатого образа и при этом выравнен в соответствии с файловым выравниванием (FileAlignment).
- Изменяем виртуальный размер памяти (Misc.VirtualSize), прибавляя к нему размер сжатого образа.
- Изменяем размер всего образа загрузчика (OptionalHeader.SizeOfImage) по древней формуле [виртуальный размер последней секции] + [виртуальный адрес последней секции], не забывая выравнивать значение по FileAlignment.
- Копируем сжатый образ в конец секции.
Расширение секции кода
О, мы едва не забыли заменить метки 0xDEADBEEF и 0xBEEFCACE, оставленные в загрузчике, на реальные значения! 0xBEEFCACE у нас меняется на размер сжатого образа, а 0xDEADBEEF — на его абсолютный адрес. Адрес образа вычисляется по формуле [адрес образа] + [виртуальный адрес секции] + [смещение образа относительно начала секции]. Следует отметить, что замену надо производить еще до обновления значения Misc.VirtualSize, иначе полученный в результате файл не заработает.
Ищем и заменяем метки с помощью очень простого цикла:
Вот, собственно, и всё. Теперь в памяти у нас есть упакованный и готовый к работе файл, достаточно сохранить его на диске с помощью функций CreateFile/WriteFile.
Процесс отладки бажного файла в OllyDbg
Выводы
Если сравнивать эффективность сжатия нашего упаковщика с UPX на примере notepad.exe — мы выигрываем примерно 1 Кб: 46 592 байта у нас против 48 128 у UPX. Однако наш пакер далеко не совершенен. И это очень заметно.
Дело в том, что мы сознательно проигнорировали такую важную вещь, как перенос ресурсов. Полученный в результате сжатия файл потеряет иконку! Реализовать недостающую функцию предстоит тебе самому. Благодаря полученным из этого материала знаниям, никаких сложностей у тебя с этим делом не возникнет.
Наш упаковщик сжал notepad.exe сильнее, чем UPX!
Переделываем в криптор
Собственно, от криптора наш пакет отличает совсем немногое: отсутствие функции шифрования и противоэмуляционных приемов. Самое простое, что можно с ходу сделать, — это добавить xor всего образа сразу после распаковки в загрузчике. Но, чтобы эмуляторы антивирусов подавились, этого недостаточно. Нужно как-то усложнить задачу. Например, не прописывать ключ xor’а в теле загрузчика. То есть загрузчик не будет знать, каким ключом ему надо расшифровывать код, он будет его перебирать в определенных нами рамках. Это может занять какое-то время, которое есть у пользователя, в отличие от антивируса.
Также ключ можно сделать зависимым от какой-нибудь неэмулируемой функции или структуры. Только их еще найти надо.
Чтобы код загрузчика не палился сигнатурно, можно прикрутить к упаковщику какие-нибудь продвинутые вирусные движки для генерации мусора и всяческого видоизменения кода, благо их в Сети навалом.
После выполнения функции LoadExecutable в загрузчике неплохо было бы освободить память, выделенную для распаковки, — она нам больше не пригодится.
Журнал Хакер, Февраль (02) 157
Peter and the Wolf.
Программы-упаковщики - это разновидность архиваторов, которые сжимают исполняемые файлы (.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, только иногда тратит на это больше времени.
Привет, хабровчане. В рамках курса "Reverse-Engineering. Basic" Александр Колесников (специалист по комплексной защите объектов информатизации) подготовил авторскую статью.
Также приглашаем всех желающих на открытый вебинар по теме «Эксплуатация уязвимостей в драйвере. Часть 1». Участники вебинара вместе с экспертом разберут уязвимости переполнения в драйверах и особенности разработки эксплойтов в режиме ядра.
Статья расскажет о подходах к анализу запакованных исполняемых файлов с помощью простых средств для обратной разработки. Будут рассмотрены некоторые пакеры, которые применяются для упаковки исполняемых файлов. Все примеры будут проведены в ОС Windows, однако изучаемые подходы можно легко портировать на любую ОС.
Инструментарий и настройка ОС
Для тестов будем использовать виртуальную машину под управлением ОС Windows. Инструментарий будет содержать следующие приложения:
установленный по умолчанию плагин x64dbg Scylla;
Самый быстрый и простой способ провести распаковку любого исполняемого файла — применить отладчик. Но так как мы будем также рассматривать язык программирования Python, то может понадобится проект:
uncompile6 проект, который позволяет разобрать байткод виртуальной машины Python;
pyinstallerExtractor инструмент для распаковки архива pyInstaller.
Общие методы снятия паковки
Разберемся, что же такое паковка. В большинстве случаев исполняемые файлы современных языков программирования имеют довольно большой размер при минимальном наборе функций. Чтобы оптимизировать данную величину, можно применить паковку или сжатие. Наиболее распространенный на сегодняшний день пакер — UPX. Ниже приведен пример того, как пакер проводит сжатие исполняемого файла.
На картинке может показаться, что файл стал по размеру больше, однако это не всегда так. Большинство файлов за счет такой модификации могут уменьшить свой размер до 1.5 раз от исходного объема.
Что же от этого реверс-инженеру? Почему надо знать и уметь определять, что файл упакован? Приведу наглядный пример. Ниже приведен снимок файла, который не запакован:
И файл, который был пропущен через алгоритм UPX:
Изменения коснулись в этом случае двух основных точек исполняемого файла:
Точка входа — в случае с упакованным файлом это начало алгоритма распаковки, настоящий алгоритм программы будет работать только после того, как будет распакован оригинальный файл;
Код оригинального файла: теперь не найти паттернов, которые можно сразу разбирать как команды.
Итак, чтобы снова анализировать оригинальный файл, нужно найти настоящую или оригинальную точку входа. Для этого нужно разбить алгоритм на основные этапы:
Этап подготовки исполнения файла — загрузчик ОС настраивает окружение, загружает файл в оперативную память;
Сохранение контекста — упаковщик сохраняет контекст исполнения файла (набор значений регистров общего назначения, которые были установлены загрузчиком ОС);
Распаковка оригинального файла;
Передача управления оригинальному файлу.
Все описанные выше этапы можно легко отследить в отладчике. Особенно может выделяться процедура сохранения контекста. Для нее в разных архитектурах могут быть использованы команды pushad/popad или множественное использование команды push . Поэтому всегда приложение трассируют до первого изменения регистра ESP/RSP, и ставят "Hardware Breakpoint" на адрес, который был помещен в регистр в первый раз. Второе обращение этому адресу будет в момент восстановления контекста, который заполнил загрузчик ОС. Без него приложение завершится с ошибкой.
Пример UPX
Попробуем с помощью отладчика найти оригинальную точку входа для приложения. Запечатлим оригинальную точку входа до упаковки UPX:
Как та же точка входа выглядит после упаковки:
Запустим отладчик и попробуем найти место сохранения контекста:
Ждем первого использования ESP — в отладчике при этом значение регистра подсветится красным цветом. Затем устанавливаем точку останова на адрес и просто запускаем приложение:
В результате попадаем на оригинальную точку входа:
Вот так просто, теперь используя плагин Scylla Hide можно сохранить результирующий файл на жесткий диск и продолжить его анализ.
Подобный метод можно применять для любого упаковщика, который сохраняет контекст на стек.
Пример PyInstaller
Не всегда подобный подход работает для приложений, которые используют более сложную структуру исполняемого файла. Рассмотрим файл, который был создан с помощью PyInstaller — пакет, который позволяет преобразовать Python скрипт в исполняемый файл. При генерации исполняемого файла создается архив, который содержит виртуальную машину Python и все необходимые библиотеки. Сам исходный код приложения при этом преобразуется в байт код и его нельзя дезассемблировать.
Попробуем все же получить что-то читаемое. Создадим простое приложение на Python и упакуем с помощью PyInstaller. Исходный код приложения:
Установим пакет pyInstaller и создадим exe файл:
Итак, проведем сбор информации о том, что в итоге получилось. У нас есть архив, который должен запустить виртуальную машину, и код, который мы записали в виде скрипта. Попробуем восстановить исходник и просто его прочесть даже без запуска.
После выполнения команд выше, у вас должна создаться директория ./dist/test.exe . Откроем последовательно файл с помощью pyinstallerextractor и uncompile3 :
Наш скрипт находится в директории, которая создается в результате распаковки. Наименование файла должно соответствовать названию exe файла. В нашем случае это test.pyc . Откроем его в hiew :
Декомпиляция стандартными средствами невозможна, так как инструменты просто не умеют работать с байткодом Python. Применим специализированный инструмент — uncompile6 .
Free UPX (the Ultimate Packer for eXecutables) - программа для упаковки и распаковки исполняемых файлов, поддерживающий несколько различных платформ и форматов файлов. Является свободным и открытым программным обеспечением, и распространяется по лицензии GNU GPL.
Наиболее важные характеристики:
* Сжатие и выполняемые файлы декомпрессии (EXE, DLL, OCX, BPL, CPL, SYS, ТОПОР, ACM, DRV, TLB и другое).
* Легкие acces на всю командную линию параметров UPX.
* Отображая подробную информацию о сжатых файлах: оригинальный файловый размер, compresson коэффициент, версия UPX, уровень сжатия и другое.
* Встроенные профили UPX для начинающих. Опытные пользователи могут определить заказные профили.
* Не нужно любая установка. Просто ИНДЕКС экстрата архивный и fupx.exe файл щелчка.
* Мобильность. Эта программа может быть прогоном с портативных устройств. Все установочные параметры записаны в файл INI.
* Интеграция Оболочки (дополнительная).
* 100% способ свободного пользования! - для частного и коммерческого использования. Нет ограничений, adware, spyware.
Free UPX is an advanced graphical interface for the UPX (Ultimate Packer for eXecutables). It allows you to compress (and decompress) files produced according to Microsoft Portable Executable and COFF Specification (EXE, DLL, OCX, BPL, CPL and other). It offers easy access to all documented and undocumented UPX parameters without the need for command line usage.
The Free UPX interface is very simple and user-friendly. To compress executable files, just drag & drop them into main window, select proper profile from list, and click the COMPRESS button.
It is the best GUI for UPX on Windows not only because it have support for all parameters of UPX.
Changes in UPX 3.91 (30 Sep 2013):
* Added experimental support for Windows 64-bit PE files, based on
work by Stefan Widmann. Please use for testing only!
* bug fixes
Changes in UPX 3.09 (18 Feb 2013):
* New option preserve-build-id for GNU ELF.
* Allow for code signing and LC_UUID on Mac OS X executables.
* Allow non-contiguous LC_SEGMENTs and 0==.vmsize for Mach-O.
* Allow zero-filled final page in PackUnix::canUnpack().
* bug fixes
Official there is no updated Version out for Free UPX 1.7 since 2013.
Here is a modded Version, while waiting for an official updated Version, with the following changes (mainly to use UPX 3.91):
Current version supports 64-bit executable files (Win64/PE), but this feature is declared as experimental.
Free UPX is designed for UPX 3.91w - the last stable version available in October 2013.
Russian localization "Free UPX 1.7" by Metabolic
Release date: 07.10.2013
Language: English/Russian
License: Freeware
System: XP/2003/Vista/Win7/Win8
File size: 1.2 MB
Download: Free UPX 1.7 en (installed)
Download: Free UPX 1.7 en (portable)
Download: Free UPX 1.7 ru (portable)
Download: UPX v3.91w
После нескольких лет разработок выпущена финальная версия одной из лучших программ для упаковки исполняемых файлов UPX (the Ultimate Packer for eXecutables). Представляет собой консольный упаковщик, способный сжать exe файлы без потери их работоспособности.
реклама
Поддерживает различные исполняемые типы (win32/pe, djgpp2/coff, atari/tos, linux/386, watcom/le, dos/exe, dos/com и прочие), выпускается в версиях для Linux, DOS, Atari, а теперь и PowerPC. Гибко настраивается, распространяется с открытыми исходными кодами. Работает из командной строки (для ленивых создано множество графических оболочек, например, UPXShell, UPX GUI , Alpx и многие другие). В среднем сжимаемые с помощью UPX файлы уменьшаются в размерах как минимум в два раза, при этом они практически ничего не теряют в скорости запуска и выполнения. При желании можно восстановить первоначальный размер, то есть распаковать. UPX будет полезен всем желающим, кто хочет освободить немного свободного места на диске, и программистам, которые смогут значительно уменьшить размеры дистрибутивов со своими программами.
- добавлена поддержка для исполняемых файлов arm/pe (ARM приложения, запускаемые под WinCE)
- добавлена поддержка для исполняемых файлов linux elf/amd64
- добавлена поддержка для исполняемых файлов linux elf/ppc32
- добавлена поддержка для исполняемых файлов mach/ppc32 (Apple Mac OS X)
- добавлена поддержка для загрузочных ядер Linux ("vmlinuz/386")
- добавлена поддержка для исполняемых файлов Playstation ("ps1/exe")
- улучшено сжатие за счет использования нового алгоритма NRV2E
- новые опции для настройки параметров сжатия (например '--brute')
- улучшена совместимость с приложениями win32/pe
- direct ELF-to-memory decompression
- исправлено множество ошибок
Для сравнения, исполняемый файл Dreamweaver.exe от версии 8 до упаковки занимал 14 610 KB, а после применения «upx Dreamweaver.exe -9» уменьшился до 4 613 KB, то есть фактически в 3.1 раза или до 31% от первоначального размера.
Читайте также: