begin process at 2012 05 27 20:17:58
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

Système

 > KILL ANY PROCESS

KILL ANY PROCESS


 Information sur la source

Note :
10 / 10 - par 4 personnes
10,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Système Niveau :Expert Date de création :15/10/2004 Vu / téléchargé :24 286 / 1 451

Auteur : Nebula

Ecrire un message privé
Site perso
Commentaire sur cette source (24)
Ajouter un commentaire et/ou une note

 Description

J'ai écrit ce code en réponse à celui posté ici : http://www.cppfrance.com/code.aspx?ID=18232, qui permettait de rendre un processus insensible aux TerminateProcess (le fichier lazarus.exe dans mon zip reprend cette protection, pour ceux qui ont la flemme de compiler).

Non seulement ce code peut terminer les processus protégés ainsi, mais il peut également tuer n'importe quel processus, services compris (essayez avec crss.exe, pour voir :P)

J'insiste sur le fait que vous DEVEZ sauvegarder votre travail avant de tester un kill, une erreur dans le PID et vous pourriez bien avoir un écran bleu...

Source

  • #include <windows.h>
  • BOOL SetDebugPrivileges(VOID) {
  • /* cette fonction permet au processus courant d'obtenir le privilège DEBUG,
  • * autrement dit la capacité de manipuler n'importe quel processus du système...
  • *
  • * pour retirer ce privilège, il suffit de mettre 0 au lieu de SE_PRIVILEGE_ENABLED
  • * ne faites pas n'importe quoi avec, c'est vraiment très puissant (ne tuez pas crss.exe, par exemple)
  • *
  • * fuite connue mais minime ici : il faudrait fermer les handles avant de quitter en cas d'erreur
  • */
  • DWORD dwPID;
  • HANDLE hProcess;
  • HANDLE hToken;
  • LUID Luid;
  • TOKEN_PRIVILEGES tpDebug;
  • dwPID = GetCurrentProcessId();
  • if ((hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPID)) == NULL) return FALSE;
  • if (OpenProcessToken(hProcess, TOKEN_ALL_ACCESS, &hToken) == 0) return FALSE;
  • if ((LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &Luid)) == 0) return FALSE;
  • tpDebug.PrivilegeCount = 1;
  • tpDebug.Privileges[0].Luid = Luid;
  • tpDebug.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
  • if ((AdjustTokenPrivileges(hToken, FALSE, &tpDebug, sizeof(tpDebug), NULL, NULL)) == 0) return FALSE;
  • if (GetLastError() != ERROR_SUCCESS) return FALSE;
  • CloseHandle(hToken);
  • CloseHandle(hProcess);
  • return TRUE;
  • }
  • #include <stdio.h>
  • int main(int argc, char** argv) {
  • /* cette fonction kille tous les processus dont le PID lui a été passé en argument
  • *
  • * attention, elle ne demande aucune confirmation et peut parfaitement planter votre système
  • * si vous demandez à terminer un processus vital (essayez avec crss.exe, par exemple)
  • */
  • int i = 0;
  • if (argc < 2) {
  • puts("Usage: kill <PID 1> [<PID 2> ... <PID n>]");
  • return 0;
  • }
  • if (SetDebugPrivileges() == 0) puts("Unable to grant debug privileges !");
  • while (++i < argc) {
  • DWORD dwPID;
  • HANDLE hProcess;
  • dwPID = atoi(argv[i]);
  • if ((hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, dwPID)) != NULL) {
  • if (TerminateProcess(hProcess, 0) == 0) printf("Unable to kill process %lu !\n", dwPID);
  • CloseHandle(hProcess);
  • } else printf("Unable to access process %lu !\n", dwPID);
  • }
  • return 0;
  • }
#include <windows.h>

BOOL SetDebugPrivileges(VOID) {
  /* cette fonction permet au processus courant d'obtenir le privilège DEBUG,
   * autrement dit la capacité de manipuler n'importe quel processus du système...
   *
   * pour retirer ce privilège, il suffit de mettre 0 au lieu de SE_PRIVILEGE_ENABLED
   * ne faites pas n'importe quoi avec, c'est vraiment très puissant (ne tuez pas crss.exe, par exemple)
   *
   * fuite connue mais minime ici : il faudrait fermer les handles avant de quitter en cas d'erreur
   */
  DWORD dwPID;
  HANDLE hProcess;
  HANDLE hToken;
  LUID Luid;
  TOKEN_PRIVILEGES tpDebug;
  dwPID = GetCurrentProcessId();
  if ((hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPID)) == NULL) return FALSE;
  if (OpenProcessToken(hProcess, TOKEN_ALL_ACCESS, &hToken) == 0) return FALSE;
  if ((LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &Luid)) == 0) return FALSE;
  tpDebug.PrivilegeCount = 1;
  tpDebug.Privileges[0].Luid = Luid;
  tpDebug.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
  if ((AdjustTokenPrivileges(hToken, FALSE, &tpDebug, sizeof(tpDebug), NULL, NULL)) == 0) return FALSE;
  if (GetLastError() != ERROR_SUCCESS) return FALSE;
  CloseHandle(hToken);
  CloseHandle(hProcess);
  return TRUE;
}

#include <stdio.h>

int main(int argc, char** argv) {
  /* cette fonction kille tous les processus dont le PID lui a été passé en argument
   *
   * attention, elle ne demande aucune confirmation et peut parfaitement planter votre système
   * si vous demandez à terminer un processus vital (essayez avec crss.exe, par exemple)
   */
  int i = 0;
  if (argc < 2) {
    puts("Usage: kill <PID 1> [<PID 2> ... <PID n>]");
    return 0;
  }
  if (SetDebugPrivileges() == 0) puts("Unable to grant debug privileges !");
  while (++i < argc) {
    DWORD dwPID;
    HANDLE hProcess;
    dwPID = atoi(argv[i]);
    if ((hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, dwPID)) != NULL) {
      if (TerminateProcess(hProcess, 0) == 0) printf("Unable to kill process %lu !\n", dwPID);
      CloseHandle(hProcess);
    } else printf("Unable to access process %lu !\n", dwPID);
  }
  return 0;
}

 Conclusion

Testé sous XP SP2 avec GCC 3.4.2 et Visual C++ 2003, fonctionne comme un charme.

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !
  • killer.cTélécharger ce fichier [Réservé aux membres club]Voir ce fichier2 182 octets
  • killer.exeTélécharger ce fichier [Réservé aux membres club]6 144 octets
  • lazarus.exeTélécharger ce fichier [Réservé aux membres club]2 048 octets

Télécharger le zip


 Sources du même auteur

Source avec Zip ÉNUMÉRATION DES PROCESSUS ET DÉCHARGEMENT FORCÉ DE DLL
Source avec Zip EXÉCUTABLES SE VÉRIFIANT LORSQU'ILS SONT LANCÉS
Source avec Zip Source avec une capture RICHEDIT AVEC SUPPORT DES THÈMES XP
Source avec Zip CALCUL DE HASH MD5 (WIN32)
Source avec Zip VÉRIFIER QUE L'UTILISATEUR EST ADMINISTRATEUR

 Sources de la même categorie

Source avec Zip Source avec une capture INFORMATION PROCESSEUR (CPUID) par Devils_Tiger
Source avec Zip Source avec une capture LECTURE TEMPÉRATURE PROCESSEUR par Devils_Tiger
Source avec Zip Source avec une capture LECTURE FRÉQUENCE PROCESSEUR par Devils_Tiger
Source avec Zip Source avec une capture UNE LISTE HÉTÉROGÈNE DOUBLEMENT CHAINÉE par pgl10
Source avec Zip Source avec une capture POUR AFFICHER LES CARACTÈRES ACCENTUÉS SOUS WINDOWS EN MODE ... par pgl10

Commentaires et avis

Commentaire de BlackGoddess le 15/10/2004 18:03:29

joli :))
interressantes cette partie de l'api sur les privileges

Commentaire de Pamaury le 16/10/2004 08:27:52

juste une question parce que j'ai pas envie d'aller sur MSDN, pourquoi tu utilise SE_DEBUG_NAME dans la fonction LookupPrivilegeValue, c'est çà qui permet les privilèges les plus élevé ou c'est juste parce qu'il faut mettre çà ??

Commentaire de Gendal67 le 16/10/2004 08:45:36

Euh slt, je trove ta source géniale...sauf une chose : ça marche pas chez moi ! Windows XP SP1...
En fait, le truc chiant c'est qu'il faut envoyer un ID du processus à la ligne de commande....et que moi je ne vois pas comment envoyer un nombre à partir d'un nom de processus, si tu pouvais m'aider...merci d'avance! :-)

Commentaire de Nebula le 16/10/2004 13:24:38

Pamaury > c'est le privilège minimal dont on a besoin pour accéder sans limites à tous les processus, oui... y'en a un autre bien plus puissant : SE_TCB_NAME (act as part of operating system), mais je n'ai pas encore réussi à l'activer, windows me le refuse lol

Gendal67 > pour les PID, tu peux les trouver dans le gestionnaire de tâches, deuxième colonne (éventuellement affichage->sélectionner des colonnes pour afficher la bonne colonne)... pour killer par noms regarde ma source "tuer un processus", peu de modifications sont nécessaires ;)

Commentaire de Gendal67 le 16/10/2004 13:36:18


Nebula, un grand grand merci pour ton aide !!!
J'ai testé et tout fonctionne impec' ! Maintenant je vais me mettre à apprendre et à connaitre ce code (se sert à rien de l'utiliser si je ne suis pas capable de le refaire et connaitre les différentes parties) :-)) merci en tt cas !!

Commentaire de Pamaury le 17/10/2004 08:47:01

Merci Nebula,
t'as regardé sur MSDN pq il le voulait pas le SE_TCB_NAME parce que s'il existe on doit pouvoir l'utiliser !!

Commentaire de Nebula le 17/10/2004 12:01:11

Gendal67 > de rien ;-)

Pamaury > bah oui j'ai regardé la MSDN, mais ils ne disent rien de particulier sur ce privilège :-/

Commentaire de basted le 18/10/2004 08:14:31

Salut, je trouve le sujet simpa alors j'ai un peut chiné sur le NET, j'ai trouvé ca sur la fich Ms Q180548

"The first and biggest of these restrictions is that on Windows NT and Windows 2000, the process that is calling LogonUser must have the SE_TCB_NAME privilege (in User Manager, this is the "Act as part of the Operating System" right). The SE_TCB_NAME privilege is very powerful and should not be granted to any arbitrary user just so that they can run an application that needs to validate credentials. The recommended method is to call LogonUser from a service that is running in the local system account, because the local system account already has the SE_TCB_NAME privilege."

En claire il faut lancé ton appli en service! J'ai mas testé mais si micro$oft le dit ...

Commentaire de Nebula le 18/10/2004 12:35:08

Merci basted pour la recherche, si quelqu'un veut tester et peut nous dire ce qu'octroie vraiment ce privilège... D'après ce que j'avais trouvé sur MSDN, il permettrait de gérer les user mais ils ne s'étendent pas vraiment sur le sujet :-/

Commentaire de kptn le 28/10/2004 15:36:52

J'ai pas encore pris le tps de regarder pour SE_TCB_NAME (je rentre tt juste de vacances, hé!hé! ^^) mais dès que j'ai un peu de tps, je vais essayer de m'y pencher dessus... C'est tjs intéressant ce genre de chose :)

Commentaire de hebusletroll le 09/11/2004 09:38:13

Cet exemple démontre comment modifier les privilège de l'utilisateur / processus courant.

Le SE_DEBUG_NAME, donne le droit par exemple de récupérer un Jeton (token) d'un autre processus. Seuls les comptes administrateurs ont la possibilité (par défaut) d'accéder à ce droit (Le compte LOCAL SYSTEM le possède également). SE_TCB_NAME assure à l'utilisateur en cours d'agir en tant que système d'exploitation.

D'autres intéressant à exploiter sont SE_DUPLICATE_TOKEN_NAME, ET SE_AJUST_TOKEN.

Je suis surpris de voir un tel code sur un site Français car force est d'avouer que très peu de personnes (voire aucune) ne s'intéressent à cet aspect de l'OS.

Pour ma part j'ai développé un outil (bientôt dispo sur le web), permettant d'exécuter un programme sous le contexter LocalSystem (Assez compliqué en soit), vous pourrez même ouvrir une session sous ce même contexte. Cependant le code est beaucoup plus compliqué.

Commentaire de nico_rigo le 16/11/2004 18:28:05

Salut,

tout d'abord un grand bravo pour le code.

Juste une petite remarque. Il ne marche pas pour tous les processus (et heureusement). Genre firewall (celui que j'utilise est Sygate Personal Firewall). Il est a priori impossible a killer.

J'ai pourtant choppé récemment un virus, qui lui, parvenait à mater sygate (comment ? je n'ai tjs pas compris).

Est-ce qu'avec ce code vous parvenez à killer ce genre de programme ? si oui comment protéger son firewall contre les kill ?

@+ et bonne continuation

Commentaire de nico_rigo le 16/11/2004 18:37:47

cela depend peut-être de la manière dont est terminée le processus.

Les différents threads sont terminés successivement ?

