eac 反调试_一种可能被用于EAC保护的检测调试器方案

测试环境：

Windows7 x64 虚拟机 win10 1809 x64 虚拟机

0x0 起因

小伙伴 @DBDig 最近也在玩APEX这个游戏，因为这个游戏有EAC保护所以有反调试，遂准备安排它。R3降权pass以后，下断没反应还又卡死又崩溃的。于是他自写了一个exe来模拟调试器的行为，万万没想到，EAC竟然对我们的exe做了这种事！他居然hook了我们的 WaitForDebugEvent这个函数，

头部 retn 10 简单粗暴，怪不得啥都没反应，都收不到调试事件了还调试个锤子?据实测，CE、x64dbg均被同样处理了。且只有游戏被调试了才会被处理，如果就开在那里则不会被处理。可以排除是定时扫进程这种操作了。

问题来了，EAC是怎么找到我们的调试器进程呢？甚至连“自写调试器”也不能幸免？

0x1 猜测

喜闻乐见的瞎蒙时间。被调试程序和调试器之间一定存在着某种神秘的联系，才能让EAC顺藤摸瓜找到我们的调试器。首先想到的就是父进程，父进程是一种手段，然而在调戏游戏的时候大多数采用附加而没有多少机会直接使用调试器启动游戏，因此父进程被排除了。

既然我们从模拟调试器的行为上发现了游戏对我们的程序做了手脚，就继续从这方面入手吧。于是我找到了这个函数：DebugActiveProcess。翻一下msdn,该函数定义如下：

调用完这个函数以后发现它做了一件很重要的事情，那就是创建了一个DEBUG_OBJECT对象。

实际上