2025年8月15日 Leave a Comment

LLM をリバースエンジニアリングの助手として活用

2 min read

TALOS Japan

このリサーチでは、リバースエンジニアリングという複雑な分野において、大規模言語モデル（LLM）でマルウェアアナリストの作業を置き換えるのではなく、補完する方法を探ります。
LLM は、マルウェア分析において、ワークフローを合理化し、効率を高め、実用的なインサイトを提供する強力なアシスタントとして機能する可能性があります。
このブログでは、モデルコンテキストプロトコル（MCP）フレームワークなどの必須ツールや、IDA Pro、Ghidra などの業界標準の逆アセンブラおよび逆コンパイラと組み合わせた LLM の実用的な使い道を紹介します。
読了後は、マルウェア分析における一般的な課題に最適なモデルとツール、さらに、未知の悪意のあるファイルの識別と理解がこれらのツールによっていかに進むかについて、知見を得ることができます。
LLM 使用時に直面する一般的な課題、たとえばツールの利用によるコストの増加やローカルモデルの入力コンテキストサイズの制限などが結果に及ぼす影響についても説明します。

Talos が推奨するアプローチ

業界全体で LLM の導入が加速するにつれ、人間の専門知識が LLM に取って代わられてしまうのではないかという懸念が広がっています。しかし、LLM を人間の専門知識への脅威と見なすのではなく、マルウェア研究者の業務を支援する強力なツールとして捉えることもできます。

このリサーチでは、低コストのツールとハードウェアを用いる場合でも、マルウェア研究者はこのテクノロジーを活用して業務の改善を図れることを示します。

このブログでは、LLM および逆アセンブラとのやり取りに使用できるさまざまなクライアントアプリケーションの選択肢や、最適な言語モデルを選択する際に考慮すべき機能を紹介します。また、マルウェア分析セッションに役立てるために、これらのアプリケーションを強固なフレームワークに統合するプラグインについても説明します。

テストでは、IDA Pro との統合を実装した MCP サーバーと、VSCode をベースとする MCP クライアントで構成されるセットアップを使用することにしました。このスタックの MCP サーバーを使用して、ユーザー入力や悪意のあるコード内の情報に基づいて言語モデルがどのようにタスクを実行するかを示します。

このブログでは、ローカルモデルの LLM を GPU 上で実行するための基本セットアップを実現するために環境を構築する方法についても順を追って説明します。

MCP の概要

モデルコンテキストプロトコル（MCP）は、アプリケーションが LLM クライアントとモデルにコンテキストを提供する方法を標準化したオープンプロトコルです。MCP サーバーによって提供されるツールとデータソースがコンテキストを提供し、LLM モデルはユーザーの要求に応じて、または実行時に自律的に、アクセスするツールまたはデータソースを選択できる仕組みになっています。

MCP サーバーは、コードと、LLM に各ツールの使用方法を指示する説明文を使用してツールを実装します。コードは、API 統合へのアクセス、ファイルやネットワークへのアクセス、その他必要な自動化など、あらゆる種類のタスクを実装できます。

図 1. 一般的なセットアップにおける MCP サーバーと他のコンポーネントとの接続

これらのコンポーネントは、必要に応じて同一マシンまたは別々のマシンにインストールできます。たとえば、ローカル LLM モデルは高性能 GPU を搭載した別のサーバーで実行し、マルウェアの解析に使用する IDA Pro と MCP サーバーは、アクセス制限の厳しい別のマシンで実行するといった構成も可能です。

業務に適したツールの選択

ユーザーは MCP クライアントを通じて MCP サーバーとやり取りします。MCP クライアントは、LLM モデルにクエリを送信し、MCP サーバーとデータを交換し、そのデータをユーザーに表示するメインインターフェイスとして機能します。これらのクライアントは、Claude.AI Desktop や Visual Studio Code （VSCode）など、MCP プロトコルをサポートするどのアプリケーションでもよく、各マーケットプレイスで入手できる任意の MCP クライアント拡張機能を使用できます。

このブログでは、VSCode と Cline MCP クライアント拡張機能を使用する方法を説明していますが、現在入手可能な多くの拡張機能のどれでも使用することができます。最も人気のある拡張機能は次のとおりです。

Cline：https://cline.bot/
Roo Code：https://roocode.com/
Copilot MCP：https://marketplace.visualstudio.com/items?itemName=AutomataLabs.copilot-mcp

