Ghostrings

P-Code 解析を使用して Go バイナリの文字列定義を復元するスクリプト群です。 x86、x86-64、ARM、ARM64 でテストされています。

スクリプト

Golang

これらはスクリプトマネージャーの Golang カテゴリにあります。

GoDynamicStrings.java
- P-Code を解析して、スタック上に作成された文字列構造を見つけます。低レベルの "register" スタイルの解析を使用します。
GoFuncCallStrings.java
- P-Code を解析して、スタックに書き込まれずにレジスタ経由で関数呼び出しに直接渡される文字列構造を見つけます。Ghidra の新しい組み込み Golang サポートを使用した "normalize" スタイルの解析を使用します（対応する Golang バージョンについては Ghidra のリリースノートを参照してください）。
GoStaticStrings.java
- 読み取り専用メモリに静的に割り当てられた Go 文字列構造を見つけます。
GoKnownStrings.java
- 標準的な固有文字列を検索して定義します。文字列データは data/known_strings.json から読み込まれます。
GoStringFiller.java
- 初期解析後に、文字列データの長さの昇順に基づいて go.string.* のギャップを埋めます。

ダイナミック文字列解析スクリプトには、特別なバリエーションがいくつかあります:

GoDynamicStringsSingle.java
- GoDynamicStrings.java と同じ解析を実行しますが、単一のデコンパイラプロセスを使用します。バイナリの解析により並列デコンパイラプロセスがシステムメモリを使い果たす場合は、これを使用してください。
GoDynamicStringsHigh.java
- 実験的。高レベルの "normalize" スタイル解析からの P-Code 出力を使用します。現在は、デコンパイラのデッドコード除去を無効にするハックに依存しています（https://research.nccgroup.com/2022/05/20/earlyremoval-in-the-conservatory-with-the-wrench/ を参照）。このハックは Ghidra 10.2 では機能しません。

P-Code

これはスクリプトマネージャーの PCode カテゴリにあります。

PrintHighPCode.java
- 現在選択されている関数の高レベル P-Code 出力を、使用するデコンパイラ簡略化スタイルのセレクタ付きでコンソールに出力します。主に P-Code 解析スクリプトの開発に使用されます。

文字列復元の流れ

これらのスクリプトを使用して Go バイナリの文字列定義を復元する一般的な流れは次のとおりです:

読み取り専用データメモリブロック内の、誤った、または自動的に定義された文字列をすべてクリアします。
- "Defined Strings" ウィンドウで "Mem Block" 列を有効にし、メモリブロックでフィルタリングして .rodata、.rdata、__rodata 内のすべての文字列を選択します。次に、コードリストで右クリックして "Clear Code Bytes" を選択します。
(任意) GoKnownStrings.java を実行して、標準的な文字列をいくつか検出します。
GoStaticStrings.java を実行します。
GoFuncCallStrings.java を実行します (Golang バイナリのバージョンが Ghidra の組み込み Golang 機能でサポートされている場合)。
GoDynamicStrings.java を実行します。
GoStringFiller.java を実行します。
- 文字列データの長さの昇順の違反を検出した場合は、その領域の誤検知の文字列定義をクリアしてスクリプトを再実行します。これを自動的に行うオプションがあります。
- バイナリがストリップされている場合は、ダイナミック文字列スクリプトで見つかった 1 バイト文字列の領域を特定します。それがグループ化された非 null 終端文字列の先頭であることを確認します（その後ろで、長さが昇順の文字列がさらに定義されるはずです）。最初の 1 バイト文字列に go.string.* ラベルを作成します。
go.string.* に残っているギャップを確認し、明らかな開始点と終了点を持つ文字列を定義します。
- GoStringFiller.java を最大限に活用するには、未定義の文字列データ内で文字列の長さが変わる箇所を特定し、その境界に最も近い文字列を定義します。その後、を再実行すると、残りの未定義文字列の長さを正しく判定できる箇所が自動的に埋められます。

セットアップ

インストール

Ghidra で:

File -> Install Extensions -> Add extension
拡張機能の ZIP ファイルを選択します

開発

GhidraDev プラグインを使用した Eclipse の場合:

リポジトリをクローンします
File -> Import -> Projects from Folder or Archive
リポジトリのディレクトリを選択します
GhidraDev -> Link Ghidra...
インポートしたプロジェクトを選択します

ビルド

Eclipse でビルド:

GhidraDev -> Export -> Ghidra Module Extension...

Gradle で直接ビルド:

$ cd Ghostrings
$ gradle -PGHIDRA_INSTALL_DIR=<ghidra_install_dir>

背景

Go プログラムのリバースエンジニアリングにおけるよく知られた問題として、Go 文字列には null 終端文字がないため、コンパイルされたバイナリから文字列定義を復元することが困難であることが挙げられます。Go プログラムの定数文字列値の多くは、コンパイルされたビルド内の 1 つの巨大なブロブにまとめて格納されており、ある文字列が終わり、別の文字列が始まる位置を示す終端文字は文字列データに組み込まれていません。"Hello world!" と出力するだけの単純なプログラムでさえ、Go ランタイムシステムやその他の標準ライブラリに関連する 1,500 を超える文字列が含まれています。このため、Ghidra が提供するような典型的な ASCII 文字列検出実装では、数万文字に及ぶ誤検知の文字列定義が作成される可能性があります。

Go は null 終端文字列の代わりに、ポインタと長さの値で構成される文字列構造を使用します。これらの文字列構造の多くは実行時にプログラムのスタック上に作成されるため、個々の文字列の開始位置と長さの値を復元するには、コンパイルされたマシンコードの解析が必要です。この解析を x86-64 命令の特定のパターンをチェックして実行する既存のスクリプトがいくつかありますが、それらは最終的にスタックに対して同じ効果を持つ未処理の命令バリエーションで作成された構造を見逃し、さらに特定の ISA に限定されています。

Ghostrings は、Ghidra のデコンパイラ解析によって生成される、アーキテクチャに依存しない簡略化された P-Code オペレーションを利用することで、これらの問題を両方とも回避します。

リリース情報

プロジェクトの主著者: James Chambers [email protected]

ghostrings

人気