因为某原因，最近要看看ctf。

angstromctf2023早在4月就结束了。今天打开一看，诶，还能访问。那就下载下来做一做。

另外，搜到了一个youtube视频专门讲这个比赛的wp，下面的记录，以及pwn环境（docker）很多参考了这个视频。毕竟菜。

I just learned about stacks and queues in DSA!

太久没做pwn题了，来看一眼。

调试的时候输入：AAAAAAAA.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p.%p

看一下打印结果：

栈里数一下：

验证一下：

Multipart challenge!

Note all use essentially the same Dockerfile. The flags are split among all three challenges. If you are already a pwn expert, the last challenge has the entire flag.

先看一眼Dockerfile，仍然需要flag.txt

根据打印提示，看看win0函数。如下，直接打印flag：

那就简单了，Canary啥的都关了，最简单的ret2text。就不调试了，根据IDA的注释，偏移等于0x40+0x8=0x48，先用这个写exp，有问题再说。

和gaga0基本一样，只不过在外面加了个if(a1 == 4919 || a2 == 16705)。简单，直接把main的ret覆盖成if判断后的地址0x401269：

exp修改如下：

然后执行后失败了，gdb调试，找到问题所在。如下图，前面覆盖ret的时候没关注rbp，直接覆盖成aaaaaaaa。而在这里会用到rbp，非法地址导致crash：

解决办法就是将rbp覆盖成一个可读可写的地址。gdb调一下，在可读可写的地址里随便选一个，比如0x404100

最终的exp如下：

这次没有“后门函数”了，查看一下保护机制：

关了PIE，开了NX，不能ret2shellcode，那就rop吧。以前一直用ROPGadget/one_gadget这些工具，这次试试pwntools里的rop模块。要说的都在注释里了，看代码吧：

结果如下：

以前都是在虚拟机里做题，如果调试，直接gdb.attach(p)就ok了。现在在docker里调试，步骤如下：

1、进入tmux

2、python脚本：context.terminal = ['tmux', 'splitw', '-h', '-F' '#{pane_pid}', '-P']

3、python脚本：gdb.attach(p)

4、执行python脚本

pwnlib.gdb.attach(target, gdbscript='', exe=None, gdb_args=None, ssh=None, sysroot=None, api=False)

pwnlib.gdb.attach - API介绍

计算栈中变量距离ret可用两个API：cyclic(num)和cyclic_find(string)。

最终还是调了一下gaga0：

可以看到main函数的返回地址被覆盖成了0x6161617461616173，对应的字符是：saaataaa。

打印结果看到是0x48

Dockerfile如下：

该程序运行在Ubuntu22环境中，同时又有flag.txt。

开启了Canary和NX，PIE是关闭的。

简单扫几眼main函数，最后调用win函数，点进去一看，功能是打印flag:)。所以大概就是让想办法使程序能走到最后。首先找前面有没有程序结束点，其他看注释吧。

看完代码，思路就清晰了：s和v9都指向堆块，两chunk连续，且v9在s上方（地址更低）。很明显，绕过if判断有两种方法：1）利用溢出修改chunk s，然后输入s2的时候溢出的内容；2）利用溢出泄露chunk s的内容，然后输入s2的时候输入泄露的内容。

if判断之后还有一次输入，这次输入能随意？不行，需要利用这次输入修复chunk s的size，不然执行到free的时候你就会发现，ptmalloc2会检查chunk的size：打印double free or corruption (out)，并导致程序退出。注意循环100次。

I seem to have lost my gadgets.

关闭了Canary（栈溢出覆盖ret简单多了）和PIE（不用泄露地址了），开启了NX。

函数列表里又有win函数。

理一理思路：

1、利用栈溢出覆盖main函数的ret为win函数中开始读flag.txt的地方。

2、看看读flag.txt的地方会不会使用到rbp，如下面的代码，是会的。

找个可读可写的地址：

这个过程中没有其他阻碍了，非常简单，格式化字符串漏洞也没用到。exp如下。

这道题用到了proof of work，在上面 exp 的注释中记录了相应的接收发送代码。

还有另一种解法，第一次溢出的时候，利用格式化字符串漏洞泄漏libc地址，然后ret覆盖为printf("Amount: ");的地址，绕过called的限制；第二次溢出的时候，ret覆盖为rop链地址，拿到shell，最后cat flag.txt。

这有个问题，libc地址怎么泄漏？栈里应该有libc的地址，那么利用格式化字符串漏洞可以泄漏出来。而且这个地址应该和libc基址的偏移应该是不变的。于是，通过gdb计算出这个偏移，然后泄漏出地址，再一算就能拿到libc基址了。

所以，偏移是0x7ff82fb37a37 - 0x7ff82fa23000

exp如下：

Join the ångstromCTF slack!

该题运行在Ubuntu22的环境中

这是模拟一个聊天软件？有一个机器人提醒你一些事情？有三次输入的机会。保护全开。

循环3次，每次都能触发同一个格式化字符串漏洞。

保护全开，这里也只有格式化字符串漏洞，那就只能想办法覆盖ret了。

1）覆写ret，那首先需要泄漏出栈里存放ret的地址

2）然后，覆盖为rop链的地址，那还需要泄漏出libc基址

所以总体思路：

1）泄漏栈和libc的地址

2）覆写ret为rop链的地址

首先，想要通过格式化字符串漏洞泄露栈上的内容，一般都会在输入时敲很多%p，但是注意，这里的每次输入最多14Byte。所以为了方便查看结果，以及不用敲那么多次输入，用脚本：