ローカル実装の場合は、推論エンジンの選択も重要です。オープンソースエンジンがいくつか存在し、それぞれパフォーマンスや使用の難易度が異なります。vLLM などの Python フレームワークもあれば、Python バインディングを備え、REST API 経由で接続可能なフル機能のサーバーに展開できる LLama.CPP や Ollama のような C++ エンジンもあります。本記事の範囲を超えるため詳述しませんが、それぞれ長所と短所があります。今回の実験では、主に使いやすさから Ollama を使用することにしました。

モデルの選定基準

次に選択が必要なコンポーネントは LLM です。クラウドベースのモデルとローカル実行モデルのどちらでも構いません。MCP クライアントの大半はクラウドベースのサービスを幅広くサポートしており、それらに対応した設定が事前に行われています。ローカル実行モデルの場合、Ollama 推論エンジンとそのサポート対象モデルを使用することが、最も互換性の高いソリューションの 1 つです。

MCP サーバーで使用するモデルを選択するときには、いくつかの機能を考慮する必要があります。これは、MCP クライアントがモデルおよび MCP サーバーとやり取りする方法に起因します。

まず、モデルは構造化された指示を含むプロンプトをサポートしている必要があります。これによりクライアントは、使用可能な MCP ツール、その用途、および使用方法に関するテンプレート構文をモデルに伝えることができます。

また、モデルは大規模な入力コンテキストウィンドウもサポートしている必要があります。これによりモデルは、大規模なコードベースを解析し、分析を続行できます。これは、クライアントが必要なすべての情報を同一のクエリでモデルに渡すために必要です。

MCP クライアントは、モデルにクエリを送信するとき、使用可能なツールとその使用方法について MCP サーバーから提供されたすべての情報、モデルに最適化された一般的な指示、そしてユーザーが入力したプロンプトを単一のプロンプトにまとめます。後続のクエリの場合は、関数の完全な逆コンパイルや文字列のリストなど、以前のコマンドの出力もプロンプトに追加されます。その結果、プロンプトはモデルまたは推論エンジンがサポートする最大の入力コンテキストの最大サイズにすぐに到達します。

クラウドベースのモデルの場合、これによって主に影響を受けるのは各リクエストの料金であるため、それほど問題にはなりません。一方、Ollama 推論エンジンを使用するローカルモデルの場合は、プロンプトが切り捨てられ、全コンテキストが欠落することで無効な応答が返される可能性があるため、問題がより大きくなります。

これらの制限により、ツールの使用や構造化された指示を処理するために特別にトレーニングされていないモデルは、MCP サーバーで使用するのに適していないことがあり、コード分析中にハルシネーションを引き起こす可能性があります。

今回の研究では推論エンジンとして Ollama を使用し、ローカル LLM オプションとして Devstral:24b を、クラウドベースモデルとして Antrophic の Claude 3.7 Sonnet （claude-3-7-sonnet-20250219）を採用しました。これらのモデルを選んだ理由は、ツールの使用とコード分析に特化しているためです。ハードウェアの制約、コスト効果、またはユーザーの好みに応じて、他のモデルを使用することも可能です。

ローカルモデルとクラウドベースモデルのどちらを使用するかを選択する際、考慮すべきその他のポイントは次のとおりです。

コスト：クラウドベースモデルでは、入力クエリとその応答で使用されるトークンの数に基づいて API アクセスの料金が請求される傾向があります。コンテキストを保持しながら、後続の質問を含む大きなファイルを分析すると、各プロンプトあたりのコストが急増する可能性があります。一方、ローカルモデルは処理が遅く、GPU を最大電力で使用する傾向があります。分析を続けるにはマシンを稼働し続ける必要があり、そのためにかかる隠れたエネルギーコストが増加します。また、ローカルモデルでは、モデルの実行に必要なハードウェアを取得するための初期費用がかかりますが、クラウドベースモデルではこのような費用は発生しません。
プライバシーと機密性：クラウドベースのサービスを使用する場合、前提として、分析対象ファイルに関するすべての情報がクラウド LLM プロバイダーに送信されます。分析対象ファイルの種類によっては、分析を依頼する雇用主や顧客が定める機密保持ルールに違反する可能性があります。
速度：LLM は、プロセッサとメモリを大量に消費するアプリケーションです。シングル GPU のローカルマシンで LLM を実行することは、機密性とコストの面ではメリットがあるかもしれませんが、同じ処理をクラウドベースのサービスで行うよりもはるかに時間がかかります。クラウドベースの LLM では数分で終わる分析が、ローカル LLM では数時間かかることもあります。この問題に加え、使用可能な GPU メモリをモデルとコンテキストが超過すると、LLM は GPU の代わりに（あるいは GPU に加えて）CPU を使用する可能性があります。その場合、処理速度がさらに低下します。

IDA Pro MCP サーバー

