happytotoro116/ghidra-llm-pipelineC再実装のための決定論的PyGhidra抽出、トリアージ、ローカルLLMコンパイラバックエンドパイプライン。
私の Ghidra + LLM パイプラインをダウンロードしていただきありがとうございます。
これは私にとって初めての README です。私の第一言語は ASL（アメリカ手話）なので、英語は完璧ではありません。できる限りのことをしました。
子供の頃から遊んでいる古い PC シミュレーションゲームが大好きで、その内部を改良したいと思っています。
OpenRA や OpenTTD のようなオープンソースゲームを見て学んだことはこれです。趣味による再実装とは、オリジナルのソースコードを手に入れることではありません。オリジナルのアセットを読み込める、新しいオープンソース版のゲームを作ることです。そうすれば誰でも拡張したり貢献したりできます。
作業には 2 種類の AI を組み合わせて使っています：
すべての関数に 1 つのラベルが付きます。これにより、OS やランタイムの大量の不要物に労力を浪費せず、多くの時間を節約できます。
|-----------|------------------------------------------------------------------------------------------------------------------
| ラベル | 意味 |
|---|---|
| KEEP | ゲーム自身のロジック（例：飛行モデル、ダメージモデル、TrackIR） |
| WRAP | OS や入力 API を呼び出す Java 向けのグルーコード：シグネチャは保持し、本体を新しく書く。 |
| （IL-2 1946 は興味深いエンジンです：C++ と Java が共存しています。） | |
| REPLACE | 古い C ランタイム、アロケータ、サンク：コンパイラや OS が提供するため、新しい 64 ビット版には不要 |
| UNKNOWN | 不明：手作業で確認する |
| ----------- | ------------------------------------------------------------------------------------------------------------------ |
私のテストプログラムでは、関数の約 44% が REPLACE だったので、変換する必要はありませんでした。
最初は C 擬似コードがすべての答えを持っていると信じていました。それは甘い考えでした。それは Ghidra によるアセンブリの解釈であり、推測を含みます（変数型、失われた引数）。
アセンブリこそが生の真実です。変数型はありませんが、各関数の正確な動作を保持しています。 そのためスクリプトはアセンブリを読み、C に似た形式のブループリントに変換します。Ghidra の C はヒントとしてのみ保持されます。
初期のテストでは、ローカル LLM（Qwen 2.5 Coder、DeepSeek Coder V2 Lite、Mellum 2）を使ってアセンブリを直接読ませていました。 それは決して安定して動作しませんでした。LLM はコードを書くために作られており、生のマシンコードを読むためではないため、ハルシネーションを起こしました。
多くの失敗した実験の後、作業を分割しました：
注：Python が答えを検証する方法
テキストチェック：関数名、ブループリントからのすべての呼び出し・グローバル・文字列、 ループ、ステップサイズ、比較される定数、戻り値、およびレジスタ名や でっち上げの名前が残っていないこと。
gcc コンパイルチェック: コードは gcc でコンパイルされます（構文チェックのみで、実行はされません）。 これは大いに役立ちました。初期の実行では、テキストチェックは Mellum 2 の回答を通過しましたが、 コメントの外に書かれたヘッダーコメントのせいで、どれもコンパイルできませんでした。 gcc はテキストチェックでは見えないものを捕捉します。宣言されていない変数や再宣言された変数、 誤った型、壊れた波括弧やセミコロンなどです。関数が PASS とみなされるのは、 テキストチェックとコンパイルの両方が OK の場合のみです。gcc はロジックが正しいことを証明するわけではないので、 私は今でもブループリントと照らし合わせてコードを読みます。
チェックが失敗した場合、LLM は失敗した項目のリストを受け取り、もう一度試みます。
Python は LLM なしで小さなミスを自ら修正します。各変数を一度だけ宣言し、 はみ出したヘッダー行をコメントで囲み、最後の return が正しい結果を返すようにし、 include と宣言を追加します。
このチェックリストは、LLM が非常に長い関数で失敗するのを目にしてから作りました。パイロットが 離陸前と着陸前に使うチェックリストと同じように機能します。Python が関数からそれを作成し、回答をそれと照らし合わせてチェックします。私のテストでは、 長い関数が通り始め、実行も速くなりました。
|-------------------|---------------------------------------|---------------------------------------------
| フォルダ | 機能 | 参照先 |
|---|---|---|
ghidra_pipeline | ダンプ、グループ化、トリアージ、ロール | ghidra_pipeline/INSTRUCTION.txt |
llm_pipeline | ブループリントと LLM ランナー (v3) | llm_pipeline/INSTRUCTION_BLUEPRINT_LLM.txt |
| ------------------- | --------------------------------------- | --------------------------------------------- |
まず ghidra_pipeline から始め、ローカル LLM を使う準備ができたら llm_pipeline に進んでください。
まず、PyGhidra でプログラムを解析し、PyGhidra Scripts/decompile_full_dump.py を実行してください。
2 つの INSTRUCTION ファイルがフォルダの設定について説明しています。その後:
まず、PyGhidra でプログラムを解析し、PyGhidra Scripts/decompile_full_dump.py を実行してください。
2 つの INSTRUCTION ファイルがフォルダの設定について説明しています。その後:
python .\make_full_lite_v2.py --in . --out .\OUT
python .\triage_evidence_v2.py --lite .\OUT\LITE_AC
python .\build_roles_v2.py --triage .\OUT\TRIAGE
python .\blueprint_v3.py --group ".\SOURCE\LITE_AC\<GroupName>" --out ".\G_<GroupName>\BLUEPRINT_v3"
python .\run_blueprint_llm_v3.py --bp ".\G_<GroupName>\BLUEPRINT_v3" --out ".\G_<GroupName>\RUN1_v3_<model>" --model <model name>
GhidraとPyGhidra、Python 3、LM Studio（モデルを1つロード済み）、そしてgcc（推奨。コンパイルチェックに使用）が必要です。
このリポジトリにはスクリプトとドキュメントのみが含まれています。ゲームファイル、コード、データは一切ありません。所有しているプログラムにのみ使用し、 それらに適用されるルールに従ってください。
別のゲームで試して、うまくいったこと・いかなかったことを教えてください。アイデアや 改善案も歓迎します。
スクリプトを自由に取得して、さらに改善していただいて構いません。Apache 2.0ライセンスにより 使用・変更・共有が可能ですので、フォークして独自のバージョンを作り、学んだことを共有してください。
私の好きな言葉は「分散化」です。私にとってそれは、コミュニティベースの共有と サポート、つまり既にあるものをみんなで一緒に改善していくことを意味します。これが趣味の再実装（リバースエンジニアリング）や LLM開発に新しいアイデアをもたらすことを願っています。
Apache License 2.0。LICENSE と NOTICE を参照してください。
Copyright 2026 Ryu116（別名 HappyTotoro116）