Create BSOD from user mode?

Question

I was getting bored with my XP box one day, so I decided to try some of the answers to this question to see if any of them would cause a BSOD.
They didn't, and they seemed like they would be the most likely to do that, so I was wondering if it is possible to trigger a BSOD from user-mode in C/C++, and if so, how?

Washable

You mean, other than by triggering bugs in kernel-mode code? – Tollbooth

A blue screen is the Windows kernel response to a bug in the kernel. So no, aside from exploiting bugs in the kernel, crashes in user mode are handled differently. – Elias

Millions of Windows users went before you, albeit unwittingly. But ably assisted by crappy C or C++ code. There isn't much left. Video drivers are your best shot by a large margin. – Lacker

Answer 1

It seriously difficult to make a BSOD from user mode unless the user mode program interacts with buggy drivers (may be a particular sequence of operations can reveal the bugs in particular driver) disturbs the driver stack. From user mode, the inputs are validated well before passing to the kernel mode to ensure the stability of the system. Most of the Microsoft API/Drivers have validated well to avoid security issues in the system; so does the driver manufactures.

The best way is to disturb the driver stack, but it's not user mode.

You can create BSOD with NotMyFault SystInternals utility. It fundamentally injects a driver and create the BSOD

http://download.sysinternals.com/Files/Notmyfault.zip

Contraception

+1 for mentioning MS API/Drivers input validation and for another OTS solution in case it was needed for testing. (gotta love sysinternals.) – Shalom

Please menton the NtRaiseHardError though – Strigil

Answer 2

It's just this:

#include <iostream>
#include <Windows.h>
#include <winternl.h>
using namespace std;
typedef NTSTATUS(NTAPI *pdef_NtRaiseHardError)(NTSTATUS ErrorStatus, ULONG NumberOfParameters, ULONG UnicodeStringParameterMask OPTIONAL, PULONG_PTR Parameters, ULONG ResponseOption, PULONG Response);
typedef NTSTATUS(NTAPI *pdef_RtlAdjustPrivilege)(ULONG Privilege, BOOLEAN Enable, BOOLEAN CurrentThread, PBOOLEAN Enabled);
int main()
{
    BOOLEAN bEnabled;
    ULONG uResp;
    LPVOID lpFuncAddress = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlAdjustPrivilege");
    LPVOID lpFuncAddress2 = GetProcAddress(GetModuleHandle("ntdll.dll"), "NtRaiseHardError");
    pdef_RtlAdjustPrivilege NtCall = (pdef_RtlAdjustPrivilege)lpFuncAddress;
    pdef_NtRaiseHardError NtCall2 = (pdef_NtRaiseHardError)lpFuncAddress2;
    NTSTATUS NtRet = NtCall(19, TRUE, FALSE, &bEnabled); 
    NtCall2(STATUS_FLOAT_MULTIPLE_FAULTS, 0, 0, 0, 6, &uResp); 
    return 0;
}

Josiejosler

If someone gets an error on line 12, change it to: LPVOID lpFuncAddress2 = GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtRaiseHardError"); – Denn

Lines 11-12: invalid conversion from 'FARPROC' {aka 'long long int (*)()'} to 'LPVOID' {aka 'void*'} – Tardigrade

Answer 3

There's the undocumented function NtRaiseHardError.

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Error/NtRaiseHardError.html

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Error/HARDERROR_RESPONSE_OPTION.html

If the fifth parameter is 6 (OptionShutdownSystem), you'll get a BSOD. This requires enabling the shutdown privilege.

Tartan

Answer 4

The approach other than bugs is resource exhaustion. An area you could investigate would be to consume all CPU on the machine (run as many threads as you have cores at a real time priority level), and consume a kernel resource and depend on the real-time priority to stop the kernel from cleaning up.

Not sure what a good resource would be though. Lots of outstanding async operations against a device that can't get CPU to clean up? You could at least experiment in that direction.

Clericals

If you can cause windows to bluescreen from user mode at all then that is a bug in a kernel mode component pure and simple. The kernel ought to be able to withstand resource exhaustion (for some definition of withstand) otherwise it is a potential DOS attack. Same applies to any other kernel - if you can stop the kernel from user mode it is a bug. – Vengeful

Yes and no. Privileged users are allowed to do things that could disrupt the kernel. Protecting against a DoS attack from an administrator account is different to protecting against a DoS attack from an unprivileged user. Something like starting many asynchronous I/O operations with fragmented OVERLAPPED structure allocation in order to consume the non-paged pool, and then have the kernel fail a page allocation at a critical point is a reasonable avenue for crashing the kernel. I would argue that this is not a kernel bug, but administration failure (and therefore from user mode). – Clericals

