Sysinternals Homepage
Forum Home Forum Home > Windows Discussions > Internals
  New Posts New Posts RSS Feed - Viewing SYSENTER in Windbg
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Viewing SYSENTER in Windbg

 Post Reply Post Reply
Author
Message
JadedUk View Drop Down
Newbie
Newbie


Joined: 08 February 2008
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote JadedUk Quote  Post ReplyReply Direct Link To This Post Topic: Viewing SYSENTER in Windbg
    Posted: 08 February 2008 at 3:37am
Going through some Windows Internals stuff at the moment (including Russinovich & Solomon's excellent book) and am currently looking in particular at system service dispatching on XP/2003.
 
Getting curious I decided to load up Windbg in local kernal mode to see if I could actually see the SYSENTER instruction in the kernel's KiFastCall function.
 
Checking out a couple of other website postings (including this one at code guru: http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8223__2/) I started by unassembling ntdll!ZwCreateMutant.  I could see the calls to SystemCallStub so did the same to that.  I expected to see, as in the article, the following:
 
SharedUserData!SystemCallStub:
7ffe0300 8bd4             mov     edx,esp
7ffe0302 0f34             sysenter
7ffe0304 c3               ret

 
 
...But, instead, I saw this:
 
 
SharedUserData!SystemCallStub:
7ffe0300 8beb            mov     ebp,ebx
7ffe0302 90              nop
7ffe0303 7c94            jl      SharedUserData+0x299 (7ffe0299)
7ffe0305 eb90            jmp     SharedUserData+0x297 (7ffe0297)
7ffe0307 7c00            jl      SharedUserData!SystemCallStub+0x9 (7ffe0309)
7ffe0309 0000            add     byte ptr [eax],al
7ffe030b 0000            add     byte ptr [eax],al
7ffe030d 0000            add     byte ptr [eax],al
 
 
This puzzled me and I continued trying to unassemble more and more of the function thinking that perhaps the article showed an 'edited' part of the unassembled code, but still couldn't see it.
 
I googled SYSENTER and WinDbg and fortunately (as is rarely the case) found a question on a forum that described exactly my problem.  There was only a single answer - which was this:
 
try this 
 
0:000> u poi(7ffe0300) 
 
ntdll!KiFastSystemCall: 
 
7c82ed50 8bd4             mov     edx,esp 
 
7c82ed52 0f34             sysenter
 
 
Sure enough I tried exactly the same thing and it worked.  Infuriatingly, there was no explanation as to why I needed to dereference a pointer at this address to view the sysenter code.  What made it all the more frustrating was that the answer given appeared to be from a Microsoft employee!
 
Can anyone explain why I need to use POI() to view this code?  Have I misunderstood the output of the 'u' command in Windbg?  I thought the left hand column was the address of the opcode in memory - so it has doubly confused me as to how poi() can dereference this address as a pointer and appear to list code found at it!
 
Any pointers would be gratefully received (no pun intended).
 
Many Thanks.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17531
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 5:39am
Hi JadedUK,

You might find this of interest:
Quote Since my system is Srv03 SP1, SystemCall is a pointer to a stub in NTDLL.
 
0:001> u poi(0x7ffe0300)
ntdll!KiFastSystemCall:
7c82ed50 8bd4             mov     edx,esp
7c82ed52 0f34             sysenter
ntdll!KiFastSystemCallRet:
7c82ed54 c3               ret
 
It is also perhaps worth noting that the CodeGuru article you referenced is dated very shortly after the release of XP SP2, so the author may not have had a chance to work with XP 2 prior to writing / editing / posting the article.  
 
In the referenced link, Skywing states:
Quote In XP SP2 and Srv03 SP1, in the interests of reducing system attack surface, the KUSER_SHARED_DATA region was marked non-executable, and SystemCall becomes a pointer to a stub residing in NTDLL
 
If you look at the opcodes for the addresses you posted for your inital attempt at unassembling SharedUserData!SystemCallStub, you'll see that rather they are memory addresses.
Quote 8beb
90 
7c94
eb90
7c
 
7c90eb8b
7c90eb94
 
So SharedUserData!SystemCallStub pointed at 7c90eb8b in your case.


Edited by molotov - 08 February 2008 at 5:50am
Daily affirmation:
net helpmsg 4006
Back to Top
JadedUk View Drop Down
Newbie
Newbie


Joined: 08 February 2008
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote JadedUk Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 6:53am
Many thanks, Molotov.  I was trying this on an XP SP 2 machine and the link explains it.
 
So prior to SP2 the SystemCall used to contain the actual code, but now it contains a pointer to a stub in NT.DLL which is why I needed to derefernce the pointer at that position instead of being able to see the code.
 
Evidently still don't fully understand the output of 'u', though, and how you arrived at the memory addresses at the end of your reply above.  I'm still confused over the line in my initial post:
 
7ffe0300 8beb            mov     ebp,ebx
 
I thought that 7ffe0300 was the memory address of this particular instruction, so how come when I call poi() on the same address I get the instructions for sysenter?  I'm sure I'll get there.
 
Thanks Again.
Back to Top
niar View Drop Down
Newbie
Newbie


Joined: 10 June 2007
Location: United Kingdom
Status: Offline
Points: 24
Post Options Post Options   Thanks (0) Thanks(0)   Quote niar Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 7:59am
hi, JadedUk, take a look at following code:
ntdll!NtCreateFile:

7c90d682 b825000000      mov     eax,25h
7c90d687 ba0003fe7f      mov     edx,offset SharedUserData!SystemCallStub (7ffe0300)
7c90d68c ff12            call    dword ptr [edx]
7c90d68e c22c00          ret     2Ch

Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17531
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 8:33am
Consider:
Quote 0:001> u 7ffe0300
SharedUserData!SystemCallStub:
7ffe0300 8beb            mov     ebp,ebx
7ffe0302 90              nop
7ffe0303 7c94            jl      SharedUserData+0x299 (7ffe0299)
Quote 0:001> dd 7ffe0300
7ffe0300  7c90eb8b 7c90eb94
 
Look at the bytes in bold - do they look familiar? (0x7c908beb)
The stub is a pointer to the function at 0x7c908beb.  u 7ffe0300 attemps to unassemble something that is not a function.
Daily affirmation:
net helpmsg 4006
Back to Top
JadedUk View Drop Down
Newbie
Newbie


Joined: 08 February 2008
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote JadedUk Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 9:01am
Thankyou!  I see.  So, u has just attempted to translate whatever it's found at that address even though it's actually a storage location containing the pointer and not valid code? 
 
Many thanks again.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17531
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 9:54am
From the DTW Debugger.chm:
Quote u (Unassemble)
The u command displays an assembly translation of the specified program code in memory.
Daily affirmation:
net helpmsg 4006
Back to Top
JadedUk View Drop Down
Newbie
Newbie


Joined: 08 February 2008
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote JadedUk Quote  Post ReplyReply Direct Link To This Post Posted: 08 February 2008 at 2:04pm

Thanks, Molotov.  I've realised that for some reason I thought the u command would be able to distinguish between actual code and storage.  Now I look back on it, it seems ridiculous that I would think that when all it does is dump memory contents and give it's best shot at helpfully translating into code :)

I guess I've just been spoilt by years of working with IDEs :)
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 11.06
Copyright ©2001-2016 Web Wiz Ltd.