LLMやMCP利用によるマルウェア関数命名の実践例

背景

• サイバーセキュリティ危機管理部の田中です。我々のチームでは、脆弱性解析やマルウェア解析を行っています。また同時に、日々進化するLLMモデル、Agent、MCP技術をウォッチ/検証して、我々の解析業務の改善できないか取り組みを行なっています。

• 本記事では、非常に稼働が必要とされるマルウェアの静的コード解析において、LLM Agent　を利用し効率化を図った場合に起こる、2つのトピックに対しての実験、結果、工夫点等を示します。

記事サマリ

• 経験のある解析者でも稼働を必要とする、IDAProを用いた静的コード解析における関数命名作業について、LLMAgent(MCP)が実践に耐えうるかの評価を実施しました。人が名前づけを行なったIDAデータ、LLMAgentが名前づけを行なったIDAデータを元にSentence-BERTにより評価をしたところ平均値0.6以上の結果となり、個々の分析も含めると、実践への導入の可能性が十分にあることが評価できました。
• LLMAgentを用いる場合、特に、関数の数が多い検体の場合、Context Windowをオーバーしてしまう課題があります。これに対して、事前にIDAProから解析結果を取得しておき、その後で、LLMAgentに解析させる工夫により、LLMAgentの負担を軽減し、目的である、関数名や引数名の命名や関数へのコメントづけを、現在のContext Window制約の中で達成できることを示しました。また同時に、LLMAPIの費用面のコストも落とせることを示しました。

トピック 1 LLMによる関数名前づけの正確性評価

環境と実験設定

• 環境 : Windows11(VM), VSCode + Cline,IDA Pro9.0 +ida-pro-mcp1.4
• ClineがVSCode上でMCPクライアントとして動作し、ida-pro-mcpがMCPサーバです。
• Clineには、外部LLMとして Claude-sonnet 4.5[200k]を利用しています。（これは当時2025/8-9頃の我々の検証では、この分野（ida-pro-mcp,x64dbg-mcp)では、Clineに組み合わせるLLMはClaude-sonnetが一番性能が出ていることを確認していた為です★）

• 上記環境を用い、プロンプトの改善を繰り返し、最終的に、末尾に示すプロンプト（プロンプト1）を用いました。解析の起点関数から呼び出し順序を辿り、それぞれの関数名を考案させ、IDA上で考案名に変更をさせます。（ライブラリ関数やLuminaで名前解決済みの関数は除外します）プロンプトで、赤字部分（解析の起点関数、アウトプットファイル名）は適宜変更してください。解析の起点は、特にDLLの場合、呼び出し側の処理に依存することもあるため、このプロンプトとしました。
• 上記LLMの命名が正しいかを判断するために、解析者が、名前づけを行った正解IDAデータベース（以下idbと呼びます)を準備します。
• LLM関数命名と解析者関数命名をsentence-transformers pythonライブラリを用いたSentence-BERTを用い類似度を算出します。(注:1)
• 以下、3検体に対しての実験結果を示します。

検体1DUSTPAN(StealthVector)

• SHA256 : 0faddbe1713455e3fc9777ec45adf07b28e24f4c3ddca37586c2aa6b539898c0
• APT41が用いるとされるAES暗号化やコード難読化を用いたローダー機能を持つ検体です。
• idbは、解析者が分析したものを、GitHubリポジトリから入手し、関数名前づけが正しいかを、IDA上でのコードや解析レポート等でチェックを行いました。
• 結果は以下の通りです。SBERT値の平均値は0.607で、個別に見ると、特に0.5を超えている関数名について、解析者目線でみても、類似の関数であることが推測できると思います。0.5以下のもの、例えば一番値の低い、0x7ff9d0381600は、コンピュータ名を取得してXOR変換等の処理を行い保存を行う処理で、これは初回呼び出しのみ行われ後で使われます。初回のみ動作し後で使われる点を重視するか、関数のXOR処理を重視するかで命名観点が異なることとなり、SBERT値が0.327と低い値となっています。
• また、プロンプトの改善により、1個以外は正解データの名前づけができました。後半の3個については、正解データでは、名前づけができていない/しなかった関数についてもLLMは名前づけが行っています（今回は正解データにないので評価対象外としました）。

検体2 ESET-Wiperと呼ばれるステージ検体の一部

