Tweet「Windowsメモリダンプ解析サービス」のご案内WinDbgとWindowsレジストリ解析(基礎)WindowsはSaaSとして提供される時代に入り、その内部は頻繁に更新されています。更新内容の多くは、いろいろな事情から、公にされることはほとんどありません。最新のユーザー空間とカーネル空間に関する信頼できる情報を取得するには、インターネットなどでは語られることのない高度な内部解析技術が必須とされています。Dump」内に保存されているWindowsレジストリ情報を本「IT談話館」の独自解析コードで解析します。1:42:54.949Windowsレジストリ情報は、オブジェクト名前空間にKeyオブジェクトとして記録されます。独自の解析コードを実行し、解析対象プロセスの「ハンドルテーブル」からオブジェクト名前空間へアクセスし、数あるオブジェクトの中からKeyオブジェクトを検出します。10ビルド環境で採取したメモリダンプを解析すると、次のようなレジストリ情報を取得することができます。解析コードの開発知識の習得には、「時間と予算の投資」が必要です。\REGISTRY\MACHINEKeyオブジェクトを検出した後は、WinDbg付属の「!reg」コマンドで次のように調査します。0xffffc70ebc83c238このコマンド操作では、上位概念から解析を開始する必要から、「kbody」と「kcb」という2つの引数を「!reg」コマンドに渡しています。上の実行結果を見ると、希望する情報が返されています。10ビルド環境で採取したメモリダンプ上で同じコマンド操作を行うと、次のようなエラーが返されてしまいます。0x7fこの例外発生の背景には、次のような内部変更の影響が推察されます。Uint8Bこの情報は、kdexts.regの開発担当者が必要とされるメモリ量が4バイトから8バイトに変更されたことをうっかり忘れていたことを示唆しています。10と一口に言ってもビルド番号が異なれば、このような細かな内部変更も発生しており、米Microsoft社内の上級エンジニアでさえも、(配属部署が異なれば)すべての変更内容を把握することは難しい、あるいは、部署間の連携にほころびが出てしまう、と推察されます。18362.1」メモリダンプに適応し、Keyオブジェクト自体の設計上の変更を確認してみることにしました。次のような結果が返されてきます。entriesLength->3ShrtKeyName->OLE[---]この情報には2箇所のデータが赤色で表示されています。MANAGER」のFullKeyName欄は「***」となっており、希望する文字列が返されていません。この背景に興味のある方は「WinDbgとWindowsレジストリ解析(応用)」を一読していただくとし、ここでは赤色の数値「122」のみを解析します。この数値はKeyBodyListを構成する要素数を示している思われます。本館はさらに、この数値は該当キーを参照しているプロセスオブジェクトの数をも示しているのではないか?と仮定し、なら、プロセス名を取得してみようと思い立ちました。そこで、新規に解析コードを開発し、次のような情報を取得してみました。Options」キーを参照しているプロセスを検出しました。他のキーも同じように解析することができます。使用した解析コードは「ハンドルテーブル」をはじめとする複数の概念の上に実装されています。10ビルド間でかなり安定してきています。レジストリ情報はメモリフォレンジックなどの作業では極めて重要な調査対象とされています。実務作業では「kbody」と「kcb」などの上位概念の解析から入り、その後、作業目的に応じて下位概念の解析に進むことになります。必要以上にレジストリ深層を解析する必要はありませんが、現在のソフトウェアの更新と提供状況を考えると、”そこはどういう意味だろう?”という疑問を解消する技術は独自に習得しておく必要があります。この姿勢を堅持していれば、たとえば、今回のようなWinDbgコマンドのエラー発生時に対処できる知識が自然と身に付きます。2020本日は2020-01-25です。