UCTF2016 twi Writeup

阅读量    194584 | 评论 1

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

前言

该题目分类为REVERSE。最终目标是提交一个flag。

从题目来看,本题目应该是UCTF 2016中的题目,可能是由于笔者的搜索能力还有待提高,没有能够找到相关的Writeup。所以,本次只能自己摸着石头过河了。

题目下载地址:https://dn.jarvisoj.com/challengefiles/twi.70087b1e507aee08fc5c376a7b5ccc80

 

解题准备

验证下载正确性

基础信息分析

文件类型识别

可以看到,文件是Atmel AVR 8-bit 的ELF文件。

查看是否有隐藏信息

从binwalk的结果来看,应该没有什么隐藏的数据。

字符串分析

各位小伙伴看到这个是不是就已经跃跃欲试了啊。反正我当时是觉得前途光明,形势非常好。不是小好,而是大好。。。

环境准备

模拟器

笔者手头并没有Atmel AVR架构的板子,所以优先考虑使用模拟器。

经过搜索,发现了三款模拟器:

  • simavr
  • simulavr
  • qemu-system-avr

考虑到simavr在网络上得到了比较多的推荐,优先考虑使用之。

笔者的系统是Ubuntu 20.04 LTS on Windows 10 WSL。这三款模拟器都可以通过apt 直接安装。

sudo apt install simavr

安装成功后,可以执行一下,看看说明信息。在说明信息中,发现了–list-cores参数。我们一并来看一下simavr都支持哪些core。

调试器

有了模拟器,我们可以执行镜像了。接下来,需要调试工具。

sudo apt install gdb-avr

gdb这种神器想必大家已经用得出神入化,不用笔者这种小白啰嗦啦。

反编译器

考虑到笔者对版权的洁癖以及贫穷,IDA虽然强大,但也只能忍痛放弃。

其实Ghidra已然足够强大了,我们本次选择ghidra_9.1.2_PUBLIC_20200212作为逆向工作环境。

在Ghidra中Import 目标文件,AVR架构可以正常识别。之后进行自动分析。

可见镜像从地址0x000000开始。由于镜像没有任何symbol或者debug信息,此处可能需要手动按D来强制进行反汇编。细心的小伙伴可能已经发现,明明每个指令是两个字节,但是前面的地址并没有按照两个字节增加。。。

Atmel AVR架构

Atmel AVR 8-bit 是一个精简指令集架构。具体信息大家可以去网上找。信息还是不少的,必定Arduino就是采用这个架构的。

AVR 采用哈弗结构,指令、数据分开寻址。从上面的图,大家可以看到code地址。其实还有一个mem地址。来看下图:

好的,我们现在来讨论一下上面说的,code地址的增加步进不是2的问题。

可以看到,mem寻址是按照1个字节的步进增加的。这里涉及到AVR的寻址模式。mem是按照正常的方式寻址,而code是按照2个字节为一组寻址。也就是内存中的地址是PC * 2。

关于AVR 8-bit的寄存器,总体来说和一般RISC架构的大同小异。不过这里要注意寄存器的别名。比如 W、X、Y以及Z,这个几个是用来间接寻址的寄存器。由于寻址需要,所以他们是8个通用寄存器,分成4对,作为4个16 bit寄存器。

需要注意的是,在gdb中执行“i r”的话,并不会显示这几个寄存器。为了能更方便的获取这几个寄存器的信息,笔者还专门写了一段gdb脚本。。。

在实际操作中,需要准备一份AVR 8-bit的指令说明书。笔者搞到这个里面里面带广告,就不放出来了,大家自己找找吧。

 

尝试运行

运行镜像,最大的挑战在于如何选择机型。笔者认为,越简单的东西,越不容易出问题。出了问题,也可以更方便的排查,所以先选择了atmega8 作为目标机型。当然,最终机型的确定是在整个解题过程中,一点点确定的。题目中的twi其实指的就是单片机中使用广泛的TWI协议,所以比如0x53、0x21和0x23肯定是TWI相关寄存器。另外,根据程序逻辑,判断0x60 肯定不能是寄存器,而是内存区域。

解题成功后,再次进行实验,目前发现atmega8 和 atmega32 都可以作为目标机型。

执行命令:

simavr -t -m atmega8 –gdb twi.70087b1e507aee08fc5c376a7b5ccc80

执行gdb,并attach:

avr-gdb

target remote :1234

这里笔者遇到了问题。尝试设定断点,可是得到:

首先,断点失败。这个在我偶然ptype $pc的时候找到了答案。由于AVR是指令数据分开寻址,所以要设定断点,我们需要提供code地址而不是data地址。怎么提供呢?大家自己ptype $pc下试试吧。当然,也可以参照笔者编写的gdb脚本。

其次,为啥明明设定的是0x26,地址却变成了0x800026。因为我们提供的0x26被认为是数据,而被模拟器自动转换到了对应的内存区域。具体情况大家可以参照simavr的源代码。

那么执行、断点的问题都解决了,我们可以开始进行逻辑分析了。

 

逻辑分析

入口点

通过Vector表,我们可以找到入口点:

这个函数是我自己加的,默认分析完这里是个label。这段代码的作用主要是进行栈的初始化,并且将程序段的一些数据copy到data区域以及进行一些内存区域的初始化。

从本块代码,我们可以看到,SP被初始化为0x45f。

接下来,将我们关注的字符串”flag{“ copy到了0x60。当然,还有”success”和”fail” 等等。然后跳转到了函数:FUN_code_0002d3。

FUN_code_0002d3

这个函数里面逻辑还是挺多的。

嗯,顿时头大。到这里,笔者决定先跑起来看看。

寻找线索

运行起来,没有Log输出。(后来发现,偶尔会有”fail” 的log出来,应该是模拟器的问题。)

经过了几次c – CTRL_C  循环后,发现程序都停在这里:

接下来看看这里在干什么。注意,这里地址是0x240,需要换算成code地址:0x120。

经过一番痛苦的分析,笔者发现:这段逻辑是个延迟。没有发现任何side effect,纯纯的延时。嗯,那还能咋办,为了能够进一步分析,当然要干掉啊。

这里,干掉这个延时有两个办法:

  1. 直接修改镜像,把无关紧要的代码修改为 xx c0或者 xx cf 跳转指令。
  2. 在gdb中下套。

当然,考虑到解题也是以学习为目的,笔者两个办法都尝试了。这里贴一下gdb下套的方案:

细心的盆友们可能又要问了,这里pc的设定为啥是按照内存地址值呢?看下一gdb中pc的显示:

注意,虽然显示的时候是按照code地址显示,但是大家在使用$pc设定值和运算的时候,一定要用内存地址值哦。

FUN_code_00012d

我们继续寻找线索。在把那个大延时干掉之后,我们又来到了一个新的区域。仍旧是c CTRL_C 循环,位置比较固定:

根据地址,寻找逻辑。

看到笔者对函数的命名,大家应该明白这个是干啥的了。这里,看起来好像很轻松就识别到了这个函数的作用,可是是实际上,笔者因此损失了多少本来就不多的头发啊!而且,靠的是灵光一闪,突然有思路。在无数次进入这个函数,笔者满地打滚、狂薅头发的过程中,突然想到:看看这东西到底在输出啥吧。。。

于是,这个函数的名字就有了。

接下来,肯定是要找引用点啦。

success 与 fail

在Ghidra强大引用分析的帮助下,不到1秒就成功定位相关逻辑。这样一来,程序的大体逻辑基本清晰了。另外,这两个点都在FUN_code_0002d3函数中。这样,就可以通过这两个指令块,来向上逆推正确的逻辑路径了。

确定路径是逆向中比较基本的工作,这里不再赘述。

第一个分支点

其中,0x60中保存的字符串是:”flag{\0”。

进入函数,分析其逻辑。

由于生平第一次接触AVR架构,再次经过了满地打滚以及狂薅头发的分析之后,发现这个函数是在检查W所指向地址中的内容前的5个字节是不是等于”flag{”。

在这个时候,笔者还没想到TWI的真实意义。(原谅我对硬件的无知与迟钝),所以还以为程序运行到一定程度,会解密出flag放在内存中。于是,这里的解决方案是:将0x60的5个字节copy过来。。。虽然,结合谜底来看简直是蠢爆了,但是在最终解决问题阶段还是用上了,也算没白费劲儿。

 

(中式英语是伟大的!是她维护了文件编码的纯洁性。

— SimonTheCoder)

第二个分支点

接下来,来到LAB_code_00030a。

这段逻辑就比较容易理解了。在判断刚才那段内存中的0x26位置是不是”}”(0x7d)。

解决方案和上一个分支点的处理方法一致,你要什么,我就给什么。

数据处理函数

这里,涉及到两个函数(如图)。又是一番痛苦的分析之后,发现这两个函数一个是将flag{******}中的******(32个)向前移动5个字节,覆盖掉”flag{”。

另一个,将这32个字节作为hexstring转换为16个字节数据。

两个函数功能虽然简单,但是由于笔者对AVR不够熟悉,着实进行一番痛苦的分析。

最终分支

这个分支点是最后一个影响程序结果的分支点,也是最难搞的一个。

由于比较长,这里只截取了一小部分指令。这一大段逻辑,是用来对之前处理好的16字节数据进行校验的。注意是校验,而不是解密。

可以看到,最终是要判断R22和R10是否相当。根据逻辑,R10以及其它参与运算的寄存器的数据,都是从数据区域读出的固定值。而R22的基础值也是从固定数据中读出,与待验证的16个字节,经过运算后形成。

其中,负责提供算法复杂性的是FUN_code_00036c:

可以看到,大量寄存器参与了运算。并且还会进行mul运算。这么一段逻辑,估计要完全分析清楚估计要很长时间以及非常强大的精神力量。

另外,整段逻辑没有任何st指令。换言之,没有对内存进行写操作。这也就意味着,并不存在将数据解密后放在内存中的逻辑。笔者之前的猜测显然是错误的。

 

接受了这个事实之后,我们需要解决两个问题:

  • 用来验证的flag是如何加载到内存中的。
  • flag的内容为何。

再一次的 FUN_code_0002d3

为了解决之前的两个问题,重新回到 FUN_code_0002d3进行分析。

用来验证的flag是如何加载到内存中的。

考虑到镜像文件中并没有相关的数据,那么只有可能是来自于外部输入。查看了一下FUN_code_0002d3中的函数调用:

几个函数中,只有000062我们目前还没有接触过。查看一下代码:

其实,只要分析清楚这块逻辑,就没有必要再进行000062的分析了。首先,可以看到这是个循环。该循环每次从FUN_code_000062中获得一个字节,放进Z中。而Z此时,正指向待check区域的地址(也就是flag放的地址)。(这个可以从gdb和使用了R3R2赋值两个角度来验证。)

len(“flag{}”)+len(“32字节神秘字符串”) = 0x6 + 0x20 = 0x26,count也对上了。

当然,实际上还是对FUN_code_000062进行了分析的。

节选一段。从代码来看,该函数再操作寄存器。根据寄存器,搜索了一下,发现是TWI相关寄存器。至此,题目中的TWI的来由我们清楚了。

从而,我们可以确定,本题目在板子上真机运行的时候,可以通过TWI将flag输入到程序中。

flag的内容为何。

确定了数据的来源,那么接下来解决数据的内容。

通过之前对数据校验区域的分析,我们可以得到一下结论:

  • 算法非常复杂,短时间内难以完成你算法。
  • flag的核心是32字节的hex string,经过处理函数处理后,得到了16字节数据。
  • flag通过TWI 输入系统。

通过以上几个结论,再考虑到之前屏蔽掉的那个延时逻辑,那么解决方案就呼之欲出了,

出题人是在疯狂暗示我们:爆破。

 

PWN

既然考虑到了爆破,那么爆破的可行性如何?

  • 16*255 种可能,完全可以接受。
  • 延时逻辑已经被干掉。
  • 本来我们也不是通过TWI输入数据,相关函数可跳过,进一步节省时间。
  • 可以通过gdb脚本实现自动化。

既然可行,那么接下来相对就要简单了。

  • 通过断点下套,跳过耗时的逻辑。
  • 通过之前的copy  “flag{” 和写入 “}”来绕过分支点。
  • 自动生成测试数据,填充到flag区域。
  • 在check判定成功、失败节点上下断点,从而获取次测试结果。

具体实现,请参照:

https://gist.github.com/SimonTheCoder/7ead8ca45008386c500c3d4813e19ff2

脚本使用:

  • 启动模拟器
  • 启动gdb
  • source help.gdb
  • lk
  • pwn

 

总结

本次的题目可以说非常折磨人,但是非常有趣。如果不研究到最后,不太容易想到需要爆破。如果没想到要爆破,也就不明白为啥前面有个奇怪的延时。直到最后,所有的线索都串起来了,豁然开朗。不过,虽然题目解开了,但是失去的头发和爆的肝也找不回来了。

最后,感谢出题人设计出这么有趣的题目。感谢Jarvis OJ提供了这么一个方便、高效又有趣的平台。对开帮助笔者这样的小白学习知识、开阔眼界提供了巨大的帮助。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多