Есть ли недостатки использования UPX для сжатия исполняемого файла Windows?

Question

Я использовал UPX прежде, чтобы уменьшить размер моих исполняемых файлов Windows, но я должен признать, что я наивен в отношении любых негативных побочных эффектов, которые это может иметь. В чем недостаток всей этой упаковки / распаковки?

Существуют ли сценарии, в которых кто-либо рекомендовал бы НЕ выполнять UPX-загрузку исполняемого файла (например, при написании DLL, службы Windows или при настройке Vista или Win7)? Я пишу большую часть своего кода на Delphi, но я также использовал UPX для сжатия исполняемых файлов C / C ++.

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

Answer 1

Причина в том, что с использованием компрессоров EXE. В частности:

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

Несколько экземпляров сжатого EXE / DLL создают несколько экземпляры кода в памяти. Если у вас есть сжатый EXE, который содержит 1 МБ кода (до сжатие) и пользователь начинает 5 случаев, около 4 МБ память потрачена впустую. Точно так же, если вы есть DLL, которая составляет 1 МБ, и она используется 5 запущенными приложениями, примерно 4 МБ памяти потрачены впустую. С несжатыми EXE / DLL, код сохраняется в памяти только один раз и распределяется между экземплярами.

http://www.jrsoftware.org/striprlc.php#execomp

Answer 2

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

Answer 3

Есть три недостатка:

1. Весь код будет полностью разархивирован в виртуальной памяти, в то время как в обычном EXE или DLL только реально используемый код загружается в память. Это особенно актуально, если при каждом запуске используется только небольшая часть кода в вашем EXE / DLL.
2. Если запущены несколько экземпляров вашей DLL и EXE, их код не может быть разделен между экземплярами, поэтому вы будете использовать больше памяти.
3. Если ваш EXE / DLL уже находится в кеше, или на очень быстром носителе, или если процессор, на котором вы работаете, работает медленно, вы почувствуете снижение скорости запуска, так как декомпрессия все равно придется выполнять, и не выиграют от уменьшенного размера. Это особенно верно для EXE-файла, который будет вызываться несколько раз.

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

Чтобы рассеять неверную информацию в других ответах:

• UPX не повлияет на вашу способность работать на машинах, защищенных DEP.
• UPX не повлияет на возможности основных антивирусных программ, поскольку они поддерживают исполняемые файлы со сжатием UPX (а также другие исполняемые форматы сжатия).
• UPX уже некоторое время может использовать сжатие LZMA (алгоритм сжатия 7zip), используйте ключ --lzma.

Answer 4

Размер имеет значение только при загрузке из Интернета. Если вы используете UPX, то на самом деле вы получаете худшую производительность, чем если бы вы использовали 7-zip (на основании моего тестирования 7-Zip в два раза лучше, чем UPX). Затем, когда он остается сжатым на целевом компьютере, ваша производительность снижается (см. Ответ Ларса). Так что UPX не является хорошим решением для размера файла. Просто распакуйте все это.

Что касается предотвращения взлома, это также FAIL . UPX также поддерживает распаковку. Если кто-то захочет изменить EXE-файл, он увидит, что он сжимается с помощью UPX, а затем распаковывает его. Процент возможных взломщиков, которые вы можете замедлить, не оправдывает потери усилий и производительности.

Лучшим решением было бы использовать двоичное подписание или хотя бы просто хеш. Простая система проверки хеша состоит в том, чтобы взять хеш вашего двоичного файла и секретное значение (обычно guid). Только ваш EXE знает секретное значение, поэтому, когда он пересчитывает хеш для проверки, он может использовать его снова. Это не идеально (секретное значение может быть восстановлено). Идеальная ситуация - использовать сертификат и подпись.

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

Недостатков нет.

Но, к вашему сведению, существует очень распространенное заблуждение относительно UPX как -

ресурсы не просто сжимаются

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

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

Answer 9

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

ОБНОВЛЕНИЕ: обратите внимание, что по мере завершения проекта Taggant возможность использования UPX (или чего-либо еще) без ложных срабатываний будет расширена, при условии, что UPX его поддерживает.

Answer 10

Антивирусные сканеры, которые ищут «неизвестные» вирусы, могут помечать сжатые UPX исполняемые файлы как наличие вируса. Мне сказали, что это потому, что несколько вирусов используют UPX, чтобы скрыть себя. Я использовал UPX в программном обеспечении, и McAfee помечает файл как вирус.