僅自己做備忘...
問(wèn)題1.pspcidtable不是全局變量嗎?咋個(gè)不能聲明直接用?
結(jié)論:
因?yàn)樗鼪](méi)有導(dǎo)出...? 其實(shí)那個(gè)SSDT的結(jié)構(gòu)能用是因?yàn)樗鼘?dǎo)出了的...
問(wèn)題2.(在windbg調(diào)試第三篇的補(bǔ)充內(nèi)容那.....)
問(wèn)題3.咋個(gè),以及為什么那個(gè)HANDLE的值,TableCode的指針和對(duì)象體的指針低2位都要是0?
結(jié)論:
為了內(nèi)存對(duì)齊~ 這樣,內(nèi)存以4字節(jié)一單位劃分,指針的值是內(nèi)存地址 必須能被4整除,所以指針的開始2位必須為0(必須為4的倍數(shù)) 搜索內(nèi)存的時(shí)候就以4字節(jié)為單位搜索 減少搜索時(shí)間
感悟1:
? ?? ? if (*(PUSHORT)cPtr == 0x35FF && *(pOpcode + 6) == 0xE8)
? ?? ? {
? ?? ?? ?pPspCidTable = **(PVOID **)(pOpcode + 2);
? ?? ?? ?break;
? ?? ? }
這個(gè)代碼是在PsLookUpProcessByProcessId的函數(shù)內(nèi)定位pspcidtable
我反了下這個(gè)PsLookUpProcessByProcessId函數(shù)
kd> uf nt!PsLookUpProcessByProcessId
nt!PsLookupProcessByProcessId:
......
805ca42e ff35
e0b25580??? push??? dword ptr [nt!PspCidTable (8055b2e0)]
805ca434 e84bb50300????? call??? nt!ExMapHandleToPointer (80605984)
......
大概就是內(nèi)存特征定位吧 哈哈 紅色標(biāo)注的地方就是pspcidtable的地址拉
也就是說(shuō)在整個(gè)函數(shù)中,pspcidtable的地址前面是0xff35 后面是 0xe8
通過(guò)這個(gè)特征找到0xff35和 0xe8之間的這8字節(jié)的數(shù)據(jù)就是pspcidtable的地址
當(dāng)然拉看起來(lái)不像是吧? 內(nèi)存存放順序跟我們看的不一樣 是以2字節(jié)為單位 壓棧壓進(jìn)去的
所以邏輯上的順序和內(nèi)存上的順序是正好相反的
所以紅色字體以2個(gè)字節(jié)倒著排過(guò)來(lái)就是 8055b2e0
我們拿windbg看看
kd> dd pspcidtable
8055b2e0? e1000860 00000002 00000000 00000000
看 果然是pspcidtable的地址 神奇阿~~
感悟2:
記得 <<基于pspCidTable的進(jìn)程檢測(cè)技術(shù)>>這篇牛文里面說(shuō)過(guò)獲取pspcidtable的方法還有一個(gè) 就是
KdEnableDebugger->KdInitSystem->KdDebuggerDataBlock
->KDDEBUGGER_DATA32->PspCidTable
這個(gè)流程 其實(shí)跟那個(gè)PsLookUpProcessByProcessId差不多 都是內(nèi)存定位
但是我們?nèi)旱呐８绺缯f(shuō)了個(gè)更加易用的方法~
#define GetVar( x )??? ??? (*(PULONG)((*(PULONG)0xffdff034) + (ULONG)(x)))
PspCidTable = GetVar(0x80);
就這么簡(jiǎn)單....? 原理很簡(jiǎn)單...? 0xffdff000是KPCR這個(gè)結(jié)構(gòu)變量的地址
那么0x34就是KdVersionBlock 成員變量在該結(jié)構(gòu)中的偏移
但是在0xffdff034指向的地方對(duì)應(yīng)有個(gè)結(jié)構(gòu)_DBGKD_GET_VERSION64
可惜的是這個(gè)結(jié)構(gòu)只有0x28字節(jié)大小 但是....嘿嘿? 這個(gè)結(jié)構(gòu)后面藏著N多超級(jí)重要的內(nèi)核變量
我們的pspcidtable這個(gè)變量其實(shí)就在這個(gè)結(jié)構(gòu)起始位置的0x80字節(jié)偏移處~
如此一來(lái) 我拿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
其實(shí)0xffdff034指向的地方對(duì)應(yīng)的結(jié)構(gòu)體應(yīng)該就是傳說(shuō)中的KDDEBUGGER_DATA32這個(gè)結(jié)構(gòu)(windbg看了下說(shuō)沒(méi)這個(gè)符號(hào)...)?
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等等? 重要的是這個(gè)地址貌似是硬編碼進(jìn)去的 也就是說(shuō)好像只要是NT內(nèi)核的機(jī)器這個(gè)地址是不會(huì)變的,什么?根據(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.
?
看沒(méi)看沒(méi) 反正我sp3上機(jī)器可以 的確是這個(gè)地址 沒(méi)錯(cuò)
涉及到的學(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