在压缩的 PE 中，数据部分的虚拟大小必须与原始大小相匹配吗？答案

【问题标题】：In a compressed PE must the virtual size of the data section match the raw size?在压缩的 PE 中，数据部分的虚拟大小必须与原始大小相匹配吗？
【发布时间】：2012-12-04 22:44:22
【问题描述】：

在使用具有 4 个字节的文件对齐和节对齐的压缩 PE（Windows 控制台 EXE）时，我注意到如果节的虚拟大小和原始大小匹配，则程序加载，但如果虚拟大小为数据部分（最后一部分）不匹配，然后 Windows 拒绝加载它，即使按照规范，您应该能够拥有大于原始大小的虚拟大小。

这是对压缩 PE 的某种隐藏约束吗？

我已经在下面粘贴了一个 exe 的 dumpbin /headers：

Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file ba42x.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               2 number of sections
        50AABC14 time date stamp Mon Nov 19 18:09:08 2012
               0 file pointer to symbol table
               0 number of symbols
              60 size of optional header
             10F characteristics
                   Relocations stripped
                   Executable
                   Line numbers stripped
                   Symbols stripped
                   32 bit word machine

OPTIONAL HEADER VALUES
             10B magic # (PE32)
            2.03 linker version
             BD0 size of code
            5000 size of initialized data
               0 size of uninitialized data
              CC entry point (004000CC)
              CC base of code
             C9C base of data
          400000 image base (00400000 to 00403FFF)
               4 section alignment
               4 file alignment
            4.00 operating system version
            0.00 image version
            4.00 subsystem version
               0 Win32 version
            4000 size of image
              CC size of headers
               0 checksum
               3 subsystem (Windows CUI)
               0 DLL characteristics
           10000 size of stack reserve
            1000 size of stack commit
               0 size of heap reserve
               0 size of heap commit
               0 loader flags
               0 number of directories


SECTION HEADER #1
   .text name
     BD0 virtual size
      CC virtual address (004000CC to 00400C9B)
     BD0 size of raw data
      CC file pointer to raw data (000000CC to 00000C9B)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
E0000020 flags
         Code
         Execute Read Write

SECTION HEADER #2
   .data name
    3102 virtual size
     C9C virtual address (00400C9C to 00403D9D)
    3102 size of raw data
     C9C file pointer to raw data (00000C9C to 00003D9D)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0000040 flags
         Initialized Data
         Read Write

  Summary

        3104 .data
         BD0 .text

例如，如果您将上述 .data 部分的虚拟大小更改为 3106，则程序将不会加载，即使初始化数据 (0x5000) 的大小足以容纳额外的内存。

【问题讨论】：

Pericin 和 Vuksan 指出，对于平面内存模型（又名低对齐模式），所有物理地址都需要与其对应的物理地址匹配。也许这就是 virtualsize 和 rawsize 也需要匹配的原因？ sebug.net/paper/Meeting-Documents/hitbsecconf2012ams/…（见幻灯片 25）
我的处境相似：尝试手工制作有效的 PE 图像文件。你解决问题了吗？

标签： c windows linker executable portable-executable

【解决方案1】：

不，没有与压缩图像相关的特殊限制，因为只要您的图像符合 PE，加载程序就不会关心压缩。压缩由存根处理，而不是加载程序。

您能否提供您的图片以供进一步分析？

只看dumpbin的输出，图像看起来很不寻常..根本没有目录，很奇怪。看起来加载器的问题与对齐没有直接关系，而是图像文件的格式错误。您是否尝试使用其他 PE 工具（例如 PeStudio、CFF Explorer..）查看您的图像文件？

【讨论】：

我将如何提供图像？我对 PEStudio 和其他工具的体验是，它们毫无价值，因为它们不使用与 Windows 加载程序相同的逻辑，因此不能依赖它们来验证 PE。通过“压缩图像”，我的意思是 PE 标头从偏移量 4 开始，并且 e_lfanew 在偏移量 x35 处与 PE 文件对齐 (=4) 结合。在此设置中，代码部分和入口点从 xCC 开始。问题是我无法让加载程序接受任何虚拟部分，甚至是初始化部分中的虚拟空间，我不知道为什么。
这里提到的工具是静态分析工具。它们本身确实不使用与加载器相同的逻辑，因为它们不执行与加载器相同的任务（执行动态活动......）。
好的，通过“压缩”图像，您的意思是“缩小”图像，而不是通常意义上的压缩（混淆，压缩 - UPX 等......）。对吗？
正确，通过在未使用的区域上尽可能紧密地覆盖部分和标题进行压缩。在标准 PE 中，有很多空白空间或不必要的数据，例如 DOS 存根。您可以将这个空间用于您的程序并制作更小的二进制文件和图像，特别是如果您使用 4 字节而不是 4096 字节等非标准对齐方式。
我会对图像感兴趣，因为我是 PeStudio 的作者，想测试它是否可以承受（不崩溃，识别）“不合规”图像...:-)