Hi

Does somebody know anything about the ntdll.dll function "CsrClientCallServer". It has 4 parameters. What are these parameters? What does the function do? I have seached everywhere but found nothing.

regards
Posted on 2003-09-24 04:56:32 by minor28
Sounds like something from a NT subsystem - possibly CSRSS? In which context are you seeing this function call, and why do you need to mess with it?
Posted on 2003-09-24 05:39:37 by f0dder
You have to take a look at the "Example 6.1: Forking a Win32 Process" and "Example 6.2: Creating a Win32 Process" in Gary Nebbett's book "Windows NT-2000 Native API Reference". Some small description also provided.

In the attachment is just ported by me into asm Gary's Example 6.2. It creates notepad process. I can't remember if I tested it under XP or 2003, but under 2000 works fine for me. Necessary incs and libs you can find in my KmdKit here http://www.masmforum.com/website/tutorials/kmdtute/index.html
Posted on 2003-09-25 04:22:58 by Four-F
Thanks Four-F

I have googled after the article you mentioned. I only find links to bookshops so I have to do without it.

My question about the "CsrClientCallServer" function was raised because of my attempt to penetrate the mystery of creating a process. My intention was to create a process only with nativ functions. I started with an empty winapp templet only with the kernelfunction ExitProcess at the end. I have used your ntdll include and lib. Now I have an exe that creates a new process. A PE-Loader perhaps.

I have studied your attached file. Our codes has many resemblances. I have tested my code only on my computer with win2K sp3.

I still test my code. There are some peculiar things I would like to get an answer to.

1. If I exclude the ExitProcess function the code doesn't work. The code can't start without a loaded kernel32.dll. Any call to a kernel function is required. I suppose i has to do with the kernel exception handling.

2. In the thread context I have loaded the pointer to the end of SEH chain into the EBX register. It seems not to be nessesary.

3. If I make a global thread context the code doesn't work. Only if the context is local it works. So that is why I have CreateThreadProcess function.

The third point is the most puculiar item.

I attach my code.

It would be interesting to know if it works on other machines than mine.

Best regards
Posted on 2003-09-26 07:26:18 by minor28
1. If I exclude the ExitProcess function the code doesn't work. The code can't start without a loaded kernel32.dll. Any call to a kernel function is required. I suppose i has to do with the kernel exception handling.
It's easy. Every exe must import at least any function from any dll other then ntdll. Ntdll mapped into every process even if it's not loaded explicitly. So, if you import only from ntdll it means you doesn't import at all. If exe imports only from ntdll the system refuse to load such exe. So, you have to do any fake import.


3. If I make a global thread context the code doesn't work. Only if the context is local it works. So that is why I have CreateThreadProcess function.
I don't know why but you can do like this:

start proc

LOCAL context:_CONTEXT
. . .
invoke NtCreateThread,...
. . .
start endp
end start

Your code works fine under my w2k+sp2. Sorry, but I don't have time to play with other questions.
Posted on 2003-09-26 08:25:17 by Four-F
It's not just "any" import that's requried - you must import from kernel32.dll - or rather, kernel32.dll must end up being imported - you can import whatever other DLL that ends up importing kernel32.dll. I think the smallest import name is some Arc function in gdi32.dll. Try importing a function from a "dummy.dll", and you'll see that it wont launch on some windows versions.
Posted on 2003-09-26 08:30:47 by f0dder
Yes, as I wrote, I did establish the fact that the kernel32 is required. But the question is why.

My aim with this meaningless project is only to get to know more how windows works. All dll functions are black boxes with lots of code doing marvellous things. My CreateProcess contains about 100 lines. If I use kernel function CreateProcess I only have to write a couple of lines. My 100 lines require 5927 steps to start the process compared to 35871 for the kernel function. On the other hand kernel function works on evry window OS.

So the question remains. Why do I have to map kernel32?

I did an experiment. I compiled the code without kernel mapping to one EXE and another with kernel. Both with dialog.exe as target app.

Then I compiled the code with my CreateProcess with kernel mapping as target. Dialog.exe starts OK.

