（印象中这题之前好像放在第八题的位置上，是因为赶上周末所以把难题调整顺序了？）

第七题
Archaia
方案二

众多熟悉的因素叠加

writeup正文开始前，先看一个有关Archaia战队的合订本。

战队名称：Archaia
战队签名&战队介绍：武汉科锐学员队
注册时间：2019-06-08

（以上信息来自 https://ctf.kanxue.com/team-myctf-101159.htm)

从注册时间往后看，最早能追溯到2019看雪CTF晋级赛Q2

Archaia战队第一次防守方出的题，思路颇有特色。
但从第二次开始(至少直到上次)，所有题目的思路高度雷同（甚至有的题目算法都相同）：windows程序+方案二+一些计算算法检查序列号+混淆&|加壳+从不公开混淆&加壳程序的源代码+官方题解从未给出过自动化去混淆脚本

2019看雪CTF晋级赛Q2 第八题：迷雾中的琴声：输入作为shellcode执行，目标是弹框Win+通过crc校验，无壳，多解。
2019看雪CTF晋级赛Q3 第十题：传家之宝：2880层自解密自复制蜗牛壳，每层都包含核心逻辑的少量分片，程序正常运行都需要若干秒才能结束。序列号的检查逻辑是魔改AES算法
2019看雪CTF总决赛 第六题：三道八佛：1401层smc，只在最后一层有核心逻辑；上次的脱壳脚本可以复用。序列号的检查逻辑是一个自定义数据算法。与2019Q3的题混淆/加壳相同，算法改变了。
看雪.深信服 2021 KCTF 春季赛 第七题 千里寻根：2021层smc，每层的蜗牛壳代码都不一样（重中之重，这一个小改动导致攻破此题的三个攻击方都没有像先前的题一样做到完美抠出核心逻辑的指令交给IDA，而是更多的依赖调试和看汇编，体力活更大了；另外，赛后出题人在题解里轻飘飘的说了句 “脚本log出来的数据需要自己提取出有用的"肉代码". 可以人肉搞定, 或者找到规律后写脚本一通字符串操作也能搞定.这里给出前几层肉代码的分析, 后面层的同理.”(链接)，但等了两年出题人却迟迟没有公开这个脚本，合理质疑下出题人真的验证过这样的简单性吗？又或许每层壳虽然代码不同但只有有限种组合，那么出题人是不是应该公开加壳处理的代码证明一下这一点呢？）。算法部分与2019Q4类似，只做了小改动。
看雪.众安 2021 KCTF 秋季赛 第九题 万事俱备：还是代码混淆，语言换成了python字节码。算法也是2021H1的老算法+微小修改。解释器改opcode是常规但对于攻击方而言除了徒增工作量以外毫无学习意义；而字节码混淆，出题人说“只要攻击方能击破代码混淆, 就是看"源码"写逆算法的活了”(链接)，不过读几位攻击方大佬的writeup，实际处理起来似乎并没有这么轻松；同样，出题人没有公开自己的处理脚本，合理质疑下出题人验题真的尝试正面破解过自己的代码混淆吗？
看雪 2022·KCTF 春季赛 第五题 危机四伏：基于2021H1题目继续加难，蜗牛壳没了，但每层的垃圾指令混淆还在。三个公开的攻击方writeup全是非预期（算法几乎完全没变，只改了异或常量），而出题人的预期仍然说的非常轻松：想办法处理xxx、找出xxx的规律、根据特征xxx、写脚本将垃圾指令除去、等(链接)。但是，具体用什么办法？规律和特征是怎样的？脚本怎么写？出题人仍然什么都没公开。
看雪 2022·KCTF 秋季赛 第十一题 衣锦昼行：这次终于换了算法，但不变的还是代码混淆+出题人对于具体怎么去混淆只字未谈（所以，题目发布前是怎么验题的？）。另外序列号在程序计算过程中暴露，导致题目被迅速非预期。

结合2022H1-2021H1-2019Q4-2019Q3题目的延续性，以及2022H2的题目被非预期，当Archaia出现在今年的防守方列表时，就有预感大概率是把2022H2的题目修了非预期再出。

正文开始