• SHA256 : 2abff990d33d99a0732ddbb3a39831c2c292f36955381d45cd8d40a816d9b47a
• ペイロード（ワイパー）実行する機能を持つ検体です。（ネットで少し調べると、ESETを装ったステージ構成のワイパーであることがわかります）
• 検体1と同じく、idbは、解析者が分析したものを、GitHubリポジトリから入手し、関数名前づけが正しいかを、IDA上でのコードや解析レポート等でチェックを行いました
• 結果は以下の通りとなります。SBERT値の平均値は0.630で、個別に見ても、全て0.5を超えており、比較的適切な命名がされたと判断できます。

• LLMはステージ構成を知らないため、wipe_dataをexecute_malware_payloadとしています。本関数(0x4016c0)内では、ShellExecuteAが隠されている構成で、引数の数と型で同APIを推定しており、「実行」を含む名前づけができたのは、LLMのコード解釈能力の高さからと思われます。

検体3 Iced_Id

• sha256 : fa684c8c3131dc54adf6379e6e2a6f605552e5063c7f0eb9e9910149ead057fe
• Iced_Idはローダー/スティーラーとして比較的有名な検体です。CAPE Sandboxでパッキングを解いた検体です。
• Github等にidbは発見できなかったため、解析記事等も参考にして、自身で命名を行い正解データを作成しました。
• 結果は以下の通りです。SBERTの平均値は0.657で、高い関数と低い関数にばらつきがあることがわかります。高い関数としては、rc4やdecrypt系の暗号系やwrite等の関数、低いものとして関数0x004010F6(0.211)があります。暗号系アルゴリズムに強いのは私の以前の調査発表からも納得が行く結果でした。関数0x004010F6(0.211)については、rdtsc命令の差分やcpuid命令で環境情報を取得して固定フォーマットで出力する処理をしています。私はアンチVMかもしれないという命名にしましたが、LLMは、システム情報を固定フォーマットで出力している点をfingerprintと解釈した可能性があります。LLMのコード解釈による命名も正しく、私の解釈もpossible_として推測なので、この辺りは、両者のすり合わせが有効かもしれません。

(補足) 検体3における関数ツリー構造

• プロンプト1による出力結果には関数ツリー構造がMermaid形式で出力されるため、以下のように、対応エディタであれば簡単に、関数呼び出し関係を図として確認することができます。

  

  ---

graph LR
start --> main_loader_function
main_loader_function --> read_file_to_buffer
main_loader_function --> download_payload_http
download_payload_http --> generate_system_fingerprint
download_payload_http --> http_request
main_loader_function --> write_buffer_to_file
main_loader_function --> rc4_decrypt
rc4_decrypt --> rc4_init_key_schedule
main_loader_function --> validate_and_decrypt_payload
validate_and_decrypt_payload --> rc4_decrypt
main_loader_function --> prepare_payload_in_memory

トピック1の結論と課題

• 人間が名前づけした関数名とLLMの名前づけした関数名のSentence-BERTによる類似度平均が6.0以上であったこと、また、個々の類似度が高い/低い関数も、根拠があることから、解析の現場でも、静的コード解析の初期稼働を削減する目的で導入でトライアルする価値は十分あると思われます。
  （もちろん、一部関数は、上記例で見見たように、に人が最終的に名前づけをする作業が残る可能性はありますが。）