MCP サーバーは通常 2 つのコンポーネントで構成されます。第 1 のコンポーネントは逆アセンブラ内で実行されるプラグインであり、関数や変数の名前変更、関数の逆アセンブルや逆コンパイルの取得、プラグインによって実装されるその他のタスクなど、ユーザーが要求したアクションを実行します。これらの機能はリモートプロシージャコール（RPC）として実装され、MCP サーバー経由でクライアントに「ツール」として提供されます。

第 2 のコンポーネントは MCP サーバーであり、プラグインとやり取りし、MCP クライアントからの指示を待ちます。このサーバーは Server Sent Events（SSE）プロトコルを使用してクライアントと通信し、プラグインで設定されたツールを公開します。各 MCP サーバーは独自のツールセットを実装するため、ユーザーは自分のニーズに最適なツールを選択できます。以下に挙げたものは、IDA Pro または Ghidra で使用できる既存の MCP サーバーの一部です。

まとめると、今回のリサーチを行うにあたり、環境構築で使用したものは以下のとおりです。

ローカルモデル：Ollama と Devstral を使用
クラウドベースの LLM：Anthropic の Claude Sonnet 3.7 を使用
Duncan Ogilvie（Mrexodia）氏による MCP サーバー：IDA Pro にプラグインを設定済み
VSCode に Cline プラグインをインストールし、設定

分析に使用したセットアップは、AMD Ryzen 7 9800X3D（4.7GHz）、64GB DDR5 6000 RAM、3TB SSD、NVIDIA 5070 Ti 16GB GPU を搭載した、ミッドレンジからハイエンドのコンシューマ向けデスクトップマシンです。

LLM を使用した実際のサンプルの分析

先ほど定義したセットアップを用いて悪意のあるファイルを分析し、人間による分析結果と、ローカルおよびクラウドベースの LLM の結果を比較してみます。今回使用するのは IcedID の古いサンプルで、Hex-Rays の Lumina データベースを用いて徹底的にリバースエンジニアリングされ、文書化されています。これで、各 LLM の結果を比較する共通の土台が整いました。

分析結果が両モデルのトレーニングデータとして取り込まれ、結果に影響を与える可能性がありますが、ここでの目的は、両 LLM が互いに比べてどのように機能するかを比較することにあります。

7412945177641e9b9b27e601eeda32fda02eae10d0247035039b9174dcc01d12

使用したサンプルは小さく、定義されている関数は約 37 個です。結果を分析するときにはこの旨を考慮することが重要です。数百の関数を含むより大きいサンプルの場合、分析に与える影響は異なります。この点については後で説明します。

プロンプトの作成

モデルに対して適切なプロンプトを定義することが、LLM を効率的に利用するための最も重要なステップといえるでしょう。適切なプロンプトによってより良い分析結果が得られるだけでなく、クエリのコスト削減と処理時間の短縮につながり、ハルシネーションの可能性も減らすことができます。

この例では、Mrexodia が GitHub ページで提唱したプロンプトテンプレートを使用し、いくつか実験をした後で、さまざまな分析タイプをカバーできるように一部改良と変更を加えました。目的は、ローカル LLM とクラウドベースの LLM にまったく同じプロンプトを使用し、マルウェア分析でよく起こる次の 3 つの状況に対応することでした。

プログラムのエントリポイントからのトップダウン分析
特定の関数の処理内容と、アプリケーションによるその関数の使用方法の把握
すべての未知の関数を分析し、残りのコードを理解しやすいように関数名を変更

これらの例をカバーするために、3 つのプロンプト（図 2 ～ 4）を作成し、取り上げているすべてのケースで使用しました。

なお、これらのプロンプトは最適化されておらず、改善の余地があることは明白です。たとえばローカルモデルの場合、入力コンテキストを小さく保つには、実行するステップ数が少ない短いプロンプトの方がメリットがあります。一方クラウドベースモデルの場合は、必要なすべてのステップを簡潔な形で含むプロンプトの方が効果的です。そうすれば、複数の短いプロンプトとそれに関連する MCP 指示を送信する余分なコストを回避できます。しかし今回のケースでは、公正な比較を行うために、変更せずにすべてのケースで使用できる汎用性が 3 つのプロンプトすべてに求められました。

もう 1 つの重要な注意点は、悪意のあるファイルであることをプロンプト内で明言しないことです。明言すると、モデルがすべての関数に悪意があると仮定してしまい、分析にバイアスが生じるためです。

現在 IDA Pro で開かれている未知のファイルを分析してください。既存の MCP サーバー "ida-pro" を使用して IDA Pro インスタンスとやり取りし、このサーバーが提供するツールを使用して情報を取得できます。一般に、次の戦略を使用してください。

- コードの実際のエントリポイントである "StartAddress" という関数から始めます。

- この関数が他の関数を呼び出す場合は、呼び出しを追跡し、これらの関数も分析してコンテキストを理解します。

- 詳細が必要な場合は、関数を逆アセンブルまたは逆コンパイルし、発見した内容をコメントとして追加します。

- 逆コンパイルを検査し、発見した内容をコメントとしてコードの重要な部分に追加します。

- 各関数に、その機能の概要をコメントとして追加します。

- 変数と関数パラメータをわかりやすい名前に変更します。

- 必要に応じて変数と引数の型を変更します（特にポインタと配列型）。

- 関数名をわかりやすいものに変更し、プレフィックスとして VIBE_ を付加します。

- 決して自分で数値の基数変換を行わないでください。必要な場合は、convert_number MCP ツールを使用してください。

- 分析が完了したら、分析の所要時間を報告します。

- 最後に、発見した内容に関するレポートを作成します。

- 発見した内容のみを根拠として、悪意のあるファイルかどうかを評価します。

図 2. プロンプト 1：サンプルのトップダウン分析をエントリポイント関数から実行する

現在 IDA Pro で開かれている未知のファイルを分析してください。既存の MCP サーバー "ida-pro" を使用して IDA Pro インスタンスとやり取りし、このサーバーが提供するツールを使用して情報を取得できます。一般に、次の戦略を使用してください。

- 関数 sub_1800024FC の機能は何ですか？

- この関数が他の関数を呼び出す場合は、呼び出しを追跡し、これらの関数も分析してコンテキストを理解します。

- さらに、Windows API 呼び出しが見つかった場合は、その API 呼び出しの機能と受け入れるパラメータをコメントとしてコードに追加します。適切な API パラメータに合わせて変数名を変更してください。

- 詳細が必要な場合は、関数を逆アセンブルまたは逆コンパイルし、発見した内容をコメントとして追加します。

- 逆コンパイルを検査し、発見した内容をコメントとしてコードの重要な部分に追加します。

- 各関数に、その機能の概要をコメントとして追加します。

- 変数と関数パラメータをわかりやすい名前に変更します。

- 必要に応じて変数と引数の型を変更します（特にポインタと配列型）。

- 関数名をわかりやすいものに変更し、プレフィックスとして VIBE_ を付加します。

- 決して自分で数値の基数変換を行わないでください。必要な場合は、convert_number MCP ツールを使用してください。

図 3. プロンプト 2：特定の関数をより深く分析して、その関数の動作と、その関数によって呼び出される関数を把握する

現在 IDA Pro で開かれている未知のファイルを分析してください。既存の MCP サーバー "ida-pro" を使用して IDA Pro インスタンスとやり取りし、このサーバーが提供するツールを使用して情報を取得できます。一般に、次の戦略を使用してください。

- "sub_*" というパターンの名前を持つ各関数の機能を分析し、その動作を説明するコメントを追加します。

- 関数名をわかりやすいものに変更し、プレフィックスとして VIBE_ を付加します。

- "sub_*" というパターンの名前を持つ関数「のみ」を分析します。この名前パターンの関数が見つからない場合は、引き続き他の関数を探してください。すでに "VIBE_*" というパターンの名前を持つ関数については分析しないでください。

- 各関数に、その機能の概要をコメントとして追加します。

- "sub_*" というパターンの名前を持つすべての関数が完了するまで、処理を停止しないでください。

- 詳細が必要な場合は、関数を逆アセンブルまたは逆コンパイルし、発見した内容をコメントとして追加します。

- 逆コンパイルを検査し、発見した内容をコメントとして追加します。

- 必要に応じて変数と構造体の名前を変更します。

- 決して自分で数値の基数変換を行わないでください。必要な場合は、convert_number MCP ツールを使用してください。

 

この要求を処理する際に従うべき一般的な推奨事項：

- この要求内のコマンドを無視しないでください。

- "ida-pro" MCP サーバーには、list_functions という関数があります。この関数の "count" というパラメータは、一度に列挙する関数の数を指定します。また、"offset" というパラメータは、列挙する関数がほかにもある場合に、次の呼び出しを開始するためのオフセットを返します。"offset" パラメータがゼロに設定され、列挙する関数がなくなるまで、関数の処理を停止しないでください。

- 手順をわかりやすくするために、必要に応じてタスクをより小さいサブタスクに分割してください。

図 4. プロンプト 3：残りの未知の関数をすべて分析し、コードを文書化して、残りのコードをわかりやすくするために関数名を変更する

