问题标签 [portable-executable]

我在术语上很少混淆。

作为链接器输入的文件称为Object File。链接器生成一个Image 文件，该文件又用作加载程序的输入。

我从“MS PE & COFF Specification”得到这个

Q1。图像文件也称为Binary Image，Binary File或简称为Binary. 对？

Q2。因此，根据上述术语，PE/ELF/COFF 是图像文件而不是目标文件的格式。对？但是http://www.sco.com/developers/gabi/latest/ch4.intro.html说

本章介绍目标文件格式，称为 ELF（可执行和链接格式）。目标文件主要分为三种类型。

• 可重定位文件包含适合与其他目标文件链接以创建可执行文件或共享目标文件的代码和数据。

• 可执行文件包含适合执行的程序；该文件指定 exec(BA_OS) 如何创建程序的进程映像。

• 共享对象文件包含适合在两个上下文中链接的代码和数据。首先，链接编辑器 [参见 ld(BA_OS)] 处理共享对象文件与其他可重定位和共享对象文件以创建另一个对象文件。其次，动态链接器将其与可执行文件和其他共享对象结合起来，以创建进程映像。

矛盾的是，他说目标文件和图像文件都是 ELF 格式，他根本没有区分目标文件和图像文件，而是通常将它们称为目标文件。是不是错了？

Q3。我知道PE源自COFF。但是为什么微软PE格式规范被命名为Microsoft Portable Executable《通用对象文件格式规范》。他们还支持COFF吗？如果他们，在哪个操作系统中？我以为PE很久以前就完全取代了COFF。

作为链接器输入的文件称为Object File。链接器生成一个Image 文件，该文件又用作加载程序的输入。

“ Microsoft Portable Executable and Common Object File Format Specification ”的简介

RVA（相对虚拟地址）。在图像文件中，项目加载到内存后的地址，减去图像文件的基地址。一个项目的 RVA 几乎总是不同于它在磁盘上文件中的位置（文件指针）。

在目标文件中，RVA 的意义不大，因为没有分配内存位置。在这种情况下，RVA 将是一个段内的地址（稍后在此表中描述），稍后在链接期间对其应用重定位。为简单起见，编译器只需将每个部分中的第一个 RVA 设置为零。

VA（虚拟地址）。与 RVA 相同，只是不减去图像文件的基地址。该地址被称为“VA”，因为 Windows 为每个进程创建了一个不同的 VA 空间，独立于物理内存。对于几乎所有目的，一个 VA 应该被认为只是一个地址。VA 不像 RVA 那样可预测，因为加载器可能不会在其首选位置加载图像。

即使读了这篇文章，我仍然不明白。我有很多问题。任何人都可以用实际的方式解释它。Object File请按照说明遵守&的术语Image File。

我所知道的地址是

• 在目标文件和图像文件中，我们都不知道确切的内存位置，所以，
• 汇编器在生成目标文件时计算相对于部分.data&的地址.text（对于函数名称）。
• 将多个目标文件作为输入的链接器会生成一个图像文件。在生成时，它首先合并每个目标文件的所有部分，并在合并时重新计算相对于每个部分的地址偏移量。而且，没有什么比全局偏移量更好的了。

如果我所知道的有什么不对的地方，请纠正我。

编辑：

在阅读了弗朗西斯的回答后，我很清楚什么是物理地址、VA 和 RVA 以及它们之间的关系。

所有变量和方法的 RVA 必须在重定位期间由链接器计算。那么，（方法/变量的 RVA 值）==（它与文件开头的偏移量）？一定是真的。但令人惊讶的是，它不是。为什么这样？

我通过使用PEView检查 了这一点c:\WINDOWS\system32\kernel32.dll，发现：

