ret2libc25.12.11附件 目录

在想要调用的函数没有被调用过，想要调用他的时候，是按照这个过程来调用的 xxx@plt -> xxx@got -> xxx@plt -> 公共 @plt -> _dl_runtime_resolve 到这里我们还需要知道 _dl_runtime_resolve 是怎么知道要查找 printf 函数的 _dl_runtime_resolve 找到 printf 函数地址之后，它怎么知道回填到哪个 GOT 表项 第一个问题，在 xxx@plt 中，我们在 jmp 之前 push 了一个参数，每个 xxx@plt 的 push 的操作数都不一样，那个参数就相当于函数的 id，告诉了 _dl_runtime_resolve 要去找哪一个函数...

看到文件开启了NX保护 有一个fgets函数 去看看有没有什么能用的 没有/bin/sh ida里面找了找也没有system 题目给了libc.so文件，属于第三类的ret2libc 再看看libc.so文件 这个是system的地址，这个和ida找到的不一样，先用这个试试 这个是libc_start_main 的地址，不知道有没有用先搞下来 这里又有了/bin/sh 现在有些问题是没有学pwntool咋用，好消息是好像什么都给了 payload构造: 我们要做的只是把binsh传进system里 那么先溢出，再传system，/bin/sh然而不行 libc会有栈对齐的要求,要ret 改为先溢出，再ret，再pop一个rdi，再...

from pwn import * local_file = './pwn' local_libc = './libc-2.31.so' remote_libc = './libc-2.31.so' select = 1 if select == 0: r = process(local_file) libc = ELF(local_libc) else: r = remote('node5.buuoj.cn',27019) libc = ELF(remote_libc) elf = ELF(local_file) context.log_level = 'debug' context.arch = elf.arch def...

payload: padding1 + address of system() + padding2 + address of “/bin/sh” padding1 处的数据可以随意填充（注意不要包含 “\x00” , 否则向程序传入溢出数据时会造成截断） 长度应该刚好覆盖函数的基地址 padding2 处的数据长度为4（32位机），对应调用 system() 时的返回地址。 因为我们在这里只需要打开 shell 就可以，并不关心从 shell 退出之后的行为，所以 padding2 的内容可以随意填充。 p64(elf.got['puts']): 参数1 - puts函数的GOT表地址 p64(elf.sym['puts']):...

system 在Linux中，system()函数调用后，传入的参数（如"/bin/sh"字符串地址）通常存储在RDI寄存器中。