main() 是如何调用的?在 __libc_start_main() 中调用 main()
How is main() called? Call to main() inside __libc_start_main()
我试图理解 __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()
?
当然,这些指令并不是导致调用 main
的指令。我不确定您是如何逐步执行这些说明的,但是如果您使用的是 GDB,则应该使用 stepi
而不是 nexti
。
我不知道为什么会这样(一些奇怪的 GDB 或 x86 怪癖?)所以我只是根据个人经验说的,但是当 reverse-engineering ELF 二进制文件时,我偶尔会发现 nexti
命令在中断之前执行几条指令。在您的情况下,它在实际 call rax
调用 main()
.
之前错过了几个 mov
s
您可以采取的补救措施是使用 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 的 __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 就是这种情况。
我试图理解 __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
. 的指令后立即跳转到 - 为什么
MOV
(到 RAX) 指令导致跳转到main()
?
main()
当然,这些指令并不是导致调用 main
的指令。我不确定您是如何逐步执行这些说明的,但是如果您使用的是 GDB,则应该使用 stepi
而不是 nexti
。
我不知道为什么会这样(一些奇怪的 GDB 或 x86 怪癖?)所以我只是根据个人经验说的,但是当 reverse-engineering ELF 二进制文件时,我偶尔会发现 nexti
命令在中断之前执行几条指令。在您的情况下,它在实际 call rax
调用 main()
.
mov
s
您可以采取的补救措施是使用 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 的 __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 就是这种情况。