1. RVA 和 FileOffset 直到 Sections 的开头都是相同的。（.text是这个 dll 中的第一部分）。
2. 从.textthrough的开始.data，.rsrc到最后一个部分的最后一个字节 ( .reloc) RVA 和 FileOffset 是不同的。&第一部分的第一个字节的 RVA 也“总是”显示为0x1000
3. 有趣的是，每个部分的字节在 FileOffset 中是连续的。我的意思是另一个部分从一个部分的最后一个字节的下一个字节开始。但是，如果我在 RVA 中看到同样的情况，那么这就是一节最后一个字节的 RVA 和下一节的第一个字节之间的巨大差距。

我猜：

1. 所有，在第一个（此处）部分之前的数据字节.text实际上“没有”加载到进程的 VA 空间中，这些数据字节仅用于定位和描述这些部分。它们可以称为“元节数据”。

   因为它们没有加载到进程的 VA 空间中。术语 RVA 的使用也毫无意义，这就是RVA == FileOffset这些字节的原因。

2. 自从，

   • RVA 术语仅对将实际加载到 VA 空间的字节有效。
   • .text, .data, .rsrc,的字节.reloc就是这样的字节。
   • 0x00000PEView 软件不是从 RVA开始，而是从0x1000.

3. 我不明白为什么第三次观察。我无法解释。

我正在编写一个应该在 16\32\64 位系统上运行的小实用程序。我的旧实用程序通过将 16 位版本压缩为 32 位并/stub在 Visual Studio 2008 中应用开关（/STUB -MS-DOS Stub File Name）在 32 位和 16 位上运行。

我正在寻找一种对我的 64 位可执行文件执行相同操作的方法。目标 64 位系统是 Win PE 64 位，它没有安装 WOW64。

可能吗？

我在 EXE 标头中看到了一个奇怪的值

我不知道那里在A8做什么，但是如果我用零替换它，我的程序就不会执行。

一言以蔽之：那是什么？

另外，你能给我链接到完整的 MS DOS 标题吗？

在 Portable-Exe 中，有可能找到导入的部分，以及所有导入的 dll 名称（使用导入描述符）。在这里，一个应用程序 Exe 有许多导入的 dll（kernel32、advapi、user、comctl32 ....etc ），现在我想找到该应用程序exe（导入的dll）中的所有依赖项..给我使用递归函数调用的逻辑..

在这里，例如 notepad.exe，假设有两个 dll（advapi32，user32），我可以获取这些 dll 的详细信息，我想知道 advapi 和 user32 的导入 dll ....顺便说一下所有依赖项...你能给仅逻辑，对我很有帮助....谢谢

你好！

我有一个旧插件（作为二进制文件，dll），由我的应用程序使用。它是为WM2003构建的。现在，如果在Windows Mobile 6.1上加载，它会使应用程序崩溃（WM5可以正常工作，WM6也可以）。

源代码不可用，开发人员不再支持它。所以我不能为WM6.1重建它。

是否可以修补或转换二进制文件以使其在WM6.1上工作？如果是这样，我该怎么做？

谢谢你。

编辑：我发现问题出在 PE loader中，它在 WM6.1 上的作用不同（与 WM6 及更早版本相比）。

假设我已经将一个 PE 可执行文件加载到内存中，并使其与 dos、nt 标头结构相匹配，现在我想找出它的 .text/code 段实际（不是 VA）偏移量+大小我该怎么做？是否有用于查找 .text 起始偏移量的 win32 api，或者可能是来自指向该段起始偏移量的结构的指针

谢谢。

我想将默认.exe图标更改为 C/C++ 中的其他图标。有人知道该怎么做吗？

在ELF文件格式中，我们在aka中有一个Alignment字段。Segment Header TableProgram Header Table

在 Windows PE 文件格式的情况下，他们将其提升到下一个级别，Section 有两个对齐值，一个在磁盘文件中，另一个在内存中。PE 文件头指定了这两个值。

我对这种对齐方式一无所知。我们需要它做什么？如何以及在哪里使用它？同样，我不知道二进制文件格式上下文中的对齐是什么，但我们为什么需要它？

我用谷歌搜索了一下并阅读了http://en.wikipedia.org/wiki/Portable_Executable但我似乎无法找到何时写入导入地址表地址。编译时会发生吗？或者当可执行文件运行时？