（1）线程调试：

（2）TLS（线程局部储存）：防止当一个线程卡死后对其它线程对全局变量或该函数内的static变量的使用产生影响，会在该线程开始时，拷贝一份全局变量和static变量到TLS段。线程的TLS段一般和栈段挨得很近

（3）线程题的canary比较：线程题的canary是把栈段的canary和TLS段的副本进行比较，所以要绕过canary的话，可以将栈段和TLS段的canary均覆盖成相同的值

（4）系统调用

（5）aoti函数

atoi (表示 ascii to integer)是把字符串转换成整型数的一个函数，应用在计算机程序和办公软件中。int atoi(const char *nptr) 函数会扫描参数 nptr字符串，会跳过前面的空白字符（例如空格，tab缩进）等。如果 nptr不能转换成 int 或者 nptr为空字符串，那么将返回 0。特别注意，该函数要求被转换的字符串是按十进制数理解的。atoi输入的字符串对应数字存在大小限制（与int类型大小有关），若其过大可能报错-1。

（6）open函数

参数一：表示打开文件的目录
参数二：表示打开文件的方式（0是只读）
功能，打开参数一所指向的文件并向rax寄存器返回fd指针

（7）getdents64函数

参数一：fd指针
参数二：写入的内存区域
参数三：4096
功能：把当前文件目录下的文件名写入参数二指向的内存区域

（8）OGW

是对使用open、getdents64、write函数（或系统调用）将目录中的文件名读入指定区域的简称

（9）ORW

是对使用open、read、

（10）沙箱保护

有些题目可能会用沙箱的prctl函数或者seccomp函数来静止使用一些系统调用
可以用seccomp-tools dump ./file_name看查

（11）泄露进程地址

网上百度了一下才知道pthread_create和pthread_join的作用

所以重点在运行的test_thread函数

发现可供读入的数据很长，所以想到栈溢出，但是函数列表里面没有后门函数，所以考虑泄露libc基址然后执行shell函数

溢出什么呢？先gdb看看栈上吧

发现了一个栈上存了一个栈地址0x7ffff7d9b700，且这个地址和其它地址的偏移是固定的。那么我们就可以泄露这个地址，根据固定偏移，就能得到可执行文件内存中存放的一个ibc库函数的got表地址（这里我选的是在main函数栈中存放的__libc_start_main函数）从而泄露libc基址

然而，如果泄露了libc地址，随意胡乱覆盖就能覆盖到返回地址的话，那你真的是小看了chuj学长

var_4是变量i在栈中的偏移，如果直接覆盖，会对i的值有所影响。后果就是要么i的值大于4095提前结束，要么覆盖到一个很远的位置。

如何解决？

覆盖的时候合理一点，这就需要个人调试，也是一道不错的练io和gdb的题

比第一题多了一个canary

main函数和第一题一样

发现也是多了一个canary

那就要思考如何绕过这个canary了

（1）相较第一题多进行一次thread_test函数泄露canary，然后在最后一次填入泄露的canary绕过然后溢出至shell函数

不行：由于canary的低字节为'\x00'，要想用puts函数泄露必须要补上非'\x00'的字符，但这样无法还原canary，会触发保护机制

（2）猜想canary是个伪随机数

离谱：如果真的是，为啥还有那么多小可爱尝试爆破

在网上搜素（2）的过程中，发现了TLS这个东西（也就是开篇的那个知识（2）），于是就有了一个还算正常的思路

覆盖canary和TLS的stack_gurd的值相同，进行绕过然后到达shell

在尝试了构造ROP链调用system函数还有onegadget不行后，询问chuj学长得知，还有最后一条路没有走——系统调用

最后走通了

还是很疑惑前两个为啥走不通

听chuj学长说应该是dtv指针被修改了

main就不看了，也是个线程，直接看线程函数

memcmp不像strcmp，不会触发'\x00'截断机制

还好，write函数也不像puts函数同样不会被截断

所以思路已经很清晰了，先用gdb调调看，看s2所指的字符长啥样然后将buf置为相同

利用write函数打印canary，然后用gets函数直接ret2backdoor

