【Windowsカーネル解析】NtQuerySystemInformationの裏に潜むKeBugCheckExの真実
title: "【Windowsカーネル解析】NtQuerySystemInformationの裏に潜むKeBugCheckExの真実"
type: "article"
topics: ["逆アセンブル", "Ghidra", "Windowsカーネル", "ブルースクリーン", "低レイヤー","ntoskrnl.exe"]
published: false
はじめに
Windowsの低レイヤーに興味を持つ者にとって、NtQuerySystemInformation は魅力的なAPIです。
プロセス情報、スレッド情報、ハンドル情報……。それらはこの1つのAPIから取得できる。
だが、今回の解析で自分は、このAPIの内部にとんでもないルートが存在していることを発見しました。
NtQuerySystemInformationの内部を追っていたら、KeBugCheckExにたどり着いた。
これは偶然の発見ではありません。Ghidraとバイナリエディタを使い、call や jz、ja、jnz、jmp の連鎖を一つずつ追った先に、
設計された“自衛本能”としてのブルースクリーン（0xF7: DRIVER_OVERRAN_STACK_BUFFER）が存在していたのです。
解析のきっかけ
そもそもなぜこのAPIを追ったのか。
きっかけは単純でした。
NtQuerySystemInformationの中身が気になった。
※ntdll.dll に定義されている NtQuerySystemInformation は、実質的にはシステムコールの入り口にすぎません。
実際の処理はすべて ntoskrnl.exe 側で行われており、今回解析したのもそのカーネル内部のロジックです。
どうやって情報を取得しているのか、どこで分岐し、どこで条件を評価しているのか。
その純粋な興味から、Ghidraを使って中身をトレースし始めました。
すると、驚くべき事実が見えてきたのです。
トレースの開始
使用ツール：Ghidra 対象：ntoskrnl.exe OSバージョン24H2 OSビルド26100.4349
以下は実際に追跡した逆アセンブルの流れを示したスクリーンショットです：
以下のような経路を確認：
NtQuerySystemInformation（複数のサブルーチン）
バッファサイズ検証関数
安全でない操作検出
KeBugCheckEx 呼び出し
このFUN_14069f330関数内で、指定バッファサイズよりも大きなコピーが検出された場合、
スタック保護機構が発動し、KeBugCheckExにより即時システムが停止します。
カーネ「ドライバのスタックベースのバッファオーバーランを検出、直ちにシステムを停止する」
※カーネは自分がカーネルを擬人化したキャラです【低レイヤーの彼女たち】02 – カーネ：仮想空間を統べる者、カーネル
これは「バグ」ではなく、「設計」です。
設計された“死”
KeBugCheckEx によるブルースクリーンは、Windowsが「自衛のために自らを止める」行為です。
特に 0xF7 のようなスタックバッファオーバーラン検出は、
悪意あるコードや不正操作からの防御を目的としています。
ちなみに、NtQuerySystemInformationを使用する場合は、このようなバッファ調整ループを書かなければなりません。
ULONG bufferSize = 0x10000;
std::unique_ptr<BYTE[]> buffer;
NTSTATUS status;
// バッファサイズ調整ループ
do {
buffer = std::make_unique<BYTE[]>(bufferSize);
status = NtQuerySystemInformation(SystemProcessInformation, buffer.get(), bufferSize, nullptr);
if (status == STATUS_INFO_LENGTH_MISMATCH) {
bufferSize *= 2;
}
} while (status == STATUS_INFO_LENGTH_MISMATCH);
if (!NT_SUCCESS(status)) {
std::wcerr << L"NtQuerySystemInformation failed. Status: 0x" << std::hex << status << std::endl;
return 1;
}
これは偶発的なものではなく、明確に“意図された終了”──つまり、「死に様の設計」です。
……なぜ、このように書かなければならないのか。もう、お分かりですよね？
考察と敬意
このルートを発見して強く感じたのは、
カーネルも、ただのプログラム。
だが、設計された“自衛本能”を持つプログラム。
ということでした。
そしてブルースクリーンは、その本能が“生きている証”。
バグチェックは設計だ。カーネルの死に様が、OSの信頼性を物語っている。
設計者に、感謝を込めて。
おわりに
このルートの発見は、知識だけでたどり着けるものではありません。
call、jnz、jmp……。
逆アセンブルされた世界を一歩ずつ、足で歩いた結果の発見でした。
※この記事は個人による逆アセンブル結果に基づいた解析記録であり、
Microsoft公式見解とは一切関係ありません。
Discussion