执行两次，结果如下：

接着，用gdb确认一下这两个index是否是stack和libc的地址，并计算偏移：

ret_addr - some_stack_addr = 0x7ffc8fb1e328 - 0x7ffc8fb1c190

libc_base_addr - some_libc_addr = 0x7f35e31bf000 - 0x7f35e33df6a0

验证之后，毛有问题。

还有两次触发机会。接下来需要把一个rop链的地址写到main_ret_addr里，也就是要把一个大数（8字节）写入到某个地址，那这需要一个字节一个字节写。还是那个问题，输入长度有限，不能一次性写长的payload，而现在触发printf的机会也只剩两次了。那可以修改局部变量i为一个负数来增加循环次数，从而增加触发printf的机会。

要覆写i为一个负数，首先来看一下i的地址：

那么泄露i的地址：

结果如下：

对于整型变量i来说，其内容为4个字节，

要将其值变成负数，最简单的方法就是把最高的一个字节变成0xff（256）。

很明显，输入空间不足以支撑。需要另想办法，如下图。

一步一步来，先来看看循环第二次时，call printf时栈的情况：

因为上面stack命令的结果中，序号是从0开始的，所以，选择的第一个地址的偏移是 0x13+1+5=25，第二个地址的偏移是0x31+1+5=55：

为什么%25$hn改变的是0x7ffe2770a8dd，而不是0x7ffe27708fa8？

因为%n对应的参数是个地址，比如：printf("testtest %n\n", &c);

这里%n对应的参数就是&c，而上面的例子中，对应的参数就是0x7ffe27708fa8，改变的内容自然就是0x7ffe2770a8dd了。

对应脚本如下：

结果如下，确实变成了一个绝对值很大的负数：

同样因为输入长度限制的原因，覆写main_ret的方法和覆写i的方法一样：

注意sa 和 sla 的问题，见注释。

My code had a couple of pesky format string vulnerabilities that kept getting exploited...I'm sure it'll fix itself if I just compile with RELRO and take away output...

题目说明很清楚，存在格式化字符串漏洞，但是使用 RELRO 进行编译并删除了输出。

注意做题环境，这道题的环境是debian@sha256:98......，我一开始用ubuntu22做题，调试的时候执行到fprintf过不去，会崩掉。

Dockerfile如下：

有源码，先看看源码。如下所示，两次输入，然后输出不再是给stdout，而是给了/dev/null

fprintf函数原型：

关闭Canary，RELRO是Full RELRO。

这道题没有输出，也就不能泄露地址了。利用思路参考上一题，不过区别是本题利用%*c来修改栈里存储的某个指针的低4字节（为什么是4字节？见下面），使其指向存储main_ret的地方。

星号在 printf 格式化字符串中的作用是用于指定动态宽度或精度。在输出字符串时，星号可以通过传递另一参数（ int 类型）的方式动态定义输出的宽度或精度。测试格式化字符串中 * 的作用：

gdb调试，输入AAAAAAAA.%p.%p.%p.%p。

和上一题一样，在栈里找一个存储了栈地址的地方，算出其偏移（fprintf格式化字符串参数之后的第几个参数）

偏移：

如果选[2]这个偏移，格式化字符串可以这样写：

在上面调试记录中，fprintf第三个参数vararg是0x7ffc6faf3460，所以%*c对应的整型值是0x6faf3460。所以，发送payload后，会将地址0x7ffc6faf3588里的内容0x7ffc6faf4f0c改成0x7ffc6faf3460。

而我们的目的是将地址0x7ffc6faf3588里的内容改成存储main_ret的地址，因此还需要计算0x7ffc6faf3460和addr(main_ret)的偏移：

其实这里有个隐含要求，就是addr(main_ret)需要大于vararg，因为我们只能在vararg低4Byte的基础上再加字符，好在题目里是满足的。

修改格式化字符串:

下面调试查看结果：

0x7ffe48560ed8对于fprintf函数来说，是格式化字符串参数后的第42个参数。

现在第42个参数已经改成了main_ret的存放地址，那么接下来就是将其改成gadget的地址。

现在栈里找一个距离libc地址近的地址，第16个参数就可以：

再看看它和one_gadget之间的偏移是多少：0xa4a91

这里选的是第三个gadget，因为main函数返回前将rsi和rdx清零了，满足第三个gadget的constraints：

输入下面的格式化字符串，先打印第16个参数低4字节（0x0b7e57cf）个字符，然后打印674449个参数，最后它两之和（也就是one_gadget真实地址的低4字节）覆写第42个参数的低4字节，即将main_ret（0x7fa20b7e5d0a）修改为one_gadget的地址，最终拿到shell。

回顾一下格式化占位符（format placeholder）的语法：

%[parameter][flags][field width][.precision][length]type

不是每次都能成功，调试过程中我发现有时候输入以后，它会把第13个参数改成一个不知道是什么的数字。这时候我会重新输入%*c%13$hn，然后多试几次就ok。所以如果写成python脚本，也是用一个死循环来多试几次：

After the sailors were betrayed by their trusty anchor, they rewrote their union smart contract to be anchor-free! They even added a new registration feature so you can show off your union registration on the blockchain!

智能合约，不会，正打算学这个。后面再补这题吧。

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

上传的附件：

• noleek.rar （3.26kb，4次下载）
• queue （16.02kb，3次下载）
• slack.rar （3.57kb，3次下载）
• widget.rar （3.01kb，3次下载）
• leek.rar （3.54kb，4次下载）