HITCTF2022{4311254395e7d3cf0b372d95b58325674d6117}

HITCTF的reverse方向总体都不难，由于是WIn32并且没有考察ollvm，主要考察方向有shellcode、动态加载、字符串混淆、花指令、驱动IO控制等一系列偏向于RW的技巧和知识点。这些知识点出现在很多流行恶意代码中，例如ransomware。

笔者稍微有一点恶意代码分析的经验，对本题目在比赛时已经还原的八九不离十，然而在最后一分钟判断奇偶时出现头昏行为把A、C判断为奇数导致没有提交flag。最后遗憾的没有苟到前十。但是题目本身已经吃透了，在这里把本题目的flag获取过程详细的给出，供参考。

一如既往，本Writeup会延续以前Writeup的风格，将按照解题的思路和顺序，对题目的考察点详细解释，可用于新手入门，但是会显得比较冗长。已经有基础的师傅可以略看，因为大部分时间我都在解释我如何看到这一点和解释我的解题思路

拿到题目，例行对题目进行格式和壳检查。拖入die，可以发现题目为32位控制台程序，未加壳。

因此拖入IDA32进行初始观察。IDA32在载入之中没有遇到麻烦，打开main函数首先看到IsDebuggerPresent

熟悉反调试的师傅可能会对这个IsDebuggerPresent进行跳patch过操作，但是我们先不急，先对整个题目做整体检查。

先看到第一个函数，其中包含了字符串give me your flag: here???和%s，似乎这个是要求输入的提示符。于是在这里我们打开程序：

可以看到提示字符串并不符合，这可能是个假输出，或者就是在哪里对字符串进行了修改。另外，我们注意到在退出程序的时候程序有延迟，并不是丝滑的点击关闭按钮程序就退出了，而是程序需要等一两秒才退出。这引起了我们的怀疑，记在小本本上。

回到IDA，这一函数的返回值是9，赋给了dword_426388。

继续向下看，观察到两个函数，这个函数使用了刚才被赋值的dword_426388：

这个函数中包含了两个可疑的部分。图中标出了。分别是对参数的偏移和解引用。这种操作一般代表这个参数是一个结构体指针。但是目前还没有确认这是什么指针，先记在小本本上。接下来是一个SM3的常量。SM3是中华人民共和国政府采用的一种密码散列函数标准，由国家密码管理局于2010年12月17日发布。本质上SM3是一种密码散列函数，可以粗浅的理解为一种类似于SHA-2的算法。

于是这个函数sub_4011F0就是我们一会儿要关注的一个点。我们接着继续查看main函数，在尾部看到最后一个函数sub_401320在这里我们看到了老朋友sub_4011F0，证实了上面的猜测。

接下来，我们注意到下面的switch块中存在两个常量。熟悉Windows开发的同学应该对这两个异常的十六进制值比较熟悉，它们分别是断点和拒绝访问错误。为什么题目在这里安置了这两个异常作为if的条件并且在其中安插了很像debug_maze题目名中maze所指的迷宫的操作呢？我们也把这个东西记在小本本上。

至此，main函数分析结束。

别急，到这里有经验的师傅还会检查TLS函数。TLS 回调函数的调用运行要先于 EP 代码的执行。它是各线程独立的数据存储空间，可修改进程的全局/静态数据。换句话说，TLS将在OEP之前执行。按下Ctrl+E，查看entry point，果然在其中看到了TLS函数的身影

打开TLS函数，其中果然出现了被修改的痕迹。

这里也出现了IsDebuggerPresent函数的调用，但是简单的看一看逻辑就会发现，这里的F5结果中第25行的判断要求不存在调试器方才执行里面的代码。这就比较奇怪了。查看里面的函数，注意到函数sub_401D40经常被调用，于是我们跟踪进去，查看其逻辑。

sub_401D40调用了sub_401D40，前者（以29行为例）传入了unk_4258B8的地址

