Windows API native: Quand et pourquoi l'utilisation Zw vs Nt préfixé appels api?

Question

Dans l'API native Microsoft exporte deux versions de chaque appel api, un préfixé avec ZW et une avec Nt, par exemple. ZwCreateThread et NtCreateThread.

Ma question est quelle est la différence entre ces deux versions des appels et quand et pourquoi on devrait utiliser Zw ou Nt exclusivement? À ma connaissance la version Zw assure que réside l'appelant en mode noyau, alors que Nt ne fonctionne pas.

Je me demande aussi sur le sens spécifique pour les préfixes Zw et nT / abréviations? On peut deviner Nt se réfère probablement à NT (New Technology) famille Windows ou autochtone (probablement pas)? Quant à ZW, en est-elle pour quelque chose?

Answer 1

Mise à jour:

En plus, il y a une autre chose que je devrais mentionner de la réponse de Larry Osterman (que vous devez définitivement lire):

Étant donné que les variantes NTXXX effectuent des contrôles comme si l'appel vient en mode utilisateur, cela signifie que les tampons transmis à la fonction NtXxs doivent résider dans des espaces d'adresses en mode utilisateur, pas en mode noyau . Donc, si vous appelez une fonction comme NtCreateFile dans votre pilote et passez des pointeurs vers des tampons en mode noyau, vous récupérerez un STATUS_ACCESS_VIOLATION à cause de cela.

---

L'utilisation de versions et Nt Zw des services Routines système natif .

Un pilote en mode noyau appelle la version Zw d'un service de système natif de routine pour informer la routine que les paramètres proviennent d'une source fiable, en mode noyau. Dans ce cas, la routine suppose qu'il peut utiliser en toute sécurité les paramètres sans les valider. Toutefois, si les paramètres peuvent provenir soit d'une source en mode utilisateur ou une source en mode noyau, le pilote appelle la place la version Nt de la routine, qui détermine, en fonction de l'histoire du thread appelant, si les paramètres sont originaires de l'utilisateur mode ou mode noyau.

routines de services système autochtones de faire des hypothèses supplémentaires sur les paramètres qu'ils reçoivent. Si une routine reçoit un pointeur vers un tampon qui a été alloué par un pilote en mode noyau, la routine suppose que le tampon a été alloué dans la mémoire système, et non pas dans la mémoire en mode utilisateur. Si la routine reçoit une poignée qui a été ouverte par une application en mode utilisateur, les regards de routine pour la poignée dans la table de poignée en mode utilisateur, pas dans la table de poignée en mode noyau.

En outre, Zw ne signifie rien. Voir Qu'est-ce que le Zw Prefix Mean :

Les routines de services système Windows natif ont des noms qui commencent par les préfixes et Nt Zw. Le préfixe Nt est une abréviation de Windows NT, mais le préfixe ZW n'a pas de sens. ZW a été choisi en partie pour éviter les conflits de noms potentiels avec d'autres API, et en partie pour éviter d'utiliser les préfixes à deux lettres potentiellement utiles qui pourraient être nécessaires à l'avenir.

Answer 2

J'allais laisser cela comme un commentaire sur la réponse de Merhdad mais il a trop longtemps ...

La réponse de Mehrdad est précis à 100%. Il est également légèrement trompeur. L'article " PreviousMode " lié par le " en utilisant Nt et Zw ... » article Mehrdad va dans plus en détail. paraphrasant: La principale différence entre les appels API et Nt Zw est que les appels Zw passent par le répartiteur d'appel système, mais pour les conducteurs , les appels sont Nt appels directs à l'API.

Quand un pilote appelle une API ZW, l'effet que réel de l'exécution par le répartiteur d'appel système est qu'il met KeGetPreviousMode () à KernelMode au lieu de UserMode (évidemment au code de mode utilisateur, les formes Zw et Nt sont identiques). Lorsque les différents appels système voient que ExGetPreviousMode est KernelMode, ils contournent le contrôle d'accès (car les pilotes peuvent faire quoi que ce soit).

Si un pilote appelle la forme NT des API, il est possible que cela échouera en raison des contrôles d'accès.

Un exemple concret: si un conducteur appelle NtCreateFile, le NtCreateFile appellera SeAccessCheck () pour voir si l'application qui a appelé dans le pilote dispose d'autorisations pour créer le fichier. Si ce même pilote appelé ZwCreateFile, l'appel API NtCreateFile n'appellera pas SeAccessCheck parce ExGetPreviousMode retourné KernelMode et donc le conducteur est supposé avoir accès au fichier.

Il est important pour les auteurs du pilote pour comprendre la différence entre les deux, car il peut avoir des implications profondes pour la sécurité ...