protéger une application d'un kill Process

Version imprimable

Voir 40 message(s) de cette discussion en une page

20/09/2010, 13h06
cincap

Bonjour à toutes et à tous,

@, Franck SORIANO, je démarre l'application avec le clickdroit et en tant qu'administrateur, même message, je doubleclick pour exécuter le projet, même message.

Ce qui n'empêche pas l'exécution du programme !

Le projet test n'a rien d'autre que le code suggéré, et forcément suite à l'erreur, il peut être désactivé comme processus.

A mon avis, il y a trop de variables entres les Os.

@+,

Cincap
22/09/2010, 05h27
Coussati

pour le .sys tu peux oublier, c'est du lourd, surtout en delphi !

et les autres méthodes cités ne fonctionneront pas forcément sur tous les OS depuis les Vista / W7, les 32 / 64 bit

peut être essayer de détecter l'os et appliquer une méthode précise à chacun ?
22/09/2010, 06h53
Paul TOTH

Citation:

Envoyé par NABIL74

bonjour,

@ evarisnea ,salut
note application qui est encore sous développement contrôle les accès à certains répertoires ,c'est en quelque sorte 'un folder guard" .
Nous voulons empêcher l'utilisateur à killer notre exe que par un mot de passe saisie auparavant par l'administrateur.
si t'as un exemple sous la main, je suis très intéressé.merci d'avance :P.

A+

NABIL74

pourquoi ne pas utiliser la gestion des droits Windows ?!

bonjour à toutes et à tous,

@ NABIL74, si tu envisages de bloquer le gestionnaire de taches, voici une procédure sous Seven 64bits qui fonctionne, les touches CTRL + SHIFT + ESC sont innactives ainsi que dans le menu concernant l'accès au gestionnaire de tache par les touches CTRL + ALT + DELETE, de plus, cet accès est aussi neutralisé dans le menu lors d'un click droit sur la barre de tache et avec la commande Démarrer / Exécuter... "taskmgr.exe".

A tester sur d'autres Os.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 procedure BloquerGestionnaireDesTaches(bloque: Boolean); begin with TRegistry.Create do try //HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System RootKey := HKEY_CURRENT_USER; //OpenKey ('SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon',false); OpenKey ('\Software\Microsoft\Windows\CurrentVersion\Policies\System',false); if bloque then WriteInteger('DisableTaskMgr', 1) //Clé DWord else DeleteValue('DisableTaskMgr'); finally CloseKey; Free ; end; end;
Pour activer la sécurité :
Code:

1 2 3 4 5 procedure TFTest.BActiveClick(Sender: TObject); begin BloquerGestionnaireDesTaches(true) ; end;
Pour Désactiver :
Code:

1 2 3 4 5 procedure TFTest.BDesactiveClick(Sender: TObject); begin BloquerGestionnaireDesTaches(False) ; end;
@ Paul TOTH, Il faut aussi penser que notre ami NABIL74 est professeur en Algérie et que la plus part des étudiants ont un Pc avec des anciens Os.

L'application peut être démarrée avec le click droit en tant qu'Administrateur mais ce n'est pas une condition.

@+,

Cincap

22/09/2010, 12h31
Franck SORIANO

Citation:

@, Franck SORIANO, je démarre l'application avec le clickdroit et en tant qu'administrateur, même message, je doubleclick pour exécuter le projet, même message.

Ce qui confirme bien qu'il ne s'agit ni d'un problème de droit d'accès, ni d'un problème lié à l'UAC. Mais bel et bien de paramètres d'appel incorrects).

Citation:

Envoyé par Coussati

et les autres méthodes cités ne fonctionneront pas forcément sur tous les OS depuis les Vista / W7, les 32 / 64 bit

Non. La revocation du droit PROCESS_TERMINATE sur le processus fonctionnera quel que soit l'OS à partir de Windows 2000.

