Есть ли недостатки использования UPX для сжатия исполняемого файла Windows?
Ранее я использовал UPX, чтобы уменьшить размер моих исполняемых файлов Windows, но я должен признать, что наивен в отношении любых негативных побочных эффектов, которые это может иметь. В чем недостаток всей этой упаковки / распаковки?
Существуют ли сценарии, в которых кто-либо рекомендовал бы НЕ выполнять UPX-загрузку исполняемого файла (например, при написании DLL, службы Windows или при настройке Vista или Win7)? Я пишу большую часть своего кода на Delphi, но я также использовал UPX для сжатия исполняемых файлов C/C++.
С другой стороны, я не запускаю UPX в какой-то попытке защитить свой exe-файл от дизассемблеров, а только для того, чтобы уменьшить размер исполняемого файла и предотвратить несанкционированное вмешательство.
12 ответов
Причина в том, что использование компрессоров EXE имеет свои недостатки. Наиболее заметно:
При запуске сжатого EXE/DLL весь код распаковывается из образа диска в память за один проход, что может вызвать перегрузку диска, если в системе недостаточно памяти и она вынуждена обращаться к файлу подкачки. Напротив, с несжатыми EXE/DLL, операционная система выделяет память для кодовых страниц по требованию (т.е. когда они выполняются).
Несколько экземпляров сжатого EXE/DLL создают несколько экземпляров кода в памяти. Если у вас есть сжатый EXE-файл, содержащий 1 МБ кода (до сжатия), и пользователь запускает 5 его экземпляров, примерно 4 МБ памяти теряется. Аналогичным образом, если у вас есть DLL, которая составляет 1 МБ, и она используется 5 запущенными приложениями, примерно 4 МБ памяти тратится впустую. С несжатыми EXE/DLL код сохраняется в памяти только один раз и распределяется между экземплярами.
Я удивлен, что это еще не было упомянуто, но использование исполняемых файлов UPX также увеличивает риск получения ложных срабатываний от эвристического антивирусного программного обеспечения, потому что статистически много вредоносных программ также использует UPX.
Есть три недостатка:
- Весь код будет полностью разархивирован в виртуальной памяти, в то время как в обычном EXE или DLL только реально используемый код загружается в память. Это особенно актуально, если при каждом запуске используется только небольшая часть кода в вашем EXE/DLL.
- Если запущены несколько экземпляров вашей DLL и EXE, их код не может быть разделен между экземплярами, поэтому вы будете использовать больше памяти.
- Если ваш 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. В зависимости от ваших конечных пользователей, это может или не может быть важным фактором.
Недостатков нет.
Но, к вашему сведению, существует очень распространенное заблуждение относительно UPX как:
ресурсы не просто сжимаются
По сути, вы создаете новый исполняемый файл, который выполняет обязанности "загрузчика", а "настоящий" исполняемый файл, в общем-то, разбирается на разделы и сжимается, помещается как ресурс двоичных данных исполняемого файла загрузчика (независимо от того, какие типы ресурсов были в оригинальный исполняемый файл).
Использование методов и инструментов обратного проектирования в образовательных или других целях покажет вам информацию, касающуюся "исполняемого файла загрузчика", а не переменную информацию, касающуюся исходного исполняемого файла.
Если ваш единственный интерес заключается в уменьшении размера исполняемых файлов, пытались ли вы сравнить размер исполняемого файла с пакетами времени выполнения и без них? Конечно, вам нужно будет также включать размеры пакетов в целом вместе с вашим исполняемым файлом, но если у вас есть несколько исполняемых файлов, которые используют одни и те же базовые пакеты, то ваша экономия будет довольно высокой.
Еще одна вещь, на которую стоит обратить внимание, это графика / глифы, которые вы используете в своей программе. Вы можете сэкономить немного места, объединив их в один список Timagelist, включенный в модуль глобальных данных, вместо того, чтобы повторять их в каждой форме. Я полагаю, что каждое изображение хранится в ресурсе формы в шестнадцатеричном формате, так что это означает, что каждый байт занимает два байта... Вы можете уменьшить это немного, загрузив изображение из ресурса RCData, используя TResourceStream.
В прошлый раз, когда я пытался использовать его в управляемой сборке, он так испортил его, что среда выполнения отказалась его загружать. Это единственный раз, когда я могу думать о том, что вы не захотите его использовать (и, действительно, это было так давно, с тех пор как я пытался это сделать, что сейчас ситуация может быть даже лучше). В прошлом я широко использовал его для всех типов неуправляемых двоичных файлов, и у меня никогда не было проблем.
Сканеры вирусов, которые ищут "неизвестные" вирусы, могут помечать сжатые исполняемые файлы UPX как наличие вируса. Мне сказали, что это потому, что несколько вирусов используют UPX, чтобы скрыть себя. Я использовал UPX в программном обеспечении, и McAfee помечает файл как вирус.
Причина, по которой у UPX так много ложных тревог, заключается в том, что его открытое лицензирование позволяет авторам вредоносного ПО безнаказанно использовать и модифицировать его. Конечно, эта проблема присуща отрасли, но, к сожалению, большой проект UPX страдает от этой проблемы.
ОБНОВЛЕНИЕ: обратите внимание, что по мере завершения проекта Taggant возможность использовать UPX (или что-либо еще) без ложных срабатываний будет расширена, при условии, что UPX его поддерживает.
ИМХО рутинно UPXing не имеет смысла, но причины изложены выше, в основном, память дороже, чем диск.
Эрик: заглушка LZMA может быть больше. Даже если алгоритм лучше, он не всегда является чистым плюсом.
Я полагаю, что существует вероятность того, что он может не работать на компьютерах, на которых включен DEP (Data Execution Prevention).
Когда Windows загружает двоичный файл, первое, что она делает, это разрешение таблицы импорта / экспорта. То есть, какие бы API и DLL ни указывались в таблице импорта, они сначала загружают DLL в случайно сгенерированный базовый адрес. И используя базовый адрес плюс смещение в функции DLL, эта информация будет обновлена в таблице импорта.
EXE не имеет таблицы экспорта.
Все это произошло еще до перехода к исходной точке входа для выполнения.
Затем после того, как он начнет выполнение с точки входа, EXE выполнит небольшой фрагмент кода перед запуском алгоритма распаковки. Этот небольшой фрагмент кода также означает, что необходимый Windows API будет очень маленьким, что приведет к небольшой таблице импорта.
Но после распаковки двоичного файла, если он начал использовать какой-либо Windows API, не разрешенный ранее, скорее всего, он выйдет из строя. Поэтому важно, чтобы процедура декомпрессии разрешала и обновляла таблицу импорта для всех упомянутых окон API внутри распакованных кодов перед выполнением распакованных кодов.
Ссылки:
https://malwaretips.com/threads/malware-analysis-2-pe-imports-static-analysis.62135/