发现cp那段很可以，复制到百度康康，然后得知是head指令后面生成了随机数，于是自己复制了head后面一大截跑了下

发现是一个长度为20的字符串，猜测flag是变成了flag+这长度为20的随机数

那就需要泄露了，一开始没有啥头绪，想到了ls好像有这个功能

就百度了一下ls的实现

于是就学到了系统调用getdents64[挂一下博客] https://blog.csdn.net/cnbird2008/article/details/11629095

发现if比较的时候用到nbytes的类型是int64，而read的一个无符号数

所以可以考虑把nbytes置为一个负数，绕过if的同时保证了read的充足输入

显然read是读不完的（至少都要读2^31个数据）

所以我们需要截断read的读入

由于read函数是读到EOF或者'\n'截止的，所以直接用sendline即可

这样我们就可以ret2ROP了

这道题的ROP我分成三个部分：泄露libc并返回main、OGW、ORW（OGW和ORW我放在”学到的知识“里面了，就不赘述）

由于OGW和ORW中间调用的打开目录是字符串"./“和”flag+20个随机数字符“

熟悉c语言的师傅应该知道，”字符串“本质上是一个地址，open和getdents64函数的目录参数也是地址

所以我们需要用read函数在中间穿插将字符串读入bss段

好家伙，比美国经济大萧条时期的股票还绿

可以看出是标准的spfa求多源最短路，由于曾经是oier，就特别入迷，能看懂但是找不到洞

切换为pwn手，发现dist[v6],v6没有范围限制，结合招新赛浩哥那道secret，就能知道这是一个任意地址读

和做浩哥那道题一样，我们直接看汇编

可以发现，rax就是我们输入的v6*8

已经有了任意地址读，那么我们希望有任意地址写的功能

从function_list也能看出已经有后门函数了

看着这个c艹的反汇编，我还真的看懂了，但其实只要知道dist这个数组，它又可以被修改就好了

修改的值是输入的边权

所以如果想修改dist+v5*8的位置，连一条源节点向这个位置的边，就可以覆盖这个位置的为边权

所以，我们如果想把main_ret的值修改为back_door，就可以这么做

至此，我们做到了伪任意地址读写

为啥是伪，因为开了pie，地址是随机的，所以需要泄露地址

需要泄露libc的和进程的基地址，泄露进程基地址很容易理解

泄露libc是为了用symbols表获得栈地址的相对偏移从而泄露

所以思路很清晰了，用两次任意地址读分别泄露libc、进程的地址

再用一次，泄露stack地址

最后用任意地址写，修改main_ret为back_door

但真的行吗？（指上一句）

gdb里发现会被对齐卡死

这里就要有一个技巧了

我们直接绕过push指令，直接ret2backdoor+5，就能对齐了

（1）/proc/self/mem

（2）tcache bin

（3）glibc 2.31版本的fastbin stash，unsorted bin UAF

（4）字符串格式化漏洞(这个直接写在另一篇博客了)

（5）realloc函数

就是一道盲打题，但是好像没有学到啥........

就练了练IO

好家伙全绿，意思是要leak

很标准的增删秀

怎么打呢？

首先利用unsorted bin进行uaf leak libc，但先需要填满tcache

由于tcache的key检测，我们需要先填满tcache然后在fastbin double free

在fastbin里double free的时候，若tcache此时为空，通过stash机制会自然把fastbin的chunk放入tcache，自然绕过了对size的检测

double free修改__free_hook为system,同时将fake_chunk的前一个add的chunk的content置为'/bin/sh'

