.Net 托管代码是否可能导致任意 BSOD?
It's possible from .Net managed code to cause an arbitrary BSOD?
我想知道是否可以从 .Net 托管代码,或者 p/invoking 所需的 NT dll,是否可以生成具有特定的 BSOD(蓝屏死机)错误检查代码原因。
我知道这可以通过调用 KeBugCheck or KeBugCheckEx 方法从内核模式驱动程序实现,但我认为无法从用户模式调用这些方法应用程序。
有人可以澄清我的事情,并为托管代码提供另一种方法(如果存在)吗?
您可以终止 csrss 进程,非常简单:
System.Diagnostics.Process.GetProcessesByName("csrss").Single().Kill();
即使这需要管理员权限
我不能肯定地说内核不提供一些从用户模式使用任意参数调用 KeBugCheck 的方法,即使只是针对高特权进程,但我非常希望 none 提供并且我当然同情任何想知道为什么你会想要这样的东西存在更不用说使用它的人。
当然,即使内核尚未公开它以供从用户模式调用,它也可以在内核模式下随时使用,即由驱动程序调用。然而,即使在那里,也强烈建议驱动程序不要在任何已发布的代码中使用它。尽管驱动程序可以公开用户模式接口,例如,通过 Device I/O Control,代表用户模式客户端调用 KeBugCheck,即使是非特权客户端,这样做对于驱动程序编写者来说是极其不负责任的(除了,也许,私人测试)。
至于 CSRSS,你们中的一些人可能想知道背景知识(并且可能已经知道)架构长期以来允许 CSRSS 不必是关键的(从某种意义上说,杀死它会杀死 Windows ) 而且它不一定是唯一的。有一个未记录的函数 RtlSetProcessIsCritical,像 CSRSS 这样的程序调用它来注册自己非常重要,以至于当内核看到它们退出时,内核应该引发两个特定的错误检查中的任何一个。
我有一些代码可以做到这一点
开始了:
你可能只需要 ntdll.dll 但我没有安装任何东西就使用它......
虽然错误检查代码似乎不是正常类型
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Runtime.InteropServices;
using System.IO;
namespace bsod
{
class Program
{
private static uint STATUS_ASSERTION_FAILURE = 0xC0000420;
// private static uint KMODE_EXEPTION_NOT_HANDLED=0x0000008E;
static void Main(string[] args) {
while (Console.ReadKey(true).Key == ConsoleKey.W)
{
crash();
}
}
static void crash()
{
bool previousValue=false;
// Console.WriteLine("Adjusting privileges");
RtlAdjustPrivilege(19, true, false, out previousValue);
// Console.WriteLine("Triggering BSOD");
uint oul = 0;
IntPtr sptr = Marshal.StringToHGlobalAnsi("");
NtRaiseHardError(STATUS_ASSERTION_FAILURE, 0, 0, IntPtr.Zero, 6, out oul);
}
[DllImport("ntdll.dll")]
private static extern uint RtlAdjustPrivilege(
int Privilege,
bool bEnablePrivilege,
bool IsThreadPrivilege,
out bool PreviousValue
);
[DllImport("ntdll.dll")]
private static extern uint NtRaiseHardError(
uint ErrorStatus,
uint NumberOfParameters,
uint UnicodeStringParameterMask,
IntPtr Parameters,
uint ValidResponseOption,
out uint Response
);
}
}
让我澄清一下,这可能非常危险,因为您离无限循环仅一步之遥,不断使您的计算机崩溃...
我想知道是否可以从 .Net 托管代码,或者 p/invoking 所需的 NT dll,是否可以生成具有特定的 BSOD(蓝屏死机)错误检查代码原因。
我知道这可以通过调用 KeBugCheck or KeBugCheckEx 方法从内核模式驱动程序实现,但我认为无法从用户模式调用这些方法应用程序。
有人可以澄清我的事情,并为托管代码提供另一种方法(如果存在)吗?
您可以终止 csrss 进程,非常简单:
System.Diagnostics.Process.GetProcessesByName("csrss").Single().Kill();
即使这需要管理员权限
我不能肯定地说内核不提供一些从用户模式使用任意参数调用 KeBugCheck 的方法,即使只是针对高特权进程,但我非常希望 none 提供并且我当然同情任何想知道为什么你会想要这样的东西存在更不用说使用它的人。
当然,即使内核尚未公开它以供从用户模式调用,它也可以在内核模式下随时使用,即由驱动程序调用。然而,即使在那里,也强烈建议驱动程序不要在任何已发布的代码中使用它。尽管驱动程序可以公开用户模式接口,例如,通过 Device I/O Control,代表用户模式客户端调用 KeBugCheck,即使是非特权客户端,这样做对于驱动程序编写者来说是极其不负责任的(除了,也许,私人测试)。
至于 CSRSS,你们中的一些人可能想知道背景知识(并且可能已经知道)架构长期以来允许 CSRSS 不必是关键的(从某种意义上说,杀死它会杀死 Windows ) 而且它不一定是唯一的。有一个未记录的函数 RtlSetProcessIsCritical,像 CSRSS 这样的程序调用它来注册自己非常重要,以至于当内核看到它们退出时,内核应该引发两个特定的错误检查中的任何一个。
我有一些代码可以做到这一点 开始了: 你可能只需要 ntdll.dll 但我没有安装任何东西就使用它...... 虽然错误检查代码似乎不是正常类型
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Runtime.InteropServices;
using System.IO;
namespace bsod
{
class Program
{
private static uint STATUS_ASSERTION_FAILURE = 0xC0000420;
// private static uint KMODE_EXEPTION_NOT_HANDLED=0x0000008E;
static void Main(string[] args) {
while (Console.ReadKey(true).Key == ConsoleKey.W)
{
crash();
}
}
static void crash()
{
bool previousValue=false;
// Console.WriteLine("Adjusting privileges");
RtlAdjustPrivilege(19, true, false, out previousValue);
// Console.WriteLine("Triggering BSOD");
uint oul = 0;
IntPtr sptr = Marshal.StringToHGlobalAnsi("");
NtRaiseHardError(STATUS_ASSERTION_FAILURE, 0, 0, IntPtr.Zero, 6, out oul);
}
[DllImport("ntdll.dll")]
private static extern uint RtlAdjustPrivilege(
int Privilege,
bool bEnablePrivilege,
bool IsThreadPrivilege,
out bool PreviousValue
);
[DllImport("ntdll.dll")]
private static extern uint NtRaiseHardError(
uint ErrorStatus,
uint NumberOfParameters,
uint UnicodeStringParameterMask,
IntPtr Parameters,
uint ValidResponseOption,
out uint Response
);
}
}
让我澄清一下,这可能非常危险,因为您离无限循环仅一步之遥,不断使您的计算机崩溃...