ÉNUMÉRATION DES PROCESSUS ET DÉCHARGEMENT FORCÉ DE DLL
mirlaine
Messages postés32Date d'inscriptionsamedi 9 août 2003StatutMembreDernière intervention24 août 2005
-
5 avril 2005 à 00:55
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 2007
-
5 avril 2005 à 04:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 20072 5 avril 2005 à 04:18
Je précise tout de même pour ceux qui auraient envie d'essayer qu'il serait extrêmement dangereux pour la stabilité du système d'activer ce privilège et d'exécuter mon programme tel quel : la plupart des services système de microsoft sont des applications natives qui ne dépendent que de ntdll, donc n'ont pas de kernel32 mappée en mémoire (ce qui implique pas de GetModuleHandle ni de FreeLibrary dans le thread distant, sinon BOUM)...
Soit il faudrait les forcer à charger kernel32 (en passant par l'api native), soit il faudrait utiliser directement l'api native dans le thread distant... Si tu es motivé, ntdll est une des rares dll avec kernel32 et user32 à être toujours chargée à son adresse de prédilection (ce qui signifie que ses fonctions ont les mêmes adresses dans tous les processus courants).
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 20072 5 avril 2005 à 04:05
Si tu parles des processus impossibles à ouvrir, je donne la solution dans mon dernier lien (en plus tu t'en sers dans une de tes sources :p) : SeDebugPrivilege :)
mirlaine
Messages postés32Date d'inscriptionsamedi 9 août 2003StatutMembreDernière intervention24 août 2005 5 avril 2005 à 00:55
salut c'est original comme méthode pour list les process
sinon je croi ya moyen que ca marche avec tou les process...
je me rappel plus comment a+
5 avril 2005 à 04:18
Soit il faudrait les forcer à charger kernel32 (en passant par l'api native), soit il faudrait utiliser directement l'api native dans le thread distant... Si tu es motivé, ntdll est une des rares dll avec kernel32 et user32 à être toujours chargée à son adresse de prédilection (ce qui signifie que ses fonctions ont les mêmes adresses dans tous les processus courants).
5 avril 2005 à 04:05
5 avril 2005 à 00:55
sinon je croi ya moyen que ca marche avec tou les process...
je me rappel plus comment a+