Richiama Blue Screen of Death usando Managed Code

Question

Solo curioso qui: è possibile invocare una schermata blu della morte di Windows usando il codice gestito .net sotto Windows XP / Vista? E se è possibile, quale potrebbe essere il codice di esempio?

Solo per la cronaca, questo non è per scopi dannosi, mi chiedo solo quale tipo di codice sarebbe necessario per uccidere effettivamente il sistema operativo come specificato.

Answer 1

La cosa della tastiera è probabilmente una buona opzione, ma se devi farlo con il codice, continua a leggere ...

Non hai davvero bisogno di nulla per barf, di per sé, tutto ciò che devi fare è trovare la funzione KeBugCheck (Ex) e invocarla.

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

Per arresti anomali avviati manualmente, si desidera utilizzare 0xE2 (MANUALLY_INITIATED_CRASH) o 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) come codice di controllo dei bug. Sono esplicitamente riservati per quell'uso.

Tuttavia, trovare la funzione potrebbe rivelarsi un po 'complicato. Il DDK di Windows può aiutare (controllare Ntddk.h) - Al momento non lo ho disponibile e al momento non riesco a trovare informazioni decisive - penso è in ntoskrnl.exe o ntkrnlpa.exe, ma non ne sono sicuro, e al momento non ho gli strumenti per verificarlo.

Potresti trovare più semplice scrivere una semplice app C ++ o qualcosa che chiama la funzione e quindi eseguirla.

Intendiamoci, sto assumendo che Windows non ti impedisca di accedere alla funzione dallo spazio utente (.NET potrebbe avere alcune disposizioni speciali). Non l'ho provato da solo.

Answer 2

Non so se funziona davvero e sono sicuro che hai bisogno dei diritti di amministratore, ma potresti impostare la chiave di registro CrashOnCtrlScroll e quindi utilizzare un SendKeys per inviare CTRL + Blocco scorrimento + Blocco scorrimento.

Ma credo che questo debba provenire dal driver della tastiera, quindi immagino che un semplice SendKeys non sia abbastanza buono e che sia necessario agganciarsi in qualche modo al driver della tastiera (sembra davvero disordinato) o verificare che CrashDump abbia un API che può essere chiamata con P / Invoke.

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

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters
Nome: CrashOnCtrlScroll
Tipo di dati: REG_DWORD
Valore: 1
Riavvia

Answer 3

Dovrei dire di no. Dovresti p / invocare e interagire con un driver o altro codice che vive nello spazio del kernel. Il codice .NET vive molto lontano da quest'area, sebbene si sia parlato di driver gestiti nelle future versioni di Windows. Aspetta ancora qualche anno e puoi schiantarti come i nostri amici non gestiti.

Answer 4

Per quanto ne so, un vero BSOD richiede un errore nel codice in modalità kernel. Vista ha ancora BSOD ma sono meno frequenti perché il nuovo modello di driver ha meno driver in modalità kernel. Eventuali errori nella modalità utente comporteranno solo la chiusura dell'applicazione.

Non è possibile eseguire il codice gestito in modalità kernel. Quindi, se si desidera BSOD, è necessario utilizzare PInvoke. Ma anche questo è abbastanza difficile. Devi fare dei PInvokes davvero fantasiosi per ottenere qualcosa in modalità kernel da sfuggire.

Ma tra le migliaia di utenti SO c'è probabilmente qualcuno che ha fatto questo :-)

Answer 5

È possibile utilizzare lo strumento OSR Online che attiva un arresto anomalo del kernel. Non l'ho mai provato da solo, ma immagino che potresti semplicemente eseguirlo tramite la classe di processo standard .net:

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

Answer 6

Una volta sono riuscito a generare un BSOD su Windows XP usando System.Net.Sockets in .NET 1.1 irresponsabilmente. Potrei ripeterlo abbastanza regolarmente, ma sfortunatamente è stato un paio d'anni fa e non ricordo esattamente come l'ho attivato o non ho più il codice sorgente in giro.

Answer 7

Prova a inserire video in diretta usando directshow in directx8 o directx9, la maggior parte delle chiamate va ai driver video in modalità kernel. Sono riuscito in molte schermate blu durante l'esecuzione di una procedura di richiamata da una sorgente di videocapture dal vivo, in particolare se il callback richiede molto tempo, è possibile arrestare l'intero driver del kernel.

Answer 8

È possibile che il codice gestito causi un controllo errori quando ha accesso a driver del kernel difettosi. Tuttavia, sarebbe il driver del kernel che causa direttamente il BSOD (ad esempio, i BSOD DirectShow di uffe, i BSOD socket di Terence Lewis o i BSOD visti quando si utilizza BitTorrent con alcune schede di rete).

L'accesso diretto in modalità utente a risorse privilegiate di basso livello può causare un controllo errori (ad esempio, scarabocchiare su Device \ PhysicalMemory , se non danneggia prima il disco rigido; Vista non consentire l'accesso in modalità utente alla memoria fisica).

Se vuoi solo un file di dump, il suggerimento di Mendelt di usare WinDbg è un'idea molto migliore rispetto allo sfruttamento di un bug in un driver del kernel. Sfortunatamente, il comando .dump non è supportato per il debug del kernel locale, quindi avresti bisogno di un secondo PC collegato tramite seriale o 1394 o di una VM connessa tramite una porta seriale virtuale. LiveKd potrebbe essere un'opzione per PC singolo, se non lo fai è necessario che lo stato del dump della memoria sia completamente auto-coerente.

Answer 9

Questo non ha bisogno di alcun driver in modalità kernel, solo un SeDebugPrivilege. Puoi impostare il tuo processo come critico NtSetInformationProcess o RtlSetProcessIsCritical e uccidi il tuo processo. Vedrai lo stesso codice di controllo bug che uccidi csrss.exe, perché hai impostato lo stesso "quot" critico " bandiera sul tuo processo.

Answer 10

Sfortunatamente, so come farlo poiché un servizio .NET sul nostro server stava causando una schermata blu. (Nota: Windows Server 2008 R2, non XP / Vista).

Non riuscivo a credere che il colpevole fosse un programma .NET, ma lo era. Inoltre, ho appena replicato BSOD in una macchina virtuale.

Il codice offensivo, causa 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 qualcuno si sta chiedendo perché vorrei replicare la schermata blu, non è nulla di malevolo. Ho modificato la nostra classe di registrazione per prendere un argomento dicendo a scrivere direttamente sul disco poiché le azioni precedenti a BSOD non apparivano nel registro nonostante fosse stato chiamato .Flush (). Ho replicato l'arresto anomalo del server per testare la modifica della registrazione. Il computer virtuale si è arrestato in modo anomalo ma la registrazione ha funzionato.

EDIT: uccidere csrss.exe sembra essere ciò che provoca la schermata blu. Come da commenti, ciò sta probabilmente accadendo nel codice del kernel.