使用UPX压缩Windows可执行文件有什么缺点吗？
我之前使用过UPX来减lessWindows可执行文件的大小，但是我必须承认，我对这种可能产生的负面影响是天真的。 所有这些包装/拆包的缺点是什么？
是否有任何人会推荐不UPX的可执行文件（例如，当编写一个DLL，Windows服务，或针对Vista或Win7时）？ 我在Delphi中编写了大部分代码，但是我也使用UPX来压缩C / C ++可执行文件。
在附注中，我没有运行UPX来保护我的exe免受反汇编，只是为了减小可执行文件的大小，并防止粗略的篡改。
原因是使用EXE压缩机有缺点。 最为显着地：
启动一个压缩的EXE / DLL后，所有代码都会从磁盘映像解压缩到内存中，如果系统内存不足，并且被迫访问交换文件，则会导致磁盘抖动。 相比之下，对于未压缩的EXE / DLL，操作系统按需分配代码页的内存（即执行时）。
压缩的EXE / DLL的多个实例在内存中创build代码的多个实例。 如果您有一个包含1 MB代码（压缩之前）的压缩EXE，并且用户启动了5个实例，则会浪费大约4 MB的内存。 同样，如果你有一个1MB的DLL，并且被5个正在运行的应用程序使用，大约4MB的内存就被浪费了。 使用未压缩的EXE / DLL，代码只存储在内存中一次，并在实例之间共享。
我很惊讶这个还没有被提到，但是使用UPX打包的可执行文件也增加了启发式反病毒软件产生误报的风险，因为统计上很多恶意软件也使用了UPX。
有三个缺点：
- 整个代码将在虚拟内存中完全解压缩，而在常规的EXE或DLL中，只有实际使用的代码被加载到内存中。 如果在每次运行时只使用EXE / DLL中的一小部分代码，这尤其相关。
- 如果有多个DLL和EXE实例在运行，它们的代码不能在实例中共享，因此您将使用更多的内存。
- 如果您的EXE / DLL已经在caching中，或者在非常快的存储介质上，或者如果您正在运行的CPU速度很慢，您将会遇到启动速度降低，因为解压仍然会发生，受益于尺寸缩小。 这对于将被多次调用的EXE尤其如此。
因此，如果您的EXE或DLL包含大量资源，上述缺点就成了一个问题，否则，考虑到可执行文件和可用内存的相对大小，除非您正在讨论DLL，否则它们在实践中可能并不是一个很重要的因素大量的可执行文件（如系统DLL）使用。
在其他答案中解散一些不正确的信息：
- UPX不会影响您在DEP保护机器上运行的能力。
- UPX不会影响主要防病毒软件的能力，因为它们支持UPX压缩的可执行文件（以及其他可执行压缩格式）。
- UPX已经能够使用LZMA压缩一段时间了（7zip的压缩algorithm），使用–lzma开关。
唯一的时间大小是在下载互联网的过程中。 如果你使用的是UPX，那么你实际上比使用7-zip （根据我的testing7-Zip是UPX的两倍）性能更差。 然后，当它在目标计算机上实际上被压缩时，性能会下降（请参阅Lars的答案）。 所以UPX不是一个好的文件大小的解决scheme。 只是7zip整个事情。
至于防止篡改，这也是一个失败 。 UPX也支持解压缩。 如果有人想修改EXE，那么他们会看到它用UPX压缩，然后解压缩。 你可能减速的可能的cookies的百分比不合理的努力和性能损失。
更好的解决scheme是使用二进制签名或至less只是一个哈希。 一个简单的哈希validation系统是对你的二进制文件和一个秘密值（通常是一个guid）进行散列。 只有你的EXE知道这个秘密值，所以当它重新计算哈希来validation时，它可以再次使用它。 这并不完美（秘密价值可以检索）。 理想的情况是使用证书和签名。
磁盘上可执行文件的最终大小在很大程度上是无关紧要的。 你的程序可能会加载几毫秒，但一旦开始运行，差异是难以区分的。
有些人可能会更怀疑你的可执行文件，因为它是用UPX压缩的。 取决于您的最终用户，这可能是也可能不是一个重要的考虑因素。
上一次我试图在一个托pipe程序集上使用它时，它将它变得非常糟糕，以至于运行时拒绝加载它。 那是我唯一能想到的，就是你不想用它（而且，实际上，我已经试了很久，现在情况可能会好起来）。 我以前在所有types的非托pipe二进制文件中广泛使用它，从来没有问题。
如果您唯一的兴趣是减小可执行文件的大小，那么您是否尝试过比较可执行文件的大小以及不使用运行时软件包？ 当然，你还必须包括整个包的大小以及你的可执行文件，但是如果你有多个使用相同基本包的可执行文件，那么你的节省将会相当高。
另一个要看的是你在程序中使用的graphics/字形。 通过将它们整合到全局数据模块中包含的单个Timagelist中，而不是在每个表单上重复它们，您可以节省相当多的空间。 我相信每个图像都以hexforms存储在表单资源中，所以这意味着每个字节占用两个字节…您可以通过使用TResourceStream从RCData资源加载图像来缩小这一点。
恕我直言，常规UPXing是毫无意义的，但原因拼写上面，主要是，内存比磁盘更昂贵。
Erik：LZMA存根可能更大。 即使algorithm更好，它并不总是一个净加。
查找“未知”病毒的病毒扫描程序可能会将UPX压缩可执行文件标记为有病毒。 我被告知这是因为几种病毒使用UPX来隐藏自己。 我在软件上使用了UPX，McAfee将这个文件标记为有病毒。
UPX有这么多的虚假警报的原因是因为它的开放许可允许恶意软件作者不受惩罚地使用和修改它。 当然，这个问题是这个行业固有的问题，但不幸的是，这个伟大的UPX项目受到了这个问题的困扰。
更新：请注意，随着Taggant项目的完成，使用UPX（或其他任何东西）而不会导致误报的能力将得到增强，假设UPX支持它。
我相信有可能在打开DEP （数据执行保护）的计算机上无法工作。
没有缺点。
但是仅供参考，关于UPX有一个很常见的误解，
资源不仅仅被压缩
本质上，你正在构build一个新的可执行文件，它具有“加载器”的职责，而“真正的”可执行文件正在被部分剥离和压缩，作为加载器可执行文件的二进制数据资源（无论资源types原始的可执行文件）。
使用反向工程方法和工具为教育目的或其他将显示有关“加载器可执行文件”的信息，而不是有关原始可执行文件的variables信息。
