Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le
gestionnaire des tâches, ou alors mettre ce processus en tant que processus
Systeme pour éviter de l'arrêter.
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le gestionnaire des tâches, ou alors mettre ce processus en tant que processus Systeme pour éviter de l'arrêter.
Merci
S'il vous plait c'est urgent
Merci de me répondre
"the viper" a écrit :
Bonjour
J'utilise Visual studio net 2003.
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le
gestionnaire des tâches, ou alors mettre ce processus en tant que processus
Systeme pour éviter de l'arrêter.
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le gestionnaire des tâches, ou alors mettre ce processus en tant que processus Systeme pour éviter de l'arrêter.
Merci
Mehdi
On Fri, 17 Mar 2006 01:51:27 -0800, the viper wrote:
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le gestionnaire des tâches, ou alors mettre ce processus en tant que processus Systeme pour éviter de l'arrêter.
Windows ne fournit a ma connaissance aucune API pour faire ca de maniere simple (car le gestionnaire de tache est justement la pour lister *tous* les processus qui tournent sur la machine). 2 cas:
1) Tu a le code source de ce programme. Dans ce cas, modifie le de maniere a ce qu'il soit un service Windows au lieu d'etre une application normale puis installe le sous le compte Local System. De cette maniere, seul un administrateur sera a meme de demarrer ou stopper le programme. Attention: - un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte. - un service windows tourne sous un compte utilisateur completement independant du compte de l'utilisateur (ou des utilisateurs) logge sur la machine ce qui restraint ce qu'il peut faire
2) Tu n'a pas le code source du programme. Il y a un petit prog sur code project http://www.codeproject.com/system/xyntservice.asp qui te permet de "transformer" n'importe quel appli en service Windows. Jamais teste. Les meme restrictions que pour la solution 1) s'appliquent ce qui veux dire que si ton appli a une interface utilisateur il est fortement probable que la solution de code project ne fonctionne pas correctement. Et meme si elle fonctionne, le fait qu'une appli tournant sous le compte Local System ait une interface utilisateur ouvre un enorme trou de securite sur la machine (ce probleme est documente sur MSDN).
On Fri, 17 Mar 2006 01:51:27 -0800, the viper wrote:
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le
gestionnaire des tâches, ou alors mettre ce processus en tant que processus
Systeme pour éviter de l'arrêter.
Windows ne fournit a ma connaissance aucune API pour faire ca de maniere
simple (car le gestionnaire de tache est justement la pour lister *tous*
les processus qui tournent sur la machine). 2 cas:
1) Tu a le code source de ce programme. Dans ce cas, modifie le de maniere
a ce qu'il soit un service Windows au lieu d'etre une application normale
puis installe le sous le compte Local System. De cette maniere, seul un
administrateur sera a meme de demarrer ou stopper le programme. Attention:
- un service Windows ne doit avoir *aucune* interface utilisateur d'aucune
sorte.
- un service windows tourne sous un compte utilisateur completement
independant du compte de l'utilisateur (ou des utilisateurs) logge sur la
machine ce qui restraint ce qu'il peut faire
2) Tu n'a pas le code source du programme. Il y a un petit prog sur code
project http://www.codeproject.com/system/xyntservice.asp qui te permet de
"transformer" n'importe quel appli en service Windows. Jamais teste. Les
meme restrictions que pour la solution 1) s'appliquent ce qui veux dire que
si ton appli a une interface utilisateur il est fortement probable que la
solution de code project ne fonctionne pas correctement. Et meme si elle
fonctionne, le fait qu'une appli tournant sous le compte Local System ait
une interface utilisateur ouvre un enorme trou de securite sur la machine
(ce probleme est documente sur MSDN).
On Fri, 17 Mar 2006 01:51:27 -0800, the viper wrote:
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le gestionnaire des tâches, ou alors mettre ce processus en tant que processus Systeme pour éviter de l'arrêter.
Windows ne fournit a ma connaissance aucune API pour faire ca de maniere simple (car le gestionnaire de tache est justement la pour lister *tous* les processus qui tournent sur la machine). 2 cas:
1) Tu a le code source de ce programme. Dans ce cas, modifie le de maniere a ce qu'il soit un service Windows au lieu d'etre une application normale puis installe le sous le compte Local System. De cette maniere, seul un administrateur sera a meme de demarrer ou stopper le programme. Attention: - un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte. - un service windows tourne sous un compte utilisateur completement independant du compte de l'utilisateur (ou des utilisateurs) logge sur la machine ce qui restraint ce qu'il peut faire
2) Tu n'a pas le code source du programme. Il y a un petit prog sur code project http://www.codeproject.com/system/xyntservice.asp qui te permet de "transformer" n'importe quel appli en service Windows. Jamais teste. Les meme restrictions que pour la solution 1) s'appliquent ce qui veux dire que si ton appli a une interface utilisateur il est fortement probable que la solution de code project ne fonctionne pas correctement. Et meme si elle fonctionne, le fait qu'une appli tournant sous le compte Local System ait une interface utilisateur ouvre un enorme trou de securite sur la machine (ce probleme est documente sur MSDN).
Patrick Philippot
Mehdi wrote:
2) Tu n'a pas le code source du programme. Il y a un petit prog sur code project http://www.codeproject.com/system/xyntservice.asp qui te permet de "transformer" n'importe quel appli en service Windows.
Ou plus officiellement, SVRANY du resource Kit.
Pour compléter la réponse:
On ne peut pas à ma connaissance empêcher qu'un processus soit listé par le Task Manager ou par un outil comme Process Explorer.
Une fois l'application transformée en service, il faut savoir qu'un admin pourra toujours l'arrêter.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Mehdi wrote:
2) Tu n'a pas le code source du programme. Il y a un petit prog sur
code project http://www.codeproject.com/system/xyntservice.asp qui te
permet de "transformer" n'importe quel appli en service Windows.
Ou plus officiellement, SVRANY du resource Kit.
Pour compléter la réponse:
On ne peut pas à ma connaissance empêcher qu'un processus soit listé par
le Task Manager ou par un outil comme Process Explorer.
Une fois l'application transformée en service, il faut savoir qu'un
admin pourra toujours l'arrêter.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
2) Tu n'a pas le code source du programme. Il y a un petit prog sur code project http://www.codeproject.com/system/xyntservice.asp qui te permet de "transformer" n'importe quel appli en service Windows.
Ou plus officiellement, SVRANY du resource Kit.
Pour compléter la réponse:
On ne peut pas à ma connaissance empêcher qu'un processus soit listé par le Task Manager ou par un outil comme Process Explorer.
Une fois l'application transformée en service, il faut savoir qu'un admin pourra toujours l'arrêter.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
David Alloza
Par curiosité.. c'est pour quoi faire ? les seules applications qui me viennent a l'idée pour ce genre de requettes concernent les backdoors spyware et autres virus...
"the viper" a écrit dans le message de news:
Bonjour
J'utilise Visual studio net 2003.
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le gestionnaire des tâches, ou alors mettre ce processus en tant que processus Systeme pour éviter de l'arrêter.
Merci
Par curiosité..
c'est pour quoi faire ?
les seules applications qui me viennent a l'idée pour ce genre de requettes
concernent les backdoors spyware et autres virus...
"the viper" <theviper@discussions.microsoft.com> a écrit dans le message de
news: 4FBDFF53-0023-4839-9DF8-DE2E25ADBAD6@microsoft.com...
Bonjour
J'utilise Visual studio net 2003.
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le
gestionnaire des tâches, ou alors mettre ce processus en tant que
processus
Systeme pour éviter de l'arrêter.
Par curiosité.. c'est pour quoi faire ? les seules applications qui me viennent a l'idée pour ce genre de requettes concernent les backdoors spyware et autres virus...
"the viper" a écrit dans le message de news:
Bonjour
J'utilise Visual studio net 2003.
Je souhaite masquer un processus afin qu'il n'apparaisse plus dans le gestionnaire des tâches, ou alors mettre ce processus en tant que processus Systeme pour éviter de l'arrêter.
Merci
Herve Chapalain
Tu peux egalement ecrire un driver (mode kernel) et le piloter avec des IO controls. -herve
Tu peux egalement ecrire un driver (mode kernel) et le piloter avec des IO
controls.
-herve
vu qu'on etait dans un newsgroup C#... l'idée du driver ne m'etait pas venue a l'idée..
"Herve Chapalain" a écrit dans le message de news: eXgM$
Tu peux egalement ecrire un driver (mode kernel) et le piloter avec des IO controls. -herve
Tsunoo Rhilty
Par curiosité.. c'est pour quoi faire ? les seules applications qui me viennent a l'idée pour ce genre de requettes concernent les backdoors spyware et autres virus...
Par curiosité..
c'est pour quoi faire ?
les seules applications qui me viennent a l'idée pour ce genre de
requettes concernent les backdoors spyware et autres virus...
Par curiosité.. c'est pour quoi faire ? les seules applications qui me viennent a l'idée pour ce genre de requettes concernent les backdoors spyware et autres virus...
> Attention: - un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
Cette phrase est hélas tout à fait fausse. Un service peut avoir une interface. Ce n'est pas pour rien qu'il y a une encoche "interagir avec le bureau"
Et dixit MS (ce qui prouve que ca marche) => Dans tous les cas, Microsoft vous recommande que vous ne modifiez pas le paramètre Autoriser le service à interagir avec le Bureau. Si vous autorisez le service à interagir avec le Bureau, toute information sur le Bureau, l'information affichée par le service s'affiche également sur le Bureau d'un utilisateur interactif. Un utilisateur malveillant peut être en mesure à contrôler le service ou à attaquer le service du Bureau interactif.
> Attention:
- un service Windows ne doit avoir *aucune* interface utilisateur d'aucune
sorte.
Cette phrase est hélas tout à fait fausse.
Un service peut avoir une interface. Ce n'est pas pour rien qu'il y a une
encoche "interagir avec le bureau"
Et dixit MS (ce qui prouve que ca marche)
=>
Dans tous les cas, Microsoft vous recommande que vous ne modifiez pas le
paramètre Autoriser le service à interagir avec le Bureau. Si vous autorisez
le service à interagir avec le Bureau, toute information sur le Bureau,
l'information affichée par le service s'affiche également sur le Bureau d'un
utilisateur interactif. Un utilisateur malveillant peut être en mesure à
contrôler le service ou à attaquer le service du Bureau interactif.
> Attention: - un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
Cette phrase est hélas tout à fait fausse. Un service peut avoir une interface. Ce n'est pas pour rien qu'il y a une encoche "interagir avec le bureau"
Et dixit MS (ce qui prouve que ca marche) => Dans tous les cas, Microsoft vous recommande que vous ne modifiez pas le paramètre Autoriser le service à interagir avec le Bureau. Si vous autorisez le service à interagir avec le Bureau, toute information sur le Bureau, l'information affichée par le service s'affiche également sur le Bureau d'un utilisateur interactif. Un utilisateur malveillant peut être en mesure à contrôler le service ou à attaquer le service du Bureau interactif.
Mehdi
On Fri, 17 Mar 2006 19:54:06 +0100, Tsunoo Rhilty wrote:
Attention: - un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
Cette phrase est hélas tout à fait fausse. Un service peut avoir une interface. Ce n'est pas pour rien qu'il y a une encoche "interagir avec le bureau"
*Techniquement*, oui, un service peut avoir une interface utilisateur grace a cette fameuse (et malheureuse) option "interagir avec le bureau". Cela dit, cette option doit etre utilisee avec une precaution extreme et uniquement si vous savez vraiment ce que vous faites. Dans 99,99& des cas, cette option ne devrait etre utlisee que pour du debugage (et meme dans ce cas, il y a d'autres methodes beaucoup plus sures et simples que d'autoriser votre service a interagir avec le bureau. Winodws Vista interdira par ailleurtout service Windows d'interagir avec le bureau). Ce n'est pas pour rien que le .NET Framework. malgre le fait qu'il offre un support quasi-complet pour le developpement et le controle des services Windows n'offre aucun moyen d'activer cette option. Cette propriete a ete largement documente (y compris dans MSDN) pour etre responsable d'enormes trous de securite dans Windows lorsqu'elle est activee.
Je maintiens: un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
Et dixit MS (ce qui prouve que ca marche) => Dans tous les cas, Microsoft vous recommande que vous ne modifiez pas le paramètre Autoriser le service à interagir avec le Bureau. Si vous autorisez le service à interagir avec le Bureau, toute information sur le Bureau, l'information affichée par le service s'affiche également sur le Bureau d'un utilisateur interactif. Un utilisateur malveillant peut être en mesure à contrôler le service ou à attaquer le service du Bureau interactif.
C'est une maniere tres diplomatique de dire les choses effectivement. Dit d'une autre maniere: si un service Windows tournant sous le compte Local System (comme le sont la plupart des services windows) a une interface utilisateur, alors quasiment n'importe qui ayant access a cette machine (meme avec un compte windows limite) peut avoit un acces administrateur sur cette machine grace a votre service Windows. Certain logiciels d'anti-virus par exemple ont fait les frais de cette faille par le passe.
On Fri, 17 Mar 2006 19:54:06 +0100, Tsunoo Rhilty wrote:
Attention:
- un service Windows ne doit avoir *aucune* interface utilisateur d'aucune
sorte.
Cette phrase est hélas tout à fait fausse.
Un service peut avoir une interface. Ce n'est pas pour rien qu'il y a une
encoche "interagir avec le bureau"
*Techniquement*, oui, un service peut avoir une interface utilisateur grace
a cette fameuse (et malheureuse) option "interagir avec le bureau". Cela
dit, cette option doit etre utilisee avec une precaution extreme et
uniquement si vous savez vraiment ce que vous faites. Dans 99,99& des cas,
cette option ne devrait etre utlisee que pour du debugage (et meme dans ce
cas, il y a d'autres methodes beaucoup plus sures et simples que
d'autoriser votre service a interagir avec le bureau. Winodws Vista
interdira par ailleurtout service Windows d'interagir avec le bureau). Ce
n'est pas pour rien que le .NET Framework. malgre le fait qu'il offre un
support quasi-complet pour le developpement et le controle des services
Windows n'offre aucun moyen d'activer cette option. Cette propriete a ete
largement documente (y compris dans MSDN) pour etre responsable d'enormes
trous de securite dans Windows lorsqu'elle est activee.
Je maintiens: un service Windows ne doit avoir *aucune* interface
utilisateur d'aucune sorte.
Et dixit MS (ce qui prouve que ca marche)
=>
Dans tous les cas, Microsoft vous recommande que vous ne modifiez pas le
paramètre Autoriser le service à interagir avec le Bureau. Si vous autorisez
le service à interagir avec le Bureau, toute information sur le Bureau,
l'information affichée par le service s'affiche également sur le Bureau d'un
utilisateur interactif. Un utilisateur malveillant peut être en mesure à
contrôler le service ou à attaquer le service du Bureau interactif.
C'est une maniere tres diplomatique de dire les choses effectivement. Dit
d'une autre maniere: si un service Windows tournant sous le compte Local
System (comme le sont la plupart des services windows) a une interface
utilisateur, alors quasiment n'importe qui ayant access a cette machine
(meme avec un compte windows limite) peut avoit un acces administrateur sur
cette machine grace a votre service Windows. Certain logiciels d'anti-virus
par exemple ont fait les frais de cette faille par le passe.
On Fri, 17 Mar 2006 19:54:06 +0100, Tsunoo Rhilty wrote:
Attention: - un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
Cette phrase est hélas tout à fait fausse. Un service peut avoir une interface. Ce n'est pas pour rien qu'il y a une encoche "interagir avec le bureau"
*Techniquement*, oui, un service peut avoir une interface utilisateur grace a cette fameuse (et malheureuse) option "interagir avec le bureau". Cela dit, cette option doit etre utilisee avec une precaution extreme et uniquement si vous savez vraiment ce que vous faites. Dans 99,99& des cas, cette option ne devrait etre utlisee que pour du debugage (et meme dans ce cas, il y a d'autres methodes beaucoup plus sures et simples que d'autoriser votre service a interagir avec le bureau. Winodws Vista interdira par ailleurtout service Windows d'interagir avec le bureau). Ce n'est pas pour rien que le .NET Framework. malgre le fait qu'il offre un support quasi-complet pour le developpement et le controle des services Windows n'offre aucun moyen d'activer cette option. Cette propriete a ete largement documente (y compris dans MSDN) pour etre responsable d'enormes trous de securite dans Windows lorsqu'elle est activee.
Je maintiens: un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
Et dixit MS (ce qui prouve que ca marche) => Dans tous les cas, Microsoft vous recommande que vous ne modifiez pas le paramètre Autoriser le service à interagir avec le Bureau. Si vous autorisez le service à interagir avec le Bureau, toute information sur le Bureau, l'information affichée par le service s'affiche également sur le Bureau d'un utilisateur interactif. Un utilisateur malveillant peut être en mesure à contrôler le service ou à attaquer le service du Bureau interactif.
C'est une maniere tres diplomatique de dire les choses effectivement. Dit d'une autre maniere: si un service Windows tournant sous le compte Local System (comme le sont la plupart des services windows) a une interface utilisateur, alors quasiment n'importe qui ayant access a cette machine (meme avec un compte windows limite) peut avoit un acces administrateur sur cette machine grace a votre service Windows. Certain logiciels d'anti-virus par exemple ont fait les frais de cette faille par le passe.
Patrick Philippot
Mehdi wrote:
Je maintiens: un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
J'abonde. L'interface utilisateur doit être un processus séparé qui communique avec le service via un mécanisme d'IPC quelconque.
J'apporterai juste une petite nuance. L'option "interagir avec le bureau" permet cependant au service, dans certains cas, d'émettre des messages d'erreur quand c'est nécessaire et que l'UI ne peut pas/plus prendre ces messages en charge. C'est d'ailleurs le cas de beaucoup de services y compris certains services Microsot. On ne peut toutefois pas parler dans ce cas d'interaction avec l'utilisateur.
Il y a cependant un moyen de contourner le problème, je le concède. J'ai eu à gérer ce genre de situation et, au lieu de faire afficher la message box par le service lui-même, j'injecte dans la session de l'utilisateur courant un process qui se charge de cet affichage. Il n'y a cependant pas toujours un utilisateur courant.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Mehdi wrote:
Je maintiens: un service Windows ne doit avoir *aucune* interface
utilisateur d'aucune sorte.
J'abonde. L'interface utilisateur doit être un processus séparé qui
communique avec le service via un mécanisme d'IPC quelconque.
J'apporterai juste une petite nuance. L'option "interagir avec le
bureau" permet cependant au service, dans certains cas, d'émettre des
messages d'erreur quand c'est nécessaire et que l'UI ne peut pas/plus
prendre ces messages en charge. C'est d'ailleurs le cas de beaucoup de
services y compris certains services Microsot. On ne peut toutefois pas
parler dans ce cas d'interaction avec l'utilisateur.
Il y a cependant un moyen de contourner le problème, je le concède. J'ai
eu à gérer ce genre de situation et, au lieu de faire afficher la
message box par le service lui-même, j'injecte dans la session de
l'utilisateur courant un process qui se charge de cet affichage. Il n'y
a cependant pas toujours un utilisateur courant.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Je maintiens: un service Windows ne doit avoir *aucune* interface utilisateur d'aucune sorte.
J'abonde. L'interface utilisateur doit être un processus séparé qui communique avec le service via un mécanisme d'IPC quelconque.
J'apporterai juste une petite nuance. L'option "interagir avec le bureau" permet cependant au service, dans certains cas, d'émettre des messages d'erreur quand c'est nécessaire et que l'UI ne peut pas/plus prendre ces messages en charge. C'est d'ailleurs le cas de beaucoup de services y compris certains services Microsot. On ne peut toutefois pas parler dans ce cas d'interaction avec l'utilisateur.
Il y a cependant un moyen de contourner le problème, je le concède. J'ai eu à gérer ce genre de situation et, au lieu de faire afficher la message box par le service lui-même, j'injecte dans la session de l'utilisateur courant un process qui se charge de cet affichage. Il n'y a cependant pas toujours un utilisateur courant.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
