我正在尝试一些安全性的东西,特别是试图理解ret2ret漏洞.我正在试验的代码:
void foo(char * val){
char buffer[64];
int i;
for (i=0; val[i]!=0; i++) buffer[i]=val[i];
return;
}
int main(int argc, char ** argv) {
foo(argv[1]);
return 0;
}
我的测试期间,ASLR,N ^ X和堆栈金丝雀都关闭了.我用gcc编译了32位.我不知道为什么,但我无法得到通常的"0x41414141 in ??()"说我覆盖了$ eip.所以我决定使用gdb进行调试,并在函数"cop"中对ret进行断点,奇怪的是,即使在写入超过300"A"之后,堆栈也是如此:
0xbffff46c: 0xb7ee2290 0xbffff496 0xb7e8f5f5 0x41414141
0xbffff47c: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff48c: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff49c: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff4ac: 0x41414141 0x41414141 0x41414141 0x00410043
对应缓冲区的64个字符在这里,但其余部分没有写入...我不知道为什么？是否由于某种更新？
编辑:buff的GDB日志[64]
Dump of assembler code for function main:
0x08048415 <+0>: push %ebp
0x08048416 <+1>: mov %esp,%ebp
0x08048418 <+3>: sub $0x4,%esp
0x0804841b …我正在关注一些关于格式字符串漏洞利用的教程，并且在某些时候他们谈论覆盖 dtors 表。但这是我在使用 nm 时发现的：
080495a8 d _DYNAMIC
0804969c d _GLOBAL_OFFSET_TABLE_
080484cc R _IO_stdin_used
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
08048594 r __FRAME_END__
080495a4 d __JCR_END__
080495a4 d __JCR_LIST__
080496bc D __TMC_END__
080496bc A __bss_start
080496b4 D __data_start
080483c0 t __do_global_dtors_aux (*)
0804959c t __do_global_dtors_aux_fini_array_entry (*)
080496b8 D __dso_handle
08049598 t __frame_dummy_init_array_entry
w __gmon_start__
080484aa T __i686.get_pc_thunk.bx
0804959c t __init_array_end
08049598 t __init_array_start
08048440 T __libc_csu_fini
08048450 T __libc_csu_init
U __libc_start_main@@GLIBC_2.0
080496bc A _edata
080496c0 A _end
080484b0 T _fini …