http://hi.baidu.com/%5Fachillis/blog/item/77a35bfa1de09f6d034f56a0.html

非常感谢achillis如此快速的回复。
    我看您提供这个网页提供的方法是针对ExAllocatePool、ExAllocatePoolWithTag、KeDelayExecutionThread进行的检测，来检测因为这些函数被hook而产生的无主的可执行代码，据我对RKU的分析，这只是他所用的众多方法中的一种，而我在问题里面所说的那个疑问是针对Stealth Code模块的最后一种方法。
    据我的理解，最后一种方法的思路如下：
    因为Windows内核模块一般都是由任务管理器中名为“System”的系统进程加载的，故而在DriverEntry函数执行时所对应的进程即为系统进程；
    另外，获取 RKU专门检测可疑线程的函数对应的线程。已知：若一个线程的teb为null，则该线程为系统线程。 若所获取的线程不符合上述条件，则该线程即为非系统线程。
    若一个非系统线程出现在系统进程内部，则定义该线程为可疑线程，并输出相应信息。
    具体汇编代码如下：
push    ebp
push    edi
call    ds:IoThreadToProcess
mov     ecx, g_Teb_offset_in_kthread
mov     ebp, eax
xor     eax, eax
cmp     [ecx+edi], eax  ; 判断teb的值是否为0，若为0 ，则说明该线程为系统线程
mov     ebx, 250h
setnz   al
xor     ecx, ecx
cmp     ebp, g_System_PEPROCESS
setz    cl
test    eax, ecx
jz      short loc_122C4

mov     eax, [esi]
imul    eax, 0B58h
add     eax, esi
lea     ecx, [eax+74Ch]
mov     edx, offset s->SuspiciousThread ; "suspicious thread"
mov     dword ptr [eax+130h], 3
mov     [eax+0FCh], edi
mov     [eax+104h], ebx
call    rk_RtlCopyWString
inc     dword ptr [esi]
上面的文字阐述是我自己对这个方法的理解，不知道对不对，请多多指教！

你说的算是一种情况吧，我并没有详细分析RKU的检测方法，我文章中提到的检测线程StartAddress也算一种，记录那三个函数的返回地址并判断也算一种，都是黑盒来的~

哦，是，RKU的Stealth Code模块确实用了那两种方法，但是，我就很奇怪，为什么我说的那种方法，执行结果与RKU的不一致呢？是不是我理解错了？

还有，我想请问下achillis，您说的那个检测线程StartAddress方法是不是枚举出所有进程中的线程，判断每个线程是不是在制定模块内？

是的~123456

不好意思，achillis，还想请教您一个问题：为什么我按照你说的那种根据线程StartAddress判断其是否在指定的模块空间内时，应该被指明为“可疑线程”的线程结果却是正常的，反而正常的却被报错？
                        eThread = (PETHREAD)_obj;
                        KdPrint(("Thread: %X  , StartAddress: %X \n",eThread , *(ULONG *)((ULONG)eThread + 0x224)));//StartAddress地址
                        if (TheAddressIsInKernelPEBody(rCon, *(ULONG *)((ULONG)eThread + 0x224)))
                        {
                                KdPrint(("Suspicious Thread \n"));
                        }
多谢指教！