那么原来free(pre_chunk_content_address)就变为system('/bin/sh'）了

很经典的保护，地址随机化+不能修改got表

从printf函数能够看出存在字符串格式化漏洞

看到了reallo函数就知道可能是需要修改__free_hook来实现shell

如何修改就需要我们的fmt了，这个在博客里写得很清楚就不再赘述了

原理： 利用unsorted bin的头和尾的bk或fd指针指向的是main_arena，而main_arena虽然不在libc.sym中 但是和libc里其它函数的sym表的偏移是固定的，于是可以间接泄露libc基地址 分为两种： （1）free之后堆指针（严格来说是数组里存的每个堆的content段的指针即malloc返回值）不清空： 那敢情好啊，直接show就好了 （2）free之后堆指针清空，那么我们可以尝试合并堆块到unsorted bin，通过调用进行切割，使得数组上存的 堆块是unsorted bin，间接达到uaf

堆定位：在堆合并的时候（记堆块指针为p，包含size和pre_size），需要知道合并的是哪个堆。这种定位主要依靠pre_size(向低地址合并)和size（向高地址合并）来实现。位于低地址的就是p-pre_size,而高地址是p+size

堆合并：再定位后会对定位的堆块和原堆块进行合并操作，合并有个重要环节就是unlink，修改部分如下：

乍一看就是链表的删除嘛 ，但是这其中其实有很大的漏洞，假如我们伪造一个堆块，其BK->fd为我们想修改的内容（如__malloc_hook）,而fd放上修改的值（如system），那么其实是可以做到任意已知地址修改的

但是这种利用手段在上古的glibc2.23版本就迎来了安全检查，比较精髓的就是会检查BK和FD是否合法(大致如下)：

然而还是有其它手段可以利用，这个利用直到2.31都没修改，具体在（4）中可以看到

size严格检查：没看源码，看别的师傅的博客学到的。如果是低地址合并的话，会检查合并的chunk的size段和准备free的chunk的pre_size段是否相同，以及pre_insure是否为0

我们知道，edit函数是直接修改数组上存的指针指向的地址，如果我们可以修改数组上存的指针，那么就能够直接通过edit修改自己想修改的地址。具体是通过unlnk把数组上存上数组的地址（一般是数组首地址，chunk的index一般是3）。此时调用edit（3）即可修改数组上的指针

unlink利用的实现：

在数组上指针为p的chunk里构造fake_chunk,fake_chunk->fd=p-0x18,fake_chunk->bk=p-0x10,并且修改高地址的chunk的pre_size和size能够通过检查。那么绕过在unlink的检查的同时，FD->bk=p=p-0x18(这就是为啥选index3使得为首地址)

通过unlink等手段修改free函数的got表为put函数的plt，数组指针ptr上存任意函数的got表,那么free(ptr)就相当于put(got)，即可泄露libc

有的题的读入是read+atoi，如果我们能够修改atoi的got表为system，read的是‘/bin/sh\x00’，那么就可以调用后门

有些时候one_gadget会集体失效，这就需要我们修改栈帧实现它对[rsp+]==NULL的匹配，使用realloc函数是个不错的选择，因为开头有大量的push，并且有一个call rax的操作（这个rax是realloc hook，realloc hook和malloc hook离得非常近），那么我们就可以修改malloc hook为realloc，并且沿途修改realloc hook为one_gadget

如果*chunk=malloc(0x68)，那么我们实际可以写入的大小是0x68,因为可以利用下一个chunk的pre_size段

这篇博客(12条消息) off by null 小结_ch3nwr1d的博客-CSDN博客写得挺好的，例题也是一个经典的模板题。

2.23

发现没有show函数，结合保护的partial relro,就可以选择使用unlink修改free函数的got来调用put函数泄露libc。同时读入是read+atoi，那么同样可以在数组所在地址上修改atoi的got为system，read进'/bin/sh\x00'即可get_shell

这题有个小坑就是edit的content的读入是用gets函数实现的，gets函数有个特性，就是会在读入的字符末尾补一个'\x00'，我们修改freegot的时候，如果直接发p64()的话，会覆盖后面函数的地址（实测函数是puts函数）,导致报错。可以通过发小端字或者p64()[:-1]解决

2.23

发现有一个show函数，且free不会把指针置为NULL，那么就可以通过unsorted bin uaf 泄露libc

知道了libc以后就是经典的fastbin double free了，修改malloc hook 为onegadget，但4个都不行，那么就用realloc抬栈

2.27

发现free以后会修改指针，没办法使用常规的double free和uaf

跟进edit和add：

发现有个off_by_null

那么思路就很清晰了，通过off_by_null实现chunk合并进入unsorted bin ，然后调用切割使得unsorted chunk的地址为数组上存的地址，再show（）即可泄露libc了

泄露libc之后，我一开始想的是常规double free即

但是不行的，因为free以后指针会清空，第二次delet(0)就相当于free(0)了

我们发现，当tache无free时，unsorted bin存在free的堆块，那么下次申请就会从unsorted bin 里切割一块下来，且是unsorted chunk的首地址，而我们已经做到首地址在数组里了，再申请一次，并free，就会把这块chunk放入tcache里面，而我们可以通过edit数组上保留的它的地址修改其fd指针为_free_hook。 此后再申请两次即可修改 __free_hook了

我们发现edit里面有两个连续的发送，中间不能通过recv隔开。然而向read函数sendline是个大忌，会出现各种各样的问题，但是两个send会连续发送。我的解决方法是利用time模块下的sleep函数，实现延迟发送:

双重否定表肯定的文学大师ida

曾经用c++搞oi的时候，遇到过一些鬼火代码：

当时就在想:

不过现在转pwn了，会遇到不少c艹的题，而且以后搞Windows和浏览器都有用所以就学了一下：

std:: 是个名称空间标示符，C++标准库中的函数或者对象都是在命名空间std中定义的，所以我们要使用标准函数库中的函数或对象都要使用std来限定。

这样做的原因：

是因为像cout这样的对象在实际操作中或许会有好几个，比如说你自己也可能会不小心定义了一个对象叫cout，那么这两个cout对象就会产生冲突。

为啥俺之前没写过捏，因为只需要这样：

这些已经刻进DNA的写法过了快4年俺才知道背后的原因，所以说要知其所以然

c++常被称为面向对象编程，就是因为它的一个核心功能——类，通过类可以封装一些标准库之外的功能比如自定义的函数和重载运算符。有点像python的module（貌似只有public才类似，privite和protect不太一样），大致用法如下：

这个网站写的很详细，就不赘述了，给上面的代码加个重载加法的功能：

vector在中文里是向量的意思，它也符合向量从起点向一个方向无限延长的性质

相较于数组需要规定大小，vector可以在push_back或者resize的时候，当超过容器容量上限的时，内部自动分配新的内存和内存空间并同时释放原空间，这样可以十分合理地处理未知输入量的问题

释放和分配好像用的是STL的allocator，源码没怎么仔细看。size（）、end()、begin()、capability（）的实现主要依赖三个迭代器（指针），随便搜搜就能搜到，蓝勾不想写

谈谈做题的经验，对于下面这个vector：

gdb里通过符号表访问notes指向的空间，存的是三个迭代器的值，再访问notes即可看查容器里存的值

主要的难点在operator，回顾前面写的重载加法，有一个发现，如果将operator换成‘+’号前面一个变量，“（参数）”换成第二个变量就完全说得通了。同样，把operator换成第一个变量（通常是后面的括号里从左到右的第一个参数），那么再代入就很好理解了。

习惯了

主要看看move_note，其它都和原来的堆题差不大多，delete保证了不能使用uaf

核心部分大概自己写的话是这个样子的：

漏洞是在notes.resize（）和下面的指针修改

notes.resize()会造成vector扩容,并把原来的数据复制到一个新的内存地址,但是*i还是原来的内存上的堆块地址,那么我们就可以故意选择一个比较大的index,引起扩容,从而使得新的内存地址上有两个相同的堆块.

有两个相同的堆块,那么我们就可以触发unsorted bin uaf泄露libc地址,然后fastbin bin double free 和fastbin stash进tcache修改free_hook触发后门函数

摸了一上午，下午有个团建就溜了，老打比赛不认真了

（1）大堆块使用vmmap分配内存，可以gdb里跟进查看地址

2.31 9_2 (和ubnutu20.4的版本不一样。。)

用ghidra可以发现存堆块的指针使用mmap函数申请的，可以用gdb下断点查看

没有限制堆块的申请大小，并且没有初始化指针，可以leak libc和heap

没有对idx为负数的检测，会造成整型溢出

由于note（存堆块指针的数组）是用mmap映射的，heap过大也会用mmap映射，那么可以申请一块较大的堆块使得它与note相邻。利用整型溢出就可以double free，然后fastbin stash就可修改free_hook为system get_shell

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课