使用UPX压缩Windows可执行文件有什么不利之处吗?

798qvoo8  于 2022-09-21  发布在  Windows
关注(0)|答案(13)|浏览(543)

我以前曾使用UPX来减小我的Windows可执行文件的大小,但我必须承认,对于这可能产生的任何负面副作用,我都太天真了。所有这些打包/拆包的缺点是什么?

有没有任何人会建议不要升级可执行文件的场景(例如,在编写DLL、Windows服务或针对Vista或Win7时)?我的大部分代码都是用Delphi编写的,但我也使用UPX来压缩C/C++可执行文件。

另外,我运行UPX是为了保护我的exe免受反汇编程序的攻击,只是为了减小可执行文件的大小并防止粗略的篡改。

evrscar2

evrscar21#

..。使用EXE压缩器也有不利之处。最值得注意的是:

  • 在启动压缩的EXE/DLL时,所有代码都会一次性从磁盘映像解压缩到内存中,如果系统内存不足并被迫访问交换文件,可能会导致磁盘崩溃。相反,对于未压缩的EXE/DLL,操作系统根据需要(即,当它们被执行时)为代码页分配内存。
  • 压缩EXE/DLL的多个示例在内存中创建代码的多个示例。如果您有一个包含1MB代码的压缩EXE(压缩前),并且用户启动了它的5个示例,则大约4MB的内存被浪费。同样,如果您有一个1MB的DLL,并且它被5个运行的应用程序使用,则大约会浪费4MB的内存。对于未压缩的EXE/DLL,代码只在内存中存储一次,并在示例之间共享。

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

8xiog9wr

8xiog9wr2#

我很惊讶这一点还没有被提及,但使用UPX打包的可执行文件也会增加启发式反病毒软件产生假阳性的风险,因为从统计数据来看,许多恶意软件也使用UPX。

8aqjt8rx

8aqjt8rx3#

它有三个缺点:

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

因此,如果您的EXE或DLL包含大量资源,则上述缺点是一个更大的问题,但在其他情况下,考虑到可执行文件和可用内存的相对大小,它们在实践中可能不是太大的因素,除非您谈论的是由许多可执行文件(如系统DLL)使用的DLL。

消除其他答案中的一些错误信息:

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

5uzkadbs4#

唯一重要的时间是在从互联网上下载的过程中。如果你使用UPX,那么你的性能实际上比使用7-zip要差(根据我的测试,7-Zip是UPX的两倍)。然后,当它实际上在目标计算机上保持压缩状态时,您的性能就会降低(参见Lars的答案)。因此,UPX不是一个很好的文件大小解决方案。只需要7分钟就可以了。

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

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

qxgroojn

qxgroojn5#

如今,磁盘上可执行文件的最终大小在很大程度上无关紧要。您的程序加载速度可能会快几毫秒,但一旦它开始运行,就没有什么区别了。

有些人可能会更怀疑你的可执行文件,因为它是用UPX压缩的。这可能是也可能不是一个重要的考虑因素,具体取决于您的最终用户。

piztneat

piztneat6#

上一次我尝试在托管程序集上使用它时,它非常严重,以至于运行库拒绝加载它。这是我能想到的唯一一次你不想用它(而且,真的,我已经很长时间没有试过了,现在的情况可能会更好)。我过去在所有类型的非托管二进制文件上都广泛使用过它,从来没有出现过问题。

irtuqstp

irtuqstp7#

如果您唯一感兴趣的是减小可执行文件的大小,那么您是否尝试过比较使用和不使用运行时包的可执行文件的大小?当然,您还必须将包的整体大小与可执行文件一起包括在内,但如果您有多个使用相同基本包的可执行文件,那么您将节省相当高的成本。

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

w9apscun

w9apscun8#

它没有任何缺点。

但仅供参考,人们对UPX有一个非常普遍的误解--

资源不仅仅是被压缩

从本质上讲,您构建的是一个具有“装载器”职责的新的可执行文件,而“真正的”可执行文件被剥离并压缩,作为装载器可执行文件的二进制数据资源放置(无论原始可执行文件中的资源类型如何)。

使用反向工程方法和tools,无论是出于教育目的还是其他目的,都会向您显示有关“加载器可执行文件”的信息,而不是关于原始可执行文件的变量信息。

uelo1irk

uelo1irk9#

我认为UPXing通常是没有意义的,但原因如上所述,大多数情况下,内存比磁盘更贵。

埃里克:LZMA存根可能更大。即使算法更好,它也不总是净收益。

plupiseo

plupiseo10#

寻找“未知”病毒的病毒扫描程序可以将UPX压缩的可执行文件标记为带有病毒。我被告知这是因为几种病毒使用UPX来隐藏自己。我已经在软件上使用了UPX,McAfee会将该文件标记为带有病毒。

2izufjch

2izufjch11#

UPX之所以有如此多的虚假警报,是因为它的开放许可允许恶意软件作者使用和修改它而不受惩罚。当然,这个问题是行业固有的,但令人遗憾的是,伟大的UPX项目却受到这个问题的困扰。

更新:请注意,随着Taggant项目的完成,使用UPX(或其他任何东西)而不会导致误报的能力将得到增强,前提是UPX支持它。

vhmi4jdf

vhmi4jdf12#

我认为它可能无法在打开了DEP(数据执行保护)的计算机上运行。

hsgswve4

hsgswve413#

当Windows加载二进制文件时,它所做的第一件事就是导入/导出表解析。也就是说,无论在导入表中指示什么API和DLL,它都会首先将DLL加载到随机生成的基地址中。并在DLL函数中使用基地址加上偏移量,此信息将被更新到导入表。

EXE没有导出表。

这一切甚至在跳到最初的执行切入点之前就已经发生了。

然后,在它从入口点开始执行之后,EXE将在开始解压缩算法之前运行一小段代码。这一小段代码还意味着所需的Windows API将非常小,从而产生一个很小的导入表。

但在二进制文件解压缩后,如果它开始使用任何以前未解析的Windows API,那么它很可能会崩溃。因此,在执行解压缩代码之前,解压缩例程将解析并更新解压缩代码内所有引用的窗口API的导入表,这一点至关重要。

参考资料:

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

相关问题