Fonctions de ntdll.dll (DDK)

**camboui** · 09/03/2010, 12h37

J'ai installé le DDK pour pouvoir faire appel à certaines fonctions qui ne se touvent pas dans l'API.

J'ai eu quelques difficulté avec les include, par exemple
#include <windows.h>
#include <ntddk.h>
ensemble ne font pas bon ménage.

Ensuite il y a un problème de link car une fonction est définie dans deux modules, ntdll.lib et libcmtd.lib

Comment résoudre cette ambiguité ?
Merci.

**Mac LAK** · 09/03/2010, 12h46

Le DDK est fait pour créer du code kernel, pas du code user... C'est normal que les deux entêtes principaux se bouffent le nez, et ce n'est pas prêt de s'arranger !

**camboui** · 09/03/2010, 13h12

Ok, ça c'est résolu en utilisant des .cpp différents.

Reste le problème de link. En fait en link dynamique c'est OK mais en link statique ça ne passe pas

Une idée pourquoi ?

**Mac LAK** · 09/03/2010, 13h17

Envoyé par camboui

Reste le problème de link. En fait en link dynamique c'est OK mais en link statique ça ne passe pas

Tu ne peux PAS mélanger du code niveau kernel et niveau user dans le même processus... Ce n'est pas parce que ça linke que ça va marcher, ou que ça passera sur une machine "normale" (= sans le DDK installé).

Si tu veux utiliser une fonction kernel dans un programme en mode user, tu dois créer un driver dédié (ou utiliser un driver existant effectuant le boulot) qui fera le "pont" entre les deux mondes. C'est la seule méthode réellement propre et fiable.

En l'occurrence : quelle(s) fonction(s) kernel cherches-tu à utiliser ?

**camboui** · 09/03/2010, 13h31

L'API a certaines lacunes qui sont comblées par des fonctions dispo ailleurs ou non documentées.

Je suis en mode user, je cherche simplement à utiliser les fonctions ZwXxx qui se trouvent dans ntdll.dll. En particulier ZwQueryInformationFile().
Le but est de faire du logging en cas d'erreur IO. Je ne trouve pas qu'il soit utile de stocker les informations en amont, infos dont je n'ai pas besoin en tant normal. Je souhaite que l'OS me fournisse cette info si nécessaire.
Exemple typique: retrouver le nom d'un fichier dont on ne connait que le handle.

**homeostasie** · 09/03/2010, 14h51

Au lieu de passer par un driver afin d'exécuter du code kernel comme l'a dit Mac LAK pour utiliser des fonctions de type Zw(n)*(x), passe par la récupération de l'adresse de ta fonction exportée par le module ntdll.
Pour cela, utilise GetProcAddress().

Allez je mets un exemple pour la fonction NtQueryInformationFile():

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
typedef long NTSTATUS;

typedef NTSTATUS (NTAPI *NTQUERYINFORMATIONFILE)(
    IN  HANDLE                 FileHandle,
    OUT PIO_STATUS_BLOCK       IoStatusBlock,
    OUT PVOID                  FileInformation,
    IN  DWORD                  Length,
    IN  FILE_INFORMATION_CLASS FileInformationClass
    );

NTQUERYINFORMATIONFILE NtQueryInformationFile = NULL;

int main()
{
    NTSTATUS status = -1;
    HMODULE hNtdll = NULL;

    hNtdll = LoadLibrary("ntdll.dll");
    if(hNtdll == NULL)
        return EXIT_FAILURE;

    NtQueryInformationFile = (NTQUERYINFORMATIONFILE)GetProcAddress(hNtdll, "NtQueryInformationFile");
    if(NtQueryInformationFile == NULL)
        return EXIT_FAILURE;

    // Utilisation de NtQueryInformationFile() à ta guise

    FreeLibrary(hNtdll);

    return 0;
}

Je te laisse définir les structures nécessaires pour pouvoir compiler.

;-)

**Mac LAK** · 09/03/2010, 14h51

Envoyé par camboui

L'API a certaines lacunes qui sont comblées par des fonctions dispo ailleurs ou non documentées.

Certes, mais il est en général dangereux et/ou caractéristique d'une "mauvaise pratique" de les utiliser. Si elles ne sont pas publiées "normalement", c'est qu'il y a une bonne raison.

Dans ton cas, cela revient à peu près à la même chose que d'aller "fouiller" le contenu interne d'une structure FILE* (en C) pour trouver des informations sur le fichier en cours d'utilisation... Chose hautement non-portable, bien sûr, mais également très dangereux car cela peut changer d'une version à l'autre du compilateur.

Envoyé par camboui

Je suis en mode user, je cherche simplement à utiliser les fonctions ZwXxx qui se trouvent dans ntdll.dll. En particulier ZwQueryInformationFile().
Le but est de faire du logging en cas d'erreur IO. Je ne trouve pas qu'il soit utile de stocker les informations en amont, infos dont je n'ai pas besoin en tant normal. Je souhaite que l'OS me fournisse cette info si nécessaire.
Exemple typique: retrouver le nom d'un fichier dont on ne connait que le handle.

Normalement, tu es censé utiliser les fonctions NtXxx en mode user, et pas les ZwXxx.

Pour l'exemple que tu cites, tu as GetFileInformationByHandleEx (API Win32 "normale") qui répond à ton besoin, et qui sera nettement plus propre à utiliser.

