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

Question

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

Mic*_*ick 37 c++ compression delphi winapi upx

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

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

另外,我没有尝试使用UPX来保护我的exe不被反汇编程序,只是为了减少可执行文件的大小并防止粗略的篡改.

Answer 1

原因是使用EXE压缩器存在缺点.最为显着地:

在启动压缩的EXE/DLL时,所有代码都会在一次传递中从磁盘映像解压缩到内存中,如果系统内存不足并被强制访问交换文件,则会导致磁盘抖动.相反,对于未压缩的EXE/DLL,OS根据需要为代码页分配内存(即,当它们被执行时).

压缩的EXE/DLL的多个实例在内存中创建多个代码实例.如果您有一个包含1 MB代码的压缩EXE(压缩前),并且用户启动了5个实例,则会浪费大约4 MB的内存.同样,如果您有一个1 MB的DLL并且由5个正在运行的应用程序使用,则会浪费大约4 MB的内存.使用未压缩的EXE/DLL,代码只存储在内存中一次,并在实例之间共享.

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

并非所有软件都处于多个实例之间的VM页面共享是一个问题,并且一些压缩器允许跳过共享部分.例如,PECompact默认跳过它们.此外,关于"正在加载的所有内存",这是真的,但如果未使用并且需要在其他地方使用,那么内存将被分页.在某些情况下,它会产生更快的负载,因为存储介质(通常是HDD)的开销较低,并且所有内容都"立即"加载并且"已经存在".所以,也有例外,并且每个人都有自己的例外.免责声明:我是PECompact的作者. (4认同)
我同意你的Damon,那么问题就变成了 - 你的应用程序是否会运行多个实例？这是我一直警告过的警告之一.当然,代码部分通常都很小 - 看看我们正在讨论的尺寸与今天的系统相比.我认为更多的内存往往会在MOST应用程序中动态分配. (3认同)
Jeremy：共享部分不像实际代码部分那样有问题。代码通常是内存映射读-执行，这意味着如果你启动 10 个程序，它们都将使用相同的、相同的物理内存页面，并且物理数据只从磁盘加载一次。操作系统还可以丢弃包含从未被调用过的代码的页面，如果它的内存不足，知道它总是可以从图像中轻松地重新加载它们。来自 exe 打包程序的代码不是这种情况，相应的页面必须由交换文件支持。 (2认同)

Answer 2

Oli*_*sen 19

我很惊讶这还没有被提及,但使用UPX打包的可执行文件也增加了从启发式反病毒软件产生误报的风险,因为统计上很多恶意软件也使用UPX.

UPX不是为了保护.只是打包. (2认同)
完全同意.在Free Pascal,我们每年会得到一些这样的报告(发行版中的一个或另一个二进制文件会触发一些avirus).然后我们经常停止上行. (2认同)

Answer 3

小智 13

有三个缺点:

整个代码将在虚拟内存中完全解压缩,而在常规EXE或DLL中,只有实际使用的代码才会加载到内存中.如果每次运行时只使用EXE/DLL中的一小部分代码,这一点尤其重要.
如果您的DLL和EXE的多个实例正在运行,则它们的代码无法在实例之间共享,因此您将使用更多内存.
如果你的EXE/DLL已经在高速缓存中,或者在非常快速的存储介质上,或者你正在运行的CPU速度很慢,你将会遇到降低的启动速度,因为仍然需要进行解压缩,而你不会从缩小的尺寸中受益.对于将重复调用多次的EXE尤其如此.

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

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

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

Answer 4

Jim*_*eth 10

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

至于防止篡改,它也是一个失败.UPX也支持解压缩.如果有人想要修改EXE,那么他们会看到它是用UPX压缩然后解压缩它.您可能放慢速度的可能破解程序的百分比并不能证明这种努力和性能损失是正确的.

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

使用不在本地硬盘上的文件时,大小也很重要.就像在网络共享或外部硬盘上一样. (3认同)
尺寸与USB记忆棒有关.便携式应用程序是一个有意义的案例. (2认同)
鉴于目前多 GB 内存的价格，我也不确定尺寸是否重要。当然，除非您要存储高清视频。 (2认同)

Answer 5

Gre*_*ill 5

如今，磁盘上可执行文件的最终大小在很大程度上无关紧要。您的程序加载速度可能快几毫秒，但一旦开始运行，差异就无法区分了。

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

+1 我总是对打包的可执行文件/DLL 持怀疑态度，尤其是当我无法解压缩它们时。 (2认同)
Docker 容器中的大小很重要。 (2认同)

归档时间：	16 年，9 月前
查看次数：	18897 次
最近记录：	9 年，7 月前