Invoque a tela azul de morte usando código gerenciado

Question

Apenas curioso aqui: é possível invocar uma tela de morte do Windows Blue usando o código gerenciado .NET no Windows XP/Vista? E se for possível, qual seria o código de exemplo?

Apenas para o registro, isso não é para nenhum propósito malicioso, só estou me perguntando que tipo de código seria necessário para realmente matar o sistema operacional, conforme especificado.

Answer 1

O teclado é provavelmente uma boa opção, mas se você precisar fazer isso por código, continue lendo ...

Você realmente não precisa de nada para fazer um barf, por si só, tudo o que você precisa fazer é encontrar a função kebugcheck (ex) e invocar isso.

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

Para falhas iniciadas manualmente, você deseja usar 0xe2 (manualmente_initiated_crash) ou 0xDeadDead (manualmente_initiated_crash1) como o código de verificação de bug. Eles são reservados explicitamente para esse uso.

No entanto, encontrar a função pode ser um pouco complicado. O Windows DDK pode ajudar (verifique ntddk.h) - Não tenho disponível no momento e não consigo encontrar informações decisivas agora - eu acho Está em çoskrnl.exe ou ntkrnlpa.exe, mas não tenho certeza e atualmente não tenho as ferramentas para verificar.

Você pode achar mais fácil escrever um aplicativo C ++ simples ou algo que chama a função e, em seguida, apenas executando isso.

Veja bem, eu sou assumindo Que o Windows não o prenda de acessar a função do espaço do usuário (.NET pode ter algumas disposições especiais). Eu não testei sozinho.

Answer 2

Não sei se realmente funciona e tenho certeza de que você precisa de direitos de administrador, mas você pode definir a chave de registro CrashOnCtrlScroll e usar um SendKeys para enviar Ctrl+Roll Lock+Scroll Lock.

Mas acredito que isso tem que vir do driver do teclado, então acho que um simples sendKeys não é bom o suficiente e você precisaria de alguma forma conectar -se ao driver do teclado (parece realmente bagunçado) ou o check -in desse crashdump tem uma API que pode ser chamado com P/Invoke.

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

HKEY_LOCAL_MACHINE SYSTEM CurrentControlset Services i8042Prt Parâmetros
Nome: CrashOnCtrlScroll
Tipo de dados: reg_dword
Valor: 1
Reiniciar

Answer 3

Eu teria que dizer não. Você teria que p/invocar e interagir com um motorista ou outro código que vive no espaço do kernel. O código .NET vive muito distante dessa área, embora tenha havido alguma conversa sobre motoristas gerenciados em versões futuras do Windows. Espere mais alguns anos e você pode travar como nossos amigos não gerenciados.

Answer 4

Tanto quanto eu sei, um BSOD real requer falha no código do modo de kernel. O Vista ainda tem o BSOD, mas eles são menos frequentes porque o novo modelo de driver tem menos drivers no modo kernel. Quaisquer falhas no modo de usuário resultarão na morte do seu aplicativo.

Você não pode executar o código gerenciado no modo kernel. Portanto, se você quiser BSOD, precisa usar o Pinvoke. Mas mesmo isso é bastante difícil. Você precisa fazer alguns pinvokes realmente sofisticados para obter algo no modo kernel no Barf.

Mas entre os milhares de usuários, provavelmente há alguém que fez isso :-)

Answer 5

Você pode usar a ferramenta da OSR Online que desencadeia um acidente de kernel. Eu nunca tentei, mas imagino que você possa executá -lo através da classe de processo .NET padrão:

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

Answer 6

Uma vez consegui gerar um BSOD no Windows XP usando o System.net.sockets no .NET 1.1 irresponsável. Eu podia repetir com bastante regularidade, mas infelizmente isso foi há alguns anos e não me lembro exatamente de como o desencadei ou tenho mais o código -fonte.

Answer 7

Experimente videoinput ao vivo usando o DirectShow no DirectX8 ou DirectX9, a maioria das chamadas vá para os drivers de vídeo do Kernel Mode. Eu suportado em muitas telas azuis ao executar um procedimento de retorno de chamada da fonte de videocaptura ao vivo, particularmente, se o seu retorno de chamada levar muito tempo, poderá interromper todo o driver do kernel.

Answer 8

É possível que o código gerenciado cause um bugcheck quando tiver acesso a drivers de kernel com defeito. No entanto, seria o driver do kernel que causa diretamente o BSOD (por exemplo, o DirectShow BSODS de Uffe, o soquete BSODS de Terence Lewis ou o BSODS visto ao usar o Bittorrent com determinados adaptadores de rede).

O acesso direto ao modo de usuário a recursos de baixo nível privilegiados podem causar um bugcheck (por exemplo, rabiscando Device\PhysicalMemory, se não corromper seu disco rígido primeiro; O Vista não permite acesso ao modo de usuário à memória física).

Se você deseja apenas um arquivo de despejo, a sugestão de Mendelt de usar o WindBG é uma idéia muito melhor do que explorar um bug em um driver de kernel. Infelizmente, o .dump O comando não é suportado para a depuração local do kernel, portanto, você precisaria de um segundo PC conectado sobre série ou 1394, ou uma VM conectada sobre uma porta serial virtual. LiveKD Pode ser uma opção de PC único, se você não precisar do estado da memória para ser completamente autoconsistente.

Answer 9

Este não precisa de nenhum drivers no modo de kernel, apenas um sedebugprivilege. Você pode definir seu processo crítico por NtSetInformationProcess, ou RtlSetProcessIsCritical e apenas mate seu processo. Você verá o mesmo código de bugcheck que mata o CSRSs.exe, porque define o mesmo sinalizador "crítico" em seu processo.

Answer 10

Infelizmente, sei como fazer isso como um serviço .NET em nosso servidor estava causando uma tela azul. (Nota: Windows Server 2008 R2, não XP/Vista).

Eu mal podia acreditar que um programa .NET era o culpado, mas era. Além disso, acabei de replicar o BSOD em uma máquina virtual.

O código ofensivo causa um 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;
}

Se alguém está se perguntando por que eu gostaria de replicar a tela azul, não é nada malicioso. Eu modifiquei nossa aula de log para fazer uma discussão dizendo para Escreva direto para o disco Como as ações anteriores ao BSOD não estavam aparecendo no log, apesar de .flush () ser chamado. Eu repliquei o travamento do servidor para testar a alteração do log. A VM travou devidamente, mas o madeireiro funcionou.

Edit: Killing csrss.exe parece ser o que causa a tela azul. Conforme comentários, isso provavelmente está acontecendo no código do kernel.