Prevenir la aplicación C# del proceso kill

¿Cómo puedo proteger mi aplicación C# de que alguien mate su proceso a través de taskman o mediante programación?Prevenir la aplicación C# del proceso kill

Aquí es mi escenario:

Aplicación A es una aplicación MFC desarrollado por otro equipo. Tiene una interfaz remota basada en texto no publicada que se habilita a través de una puerta trasera.

Estoy desarrollando la aplicación B, una aplicación C# WinForms que interactúa con A. B habilita la puerta trasera de A cuando necesita acceso remoto la cierra cuando termina (o cuando falla).

Estoy explorando formas en las que los usuarios podrían abusar de B para obtener acceso a la funcionalidad oculta de A, como matar el proceso de B después de haber habilitado la interfaz remota de A. Me gustaría tener una última oportunidad para que B cierre la puerta trasera de A cuando eso suceda.

B usa localhost para interactuar con A, por lo que no me preocupa el escenario de apagado.

Busco una solución que no implique cambio de A.

No espero ser capaz de detener oscuro Tangente (aunque eso sería una ventaja), pero en este momento un script kiddie podría tener su camino con este diseño :)

Estas aplicaciones se ejecutan en Windows XP, pero también pronto apoyar Vista & 7.

Gracias de antemano, Jim

Fuente

2010-06-25 Jim C

Hacer esto puede marcar su aplicación como malware/a virus por algunos motores de detección. Este es un patrón frecuentemente utilizado por virus o malware. – Aren

También es, curiosamente, una táctica también utilizada por los escáneres antivirus/malware, ya que el malware intentará desactivar el software de detección residente. Lo que significa que EXISTEN razones válidas para hacerlo, aunque los casos de uso son (IMO) bastante definidos. – Joe

Parece que está más interesado en cómo asegurarse de limpiar antes de irse. Si puede dar más detalles, puede obtener algunas respuestas que lo ayuden a resolver su problema * real *. –

No puede - siempre que el usuario tenga derecho a llamar a TerminateProcess en su programa, no puede evitar que el proceso final lo mate de inmediato en el administrador de tareas. Raymond Chen publicó esto hace algún tiempo: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/16/73780.aspx

Fuente

2010-06-25 22:41:43 Michael

Entonces, ¿nunca ha visto el virus que impide que el usuario abra el administrador de tareas, el panel de control o MSCONFIG?Mi amigo captó esto haciendo clic en "¡Tienes un virus!" bandera. Doloroso. –

@Phil - incluso yo no iría tan mal :) De todos modos, uno podría escribir una aplicación que ejecutaría TerminateProcess programáticamente, por lo que la protección contra la terminación basada en GUI no es suficiente. –

Al final, la discusión en el enlace que proporcionó me convenció de mi locura. Voy a presionar al equipo A. –

realmente, realmente, realmente no quiero hacer esto. ¡Hace que los usuarios se enojen mucho! Sin embargo, si se supone que es un servicio, ejecútelo como una cuenta de servicio y no otorgue derechos de administrador a los usuarios.

Fuente

2010-06-25 22:07:36 George

Ver mi publicación editada. –

Es una aplicación WinForms. –

Respuesta corta: no puede y no debe.

Respuesta larga: Puede intentar iniciar un segundo proceso de 'ayuda', que comprueba cada x segundos si su aplicación todavía se está ejecutando. Si no es así, lo reinicia.

Si desea que un proceso se ejecute durante mucho tiempo simplemente no confíe en los usuarios para que siga funcionando, considere los servicios de Windows. Ellos están diseñados para esto.

Fuente

2010-06-25 22:09:18

Por lo que sé, no puede, e incluso si pudiera, realmente no debería. imagina lo molesto que sería si no pudieras forzar a matar una aplicación.

Si es importante que su aplicación siga ejecutándose, siempre podría crear un servicio de Windows que "haga ping" la aplicación para asegurarse de que se está ejecutando (puede usar named pipes, sockets, pid files ... lo que sea). si el servicio detecta que el proceso ha muerto, puede reiniciarlo. esta es probablemente tu mejor apuesta.

Fuente

2010-06-25 22:09:59 luke

Estoy dispuesto a cerrar la aplicación cuando lo intentan, pero primero necesito hacer algunas cosas.

Tener los pasos necesarios para el apagado del programa conduce a programas frágiles que se rompen fácilmente. Incluso si pudieras evitar que alguien matara tu programa a través del administrador de tareas, no puedes evitar que apaguen la computadora o incluso que jalen el cable de la pared. Cualquier tarea que era tan vitalmente importante de completar se perderá. ¿Y qué pasa si hay un corte de energía? De nuevo, su tarea no se completará y su código de limpieza vital no se ejecutará.

En su lugar, debe hacer que su programa sea robusto ante fallas en cualquier punto. Use transacciones y siempre guarde el estado en archivos de forma atómica: asegúrese de tener siempre al menos una copia válida de sus datos. No sobrescriba los archivos importantes de manera que se vuelvan temporalmente inválidos.

Finalmente, puede agregar un cuadro de diálogo a su programa que cuando intenta cerrarlo, les advierte que el programa debe cerrarse correctamente. Si realiza el apagado rápido, los usuarios no querrán matarlo y dejarán que finalice correctamente. Si su cierre demora años, la gente intentará matarlo. Si eres amable con tus usuarios, también serán amables contigo.

Si apagarse rápidamente significa que el usuario perderá algo de trabajo sin terminar, pregúntele al respecto y bríndeles la oportunidad de esperar a que termine la tarea, pero si realmente desean abandonar su programa, entonces déjelos.

Fuente

2010-06-25 22:10:37

Estás haciendo una suposición general para alguien que aparece con tanta fuerza ... Específicamente estás asumiendo POR QUÉ quiere ejecutar algo en la aplicación kill. Hay razones para asegurarse de que se cierre, a excepción de tener escrituras sucias/todavía abrir transacciones por ahí. Mayormente cerrando cualquier proceso niño u otros recursos. –

Tuve este problema una vez. Tuve un proceso que utilizaba semáforos para comunicarse con otras instancias de sí mismo. Si lo termina mal, dejaría un número desconocido de conteos en el semáforo, arruinando todas las demás instancias. – Gabe

@Jim Leonardo: Otra forma de abordar el problema que menciona es hacer que los procesos secundarios se programen de manera más robusta para manejar correctamente la condición de que el programa principal se canceló repentinamente. La robustez en la aplicación distribuida aumenta si cada componente puede funcionar con sensatez independientemente de los demás. –

Creo que todos se han perdido el punto. Si lo leo correctamente (después de su edición), ¿desea saber cuándo lo "matan" para que pueda cerrarlo con elegancia?

El objetivo de "matar" es que "no puedes" detenerlo. Por supuesto, hay soluciones como usar una segunda aplicación para revivir una aplicación muerta, pero eso no tiene nada que ver con simplemente poder cerrar con gracia.

Lo mejor es ejecutar un servicio (para que no te maten, simplemente solicitar que se apague) o reestructurar la forma en que funciona tu aplicación para que no tenga que "arreglarse" antes de que se cierre. Cuando se cierra una aplicación, la mayoría de los recursos que contiene se limpian automáticamente, por lo que solo es realmente su propia información la que tiene que cerrar limpiamente. Los enfoques que puede probar son:

Frecuentemente ingrese su estado en el disco para que no pierda mucho (o nada) si se cierra inesperadamente. (Recuerde vaciar todas las secuencias de E/S para asegurarse de que están comprometidas en el disco)
Guarde información en el disco que le permita detectar un apagado inesperado la próxima vez que se ejecute su programa, para poder detectar y rectificar cualquier problema podría haber sido causado por la muerte.
Dile a tus usuarios que no sean idiotas, y sal de tu aplicación muy bien. Pórtelos a los ojos si lo ignoran. Por lo general, después de no más de dos veces escuchan :-)

Fuente

2010-06-25 22:44:50

El servicio se puede matar. – Rohit

+1 para "realizar la recuperación la próxima vez que se inicie la aplicación", ya que se producen cierres inesperados (evento de energía, falla de disco, etc.) –

@rohit: muchos usuarios saben cómo eliminar tareas. Relativamente pocos saben cómo detener un servicio, y mucho menos * matar * uno. –

Cuando la aplicación se inicia por primera vez no se podía ejecutar una tercera AP/proceso que se ejecuta en segundo plano y los intentos de devolución de llamada a la aplicación B de vez Por lo tanto, cuando esa aplicación B se cierra, la aplicación C puede ver eso y ejecuta un procedimiento para cerrar la puerta trasera de la aplicación A.

Así que cuando la aplicación B se cierra con éxito a través del botón Cerrar previsto que desactivará la aplicación C de comprobación de la aplicación B sigue trabajando bien ...

No estoy realmente la mejor con C# en este momento, pero mirando a su problema que es probablemente una de las maneras en que trataría de hacerlo ...

Además, si la aplicación B también comprueba la aplicación C, si la aplicación C se ha desactivado, la aplicación B cerrará la puerta trasera si puede.

Como dicen los demás esto puede no ser una buena idea aunque.

Fuente

2010-06-28 15:39:03 RobertPitt

Interesante. Desafortunadamente, "App B" representa una clase de aplicaciones, cada una de las cuales manipula la puerta trasera. Aunque solo una B se ejecuta a la vez, esto complicaría la forma en que una 3ª aplicación/servicio podría supervisar la existencia de B. –

Como dije y me disculpo por la falta de habilidades en esta área, mi comentario se basó en lo que pensé que sería posible y en cómo resolvería una situación como esa. Crear e implementar esto de mi lado no va a un punto fuerte, simplemente estaba tratando de darte una solución práctica. tu el hombre para averiguar cómo hacerlo. – RobertPitt

Ya, me doy cuenta de eso. No estoy buscando que escriba mi código, simplemente le doy más información sobre el concepto B. –

Con el fin de impedir que la aplicación sea terminado, se ejecuta la aplicación como otro usuario (decir como un servicio , o como otra cuenta de usuario), y los usuarios límite que usuario estándar.

De esta manera, ningún usuario malintencionado puede matar su proceso, ya que solo los administradores pueden matarlo, y ese es un privilegio que aparentemente no confía en nadie.

Tiene la ventaja de seguir el diseño previsto del sistema operativo.

Fuente

2010-06-28 15:44:34

@Jim

Si App A puede recibir modificación solicita

Preferiblemente, lo haría una arquitectura donde todos App B de están registrados al abrir la puerta trasera y están obligados a hacer ping App A con el registro en un intervalo para que la aplicación A pueda cerrar su propia puerta trasera en la aplicación B sin informarle que todavía necesita acceso. Esto aún no es perfectamente seguro, pero la aplicación A no debe estructurarse con una interfaz de este tipo sin algún tipo de autorregulación para medios de comunicación "seguros".
O bien, podría sugerir que se modifique la Aplicación A para comprobar si hay procesos válidos y si no se encuentra ninguno mientras la puerta trasera está abierta, se cierra (esto es falso porque pasa por el nombre procesado).

De lo contrario, parece que la aplicación B debe cerrar la puerta trasera tan a menudo como sea posible cuando no necesita acceso inmediato.

Requerir una aplicación B para proporcionar seguridad de acceso a la aplicación A es un modelo deficiente.

Fuente

2010-06-28 16:14:05

B cierra la puerta trasera cuando se completa la tarea. Estoy de acuerdo, A no está diseñado de manera óptima. –

Prevenir la aplicación C# del proceso kill

Respuesta

Cuestiones relacionadas