• 課題として一番大きいのは、LLMのContext_Windowの限界です。今回検体1が一番大きく20個程度の関数を解析する必要がありましたが、17個にとどまりました。実際のCline(MCPクライアント）の動作として、Context_Windowを40%程度消費すると、LLMが正常に応答しなくなり、作業を強制終了させようとします。プロンプト1では重要作業のスキップを防ぐため、かなりストリクトなプロンプトとしています。当然、さらに多くの関数を持つ検体は存在するためスクリプト対応では限界があり、課題となります。

(参考) プロンプト1

あなたはマルウェア解析のエキスパートです。現在 IDA Pro MCP で開いているマルウェアを解析します。

出力は必ず日本語で行ってください。

(0) 解析方針　標準ライブラリ関数やシステムAPIの中身は調査しない。
解析対象はユーザ定義関数のみとする。　デコンパイルコードの解析ができない場合は、逆アセンブリコードの解析をする　"[ERROR] Failed to process response: Too many tokens, please wait before trying again."が発生　したときは、少し時間をおいてから再実行すること

(1) 開始点　
メイン関数（解析開始関数名を指定）から解析を開始する。

(2) 呼び出し関係の俯瞰　
メイン関数のget_calleesで1階層目の内部関数を全抽出する　
各内部関数に対して再帰的にget_calleesを実行する　
context window制限まで可能な限り深い階層を探索する　
発見した全内部関数をリスト化し重複排除する

(3) 関数名の命名　
(3)でリスト化した全内部関数（〇個）を以下を順次実行：　
・decompile_functionで解析する　
・機能を推定し適切な関数名を考案する　
・rename_function APIで実際に全ての関数名を変更する（★必ず実行★）　
・rename忘れがないか必ず、(3)のリストと比較してチェックする　
変更前後の対応表を作成する　
【重要】全○個の関数について必ずrename_function APIを実行すること　
【禁止】時間効率や重要度を理由とした作業の省略は一切認めない　
【確認】rename実行前に必ず「○個中○個完了」で進捗報告すること　
【検証】最終的にリスト化した全関数の変更前後対応表を作成

(4) 重要関数リストの作成
次の観点で重要度を評価する　
・システムAPI呼び出しの多さ（通信、ファイル操作、プロセス操作など）
・暗号化・復号・圧縮などの処理を含むか　
・コードサイズや分岐の多さ　
・他の関数からの呼び出し頻度　
これらをもとに「重要関数リスト」を生成する。

(5) コメントの付与（重要関数のみ）　
重要関数リストに載っている関数のみ以下を実施する。　
コメント付与APIを使ってデコンパイルコードまたはアセンブリコードにコメントを付与する。

(6) 変数名の命名（重要関数のみ）　重要関数リストに載っている関数のみ以下を実施する。　
デコンパイルコード上の無意味な変数名 (v1,v2,v3... / a1,a2,a3...) を特定し、　用途を分析して重要変数のみ、より意味のある名前に変更する。　rename_local_variable API を使って命名する。　
EtwEventWriteなど、明示的に意味を持つ変数名は変更しない。　
変更前後の対応表を詳細に記録

(7) ファイル出力 　
ファイル名：（ファイル出力名を指定).md　
出力には以下を含む：　
・呼び出し関係ツリー（簡略でよい）　
・関数の命名結果（旧名→新名）　
・関数ごとに変数名の変更（旧名→新名）　
・関数ごとの機能概要（1〜2文）　
・コメント追加箇所の例（数行）

### 重要な制約事項 ###
■ 作業完了の定義
- 発見した全内部関数数と実際にrename_functionを実行した関数数が一致すること
- 1つでも未処理の関数がある場合は「未完了」とする

■ 進捗管理の強制
- 各関数処理後に「○個中○個完了 (残り○個)」を必ず報告
- task_progressパラメータで具体的な数値を更新

注意事項

注:1 論文等、厳密に評価する必要がある場合は、人が行う名前づけ自体にもブレがあるため、命名のルールかや正規化等が必要ですし、Sentence-BERTや他のアルゴリズムも加えて、F値等の、通常の機械学習の流儀における評価が必要です。今回は論文化ではなく、解析現場での利用促進が可能か想定してSBERTで当たりをつけて個々を見る評価を行っています。

トピック2 LLMのContext_Windowの節約の工夫

Context_Window

• トピック1で課題となった、Context_Window制約による問題を解決する手段を検討します。Context_Windowは、LLMモデルが一度のやり取りで保持できる入力と出力の合計トークン数です。
• Claude-sonnet 4.5[200k] モデルは名前の通り、Context_Windowは200kです。1Mモデルも選択できますが、200k以上になると、

  現時点の料金設定では、Tokenあたりの金額が倍になる価格設定になっており、コスト面でも課題になり、200kモデルを選択しています。

• 今回は未知関数が最大でも20個程度の検証をトピック1では扱いましたが、現実は、もっと未知関数が膨大な検体も多く存在するので、優先度の高い課題と考えました。

解決手法

