11

objdump-dの呼び出しによって返されるアセンブリ結果の制御フローグラフを作成しようとしています。現在、私が思いついた最善の方法は、結果の各行をリンクリストに入れ、各行のメモリアドレス、オペコード、およびオペランドを分離することです。objdumpの結果の通常の性質に依存してそれらを分離しています(メモリアドレスは、各行を表す文字列の文字2から文字7までです)。

これが完了したら、実際のCFG命令を開始します。CFGの各ノードは、開始メモリアドレスと終了メモリアドレス、前の基本ブロックへのポインタ、および任意の子基本ブロックへのポインタを保持します。次に、objdumpの結果を調べて、オペコードをx86_64内のすべての制御フローオペコードの配列と比較します。オペコードが制御フローのものである場合、基本ブロックの終わりとしてアドレスを記録し、オペコードに応じて、2つの子ポインター(条件付きオペコード)または1つ(呼び出しまたは戻り)を追加します。

私はこれをCで実装している最中であり、動作するように見えますが、非常に希薄な感じがします。誰か提案、または私が考慮していない何かがありますか?

これを読んでくれてありがとう!

編集:

これを使用して、DynamoRIOによって生成されたシステムコールのスタックトレースを、ターゲットバイナリの予想されるCFGと比較するという考え方です。このように構築することで、それが容易になることを願っています。利用可能なものを再利用していません。A)実際にはそれについては理解していなかったため、B)パス比較を実行できるように、グラフを使用可能なデータ構造にする必要があるためです。私を正しい方向に向けてくれてありがとう、あなたが並べたページのユーティリティのいくつかを見ていきます。コメントありがとうございます、本当に感謝しています!

4

2 に答える 2

5

プログラム分析用に設計された IL を使用する必要があります。いくつかあります。

DynInst プロジェクト (dyninst.org) には、関数/プログラムの ELF バイナリから CFG に変換できるリフターがあります (または、最後に見たときはそうでした)。DynInst は C++ で書かれています。

BinNavi は、IDA (Interactive Disassemblyr) からの出力を使用して、IDA が識別する制御フロー グラフから IL を構築します。また、IDA のコピーをお勧めします。これにより、CFG を視覚的にスポット チェックできます。BinNavi にプログラムを作成すると、関数/CFG の IL 表現を取得できます。

関数ポインターは、制御フロー グラフを静的に識別するための問題の始まりにすぎません。ジャンプ テーブル (特定のケースでは switch case ステートメント用に生成され、他のケースでは手動で生成される種類) も同様に厄介です。私が知っているすべてのコード分析フレームワークは、非常にヒューリスティックを多用したアプローチでそれらを扱っています。次に、例外と例外処理、および自己変更コードがあります。

幸運を!DynamoRIO トレースからすでに多くの情報を取得しています。そのトレースからできる限り多くの情報を利用することをお勧めします...

于 2011-09-13T05:10:12.950 に答える
1

同じものを探すことに興味があったので、あなたの質問を見つけました。私は何も見つけられず、これのための簡単な python スクリプトを書き、それを github に投げました: https://github.com/zestrada/playground/blob/master/objdump_cfg/objdump_to_cfg.py

返されない関数、32 ビット x86 の gcc スタック プロテクターなどを処理するためのヒューリスティックがあることに注意してください。

私は間接呼び出しをあなたと同じように扱います (基本的に、間接呼び出しから戻るときのソースであるグラフにノードがあります)。

これが、同様の制限で同様の分析を行うことを検討しているすべての人にとって役立つことを願っています。

于 2015-11-01T23:01:44.080 に答える