Hoy les presentaré la nueva característica de Windows 7/Windows Server 2008 R2: host de consola (ConHost.exe).
De hecho, ya sea como usuarios comunes o administradores empresariales, usaremos aplicaciones de consola más o menos en nuestras aplicaciones diarias de Windows y en nuestros procesos de operación y mantenimiento. La aplicación de consola no tiene interfaz de usuario. Necesitamos realizar operaciones de entrada y salida a través del símbolo del sistema (CMD, esto no es DOS, mucha gente está confundida).
Así que pensemos en ello, ¿con qué aplicaciones de consola viene Windows?
De hecho, los más típicos incluyen cmd.exe, nslookup.exe y telnet.exe.
.jpg)
En versiones anteriores de Windows, todas las aplicaciones que representaban actividades que no eran GUI (es decir, aplicaciones de consola) se coordinaban a través del proceso del sistema Csrss.exe cuando querían ejecutarse en el escritorio. Cuando una aplicación de consola necesita recibir caracteres, llama a una pequeña "API de consola" en Kernel32.dll para permitir que Kernel32 genere LPC para llamar a CSRSS. En este momento, CSRSS verificará y verificará la cola de entrada de la ventana de la consola y devolverá los resultados del modo de caracteres a la aplicación de la consola a través de Kernel32 para su asociación. El mecanismo de procesamiento de mensajes de las aplicaciones de consola en las primeras versiones de Windows se muestra en la siguiente figura:.jpg)
Este mecanismo de procesamiento ha creado un problema: incluso si una aplicación de consola se ejecuta en el contexto de un usuario normal, Csrss.exe siempre se ejecuta con los permisos de la cuenta del sistema local. Por lo tanto, en algunos casos, el malware desarrollado por "malos" puede obtener más privilegios a través de Csrss.exe ejecutado con permisos de cuenta del sistema local. Este modo de ataque se llama Shatter Attack.
En la era de Win7 y Windows Server 2008 R2, todas las aplicaciones de consola se colocan en un nuevo proceso contextual ConHost.exe para su ejecución, y ConHost (host de consola) y los programas de consola se ejecutan en el mismo contexto de nivel de seguridad, en lugar de emitirse. una solicitud de mensaje LPC a CSRSS para su procesamiento, en su lugar solicita ConHost. Por lo tanto, cualquier intento de aplicación de explotar una solicitud de mensaje para provocar una elevación automática de privilegios no tendrá éxito. La siguiente figura es un diagrama esquemático del nuevo mecanismo utilizado en Windows 7 y Windows Server 2008 R2:
.jpg)
ConHost reemplaza un cambio permanente en la forma en que las aplicaciones de consola manejan la E/S. Los usuarios no pueden obligar a Windows a volver al comportamiento de la consola en "modo heredado" a través del registro o la Política de grupo. Por lo tanto, los usuarios deben probar minuciosamente las aplicaciones antes de actualizar a Windows 7 o Windows Server 2008 R2. No olvide que, aunque la mayoría de las funciones de algunas aplicaciones se implementan a través de la GUI, los datos aún se procesan en lotes a través de la consola u otras interfaces funcionales en segundo plano. Por lo tanto, es muy necesario realizar pruebas funcionales integrales de la aplicación antes de la migración o nivelación.
Cuando una aplicación no se puede usar normalmente en Windows 7, primero debemos probarla y ejecutarla nuevamente con derechos de administrador para ver si ocurre el problema. De hecho, luego podemos usar Process Monitor para monitorear si la aplicación tiene derechos de acceso a los archivos o al registro. son normales. Si la aplicación aún no puede ejecutarse normalmente después de solucionar los problemas anteriores, debe considerar comunicarse con el ISV o su desarrollador.
Si una aplicación falla, el archivo de volcado de falla correspondiente es de gran ayuda para que los desarrolladores e ISV encuentren el meollo del problema. Si la aplicación deja de responder, puede intentar usar ADPlus para capturarla y su volcado de proceso ConHost.exe asociado. Las aplicaciones de consola pueden compartir muchos subprocesos de la consola de Windows. Por ejemplo, cuando el usuario inicia Telnet desde la ventana CMD, Telnet.exe se convertirá en un subproceso de Cmd.exe. En este caso, el host ConHost.exe procesa instancias de mensajes tanto del proceso principal como del proceso secundario. Al usar Process Explorer podemos confirmar qué procesos está manejando ConHost.exe:
.jpg)
También puede utilizar la función "Analizar cadena de espera" en el Monitor de recursos de Windows 7 para ver el proceso de aplicación del proceso ConHost.exe:.jpg)
Por último, ¡no olvide probar completamente la aplicación antes de la migración!