Then I compiled the code with my CreateProcess without kernel mapping as target. Dialog.exe don't start. I debugged every step of the code and as I could see all steps were OK. Nothing differed from the one that started dialog.exe.

I thouth that I had penetrated the black box. But I only found other black boxes. For example NtOpenFile contains only 4 lines as other Ntfunction. First it loads a servicenumber into EAX register. In this case 64h which seems to be the servicenumber for open a file. Second it loads a pointer to the container of parameters, i.e. the last pushed parameter. Then it call an interupt 2E (for NT i suppose). Last it restores the stack and returns.

On these 4 lines win2k has open a conection to the file on the disk and deliver a filehandle, not in eax register as usual but in one of the parameters. Where is all this done (in the processor ofcouse)? Where can I finde the code related to the servicenumber? Could it be debugged?

I suppose these questions are obvious things for most programmers. I would very much appreciate if someone could enlighten me.

Best regards
Posted on 2003-09-27 02:47:54 by minor28
More confusion. If I replace
;Initilize and count the string. Store in pEXEansi string structure

invoke RtlInitString,addr pEXEansi,addr szEXE
;Convert the string to a unicode string and count. Store in pEXEuni string structure
invoke RtlAnsiStringToUnicodeString,addr pEXEuni,addr pEXEansi,TRUE

;Convert full path to a unicode string. Stor in dospath
invoke RtlDosPathNameToNtPathName_U,pEXEuni.buffer,addr dospath,0,addr ntpath

mov oa.dwLength,sizeof oa
mov eax,ntpath.unknown
mov oa.RootDirectory,eax
mov oa.ObjectName,offset ntpath
mov oa.Attributes,OBJ_CASE_INSENSITIVE
mov oa.SecurityDescriptor,0
mov oa.SecurityQualityOfService,0

invoke NtOpenFile,addr FileHandle,100020h,addr oa,addr iosb,0,0
with
invoke CreateFile,addr szEXE,GENERIC_READ,FILE_SHARE_READ,addr sa,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0
both deliver a FileHandle value of 28h. However the later don't work. NtCreateSection fails. The only visible conection between the file and the createsection is the filehandle. It don't work even if I make the registers equal. It might be because of the available values of desired access.

Any id?as?

Regards
Posted on 2003-09-27 04:29:27 by minor28
But I only found other black boxes.

Step into SoftICE and type exp NtOpenFile. And you will see something like this.

:exp NtOpenFile
ntoskrnl
0008:80576449 NtOpenFile
ntdll
001B:77F7EAF3 NtOpenFile

ntdll!NtOpenFile does nothing except it triggers software interrupt (int2E for NT4 & 2000) and code execution flows into kernel mode. Under XP & 2003 the same is done by sysenter instruction. And all job is done by ntoskrnl!NtOpenFile. You can set breakpoint on it and you will see how much it does.

Inside the Native API

And you can just google - much info can be found.
Posted on 2003-09-27 08:05:30 by Four-F
Thanks Four-F

Now I begin to understand. Nt functions in NTDLL.dll is a sort of springboard to a secret world in NTOSKRNL.EXE. The servicenumber pushed to eax is the number in KiSystemServiceTable to a pointer to NtOpenFile in NTOSKRNL.EXE. A new jumptable i.e.

I don't have SoftIce and I can't debug into NTOSKRNL.EXE. But with PEBrowser i can disassemble it and I can see that NtOpenFile is a new springboard. It just increases the number of parameters from 6 to 14. Very interesting. Then it calls IoCreateFile with a huge number of lines and calls. The exe also import a lot of functions from bootvid.dll and hal.dll.

To penetrate that is beyond my powers. Well I guess it must be a reason why it has to be so complicated. I have to accept black boxes and I do have learnt alot.

I will have a closer look at your KmdKit10. I saw a hal.lib and a ntoskrnl.lib.

Best regard
Posted on 2003-09-27 09:35:03 by minor28
...and I do have learnt alot.
I recommend you to read "Inside Microsoft Window 2000 3rd Edition" by David Solomon & Mark Russinovich. It's not easy reading, by the way, but the book is excellent and unique.
Posted on 2003-09-28 04:52:49 by Four-F