Discussion :

[sivaller]

Bonjour,

Je recupére le handle du processus lut par mon driver à l'aide de la fonction
DeviceIoControl

En Kernel-mode.
HANDLE
PsGetCurrentProcessId(
VOID
);

Je recupére donc le HANDLE du processus recupére à l'aide de la fonction
DeviceIocontrol.

Mais en user-mode quel api windows faut t'il utiliser pour recupérer les informations de ce processus (ex nom de l'image,PID etc.) ????
Merci beaucoup.

[bacelar]

Je ne suis pas sûr qu'un handle récupérer en kernel-mode soit fonctionnel en user-mode, sinon :
NtQueryInformationProcess
http://msdn.microsoft.com/en-us/libr...80(VS.85).aspx

[Mac LAK]

Je ne suis pas sûr qu'un handle récupérer en kernel-mode soit fonctionnel en user-mode

Cela m'étonnerait beaucoup moi aussi.
Regarde aussi du côté de GetModuleFileName et GetCurrentProcessId, et de façon générale le topic Processes and Threads de MSDN.

[sloshy]

Bonjour,
un HANDLE n'est pas un pointeur mais bien un nombre.
Si j'en crois PsGetCurrentProcessId()

Code :

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

returns the process ID of the of the current thread's process.

Donc techniquement l'information qu'il récupère est un PID valable en userland, il peut donc (avec les droits adéquat) faire un OpenProcess dessus suivi par un NtQueryInformationProcess non?

[Médinoc]

Pourtant, en user-mode, tu as bien deux concepts différents: Le Process ID (un DWORD) et le handle de processus ouvert (un HANDLE)...

OpenProcess() et GetProcessId() m'en sont témoins, ainsi que GetCurrentProcess() (retourne un pseudo-handle valide uniquement dans le processus courant) et GetCurrentProcessId() (retourne un DWORD toujours valide)...

[sloshy]

On est bien d'accord pour l'user mode.
Cela dis je ne fais que de me référer a la MSDN sans plus.

Il existe des handles globaux, et il me semble logique que dans le kernel le PID d'un processus soit un handle global sur celui-ci. (c'est même sa fonction première non?)
Pourquoi ce n'est pas pareil en userland? car deux applications peuvent avoir besoins d'ouvrir un handle sur le même processus et qu'il faut bien distinguer les deux (et donc le handle ne peut être égal au PID du processus a atteindre).

enfin c'est ce que je pense, il existe peut être d'autre raison mais celle-ci me semble parfaitement logique (je peux me tromper).

[Mac LAK]

Attention aussi aux confusions possibles (y compris de doc sur MSDN, l'erreur est humaine...) avec Windows CE : sous CE, le handle sur un processus/thread est IDENTIQUE (au cast près) au PID/TID, et il est donc "partageable" (mais bon, crado quand même).

Ceci est par contre FAUX par défaut sur les noyaux NT, ne serait-ce qu'à cause des droits NT : deux handles ouverts avec des droits différents sont différents entre eux, et ne peuvent donc pas être égaux au PID ("H1==PID" ET "H2==PID" ET "H1!=H2" n'a bien sûr pas de solution).

[sloshy]

c'est bien la différence entre un handle locale et un handle globale non?
Nul n'est a l'abri d'une erreur humaine mais je pense que la msdn et vue et revue

[Mac LAK]

Nul n'est a l'abri d'une erreur humaine mais je pense que la msdn et vue et revue

Je viens de tomber sur une erreur de lien tout à l'heure, si tu veux un exemple...
Plus sérieusement, elle est comme toutes les docs faites sérieusement : digne de confiance sur le fond général, et potentiellement fausse sur les détails "insignifiants".

En l'occurrence, là, on parle de PID retourné via un HANDLE, ce qui n'est pas l'usage normal de l'API Win32 (sous-entendu "user") qui utilise un DWORD à cet effet. On peut donc légitimement présupposer qu'il y a une coquille et/ou que c'est spécifique au mode kernel.

Dans le cas de PsGetCurrentProcessId, c'est en effet une fonction Kernel à la base, donc les règles sont différentes de l'user-land. OK, le PID ne change pas de valeur entre le mode user et le mode kernel, mais cela ne fait pas du HANDLE retourné par PsGetCurrentProcessId un handle valide en mode User. Il est du bon type, certes, mais la fonction adéquate User est GetCurrentProcess.

[sloshy]

Relis ce que je dis )
Je dis qu'il retourne un PID valide en user mode, de la il faut OpenProcess pour avoir un handle

[Mac LAK]

Ah, OK, si c'est en passant ça comme un PID, qui est interprété comme un PID en mode user et non pas comme un HANDLE (+ API Win32 derrière pour récupérer les infos bien sûr).

La forme interrogative que tu avais utilisée m'a induit en erreur, j'ai cru que tu voulais passer directement le handle du mode Kernel vers le mode User, en tant que handle global et comme alternative à OpenProcess...

[sloshy]

La forme interrogative était la uniquement car c'est une supposition âpres la lecture de la doc sans avoir fait de test