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

35

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

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

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

  • 1
    +1 причина не использовать UPX: некоторые антивирусы идентифицируют Delphi + UPX как потенциальный вирус. Предпочтительнее использовать наш LVCL, который составляет 30 КБ exe с Delphi, без сжатия (вместо 300 КБ / 800 КБ exe с обычным VCL). Этого достаточно, например, для программы установки, которая распакует содержимое. См. Synopse.info/forum/viewtopic.php?id=30. Вы также можете взглянуть на KOL, который является более сложным в использовании, но также и более мощным.
Теги:
winapi
compression
upx

12 ответов

47
Лучший ответ

Причиной тому являются недостатки используя компрессоры EXE. Наиболее заметно:

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

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

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

  • 4
    Однако не все программное обеспечение находится в ситуации, когда проблемой является совместное использование страниц виртуальных машин между несколькими экземплярами, а некоторые компрессоры допускают пропуск общих разделов. Например, PECompact пропускает их по умолчанию. Также, что касается «всей загружаемой памяти», это верно, но эта память будет выгружена обратно, если она не используется и нужна где-то еще. В некоторых ситуациях это создает более быструю загрузку, потому что издержки носителя (обычно жесткого диска) ниже, и все загружается «сразу» и «уже есть». Итак, есть исключения, и каждому свое. ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я автор PECompact.
  • 1
    Джереми: Общие разделы - это не столько проблема, сколько реальные разделы кода. Код, как правило, представляет собой чтение-выполнение с отображением в памяти, что означает, что если вы запустите 10 программ, все они будут использовать одни и те же идентичные страницы физической памяти, а физические данные загружаются с диска только один раз. ОС может также отбрасывать страницы, которые содержат код, который никогда не вызывался, если у него не хватает памяти, зная, что он всегда может перезагрузить их из образа. Ничего подобного не происходит с кодом, полученным из упаковщика exe, соответствующие страницы должны быть подкреплены файлом подкачки.
Показать ещё 2 комментария
18

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

  • 2
    UPX не для защиты. Просто упаковка.
  • 0
    Извините, я немного пренебрегал этим. Изменили формулировку сейчас.
Показать ещё 2 комментария
13

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

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

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

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

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

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

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

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

  • 2
    Размер имеет значение на флешке. Портативные приложения - это тот случай, когда это имеет смысл.
  • 1
    Учитывая текущие цены на мультигигабайтные флешки, я не уверен, что размер там уже имеет значение. Если, конечно, вы не храните HD-видео.
Показать ещё 3 комментария
4

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

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

  • 1
    +1 Я всегда с подозрением отношусь к упакованным исполняемым файлам / DLL, особенно если я не могу их распаковать
  • 0
    Размер имеет значение в контейнерах Docker.
2

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

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

2

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

1

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

Но просто FYI существует очень распространенное заблуждение относительно UPX as -

Ресурсы

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

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

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

Изображение 7773

Изображение 7774

  • 4
    «Недостатков нет». - это просто неправильное утверждение.
  • 0
    @kobik, хотя «нет недостатков» *, вероятно, следует заменить на «нет практических недостатков», * что по сути (для практического разработчика в современной архитектуре) означает то же самое, я решил, что это не требует редактирования, в пользу более четкий, реалистичный ответ. Смирись с этим :)
Показать ещё 2 комментария
1

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

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

1

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

  • 5
    McAfee? Это самое ужасное антивирусное программное обеспечение, которое я когда-либо использовал. Держись подальше!
  • 9
    На самом деле, держитесь подальше от любого антивирусного сканера, который настолько глуп, чтобы пометить каждый сжатый файл upx как вирус.
1

IMHO регулярно UPXing бессмысленна, но причины написаны выше, в основном, память дороже диска.

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

  • 0
    Похоже, что память и дисковое пространство не сильно влияют на современное оборудование, что делает UPX просто дополнительным осложнением. По своему опыту я экономлю только около 500 КБ из приложения размером 3 МБ, особенно на Mac, где файлы dylib не поддерживаются.
0

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

  • 2
    Как автор коммерческого компрессора PE (PECompact), я могу сказать, что каждый упаковщик должен полностью поддерживать DEP - включая UPX. Я не могу с уверенностью сказать, что это так, но, безусловно, так и есть - это было проблемой много лет назад.
  • 0
    Кул, ты дашь какие-нибудь подробности, как это достигается в деталях? (Источник / литература)
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню