WindowsおよびUnixシステムにおけるメモリダンプとカーネル解析

インフォマテックデジタル » Recursos » WindowsおよびUnixシステムにおけるメモリダンプとカーネル解析

オペレーティングシステムがパニック状態になったりクラッシュしたりした場合、何が起こったのかを理解する唯一の方法は、カーネルメモリダンプを取得して分析することです。これらのダンプは、障害発生時のシステムの内部状態を捉えており、複雑なエラーのデバッグ、セキュリティインシデントの調査、またはフォレンジック調査を行う上で不可欠です。

一見すると非常に「低レベル」な作業のように思えるかもしれませんが、メモリダンプ解析はカーネル開発者だけのものではありません。システム管理者、サポートエンジニア、さらにはセキュリティ監査担当者でさえ、適切なツール、さまざまな種類のダンプ、そして基本的な解釈手法を知っていれば、その恩恵を受けることができます。この記事では、WinDbg、crash、kgdb、LiMEといったツールを用いて、Windows、Unix/Linux、BSD環境でのこれらの手順を詳しく解説します。

カーネルメモリダンプとは何ですか？また、なぜ分析する価値があるのでしょうか？

カーネルメモリダンプ（カーネルクラッシュダンプ、または単にクラッシュダンプとも呼ばれる）とは、Unix/Linux のカーネルパニックや Windows のブルースクリーン (BSOD)など、システムが重大な障害に見舞われた時点のメモリのコピー（完全コピーまたは部分コピー）を含むファイルです。

実際には、この種のダンプには、カーネルの内部構造、コールスタック、プロセスコンテキスト、ロードされたドライバなどが保存されます。そのため、障害発生後には、稼働中のシステムをデバッグするのと非常によく似た事後分析を行うことができますが、障害が発生している本番環境のマシンを操作するプレッシャーはありません。

カーネルダンプを詳細に調査する理由は様々です。一見ランダムに見えるバグや断続的なクラッシュのデバッグから、システムが悪意を持って操作されたかどうか、あるいはクラッシュによって機密情報がディスク上に残されたかどうかを調査することまで多岐にわたります。

完全なコアダンプに加えて、個々のプロセスのダンプ（従来のコアダンプ）を取得することも可能です。これは、問題を特定のアプリケーションに限定したり、電子メールやメッセージングクライアントなどのサービスの機密性への影響を確認したりする場合などに非常に役立ちます。

Windowsにおけるメモリダンプの種類とその有用性

Windowsシステムでは、STOPエラーが発生すると、オペレーティングシステム自体がさまざまな種類のダンプを生成することがあります。それぞれのダンプには異なるレベルの詳細情報が含まれているため、問題の種類やディスク容量の制限に応じて、どのタイプのダンプが必要かを把握しておくことが重要です。

ユーザー環境や多くのサーバーで最も一般的なフォーマットの1つは、 小さなメモリダンプ（ミニダンプ）これは最もスペースを消費しないもので、通常は %SystemRoot%\Minidumpスタイルのファイルを含む MiniMMDDYY-01.dmp.

このミニダンプには、非常に具体的で重要な情報が含まれています。具体的には、 STOPエラーコードとそのパラメータ、障害発生時にロードされたドライバのリスト、停止したプロセッサのコンテキスト（PRCB）、関連するプロセスとスレッドのコンテキスト（EPROCESSおよびETHREAD構造体）、およびそのスレッドのカーネルモードコールスタックです。

これらの基本的な構造のおかげで、ミニダンプでも、クラッシュの原因となっているドライバやモジュールを特定できる場合が多いのですが、問題がクラッシュ時に実行されていたスレッドから遠く離れた場所で発生し、利用可能なコンテキスト情報が限られている場合は、必ずしも全過程を追跡できるとは限りません。

Windowsは、カーネルメモリダンプや、物理メモリの一部または全部を含むより大規模なフルダンプを生成することもできます。これらは、低レベルの分析、フォレンジック調査、ドライバやシステム自体の高度なデバッグに特に役立ちます。

WindowsでWinDbgとKDを使用してメモリダンプを設定および開く

Windowsでシステムダンプを活用するには、まず起動オプションと回復オプションを適切に設定する必要があります。コントロールパネルのシステムの詳細設定で、障害発生時に生成するダンプの種類（例えば「小メモリダンプ（256KB）」）と保存先パスを指定できます。

システムは、ダンプを書き込むために、ブートボリューム上に少なくとも数メガバイトのページングファイルを必要とします。最新バージョンのWindowsでは、クラッシュが発生するたびに新しいファイルが作成され、設定されたフォルダに履歴が保持されるため、過去のインシデントを簡単に確認できます。

生成されたダンプファイルが正しいことを検証する方法はいくつかあります。代表的なユーティリティとしてDumpchk.exeがあり、これを使用するとファイルの基本的な整合性をチェックし、概要情報を出力できます。より高度な分析には、 WinDbg（グラフィカルインターフェース）やKD（コマンドライン版）などのWindowsデバッグツールが使用されます。

Microsoft Web サイトからデバッグ パッケージをインストールすると、ツールは通常、C:\Program Files\Debugging Tools for Windowsなどのフォルダーに格納されます。そこからコマンド プロンプトを開き、WinDbg または KD を使用してダンプ ファイルを読み込み、 -z パラメーターでファイルを指定します。

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

シンボルパスは、ローカルキャッシュを備えたシンボルサーバーを指すことができます。例：

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

バイナリパスは通常次のようなものです。 C:\Windows\I386 または、ダンプを生成したバージョンに対応するシステム実行ファイルをコピーしたフォルダ。これは、 ミニダンプにはすべてのバイナリは含まれていません参照のみが存在するため、デバッガーはそれらを見つけることができなければなりません。

Windowsにおけるカーネルクラッシュダンプの基本的な分析

WinDbgまたはKDを使用してダンプをロードしたら、カーネルクラッシュダンプの分析は、事後デバッグセッションと非常によく似ています。ほとんどの人が最初に実行するコマンドは`!analyze`で、これは自動分析を開始し、初期レポートを生成します。

コマンド !analyze -show を示しています バグチェックコードとそのパラメータつつ !analyze -v より詳細な出力が生成されます。疑わしいモジュール、コールスタック、コンテキスト情報、そして多くの場合、考えられる原因や診断手順に関する提案が含まれます。

その分析を補完するために、.bugcheckコマンドはエラー コードと関連するパラメーターを再度出力します。これをMicrosoft のバグチェック コード リファレンスと比較することで、各値の正確な意味と典型的な原因を特定できます。

コマンド lm N T (リストモジュール) を使用すると、 ロードされたモジュールの一覧（パス、アドレス、ステータスを含む）これは、自動分析によって特定されたドライバが実際にメモリ上に存在するかどうか、またそのバージョンを確認するのに役立ちます。このリストは、カーネルと連携するサードパーティ製ドライバやセキュリティコンポーネントが疑われる場合に特に有用です。

必要に応じて、ダンプファイルのパスを受け取り、適切なパラメータを指定してKDまたはWinDbgを起動するバッチファイルを作成することで、ダンプファイルの読み込みを簡素化できます。こうすることで、ファイルパスのみを含む短いコマンドを記述するだけで済み、スクリプトが残りの処理をすべて行ってくれます。

WinDbgを使用して詳細なカーネルダンプを取得する

カーネルモードのメモリダンプの場合、WinDbg は複数のファイルとセッションを扱う機能も提供します。ダンプは、コマンドラインから-zオプションを使用して開くか、グラフィカルインターフェイスから [ファイル] > [メモリダンプを開く] メニューまたはキーボードショートカットCtrl+Dを使用して開くことができます。

WinDbgが既にパッシブモードで起動している場合は、「クラッシュダンプを開く」ダイアログボックスでパスを指定するかディスクを参照してファイルを選択するだけです。読み込みが完了したら、特定の状況では「g」（Go）コマンドでセッションを開始したり、初期分析コマンドを直接実行したりできます。

クラシックに加えて !analyzeよく知っておくことをお勧めします デバッガコマンドリファレンスセクションここでは、内部構造の読み取り、メモリの検査、スタックの解釈など、利用可能なすべてのコマンドについて説明します。これらの手法の多くは、ライブセッションとオフラインダンプの両方に適用できます。

WinDbg では、 複数の並列ダンプコマンドラインに複数の -z パラメータを追加できます。それぞれのパラメータの後に異なるファイル名が続きます。または、コマンドを使用して新しいターゲットを追加できます。 .opendump複数の宛先をデバッグすることは、繰り返し発生する障害や連鎖的に発生する事象を比較するのに役立ちます。

一部の環境では、メモリダンプは容量を節約したり転送を容易にするために CAB ファイルにパッケージ化されます。WinDbg は直接 CAB ファイルを開くことができます。 .cab -z を使用した場合と、 .opendump彼は読むだろうが ダンプされたファイルのうち1つだけが抽出され、他のファイルは抽出されません。 それらは同じパッケージに同梱できる。

UnixおよびLinuxにおけるクラッシュダンプ：ユーティリティ、ツール、および要件

UnixシステムとGNU/Linuxシステムでは、基本的な考え方は似ていますが、ツール群のエコシステムは大きく異なります。ほとんどのUnix系カーネルは、致命的なエラーが発生した際にメモリのコピーを保存する機能を備えており、これはコアダンプまたはカーネルクラッシュダンプと呼ばれています。

これらのダンプの主な用途はカーネルお​​よびドライバの開発であるが、セキュリティ面においても重要な意味を持つ。クラッシュはプログラミングエラーだけでなく、悪意のある行為の失敗、システムコンポーネントの操作試行、あるいは不器用に悪用された競合状態によっても引き起こされる可能性がある。

適切に設定されたUnixシステムでは、日常的なクラッシュはまれですが、万が一発生した場合は、Kdump、LKCD、またはシステムメモリをキャプチャできるその他のソリューションなど、ダンプインフラストラクチャを整備しておくことをお勧めします。ただし、ダンプの診断価値と、そこに機密性の高いデータが含まれるリスクの両方を慎重に検討することが重要です。

Linuxにおけるこの種の分析に最も包括的で広く使用されているツールの1つが、Red Hatが開発したcrashです。このユーティリティは、カーネルダンプの調査や実行中のシステムの分析において、事実上の標準となっています。

クラッシュは、システムのライブメモリに対して、 /dev/mem または、Red Hat および派生ディストリビューションでは、特定のデバイスを使用します /dev/crashそれでも、次のようなメカニズムによって生成されたダンプファイルをツールに与えるのが一般的です。 Kdump, メイクダンプファイル, ディスクダンプ またはアーキテクチャ固有のダンプなど s390/s390x または xendump 仮想化環境で。

Linuxにおけるcrashの役割とvmlinuxの重要性

クラッシュユーティリティは、部分的には、使用上の制限を克服するために作成されました。 gdb を直接 /proc/kcoreとりわけ、そのメモリ擬似イメージへのアクセスが制限される場合があり、さらに、特定のカーネルコンパイルオプションによっては、圧縮された実行可能バイナリしかない場合、内部構造を適切に解釈することが困難になる場合があります。

crashツールが正しく動作するためには、2つの重要な要素が必要です。1つはデバッグシンボルを含むコンパイル済みのvmlinuxファイル（通常は-gなどのフラグを使用）、もう1つはカーネルダンプそのものです。この組み合わせにより、ツールはメモリアドレスを関数、構造体、およびコード行にマッピングすることができます。

区別することが重要です vmlinuxとvmlinuzほとんどのシステムでは、vmlinux のみが表示されます。これはカーネルの圧縮されたブート可能なバージョンです。クラッシュにはシンボル的に解凍された vmlinux が必要です。これがないと、ダンプをロードしようとしたり、 /dev/mem 次のようなエラーが発生します 起動したカーネルが見つかりません。名前リスト引数を入力してください。.

vmlinuzを手動で抽出することも可能ですが、その手順は必ずしも簡単ではなく、実際にはカーネルを再コンパイルしてvmlinuxとvmlinuzの両方を同時に取得する方がはるかに便利な場合が多いです。本格的な管理環境では、このような状況に備えて、展開するカーネルバージョンごとに個別のvmlinuzパッケージを用意しておくのが良いでしょう。

要件を満たせば、ダンプファイルに対してcrashを実行するのは比較的簡単です。適切なvmlinuxとダンプファイルを指定するだけで、ツールは対話型セッションを開き、そこからカーネル構造の探索、プロセスの一覧表示、コールスタックの表示、フォレンジック情報の抽出を行うことができます。さらに深く掘り下げたい場合は、有名なcrashの技術ホワイトペーパーなどの専門ドキュメントを参照してください。

Linuxにおける/dev/memの制限と最初のアプローチ

特定のツールに頼る前に、多くの管理者はこれまでメモリダンプの取得を試みてきた。 デバイスから直接読み取る /dev/memこのアプローチは単純に思えた。次のようなツールを使用する。 メモリダンプ （そのデバイスを標準出力にダンプします）または以下から取得します dd if=/dev/mem of=volcado.mem.

しかし、最新のカーネルは次のようなコンパイルオプションを提供しています。 CONFIG_STRICT_DEVMEMユーザー空間からアクセスを厳しく制限する /dev/mem典型的な結果として、小さなブロック (例えば 1 MB) の後に読み取りが中断されるか、最悪の場合、その相互作用のバグにより、 カーネルパニック 直ちに機械を再起動してください。

この保護措置はセキュリティの観点からは理にかなっているが、以前ほど入手しやすくなくなった汎用デバイスに完全に依存することなく、信頼性が高く完全なダンプを取得するための他の方法を探さざるを得なくなる。

したがって、現在の傾向としては、最新のカーネル保護ポリシーとの共存を想定して設計されていないユーザー空間ツールを使って単に「メモリをスクレイピング」しようとするのではなく、特定のモジュールや統合されたクラッシュダンプインフラストラクチャに頼る方向になっている。

LiME Forensics: LinuxおよびAndroidにおけるメモリ抽出

フォレンジック分野で非常に強力な代替手段となるのが、LiME（Linux Memory Extractor）です。これは、/dev/mem に適用される制限なしに、制御された方法で揮発性メモリをキャプチャするために設計されたカーネルモジュールです。LiME はカーネル空間で動作するため、RAM に非常に直接的にアクセスできます。

LiMEはソースコードと共に配布され、 カーネルヘッダーが使用されていますコンパイルプロセスはモジュールを生成します .ko ロードされるカーネルバージョンに固有です。コンパイル後、次のようなツールで検証できます。 file 当社のアーキテクチャに対応するELFモジュールが正しく生成されていることを確認するため。

LiMEを使用するには、モジュールをロードするだけです。 insmod ルートから適切なオプションを渡します。たとえば、 TCPとRAW形式を使用したネットワークダンプの宛先:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

並行して、ダンプを受信するマシンでは、次のようなツールを使用して設定されたポートで待機します。 nc出力をファイルにリダイレクトする:

nc <IP_origen> 4444 > volcado.mem

RAM容量とネットワーク性能にもよりますが、数分後には、ソースシステムの物理メモリ容量と同サイズのファイルが生成されます。これは完全なRAMダンプであり、フォレンジックツールや文字列解析ツールなどのユーティリティを用いて分析することで、興味深い文字列を特定するための第一歩として活用できます。

プロセスダンプとデータ漏洩のリスク

カーネルダンプ全体は非常に多くの情報を提供しますが、特定のプロセスのみに関心がある場合は過剰になることもあります。そのような場合は、次の方法に頼るのが理にかなっています... 個々のプロセスダンプ 次のようなツールを使って gcore Unix/Linux環境において。

こうしたプロセスごとのダンプはサイズがはるかに小さく管理しやすく、メッセージングクライアント（Skypeなど）やメールクライアント（Thunderbirdなど）といった特定のアプリケーションに分析を集中させることができます。これらのアプリケーションでは、メモリ文字列を調べることで、平文のパスワード、セッショントークン、連絡先データなどを比較的簡単に見つけることができます。

開発の観点から見ると、これらのコアダンプは、プログラミングエラー、メモリリーク、またはサービス内の矛盾した状態を特定するのに役立ちます。しかし、セキュリティの観点から見ると、これらのダンプが定期的に生成され、システム自体または共有ネットワークリソース上の他のユーザーがアクセスできる場所に保存される場合に問題が発生します。

ユーザーがタスクをスケジュールした場合、 cron 攻撃者は、機密性の高いプロセスのダンプを定期的に取得し、グローバルに読み取り可能なディレクトリに残すことで、重要な情報が漏洩する大きな扉を開いています。多くの監査シナリオでは、これらのファイルを分析することで、攻撃者は情報を復元することができます。 認証情報、連絡先リスト、通信履歴、その他の個人データ 比較的少ない労力で。

したがって、Unix システムの本格的な監査においては、ダンプ (完全または部分) が生成されているかどうか、それらがどこに保存されているか、どのような権限が付与されているか、そして不正なユーザーがアクセスできる範囲にメモリのコピーを残すような自動化されたプロセスが存在するかどうかを確認するために、数分を費やすことをお勧めします。

kgdb を使用した FreeBSD のダンプの事後分析

BSDの世界、特にFreeBSDでは、事後分析のアプローチには以下が含まれます。 システムでクラッシュダンプを有効にし、デバッグシンボル付きでカーネルをコンパイルするこれはカーネル設定ディレクトリから制御されます。通常は /usr/src/sys/<arq>/conf.

対応する設定ファイルでは、次のような行を追加することでシンボル生成を有効にできます。

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

設定を変更した後、カーネルを再コンパイルする必要があります。一部のオブジェクトが再生成されます（例： trap.oビルド ファイルの変更により、カーネルが 問題のあるコードと同じだが、必要なデバッグ情報を追加した。旧サイズと新サイズを比較するには、以下のコマンドを使用することをお勧めします。 size バイナリに予期せぬ変更がないことを確認するため。

シンボルを含むカーネルがインストールされたら、公式ドキュメントに記載されているようにkgdbを使用してダンプを調べることができます。すべてのシンボルが完全であるとは限らず、一部の関数には行番号や引数情報が表示されない場合がありますが、ほとんどの場合、問題の特定に必要な詳細情報が得られます。

分析によってすべてのインシデントが解決されるという絶対的な保証はありませんが、実際には、この戦略は多くのシナリオで非常にうまく機能します。特に、クラッシュダンプとシステムへの最近の変更の適切なレビューを組み合わせると効果的です。

カーネルエラーの分析と文書化に関するベストプラクティス

オペレーティングシステムの種類に関わらず、カーネルダンプの解析では、メッセージ、エラーコード、および見慣れない記号を解釈するために、通常は技術文書、知識ベース、専門フォーラム、あるいはカーネルのソースコード自体を参照することになる。

Linuxでは、公式のソースコードツリー、組み込みのドキュメント、コミュニティのリソースを活用することが非常に役立ちます。多くのカーネルエラーメッセージは、発生元の正確なファイルまで遡って追跡できるため、特定のBUG()やWARN()がトリガーされた状況を理解するのに役立ちます。

Windowsでは、Microsoftのドキュメント、ナレッジベース（KB）、および技術フォーラムに、バグチェックコード、トラブルシューティングの推奨事項、既知のエラーパターンに関する詳細な説明が記載されています。これらの情報と!analyze -vコマンドのレポートを組み合わせることで、適切な対策プランを策定することが可能になります。

クラッシュダンプの真価は、そのすべての情報を、オペレーティングシステムと障害が発生した特定の環境に関する確かな理解と照らし合わせて初めて発揮されます。そうして初めて、永続的な解決策を開発することができ、何よりも、同じ問題が将来、より深刻な結果を招く形で再発するのを防ぐことができるのです。

カーネルメモリダンプ解析は、究極的には科学と職人技の融合です。適切なツール、事前の設定（シンボル、ダンプオプション、安全なストレージ）、そしてスタック、構造体、エラーコードの読み取りに関する豊富な経験が必要です。これらの技術を習得することで、複雑なインシデントのデバッグが可能になるだけでなく、管理対象システムのセキュリティと回復力を飛躍的に向上させることができます。