Discussion :

[Shinitoku]

Bonjour,

Je suis actuellement étudiant en BTS IRIS, je recherche une définition qui peux m'expliquer clairement ce que sont les API bas niveau, car depuis le début de mon projet on en parle mais on ne le définie pas et donc rien n'est clair pour moi. J'utilise des API bas niveau dans la création d'un driver Windows mais je ne sais pas dire ce que c'est. J'ai fais plusieurs recherche qui ne furent pas fructueuses voila la raison de ce post.

Merci si réponse il y a.

[Mat.M]

C'est vraiment tout simple ! les API bas-niveau ce ne sont ni plus ni moins que des fonctions qui s'intercalent entre le CPU ou le système ( disque dur, vidéo ) et le système d'opération !
Je ne connais pas la programmation de Device Drivers mais si tu appelles telle ou telle fonction bas-niveau par exemple pour aller écrire sur le disque-dur l'OS va interprêter cette fonction et agir en conséquence.
Dans un système informatique tu as :
*la couche matérielle avec le CPU, la RAM, le disque dur
*la couche gestionnaire de périphériques ou device drivers qui permettent de faire une interaction etre l'OS et le matériel
*et l'OS comme Windows avec ses menus et fenêtres

[Shinitoku]

Merci de ta reponse je commence a comprendre un peu mieu

[Médinoc]

Il y a aussi ce qu'on appelle, sous Windows, "L'API Native" dee Windows NT, qui se situe au niveau en-dessous de l'API Win32.

Sinon, j'ai aussi connu un prof de C qui appelait "fonctions bas niveau" les fonctions POSIX-like de gestion des flux en C (open, read, write, close), mais sous Windows, il y a encore plus bas niveau que ça: open() repose sur la fonction Win32 CreateFile(), qui repose sur la fonction Native NtCreateFile() et encore en-dessous, je n'ai pas bien compris si NtCreateFile() repose sur la fonction kernel-mode ZwCreateFile() ou non.

[homeostasie]

mais sous Windows, il y a encore plus bas niveau que ça: open() repose sur la fonction Win32 CreateFile(), qui repose sur la fonction Native NtCreateFile() et encore en-dessous, je n'ai pas bien compris si NtCreateFile() repose sur la fonction kernel-mode ZwCreateFile() ou non.

Les fonctions Nt* sont des fonctions privées dont les adresses sont contenues dans la SSDT.
Les fonctions Zw* sont exportées par le noyau via Ntoskrnl.exe pour être utilisées notamment par les drivers.

De ce que j'ai cerné de mon côté, car je m'étais déjà posé cette question pour effectuer du developpement noyau.
Pour une application en mode utilisateur, un appel système engendre un moment donné un appel dans Ntdll.dll. Cette DLL charge dans le registre EAX le numéro de service correspondant à une fonction du noyau équivalente, notamment l'appel à une fonction de l'API native de la forme Nt*. Puis une instruction INT 2E ou SYSCENTER est provoquée pour effectuer un trap vers le noyau.
Pour une application en mode noyau, l'appel d'une fonction de type Zw* fait le même travail que celui décrit précédemment mais avec la possibilité d'avoir accès à plus de paramètres.

Dans les 2 cas, on aura un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
mov eax, 25h      ; 
mov edx, 7FFE0300h
call dword ptr [edx]      ; appel de KiFastSystemCall
retn 2Ch

Mais je recommence à avoir un petit doute... Il est possible que dans les 2 cas, ca soit au final le même code qui soit exécuter. Vais-je devoir à nouveau debugger?!

[Médinoc]

Ça me parait bizarre, car ZwCreateFile() possède exactement le même prototype que NtCreateFile() et est supposée être appelée quand on est déjà en kernel-mode...

C'est pourquoi j'ai l'impression qu'après le KiFastSystemCall() de NtCreateFile(), on se retrouve dans ZwCreateFile()... (ou dans une fonction interne qui serait wrappée par celle-ci).

[homeostasie]

Ça me parait bizarre, car ZwCreateFile() possède exactement le même prototype que NtCreateFile() et est supposée être appelée quand on est déjà en kernel-mode

Quand je faisais référence au nombre de paramètres, c'était en comparaison de CreateFile et ZwCreateFile.

Après m'être renseigné plus amplement à partir d'une source.
En mode utilisateur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
kd> u ntdll!ZwReadFile
ntdll!NtReadFile:
77f761e8 b8b7000000       mov     eax,0xb7
77f761ed ba0003fe7f       mov     edx,0x7ffe0300
77f761f2 ffd2             call    edx
77f761f4 c22400           ret     0x24

So, to summarize the flow of a native API call from User Mode

User Mode program calls either NtXxx or ZwXxx, both of which point to the same location.

All native API calls from User Mode have a body that simply loads an index into EAX, executes SystemCallStub, and returns.

SystemCallStub saves a pointer to the top of the User Mode stack into EDX and executes a SYSENTER instruction.

SYSENTER disables interrupts, switches the thread into Kernel Mode and executes the instruction located in the SYSENTER_EIP_MSR (which on XP SP1 is KiFastCallEntry).

KiFastCallEntry builds a trap frame so it knows where to go when returning back to User Mode, enables interrupts, and jumps into KiSystemService

KiSystemService, amongst doing other things, copies the parameters from the User stack (pointed to by EDX) and takes the value previously stored in EAX and executes the function located at KiServiceTable[EAX].

The native API now executes in Kernel Mode with the previous mode of the thread set to User Mode.
This indicates the caller came from User Mode. If you are going to remember one thing about this exercise, remember this! We?ll talk about it much more later in this article.

Now that we have gone through a gross amount of detail for the User Mode portion, we should be able to zip right through the Kernel Mode variants.

En mode noyau:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 kd> u nt!ZwReadFile
nt!ZwReadFile:
80504d4c b8b7000000       mov     eax,0xb7
80504d51 8d542404         lea     edx,[esp+0x4]
80504d55 9c               pushfd
80504d56 6a08             push    0x8
80504d58 e89e550300       call    nt!KiSystemService (8053a2fb)
80504d5d c22400           ret     0x24

So, to summarize the flow of a native API call from Kernel Mode:
Case A:
* Kernel Mode component calls NtXxx
* This is a direct call to the function that implements the system service. The call does not change previous mode.

Case B:
* Kernel Mode component calls ZwXxxx
* This leads to a step that puts the system service code (index value) into EAX, and a pointer to the arguments that have already been pushed onto the (Kernel Mode) stack into EDX.
* Then calls KiSystemService, which amongst doing other things, copies the parameters from the location pointed to by EDX and takes the value previously stored in EAX and executes the function located at KiServiceTable[EAX].
* The native API now executes (still in Kernel Mode) with the previous mode set to Kernel Mode. This indicates the caller came from Kernel Mode.

Ca clarifie le principe de fonctionnement!

[Médinoc]

Merci.

On notera donc que Microsoft recommande, en Kernel-mode, la méthode B.

[homeostasie]

Oui tout à fait!

D'ailleurs:

So, it?s clear that calling NtXxx directly has less overhead, but calling ZwXxxx changes previous mode. So, what?s up with that? It seems like previous mode must be something pretty important.

Grossomodo, lors d'un appel directement à une fonction de l'API native Nt*, le "previous mode" reste inchangé et donc le noyau pourrait arbitrairement utiliser la pile précédemment utilisée lors d'un appel en mode utilisateur. De plus le fait que le code soit exécuté avec une origine user au lieu de kernel, on risquerait d'avoir un échec lors de cet appel.