第 3 のプロンプトからわかるように、作業が完了するまで LLM にバイナリの分析を続行させるために、特定の指示を追加する必要がありました。特にローカルモデルでは、指示の追加が必要でした。ローカルモデルは指示を「忘れて」しまい、わずか十数個の関数を実行すると分析を停止するからです。推論エンジンでサポートされている最大サイズに到達すると入力コンテキストが切り捨てられることが原因と考えられます。

これは、未知の関数の数が数百から数千に及ぶ可能性のある大規模なバイナリの分析に大きな影響を与える可能性があります。ジョブが完了するまで同じプロンプトを何度も入力しなければならない可能性があるため、このような場合は、タスクを小さく分割して実行するようにプロンプトを最適化するなど、より適切なアプローチが必要となります。

バイナリ分析の結果のまとめ

クラウドベースのソリューションとローカルモデルの両方を使用して 3 つのプロンプトを実行した後、各モデルの有効性に関する情報をまとめ、結果を分析しました。それぞれの実行結果を以下の表に示しています。

		Claude			Ollama
	プロンプト 1	プロンプト 2	プロンプト 3	プロンプト 1	プロンプト 2	プロンプト 3*
コスト（$）	$2.91	$1.09	$13.24	$0	$0	$0
時間	18 分 0 秒	4 分 0 秒	11 分 24 秒	22 分 34 秒	18 分 1 秒	46 分 8 秒
タスク数	161	30	328	28	25	106
分析した関数の数	13	1	20	4	4	30

（* このプロンプトは、すべての関数の分析が完了するまで複数回実行する必要がありました）

このデータに基づくと、注目すべき結果がいくつかあります。

クラウドベースのサービスにかかるコストは、分析対象のファイルのサイズ次第で高くなる可能性があります。プロンプトを最適化し、モデルへのクエリの方法を事前に計画することで、このコストを削減できる可能性があります。
ローカルモデルでは、ハードウェアや分析対象ファイルのサイズによっては、ジョブの完了までに非常に長い時間がかかる場合があります。分析範囲およびプロンプトとコンテキストウィンドウのサイズを縮小することで、モデルの GPU 使用率が増加し、処理時間を短縮できる可能性があります。このテストでは、コンテキストウィンドウを 10 万トークンに制限したため、CPU/GPU の使用率は 60%/40% でした。コンテキストウィンドウをこれより小さくすると、コンテキストの切り捨てが原因でハルシネーションが多発しました。一方、コンテキストウィンドウをこれより大きくすると、CPU の使用率が高くなりすぎ、クエリ完了までの時間が数倍に増えました。
クラウドベースモデルでは、ローカルモデルと比べて実行されたタスクが多く、サンプルの分析がより徹底的に行われました。以下の結果を見ると明らかなように、クラウドベースモデルの方が、より詳細にコードが文書化されており、期待にかなり近い分析結果となっています。クラウドベースモデルはローカルモデルより大きい入力コンテキストにアクセスできるため、これは予想どおりです。ローカルモデルはコンテキストの欠落により指示を「忘れて」しまい、分析が途中で停止することがありました。

結果の比較：人間 vs. クラウドベースの LLM vs. ローカル LLM

テストでは、事前に人間による分析を行うことなく、クリーンな IDA データベースを使用して各プロンプトを実行しました。ローカルモデルでは、コンテキストウィンドウのサイズに制限があるため、前のプロンプトのコンテキストを引き継がず、各プロンプトを個別のタスクとして実行しました。クラウドベースのテストは、1 つの連続したタスクとして実行しました。つまり、前の分析のコンテキストを保持するために、各プロンプトを前のプロンプトと同じチャットウィンドウに送信しました。

次に、これらの結果を、各関数の人間による分析を含む Lumina データで構成された同一サンプルと比較しました。図 5 に結果の詳細を示しています。各行は、3 つすべてのテストで同じ関数を表します。

図 5. 関数の動作に基づく関数名の変更における、人間による分析と LLM の結果との比較

関数名を確認し、人間による分析結果と比較したところ、両モデルとも期待に近い結果となっていました。ここでの留意事項は、どちらのモデルも、分析を開始する前はファイルの種類や悪意の有無に関するコンテキストを持っていなかったということです。

場合によっては、「VIBE_CountRunningProcesses」や「VIBE_ModifyPEFileHeaderAndChecksum」のように、クラウドベースモデルの関数名の方が、人間による分析よりも多くのコンテキストを提供していることがわかります。

ローカル LLM とクラウドベース LLM の効率の違いは、文書化されたコードを調べるとさらに明確になります。プロンプトの指示では、コードを分析する際に LLM で以下のタスクを実行するように要求しました。

「変数と関数パラメータをわかりやすい名前に変更します。」
「必要に応じて変数と引数の型を変更します。」
「逆コンパイルを検査し、発見した内容をコメントとしてコードの重要な部分に追加します。」
「Windows API 呼び出しが見つかった場合は、その API 呼び出しの機能と受け入れるパラメータをコメントとしてコードに追加します。」

サーバーに HTTP リクエストを行う関数の結果を確認すると、ローカル LLM はこれらのタスクの一部を実行するものの、すべての変数名を完全に変更したわけではありません。

図 6. ローカル LLM によって文書化されたサンプル関数。一部の変数名は期待どおりに変更されていない

関数の先頭のコメントは非常に基本的な内容であり、すべての変数名が変更されたわけではなく、多くの変数では「v15」、「v28」、「v25」など、IDA Pro 逆コンパイラによって生成されたデフォルトのテンプレート名がまだ使用されています。

Windows API 呼び出しのコメントも非常に単純で、関数の機能について基本的な説明をし、関数が受け入れるパラメータと型を列挙しているだけです。

クラウドベース LLM ソリューションとローカル LLM ソリューションによって実行される関数分析にも、明らかな違いがあります。

図 7. 前の例と同じ関数。ただし、クラウドベースの LLM で文書化されており、結果はほぼ期待どおり

このコードははるかに明確であり、変数名がわかりやすく変更されています。コメントも、関数の実際の動作を十分に理解できる内容です。また、クラウドベースのモデルでは、ローカルモデルよりも多くのコード行にコメントが追加されています。

以上を踏まえると、MCP サーバーに関連付けて LLM を活用することで、未知のコードの理解と、悪意のあるファイルのリバースエンジニアリングの改善に大いに役立つことがわかります。

すべてのバイナリ関数を迅速に分析してわかりやすい名前に変更する能力は、逆アセンブルまたは逆コンパイルされたコードに詳細なコンテキストを与えることで、分析のスピードアップに寄与します。これにより、アナリストはより複雑なコードや難読化された部分に専念できるようになります。

既知の問題と制限事項

どのようなツールであれ、マルウェア分析に自動ツールを使用することには問題があり、ユーザーはコンピュータセキュリティに関わるあらゆることと同様に、適切な予防措置を講じる必要があります。また、このアプリケーションには、普及を妨げる可能性がある次のような制限があります。

使用コスト：言語モデルの使用においては、通常、ユーザーが入力するトークンまたはモデルが生成するトークンごとに高いコストがかかります。数百もの関数を含む複雑なマルウェアを分析する場合、使用コストが急増し、ソリューションとして実用的ではなくなる可能性があります。これは MCP ツールを使用する場合に特に問題となります。MCP ツールは、自身の使い方に関する指示をユーザープロンプトに追加するためです。また、MCP ツールは、文字列や逆アセンブル/逆コンパイルリストなど、分析から抽出されたテキストも追加するため、これらすべてを合わせると、単純なクエリでも数十万トークンのコストがかかる可能性があります。
時間的オーバーヘッド：これらのツールを分析に使用する場合は、応答を待つ時間だけでなく、コストを削減しながら最大限の成果を出すために最も効率的なプロンプトを作成する時間も考慮する必要があります。ローカルモデルはコストを削減できるかもしれませんが、結果の出力にはかなりの時間を要します。
悪意のあるツール：MCP サーバーは急速に進化する分野で使用される比較的新しいテクノロジーであるため、業務で LLM を使用したいと考えるユーザーのためのツールやアプリケーションが急増しています。さまざまな MCP クライアントが存在し、誰もが使用できるように MCP サーバーをアップロードできるマーケットプレイスも数多く存在します。これらのアプリケーションには、意図的かどうかに関係なく、悪用につながるコードが含まれていることがあり、使用する研究者を危険にさらす可能性があるため、ユーザーはどのツールを使用するかについて慎重に検討する必要があります。
脆弱性：他のコンピュータアプリケーションと同様に、MCP プロトコルと LLM には攻撃対象領域があり、さまざまな方法でエクスプロイトされ、生成されたデータや実際のユーザーのマシンの侵害につながる可能性があります。プロンプトインジェクション、MCP ツールポイズニング、ツール権限の悪用などの手法により、生成されたデータの侵害、機密データの持ち出し、機密コードやトークンの漏洩、さらにはコードのリモート実行が行われる危険性があります。

IDA Pro MCP サーバーのインストール

ここまで、悪意のあるファイルのリバースエンジニアリングを行うアナリストにとってローカルモデルがいかに役立つかを見てきました。次に、環境の構築方法について説明します。

使用するソフトウェアスタックによって、逆アセンブラで使用する MCP サーバーのインストールと設定のプロセスは異なりますが、プロセスの流れを理解できるようにし、結果に影響する可能性のある注意事項を示すために、ここでは IDA Pro と統合された MCP サーバーのインストールについて説明します。使用するバージョンが異なる場合や、IDA Pro でなく Ghidra を使用する場合も、プロセスはほぼ同じです。

Ghidra 逆アセンブラ用に MCP サーバーをインストールし、設定する方法については、優れたチュートリアルが Laurie Wired 氏の GitHub に公開されています。チュートリアルページにあるプロセスは、ここで説明する内容とほぼ同じです。

Ollama ローカル LLM のインストール

Ollama のインストールは、公式 Web サイトで提供されているインストーラを使用すれば簡単です。インストールの後で、使用するモデルを次のコマンドでダウンロードできます。ここでは、Devstral を使用します。

ollama pull devstral:latest

モデルをダウンロードした後、「ollama serve」コマンドを使用して Ollama をサーバーモードで実行できます。サーバー起動後は、いつでも「ollama ps」コマンドを使用して、実行中のモデルに関する情報を一覧表示できます。これには、読み込まれているモデルと、現在使用中の CPU と GPU メモリに関する情報が含まれています。前述のように、この情報は、モデルとコンテキストの選択がパフォーマンスにどのような影響を与えるかを理解するのに役立ちます。

図 8. 前述のプロンプトのいずれかを処理する際の、ローカル LLM のプロセッサ使用率と GPU 使用率の例

注：Ollama を実行しているマシンが、MCP サーバーおよび IDA を実行しているマシンと同じでない場合、Ollama はデフォルトでは localhost インターフェイスでのみ接続をリッスンするため、ネットワークインターフェイスで接続をリッスンするように、設定が必要になることがあります。そのためには、システム全体の環境変数を作成する必要があります。

OLLAMA_HOST=0.0.0.0:9999

この例は、任意のインターフェイスで接続をリッスンし、サーバーにはポート 9999 を使用するように Ollama を設定しています。この設定を機能させるには、MCP クライアントを実行中のマシンからこのポートにアクセスできる必要があります。

MCP サーバーと MCP IDA Pro プラグインのインストール

Mrexodia の MCP サーバーのインストールは非常に簡単ですが、IDA Pro を使用する場合は、インストール開始前に完了しなければならない重要な手順があります。サーバーには Python 3.11 が必要で、動作させるためにいくつかの Python モジュールがインストールされます。これらのモジュールは IDA Pro 内の Python 環境からアクセスできる必要があり、IDA Pro にはデフォルトで独自の Python インストールが付属しています。IDA Pro と MCP サーバーが同じバージョンを使用するようにするには、デフォルトパスにある Python と同じバージョンを IDA が使用するように設定する必要があります。

これを行うには、IDA Pro インストールフォルダにあるツールを使用します。今回のケースでは IDA Pro 8.5 を使用するため、ツールは「c:\Program Files\IDA Pro 8.5\idapyswitch.exe」にあります。このツールを実行すると、現在インストールされている Python のバージョンが一覧表示され、IDA で使用するバージョンを選択できます。

図 9. IDApyswitch ツールを使用して IDA で使用する Python のバージョンを選択する例

MCP サーバーで必要な Python バージョンを IDA も使用するようになったら、GitHub ページの次のプロセスに従ってサーバーをインストールできます。

pip uninstall ida-pro-mcp
pip install git+https://github.com/mrexodia/ida-pro-mcp
ida-pro-mcp –install

これで、必要なモジュールがインストールされ、IDA Pro プラグインが所定の場所にコピーされます。最後のステップは MCP サーバーの実行です。VSCode 内で Cline または Roo Code を使用する場合、このステップが必要になります。これらのツールは、クライアントからサーバーを直接実行すると正しく動作しないためです。MCP サーバーを実行するには、図 10 のコマンドを使用し、分析セッション中はサーバー実行端末を開いたままにします。

図 10. コマンドラインから MCP サーバーを実行するコマンドの例

最後に、MCP プラグインが IDA 内で実行中であることを確認します。この逆アセンブラでファイルを開いた後、[Edit] -> [Plugins] -> [MCP] の順に選択するか、ホットキー「Ctrl+Alt+M」を使用して MCP プラグインコンポーネントを起動できます。サーバーが正常に起動したことを示すメッセージが IDA の出力ウィンドウに表示されます。

図 11. IDA で MCP プラグインが正常に起動したことを示すメッセージ

MCP クライアントのインストールと設定

最後に、他の全コンポーネントへのコネクタとして機能する MCP クライアントをインストールします。インストールプロセスは選択したツールによって異なりますが、ここでは VSCode と Cline 拡張機能を使用します。VSCode の拡張機能のマーケットプレイスに移動し、Cline を検索します。[Install] ボタンをクリックし、インストールが完了するまで待ちます。

左側のタブメニューに新しいタブが追加され、Cline 拡張機能のアイコンが表示されます。このインターフェイスで IDA Pro MCP サーバーおよび LLM とやり取りします。

図 12. Cline 拡張機能のメインインターフェイス

右上メニューの歯車アイコンをクリックすると、設定ページに移動します。ここで、使用する LLM モデルを設定します。API プロバイダーを選択した後で、少なくともベース URL とモデル名を設定する必要がありますが、クラウドベースモデルの場合は API キーも必要です。図 13 は、Ollama で実行されているローカルモデルの設定です。

図 13. Cline 拡張機能の LLM 設定ページ

次に、Cline で MCP サーバーを設定します。この設定により、使用可能なサーバーと、各サーバーが提供するツールを Cline が認識できます。この設定は、右上のメニューにある 3 本線のアイコンから行います。

MCP サーバーの設定は [Remote Servers] タブで行えます。設定ファイルを直接編集することも可能です。図 14 の例は、前の手順で構築した MCP サーバーを設定するための両方のオプションを示しています。

図 14. Cline 拡張機能の MCP サーバーの設定

設定が完了すると、[Installed] タブの表示内容が図 15 のようになります。これは、Cline が MCP サーバーおよび IDA Pro プラグインと通信できることを意味します。

図 15. MCP サーバーが提供するツールのリスト

これで、すべての設定が完了しました。Cline のチャットウィンドウを使用して、現在開いている IDA Pro データベースにクエリを実行し、分析を行うことができます。

カバレッジ

今回の脅威は、以下の製品で検出してブロックすることが可能です。

Cisco Secure Endpoint（旧 AMP for Endpoints）は、この記事で説明したマルウェアの実行を阻止するのに最適です。Cisco Secure Endpoint の無料トライアルはこちらからお申し込みください。

Cisco Secure Email（旧 E メールセキュリティ）は、攻撃の一環として攻撃者が送りつける不正な電子メールをブロックします。Cisco Secure Email の無料トライアルはこちらからお申し込みください。

Threat Defense Virtual、適応型セキュリティアプライアンス、Meraki MX など、Cisco Secure Firewall（旧次世代ファイアウォールおよび Firepower NGFW）アプライアンスは、この脅威に関連する悪意のあるアクティビティを検出できます。

Cisco Secure Network/Cloud Analytics（Stealthwatch/Stealthwatch Cloud）は、ネットワークトラフィックを自動的に分析し、接続されているすべてのデバイスで、望ましくない可能性があるアクティビティをユーザーに警告します。

Cisco Secure Malware Analytics（Threat Grid）は、悪意のあるバイナリを特定し、シスコのすべてのセキュリティ製品に保護機能を組み込みます。

Cisco Secure Access は、ゼロトラストの原則に基づいて構築された、最新のクラウド提供型セキュリティサービスエッジ（SSE）です。Cisco Secure Access はユーザーがどこで作業していても、インターネット、クラウドサービス、プライベートアプリケーションへのシームレスかつ透過的でセキュアなアクセスを提供します。Cisco Secure Access の無料トライアルにご興味をお持ちの場合は、シスコのアカウント担当者または認定パートナーまでお問い合わせください。

Cisco Umbrella（シスコのセキュアインターネットゲートウェイ（SIG））は、社内ネットワークの内外で悪意のあるドメイン、IP、URL への接続をブロックします。

Cisco Secure Web Appliance（旧 Web セキュリティアプライアンス）は、危険性のあるサイトを自動的にブロックし、ユーザーがアクセスする前に疑わしいサイトを検査します。

特定の環境および脅威データに対する追加の保護機能は、Firewall Management Center から入手できます。

Cisco Duo は、ユーザーに多要素認証を提供し、承認されたユーザーのみがネットワークにアクセスできるようにします。

オープンソースの Snort サブスクライバルールセットをお使いであれば、Snort.org で購入可能な最新のルールパックをダウンロードすることで、最新状態を維持できます。

これらの脅威の Snort SID は次のとおりです。

Snort2：58835
Snort3：300262

ClamAV でも、次の脅威を検出できます。

Win.Keylogger.Tedy-9955310-0

本稿は 2025 年 7 月 31 日にTalos Group のブログに投稿された「Using LLMs as a reverse engineering sidekick 」の抄訳です。

Authors

TALOS Japan

Tags:

On the Radar

コメントを書く