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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИМХО в обычном режиме UPXing бессмысленен, но причины изложены выше, в основном, память дороже диска.

Эрик: заглушка LZMA могла бы быть больше. Даже если алгоритм лучше, это не всегда будет чистым плюсом.

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

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

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

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

Когда Windows загружает двоичный файл, первое, что она делает, это разрешение таблицы импорта / экспорта. То есть, какие бы API и DLL не были указаны в таблице импорта, они сначала загрузят DLL в случайно сгенерированный базовый адрес. И используя базовый адрес плюс смещение в функции DLL, эта информация будет обновлена ​​в таблице импорта.

EXE не имеет таблицы экспорта.

Все это произошло еще до перехода к исходной точке входа для выполнения.

Затем после того, как он начнет выполнение с точки входа, EXE выполнит небольшой фрагмент кода перед запуском алгоритма распаковки. Этот небольшой фрагмент кода также означает, что необходимый Windows API будет очень маленьким, что приведет к небольшой таблице импорта.

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

Использованная литература:

https://malwaretips.com/threads/malware-analysis-2-pe-imports-static-analysis.62135/