MmGetSystemRoutineAddress ,但只从 Ntoskrnl.exe 或 HAL 动态解析导出函数地址。
应该一样啊

调用MmGetSystemRoutineAddress函数获取内存地址的函数如下：
ULONG GetCidAddr()
{
       
        PUCHAR addr;
        PUCHAR p;
        UNICODE_STRING pslookup;       
        ULONG cid;
       
        RtlInitUnicodeString (&pslookup, L"PsLookupProcessByProcessId");       
        //RtlInitUnicodeString (&pslookup, L"PsLookupProcessThreadbyCid");       
        addr = (PUCHAR) MmGetSystemRoutineAddress(&pslookup);//MmGetSystemRoutineAddress可以通过函数名获得函数地址
        KdPrint(("PsLookupProcessByProcessId addr=0x%x\r\n", addr));
        for (p=addr;p<addr+PAGE_SIZE;p++)
        {
                if((*(PUSHORT)p==0x35ff)&&(*(p+6)==0xe8))
                {
                        cid=*(PULONG)(p+2);
                        return cid;
                        //break;
                }
        }
        return 0;
}
在取得addr后用KdPrint打印出，结果如下：
PsLookupProcessByProcessId addr=0xb9f7bdaa
为了验证该函数返回的地址值是否正确
lkd> u PsLookupProcessByProcessId
nt!PsLookupProcessByProcessId:
805d40de 8bff            mov     edi,edi
805d40e0 55              push    ebp
805d40e1 8bec            mov     ebp,esp
805d40e3 53              push    ebx
805d40e4 56              push    esi
805d40e5 64a124010000    mov     eax,dword ptr fs:[00000124h]
805d40eb ff7508          push    dword ptr [ebp+8]
805d40ee 8bf0            mov     esi,eax

证实该地址并非是正确的地址

另外，如果换成取PsLookupProcessThreadByCid地址，则直接BsoD

若你的NTOSKRNL的EAT被修改，这个函数获取的就是错的。
你可以在WINDBG内:
.reload
然后u 0xb9f7bdaa
看看是在哪个模块

至于你PsLookupProcessThreadbyCid获取时BSOD，则是因为你的字母写错了

PsLookupProcessThreadbyCid这个函数，By的"B"是大写的

MmGetSystemRoutineAddress这个函数在XP上有一些问题，若你获取的函数不正确，可能引发蓝屏

正解..........

lkd> .reload
Connected to Windows XP 2600 x86 compatible target at (Mon Sep 21 17:27:25.078 2009 (GMT+8)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
................................................................
..........
Loading User Symbols
...................................
Loading unloaded module list
.............
lkd> dd b9f7bdaa
b9f7bdaa  8b55ff8b 758b56ec 75ff560c b015ff08
b9f7bdba  85b9f833 571e7cc0 00400068 e836ff00
b9f7bdca  ffffe3bc ff85f88b 0e8b0874 33ac15ff
b9f7bdda  c78bb9f8 c25d5e5f cccc0008 cccccccc
b9f7bdea  8b55ff8b 25ff5dec b9f83320 cccccccc
b9f7bdfa  ff8bcccc ffec8b55 dfe80c75 85ffffdc
b9f7be0a  ff4075c0 d9e80c75 85ffffca 563475c0
b9f7be1a  3539f633 b9f855f8 888b2874 b9f85600
lkd> u b9f7bdaa
*** ERROR: Module load completed but symbols could not be loaded for SysGuard.sys
SysGuard+0x3daa:
b9f7bdaa 8bff            mov     edi,edi
b9f7bdac 55              push    ebp
b9f7bdad 8bec            mov     ebp,esp
b9f7bdaf 56              push    esi
b9f7bdb0 8b750c          mov     esi,dword ptr [ebp+0Ch]
b9f7bdb3 56              push    esi
b9f7bdb4 ff7508          push    dword ptr [ebp+8]
b9f7bdb7 ff15b033f8b9    call    dword ptr [SysGuard+0xb3b0 (b9f833b0)]

是不是和什么SysGuard有关？如果EAT被修改，MmGetSystemRoutineAddress不能反应出被修改的内容吗？难道其地址是硬编码的？另外如果EAT被改掉了，不会对系统造成什么别的影响吗？

SysGuard应该是江民的垃圾驱动。他使用这个方法，劫持驱动程序对PsLookupProcessByProcessId的调用。

MmGetSystemRoutineAddress正是使用分析NTOSKRNL的EAT表来获取函数地址的，当然会被它影响。

要准确点的 就得自己读文件重定位  不过还是会被INLINE HOOK  
现在这世道啊

的确是江民的驱动，看来想做的通用一点还是难啊