Lsof : la liste des handles ouverts par les processus (comme sous unix)

Soyez le premier à donner votre avis sur cette source.

Vue 12 866 fois - Téléchargée 769 fois

Description

Ce code permet d'avoir la liste des fichiers ouverts sur le système, comme le fait la commande lsof sous Unix. Il emploie des fonctions non documentées.Il contient une classe pour obtenir cette liste.

L'application de ce projet pourrait être : quand on ouvre un fichier et que l'on obtient une erreur, on peut afficher l'application qui utilise le fichier actuellement. Le seul problème, c'est que ce code nécessite les droits d'ADMINISTRATEUR (lsof nécessite les droits root sous Unix)...

Si l'on a les droits appropriés (administrateur), on peut obtenir la liste des fichiers ouverts, même des processus système (privilège SeDebugPrivilege).

Il nécessite un driver, car, parmi les fichiers il y a les pipes...et le probleme des pipes est qu'ils peuvent créer des deadlocks (blocage dû au fait qu'on attend après une ressource (le pipe) qui ne sera jamais libérée)...Or dans les objets kernels (au sens de structure mais bon c le terme) correspondants aux handles, il y a un membre de la structure dudit objet qui renseigne sur "l'occupation" de l'objet...Mais on ne peut accéder aux objets kernels qu'en mode kernel donc dans un driver...
bref, le driver regarde si un appel à NtQueryObject créera ou non un deadlock :
- si pas deadlock, il appelle ObQueryNameString (<=> NtQueryObject) pour obtenir le nom de l'objet
- si deadlock, il se débrouille avec les pointeurs vers les noms et les objets eux-mêmes pour trouver le nom complet

il est nécessaire de mettre le driver KernelMemory.sys dans Debug\ et/ou Release\ (dans le dossier de l'exe) avant de lancer

Conclusion :


Pour plus d'infos sur les API Native de Windows NT/2000/XP, regarder le livre "Windows NT/2000 NATIVE API Reference" de Gary Nebbett

Ce code ne fonctionne pas sous 9x/ME. Testé sur XP Pro, 2000, 2003. Ne fonctionne pas sous NT4 et Vista.

N'hésitez pas à commenter et à noter...

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Messages postés
2676
Date d'inscription
vendredi 28 juin 2002
Statut
Membre
Dernière intervention
13 janvier 2016
20
salut,

Il n'y a pas de manière simple de récupérer les informations complètes. La manière "la plus simple" serait certainement de lire directement les structures de données en mémoire noyau comme le font les root kits. Cependant, cela reste relativement complexe dans la mesure où le moindre bug peut faire planter Windows...

ShareVB
Messages postés
1
Date d'inscription
mardi 23 décembre 2008
Statut
Membre
Dernière intervention
3 février 2009

Le ProcessID contenu dans la structure SYSTEM_HANDLE_INFORMATION est tronqué à 16 bits...

Y-a-t'il un moyen de contourner ce problème ???
Messages postés
2676
Date d'inscription
vendredi 28 juin 2002
Statut
Membre
Dernière intervention
13 janvier 2016
20
salut,

justement, si tu es sur un compte administrateur au moment où tu exécutes ce programme, cela devrait marcher...dans tous les cas, ils faut un accès qui te permettent de charger des pilotes (droit local dans les polices de sécurité, secpol.msc si je me souviens bien)...le mieux pour tester restant un compte admin...

ShareVB
Messages postés
5
Date d'inscription
lundi 9 juillet 2007
Statut
Membre
Dernière intervention
22 décembre 2008

Salut,

Comment faire pour que ca marche sous Vista?
Merci

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.