IDA打开，看到main函数立刻证明了这就是基于2022H2题目修改而来。下载2022H2题目出题人公开的源代码(链接)，对照main函数，把所有变量和函数重命名并修正类型。

注意这些被调用函数的调用约定都是"__cdecl"，需要先手动修正过来，否则IDA对栈上临时变量的识别会出问题。

调用的Encode_{X}、RSHash、sub_40F9AF、Encode_For_Serial、sub_403ACA、Decode_For_Serial函数都加了混淆，主要是花指令+垃圾指令+控制流跳转混淆。（例如，jz xxx ; jnz xxx 两个相邻且条件相反的条件跳转指令，等价于一条绝对跳转。）

大概看了一下，感觉模式匹配或许能处理一部分；或者，不处理混淆，动态调试单步执行硬跟的复杂度也能接受。

在此之前，main函数没有混淆，先梳理一下name和serial的数据流。

name输入后，先经过48个Encode_{X}函数运算，再经过RSHash运算，得到szHash2Hash_，作为最后strcmp的第一个参数参与比较。
然后对szHash2Hash先做两次sub_40F9AF_0(以0作为第三个参数调用sub_40F9AF)运算再做21次Encode_For_Serial运算可得到szCurrentSer。
serial输入后，先hexdecode，再与szCurrentSer一起做sub_403ACA运算，然后是22次Decode_For_Serial运算，最后是sub_40F9AF_1(以1作为第三个参数调用sub_40F9AF)运算，得到szDecCurrent_，作为最后strcmp的第二个参数参与比较，如果与szHash2Hash_相等则通过校验。

但是，如果在输入serial之前最后一个调用的Encode_For_Serial和输入serial之后第一个调用的Decode_For_Serial下断点，可以发现它们的参数是互逆的。这表明，从szHash2Hash出发，依次做 2次sub_40F9AF_0 -> 22次Encode_For_Serial -> 22次Decode_For_Serial -> 1次sub_40F9AF_1，会得到与szHash2Hash相等的值，而已知Encode_For_Serial与Decode_For_Serial互逆，所以 2次sub_40F9AF_0 与 1次sub_40F9AF_0 互逆，这几个函数混淆后的代码都无需关注。

所以，现在只有sub_403ACA的逻辑未知且找不到它的逆函数。动态调试发现它的前两个参数是输入，第三个参数是输出。

当已知name时，沿着数据流可以正向得到szCurrentSer作为sub_403ACA的第二个参数，同时可以正向得到szHash2Hash，经判等转到szDecCurrent_，再逆向 1次sub_40F9AF_1+22次Decode_For_Serial可得到sub_403ACA的第三个参数 (前面验证了这个逆向的过程等同于 2次sub_40F9AF_0+22次Encode_For_Serial，所以直接在0x40347A，即最后一个Encode_For_Serial的位置下断点看此时栈上的参数即可获得具体值) 。

总结下来，在已知name时，sub_403ACA的第二个参数和第三个参数都可以获得，而第一个参数是待求的serial，所以只需要逆向这一个函数即可。

静态逆向？代码混淆着实非常讨厌，这里从动态调试入手分析。

动态调试观察到sub_403ACA函数的三个参数，每个长度都是16字节，且前两个参数即使改一个bit第三个参数的输出也会完全改变，所以这很可能是某种16字节的块加密算法。

对前两个参数所在的内存下硬件数据读写断点，在经历一次数据复制后到达了栈上19EDB4的位置，此后的数据访问都发生在这里。
实测发现，需要对第一个参数（即serial）的4个四字节都下上硬件读写断点，如果偷懒只下一个或两个程序有可能会闪退。具体原因未深究，但是注意到main函数有启动一个新的线程，且如果patch掉这块代码，程序会在sub_403ACA闪退，所以这里可能有特殊的检测。代码混淆太恶心了，不想去碰。

初始：name和serial分别输入题目提供的值：CCFE84316BD02C02和D532E41AFE55A4265D7789C84BF40384

对第二个参数下好4个断点，逐步按F9并跟随数据复制修改断点位置，发现代码在逐渐填充19ECF0到19EDAF之间的数据，填充数量合计11*4个四字节。

对第一个参数下好4个断点，同样按F9并跟随数据复制修改断点位置，观察到19EDB4数据的变化，发现有逐单字节改变和逐四字节改变的交替

