WL 2009 professional【已解决】谢谢nooby跟海风

WL 2009 professional【已解决】谢谢nooby跟海风

研究这个好久了，从中也学习到了不少东西
帮朋友研究XX的反调试,一个没见过的反调试，不能断点,输出是WL 2009
首先当然是用强壮的SOD以及hideod来实验了下了，没通过
然后想到了setinformationthread  简单HOOK了看调用，然后直接给他返回status_successful,测试，不行
翻了翻windows异常处理，

若KiDebugRoutine不为空，则不为空就将Context、陷阱帧、异常记录、异常帧、发生异常的模式等压入栈并将控制交给KiDebugRoutine。当处理完毕用Context设置陷阱帧并返回到上一级例程。(第一次机会)否则把异常记录压栈并调用DbgkForwardException，在DbgkForwardException里判断当前线程ETHREAD结构的HideFromDebugger成员如果为FALSE(为TRUE表示该异常对用户调试器不可见)则向当前进程的调试端口(DebugPort)发送LPC消息。
         |
         |
         |
     当上一步无法处理异常时将Context结构拷贝到用户堆栈，在堆栈中设置一个陷阱帧，陷阱帧的Eip为Ke(i)UserExceptionDisptcher((i)表示这个函数的Ke和Ki打头的符号其实是一回事)，接着返回陷阱处理程序，由陷阱处理程序iret返回用户态执行Ke(i)UserExceptionDispatcher(这个函数虽然是Ke(Ki)打头，却不是内核里的函数。同样性质特殊的还有Ke(i)RaiseUserExceptionDispatcher、Ke(i)UserCallbackDispatcher、Ke(i)UserApcDispatcher。它们的共同特点就是不是被调用的，而是由内核例程设置了陷阱帧TrapFrame.Eip为该函数后iret执行到这里的)。Ke(i)UserExceptionDisptcher调用RtlDispatchException(用户态下的)寻找堆栈中基于帧的异常处理例程(若在XP和2003下先处理VEH再处理SEH)，这个流程大家应该很熟了，就是搜索SEH链表，若都不处理就调用顶层异常处理(TOP LEVEL SEH)例程。当再无法处理时就调用默认异常处理例程终止进程(有VC时这里就换成了VC)。有点不同的是用户态下的RtlDispatchException只判断返回值是ExceptionContinueExecution还是ExceptionContinueSearch。若RtlDispatchException找到异常处理例程能够处理异常，则调用ZwContinue按照设置好的Context结构继续执行，否则调用ZwRaiseException，并且把第三个布尔参数设为FALSE，表示进入第二次机会处理。
         |
         |
         |
     ZwRaiseException经过一系列调用最后直接调用KiDispatchException，由于把布尔值FirstChance设置为FALSE，在KiDispatchException里直接进入第二次机会处理。
         |
         |
         |
     (第二次机会)向进程的DebugPort发消息，若无法处理，则改向进程的ExceptionPort发消息(这里同样如果该异常对用户调试器不可见，则只会发送到ExceptionPort)。DebugPort和ExceptionPort的区别在于，若向ExceptionPort发消息，先停止目标进程所有线程的执行，直到收到回应消息后线程才恢复执行，而向DebugPort发消息则不需要停止线程运行。还有DebugPort是向会话管理器发消息，而ExceptionPort是向Win32子系统发消息，当向ExceptionPort发消息时，已经不给用户态调试器任何机会了:)。
         |


对这种断点后进程退出的现象，确实跟hidefromdebugger吻合，于是又做了个实验，遍历线程然后将+0x248  hidefromdebugger输出一看，这个都是0，疑惑ing
再将这个偏移都写0，还是没效果
跟了下eprocess+debuport没有发现清0代码,从现象上看，debugport清0的现象也不适用
期间还尝试过hook  DbgkForwardException，结果写一半发现这函数有个属性（noninline)T-T，
疑惑ing，没思路已经好几天，盼各位大牛们指点下方向啊，