程序运行后输入回车验证，没有任何提示，于是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层循环枚举：

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

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界