type
status
date
slug
summary
tags
category
icon
password
Week 1随便乱搞的shellcodeWeek 2stack_migrationshellcode revengeWeek 3puts or system?ezorwsropdlresolveWeek 4Doubleezheapgod of change
newstarctf 2023是我觉得难度比0xgame要小，但是相对应的，它的广度要更大一点，每一道题目都是比较容易进行payload的，但是就是题目的类型非常非常多，导致我现在都还做不完
Week 1
随便乱搞的shellcode
收获：
- 使用rjust将命令放在一串地址的最后部分，前面填充
\x90：这个是一个nop指令，意思就是什么都没干
Week 2
stack_migration
收获：
libc.sym["system"]直接就是system函数的地址，不是相对位置
shellcode revenge
syscall调用read很容易，在执行syscall这个命令时，只要满足以下条件即可：
RAX= 0RDI= 0RSI= 要写入的地址RDX= 很大的数
相当于执行了
read(RDI,RSI,RDX)，你就可以往RSI这个地方写很多数据。
其中，RAX是函数的调用号，没有这个，syscall不知道你要调用什么函数。以下是64位系统调用表：https://blog.csdn.net/SUKI547/article/details/103315487
以上是两个和汇编相关的网站
收获：
- 学会了怎么直接用二进制机器码来构造
shellcode，特别是在针对限制了输入范围的情况下，通过搜索上面两个网站可以得到相关的机器码
- 主要是通过
xor来进行值的赋予，我们先从gdb中可以知晓当前的寄存器情况，发现是可以满足一个read函数的形式的，然后我们通过0x4e^0x41=0xf0x44^0x41=0x5将\x4e\x44\x4e\x44变成了\x0f\x05\x0f\x05（注意，这里的0f 05就是syscall的字节码）
- 我们通过这份payload将
eax变为0，将其余寄存器保存后直接进行syscall即可，进行read函数输入就没有字符的限制了，就可以直接进行shellcode注入
- 有一个疑问就是连续两个
syscall真的没有影响吗？但是确实是正常运行了，也没有输入第二次
Week 3
puts or system?
ezorw
在无法找寻二进制文件
ROP的情况下，可以使用libc的ROP，只要知晓libc基地址，就可以将其ROP进行使用orw 这个词，意思是指“open、read、write”这三个函数的组成。意思就是用这三个函数来将系统中的文件泄露出来在二进制程序被禁用了
exec系统调用（称之为被sandbox，我也不知道为什么），在这个情况下是无法使用system('/bin/sh') 的，因为system函数是会使用exec系统调用的，所以我们只能使用其他方式来进行flag的找寻shellcraft 模块，在我们想要写出orw函数的shellcode的时候，可以用shellcraft 模块构造，它生成了相关的汇编代码，然后我们使用asm() 函数，将这个汇编代码变成了二进制机器码，输入进拥有执行权限的srop
dlresolve
Week 4
Double
这是一道很基础简单的UAF类型题，也可以说是fastbin poisoning
主要是由于有UAF的漏洞，导致可以和fastbin dup联合。这种题只需要通过修改fastbin中的fd指针，即可完成对任意地址写的实现
步骤：
- free，但是有UAF所以我们可以改fd指针
- 改fd指针，bin中多了一个我们想要任意写的地址
- malloc，得到这个地址的chunk
- 写入content
即可完成，很简单
ezheap
很经典的一道heap题，考察的是UAF
它是一个具有管理chunk的系统，add、edit、delete函数如下：
不能用poisoning的原因是因为edit函数有条件判断，必须要和一个chunk数组（这个数组是用来进行存储对应的chunk的大小）中的size相等，才能进行edit
我们发现上图中free函数只free了管理块，没有free内容块，这点可以被利用。
当我们free掉两个管理块时，如果我们在malloc一个和管理块相同的大小chunk时，就可以直接将一个管理块变成我们的内容块，这样就可以进行一开始的修改
为什么这样就可以绕过edit函数的检测了呢？因为可以在edit的时候将我们的新内容块（原管理块内容修改，将其头部对应size大小，然后再通过原管理块进行其指针修改
说起来很抽象难懂，举例子说明
一开始我们申请三个块
然后删除两个块
就会得到
可以看到我们第4个内容块的chunk就是第一个管理块
意思是我们更改第4个内容块就是把第一个管理块内容改了
然后将第一个管理块前面三个字节覆盖后，就能得到第一个内容块的地址，这个地址是mmap获取，所以可以泄露出libc地址
然后使用edit函数，参数是第4个块，由于size也没变，所以可以更改，将第一个内容块的地址变成free_hook，同时把头改为第一个块的大小，方便修改free_hook指向。再使用edit函数，参数是第1个块，将free_hook的函数指向system
然后再找个管理块改成/bin/sh，进行free就好了
god of change
这道题让我理解了unsorted bin的用法，这个bin我确实之前有点看得不是很懂，这个题涉及了一点unsorted bin的用法，还有一点关于chunk的fd和bk指针的获取技巧
这道题只有3个功能，add、del和show
同时程序保护全开
我们可以发现add函数中其实是有off-by-one的，所以是可以更改后一个chunk的大小，实现overlap。
但是我们发现这个show函数其实是要看另一个叫做byte的数组，这个数组标记heaparray中是否存在，哪怕我们更改了下一个chunk的头，将它释放成unsorted bin，也是不能show出来的（我就是卡在这里）
然后看wp才知道，原来在存在unsorted bin的情况下，后续申请的小chunk是直接从unsorted bin中切割出来的，这样的话我们后续申请的chunk的开始两个8字节头都是存在main_arena的，这个技巧真好
剩下的就是直接用__free_hook了
exp如下