SSCTF-Final-Re-Play

SSCTF-Final-Re-Play

　 比赛时花了一晚上搞定了，结果写脚本的时候发送的内容忘记base64加密然后异或8了，手动测试的时候当然是这样做了，写脚本的时候脑抽了。这个题只有forx做出来了，白白损失了一个打全场的机会，赛后大家估算了下要是没弄错了的话，应该是在前5名。补丁打好了，但是这个程序本身就是一个服务端，必须手动地停止服务再重新启动，结果并没有这么做，所以补丁白打了，还是被打。

最初还以为是个PWN的题，因为还没见过攻防形式下的Reverse题。傻傻地去找格式化字符漏洞和溢出。后来弄清楚题意后知道是个逆向题目，和龙少花了一晚上搞了搞，一个人的话真得很容易放弃。

是一个QT的程序，启动后会不断地连接192.168.199.1:1234，自身监听9527端口。192.168.199.1:1234是主办方的服务端，我们并不能控制，主办方给了一个文件里给了192.168.199.1:1234给这个QT的程序发送的数据，在调试的时候，我也模拟192.168.199.1:1234向程序发送数据。

程序会监听9527端口，我连接上后，可以发送数据，并返回一定的结果，发送随机字符串的话，会返回0；发送一个数字的时候，会返回数字的2倍。

看程序的界面，会发现发送的东西以乱码的形式呈现到界面，分明是经过了某种处理。

在知道了这些东西后，开始上IDA分析。

在MainWindow的构造函数中，发现了saddddd....HP这个函数，进去后发现做了一些初始化的造作，以及信号和槽的连接。

　 初始化后可以看到MainWindow的结构

+ 8    QTimer

+ 9    QTCPserver

+10    QTCPSocket

+11    QUDPSocket

这个TCPSocket会在Timer的作用下不断的连接192.168.199.1:1234，直到成功。

　 QTCPServer则会监听9527端口。

信号与槽通过Qobject::connect联系：

重点看第二个和第三个，第二个说一旦QtcpServer监听的9527端口有新的连接来到，则调用MainWindow::cST()函数，第三个说一旦QtcpSocket接受192.168.199.1:1234的数据时，调用MainWindow::rD()函数。

除此之外，函数中还有其他的信号与槽的联系，在这里先不说。我们把重点放到MainWindow::cST()上，因为只有这部分是我们可以控制的，我们向9527端口连接，并发送内容。在MainWindow::cST()中，首先创建了一个socketThread，来与客户端进行通信。

在socketThread的构造函数里，看到建立了QTcpSocket和SocketThread的信号与槽的联系。

这里的a1+28就是连接到9527端口的QTcpSocket，a1则是socketThread本身。从这里可以知道如果客户端连接到9527端口并发送数据时(readyRead)，将会调用socketThead::rD()函数。

在socketThead::rD()逛的时候，发现了这些东东。

看到了异或和解base64，感觉挺可疑的，就在这下断点，竟然发现是对输入先异或了8后进行解base64。这个时候，我将测试发送的内容进行base64编码，异或8后发送过去，在界面上看到了明文哦。

做题的时候，一直在想这个逆向题目是怎么获取到对方的flag的。隐隐中觉得是发送一定的内容就会返回flag。继续在socketThead::rD()中逛，会发现有打开文件操作、base64操作等，这些都是可疑操作，就在上面下断点。竟然发现，会尝试以刚才发送的数据的解码结果为名打开文件。

接着就一个存在的文件做实验（文件名经过base64加密后异或上8），发现竟然返回结果了！！！

这明显不是文件的内容，但是应该是某种形式的加密。继续在socketThead::rD()中逛，突然想到好像在函数列表中有进行密码学运算的库函数，赶紧交叉引用找到调用点，下断点。

发现了奥秘，原来是文件的每3个字节进行md5运算，最后拼接后，发送到客户端。

至此，弄清楚了程序的意思，只要发送base64encode('/home/user2/flag')^0x8，就能得到flag每3个字节进行md5后拼接的结果，3个字节的md5是很容易爆破的，因此就能拿到flag。

感觉做Linux下的逆向还是IDA debugger好用，做pwn的话GDB好用。