RCTF Re300 Writeup

时间:2023-12-05 15:00:38

  发现一篇写得更好的:http://insight-labs.org/?p=2009 

  程序要求输入一个flag。拿ida加载后,发现是Upx壳,脱壳后加载入ida进行分析。定位到输入flag的地方,如下图:

RCTF Re300 Writeup

在od中在0x401455处下断点,执行到此。继续f8执行下去,发现程序来到一块不在程序代码段的用户空间。如下图:

RCTF Re300 Writeup

这一段执行完后,程序在修改代码段的内容,是动态代码修改。修改完成后,跳转到0x0040189e去执行。如下图:

RCTF Re300 Writeup

我就觉得是一个壳,而0x0040189e则是OEP。因此,我使用OllyDump对程序进行脱壳,并使用ImportRec进行导入表的修复。修复成功后,成功得到一个exe。

RCTF Re300 Writeup

RCTF Re300 Writeup

得到exe后,我尝试运行,发现不能运行,因此我就拖入ida进行分析。发现程序在动态修改代码段的内容,而代码段是不能执行的,因此不能运行。不过对于静态分析还是不错的,在里面我清晰地看到程序的算法。

RCTF Re300 Writeup

将数据调整完顺序后,会与一个字符串比较,如果相同,则成功,否则,则失败。

RCTF Re300 Writeup

Hexlify(char *s, char *d, int len):将s表示为16进制放在d中,d的长度为s的两倍。

Xor(char *source, int len) :source里的每两个字符是一个字符的16进制表示,将source里的每两个字符与第一第二个字符比较,如果都相等,这两个字符分别异或0x19和0x20,如果都不相等则将字符异或0x18。

Core_algo()为一个递归算法,将产生打乱后的顺序。

Disorder(0)则根据core_algo产生的打乱后的顺序将final的顺序打乱。

我发现只有两个函数对final这个字符串数组进行了操作,也就是说打乱的顺序与输入的数据没有关系。我将core_algo执行完后,把内容从40adf8开始的0x510字节dump出来,并写了个脚本拿到了打乱后的顺序。

因此,可以从后向前推出flag。脚本如下:

RCTF Re300 Writeup

RCTF Re300 Writeup

RCTF Re300 Writeup

RCTF Re300 Writeup