重新开始单步调试，观察到这里数据的变化有几个阶段：

初始：
19EDB4的数据清零；堆区有分配的serial值（注意8BD8D8这个地址不是固定的）

第一步：把serial值复制到19EDB4处，复制时以4为间隔步长（另一个角度理解，相当于4*4矩阵的转置）
新的数值：

第二步：19EDB4开始的4个四字节，分别与19ECF8、19ED24、19ED50、19ED7C的4个四字节异或
待异或的值：

异或之后的值：

第三步：19EDB4位置，4个字节一组，第一组不变，第二组循环左移1字节，第三组循环左移3字节，第四组循环左移2字节
变化之后的值：

第四步：19EDB4的每个字节做一次查表变换，表在0x62C700，位于程序的.rdata段

变换之后：

至此，数据的变换已经出现了明显的AES特征。第二、三、四步分别可能对应addroundkey、shiftrows/invshiftrows、subbytes/invsubbytes。

回顾一下10轮AES-128加密和解密的步骤：

加密：

解密：

目前的第二、三、四步，与加密的前三步不同，与解密的前三步能对应上，且能够确认的是invshiftrows有魔改（每行移位的数量与标准算法不同）、invsbox有修改。

按照AES解密的逻辑，下一个步骤应该是invmixcolumns。先前找到了魔改过的invsbox在全局变量byte_62C700，而它附近的byte_62C800恰好是对应的sbox，且在.text段有交叉引用（这或许预示着sub_403ACA的逆函数就在程序里，但那又有什么用呢，代码混淆解开之前根本找不到入口点在哪里）；再看附近的内存，byte_62C900 (02 03 01 01 01 02 03 01 01 01 02 03 03 01 01 02) 和byte_62C910分别是mixcolumns和invmixcolumns矩阵的标准形式，所以invmixcolumns应该没有经过魔改。继续单步调试，数据变换与标准的invmixcolumns计算结果相同，证明确实如此。

最后是addroundkey使用的轮密钥，调试发现是19ECF0到19EDAF之间填充的值，但每轮并不是按顺序取值。在这块区域下数据访问断点，多调试几轮，可以找出具体顺序。

基于以上分析，写出aes_dec复现sub_403ACA的逻辑，动态调试验证结果正确后改写为aes_enc，得到serial生成脚本如下：

最终答案：

多解：
hexdecode之前只检查了不出现小写字母，但调试发现如果输入的字符不在[0-9A-F]会视为0，所以serial中的0可以替换为几乎所有字符，例如：
8BCBB6979E174CB7ECAEACDA1G4522CA
（题目过滤小写字母大概是想避免2022H2的大小写多解，但是，基于黑名单的过滤总是容易出现意外惊喜；既然做了字符过滤，换成白名单，限制只允许[0-9A-F]即可轻松解决（用哈希虽然也能限制多解，但是缺了灵魂））

正文结束

最后，作为对攻击方“在最终成绩公布前请在【答案提交区】发表解题分析文章、所用工具、源代码等材料，且文章有理有据能够详细完成说明自己获得答案的整个过程”的对等要求，在此恳请组委会，要求此题防守方能公开此题做混淆处理过程的源代码(注意这不同于crackme混淆前的源代码)（ref：看雪·2023 KCTF 年度赛【防守方】规则 方案二，“所提交的壳或VM或其他手工处理的方法将在赛后向广大会员公开”，https://bbs.kanxue.com/thread-276642.htm，这里是不是应该理解为用出题人公开的源代码按照出题人公开的方法要能够生成最终的二进制文件？另外.obj文件显然并不等同于源代码），以及，验题时出题人/验题人以攻击者视角做题时的具体去混淆方法和处理代码（这里 描述的破解思路，显然过于简洁，并不满足“有理有据能够详细完成说明自己获得答案的整个过程”的(虽然这是对攻击方的要求，但防守方自己出的题，达成同样的要求会更简单)；或者说，出题人给出的题解，至少要充分详细到让一个完全没有做过这道题的人照着抄答案能够破解掉题目，对于加了混淆的题目，详细且可复现的去混淆方法当然是必备的）。

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界