bugkuctf的reverse_3.exe

这道题目是bugkuctf平台的，由于我最近在学习逆向这块儿，在此记录一下拿到flag的过程

首先文件运行起来如下图：

接收一个参数，如上图我输入abc后回车直接提示wrong flag!

这个小ctf我起初是直接搜索字符串，看看是否正确的flag是硬编码的形式写在代码中

如图，当时发现一个字符串：e3nifIH9b_C@n@dH

拿到这个字符串当作参数试了一下，结果还是报错

最后利用ida看了一下F5后的逻辑，直接找到main函数看逻辑，逻辑如下：

如图一眼就看到了”wrong flag!”，可以看到使用到了strncmp函数进行了比较，如果Dest的值等于Str2的值，那么就调用sub_41132F，这个函数其实就是printf函数，输出”right flag!”

跟进去发现Str2的值就是上面看到的字符串e3nifIH9b_C@n@dH

Str2是e3nifIH9b_C@n@dH，Dest的值必须也等于e3nifIH9b_C@n@dH才会打印”right flag!”，那既然如此答案不就出来了吗？其实这不是最终答案，一开始就试过搜索到了这个字符串，输入之后依然打印错误的flag，那么是什么原因呢？明明这里进行的比较，2者相等就输出正确的flag，不相等则输出错误的flag，我明明输入的是与Str2相等的值，为什么还是输出错误的flag呢？

原来关键地方在这里：

sub_4110BE函数，该函数对我们的输入的内容进行了处理后并返回新的字符串，跟进去看了一下sub_4110BE，内容如下图：

核心内容就是base64算法对输入内容进行加密,其中的aAbcdefghijklmn是一个base64编码表，加密算法就是基于这个表。base64的算法我清楚原理，第一眼看到这段带代码就知道是它。

继续分析，sub_4110BE函数将我们输入的内容进行了base64编码后保存到了v1中

接着又调用了strncpy函数将加密后的内容拷贝到了Dest中，再回过头看前面看过的strncmp函数就知道了，原来前面看strncmp函数时，它对Dest和Str2进行比较的值是加密后的值，已知Str2的值是e3nifIH9b_C@n@dH，那么我们依据base64解密即可得出结果，但仔细看发现e3nifIH9b_C@n@dH并不像base64加密后的结果呀？这是为什么呢？利用base64解密e3nifIH9b_C@n@dH也不对啊，解出来的是个乱七八糟的东西

为什么呢？因为加密后又进行了处理，处理的地方如下图：

此处将加密后的字符串的内容从第一个字符开始，将他们的ascii码值从0开始做了相加，假如加密后的字符串长度是8，那么从第一个字符串开始，首先加0，第二个加1，第三个加2，以此类推。所以最终我们看到的是e3nifIH9b_C@n@dH，就是因为这一步将它变形了，弄个清楚后直接上Python还原出他的原始内容并base64解密：

看样子flag就是{i_l0ve_you}，我们试试看，如下图：

我们尝试输入{i_l0ve_you}验证一下看看是否输出right flag!

nice! game over!