首页
论坛
专栏
课程
4

[原创]第5题解题过程

维一零 2017-6-11 10:17 1132

程序运行后输入回车验证,没有任何提示,于是OD附加进程,但是发现无论是硬件断点还是内存断点,只要程序一运行到下断的位置就会直接崩溃,各种版本的OD过反调试都失效:


后来发现这是一个神奇的反调试,核心代码在驱动层,并且实现方法也很简单,主要就是在底层遍历找到crackme进程将调试端口置为0

而这个检测触发的条件需要应用层程序发送一个控制码来触发:

分析一下应用层程序对应的控制码部分,一共有2个函数里发送了该控制码,以下是一个线程函数里专门每隔3秒钟发送一次该控制码进行反调试检测:


另外一处是在验证输入key时,在把key传给驱动程序前做了一次检测:

这样一来,要过反调试有两个选择,一种是patch应用层程序,把这两处发送的控制码的地方简单patch,但是有个弊端就是程序需至少发送一次该控制码给驱动层才能将bCheck值改成1,后面才会去正常验证key返回结果。这样的话就比较麻烦,所以用另外一种选择,修改驱动,在处理该控制码的位置将调用反调试函数的代码patch掉,然后修正一下校验和,在包含该驱动的exe文件对应处修改patch后的数据:


这样卸载驱动程序后重新运行程序,便可以高枕无忧的进行动态调试了。下面开始分析验证算法。

此时可以正常下断,GetWindowText*可以跟踪到输入串,发现检查了输入串的长度为6才进行校验:

然后把输入串翻转一下直接发送给驱动程序:


驱动层计算完结果直接返回,看着像md5串:


接着把该16进制串计算一下MD5


最后取其子串进行比较,一致的话则成功:


可见问题的关键在于把输入串传递给驱动进行计算的过程了,由于输入串长度为6比较小,比较容易进行暴力枚举进行破解,然后又有两个选择,一个是直接当驱动是个黑盒,在枚举过程中将字符串传给驱动去计算再返回校验,另一种就是去分析驱动的算法来提高暴力枚举的“效率”。本人尝试了两种方法,发现确实速度提供了不少,毕竟减少了通信的读写过程。上面提到,驱动返回的结果有点像md5串,一开始以为是修改后的md5算法,但是仔细过一遍应用层和驱动层的md5算法能够发现,其实算法是一致的,也就是都用的是md5算法,但是驱动层又另外对输入串进行了一次处理,导致返回的md5值并不是原输入串的md5

这样的话就清晰很多了,都是md5算法,枚举算法好办了,省去了和驱动通信的额外开销,可以专心的跑脚本了。。。贴个比较暴力的6层循环枚举:


就这样吧,看装备看人品了哈。




快讯:看雪智能设备漏洞挖掘公开课招生中!

上传的附件:
最新回复 (0)
返回