**homeostasie** · 09/03/2010, 15h03

Envoyé par Mac LAK

Certes, mais il est en général dangereux et/ou caractéristique d'une "mauvaise pratique" de les utiliser.

Une mauvaise pratique, souvent utiliser à des fins douteuses...
Enfin, si c'est dans un but d'apprendre, de découvrir, de réaliser des tools de surveillance etc..., c'est bien plus nôble!

En tout cas, l'idéal comme tu fais part, c'est d'utiliser des APIs documentées, prévues pour une programmation "normale" au niveau utilisateur.

**camboui** · 09/03/2010, 15h37

Envoyé par Mac LAK

Pour l'exemple que tu cites, tu as GetFileInformationByHandleEx (API Win32 "normale") qui répond à ton besoin, et qui sera nettement plus propre à utiliser.

Je n'en doute pas, mais
Minimum supported client: Windows Vista
Minimum supported server: Windows Server 2008
C'est un peu contrariant...
J'essaie malgré tout, je suis sous XP et VS2005. Ça compile mais le linker ne trouve pas la fonction... (kernel32.lib qui n'est pas à jour ?)

Je veux bien utiliser les versions NtXxx au lieu de ZwXxx mais dans quel header sont-elles déclarées ? (pas ntddk.h en tout cas)

Sinon l'idée de charger dynamiquement les adresses des fonctions de l'API est bonne, et c'est instructif, merci ! (on aime bien chipotter, hein !

)

**homeostasie** · 09/03/2010, 16h13

Envoyé par camboui

Je veux bien utiliser les versions NtXxx au lieu de ZwXxx mais dans quel header sont-elles déclarées ? (pas ntddk.h en tout cas)

Sinon l'idée de charger dynamiquement les adresses des fonctions de l'API est bonne, et c'est instructif, merci ! (on aime bien chipotter, hein ! )

J'ai l'impression que tu as parcouru rapidement le code que je t'ai posté. ;')
Tout y est pour l'utilisation d'une fonction Ntxxx, notamment en passant par un pointeur de fonction auquel on assignera la valeur récupérée via GetProcAddress(). De ce fait, nul besoin de chercher un fichier d'entête déclarant des fonctions en NtXxx. D'ailleurs, je ne crois pas qu'il existe!?

Le seul fichier d'entête que tu as surement besoin pour le code fourni est celui-ci:

Code :

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

#include <windows.h>

**camboui** · 09/03/2010, 16h41

J'ai complété et testé ton bout de code, et de fait ça fonctionne !

Il m'a même permis de vérifier que GetFileInformationByHandleEx n'existe pas sur ma machine (GetFileInformationByHandle bien).

Reste qu'il ne faut pas se tromper dans le prototypage et espérer que le cast nécessaire en retour de GetProcAddress soit le bon.
A propos, GetProcAddress n'a pas d'équivalent GetProcAddressA et GetProcAddressW ?

**Mac LAK** · 09/03/2010, 17h35

Envoyé par camboui

Je n'en doute pas, mais
Minimum supported client: Windows Vista
Minimum supported server: Windows Server 2008
C'est un peu contrariant...

Relis mieux les notes en bas de page. Pour Vista, c'est dispo "tel quel", sans fioritures, au travers de "Winbase.h". Pour XP / 2003, c'est dans le DDK, au travers de "FileExtd.h".

Envoyé par MSDN

Minimum supported client: Windows Vista
Minimum supported server: Windows Server 2008
Redistributable: Windows SDK on Windows Server 2003 and Windows XP.
Header: WinBase.h (include Windows.h), FileExtd.h on Windows Server 2003 and Windows XP
Library: Kernel32.lib, FileExtd.lib on Windows Server 2003 and Windows XP
DLL: Kernel32.dll

Ce n'est pas le cas pour toutes les fonctions de Vista, bien sûr, mais en l'occurrence je suis prêt à parier que cette fonction (sous XP) ne fait que wrapper de façon sécurisée l'appel à la fonction NtQueryInformationFile... Mais au moins, c'est blindé, 100% compatible avec le mode user et sans problèmes de réentrance.
Il n'y a que pour Windows 2000 que tu es, potentiellement, dans la mouise.

Envoyé par camboui

Je veux bien utiliser les versions NtXxx au lieu de ZwXxx mais dans quel header sont-elles déclarées ? (pas ntddk.h en tout cas)

Je n'ai pas le DDK sous le coude, mais je crois que c'est dans "Winternl.h".

**homeostasie** · 09/03/2010, 17h40

Envoyé par Mac LAK

Je n'ai pas le DDK sous le coude, mais je crois que c'est dans "Winternl.h".

Bien vu et bonne mémoire!

**camboui** · 09/03/2010, 18h18

J'ai bien tout lu, et je dois manifestement avoir un DDK trop vieux (novembre 2006), il n'y a pas de FileExtd.h ni de FileExtd.lib.

Je ne vais probablement pas généralisé l'usage de ces fonctions un peu "cachées". En attendant de pouvoir utiliser la nouvelle fonction dispo depuis Vista et WS2008 je vais faire l'appel dynamique à NtXxx avec GetProcAddress. Au pire elle n'existe pas et tant pis, mais au moins le programme fonctionnera sur tous les Windows (depuis XP au moins) sans se demander si tel ou tel màj est installée.

Merci à tous les deux !