main() 是如何调用的？在 __libc_start_main() 中调用 main()答案

【问题标题】：How is main() called? Call to main() inside __libc_start_main()main() 是如何调用的？在 __libc_start_main() 中调用 main()
【发布时间】：2021-01-30 12:05:29
【问题描述】：

我试图理解在__libc_start_main() 中对main() 的调用。我知道__libc_start_main()的参数之一是main()的地址。但是，由于没有操作码 CALL 或 JMP，我无法弄清楚 main() 是如何在 __libc_start_main() 中调用的。在执行跳转到main() 之前，我看到了以下反汇编。

   0x7ffff7ded08b <__libc_start_main+203>:  lea    rax,[rsp+0x20]
   0x7ffff7ded090 <__libc_start_main+208>:  mov    QWORD PTR fs:0x300,rax
=> 0x7ffff7ded099 <__libc_start_main+217>:  mov    rax,QWORD PTR [rip+0x1c3e10]        # 0x7ffff7fb0eb0

我用 C 写了一个简单的"Hello, World!!"。在上面的程序集中：

在地址0x7ffff7ded099处的指令之后，执行立即跳转到main()。
为什么 MOV（到 RAX） 指令会导致跳转到 main()？

【问题讨论】：

标签： c reverse-engineering main disassembly libc

【解决方案1】：

当然，这些指令不是导致调用main 的指令。我不确定您是如何逐步完成这些说明的，但如果您使用的是 GDB，则应该使用 stepi 而不是 nexti。

我不知道为什么会发生这种情况（一些奇怪的 GDB 或 x86 怪癖？）所以我只是根据个人经验说话，但是在逆向工程 ELF 二进制文件时，我偶尔会发现 nexti 命令之前执行了几条指令打破。在您的情况下，它在实际的call rax 之前错过了几个movs 来调用main()。

您可以采取的补救措施是使用stepi，或者转储更多代码，然后明确告诉 GDB 设置断点：

(gdb) x/20i
    0x7ffff7ded08b <__libc_start_main+203>: lea    rax,[rsp+0x20]
    0x7ffff7ded090 <__libc_start_main+208>: mov    QWORD PTR fs:0x300,rax
 => 0x7ffff7ded099 <__libc_start_main+217>: mov    rax,QWORD PTR [rip+0x1c3e10]        # 0x7ffff7fb0eb0
    ... more lines ...
    ... find call rax ...
(gdb) b *0x7ffff7dedXXX <= replace this
(gdb) continue

这是我系统上的__libc_start_main() 调用main() 所做的：

21b6f:  48 8d 44 24 20          lea    rax,[rsp+0x20]               ; start preparing args
21b74:  64 48 89 04 25 00 03    mov    QWORD PTR fs:0x300,rax
21b7b:  00 00
21b7d:  48 8b 05 24 93 3c 00    mov    rax,QWORD PTR [rip+0x3c9324] 
21b84:  48 8b 74 24 08          mov    rsi,QWORD PTR [rsp+0x8]
21b89:  8b 7c 24 14             mov    edi,DWORD PTR [rsp+0x14]
21b8d:  48 8b 10                mov    rdx,QWORD PTR [rax]
21b90:  48 8b 44 24 18          mov    rax,QWORD PTR [rsp+0x18]     ; get address of main
21b95:  ff d0                   call   rax                          ; actual call to main()
21b97:  89 c7                   mov    edi,eax
21b99:  e8 32 16 02 00          call   431d0 <exit@@GLIBC_2.2.5>    ; exit(result of main)

前三个指令与您显示的相同。在call rax 的时刻，rax 将包含main 的地址。调用main 后，将结果移入edi（第一个参数）并调用exit(result)。

查看glibc's source code for __libc_start_main()，我们可以看到这正是发生的情况：

/* ... */

#ifdef HAVE_CLEANUP_JMP_BUF
  int not_first_call;
  not_first_call = setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf);
  if (__glibc_likely (! not_first_call))
    {
      /* ... a bunch of stuff ... */
      /* Run the program.  */
      result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
    }
  else
    {
      /* ... a bunch of stuff ... */
    }
#else
  /* Nothing fancy, just call the function.  */
  result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
#endif
  exit (result);
}

在我的例子中，我可以从反汇编中看到 HAVE_CLEANUP_JMP_BUF 是在编译我的 glibc 时定义的，因此对 main() 的实际调用是 if 中的调用。我也怀疑你的 glibc 就是这种情况。

【讨论】：

有趣...我不知道为什么我在反汇编中没有看到“CALL RAX”指令。
@Harry 我已经添加了关于如何让 GDB 显示更多行的说明。
是的，我现在看到“CALL RAX”回答了我的问题。奇怪的是 GDB 在使用“nexti”时会跳过一些指令......
"我经常发现nexti命令执行了好几条指令后才中断。" -- 这在x86_64 上几乎是不可能的，我从未见过这种情况发生（而且我整日调试）。 else 正在发生。
@EmployedRussian 我真的不知道如何解释这种行为真的......我知道这很荒谬，但是这发生在我之前......我可能不应该说“经常”，这是罕见的。这可能是我正在使用的GDB plugin IDK 的错误。不过我很感兴趣，为什么你说这在 x86-64 上是不可能的？这完全由硬件功能支持吗？