由如何绕过IS进程检测说起

  对于进程检测来说就是要尽可能枚举全系统内所有EPROCESS对象的指针。IceSword120_cn设了4道障碍来阻止及发现隐藏进程：
1. 先调用ExEnumHandleTable函数枚举PspCidTable句柄表中所有进程对象的指针，将指针结合放到一个缓冲区中。
2. 调用NtQuerySystemInformation枚举系统句柄信息，搜索csrss.exe打开的所有进程类句柄，再得到相应EPROCESS对象指针，并比较该进程对象指针是否已在上述缓冲区中，若没有则添加。
3. 通过PEPROCESS->Vm.WorkingSetExpansionLinks链表枚举进程对象，若缓冲区内没有则添加。
4. 从0x81000030-0x8116xxxx之间搜索EPROCESS结构指针。
  在这其中就可以钻IS的空子：为了与枚举出来的线程对象区分，IS在判断一个对象是不是进程对象时用到了进程id（在ExEnumHandleTable的回调例程中用到），POBJECT_HEADER->Type域（对于进程对象该值应该是*PsProcessType）
以及PEPROCESS->Pcb.Header.Type（进程对象该值为3）。综上，可以把我们要隐藏的进程对象“伪装”成一个线程对象，涂改掉PID，以达到让IS程序误判的目的，这样一来便绕过了检测。改掉这3项后，事实证明也绕过了DS1.0.5的检测。
  DKOM的最大缺点就是它的不稳定性，随即这里面也就有一个问题：这样经过隐藏的进程对象会不会变得不稳定呢？这点我确实不太清楚，但目前给我的感觉就是如果你的进程与OS或其它程序交互很少的话似乎不会有什么影响。

  另一方面，这种方法在RkU v3.30.150.400中就会BSOD，这也好，因为用户会以为是RkU的问题=) 在它的帮助文档上有这样几句说明：

Hidden processes detection

Detection of processes hidden from Windows API
Most powerful in the world at the current time
Detection of processes with full path and name (unique)

  那么我们就看看它用到了什么“Most powerful”tech，RkU设了两道障碍：
1. 从(*PspCidTable)->TableCode所指地址开始0x1000字节范围内，专门搜索线程对象指针，然后通过调用IoThreadToProcess得到相应进程对象。
2. 在XP以上OS中，用特征搜索的方式获得内核线程调度链表头KiWaitListHead，然后通过遍历该链表获取部分进程对象的指针。
  BSOD的原因大家应该已经知道了，这里不再赘述。感觉俄罗斯人做东西挺变态的。

只是一种思路 :) 最近被cardmagic给搞郁闷了,哈哈

恩,崩溃确实很有可能,我也只是在xp sp2下试过,代码是在fu上加的, pid赋的0xffffffff

你是写流氓还是写rk啊,流氓的做法估计会让anti的作者们鄙视的