(est-ce qu'un thread peut survivre sans son application mère ?)

Si c'est le cas (arretez-moi si je dis une connerie) il serait possible de faire un thread dédié uniquement a relancer l'application qui la créé au cas ou celle-ci serait killer ?

Si qqun a une explication il est le bien venu...

Commentaire de Pamaury le 16/11/2004 20:45:43

Il ne me semble pas qu'un thread puisse tourner sans son procesus mère excepté le processus système !! Puisqu'en fait un processus n'est qu'un espace d'adresse et les thread le code exécuté dans le processus .

Maintenant pour qu'un processus sont non-killable il y a toujours la méthode qui consiste à hooker les appels à TerminateThread et TerminateThread et empêcher de les diriger contre le processus voulu ou alors il faut le créer avec un statut tellement important qu'on ne puisse pas le terminer(processus système ?) .

Ou alors pour "killer" une application il y a une autre méthode "très barabare" : tu récupère un handle sur le processus et tu écrit des octets dans le code qui ne correspondent pas à des instructions
=>  opcode exception
=> fermeture du thread plus que probable .

Ou alors injecter une dll dans ce processus et provoquer volontairement une erreur(overflow, non allocation de mémoire, écriture à une adresse non valide...) et la dll faisant parti du processus alors celui-ci se ferme obligatoirement .

Donc tu vois que pour terminer un process/thread tout est bon même si c'est pas très propre !

Commentaire de kptn le 17/11/2004 11:09:51

L'impossibilité de tuer un processus avec cette méthode ne vient pas du status (tu peux tuer le kernel si ça te chante), mais plus probablement d'un arrêt des méthodes TerminateThread et TerminateProcess via un hook.

Maintenant en ce qui concerne les threads, non il n'est pas possible de les laisser vivre tout seul sans leur processus associé. Ce qui signifie que si tu fermes le processus, tu fermes tous les threads avec. Mais il est tout à fait envisageable d'injecter" un thread dans un autre processus (comme un processus système) ce qui rendrait ce thread indépendant du programme, et pourrait éventuellement reouvrir une appli qui serait killée... Mais attention toutefois, les RemoteThread sont difficiles à utiliser et assez mal vu puisque très souvent associés aux virus

Commentaire de sosodef88 le 02/06/2005 14:45:14

bonjour es ce que quelqu'un sais me traduire ca en delphi ou vb paske je comprend pas bien le c++ :(

Commentaire de djnos le 09/08/2005 14:16:29

Salut SOSODEF88, moi aussi je connais pas le c++ mais le delphi mais bon là y a pas trop de c++ c surtout une utilisation de l'api windows alors ajoute l'unité shellapi à ton application et reprend les fonctions... le code ne change pas bcp.

@+

Commentaire de djnos le 09/08/2005 14:41:46

Bon pour te simplifier la tâche, voilà un lien :

http://www.delphifr.com/code.aspx?ID=32493

@+

Commentaire de ganply le 29/12/2005 17:26:06

Bonjour, je suis novice dans la programmation et je n'ai pas trouvé comment indiquer le PID du processus qu'on veut killer au programme.
Est ce que quelqu'un peut m'aider svp ?

Commentaire de kptn le 02/01/2006 09:31:53

Une méthode, simple, est d'aller dans le gestionnaire des taches, d'aller dans l'onglet Processus et de lire la colonne PID. Si elle n'est pas affiché, suffit de l'ajouter (Affichage / Sélerctionner les colonnes... / PID (Identificateur de processus...))

Sinon, tu peux aussi t'amuser à le programmer. ;o)

Commentaire de jozefff le 02/05/2007 17:20:43

yaurais pas moyen de trouver la meme apli mais avec le nom de l'executable, ou alors une apli qui en fonction du nom de l'executable donne le pid et en récupéran le résultat apliker cette methode ...

Commentaire de millouche le 26/11/2007 12:04:19

Salut Nebula. Ca marche très bien en effet mais uniquement sur une machine locale. Sais tu comment il est possible de tuer un process d'une machine connectée en réseau local ? J'arrive très bien à récupérer l'ID du process mais impossible de l'ouvrir. Le OpenProcess retourne systématiquement un NULL ?

Commentaire de mokahmed le 31/05/2008 22:34:26

salut,
peut-être que je m'interroge pour rien, mais ta fonction setdebugprivilege est de type bool, et les tests effectués dans la fonction main font une comparaison avec du numérique.
ça ne pose pas de problème ?

Commentaire de taye78 le 10/11/2010 12:49:32

ok

N3buL4

 Ajouter un commentaire




Nos sponsors


Sondage...

Comparez les prix

CalendriCode

Mai 2012
LMMJVSD
 123456
78910111213
14151617181920
21222324252627
28293031   

Consulter la suite du CalendriCode

A découvrir



 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 15,569 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales