d3ctf2023 | moyaoxueの小屋

d3ctf2023

type

status

date

slug

首先这里的d3runtime.dll就够可疑的了，调起来就有点印象。先在main开头断下来，果不其然modules里面的d3runtime.dll里面的东西很可疑

之前自己弄过一点dll加载相关的出题（后面有空写个blog记录一下，~~希望不鸽,虽然已经鸽了半年~~）这个位置直接调有时候窗口不会自己跳转过来，这里函数不多，直接往每个函数开头下断点

main里面的sleep常规nop掉，下面的逻辑看着是在骗人，真正的逻辑在dll里

胆大的直接F9，出锅了，调了调发现卡在sub_40216A，重来

压根没进main，tls_callback就把dll起起来了（第一遍动态的时候在dll下了断点，第二遍就直接发现了）

直接进了d3runtime__61FC1628看不出来啥用，有点像花但不能nop的

感觉是故意的...编译器会这么优化么...不能删这里，逻辑是中间的mov 和add 走两次，下面有个一样的操作

谁教的......

不能F5，单步往下

而后d3runtime__61FC1578函数，TEA加密，但是不知道啥用，接着调

这里上了反调，直接过掉，但是后面的代码很奇怪，明显反编译有问题，重调

注意到一个很奇怪的事情，这里：

合理的话按照上面相同的写法，应该是E8 00 00 00 00，但是这里少了一个00，一开始以为可以不需要，但是想想不对。这里怎么想都应该是call $5的操作，然后后面可以还原出上面的逻辑

哦，动动脑子，这里换32-bit了，天堂之门，对应题目hell

这里确实萌新没接触过天堂之门的，没从tls和DllMainCRTStartup里看出什么端倪，但是总归这里是32bit，那dump下来放进ida里看看，呜哇，修了半个小时修不明白

那也可以硬调吧，不妨碍，既然他能运行那姑且也可以调

调dll的确实...~~不知道谁也出过类似的恶心题目~~

但是主逻辑有了的，下面isdebuggerpresent给他拿掉，这里主要是V0没有识别出来，跳转的时候没有找到jmp的位置，否则不会有那么多逃逸变量...

勉强可以辨认这里修改的表

回到main里，实际操作也就这里面：

byte_405060刚才在dll已经走过了，差这个flag表，应当在这里走走：

再往前推么发现跟v12有关，于是牵扯到了sub_40216A，这里确实确实看不懂了，即使出题人好心没去结构体的符号表...

先说结论，这里是大整数分解。其次，看的别人的wp知道的

结论是这里把换后的表带入大整数分解，得到的两段拼接起来是flag...