Version imprimable
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.
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 ! ;)
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 ?
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é).Citation:
Envoyé par camboui
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 ?
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.
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():
Je te laisse définir les structures nécessaires pour pouvoir compiler.Code:
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
31typedef 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; }
;-)
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.Citation:
Envoyé par camboui
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.
Normalement, tu es censé utiliser les fonctions NtXxx en mode user, et pas les ZwXxx.Citation:
Envoyé par camboui
Pour l'exemple que tu cites, tu as GetFileInformationByHandleEx (API Win32 "normale") qui répond à ton besoin, et qui sera nettement plus propre à utiliser.
Une mauvaise pratique, souvent utiliser à des fins douteuses...Citation:
Envoyé par Mac LAK
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.
Je n'en doute pas, maisCitation:
Envoyé par Mac LAK
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 ! ;))
J'ai l'impression que tu as parcouru rapidement le code que je t'ai posté. ;')Citation:
Envoyé par camboui
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:#include <windows.h>
J'ai complété et testé ton bout de code, et de fait ça fonctionne ! :ccool:
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 ?
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".Citation:
Envoyé par camboui
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.Citation:
Envoyé par MSDN
Il n'y a que pour Windows 2000 que tu es, potentiellement, dans la mouise.
Je n'ai pas le DDK sous le coude, mais je crois que c'est dans "Winternl.h".Citation:
Envoyé par camboui
Bien vu et bonne mémoire! ;)Citation:
Envoyé par Mac LAK
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 !
Ah ben c'est malin, tiens... :roll:Citation:
Envoyé par camboui
Blague à part : pourquoi ne télécharges-tu pas le dernier WDK sur le site MS ?