Click to See Complete Forum and Search --> : Code fragment for a systemcall in windows subsystem dll


reenan
September 23rd, 2007, 10:56 PM
Hello,

I am new to the world of windows programming. I am trying to figure out how the graphics system in windows actually work. From many articles, I read that the dlls have a particular code fragment for system call, as given below:

mov eax, function_index
lea edx, [esp+4]
int 0x2E
ret parameter_number * 4

I am using windows gdi programming book by Mr.Feng Yuan as a reference. I tried to use the code snippets given along with the book, to write a program to list the system calls in gdi32.dll. But I could not find any such code fragment. In fact, when i used a dissassembler to view gdi32.dll, I found the following code pattern being used:

mov eax, function_index
mov edx, 7FFE0300H
call [edx]
ret <value>

Does these two code fragments represent the same? What does the address '7FFE0300' represent? why there is no int 2e call?

I modified my program to search for the above pattern of assembly code at a particular symbol address, and the symbols displayed were the system calls itself. (I used imagehlp library for enumerating the symbols). That is, i got the same output as given in the book. Then why is there a difference in the assembly code? I am working on windows server 2003. I will be extremely thankful if I could get a reply for this.

Thanks,
reenan

googler
September 24th, 2007, 05:50 AM
The book is outdated. Windows NT used to make system calls by executing a software interrupt 0x2E. Intel added a CPU instruction called SYSENTER in the Pentium II that makes it possible to enter kernel mode with less work done by the CPU than a software interrupt. So nowadays the kernel is entered with a SYSENTER instruction. The kernel maps a single page (4K) of shared memory into the user-mode address space of all processes called SharedUserData. On 32-bit systems it's at 0x7FFE0000.
lkd> dt _KUSER_SHARED_DATA 0x7FFE0000
nt!_KUSER_SHARED_DATA
+0x000 TickCountLow : 0x439a2
+0x004 TickCountMultiplier : 0xfa00000
+0x008 InterruptTime : _KSYSTEM_TIME
+0x014 SystemTime : _KSYSTEM_TIME
+0x020 TimeZoneBias : _KSYSTEM_TIME
+0x02c ImageNumberLow : 0x14c
+0x02e ImageNumberHigh : 0x14c
+0x030 NtSystemRoot : [260] 0x43
+0x238 MaxStackTraceDepth : 0
+0x23c CryptoExponent : 0
+0x240 TimeZoneId : 1
+0x244 Reserved2 : [8] 0
+0x264 NtProductType : 1 ( NtProductWinNt )
+0x268 ProductTypeIsValid : 0x1 ''
+0x26c NtMajorVersion : 5
+0x270 NtMinorVersion : 1
+0x274 ProcessorFeatures : [64] ""
+0x2b4 Reserved1 : 0x7ffeffff
+0x2b8 Reserved3 : 0x80000000
+0x2bc TimeSlip : 0
+0x2c0 AlternativeArchitecture : 0 ( StandardDesign )
+0x2c8 SystemExpirationDate : _LARGE_INTEGER 0x0
+0x2d0 SuiteMask : 0x110
+0x2d4 KdDebuggerEnabled : 0 ''
+0x2d5 NXSupportPolicy : 0x2 ''
+0x2d8 ActiveConsoleId : 0
+0x2dc DismountCount : 0
+0x2e0 ComPlusPackage : 0xffffffff
+0x2e4 LastSystemRITEventTickCount : 0x4123e7
+0x2e8 NumberOfPhysicalPages : 0x2ff7c
+0x2ec SafeBootMode : 0 ''
+0x2f0 TraceLogging : 0
+0x2f8 TestRetInstruction : 0xc3
+0x300 SystemCallStub : 0x7c90eb8b
+0x304 SystemCallReturn : 0x7c90eb94
+0x308 SystemCallPad : [3] 0
+0x320 TickCount : _KSYSTEM_TIME
+0x320 TickCountQuad : 0
+0x330 Cookie : 0x1c18aeea
the address 0x7FFE0300 is SharedUserData!SystemCallStub which points to 0x7C90EB8B = ntdll!KiFastSystemCall. There what you have is
ntdll!KiFastSystemCall:
7c90eb8b 8bd4 mov edx,esp
7c90eb8d 0f34 sysenterThe sysenter instruction goes to the address given by MSR 0x176 which is 0x804DE6F0 = nt!KiFastCallEntry.
When the kernel exits, it executes a SYSEXIT instruction which jump to the address given in SharedUserData!SystemCallReturn = 0x7C90EB94 = ntdll!KiFastSystemCallRet, which is just
ntdll!KiFastSystemCallRet:
7c90eb94 c3 retThis ret instruction returns to the code following "call [edx]" in your posting, since that's the last return address pushed on the user-mode stack. :wave:

reenan
September 25th, 2007, 03:48 AM
Thanks A lot!!!! I think I have to look for newer resources for my work. Thanks Again.