• 【旧文章搬运】更正一个枚举PspCidTable时的错误


    原文发表于百度空间及看雪论坛,2009-02-27

    看雪论坛地址:https://bbs.pediy.com/thread-82919.htm
    ==========================================================================

    PspCidTable现在已经很科普了,关于其具体格式及如何枚举,网上相关文章一大堆,最多的两篇是gz1x和sudami写的。我这里只谈一个问题,就是枚举PspCidTable时cid的上限问题。很多人提到以一个Magic Number为上限,其值为0x4e1c,比如sudami的《PspCidTable杂谈》。虽然大多数时候这个上限已经大到足够用了,但事实上这个上限值是不可靠的,附张图,这个极BT的pid把我雷到了...


    看到这张图后,我自己也写个了程序来验证了一下,更证实了0x4e1c这个值的不可靠。
    程序如下:

    ///////////////////////代码开始////////////////////
    #include "stdafx.h"
    #include <windows.h>
    #include <stdio.h>
    
    DWORD WINAPI ThreadProc(LPVOID lpParameter );
    HANDLE hEvent=NULL;
    int main(int argc, char* argv[])
    {
    
    int i=0;
    DWORD tid=0;
    hEvent=CreateEvent(NULL,FALSE,TRUE,"TEST");
    for (i=0;i<2000;i++)
    {
      
       CreateThread(NULL,0,ThreadProc,NULL,NULL,&tid);
       printf("Runing %d...TID=%d
    ",i,tid);
       Sleep(20);
    }
    while (1)
    {
       Sleep(100);
    }
    return 0;
    }
    
    DWORD WINAPI ThreadProc(LPVOID lpParameter )
    {
    WaitForSingleObject(hEvent,INFINITE);
    return 0;
    }
    ///////////////////////代码开始////////////////////


    虽然ProcessId和ThreadId同样在PspCidTable占位,但是创建线程的开销明显要小于创建进程,因此这里创建2000个线程,而且这个线程里等待一个无信号的事件而进入挂起状态,运行开销也要小得多。(当然也可以直接在创建时就挂起)运行这个程序,可以直接从返回的ThreadId明显感觉到PspCidTable的膨胀。在我把这个程序运行了四次之后,就可以看到pid=25508=0x63A4(此时其线程的tid更大),再运行Windbg可看到其pid=33736=0x83C8,很BT~


    很明显了,0x4e1c这个不知道哪儿来的数(貌似是BlackLight提出的)并不可靠,正确的方法呢?
    正确方法就是以PspCidTable的NextHandleNeedingPool为上限。
    来看一下当前的PspCidTable:

    lkd> dd pspcidtable L1
    805695e0 e1001a00
    lkd> dt _HANDLE_TABLE e1001a00
    nt!_HANDLE_TABLE
       +0x000 TableCode        : 0xe12e4001
       +0x004 QuotaProcess     : (null) 
       +0x008 UniqueProcessId : (null) 
       +0x00c HandleTableLock : [4] _EX_PUSH_LOCK
       +0x01c HandleTableList : _LIST_ENTRY [ 0xe1001a1c - 0xe1001a1c ]
       +0x024 HandleContentionEvent : _EX_PUSH_LOCK
       +0x028 DebugInfo        : (null) 
       +0x02c ExtraInfoPages   : 0
       +0x030 FirstFree        : 0x86d0
       +0x034 LastFree         : 0x86bc
       +0x038 NextHandleNeedingPool : 0x8800
       +0x03c HandleCount      : 8380
       +0x040 Flags            : 1
       +0x040 StrictFIFO       : 0y1

    可以看到NextHandleNeedingPool值为0x8800=34816,这对当前情况来说是个很合理的值。其实由Windows分配句柄表的原理可知,0x8800才是当前句柄表(PspCidTable)的句柄上限,仅当当前Pool已满,不能放下更多对象时,才会再次分配一个一级表,而NextHandleNeedingPool也将增大到0x9000,步长为一个一级表的句柄大小0x800.

    在枚举PspCidTable时就不再用0x4e1c的另一个理由是(当然,前面那张图已经很有说服力了,哈哈):系统自己在枚举句柄表时使用的ExEnumHandleTable函数仍然是调用了ExpLookupHandleTableEntry来实现的。而ExpLookupHandleTableEntry的开头是这样写的:

    ////////////省略无关代码//////////
    MaxHandle = *(volatile ULONG *) &HandleTable->NextHandleNeedingPool;
    
        //
        // See if this can be a valid handle given the table levels.
        //
        if (Handle.Value >= MaxHandle) {
            return NULL;        
        }
    ////////////省略无关代码//////////

    看到了吗?系统也是以NextHandleNeedingPool的值作为当前句柄表中的句柄上限,即使你用0x4e1c来暴力枚举,在超出NextHandleNeedingPool之后也得不到哪怕一个有效的进线程对象。不用多说什么了,以后我们要忘掉0x4e1c,使用NextHandleNeedingPool作为枚举时正确的句柄上限值。

  • 相关阅读:
    CF-911E.Stack Sorting(栈)
    随机算法 && CodeForces
    CF-579D."Or" Game(或运算)
    CF-242E.XOR on Segment(异或线段树)
    莫队 && 洛谷 P1494 [国家集训队]小Z的袜子
    洛谷 P4168 [Violet]蒲公英(分块)
    分块 && 洛谷 P2801 教主的魔法
    启发式合并 && U41492 树上数颜色
    使用mysqlbinlog server远程备份binlog的脚本
    mysqldump备份过程中都干了些什么
  • 原文地址:https://www.cnblogs.com/achillis/p/10181206.html
Copyright © 2020-2023  润新知