花时间尝试了下这道题，最后败的倒地不起，但失败是好事，人总能在一次次失败中吸取教训，因此有了这篇wp，记录下这道题的踩坑过程。希望这篇wp可以让那些和我一样正在尝试逆向的萌新打开一些思路，共同进步

第一步，是令程序禁止地址随机化，这样程序每次从0x400000开始加载，而不是每次开机都会随机选择一个地址。虽然通过对IDA进行Segment的Rebase，也可以使其地址与OD/x32dbg一致（说起来，大佬们都是用x32dbg去做题，看来以后做题时也得切换调试器了），但是用0x400000显然更好，并且也能与家里电脑分析时保持一致。具体手法如下图（图片来源在文末）：

首先会判断输入的字符串首字符是否为'A'，以及长度是否为32位。

如果死在前两处校验，则会打印错误；否则会打印失败

经过单步验证，输入字符串"1234"（符合首字符不为'A'的情况），会依次调用sub_415B2C、sub_499715、sub_49B4ED这3个函数，其中执行完sub_49B4ED后，可以在eax指向的地址中找到中文字符"错误"，执行完sub_49B4ED后，会在命令行中打印出"错误"

回到IDA中分析伪代码，通过观察可以发现，sub_415B2C初始化了一个数组，然后sub_499715通过对数组中特定位置字符进行异或运算，解出"错误"对应的ascii码，然后再通过sub_49B4ED打印出字符

图中两处橙色方框，都是先初始化数组，再进行异或解密，然后打印字符；但是两处初始化数组的函数不同，解密函数也不同，用于打印字符的函数是相同的。根据这个特征，我们可以去找sub_49B4ED这个函数的交叉引用，这样也许就可以找到打印"失败"所在的位置了

可以看到，在函数sub_46D092中也有三处调用sub_49B4ED的地方。进入其所在汇编附近（这里无法看伪代码，因为函数过长，超过1w行，IDA无法解析，修改解析函数大小后，又遇到了stack frame is too big的问题，查阅资料后扔无法解决，因此只能看汇编），可以看到，在每次调用sub_49B4ED之前，都有2个call，猜测这两个call是分别用来数组初始化与解密得到中文字符用的。

纯看汇编肯定不行，上万行呢！好在IDA支持CFG的形式，这里需要按照上图所示，在选项中对Graph视图进行配置，调整最大结点数，然后就能够以"基本块+边"的方式对汇编进行查看，体验会稍好些

先找到loc_47541A这个基本块，这个基本块里会打印出"失败"，我标记为"失败1"是因为，一共有2个失败，说明可能有2次判断，而这里打印"失败"的地址最靠前，说明会受到第一次判断的影响，因此被标记为"失败1"，也就先分析它

这里还有一点需要说明，就是图中左右两侧的边都是直上直下连接的，也就是说左侧是从上到下几乎完全线性的基本块，不会有边从左侧的基本块连接到右侧的基本块，右侧也几乎同样如此，所以此时基本可以忽略左侧的基本块，直接看右侧上方的调用链即可

在往上查看右侧调用链时，可以发现打印"成功"的基本块，并且是在右侧。我们知道左侧的基本块会走到"失败"，现在我们要找到，导致走向失败或者成功的这个分支点在哪

再往上看，就可以找到图中所示的这片代码块了，在这里，我们看到了"失败2"所在的代码块。这里重点关注两个蓝色方框

其次是下面的蓝色方框（位于loc_478405），这里是一个循环，和上方的代码块loc_4783E3是关联的，IDA没有完全分析出，进入OD下断（当然先把前面的分支跳转patch掉，使之可以走到此处的代码块）可以发现，这一块是对输入的字符串进行判断，筛选出小写，即只允许输入 [0-9A-Za-z] 范围内的字符

继续往上分析，找到导致跳转的源头，结合OD进行分析，可以得到，这里对栈中的值进行了比较，若两处的值完全相同，则会进入理想的分支中。否则会跳转到"失败1"对应的分支

通过交叉引用，可以发现，其中进行比较的一个值是写死的，可以直接找到（所以另一个值就是将输入的字符串进行变换得到的了），这里可以先将其记录下

这里可以看到，随机输入的字符串，得到的新字符串（暂且称作其为加密字符串），和需要进行比较的结果差距还是很大的。接下来要做的，就是找出字符串是如何经过变换得到加密字符串的

这里为什么要找[ebp+0x1B0]？上层调用函数栈不是会下降吗？ebp变了，为啥寻址没变？其实我也不知道为啥要这样做，我只是找规律，我通过交叉引用找到调用sub_46D092的上层函数时，发现在该函数[ebp+0x1B0]的位置，也已经存储了加密后的字符串（这意味着还需要往上层找），尽管sub_46D092中的ebp和上层函数中的ebp值不一样，但是加密字符串都是存在[ebp+0x1B0]处，所以按照规律就这么找了，这里对这个地址下硬件访问断点也可以

然后我们在sub_4631E9中找到了，arg_1A8对应的刚好是0x1B0。这是sub_46D092上层函数的上层函数

接下来，通过交叉引用，可以找到一个函数sub_49AF99，它将[ebp+0x1B0]这个地址作为参数传了进去

单步调试一下，也可以发现，执行sub_49AF99前，会传入一个空缓冲区，执行后就填充了加密后的字符串，这下可以断定，这里的sub_49AF99就是对字符串进行加密的地方。接下来就可以针对sub_49AF99这个函数进行分析

我们知道，加密字符串有一个比较的值是写死的，所以我们带入加密后的字符串，分别进行解密，可以得到如下的结果，

将图中橙色方框按照顺序，以小端方式写入那个已经经过变换后的字符串堆块（在执行sub_49D07F之前，strcpy之后）中，然后F9执行

可以发现，这么做，进行手动修改加密前的字符串，是可以执行成功的，也说解密的程序是没有问题的，但是这里还存在两个问题

找字符串变换逻辑和找字符串加密逻辑一样，从这里可以看到，字符串作为参数传入sub_49AF99时位于[ebp+Source]也就是[ebp+0x2CA]，然后据此通过交叉引用向上找，看看上层函数是否有修改[ebp+0x2CA]的地方

不断的往上找，可以发现在函数sub_44BC99中使用到了[ebp+0x2CA]这个栈空间，在该函数的基本块loc_44EBEC中，将输入的字符串与一个写死的全局变量进行了异或运算，可以看到这个全局变量就是"55555555555555555555555555555555"

总感觉就只差一步，但最终还是无能为力，直至题目结束，看了6位大佬的wp，咨询了出题的师傅，才豁然开朗

首先是对字符串进行加密的算法是SM4加密，由于自身的算法意识浅薄，看不出来（第三题的AES也没看出来），这也导致了始终发现不了最后的坑，但是不知道为什么Findcrypt只识别出了MD5和Base64

不过还是有一些特征的，在对进行密钥进行扩展的函数里，可以找到4个常量，搜索一下这4个常量就可以发现这是一个SM4的加密算法。这一点在mb_mgodlfyn的文章中有提到

这道题涉及到多种反调试手法，这一点在深山修行之人在他的文章进行总结，其中一种，就是修改SM4的密钥key

在使用调试器的情况下，用于进行函数扩展的密钥如图中橙色方框所示，此时按照mb_mgodlfyn大佬的思路patch在这个基本块Patch一个死循环，然后再附加（这样就可以过掉反调试了，或者像中午吃什么大佬那样，注入自己的Dll，在算法前后打印出相应的参数值），然后比较一下密钥的值

这里OD附加不了Patch的程序，所以用了x32dbg，可以看到，Patch后停下来得到的密钥确实和原先的不一样。或许这就是真实的密钥

修改box后重新运行一遍解密程序，可以发现，用于匹配的字符串后半部分算出来刚好是0，也就是说，确实只用到了前16字节进行运算。然后我们拼接一下计算出的结果，就可以得到"FAA2FBAEDFBAA3C2E3EC40AFCD4D9E43"，与"55555555555555555555555555555555"进行异或，就可以得到"AFF7AEFB8AEFF697B6B915FA9818CB16"。带入到程序中，成功运行

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