“Jun Koi” wrote in message news:xxxxx@windbg… > the first 8 bytes of this table should point to NtAcceptConnectPort, > so logically NtAcceptConnectPort should have value of > 02f9e20004113300.<br><br>No, the format of the table has changed for 64bit. It no longer points to <br>the functions direction, instead it is an array of 32bit signed offsets plus <br>some control information.<br><br>3: kd> dd nt!kiservicetable l2<br>fffff80002a7fb00 04106900 02f6f000 3: kd> * 3: kd> u (nt!kiservicetable + (04106900 >> 4)) l1 nt!NtMapUserPhysicalPagesScatter: fffff80002e90190 48895c2408 mov qword ptr [rsp+8],rbx<br>3: kd> *<br>3: kd> u (nt!kiservicetable + (02f6f000 >> 4)) l1<br>nt!NtWaitForSingleObject:<br>fffff80002d76a00 4c8bdc mov r11,rsp
>> ln NtAcceptConnectPort > (0000000077a10380) ntdll!NtAcceptConnectPort<br><br>That's the wrong symbol, you're looking at the user mode system service <br>stub. Put the module prefix on the symbol to make sure you get the kernel <br>API:<br><br>ln nt!NtAcceptConnectPort<br><br>-scott<br><br>-- <br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Jun Koi" <xxxxx> wrote in message news:xxxxx@windbg...<br>> hi,<br>><br>> on Win7 x64, i use Windbg (local kernel debugging) , to look into the<br>> KiServiceTable, and i found its content like below:<br>><br>>> dq KiServiceTable<br>><br>> fffff8000268b300 02f9e20004113300 031cb705fff73100 > fffff8000268b310 0315f605031ac106 02b76c0002ba5601<br>> fffff8000268b320 03e0fc000310e200 031bdc4002cf1e00 > fffff8000268b330 02e7ee0103153200 02dfcb8002e25d01<br>> fffff8000268b340 02f24a4002e38302 02dbe10102b04280 > fffff8000268b350 0300de0202da2b02 0321a54103110401<br>> fffff8000268b360 02c7fd0004588705 00408100029d4003 > fffff8000268b370 02f9bd80043f0900 0312140002d08401<br>><br>><br>> the first 8 bytes of this table should point to NtAcceptConnectPort,<br>> so logically NtAcceptConnectPort should have value of<br>> 02f9e20004113300. > > but then i verified the value of this symbol with WinDbg, it returned > a different value > >> ln NtAcceptConnectPort > (00000000`77a10380) ntdll!NtAcceptConnectPort > > > what is wrong here?? > > many thanks, > Jun >
So NtAcceptConnectPort index in service table is 0x60 (not 0). Now on
x64 entries in service table are not pointers to functions:
r$t0=0x60; ln (nt!KiServiceTable+(dwo(nt!KiServiceTable+@$t0*4) >> 4))
Pseudo register t0 contains service index, again for NtAcceptConnectPort
case it’s 0x60.
Btw. you should specify module for the symbol you are looking for. In
your case “ln NtAcceptConnectPort” returned address for
NtAcceptConnectPort API in user mode (NTDLL). Use “ln
nt!NtAcceptConnectPort” to get kernel mode address instead.
Kris
-----Original Message-----
From: Jun Koi [mailto:xxxxx@gmail.com]
Posted At: Thursday, November 11, 2010 7:46 AM
Posted To: windbg
Conversation: Inconsistent value of Syscall table?
Subject: Inconsistent value of Syscall table?
hi,
on Win7 x64, i use Windbg (local kernel debugging) , to look into the
KiServiceTable, and i found its content like below:
On Thu, Nov 11, 2010 at 6:20 PM, Scott Noone wrote: > “Jun Koi” wrote in message news:xxxxx@windbg… >> >> the first 8 bytes of this table should point to NtAcceptConnectPort, >> so logically NtAcceptConnectPort should have value of >> 02f9e200`04113300. > > No, the format of the table has changed for 64bit. It no longer points to > the functions direction, instead it is an array of 32bit signed offsets plus > some control information.
thanks! it was my mistake: i thought the syscall table of 64bit still have the same structure as with 32 bit.
btw, is there any book/paper describing this structure for 64bit OS?
On Thu, Nov 11, 2010 at 7:14 PM, Krzysztof Uchronski wrote: > First of all what makes you think that first element of KiSystemTable on > Windows 7 x64 points to NtAcceptConnectPort? > > kd> uf ntdll!NtAcceptConnectPort > ntdll!NtAcceptConnectPort: > 0000000077b50380 4c8bd1 ? ? ? ? ?mov ? ? r10,rcx<br>> 0000000077b50383 b860000000 ? ? ?mov ? ? eax,60h > 0000000077b50388 0f05 ? ? ? ? ? ?syscall<br>> 0000000077b5038a c3 ? ? ? ? ? ? ?ret > > So NtAcceptConnectPort index in service table is 0x60 (not 0). Now on > x64 entries in service table are not pointers to functions: > r$t0=0x60; ln (nt!KiServiceTable+(dwo(nt!KiServiceTable+@$t0*4) >> 4)) > Pseudo register t0 contains service index, again for NtAcceptConnectPort > case it’s 0x60. > > Btw. you should specify module for the symbol you are looking for. In > your case “ln NtAcceptConnectPort” returned address for > NtAcceptConnectPort API in user mode (NTDLL). Use “ln > nt!NtAcceptConnectPort” to get kernel mode address instead.
i am still new to Windows OS and Windbg, hence these mistakes. Thanks!!! J
On Thu, Nov 11, 2010 at 7:20 PM, Scott Noone wrote: > “Jun Koi” wrote in message news:xxxxx@windbg… >> >> the first 8 bytes of this table should point to NtAcceptConnectPort, >> so logically NtAcceptConnectPort should have value of >> 02f9e200`04113300. > > No, the format of the table has changed for 64bit. It no longer points to > the functions direction, instead it is an array of 32bit signed offsets plus > some control information.
Could you clarify more on the “Control information” above? It seems the lowest 4 bits of each offset index in the table are dedicated for something, but I cannot find any information about that anywhere.