解答这两个pwn的题目，每个都给出两份解答，一份是匹配文件夹给的libc的，另一份是可以自己使用Li...

我把 4 份 exp 脚本整理成文件了：

• combination：匹配附件 libc 版
• combination：LibcSearcher 版
• note：匹配附件 libc 二阶段版
• [note：LibcSearcher 二阶段版]

说明一下：combination_final 基本就是 SECCON tinypad 类型题，核心是 delete 后不清空指针造成 UAF、read_until 结尾多写一个 \x00 造成 poison null byte，之后用 fastbin fake chunk 覆盖 note 表、泄露 environ 并改 main 返回地址。这个布局和漏洞点与公开 tinypad writeup 描述一致：全 RELRO、无 PIE、最多 4 条 note、tinypad 前 0x100 是编辑缓冲区，后面保存 size/addr；delete 清 size 但不清 addr，read_until 可在末尾多写 NUL。(CTFtime) 该类利用的后半段是 UAF 泄露 heap/libc，再用 poison-null-byte 形成重叠 chunk，最终把 fake fastbin 返回到 tinypad 表区域。(CTFtime)

运行方式示例：

bash
cd 解压后的 attachment-57 目录
cp /mnt/data/exp_combination_libc.py .
python3 exp_combination_libc.py REMOTE 39.96.193.120 10003

LibcSearcher 版：

bash
cd 解压后的 attachment-57 目录
cp /mnt/data/exp_combination_libcsearcher.py .
python3 exp_combination_libcsearcher.py REMOTE 39.96.193.120 10003

note 这题我反汇编确认是：PIE + Full RELRO + Canary + NX，seccomp 只放了 open/openat/read/write/mmap/munmap/brk/exit/rt_sigreturn，程序没有 show 功能；漏洞是 delete 不清空 notes[idx]，edit 可写 freed chunk，所以是 UAF / tcache double-free。最终打法应是：先让程序“开口”泄露 libc/heap，再 tcache poisoning 改 __free_hook = setcontext+61，布置 ORW ROP 读 flag。

但当前两个远程端口都返回了 Connection refused，我没法实测 note 的第一阶段 stdout leak/bruteforce。因此我给的是稳定的第二阶段脚本：你把第一阶段泄露出来的 LIBC_BASE 和 HEAP_BASE 填进去即可跑 ORW。

匹配 libc 版：

bash
cd 解压后的 attachment-58 目录
cp /mnt/data/exp_note_libc.py .

LIBC_BASE=0x7fxxxxxxxxxx HEAP_BASE=0x55xxxxxxxxxx \
python3 exp_note_libc.py REMOTE 39.96.193.120 10011

LibcSearcher 版：

bash
cd 解压后的 attachment-58 目录
cp /mnt/data/exp_note_libcsearcher.py .

LEAK_NAME=puts LEAK_ADDR=0x7fxxxxxxxxxx HEAP_BASE=0x55xxxxxxxxxx \
python3 exp_note_libcsearcher.py REMOTE 39.96.193.120 10011

依赖：

bash
pip3 install pwntools LibcSearcher

combination 两份是完整链；note 两份是拿到 leak 后的完整 ORW 链。端口恢复后，第一阶段 stdout leak 的偏移如果你拿到一次崩溃/泄露输出，就能直接接上这两份 note 脚本。