这个地址看上去像是一个字符串。但是我们还未知道字符串的内容是什么。后一个函数接收两个参数，而传递给他的参数第一个为&unk_4258B8 + 1，第二个参数为这个字符串的第一个字符。跟踪到函数内可以看到函数的逻辑是异或加密

分析上述函数的逻辑，得知这是将字符串的第1字节往后与第0字节异或，得到新的字符串再填入原来的空间。对unk_4258B8进行这样的操作：

From Hex, XOR - CyberChefXOR({'option':'Hex','string':'0x7f'},'Standard',false)&input=N0YgMTggMTYgMDkgMUEgNUYgMTIgMUEgNUYgMDYgMTAgMEEgMEQgNUYgMTkgMTMgMUUgMTggNDUgN0YgMDAgMDAgMDAgMDA)

很好，我们看到了程序的输出字符串，这个函数改名为dec_xored。后面紧跟的函数sub_4016C0就是printf函数（根据里面的va_start标志），同样的，sub_401730是scanf。另一个函数sub_401D70，经过类似的简要分析知道他是一个加密函数。用于在解密字符串后以任意密钥加密字符串，来防止内存搜索。

类似的，函数更名为enc_xored

接下来分为两个部分，第一部分校验输入的合法性。

其中调用了函数_loaddll。字面意义上看，这似乎是一个调用动态链接库的函数。跟踪查看函数中调用了ExitProcess，因此可以知道这个函数和退出进程有关。我们暂时不管他。

第二部分是将输入变换之后填充到内存地址中

其中要求变换后的各字节都为奇数，这是一个重要的提示，记在小本本上。

这里我们遇到了两个变量：byte_42639B和Str1。他们有什么关系呢？根据内存布局图

他们似乎是互不相干的两个变量。细心的同学在分析scanf函数时就已经发现，Str的大小应该是1024字节

结合分析，第二部分的for分析后注释如下。这一段是将输入的字符，例如1234转换为十六进制值0x1234并检查是否为奇数。

在完成这对两个字符的操作之后，如果为偶数，则进入错误环节。

经过刚才我们这一通操作，我们总结了下述要点

首先注意到这个函数返回的值在后续都被按照函数的方式被调用

因此这很可能是一个类似于GetProcAddress函数的地址转换机构。但是如果我们按照dword_426388 := 9的初始值执行分析，就会发现总是会出发访问异常。验证这一函数的结构体的方法，是使用vs对应的编译一个程序出来

注意到这个是异常0xC0000005，会不会是后续的函数的处理条件呢？我们跟踪到函数sub_401320中查看发现

在其函数中也存在这一函数，而上下文中并不存在跳转，并且在TLS到OEP中都不存在自修改trick，因此我们可以认定，这个代码很可能出错了。但是运行时并没有出现这一错误，调试器也没有遇到这一问题，Windows也没有遇到这一问题，那么只有可能是我们的复现出错了。

有人问有没有可能是某处的SEH或者VEH（一种异常处理机制）？答案是否定的。先观察我们漏掉的“系统函数”_CRT_INIT，只有在.text:004017B4处调用的_CRT_INIT中初始化了SEH链。在.text:00D3396F中调用了一个sub_40F960，这个函数是一个数组调用函数（CALL_LIST）即对调用输入的参数。在其第一个参数unk_41E128的第二个offset sub_401000中调用了sub_403150，对byte_426B90进行了大量的赋值。这个变量也在刚才我们说到的异常分析函数中出现了。

而在start中，只有sub_4040B5中调用了SetUnhandledExceptionFilter

其参数为0，代表传递给系统默认的错误处理句柄。稍有VS工程逆向经验的师傅都清楚，start中的诸多操作都很干净，这些异常是为了防止栈溢出的操作。感兴趣的同学可以自己编译一个vs项目做实验，笔者使用VS2022任意编译的项目的起始代码和题目的代码相差无几。下面给出笔者编译的代码（包含了vs自动生成的符号表）

注意刚才我们怀疑的部分

是完全一样的。这意味着这刚才我们遇到的错误并不是题目刻意引发的，而是我们的分析错误。

