winapi - PE 101 windows api调用地址的解释

Question

我正在尝试构建一个程序，该程序将提供有关文件以及可能的反汇编程序的更多信息。我看了https://code.google.com/p/corkami/wiki/PE101以获得更多信息，读了几遍后我就理解了其中的大部分内容。我不明白的部分是 windows api 的调用地址。例如，他怎么知道指令调用 [0x402070] 是对 messagebox 的 api 调用？我了解如何计算字符串的地址，并且对字符串的 2 个推送命令有意义，但 dll 部分则不然。

我想我想说的是我不明白“导入结构”的部分 (我用黄色画了一个框的部分)如果有人可以向我解释一下 0x402068 如何指向 exitProcess 和 0x402070 如何指向 MessageBoxA，这真的会对我有帮助。谢谢

Answer 1

Loader(Windows操作系统的一部分)在启动示例程序之前“修补”导入地址表(IAT)，此时才是库的真实地址过程出现在内存位置 0x402068 和 0x402068 中。请注意，导入位于 simple.asm 的 nobits 部分:

section nobits vstart=IMAGEBASE + 2 * SECTIONALIGN align=FILEALIGN

加载后导入的部分从虚拟地址开始 (IMAGEBASE=400000h)+2*(SECTIONALIGN=1000h)=0x402000 。

该示例的 yasm 源非常不寻常，该图也不是学习PE 格式的最佳位置。请首先阅读Wikipedia:Portable_Executable首先(一篇短文)。它有指向 full documents 的链接，所以我在这里只做一些简短的笔记。

您可能还想使用 Cheat Engine检查 sample 。启动 simple.exe，然后使用Cheat Engine附加到进程，按内存 View ，然后菜单工具->剖析PE header ，然后按信息按钮，查看导入选项卡。在内存转储中，转到地址 00402000 (CTRL+G 00402000 Enter:

00402068: E4 39 BE 75 00 00 00 00 69 5F 47 77 00 00 00 00 6B 65 72 6E 65 6C 33 32 2E

记下这些位置的值

• 00402068:0x75BE39E4(在我的计算机上)= KERNEL32.ExitProcess 的地址
• 00402070:0x77475F69(仅在我的情况下)= user32.MessageBoxA 的地址

请注意它们后面的文本“kernel32.dll user32.dll”。现在查看 simple.exe 的十六进制转储(我将使用 Far Manager )并在字符串 "kernel32.dll user32.dll" 之前找到相同的位置。里面的值有

0000000450: 69 74 50 72 6F 63 65 73 │ 73 00 00 00 4D 65 73 73  itProcess   Mess
0000000460: 61 67 65 42 6F 78 41 00 │ 4C_20_00_00 00 00 00 00  ageBoxA L
0000000470: 5A_20_00_00 00 00 00 00 │ 6B 65 72 6E 65 6C 33 32  Z       kernel32
0000000480: 2E 64 6C 6C 00 75 73 65 │ 72 33 32 2E 64 6C 6C 00  .dll user32.dll

• 0000000468: 0x0000204C — dw 0;db 'ExitProcess', 0 的相对虚拟地址
• 0000000470: 0x0000205A — dw 0;db 'MessageBoxA', 0 的相对虚拟地址

加载到内存后，加载程序已更改了文件中的这些值。 Microsoft 文档 pecoff.doc 对此进行了介绍:

6.4.4. Import Address Table The structure and content of the Import Address Table are identical to that of the Import Lookup Table, until the file is bound. During binding, the entries in the Import Address Table are overwritten with the 32-bit (or 64-bit for PE32+) addresses of the symbols being imported: these addresses are the actual memory addresses of the symbols themselves (although technically, they are still called “virtual addresses”). The processing of binding is typically performed by the loader.