这个系列计划分为上下两部，上部是内置型辅助，下部是按键型辅助。我不保证会写完。

聊聊游戏辅助那些事上部第一篇——过掉那些讨厌的游戏保护。

相对以前那些裸奔游戏，现在的新游戏多少都会有些保护，这是绕不过去的坎。

下面针对我发现的几个保护方法，逐个的聊一聊。

1、R3应用层下，DebugActiveProcess 加载调试器时，会设置一个远程断点，而这个远程断点其实多此一举，反而有时会触发反调试检测。唯一要做的就是绕过它。

这是NtDebugActiveProcess的上层函数，DbgUiDebugActiveProcess的反汇编代码：
_NtDebugActiveProcess@8 (775909A4h) 
7760FC64  mov         esi,eax        // 原始返回地址
7760FC66  test        esi,esi 
7760FC68  jl          _DbgUiIssueRemoteBreakin@4 (7760FC03h) 
7760FC72  mov         esi,eax 
7760FC74  test        esi,esi 
7760FC76  jge         _DbgUiStopDebugging@4 (7760FB88h) 
7760FC80  mov         eax,esi 
7760FC82  pop         esi        // +0x1E后的返回地址
7760FC83  pop         ebp 
7760FC84  ret         4 

下面是64位 WINDOW7 下面的 NtDebugActiveProcess 的钩子函数的具体代码，绕过远程断点的方法是在返回地址上加偏移0x1E

2、如果保护程序有驱动，那么在R0核心层下调试端口清零会是绝大多数游戏保护的选择。进程的调试端口保存了一个调试器对像，当有异常发生时，操作系统的异常处理程序会查询这个端口，如果存在调试器，就会将异常发送给调试器，调试器会优先获得异常处理的权利。

网上有不少方法，这儿采用自建调试端口管理的方法绕过它，呵呵，你想清零就清零，反正我又不用它。直接上获取设置调试端口的相关代码。

这是真正的核心代码，注意看注释。后面的 DeviceIoControlDispatch 会调用这个函数。

但是用 OnNtDebugActiveProcess 加载那是完全不调试，因为这个函数不用你清零调试端口了，我自己就直接清零了。然后就要对DbgkForwardException下钩子，让我们自己保存的调试端口发挥作用。具体代码。

上面的两个函数用到了几个没有导出的核心函数，这就需要自己定位相关的函数了，这里就不再展开定位的方法了。

调试器在应用层需要添加钩子函数：DbgNtDebugActiveProcess64，与前面的 DbgNtDebugActiveProcess64 的差别在不再调用 TrueNtDebugActiveProcess，而是通过 DeviceIoControl 调用我们自己的NtDebugActiveProcess

3、调试器对像降权。当系统的调试器对像的访问权限被设置为零时，表现为附加不上所有程序，游戏保护让我们创建的调试对像成为没有调试权限的调试对像。处理方法：重建一个调试对像类型，然后替换掉系统的调试对像类型。

DbgkDebugObjectType 为系统内核调试器对像地址，可以通过符号搜索获取地址。TP在启动后会让所用的附加或启动调试失败，然后我们来这么一下，整个世界就安静了。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课