Check my answer. You CAN generate Blue Screen from user mode by getting SeShutdownPrivilege then, call NtRaiseHardError with Floating Point exception, for example. Not all exceptions will generate BSODs, but Floating Multiple Faults will. – Strigil

Answer 5

If the operating system has no bugs in it, then it should be impossible to BSOD a machine from user space. At worst, it should just crash the offending application.

However, nothing is perfect. There are bugs in every operating system and every operating system has had bugs which cause a BSOD (or an OOPS as Linux does, or however else a given OS chooses to report an irrecoverable error) that is exploitable from user space.

As far as specifics, it really depends on the nature of the bug. There is no generic answer beyond "yes, it's possible".

For more details, you should look more into OS design, and how paging, ring levels and other techniques can be used to separate processes from each other and kernel space.

Jug

an oops is not unrecoverable, a kernel panic is – Billibilliard

Answer 6

Well, BSODs are from unrecoverable errors that happen in kernel mode; there is no way to cause that to happen without triggering a kernel error somehow. In general, if you wanted to do it, you would have to find a flaw in a driver [edit: or as a commenter pointed out, a system call] and exploit that.

Or, you could do what this app does: http://www.nirsoft.net/utils/start_blue_screen.html . Just write your own driver to crash the system any way you want to. :)

The Wikipedia page had some interesting information so I include it for reference: http://en.wikipedia.org/wiki/Blue_Screen_of_Death .

Shalom

writing your own driver isn't exactly "from user-mode" ;-). – Jug

well to be fair the question was: "so I was wondering if it is possible to trigger a BSOD from user-mode in C/C++" not "is it possible to trigger a BSOD without calling a driver". :P – Shalom

in all seriousness, though, although the real answer is that you can't do it without exploiting some flaw or writing a driver that does it intentionally, i suppose the driver could be useful in some testing scenarios; e.g. you have an application that has to maintain consistency in a written file, and you need to make sure that the file doesn't get corrupted upon a BSOD. i'd hate to be the test engineer doing those tests though. :D – Shalom

well you forget about system calls, which don't necessarily need a "driver", they can be core kernel features... But beyond that, calling a routine in a driver which has a flaw and writing a driver designed to crash are two very different things. – Jug

well, good point about the syscalls, however it still would require finding an exploitable flaw. but i believe you are entirely incorrect in your next statement, at least as long as the "different" you are referring to is a technical difference. so, yes, they are different in the sense that, for instance, you wouldn't require administrative privileges to install a driver if you exploit an existing hole. but technically, there is no difference. you have simply written a driver that has one or more flaws intentionally built in. any BSOD caused by a driver is caused by a flaw in the driver. – Shalom

Answer 7

You can force a system crash with the keyboard. Your title talks about user mode, I am not sure whether this qualifies as user mode, yet it might be useful.

Padre

Answer 8

Two ways without using drivers:

1. Using the undocumented function NtRaiseHardError as someone pointed out
2. Setting a critical process with the undocumented function RtlSetProcessIsCritical then terminating it. Requires the SE_DEBUG_NAME privilege. http://www.codeproject.com/Articles/43405/Protecting-Your-Process-with-RtlSetProcessIsCriti

Vu

This works on process quit with CRITICAL_PROCESS_DIED. You can directly use NtRaiseHardError for messages and there was a hack once to even print custom text (no longer works in Windows 10) – Strigil

Answer 9

I found at this link a code that generates a bsod : https://www.mpgh.net/forum/showthread.php?t=1100477

And here's the code (I tried it and it works, you just need to call the BlueScreen() function)

#include <windows.h>
#pragma comment(lib, "ntdll.lib")

extern "C" NTSTATUS NTAPI RtlAdjustPrivilege(ULONG Privilege, BOOLEAN Enable, BOOLEAN CurrentThread, PBOOLEAN OldValue);
extern "C" NTSTATUS NTAPI NtRaiseHardError(LONG ErrorStatus, ULONG NumberOfParameters, ULONG UnicodeStringParameterMask,
    PULONG_PTR Parameters, ULONG ValidResponseOptions, PULONG Response);

    void BlueScreen()
    {
        BOOLEAN bl;
        ULONG Response;
        RtlAdjustPrivilege(19, TRUE, FALSE, &bl); // Enable SeShutdownPrivilege
        NtRaiseHardError(STATUS_ASSERTION_FAILURE, 0, 0, NULL, 6, &Response); // Shutdown
    }

Sink

Answer 10

Just open up Windows run and type C:\con\con

Averi

That was for Windows 9x, that has been fixed – Glaudia