• いくつかのアイディアに基づき検証を行った結果、一番うまくいったのは、MCP/LLMを使う前に、IDA ProからIDApythonで、関数起点からの関数の呼び出しツリー、デコンパイルコード及びディスアセンブリコード等の抽出の3情報を事前に取得しておく方法でした。（その他、IDA Proから取れる情報をできる限り取得しました。例えば、import/export情報、グローバル、配列、名前付きデータ参照情報、文字列参照情報等です。）
• IDA Pro MCP は、get_callees 、get_callers等のAPIを用いて、関数の呼び出し関係を調査することが可能で、トピック1ではMCPに指示しています。ですが、MCPに実行されれば、その分の、token数が消費されます。同じく、デコンパイルコード及びディスアセンブリコード抽出も同様です。これらはContext_Window消費の要因となります。
• そこで、あらかじめ、IDApythonにより情報取得、idbディレクトリ階層に配置しておき、MCPに参照させることで、MCPの負担を減らします。
• トピック1の検体1で使用したプロンプトは、末尾に示すプロンプト2(ベースプロンプト：検体ごとに共通のもの）、同じく末尾に示すベースプロンプトに付加する関数ツリー情報、に示します。何回か試行を試行を繰り返し、最も役立つのは、関数の呼び出しツリー、デコンパイルコード及びディスアセンブリコードの3点だとわかったため、プロンプト2の構成としました。
• また、プロンプト2ではContext_Windowに余裕ができることを想定し、解析時において、関数名の次に重要となる引数名の解析の指示も含めました。さらに、LLMの関数命名の確信度を判断させ、 関数名先頭にはmw+数値の表記(1-3で1が確信度高)も含めました。この数値により、最終的に人間が判断する際の目安となることを期待しています。
• なお、今回、記事の長さの都合もあり、IDApythonの実コードはつけることができませんでしたが、取得できるデータをダンプするという単純な処理なので、再現は容易だと思います。

結果

• LLMをトピック1のClaude-Sonnet 4.5を使った場合、関数名は全てidb上での名前づけを行えましたが、引数が、3関数のみでContext_Windowオーバーで打ち切りとなりました。

• LLMをOpenAI gpt-5-2025-08-07モデル(Context Window 272k)に変更したところ、以下の結果の通り、すべての関数及び引数（引数がない関数もあるため関数名とは一致していません）のidb上での変更ができ、まだ、Context_Windowに余裕がある状態でした。

• トピック1で、Cline + Claude Sonnetの方が性能が出ていたため（★の部分参照）、最初にSonnetを利用しました。ですが、トピック2の手法では、事前にIDApythonにより解析に必要なファイルを準備しておき、解析戦略が最小限となり、MCPとしてはコードの解釈とMCPのAPIを用いたidb上の名前変更に特化したため、gpt-5でも十分対応できたと考察しています。また最後まで解析できて、まだContext_Windowに余裕がある状態というのは、単にgpt5が272kと大きいという要因意外にも何か別の要因（例えば、Cline + Claude Sonnetの方がMCP間のやり取りで多く推測をしている、これはClineの解析画面を見ていると確認できる）がある可能性も考えられます。

• 費用については、現時点では、Claude Sonnet 4.5とOpenAI gpt-5では、Sonnetの方が2-3倍高いことから、大量の関数を想定した場合も費用に優位性があることがわかりました。実際のAPI費用は、検体1の場合、2.50$でした。トピック1では、解析打ち切りになり十分にプロンプト指示を満たせない状態で、8-10$程度の費用がかかっていました。

  ---

  以下を実施し、IDA上で関数名および引数名を実際に変更しました。
  1. 関数名（mw_接頭辞で命名）
  - 0x7FF9D0381D50 → mw1_entry_orchestrator
  - 0x7FF9D03816F0 → mw1_config_init_from_embedded_blob
  - 0x7FF9D03821C0 → mw1_read_decrypt_payload_from_file
  - 0x7FF9D03835B0 → mw2_map_payload_into_module_section
  - 0x7FF9D03847B0 → mw2_inject_and_resume_remote_thread
  - 0x7FF9D0384490 → mw2_create_suspended_process_with_ppid
  - 0x7FF9D03837E0 → mw2_map_system_dll_section_in_remote_and_copy_payload
  - 0x7FF9D03832D0 → mw2_build_system_dll_path_for_payload
  - 0x7FF9D0383410 → mw2_locate_ntdll_syscall_stub_pattern
  - 0x7FF9D0382710 → mw2_encrypt_xor_with_hostname_and_write_file
  - 0x7FF9D0381600 → mw1_decrypt_alloc- 0x7FF9D0381300 → mw1_aes_cbc_decrypt_with_embedded_key
  - 0x7FF9D0381000 → mw1_aes_cbc_encrypt_with_embedded_key
  - 0x7FF9D0382CE0 → mw2_pick_compatible_system_dll_and_rva
  - 0x7FF9D0384090 → mw2_find_ppid_candidate_pid
  - 0x7FF9D0382500 → mw1_resolve_payload_file_path
  - 0x7FF9D0382990 → mw2_is_whitelisted_system_dll_name
  - 0x7FF9D0383F00 → mw2_is_suitable_parent_candidate
  - 0x7FF9D0383D30 → mw1_get_process_token_user
  - 0x7FF9D0383B10 → mw1_process_has_se_debug_privilege
  - 0x7FF9D0384AC0 → mw3_post_injection_cleanup
  

  2. 引数名（パラメータ名の意味付け
  - 0x7FF9D03821C0 mw1_read_decrypt_payload_from_file: a1→outPayload, a2→outSize
  - 0x7FF9D03835B0 mw2_map_payload_into_module_section: a1→payloadData, a2→payloadSize, a3→outMappedEntry
  - 0x7FF9D03847B0 mw2_inject_and_resume_remote_thread: a1→payloadData, a2→payloadSize, a3→targetProcessInfo
  - 0x7FF9D0384490 mw2_create_suspended_process_with_ppid: a1→appPath, a2→outProcessHandle, a3→outThreadHandle
  - 0x7FF9D03837E0 mw2_map_system_dll_section_in_remote_and_copy_payload: 既に第1引数は hProcess（IDA側推定名）。a2→payloadData, a3→payloadSize, a4→outRemoteEntry を反映済み
  - 0x7FF9D03832D0 mw2_build_system_dll_path_for_payload: a1→payloadSize, a2→reserved, a3→outDllPath, a4→outRvaOffset
  - 0x7FF9D0382710 mw2_encrypt_xor_with_hostname_and_write_file: lpFileName→destPathW, Src→dataPtr, MaxCount→dataSize
  - 0x7FF9D0381600 mw1_decrypt_alloc: a1→encCtxFlags, a2→iv16, a3→inBuf, a4→inSize, a5→outPtr, a6→outSize
  - 0x7FF9D0381300 mw1_aes_cbc_decrypt_with_embedded_key: a1→encCtxFlags, a2→iv16, a3→inBuf, a4→inSize, a5→outBuf, a6→inoutOutSize
  - 0x7FF9D0381000 mw1_aes_cbc_encrypt_with_embedded_key: a1→encCtxFlags, a2→iv16, a3→inBuf, a4→inSize, a5→outBuf, a6→inoutOutSize
  - 0x7FF9D0382CE0 mw2_pick_compatible_system_dll_and_rva: a1→payloadSize, a2→outDllName, a3→outRvaOffset
  - 0x7FF9D0382500 mw1_resolve_payload_file_path: a1→outPathW
  - 0x7FF9D0382990 mw2_is_whitelisted_system_dll_name: a1→dllNameW
  - 0x7FF9D0383F00 mw2_is_suitable_parent_candidate: a1→pid, a2→imageNameW
  - 0x7FF9D0383D30 mw1_get_process_token_user: a1→pid, a2→outTokenUser
  - 0x7FF9D0383B10 mw1_process_has_se_debug_privilege: a1→pid

(参考) プロンプト2（ベースプロンプト）

あなたはマルウェア解析のエキスパートです。カレントファイルにあるファイル群は、ある検体をIDA Proで解析し、抽出したデータです。
特に重要なファイルは以下です。
- decompフォルダ : 各関数のデコンパイル結果
- functions.jsonl : 関数のディスアセンブル結果
開始アドレスは、sub_7FF9D0381D50です。開始アドレスから呼び出される関数に対し以下の作業を行ってください。呼び出し関係は★を参照してください。

(1) 各関数の意味を考察し、関数の名前を考案する。その際に、考案した名前が対象関数の意味を的確に表現できたかの指標（1-3の値で1が一番確信度が高い）も算出する。新関数名は、mw + 確信度(1-3) + "_" + 考案した名前とする。

(2) 各関数の引数の意味を考察し、引数の名前を考案する。例: a1 → outBuffer, a2 → outSize のように意味のある名前にする

(3) ★重要★IDA Pro MCPを用いて以下を実行する：
- rename_function ツールで関数名を変更
- rename_local_variable ツールで各関数の引数名（a1, a2, a3など）を変更
- 全ての関数について、関数名と引数名の両方をIDA上で実際に変更すること
- set_comment ツールで各関数の概要をコメントとしてIDAに反映する

[重要事項]
- 必ずIDA Pro MCPのツールを使用して、実際にIDA上で名前を変更してください
- 関数名の変更だけでなく、引数名（パラメータ名）の変更も必ず実行してください
- IDA Pro MCPサーバー(ida-pro-mcp)が接続されているので、use_mcp_toolで利用できます
- 引数名の変更には rename_local_variable ツールを使用します

★開始アドレスからの呼び出し関係及び階層ごとの一覧は以下のとおりです。

(参考) ベースプロンプト末尾に付与する、関数ツリー情報。

graph TD
sub_7FF9D0381D50 --> sub_7FF9D03821C0
sub_7FF9D0381D50 --> sub_7FF9D03821C0 --> sub_7FF9D0382500
sub_7FF9D0381D50 --> sub_7FF9D03821C0 --> sub_7FF9D0381300
sub_7FF9D0381D50 --> sub_7FF9D03821C0 --> sub_7FF9D0382710
sub_7FF9D0381D50 --> sub_7FF9D03821C0 --> sub_7FF9D0382710 --> sub_7FF9D0381000
sub_7FF9D0381D50 --> sub_7FF9D0384AC0
sub_7FF9D0381D50 --> sub_7FF9D03816F0
sub_7FF9D0381D50 --> sub_7FF9D03816F0 --> sub_7FF9D0381600
sub_7FF9D0381D50 --> sub_7FF9D03816F0 --> sub_7FF9D0381600 --> sub_7FF9D0381300
sub_7FF9D0381D50 --> sub_7FF9D03835B0
sub_7FF9D0381D50 --> sub_7FF9D03835B0 --> sub_7FF9D0383410
sub_7FF9D0381D50 --> sub_7FF9D03835B0 --> sub_7FF9D03832D0
sub_7FF9D0381D50 --> sub_7FF9D03835B0 --> sub_7FF9D03832D0 --> sub_7FF9D0382CE0
sub_7FF9D0381D50 --> sub_7FF9D03835B0 --> sub_7FF9D03832D0 --> sub_7FF9D0382CE0 --> sub_7FF9D0382990
sub_7FF9D0381D50 --> sub_7FF9D03847B0
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D0384490
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D0384490 --> sub_7FF9D0384090
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D0384490 --> sub_7FF9D0384090 --> sub_7FF9D0383B10
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D0384490 --> sub_7FF9D0384090 --> sub_7FF9D0383F00
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D0384490 --> sub_7FF9D0384090 --> sub_7FF9D0383F00 --> sub_7FF9D0383D30
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D0384490 --> sub_7FF9D0384090 --> sub_7FF9D0383F00 --> sub_7FF9D0383B10
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D0384490 --> sub_7FF9D0384090 --> sub_7FF9D0383D30
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D03837E0
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D03837E0 --> sub_7FF9D0382CE0
sub_7FF9D0381D50 --> sub_7FF9D03847B0 --> sub_7FF9D03837E0 --> sub_7FF9D0382CE0 --> sub_7FF9D0382990

開始アドレスから呼ばれる関数(xrefs.jsonl)

- --- Unique Functions (階層順) ----
sub_7FF9D0381D50 (depth=0)
sub_7FF9D03821C0 (depth=1)
sub_7FF9D0384AC0 (depth=1)
sub_7FF9D03835B0 (depth=1)
sub_7FF9D03816F0 (depth=1)
sub_7FF9D03847B0 (depth=1)
sub_7FF9D0381300 (depth=2)
sub_7FF9D03832D0 (depth=2)
sub_7FF9D0383410 (depth=2)
sub_7FF9D0384490 (depth=2)
sub_7FF9D0382710 (depth=2)
sub_7FF9D03837E0 (depth=2)
sub_7FF9D0381600 (depth=2)
sub_7FF9D0382500 (depth=2)
sub_7FF9D0381000 (depth=3)
sub_7FF9D0384090 (depth=3)
sub_7FF9D0382CE0 (depth=3)
sub_7FF9D0382990 (depth=4)
sub_7FF9D0383F00 (depth=4)
sub_7FF9D0383D30 (depth=4)
sub_7FF9D0383B10 (depth=4)

まとめ

• 今回は、LLMによる関数名前づけの正確性評価、と、LLMのContext_Windowの節約の工夫について、紹介させて頂きました。IDAで解析をやられる業務をしている方であれば、業務効率化につながる可能性があるので、是非、実験をしてみるのをお勧めしたいと思います。

• LLMやMCPの進歩はとても早いので、我々も日々ウォッチして検証をしておりますが、現時点での、比較的良い知見ということをご理解いただければ幸いです

社会情報研究所 田中 恭之、佐藤 亮太