[原创]从异常分发流程的实现看反双机调试【有码】
本篇是从异常分发流程的实现看反用户调试器和从3环调试器工作流程的实现看反调试 的后续篇。
由于本人水平有限，错误之处难免，请大神们不吝指正哈！
目录
当一个INT3被执行的时候异常是如何分发的：... 1
内核调试器的工作流程：... 1
内核调试器的执行流程：... 1
主要函数分析... 1
KdEnterDebugger的分析：... 1
KdpSendWaitContinue的分析：... 1
根据内核异常分发流程总结出来的反调试方法：... 1
部分代码和实现(Win7X86Sp1)：...1
方法1：直接调用
KdDisableDebugger ...1
方法2：如果KdDisableDebugger怕别人hook，可以自己实现下 ...1
具体的原理：...1
效果演示：... 1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>正文部分>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
当一个INT3被执行的时候异常是如何分发的：
说明：
1. 不管用户层还是内核层的异常，都会在CommonDispatchException填充异常结构体
2. 这篇文章的主要任务就是研究内核调试器的工作流程，根据流程找到这么防范我们的程序不被内核调试/双机调试
内核调试器的工作流程：
内核调试器的执行流程：
说明：
1. 在KiDispatchException中，如果存在内核调试器，kdpTrap会被赋值给KiDebugRoutine
2. KdpTrap是实际负责内核调试相关业务的函数，里面有大量的switchcase，对各种异常进行处理
3. KdEnterDebugger会获取一个自旋转锁，但是获取的方式的异步的，我们不能直接卡着调试器，但是可以对获取自旋锁做钩子，因为参数是固定的：DdpDebuggerLock，很好判断
4. KdpSendWaitContinue,主要调用KdpSendPacket和KdpReceivePack和winddbg进行交互
主要函数分析
KdEnterDebugger的分析：
我们不能直接卡着调试器，但是可以hookKitryToAcquireSpinLock,判断这个全局变量，如果是就直接蓝屏
KdpSendWaitContinue的分析：
等待windbg的输入
发送数据到windbg：
根据内核异常分发流程总结出来的反调试方法：
1. KernelDebuggerEnabled设置为false，有专门的函数干这个事情: KdDisableDebugger
2. 对KdpReceivePacket和KdpSendPacket做IAT hook，这两个函数在kdcom.sys中导出
3. 把kdpDebuggerLock，但是可以对获取自旋锁做钩子，因为参数是固定的：DdpDebuggerLock，很好判断
4. 直接替换KiDebugRoutine
部分代码和实现(Win7X86Sp1) ----还有两种方法，如果谁有时间可以写下，记得共享下哈
方法1：直接调用 KdDisableDebugger
#include <ntddk.h>
NTSTATUS UnloadDriver(PDRIVER_OBJECT DriverObject)
{
DriverObject;
return STATUS_SUCCESS;
}
NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
RegistryPath;
DriverObject->DriverUnload = UnloadDriver;
KdDisableDebugger();
return STATUS_SUCCESS;
}
注意：上传附件及图片大小不得大于30M。
⚠️ 版权声明：
本博客所有内容（含教程、源码、工具）仅供个人技术学习与研究交流使用，严禁商用、倒卖、二次分发及非法用途。
未经作者书面授权，任何组织或个人不得转载、复制或用于其他平台，违者将追究相关责任。
参与讨论
登录后可查看全部回复并参与讨论。
