Hoe forceer je een Bluescreen? (C# .net 2.0)

[Themperror]

Dusja zoals de titel al zegt.. hoe? Ik heb al gegoogled maar kan niks vinden wat direct ervoor kan zorgen

kzag bijvoorbeeld een post over een process op critical te zetten en dan die afsluiten

of csrss.exe af te sluiten (wat niet lukt btw)

dus dingetjes zoals

Process.GetProcessesByName("csrss")[0].Kill(); werkt niet
(krijg argument exception process has already exited)

nor lukte het current process op critical zetten en dan die afsluiten (geen bluescreen, process sloot gewoon af)

is dit nergens aan te roepen in een of andere library die verder in het systeem zit?
like forceer bugcheck(0)?

[jimmy87]

Hele stomme vraag dan misschien, maar waarom zou je dat willen forceren?

[azerty]

Misschien kun je je mosterd hier halen:

http://www.nirsoft.net/utils/start_blue_screen.html

[Themperror]

wsitedesign schreef op donderdag 11 april 2013 @ 23:45:
Misschien kun je je mosterd hier halen:

http://www.nirsoft.net/utils/start_blue_screen.html

nja kijk.. het moet dus echt via code en niet via externe applicaties / drivers (waar bluescreens meestal vandaan komen)

is het niet mogelijk om via code in de NTKernel te komen en daar iets kwa DoBluescreen(bccode) uit te voeren ofzo? (om het simpel te zeggen)?

[CoolGamer]

Die functie is er wel, maar die is beperkt tot drivers en drivers kan je niet schrijven in C#. Dus dat zal geen optie zijn.

[Xessive]

MSDN: KeBugCheckEx routine (Windows Drivers)

[Themperror]

Xessive schreef op donderdag 11 april 2013 @ 23:52:
MSDN: KeBugCheckEx routine (Windows Drivers)

daar kom in niet in met C#.. but thanks anyways voor je poging

[RobIII]

Niet per-se C# specifiek maar:
MSDN: Forcing a System Crash from the Keyboard (Windows Debuggers)

Geen idee of je dan met een SendKeys bijvoorbeeld de crash kunt forceren (maar ik acht de kans klein; ik verwacht dat er échte toetsaanslagen vereist zijn: hoogstwaarschijnlijk ook de reden waarom die specifieke registry key gebruikt wordt ).

Xessive schreef op donderdag 11 april 2013 @ 23:52:
MSDN: KeBugCheckEx routine (Windows Drivers)

Daar is geen usermode wrapper voor Vandaar 't bestaan van projecten als Nirsoft's StartBlueScreen

[ Voor 81% gewijzigd door RobIII op 12-04-2013 00:27 ]

[Compizfox]

Het lijkt me sterk dat dat kan, aangezien C# een redelijk hoge/abstracte programmeertaal is, omdat je natuurlijk .NET ertussen hebt zitten, die de meeste dingen afvangt en exceptions throwt.

Zo kun je ook niet je programma 'hard' laten crashen door bv. een null pointer dereference of een divide by zero waar dat bij bv. C of C++ wel kan.

Oh, en voor een BSOD moet je zelfs iets hebben wat in kernel space draait. Bij Windows betekent dat dus een driver. (zo werkt dat appje van Nirsoft ook IIRC)

[ Voor 19% gewijzigd door Compizfox op 12-04-2013 00:02 ]

[Themperror]

RobIII schreef op donderdag 11 april 2013 @ 23:54:
Niet per-se C# specifiek maar:
MSDN: Forcing a System Crash from the Keyboard (Windows Debuggers)

>You must restart the system for these settings to take effect.

dus tijdens runtime die register waarde toevoegen en daarna op ctrl drukken is ook geen optie..

[revertive]

MSDN: Unsafe Code and Pointers (C# Programming Guide)

[Themperror]

revertive schreef op donderdag 11 april 2013 @ 23:56:
MSDN: Unsafe Code and Pointers (C# Programming Guide)

Zou het dus kunnen met unsafe code? like zoals iemand hierboven al zei

null pointer of divide by zero?

ik denk niet dat dat een bluescreen veroorzaakt maar dus gewoon je programma crasht..

[RobIII]

Themperror schreef op donderdag 11 april 2013 @ 23:56:
[...]


>You must restart the system for these settings to take effect.

dus tijdens runtime die register waarde toevoegen en daarna op ctrl drukken is ook geen optie..

Nee, maar er lopen hier nogal wat zaken door elkaar denk ik.

Allereerst zou ik graag weten wat je precies probeert te bereiken en waarom. En waarom je denkt dat "zomaar" vanuit een Ring 3 applicatie voor elkaar te krijgen (let alone .Net). Daar zul je sowieso, expliciet, "support" voor moeten aanzetten. Dat gaat je niet lukken zonder de juiste rechten etc.

Een echte bluescreen kun je alleen forceren door op 0 - 2 zaken uit te spoken. Alle applicaties draaien in in ring 3 dus zelfs een nullpointer of deling door nul en andere fratsen zullen hooguit de applicatie onderuit halen.

Als het zo makkelijk was een bluescreen te forceren waren er heel wat "leuke appjes" in omloop die om de haverklap je PC onderuit haalden. Ik zie de mails al voor me:

Wat ik net toch vond: "KlikMij.exe" Hilarisch! Klik gauw 't attachment!

Dat gaat je alleen lukken met de daarvoor bedoelde functies (zie mijn eerdere suggestie) waarvoor je, logischerwijs, door wat "hoops" zult moeten om 't voor elkaar te krijgen of in de lagere ringen te komen (waarvoor je een driver zult moeten schrijven, die zult moeten (laten) signen etc. etc.).

[ Voor 37% gewijzigd door RobIII op 12-04-2013 00:04 ]

[Compizfox]

Themperror schreef op donderdag 11 april 2013 @ 23:57:
[...]


Zou het dus kunnen met unsafe code? like zoals iemand hierboven al zei

null pointer of divide by zero?

ik denk niet dat dat een bluescreen veroorzaakt maar dus gewoon je programma crasht..

Lees mijn post eens

Met een null pointer dereference of een divide by zero laat je in C# niet eens je app écht crashen. Je krijgt 'maar' een .NET-exception.

En een BSOD creëren vanuit een applicatie kan je sowieso vergeten, dat lukt alleen met een driver.

[Themperror]

RobIII schreef op donderdag 11 april 2013 @ 23:59:
[...]

Nee, maar er lopen hier nogal wat zaken door elkaar denk ik.

Allereerst zou ik graag weten wat je precies probeert te bereiken en waarom. En waarom je denkt dat "zomaar" vanuit een Ring 3 applicatie voor elkaar te krijgen (let alone .Net). Daar zul je sowieso, expliciet, "support" voor moeten aanzetten. Dat gaat je niet lukken zonder de juiste rechten etc.

okay.

Ik heb nog nooit eerder van de term ring 3 gehoord (en lees nu net die wikipedia page voor het eerst)

en waarom ik dit wil, Pure nieuwsgierigheid.

Ik kan wel though Dll's inladen en hooks maken, kan ik niet vanuit zon punt iets aanroepen dat enigsinds zoiets zou kunnen veroorzaken

(note wel, Kwa programming kan ik wel wat, maar ik ben nooit echt diep in het systeem gegaan en dit is dus vooral research)

[RobIII]

Themperror schreef op vrijdag 12 april 2013 @ 00:02:
Ik kan wel though Dll's inladen en hooks maken, kan ik niet vanuit zon punt iets aanroepen dat enigsinds zoiets zou kunnen veroorzaken

Nee. En als dat al kan mag je 't melden (en als jij 't niet doet doet 'n ander dat wel) bij MS want dan heb je een dik vet probleem gevonden en wordt 't probleem gedicht/gepatched en is je "BSOD applicatie" over 2 weken alsnog nutteloos. Ga eerst maar eens rustig lezen in 't artikel waarnaar ik verwees en hier Je zou een .Net applicatie door de .Net runtime zelfs als "Ring 4" kunnen beschouwen door de onderliggende CLR waarin je "sandboxed" bent in je eigen ring/'laag' (waarin je, at best, ring 3 kunt 'bereiken').

Zie ook:
http://www.codinghorror.c...user-and-kernel-mode.html

[ Voor 31% gewijzigd door RobIII op 12-04-2013 00:11 ]

[Themperror]

Dus als ik het allemaal goed begrijp is het kortom.. Onmogelijk?

Indien dat zo is dan zeg ik hierbij,

Bedankt voor alle informatie, heb ik weer wat bijgeleerd.

[StM]

De enige mogelijkheid die ik kan bedenken is met een dummy driver die de feitelijke crash veroorzaakt

[RobIII]

StM schreef op vrijdag 12 april 2013 @ 00:10:
De enige mogelijkheid die ik kan bedenken is met een dummy driver die de feitelijke crash veroorzaakt

Precies wat wsitedesign in "Hoe forceer je een Bluescreen? (C# .net 2.0)" suggesteert

[Gomez12]

Onmogelijk is een groot woord, maar of je moet ver in de krochten van windows gaan pielen, of je moet met unmanaged code drivers "rare" dingen laten doen.

Zo hadden vroegere nvidia drivers code waarmee je bijv de safeguards uit kon zetten en als je dan die gpu hard genoeg liet werken (/warm genoeg liet worden) dan kon je na een tijdje een blue screen forceren.

Maar dan moet je dus zoeken of die code nog in de nvidia drivers zit en of je target een nvidia kaart heeft (met exact die drivers).

In principe met een net applicatie heb je :
- Eerst .net die het op moet vangen
- Dan windows die het op moet vangen
- En daarna pas de bsod code

[Compizfox]

Gomez12 schreef op vrijdag 12 april 2013 @ 00:17:
Zo hadden vroegere nvidia drivers code waarmee je bijv de safeguards uit kon zetten en als je dan die gpu hard genoeg liet werken (/warm genoeg liet worden) dan kon je na een tijdje een blue screen forceren.

Dan nog produceer je die BSOD in dat geval door een hardware failure, en laat je het systeem niet crashen door de code (wat TS wil leren, neem ik aan)
Daarnaast kun je zelfs hardwareschade veroorzaken als je daadwerkelijk safeguards in de GPU kunt uitzetten. Ik neem aan dat die bug er wel een keer uit is gehaald, btw

[StM]

RobIII schreef op vrijdag 12 april 2013 @ 00:11:
[...]

Precies wat wsitedesign in "Hoe forceer je een Bluescreen? (C# .net 2.0)" suggesteert

Oeps, link niet gechecked

Maar ik kan me haast niet voorstellen dat SendKeys in de keyboard en muis io driver zijn invoer inject, maar dit juist op een hoger niveau doet in een 1 of andere kernel buffer of input handler. En dan ben je al te ver om gebruik te kunnen maken van die debug optie.

Gomez12 schreef op vrijdag 12 april 2013 @ 00:17:
Onmogelijk is een groot woord, maar of je moet ver in de krochten van windows gaan pielen, of je moet met unmanaged code drivers "rare" dingen laten doen.

Zo hadden vroegere nvidia drivers code waarmee je bijv de safeguards uit kon zetten en als je dan die gpu hard genoeg liet werken (/warm genoeg liet worden) dan kon je na een tijdje een blue screen forceren.

Maar dan moet je dus zoeken of die code nog in de nvidia drivers zit en of je target een nvidia kaart heeft (met exact die drivers).

In principe met een net applicatie heb je :
- Eerst .net die het op moet vangen
- Dan windows die het op moet vangen
- En daarna pas de bsod code

Ik denk dat je dezelfde aanroepen ook wel moet kunnen doen dmv unsafe code in C# en mogelijk in combinatie met de misbruik van wat p/invoke calls, maar ik zou me sterk af gaan vragen of je dat wel moet willen

[RobIII]

StM schreef op vrijdag 12 april 2013 @ 00:23:
Maar ik kan me haast niet voorstellen dat SendKeys in de keyboard en muis io driver zijn invoer inject, maar dit juist op een hoger niveau doet in een 1 of andere kernel buffer of input handler. En dan ben je al te ver om gebruik te kunnen maken van die debug optie.

Hence mijn edit

Maar nu hebben we nog steeds niet gehoord wat de precieze reden is waarom TS dit überhaupt zou willen doen. Als 't "alleen maar voor research" is dan zou ik mijn research eens beginnen bij 't begin: de eerder aangehaalde artikelen over kernel rings e.d.

[ Voor 22% gewijzigd door RobIII op 12-04-2013 00:28 ]

[CyBeR]

Themperror schreef op donderdag 11 april 2013 @ 23:57:
[...]


Zou het dus kunnen met unsafe code? like zoals iemand hierboven al zei

null pointer of divide by zero?

ik denk niet dat dat een bluescreen veroorzaakt maar dus gewoon je programma crasht..

De enige manier in een modern OS is om een kernel-mode driver te schrijven (in C nagenoeg altijd) en daarin iets dergelijks te doen. (Hoewel je volgens mij in unix dan gewoon panic() aan kunt roepen.) Als je dit vanuit userspace weet te doen heb je een keiharde bug te pakken in de kernel of een driver want dat mag nooit kunnen.

[ Voor 5% gewijzigd door CyBeR op 12-04-2013 00:29 ]

[Xanland]

Wat ik vanochtend toevallig hoorde van mijn docent:

Bij het killen van het proces csrss.exe komt er automatisch een BSOD tevoorschijn. Dit proces is namelijk zeer belangrijk voor het functioneren van iets (ik dacht de GUI oid).

Meh, lezen is moeilijk. Excuus,

[ Voor 8% gewijzigd door Xanland op 12-04-2013 19:32 ]

[Compizfox]

Veel succes met het killen van csrss.exe

[Mavamaarten]

Het kan wel degelijk, ik heb een voorbeeldje in VB.Net (kan je makkelijk vertalen naar C#) dat gewoon een BSOD veroorzaakt. Hij maakt het huidige process critical, en beëindigt daarna zichzelf.

DM maar voor de source, k ben nu niet op mijn eigen PC, ik zal zodra ik op mijn eigen PC zit de source doorsturen dan.

[RobIII]

Zet gewoon die (relevante) source even online? Hier in 't topic als het even kan en anders op pastebin ofzo? Het zal nooit veel code zijn (en tbh geloof ik er weinig van).

[ Voor 22% gewijzigd door RobIII op 12-04-2013 21:36 ]

[Mavamaarten]

RobIII schreef op vrijdag 12 april 2013 @ 21:35:
Zet gewoon die (relevante) source even online? Hier in 't topic als het even kan en anders op pastebin ofzo? Het zal nooit veel code zijn (en tbh geloof ik er weinig van).

Ik was toen niet thuis en had dus geen toegang tot de source. Nu dus wel, maar het blijkt een VB6 project te zijn.
Dan nog, het gebruikt gewoon windows API's dus het zou gewoon moeten werken in C#.

Visual Basic .NET:

Private Declare Function RtlAdjustPrivilege Lib "NTDLL" (ByVal Privilege As Long, ByVal Enable As Boolean, ByVal Client As Boolean, WasEnabled As Long) As Long
Private Declare Function NtSetInformationProcess Lib "NTDLL.DLL" (ByVal hProcess As Integer, ByVal ProcessInformationClass As Integer, ByVal ProcessInformation As Long, ByVal ProcessInformationLength As Integer) As Integer
Private Declare Sub ExitProcess Lib "kernel32" (ByVal uExitCode As Long)

Public Function MakeCritical(Phandle As Long, Value As Boolean)
    Dim ProcessInfo As Long
    ProcessInfo = IIf(Value, 29&, 0&)
    Call RtlAdjustPrivilege(20, True, True, 0)
    Call NtSetInformationProcess(Phandle, 29, VarPtr(ProcessInfo), Len(ProcessInfo))
End Function

Public Sub Bsod()
    Call MakeCritical(-1, True)
    Call ExitProcess(0)
End Sub

[RobIII]

Daar moet je wel Administrator voor zijn, maar, inderdaad; dat levert wel een BSOD op.
Dit volstaat:

C#:

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

class Program
{
    [DllImport("ntdll")]
    static extern int NtSetInformationProcess(IntPtr p, int c, ref int i, int l);

    static void Main()
    {
        Process p = Process.GetCurrentProcess();
        int e = 1;
        NtSetInformationProcess(p.Handle, 29, ref e, 4);
        p.Kill();
    }
}

Waarom dit werkt (als in: waarom dit daadwerkelijk een BSOD oplevert) is me nog even een raadsel.

[Gomez12]

RobIII schreef op vrijdag 12 april 2013 @ 22:18:
Waarom dit werkt (als in: waarom dit daadwerkelijk een BSOD oplevert) is me nog even een raadsel.

Ik gok op legacy...

[RobIII]

Gomez12 schreef op vrijdag 12 april 2013 @ 22:20:
[...]

Ik gok op legacy...

Het is sowieso undocumented (en kan dus elk moment veranderen / "opgelost" worden, hoewel 't al sinds (zeker) 2005* "publiek geheim" is). En je moet nog steeds administrator zijn of SeDebugPrivilege hebben (althans: ik krijg op W8 alleen een BSOD als Admin).

* De eerste vermelding die ik zo snel vond, maar het kan er al goed sinds Win95 in zitten

[ Voor 13% gewijzigd door RobIII op 12-04-2013 22:31 ]

[Gomez12]

RobIII schreef op vrijdag 12 april 2013 @ 22:22:
[...]
* De eerste vermelding die ik zo snel vond, maar het kan er al goed sinds Win95 in zitten

Hmmm, Wikipedia: Visual Basic VB6 Mid 1998, was er toen al een andere versie als win95? (NT family even uitgezonderd)

[ Voor 4% gewijzigd door Gomez12 op 12-04-2013 22:35 ]

[RobIII]

Gomez12 schreef op vrijdag 12 april 2013 @ 22:35:
[...]

Hmmm, Wikipedia: Visual Basic VB6 Mid 1998, was er toen al een andere versie als win95?

Het gaat niet om VB flapdrol Het gaat om de NtSetInformationProcess die met de juiste parameters een BSOD geeft; de eerste hint daarnaar (die ik zo snel vond, heb niet lang gespeurd) vond ik omstreeks 2005. VB6 wordt tot op vandaag de dag nog gebruikt (*huivert*). De functie NtSetInformationThread bestaat iig pas sinds W2k.

[ Voor 22% gewijzigd door RobIII op 12-04-2013 22:55 ]

[Sebazzz]

Themperror schreef op donderdag 11 april 2013 @ 23:53:
[...]


daar kom in niet in met C#.. but thanks anyways voor je poging

P/Invoke is toch geen probleem?

[CoolGamer]

Die kan je alleen aanroepen vanuit een driver. Drivers kan je niet schrijven in C#, dus P/Invoke is ook geen optie.

[rrrandy]

Old skool: lezen van de floppy drive als er niks in zit