Par contre il faut faire attention à la définition du SID sur lequel on définit l'interdiction.
L'exemple que j'ai donné se base sur le nom du groupe. Or ce dernier peut changer selon la localisation de l'OS.
Pour faire une fonction qui fonctionne partout, il faudrait définir le SID en utilisant son identifiant binaire (ce qui nécessite de revoir l'initialisation de la partie Trustee de la structure EXPLICIT_ACCESS).

en effet j'ai l'erreur sous XP

j'ai tenté cette modification mais ça ne marche pas mieux

Code:

1
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
31
32
33
 
type
 TIdentifierAuthority = Packed Array[0..5] of Byte;
var
  SID : packed record
    Revision : Byte;
    SubAuthorityCount: Byte;
    IdentifierAuthority : TIdentifierAuthority;
    SubAuthority : Cardinal;
  end;
const
  SECURIRY_WORLD_SID : TIdentifierAuthority = (0,0,0,0,0,1);
begin
  SID.Revision := 1;
  SID.SubAuthorityCount := 1;
  SID.IdentifierAuthority := SECURIRY_WORLD_SID;
  SID.SubAuthority := 0;
 
  hpWriteDAC := OpenProcess(WRITE_DAC, false, pid);
 
  users := 'Tout le monde';
  ea.grfAccessPermissions := PROCESS_TERMINATE;
  ea.grfAccessMode := DENY_ACCESS;
  ea.grfInheritance := NO_INHERITANCE;
  ea.Trustee.pMultipleTrustee := nil;
  ea.Trustee.MultipleTrusteeOperation := NO_MULTIPLE_TRUSTEE;
  ea.Trustee.TrusteeForm := TRUSTEE_IS_SID; // TRUSTEE_IS_NAME;
  ea.Trustee.TrusteeType := TRUSTEE_IS_USER; //TRUSTEE_IS_WELL_KNOWN_GROUP;
  ea.Trustee.ptstrName := PChar(@SID); // PChar(users);
  pdacl := nil;
  dwErr := SetEntriesInAcl(1, @ea, nil, pdacl);
  if dwErr<>0
  then RaiseLastOSError;

22/09/2010, 19h03
NABIL74

bonjour à toutes et à tous,

@ Coussati,
pour ce qui du lourd en delphi, c'est du lourd :), mais on sait jamais,peut-être un des membres du club a rencontré ce problème et qu'il a une solution ou une suggestion.

Citation:

Envoyé par Paul TOTH

pourquoi ne pas utiliser la gestion des droits Windows ?!

merci de ton conseil Paul, mais comme t'as dit mon ami cincap c'est qu'il faut aussi penser que la plus part de nos étudiants ont un pc avec XP, alors je suis "obligé" de faire tourner notre application sous cet os.

@ cincap,

merci mon frère.
après beaucoup de discutions entre nous les collègues au travail,nous avons repenser des dizaines de fois à quelle piste nous allons suivre et enfin, nous nous sommes mis d'accord sur: cacher complètement l'application dans le gestionnaire de taches.
personnellement, je ne suis pas satisfait de cette piste.enfin bon :).

merci à vous tous pour votre aide.

je clôture ce topic, mais je continue mes recherches et mes tests.

toutes idées seraient le bienvenue.

NABIL74
22/09/2010, 20h39
Franck SORIANO

Citation:

Envoyé par Paul TOTH

en effet j'ai l'erreur sous XP

Tu as une erreur au moment de la définition des droits ou bien ça passe correctement mais tu parviens malgré tout à tuer l'appli ?

Moi avec tes modifs sa passe également sous XP. Mais je peux tuer l'appli.

Il faut qu'en même savoir que si le processus qui fait le kill possède le privillège SE_DEBUG (déboguer les applications) il peut tuer n'importe quel processus.
Et les comptes administrateurs possèdent par défaut le privillège en question, ce qui fait qu'il n'est pas vraiment possible d'interdire le kill.
22/09/2010, 21h04
Paul TOTH

Citation:

Envoyé par Franck SORIANO

Tu as une erreur au moment de la définition des droits ou bien ça passe correctement mais tu parviens malgré tout à tuer l'appli ?

Moi avec tes modifs sa passe également sous XP. Mais je peux tuer l'appli.

Il faut qu'en même savoir que si le processus qui fait le kill possède le privillège SE_DEBUG (déboguer les applications) il peut tuer n'importe quel processus.
Et les comptes administrateurs possèdent par défaut le privillège en question, ce qui fait qu'il n'est pas vraiment possible d'interdire le kill.

j'ai un EOSError "Un appel à une fonction du système d'exploitation a échoué" lors de l'appel à SetSecurityInfo.

Voir 40 message(s) de cette discussion en une page