• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Ay's Blog@CNSSUESTC

            跟群內(nèi)某大牛聊天筆記...... FOR PspCidTable

            僅自己做備忘...


            問題1.pspcidtable不是全局變量嗎?咋個不能聲明直接用?
            結(jié)論:
            因為它沒有導(dǎo)出...? 其實那個SSDT的結(jié)構(gòu)能用是因為它導(dǎo)出了的...

            問題2.(在windbg調(diào)試第三篇的補充內(nèi)容那.....)

            問題3.咋個,以及為什么那個HANDLE的值,TableCode的指針和對象體的指針低2位都要是0?
            結(jié)論:
            為了內(nèi)存對齊~ 這樣,內(nèi)存以4字節(jié)一單位劃分,指針的值是內(nèi)存地址 必須能被4整除,所以指針的開始2位必須為0(必須為4的倍數(shù)) 搜索內(nèi)存的時候就以4字節(jié)為單位搜索 減少搜索時間

            感悟1:

            ? ?? ? if (*(PUSHORT)cPtr == 0x35FF && *(pOpcode + 6) == 0xE8)
            ? ?? ? {
            ? ?? ?? ?pPspCidTable = **(PVOID **)(pOpcode + 2);
            ? ?? ?? ?break;
            ? ?? ? }
            這個代碼是在PsLookUpProcessByProcessId的函數(shù)內(nèi)定位pspcidtable
            我反了下這個PsLookUpProcessByProcessId函數(shù)

            kd> uf nt!PsLookUpProcessByProcessId
            nt!PsLookupProcessByProcessId:
            ......
            805ca42e ff35e0b25580??? push??? dword ptr [nt!PspCidTable (8055b2e0)]
            805ca434 e84bb50300????? call??? nt!ExMapHandleToPointer (80605984)
            ......

            大概就是內(nèi)存特征定位吧 哈哈 紅色標(biāo)注的地方就是pspcidtable的地址拉
            也就是說在整個函數(shù)中,pspcidtable的地址前面是0xff35 后面是 0xe8
            通過這個特征找到0xff35和 0xe8之間的這8字節(jié)的數(shù)據(jù)就是pspcidtable的地址
            當(dāng)然拉看起來不像是吧? 內(nèi)存存放順序跟我們看的不一樣 是以2字節(jié)為單位 壓棧壓進(jìn)去的
            所以邏輯上的順序和內(nèi)存上的順序是正好相反的
            所以紅色字體以2個字節(jié)倒著排過來就是 8055b2e0
            我們拿windbg看看
            kd> dd pspcidtable
            8055b2e0? e1000860 00000002 00000000 00000000

            看 果然是pspcidtable的地址 神奇阿~~

            感悟2:
            記得 <<基于pspCidTable的進(jìn)程檢測技術(shù)>>這篇牛文里面說過獲取pspcidtable的方法還有一個 就是
            KdEnableDebugger->KdInitSystem->KdDebuggerDataBlock
            ->KDDEBUGGER_DATA32->PspCidTable
            這個流程 其實跟那個PsLookUpProcessByProcessId差不多 都是內(nèi)存定位
            但是我們?nèi)旱呐8绺缯f了個更加易用的方法~

            #define GetVar( x )??? ??? (*(PULONG)((*(PULONG)0xffdff034) + (ULONG)(x)))
            PspCidTable = GetVar(0x80);

            就這么簡單....? 原理很簡單...? 0xffdff000是KPCR這個結(jié)構(gòu)變量的地址
            那么0x34就是KdVersionBlock 成員變量在該結(jié)構(gòu)中的偏移
            但是在0xffdff034指向的地方對應(yīng)有個結(jié)構(gòu)_DBGKD_GET_VERSION64
            可惜的是這個結(jié)構(gòu)只有0x28字節(jié)大小 但是....嘿嘿? 這個結(jié)構(gòu)后面藏著N多超級重要的內(nèi)核變量
            我們的pspcidtable這個變量其實就在這個結(jié)構(gòu)起始位置的0x80字節(jié)偏移處~
            如此一來 我拿sp3的xp系統(tǒng)調(diào)試如下:
            kd> dd 0xffdff034
            ffdff034? 80546b38 8003f400 8003f000 80042000

            kd> dd 80546b38+0x80
            80546bb8? 8055b2e0 00000000 8055d708 00000000

            kd> dd pspcidtable
            8055b2e0? e1000860 00000002 00000000 00000000

            其實0xffdff034指向的地方對應(yīng)的結(jié)構(gòu)體應(yīng)該就是傳說中的KDDEBUGGER_DATA32這個結(jié)構(gòu)(windbg看了下說沒這個符號...)?
            typedef struct _KDDEBUGGER_DATA32 {
            ? ???DBGKD_DEBUG_DATA_HEADER32 Header;
            ? ???ULONG? ? KernBase;
            ? ???ULONG? ? BreakpointWithStatus;? ?? ?// address of breakpoint
            ? ???ULONG? ? SavedContext;
            ? ???USHORT? ? ThCallbackStack;? ?? ?? ?// offset in thread data
            ? ???USHORT? ? NextCallback;? ?? ?? ? // saved pointer to next callback frame
            ? ???USHORT? ? FramePointer;? ?? ?? ? // saved frame pointer
            ? ???USHORT? ? PaeEnabled:1;
            ? ???ULONG? ? KiCallUserMode;? ?? ?? ?// kernel routine
            ? ???ULONG? ? KeUserCallbackDispatcher;? ? // address in ntdll

            ? ???ULONG? ? PsLoadedModuleList;
            ? ???ULONG? ? PsActiveProcessHead;
            ? ???ULONG? ? PspCidTable;? ?? ?? ?// <--------- What we need!!
            ? ???//...
            ? ???ULONG? ? MmLoadedUserImageList;
            } KDDEBUGGER_DATA32, *PKDDEBUGGER_DATA32;
            大概就是這樣的 呵呵 里面保存著比較重要的變量比如pspcidtable PsActiveProcessHead
            PsLoadedModuleList等等? 重要的是這個地址貌似是硬編碼進(jìn)去的 也就是說好像只要是NT內(nèi)核的機器這個地址是不會變的,什么?根據(jù)?嘿嘿...
            據(jù)某老外文獻(xiàn)記載:
            ;?Start?of?the?architecturally?defined?section?of?the?PCR.?This?section
            ;?may?be?directly?addressed?by?vendor/platform?specific?HAL?code?and?will
            ;?not?change?from?version?to?version?of?NT.
            ?
            看沒看沒 反正我sp3上機器可以 的確是這個地址 沒錯



            ??????????????????????????????????????????????????????????????????????????????????????????????????????????? ?? __ay.字
            涉及到的學(xué)習(xí)資料
            http://bbs.pediy.com/showthread.php?p=13746
            http://www.0GiNr.com/
            http://bbs.pediy.com/showthread.php?t=73028
            futo 抹句柄表
            Rootkits.com? opc0de



            posted on 2009-01-26 21:04 __ay 閱讀(2923) 評論(1)  編輯 收藏 引用 所屬分類: 操作系統(tǒng)&&內(nèi)核

            Feedback

            # re: 跟群內(nèi)某大牛聊天筆記...... FOR PspCidTable[未登錄] 2010-03-16 18:12 xxx

            西瓜很強悍。。。。。  回復(fù)  更多評論   


            久久嫩草影院免费看夜色| 久久精品视频网| 久久人人爽人人爽AV片| 综合网日日天干夜夜久久| 麻豆AV一区二区三区久久| 久久精品国产免费一区| 综合久久精品色| 精品久久一区二区| 久久精品国产精品亚洲精品 | 中文精品99久久国产| 99热都是精品久久久久久| 精品久久人妻av中文字幕| 亚洲精品白浆高清久久久久久 | 精品久久一区二区三区| 国产亚洲精品美女久久久| 国产一区二区精品久久岳| 久久se精品一区精品二区国产 | 午夜人妻久久久久久久久| 久久91综合国产91久久精品| 国内精品伊人久久久久妇| a高清免费毛片久久| 日产久久强奸免费的看| 国产一区二区精品久久岳| 色偷偷91久久综合噜噜噜噜| 成人久久综合网| 亚洲精品综合久久| 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲 | 久久国产成人午夜AV影院| 久久久久se色偷偷亚洲精品av | 久久人人爽人人爽人人片av麻烦| 丁香五月网久久综合| 人人狠狠综合久久亚洲| 91精品国产综合久久久久久| 久久人人爽人人爽AV片| 久久精品一区二区三区不卡| 久久精品无码午夜福利理论片| 久久久久久久综合狠狠综合| 无码国内精品久久综合88| 午夜精品久久久久久影视riav| 欧美一级久久久久久久大| 青春久久|