据我所知，在 PE 文件中，虚拟大小显示了在加载过程中为节分配了多少空间，而原始大小显示了该节在磁盘上的大小 .
我遇到了这个可执行文件，它执行了以下操作：
它从原始数据大小（ offset 0x10 ）中减去虚拟大小（ offset 0x8 ），并确保有一些空间（例如100个字节） . 在文本部分 Headers 的偏移 0x14 处，它在文件中找到了该部分本身的偏移量 . 它添加了虚拟大小，找到该部分在文件中结束的位置 . 它复制了一些shellcode（最后跳转到可执行文件的原始入口点以确保原始可执行文件运行）到二进制文本部分的末尾 .
现在我对此感到困惑，如果虚拟大小显示将为可执行文件分配的确切空间，则不会在 .txt 末尾添加代码覆盖可执行文件的其他一些数据并使其崩溃？谢谢 .
2 回答
嗯，这个黑客代码似乎是为了隐藏各部分之间的恶意代码 .
回答你的问题，你是对的VirtualSize是真正在内存中分配的空间，RawSize是磁盘上用来保存段数据的空间 . 您错过的是（来自MS PECOFF规范）：
这意味着 if a the result of SizeOfRawData-VirtualSize is positive we have some space available on disk actually filled with 0's .
如果该空间足以容纳恶意代码，然后使用
VirtualSize在磁盘上添加文本开头部分，则可以获得可用于复制代码的0的填充区域的开头 .剩下的就是故事......
这是一个很好的问题，并说明了Windows加载程序如何计算内存大小的一个非常重要的观点（或者你可能会说是怪癖） .
PE / COFF规范确实将VirtualSize描述为“加载到内存中时节的总大小” . 如果您认为total是包含该部分的REAL数据的总量，那么这在技术上是正确的，但它不是Windows为该部分分配的内存总量 . 您会发现VirtualSize通常比Windows为内存中的部分分配的数量少，因为VirtualSize必须四舍五入到最近的内存对齐值（在PE映像中设置） .
换句话说，VirtualSize表示节的未包围大小，而SizeOfRawData是图像文件中数据的大小，但向上舍入到最近的文件对齐填充值 . 这就是为什么VirtualSize更好地表示数据的真正“原始”大小，在内存或磁盘上 . PE / COFF规范没有做出这种区分 . 为什么一个在图像文件中被舍入而另一个可能在其向后兼容性方面具有古老的根源 .
这正是您的shellcode使用VirtualSize查找数据的“真实”结束的原因，即使它位于图像文件中也是如此 . 毫不奇怪，您可以通过将VirtualSize四舍五入到文件对齐的值来计算SizeOfRawData，至少在格式良好的PE文件中 .
shellcode只是使用VirtualSize来查找REAL代码的结尾 . 在那里和SizeOfRawData字节之间，只是未使用的填充零，使其成为添加新代码而不影响文件大小或破坏PE文件中的寻址偏移的主要位置 .
总之，Windows加载器基本上采用VirtualSize值并将其四舍五入到内存对齐值，以获得内存分配的实际大小（甚至可以将其四舍五入到最接近的4k最小内存页） . 然后将SizeOfRawData字节从文件复制到内存部分的开头 . 如果它小于内存中节的大小，则余数为零 .