ZIKH26's Blog

通过这道题的学习与总结：

1、rep指令是进行循环，movs qword ptr [rdi],qword ptr[rsi]则可以拷贝，二者结合就是可以大规模拷贝数据到另一个内存空间。而想实现它，仅仅只需要控制rdi和rsi以及rcx寄存器即可。

2、我们往可读可写可执行的内存中写入的任何机器码都是可以被当做指令来执行的，而想执行这些指令，仅仅用ret或者call跳转到这些指令所在地址即可（ret和call要的是指令所在地址，并非指令）

3、关闭标准输出，没有回显时，可以利用magic_gadget来去获取一些我们需要的函数。

4、开启沙箱并且三个文件描述符全关时（意味着orw读取的flag也无法看见），可以用socket+connect将flag发送到这个新开的文件上（毕竟close关闭的仅仅是当前终端的0,1,2)

总结：

通过这道题的学习与收获有：

1、学习了格式化字符串漏洞中的%s泄露函数地址原理以及roderick师傅写的Libcbox的用法（其实用法也很简单了），之后就没什么了直接ret2libc就打了。

2、这道赛题最后只有三解… 不过真的很简单，做出来的人很少的原因估计是因为这道题是比赛还有不到两个小时结束，才把正确的程序放出来（之前放的都是错误的…）。

总结

通过本题的学习与总结有:

1. 本题与starctf2018_babystack这题一样，考察的都是篡改TLS中的stack_guard从而绕过canary的检查，因为在2.23和2.27 32位的glibc里面主线程的TLS是位于mmap映射出来的内存，并且位置固定并不随机。而本题可以通过数组索引无限制，而在mmap映射出来的区域精准的修改某个内存，这就给了篡改TLS中的stack_guard的机会
2. 本题的难点在于之后绕过canary，无法正常的泄露libc地址，从而造成了一定难度，通过学习网上各位师傅的wp，发现本题一共有三种做法，分别是利用magic gadget篡改got表，ret2dl以及攻击IO_FILE。这里我采用的是利用magic gadget篡改got表

本题为一道经典的控制堆块的题目，对于这类题目通常的方法是将控制堆块申请出来当做用户堆块来使用，向其写入特定数据来篡改其中的函数指针。

总结：

通过这道题的学习与收获有：

1、atol函数放入的数据应该是打包之前的，而非是打包之后的数据

2、exit函数执行流程，exit函数的调用流程exit函数—>run_exit_handlers函数—>_dl_fini函数—> rtld_lock_unlock_recursive指针 如果我们能够将最后的指针所指向的内容修改为one_gadget，那么即可获取shell。这个劫持exit_hook的可取之处在于，程序正常结束的话，最后都会调用这个exit函数

3、学会了重新绑定程序所对应的libc动态库（patch libc和ld）

4、用这个方法可以在开了PIE的程序中下断点。gdb.attach(p, ‘b * $rebase(0xd63)\nc’)

5、one_gadget加上参数-l2可以搜索更多的one_gadget。

6、即使相同的libc库，在小版本不同的情况下，某些内容的偏移也是不一样的。

由于本人比较菜，同时学pwn的时间不是太久，因此iscc的很多堆还没有能力去做，只把比赛的栈题给做完了 赛后又做了一下unlink那道题。其他堆题目前还没有复现。（有一个格式化字符串太简单了，我就不写wp了）

本题考察了 unlink

写在前面：

在之前做这道题的时候SWPUCTF_2019_p1KkHeap,就受到了tcache dup+tcache poisoning来爆破申请tcache_perthread_struct结构体的启发，结果在做这道题的时候就遇见了这种手法。由于还需要打io_leak再次爆破半个字节，因此这种手法成功的概率只有1/256。

总结:

通过本题的学习，知道了malloc consolidate函数可以让fast bin的堆块进行合并，然后放到unsorted bin，同时将下一个堆块的prev inuse位置空。通过这一点给了我们利用unlink的机会,如果在2.23下我们可以利用UAF，那么即使没有溢出，也可以利用malloc consolidate让下一个堆块的prev inuse置空，最后在被合并的堆块里伪造一个fake chunk即可触发unlink。

总结

通过本题的学习与总结有：

1. 之前一直以为ret2libc必须得返回到原本的输入函数处，再次输入一次getshell。但有时候我们重新返回到原本的输入函数可能会出现一些问题，因此我们可以打一个栈迁移+rop执行read。就是先覆盖rbp为bss段上的地址，然后执行puts函数泄露libc，接着执行read函数往bss段上输入数据，最后执行leave ret完成栈迁移从而将执行流劫持到bss段上

2. 插入到栈里的canary是从TLS结构体中的stack_guard成员变量赋值过来的(而函数返回时，会将栈里的canary与TLS中的stack_guard做对比)。主线程中的TLS通常位于mmap映射出来的地址空间里，而位置也比较随机，覆盖的可能性不大；子线程中的TLS则位于线程栈的顶部(高地址处)，而这个子线程栈通常也是mmap映射出来的一段内存，这就给了我们栈溢出控制子线程中的TLS机会

3. TLS(Thread Local Storage) 线程局部存储。本身是一种机制，简单来说就是多个线程访问同一个全局变量或者静态变量可能会发生冲突，而这个机制类似于让每个线程都备份了一份全局变量或者静态变量，当前线程只能修改自己这份全局变量或者静态变量并不会影响其他线程的全局变量以及静态变量。

4. 在glibc实现中，TLS被指向一个segment register fs(x86-64上)，它的结构tcbhead_t定义如下：

   typedef struct { void *tcb; /* Pointer to the TCB. Not necessarily the thread descriptor used by libpthread. */ dtv_t *dtv; void *self; /* Pointer to the thread descriptor. */ int multiple_threads; int gscope_flag; uintptr_t sysinfo; uintptr_t stack_guard; uintptr_t pointer_guard; ... } tcbhead_t;

   而上面的stack_guard也就是放到栈里的canary，而在程序里看见的这行代码

   xor rdx, fs:28h中的fs寄存器也就指向了TLS这个结构体，而偏移0x28的位置正好是stack_guard,canary是来自于内核生成的一个随机数。

5. 最后要说一下这个子线程栈和父线程内存的关系。每个线程都会有自己单独的栈区，而子线程的栈区通常都是调用了mmap映射了一段内存。在父进程里我们依然可以看到这片内存

   阅读全文 »