Invocar pantalla azul de la muerte con código administrado

Question

Solo tengo curiosidad aquí: ¿es posible invocar una pantalla azul de la muerte de Windows usando el código administrado .net en Windows XP / Vista? Y si es posible, ¿cuál podría ser el código de ejemplo?

Solo para el registro, esto no es para ningún propósito malicioso, solo me pregunto qué tipo de código se necesitaría para matar realmente el sistema operativo como se especifica.

Answer 1

Lo del teclado es probablemente una buena opción, pero si necesita hacerlo por código, continúe leyendo ...

Realmente no necesitas nada para vomitar, per se, todo lo que necesitas hacer es encontrar la función KeBugCheck (Ex) e invocar eso.

http://msdn.microsoft.com/en-us/library/ ms801640.aspx http://msdn.microsoft.com/en-us/library/ms801645.aspx

Para bloqueos iniciados manualmente, desea utilizar 0xE2 (MANUALLY_INITIATED_CRASH) o 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) como código de verificación de errores. Están reservados explícitamente para ese uso.

Sin embargo, encontrar la función puede resultar un poco complicado. El DDK de Windows puede ayudar (consulte Ntddk.h): no lo tengo disponible en este momento y parece que no puedo encontrar información decisiva en este momento: creo que está en ntoskrnl.exe o ntkrnlpa.exe, pero no estoy seguro, y actualmente no tengo las herramientas para verificarlo.

Es posible que le resulte más fácil escribir una aplicación C ++ simple o algo que llame a la función, y luego simplemente ejecutarla.

Eso sí, estoy suponiendo que Windows no le impide acceder a la función desde el espacio de usuario (.NET podría tener algunas disposiciones especiales). No lo he probado yo mismo.

Answer 2

No sé si realmente funciona y estoy seguro de que necesita derechos de administrador, pero puede configurar la clave de registro CrashOnCtrlScroll y luego usar SendKeys para enviar CTRL + Scroll Lock + Scroll Lock.

Pero creo que esto TIENE que provenir del controlador del teclado, por lo que supongo que un simple SendKeys no es lo suficientemente bueno y que de alguna manera tendrías que conectarlo al controlador del teclado (suena realmente desordenado) o comprobar que CrashDump tiene un API que se puede llamar con P / Invoke.

http://support.microsoft.com/kb/244139

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parámetros
Nombre: CrashOnCtrlScroll
Tipo de datos: REG_DWORD
Valor: 1
Reiniciar

Answer 3

Tendría que decir que no. Tendría que invocar e interactuar con un controlador u otro código que viva en el espacio del kernel. El código .NET vive muy lejos de esta área, aunque se ha hablado mucho sobre controladores administrados en futuras versiones de Windows. Solo espere unos años más y puede colapsar como nuestros amigos no administrados.

Answer 4

Hasta donde yo sé, un BSOD real requiere una falla en el código del modo kernel. Vista todavía tiene BSOD, pero son menos frecuentes porque el nuevo modelo de controlador tiene menos controladores en modo kernel. Cualquier falla en el modo de usuario solo dará como resultado que su aplicación sea eliminada.

No puede ejecutar código administrado en modo kernel. Entonces, si desea BSOD, debe usar PInvoke. Pero incluso esto es bastante difícil. Debe hacer algunas PInvokes realmente elegantes para que algo en el modo kernel se muerda.

Pero entre los miles de usuarios de SO probablemente haya alguien que haya hecho esto :-)

Answer 5

Puede utilizar la herramienta de OSR Online que desencadena un bloqueo del kernel. Nunca lo he probado yo mismo, pero imagino que podrías ejecutarlo a través de la clase de proceso .net estándar:

http://www.osronline.com/article.cfm?article=153

Answer 6

Una vez logré generar un BSOD en Windows XP usando System.Net.Sockets en .NET 1.1 de manera irresponsable. Podría repetirlo con bastante regularidad, pero desafortunadamente eso fue hace un par de años y no recuerdo exactamente cómo lo activé, o ya no tengo el código fuente.

Answer 7

Pruebe la entrada de video en vivo usando directshow en directx8 o directx9, la mayoría de las llamadas van a los controladores de video en modo kernel. Tuve éxito en muchas pantallas azules cuando ejecuté un procedimiento de devolución de llamada desde una fuente de captura de video en vivo, particularmente si su devolución de llamada toma mucho tiempo, puede detener todo el controlador del Kernel.

Answer 8

Es posible que el código administrado provoque una comprobación de errores cuando tiene acceso a controladores de kernel defectuosos. Sin embargo, sería el controlador del núcleo el que causa directamente el BSOD (por ejemplo, los BSOD DirectShow de uffe, los BSOD de socket de Terence Lewis o los BSOD que se ven cuando se utiliza BitTorrent con ciertos adaptadores de red).

El acceso directo en modo de usuario a recursos privilegiados de bajo nivel puede causar una verificación de errores (por ejemplo, garabatear en Device \ PhysicalMemory , si no corrompe su disco duro primero; Vista no permitir el acceso en modo de usuario a la memoria física).

Si solo desea un archivo de volcado, la sugerencia de Mendelt de usar WinDbg es una idea mucho mejor que explotar un error en un controlador de kernel. Desafortunadamente, el comando .dump no es compatible con la depuración local del núcleo, por lo que necesitaría una segunda PC conectada en serie o 1394, o una VM conectada en un puerto en serie virtual. LiveKd puede ser una opción de PC única, si no lo hace necesita que el estado del volcado de memoria sea completamente coherente.

Answer 9

Este no necesita ningún controlador en modo kernel, solo un SeDebugPrivilege. Puede configurar su proceso crítico NtSetInformationProcess o RtlSetProcessIsCritical y simplemente elimine su proceso. Verá el mismo código de comprobación de errores cuando elimine csrss.exe, porque configura el mismo "crítico". marca en su proceso.

Answer 10

Desafortunadamente, sé cómo hacer esto porque un servicio .NET en nuestro servidor estaba causando una pantalla azul. (Nota: Windows Server 2008 R2, no XP / Vista).

Apenas podía creer que un programa .NET fuera el culpable, pero lo fue. Además, acabo de replicar el BSOD en una máquina virtual.

El código infractor provoca un 0x00000f4:

string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace

foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
    Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
    process.Kill();
    r = true;
}

Si alguien se pregunta por qué quiero replicar la pantalla azul, no es nada malicioso. Modifiqué nuestra clase de registro para tomar un argumento diciéndole que escriba directamente en el disco ya que las acciones anteriores al BSOD no aparecían en el registro a pesar de que se llamaba a .Flush (). Repliqué el bloqueo del servidor para probar el cambio de registro. La VM se bloqueó debidamente pero el registro funcionó.

EDITAR: matar csrss.exe parece ser lo que causa la pantalla azul. Según los comentarios, es probable que esto ocurra en el código del kernel.