Y a-t-il un moyen de protéger mon application Delphi d'être tué par le gestionnaire de tâches Windows (ou d'autres comme Process Explorer)?
Je pense que les messages Windows peuvent faire cela (en faisant un crochet et intercepter le message de traitement de ligne).
Je veux un exemple de cette protection. Les suites anti-virus de Kaspersky sont comme celle-ci; Nous ne pouvons pas terminer leur processus dans le gestionnaire de tâches.
6 Réponses :
Comme le dit Kornel, il existe une protection des processus au niveau du système d'exploitation isolée par les utilisateurs. Mais d'une manière générale, il n'ya aucun moyen d'arrêter votre processus d'être résilié par un utilisateur avec la permission de le faire. Et un utilisateur a la permission de mettre fin aux processus fonctionnant comme cet utilisateur.
Même si vous vouliez l'exécuter en tant que système, vous ne pouvez pas utiliser ce processus pour interagir avec l'utilisateur connecté. Vous auriez besoin de le courir comme un service et il n'aurait aucune interface graphique. Vous pouvez essayer d'autres approches telles que l'obtention d'une DLL chargée dans un processus comme Explorer.exe que les utilisateurs ne se terminent pas car ils ne veulent pas, mais c'est juste abusif.
Ce serait une très mauvaise situation pour les utilisateurs finaux si les développeurs pouvaient simplement écrire des applications qui n'ont pas pu être terminées. S'il s'agit d'une application interne, vous pouvez vérifier l'erreur de serveur pour voir s'il y a un moyen de le réaliser avec la stratégie de groupe.
Les programmes AV comme Kaspersky utilisent probablement un pilote et utilisez un crochet pour éviter la résiliation. Dans votre situation, je conseillerais de définir une ACL sur le processus, cela empêche la résiliation avec le gestionnaire de tâches ou les outils CMDLINE (si l'utilisateur n'a pas le privilège de débogage). Bien sûr, l'utilisateur peut toujours utiliser un outil tel que Process Explorer, prendre la propriété du processus, définir une nouvelle ACL et terminer.
Si l'utilisateur n'est pas un administrateur, il suffirait d'exécuter le processus dans un contexte utilisateur différent (par exemple, lancez-le d'un service).
Définition d'un processus ACL est très facile avec le bibliothèque de sécurité de Jedi Windows comme ça échantillon montre.
Oaky Remko, cette bibliothèque me satisfait, qui est montrée dans l'exemple pourraient répondre à mes besoins, car je veux juste quelque chose "ONU" -KILLIBLABLE PAR NOUVEAUX (UTILISATIONS ET TAKMANAGER !!)
@JoshEinstein maintenant c'est civilisé. +1 pour le commentaire et votre réponse.
Créer un projet NT-Service, les processus de service ne peuvent pas être tués avec le gestionnaire de processus, mais sont contrôlés par le gestionnaire de services interne.
C'est une très mauvaise idée. Si votre programme est exécuté sur l'ordinateur de quelqu'un d'autre, c'est sur leur propriété, pas la vôtre et doit se comporter comme un invité chez lui. Cela signifie que vous n'agissez pas comme si vous possédez l'endroit, et vous ne dites certainement pas le propriétaire de l'ordinateur ce qu'il ne peut pas faire de sa propre propriété, comme tuer une tâche qu'il ne veut pas courir. Si vous faites cela, votre programme n'est pas meilleur que les logiciels malveillants et est susceptible d'être traité comme des logiciels malveillants.
-1: L'ordinateur ne peut pas être leur propriété. par exemple. Des bureaux d'aide où les gestionnaires doivent superviser les opérateurs, en particulier lorsqu'ils ont accès à des données sensibles. Le système d'exploitation n'est pas sur les ethiс, il s'agit de questions de programmation
@Andy: Dans une telle situation, il existe des outils d'édition de politiques appropriés pour la gestion pour gérer ces situations. Et si vous pensez que l'éthique peut être séparée de la programmation en quelque sorte, veuillez ne jamais toucher un compilateur à nouveau. Je ne veux pas courir le risque que quelque chose que vous avez écrit se termine sur ma machine.
Pourquoi ne pas décrire cela en détail? OP a déjà donné sa parole qu'il ne s'agit pas de logiciels malveillants (en commentaires)
@Andy: Peut-être que cela n'arrête peut-être pas quelqu'un d'autre qui est essayer d'écrire des logiciels malveillants de la recherche de cette page.
Je pense que la connaissance devrait être publique, vous pensez différent. C'est pourquoi je recommanderais de discuter de telles choses ailleurs à éviter de flamer. Si vous pensez que OP ne mérite pas que des informations très dangereuses, il pose des questions - ne lui donnez pas. J'espère que les autres pensent différemment
Je pense que vous posez une mauvaise question.
Vous essayez de résoudre " que si la connexion sera terminée au milieu de la discussion avec le problème du serveur " "dans le mauvais sens. La réponse est Pourquoi? Cause, évidemment, la résiliation de la connexion peut être due à des problèmes de réseau (vous ne pouvez pas refuser vos utilisateurs à débrancher la machine à partir du réseau) et non de terminaison du client!
Pourquoi ne pouvez-vous pas interrompre la traduction? < / a>
Et si vous êtes inquiet à propos de l'application s'est écrasé - il suffit d'utiliser API de redémarrage et de récupération d'application .
Le moyen le plus simple: vous pouvez simplement commencer Désolé, mais je pense que votre "serveur / application client" a Trojan / Backdoor Capacités. " CLIENT APP Envoie des données utiles " "," Processus Unkillable "(dans vos commentaires) semble trop soupçon pour moi.
Si l'un d'entre eux était fermé, laissez l'autre récolte le redémarrer. Cela empêchera les débutants (comme vous l'avez dit) de tuer ce processus.
Quelle raison légitime avez-vous pour ce faire cela?
Je suggère une alternative: avoir un drapeau de statut qui montre une fermeture appropriée, et si vous êtes démarré sans que l'indicateur d'arrêt soit défini, effectuez un journal (ou plus grand). Et ensuite avoir un service qui surveille votre processus et garantit qu'il fonctionne. Si l'utilisateur la tue, recommencez-le. C'est ce que nous faisons avec un processus "doit être en cours d'exécution" que l'utilisateur peut gâcher.
J'ai une suggestion: s'il vous plaît, ne faites pas cela.
Et si un gars veut écrire un virus, et vient sur Stackoverflow essayant d'obtenir de l'aide pour le rendre extra-méchant. Est-ce que nous l'aidons ou non?
@Warren P, je n'écris pas de virus, je répète une application serveur / client, et je ne veux pas que mon tueur d'application cliente par une personne sans le serveur (administrateur) soit d'accord. Parce que cette application client envoie quelques données utiles sur le serveur.
Ensuite, ce n'est pas un problème technologique, c'est une question sociale / éducative. La solution consiste à s'assurer que les utilisateurs savent qu'il s'agit d'un processus légitime qu'ils ne devraient pas être tués. L'ajout d'un comportement ressemblant à un virus ne fera que rendre des utilisateurs avertis plus méfiant.
@ Mason Wheeler: Je suis totalement d'accord, mais tout fonctionne normalement dans notre monde d'aujourd'hui. Je ne conserverai donc pas une forme de vulnérabilité mon programme car l'utilisateur final dit qu'il s'agit d'un bogue ou n'achète pas le doux. Mais, comme vous l'avez dit, cela fera des utilisateurs suspects, mais je préfère avoir un minimum d'utilisateurs suspects et non un utilisateur max qui tente de tuer le doux pour obtenir des "choses" spéciales (comme elles pensent).