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!