使用UPX压缩Windows可执行文件有什么缺点吗？

Question

之前我曾使用UPX来减少我的Windows可执行文件的大小，但我必须承认我对这可能产生的任何负面影响都很天真。所有包装/拆包的缺点是什么？

是否存在任何人建议NOT UPX-ing可执行文件的情况（例如，在编写DLL，Windows服务或定位Vista或Win7时）？我在Delphi中编写了大部分代码，但我也使用UPX来压缩C / C ++可执行文件。

另一方面，我不在某些尝试中运行UPX以保护我的exe不被反汇编程序，只是为了减少可执行文件的大小并防止粗略的篡改。

Answer 1

  

原因是存在缺点   使用EXE压缩机。最值得注意的是：

     

启动压缩的EXE / DLL后，所有代码都是   从磁盘映像解压缩到   一次通过内存，这可能会导致   如果系统处于低电平状态，则磁盘抖动   内存并被迫访问   交换文件。与...对比   未压缩的EXE / DLL，操作系统   为代码页分配内存   需求（即执行时）。

     

压缩的EXE / DLL的多个实例创建多个   内存中代码的实例。如果   你有一个压缩的EXE   包含1 MB的代码（之前   压缩）并且用户启动5   它的实例，大约4 MB   记忆浪费了。同样，如果你   有一个1 MB的DLL，它被使用   由5个正在运行的应用   大约4 MB的内存   浪费了。使用未压缩的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已经在高速缓存中，或者在非常快速的存储介质上，或者你正在运行的CPU速度很慢，你将会遇到降低的启动速度，因为仍然需要进行解压缩，而你不会受益于缩小的尺寸。对于将重复多次调用的EXE尤其如此。

因此，如果您的EXE或DLL包含大量资源，则上述缺点更多是一个问题，但是，鉴于可执行文件和可用内存的相对大小，它们在实践中可能不是很重要，除非您是谈论许多可执行文件（如系统DLL）使用的DLL。

在其他答案中消除一些不正确的信息：

• UPX不会影响您在受DEP保护的计算机上运行的能力。
• UPX不会影响主要防病毒软件的能力，因为它们支持UPX压缩的可执行文件（以及其他可执行的压缩格式）。
• UPX已经能够使用LZMA压缩一段时间了（7zip的压缩算法），使用--lzma开关。

Answer 4

唯一重要的时间是从互联网下载期间。如果您使用的是UPX，那么实际上您的性能会比使用7-zip时更差（基于我的测试，7-Zip是UPX的两倍）。然后，当它在目标计算机上实际上被压缩时，性能会降低（请参阅Lars的回答）。因此UPX不是文件大小的好解决方案。只需7zip整个事情。

就防止篡改而言，它也是 FAIL 。 UPX也支持解压缩。如果有人想要修改EXE，那么他们会看到它是用UPX压缩然后解压缩它。您可能放慢速度的可能破解程序的百分比并不能证明这种努力和性能损失是合理的。

更好的解决方案是使用二进制签名或至少只是哈希。一个简单的哈希验证系统是获取二进制的哈希值和一个秘密值（通常是一个guid）。只有您的EXE知道秘密值，因此当它重新计算哈希值以进行验证时，它可以再次使用它。这不是完美的（可以检索秘密值）。理想的情况是使用证书和签名。

Answer 5

磁盘上可执行文件的最终大小现在基本上无关紧要。您的程序可能会加载几毫秒，但一旦开始运行，差异就无法区分。

有些人可能因为使用UPX进行压缩而对您的可执行文件更加怀疑。根据您的最终用户，这可能是也可能不是重要的考虑因素。

Answer 6

我最后一次尝试在托管程序集上使用它时，它使它非常糟糕，以至于运行时拒绝加载它。这是我唯一能想到你不想使用它的时间（而且，实际上，自从我尝试过这么久以后情况甚至可能会更好）。我过去在所有类型的非托管二进制文件中广泛使用它，从来没有遇到过问题。

Answer 7

如果您唯一感兴趣的是减少可执行文件的大小，那么您是否尝试使用和不使用运行时包来比较可执行文件的大小？当然，您还必须包括整个软件包的大小以及可执行文件，但如果您有多个使用相同基本软件包的可执行文件，那么您的节省将会相当高。

要看的另一件事是您在程序中使用的图形/字形。通过将它们合并到包含在全局数据模块中的单个Timagelist而不是在每个表单上重复它们，可以节省相当多的空间。我相信每个图像都以十六进制形式存储在表单资源中，这意味着每个字节占用两个字节...您可以通过使用TResourceStream从RCData资源加载图像来缩小这一点。

Answer 8

恕我直言UPX是毫无意义的，但原因如上所述，主要是内存比磁盘更贵。

Erik：LZMA存根可能更大。即使算法更好，它也不总是净加。

Answer 9

查找“未知”病毒的病毒扫描程序可以将UPX压缩的可执行文件标记为有病毒。我被告知这是因为有几种病毒使用UPX来隐藏自己。我在软件上使用了UPX，迈克菲将该文件标记为有病毒。

Answer 10

UPX之所以有这么多误报是因为它的开放许可允许恶意软件作者使用和修改它而不受惩罚。当然，这个问题是该行业固有的问题，但遗憾的是，UPX项目很受此问题的困扰。

更新：请注意，当Taggant项目完成后，假设UPX支持，则可以增强使用UPX（或其他任何内容）而不会导致误报的能力。

Answer 11

没有任何缺点。

但仅仅是FYI，关于UPX存在一个非常普遍的误解 -

资源不只是被压缩

基本上，您正在构建一个具有＆＃34; loader＆＃34;的新可执行文件。责任和真实的＆＃34;可执行文件，正在进行分段剥离和压缩，作为加载程序可执行文件的二进制数据资源放置（无论资源类型是否在原始可执行文件中）。

使用逆向工程方法和tools用于教育目的或其他将向您显示有关＆＃34;加载程序可执行文件＆＃34;的信息，而不是有关原始可执行文件。

Answer 12

我相信它可能无法在已启用DEP（数据执行保护）的计算机上运行。

Answer 13

Windows加载二进制文件时，首先要做的就是导入/导出表解析。即，无论导入表中指示了什么API和DLL，它都会首先将DLL加载到随机生成的基址中。然后，在DLL函数中使用基地址加偏移量，此信息将更新到“导入表”。

EXE没有导出表。

所有这些事情甚至在跳转到原始入口点执行之前就发生了。

然后从入口点开始执行后，EXE将运行一小段代码，然后再启动解压缩算法。这小段代码也意味着所需的Windows API将会非常小，从而导致导入表也很小。

但是在二进制文件解压缩后，如果它开始使用以前未解析的任何Windows API，则很可能会崩溃。因此，在执行解压缩的代码之前，解压缩例程必须为解压缩的代码内的所有引用的Window API解析并更新导入表。

参考：

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