那么究竟是哪里出错了呢？我们注意到复现版本的代码中引用了变量dword_426388，这个变量在sub_401170中被修改过。

观察IDA似乎只有一行短短的return 9i。于是我们试图从汇编中找答案

返回值被存储在eax里，而这个返回值本应该是一个if选择结构，这里因为可以执行编译前运算，IDA自动把不会触发的分支省略了，即右半边的loc_4011D1。这里的汇编代码如下：

其中出现了一个指令：call $+5，这是一个经典的反分析trick。在《恶意代码分析实战》第15章“对抗反汇编”第15.4.3节“滥用返回指针”中详细解释了这一花指令的原理

对于我们这里的花指令，call $+5会执行mul eax两次，一次由call跳转，然后call结束时返回到mul eax顺序执行，因此正确的执行结果是eax == 51h，满足jz的条件，从而通过PEB获取了kernel32.dll基址

知道了上述的关键信息，我们再返回看刚才的地址转换机构的前半部分就很明朗了

后面部分的是SM3加密，这个加密我们可以轻易地知道这段代码实现了GetProcAddress的机制，也就是通过将函数的名称做数字签名，依次与传入的第二个参数进行比较，从而简介获取函数地址。有兴趣的师傅可以自己手动实现一个SM3代码，这里给出一个参考

SMx/sm3.c at master · NEWPLAN/SMx (github.com)

我的方法是通过绕过IsDebuggerPresent的方法动态调试，或者叫任意执行到这个函数，然后看eax对应的函数结构判断函数。通过判断，能够轻易地给出各种函数的名称，换句话说，导入表。下面给出一个示例

通过上文的分析，我们将所有API转换，并给予相应的常量、名称和结构，能够大致梳理出题目的思路：

题目在未被调试的环境下创建了子进程，并使用DEBUG_ONLY_THIS_PROCESS | DEBUG_PROCESS启动。这样会使子进程进入被调试状态，将其事件全部发送给父进程，父进程接收子进程线程的异常，处理并观察flag的正确性，最终给出输出。

上图给的是地址转换之后的API以及对应的函数结构。可以看到其基本流程为

而对应的两个异常，也和main函数的初始节中的一大堆奇怪的调试错误对上号。我们观察主函数中需要调试器（即子进程）中执行的汇编代码

可以发现，这些代码中正好只操作了三个寄存器：eax/ebx/ecx。根据这些代码写一个小脚本模拟执行，来对应异常处理的vm指令

其执行流如下

得到了执行流，接下来的工作就是对执行流进行逆向。首先，执行流所使用的函数有几种

以及其操作的变量有dword_427B90、byte_427BBC、dword_427BC0。其中dword_427B90具有初始值。

这些“原子”操作的逆向很简单，其对应的指令如下

修改这些函数名，再次运行上面的脚本：

分析上面的执行流，可以知道这个执行流的逻辑极其简单。其从byte_426B90中读取数据并寻找这个数据，判断迷宫。换句话说可以认为，输入的数据首先要在byte_426B90的范围内，如果数据和迷宫的字节相同，则往那个方向走一步。如果没有就报错，如果走错了也报错。byte_426B90的初始化是一个迷宫。走迷宫的规则在TLS函数里，其规则很简单，只需要依据奇数走迷宫即可。

而我们被处理的输入，在.text:00401346的memmove(&unk_426C58, &Str1, 0x13u);被放置在unk_426C58中，这个变量其实是byte_426B90的第0xC8位置。（0xC8同时也是dword_427B90[9]的值）。迷宫有dword_427B90[6] = 12行，初始位置坐标为(5,0)（dword_427B90[4] = 5;dword_427B90[5] = 0;)

知道上面这些所有的信息，打开我们最初找到的初始化部分sub_401000，把数据导出并按照12行排列，走迷宫喽！

reverse3.exe是题目
reverse3.exe.idb为笔者自己分析的IDA数据库文件，版本IDA75

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！