エミュレーションによる正確かつスケーラブルなクロスアーキテクチャ、クロス OS バイナリ コード検索 [東証 2018]
yingxing xue、中国科学技術大学
Zhengzi Xu、南洋理工大学
Mahinthan Chandramohan、南洋理工大学
Yang Liu、南洋理工大学
ソース コードのクローン検出とは異なり、バイナリ実行可能ファイルでのクローン検出 (コード検索と同様) は、コンパイラ、アーキテクチャ、オペレーティング システムの構成の違いによりバイナリ コードの構文と構造が大きく異なるため、大きな課題に直面します。既存の研究では、CFG 構造、CFG 内の N グラム、入出力値などを含む、バイナリ コード クローンを検出するためのさまざまなタイプの特徴が提案されています。私たちの以前の研究とツール BINGO では、コンパイル シナリオの違いによる CFG 構造の大きな違いを軽減するために、依存ライブラリとユーザー定義関数のセマンティクスをインライン化することで完全な関数をキャプチャする選択的インライン化手法を提案しました。ただし、BINGO では入出力値の特性のみが考慮されます。この研究では、異なるクラスの特徴 (例: 構造的特徴と高レベルの意味的特徴) を組み合わせて精度を向上させ、シミュレーションを通じて効率を向上させることを提案します。私たちは、当社のツール BINGO-e の検索精度とパフォーマンスの違いを、以前のツール BINGO および利用可能な最先端のバイナリ コード検索ツールと経験的に比較しました。結果は、BINGO-e が、アーキテクチャ間マッチング、オペレーティング システム間マッチング、コンパイラー間マッチング、およびコンパイラー内マッチングの点で BINGO よりも大幅に正確であることを示しています。さらに、BINGO-E は、フォークされたプロジェクトのバイナリを照合するという新しいタスクにおいて、既存のベンチマークよりも高い精度を示しています。同時に、BINGO-e アルゴリズムは、BINGO アルゴリズムよりもマッチング プロセスにかかる時間が短くなります。
一言で言えば - BinGo-E: さまざまなカテゴリの機能を組み合わせて BinGo の精度を向上させ、シミュレーションを適用して実行効率を向上させます。
(この論文は BinGo の拡張です。イノベーションには主に 3D-CFG 法の適用が含まれます。エミュレーションは動的な低レベルの意味特徴を抽出し、静的な高レベルの意味特徴と静的な低レベルの意味特徴を追加します。残りは大まかに言うとBinGo と一致します。別のブログ共有を参照できます。
序章
バックグラウンド
GPL に基づくソフトウェアを使用すると、新しいソフトウェア (商用のオープンソース プロジェクトやオープン ソフトウェア ブームでも) 既存の関連プロジェクトのコードを再利用できます。ただし、既存のコードを頻繁に再利用すると、いくつかの法的およびセキュリティ上の問題が発生する可能性があります。レポート「gplviolations.org」[1] によると、ソフトウェア製品で GNU Public License の 200 以上の違反が発見されました。その中でも、VMWARE は GPL 違反で訴訟に直面している有名なソフトウェア サプライヤーです。同時に、コードの再利用は、再利用されたプロジェクトで公開された脆弱性が、未公開の脆弱性の形で新しい商用製品に伝播する可能性があるというリスクをもたらします。たとえば、2014 年 12 月には、ネットワーク タイム プロトコル (NTP) ntpd 実装の脆弱性が、Linux ディストリビューション、Cisco の 5900x、Apple の OSX スイッチなど、このプロトコルをインポートする製品に影響を与えました。
バイナリ コード検索により、実行可能ファイルまたはライブラリのソース コードが利用できない場合、GPL 違反の検出、ソフトウェア盗用の検出、リバース エンジニアリング、セマンティック リカバリ、マルウェアの検出、個々のソフトウェア コンポーネントの脆弱性 (脆弱) コードの特定などのタスクが容易になります。ただし、バイナリ コードの検索は、プラットフォーム、アーキテクチャ、コンパイル オプションによって生じる構文のギャップにより、ソース コードの検索よりも根本的に困難な問題です。
ソース コード検索では、2 つのコード セグメントの類似性は、トークン [12]、抽象構文ツリー (AST) [13]、制御フロー グラフ (CFG) [14] など、ソース コードの何らかの表現に基づいて測定されます。またはプログラム依存関係グラフ (PDG) [15] の方法。これらの表現はすべて、プログラムの構文または構造情報をキャプチャし、ソース コード検索の正確な結果を生成します。ただし、これらのメソッドをバイナリ コード検索に適用すると失敗します。その理由は、アーキテクチャ、プラットフォーム、またはコンパイル オプションの選択により、同じソース コードが異なる構造のアセンブリ コードにコンパイルされる可能性があるためです。したがって、構文情報や構造情報だけではバイナリ コードを正確に検索するのに十分ではありません。
実際、バイナリ コード クローン検索は、同じアーキテクチャとプラットフォームの 2 つの類似したプロジェクトでバイナリ コード クローンを見つけるという一般的なバイナリ コード クローン検索の問題よりも複雑です。多くの場合、クロスアーキテクチャおよびクロス OS である必要があります。有名なオープンソース プロジェクト (libXML2 など) に重大なバグのあるコードが含まれていると報告されていると仮定すると、さまざまなアーキテクチャやプラットフォーム コードでプロジェクトを再利用できる、対応するアプリケーションのバグのあるバイナリを見つける必要があります。上記の問題に対処するために、正確でスケーラブルなクロスアーキテクチャおよびクロス OS バイナリ コード検索ツールの 3 つの望ましい特性を提案します。
- P1 は、コンパイラ、アーキテクチャ、オペレーティング システムの異なる構成によって生じる構文や構造の違いに対する耐性があります。
- P2 は抽象化と完全な関数セマンティクスを正確に捉え、コンパイラの最適化レベルの影響のバランスをとります。
- P3 は、実際の大規模なバイナリにスケールし、動的な実行や制約解決に基づく分析のオーバーヘッドを回避します。
表 1 に、文献に記載されている最先端のバイナリ コード検索ツールを示します。これらのツールのうち、BLEX [20] だけが、実行によって生成される 7 つの意味特徴を使用する動的関数マッチング ツールです。他のすべてのツールは静的分析を採用しているため、P1 と P2 の問題が発生します。TRACY [10] は、関数マッチングに純粋な構文情報を使用します。これは、アーキテクチャおよび OS に依存する k-tracelets (つまり、制御フロー パスに沿った長さ k の基本ブロック) を使用します。Discover [21] は、バイナリ内のアーキテクチャにまたがるバグを見つけるためのスケーラブルな方法を提案しています。この方法では、2 つのフィルター (数値フィルターと構造フィルター) を使用して、ターゲット関数の類似した候補を迅速に見つけます。COP [4] は、意味的に同等のコード セグメントを検索する定理証明を使用する盗作検出ツールです。[9] で提案されているバグ検索ツールは、バイナリ コードを中間表現に変換し、入力変数と出力変数の代入式を解くことにより、クロスアーキテクチャ分析をサポートします。ESH [22] は、画像構成における類似性のアイデアに触発され、各プロセスを小さなコード セグメント (いわゆるチェーン) に分解し、チェーンを意味論的に比較して類似性を判断し、その結果をプロセスとして推進することを提案しています。
バイナリ コード クローンを照合するには、2 つの基本的なアプローチが取られます。1 つ目は、IDA PRO [28]、DYNINST [29]、ANGR [30] などのツールを使用した静的分析です。これらのツールを使用すると、バイナリ プログラムでバイナリ関数の制御フロー グラフ (CFG) を構築できます。二値関数の類似度に基づいて、2 つの二値関数の類似度が測定されます。最近、Android でのバイトコード クローン作成に適合するために、3D-CFG の概念が [31] で提案されました。3D-CFG は、その名前が示すように、関数の CFG を 3D 座標系に投影することです。従来、CFG の類似性はグラフ マッチングまたはグラフ同型性によって測定されます。3D-CFG では、各機能は 3 次元座標系のオブジェクトとして考慮され、2 つの機能の類似性は、2 つの機能をそれぞれ表す 2 つのオブジェクトの重心間の距離によって測定されます。もう 1 つのアプローチは、動的解析に計測ツールまたはシミュレーション ツールを使用することです。これらのツールの中で最も基本的なのは、ハードウェア仮想化を実行するための無料のオープンソースのマネージド ハイパーバイザーである QEMU [32] です。QEMU はコンピュータのほとんどの機能をエミュレートできます。最新のエミュレータの多くは QEMU 上に拡張されています。これらの拡張機能のうち、UNICORN [27] は軽量のマルチプラットフォーム、マルチアーキテクチャの CPU シミュレーターです。ジャストインタイム コンパイラ テクノロジを使用することにより、パフォーマンスが向上し、さまざまなレベルのきめ細かいインストルメンテーションをサポートします。UNICORN を使用してバイナリ関数を実行すると、2 つのバイナリ コード セグメントの I/O 値を比較することで、2 つのバイナリ コード セグメントのマッチングを簡素化できます。
モチベーション
いくつかの実世界のバイナリ [23] に関する以前の評価では、BINGO は、同じタスクの検索精度とパフォーマンスの点で、既存の最先端ツール (つまり、TRACY [10] および BINDIFF [24]) を上回っています。ただし、BINGO を使用すると誤検知 (FP) が発生する例がいくつか見つかりました。関数に小さなアセンブリ命令が含まれている場合、その関数から抽出された低レベルのセマンティクス機能は汎用的すぎて、実際のセマンティクスを含めることができない可能性があります。たとえば、図 2 は、同一の入力/出力値による BINGO の誤検知のケースを示しています。
FP のケースに対処するために、ツール BINGO-E の新しいバージョンは、高度なセマンティック機能と構造機能をサポートしています。私たちが使用する高レベルのセマンティック機能は、システム コールまたはライブラリ コールの情報ですが、一方で、CFG を 3D 座標の重心に投影することに基づく高速バイトコード クローン検出のアイデアを借用しています [26]。この方法 (3D-CFG、[26] と呼ばれる) に触発されて、グラフ同型問題は重心間の距離を計算する問題に帰着します。BINGO-E で実装される 3D-CFG は、基本ブロック (BB) シーケンス、サイクル情報、および BB のイン/アウト次数の構造情報を採用します。
このプロセスを高速化するために、BINGO-E は、低レベルの意味特徴を抽出するときに使用される制約解決ではなく、シミュレーションを利用します。我々は、軽量のマルチプラットフォーム、マルチアーキテクチャの CPU エミュレータ フレームワークである UNICORN [27] を使用して、特定の関数の機能モデルから抽出された部分トレースを仮想的に実行します。シミュレーション ステップは、制約を解決するよりも大幅に時間がかかります。UNICORN [27] を統合する際の課題は、関数呼び出しのハンドルです。最後に、構造、低レベルのセマンティクス、および高レベルのセマンティクスに関する 2 つの関数の類似性スコアが最終的なマッチングのために結合されます。
貢献
(1) シミュレーションとクロスアーキテクチャ、クロスOSバイナリコード検索を組み合わせる初の試み
(2) セントロイドクローン検出の考え方に基づいて構造特徴を抽出。以前は、3D-CFG ベースのマッチングは主に、表 1 にリストされているさまざまなカテゴリの特徴を組み合わせたバイトコード クローン検出
(3) に適用されていました。提案手法は、アーキテクチャ間マッチング、オペレーティング システム間マッチング、およびコンパイラ間マッチングのシナリオで評価されます
(4)。BINGO-E は、BINGO および利用可能な最先端のバイナリ コード検索ツールと実験的に比較されます。検索の精度とパフォーマンスの観点から。
BINGO-Eの有効性を評価するために、さまざまな実験を行っています。coreutils バイナリのクロスアーキテクチャ マッチングでは、平均して、BINGO-E が BINGO (35.1%) よりも大幅に優れた最良のマッチング率 (65.6%) を達成しています。coreutils バイナリでのクロスコンパイラ マッチングおよびコンパイラ固有のマッチングでは、平均して、最適一致率が 30 ～ 60% の範囲 (BINGO) から 70 ～ 99% の範囲 (BINGO-e) に向上しました。Windows バイナリ mscvrt と Linux バイナリ libc での OS 間マッチングでは、平均して、最良のマッチング率が 22% (BINGO) から 51.7% (BINGO-E) に向上しました。フォークされたプロジェクトのバイナリ コード マッチングに関する追加の実験では、BINGO-E は既存のベンチマーク ツールの最適一致率 (88%) よりも高い最適一致率 (93.6%) を達成しました。最後に、シミュレーションを通じて、基礎となるセマンティック特徴抽出の最も時間のかかる部分が大幅に高速化されるため、より多くの特徴を導入して精度を向上させることができます。
方法
概要
BINGO の新しい拡張機能である BINGO-E は、正確で拡張可能なバイナリ コード検索エンジンを目指しています。一致するバイナリ関数 (検索のシグネチャ関数) が与えられると、BinGo-E は、分析されたバイナリ関数 (検索のターゲット関数) のプールから、意味論的な類似性に基づいてランク付けされた関数を返します。
BINGO-E のワークフローを図 3 に示します。入力は、署名関数としてのバイナリ関数と、可能なターゲットとしての候補関数のセットです。出力は、ユーザー定義の類似性スコアしきい値を超える候補目的関数のランク付けされたリストです。最初のステップでは、署名関数が与えられると、前処理、つまり署名関数の CFG の分解と構築が実行されます。ステップ 2 では、これらの特徴が表 2 の高レベルの意味論的情報および構造情報から抽出されます。表 2 に示すように、6 つの高レベルの意味特徴と 3D-CFG 構造特徴を抽出します。3 番目のステップでは、高レベルの意味的特徴の Jaccard 距離と構造的特徴の重心距離に基づいて、主要なマッチング ステップが実行され、類似性が測定されます。類似性のしきい値を超える結果がない場合、プロセスは低レベルの意味特徴の比較を続行します。ステップ 3 が返されない場合は、マッチングの第 2 フェーズが始まります。ステップ 4 では、ターゲット バイナリ内の関数ごとに関数呼び出しが識別され、呼び出されたライブラリやその他のユーザー定義関数への依存関係に基づいて選択的にインライン化されます。ステップ 5 では、署名特徴、長さ可変部分トレースレット (k-トレースレット) が生成され、グループ化されて特徴モデルが形成され、そこから基礎となる意味論的特徴が抽出されます。機能モデルの生成と特徴抽出は 1 回限りのジョブであることに注意してください。ステップ 6 では、シミュレーションに依存して、入出力値、フラグ、符号付き関数のメモリ アドレスを低レベルの意味論的特徴として取得します。最後に、ステップ 7 で、Jaccard 距離の低レベルの意味論的特徴と一次マッチングの結果を組み合わせて、BINGO-E は類似性しきい値を超える目的関数をソートされた順序で返します。まとめると、図 3 の BINGO-E では、ステップ 2、3、6、7 が新たに導入されています。
バイナリコードマッチング機能
このセクションでは、2 つのバイナリ コード セグメントの類似性を測定するために使用される特徴について詳しく説明します。表 2 に示すように、これらの特性は 3 つのカテゴリに分類されます。表 2 の各機能について、次のセクションで例と説明を示します。構造的特徴と高レベルの意味的特徴は、ステップ 2 の機能である静的解析によって抽出されます。最後のステップは、シミュレートされた実行で低レベルのセマンティック特徴を取得することです。
3D-CFGの考え方はもともとAndroidのバイトコードマッチングで使われていたもので、そのアイデアの核心はメソッドのコントロールフローグラフ(CFG)の各ノード(基本ブロック)に構造的な3次元座標値を割り当てることで、次に、これらの座標の質量重心をメソッドの重心として計算します。2 つの方法間の類似性は、重心間の距離を計算することで測定できます。
重みｗは基本ブロックの命令数であり、重み付けされた重みｗ'はｗ＋Ｎとなる（Ｎは関数呼び出し命令の数）。
重心の差
関数 f のシグネチャは 2 つの重心で表されます。1 つは通常の重心で、もう 1 つは関数呼び出しの重み付けされた重心です。2 つの関数が与えられた場合、関数の差は
それらの重心距離 (CDD) と重み付き重心として定義されます。間の距離 (重み付け) の最大値
3D-CFG をバイナリ コード検索に適用する際の課題は、バイナリ コード用の正確な CFG を構築するという課題と複雑さにあることに注意してください [39]。一般に、バイナリ コードよりも Java バイトコードを逆コンパイルする方が簡単です。したがって、3D-CFGの精度をさらに向上させるためには、正確なループ（間接呼び出しループジャンプ）構造をどのように取得するか、データとコードをどのように区別するかという問題も解決する必要がある。これらの問題は、この記事の範囲外です。
低レベルのセマンティック機能
BINGO-Eで新たに追加された機能
前述したように、レジスタの入出力値をアーキテクチャをまたがるコード検索に直接使用することはできません。シミュレーションのおかげで、BINGO-E は、関数パラメーターと関数で使用される中間値の特性を抽出する際に、より高速かつ便利になりました。したがって、低レベルの意味特徴の精度をさらに向上させるために、BLEX [20] でも使用されている次の中間値特徴を組み込むことを提案します。
アドレス解析の基本的な考え方は次のとおりです。シミュレーションの前に、スタックの開始アドレス (ebp) が特定の 16 進値であると仮定します。次に、シミュレーションでは、各命令の実行後にスタックの終了アドレス (esp) を追跡し続けます。オペレーションが ebp と esp の間のアドレスにある場合、そのオペレーションがスタック上にある (「v3」または「v4」に属する) ことがわかります。それ以外の場合は、ヒープ (「v1」または「v2」に属する) 上の操作として処理されます。ただし、まれに命令がグローバル スタック (グローバル変数のスタック) 上で動作する場合があります。シミュレーションでは、これらの非ヒープ アドレスをさらに区別することは困難であるため、これらのアドレスのみをヒープ アドレスとして扱います。
エミュレーション
シミュレーションは実際の実行よりも高速であり、制約解決よりもはるかに高速です。BINGO-Eでは固有値の抽出にシミュレーションを利用します。2 つのコードセグメントが与えられた場合、それらは同じ初期メモリ状態 (つまり、同じアドレスとレイアウト) を持っていると仮定します。同じアーキテクチャ上のコードのマッチングの場合は、レジスタの値、シミュレーション後のフラグ、シミュレーション中のスタックとヒープ上の読み取りおよび書き込み操作のアドレスをチェックしますが、アーキテクチャ間のコードのマッチングの場合は、シミュレーション後のフラグ、値、およびシミュレーション中のスタックおよびヒープ上の読み取り/書き込み操作のアドレスをチェックします。たとえば、図 6 の 3 つのコード セグメントでは、初期メモリ状態が同じで、最終メモリ状態も同じになります。オーバーフロー フラグ (V フラグ) は 0、ゼロ フラグ (Z フラグ) は 1、ネガティブフラグ (N フラグ) は 0 であり、キャリーフラグ (C フラグ) は一致しています。図 6a と図 6b のコード セグメントは同じアーキテクチャ上でコード照合されているため、レジスタ eax と ebx の結果値も同じになります。また、この場合、プログラム ヒープ/スタックから値を読み書きするために低レベルの機能を使用します。たとえば、0x1100 はスタックに書き込まれる中間値です。
シミュレーション部分における主な技術的課題は、1) 関数呼び出しの処理、2) レジスタ、フラグ、メモリ アドレスの入力または初期値の選択です。偽装は選択的インライン化と競合しないことに注意してください。エミュレーション ステップは選択的インライン化ステップの後に行われるため、多くの重要な関数呼び出し (システム コールやライブラリ呼び出しなど) がインライン化されます。インライン化対象として選択されていない関数呼び出しについては、さまざまなシナリオに応じて 2 つの異なる戦略を採用します。
(1) 同じコード ベースのバイナリを照合する場合、インラインなし戦略を採用します。つまり、どの関数もインライン化されません。論理的根拠は 2 つあります: 選択的インライン化によってインライン化されていない関数は、プログラムのセマンティクスを表す可能性が低く (ユーティリティ関数である可能性が高くなります)、シグネチャ関数とターゲット関数の両方が関数を呼び出しているためです (コードが同じであるため)。ライブラリ)、同じ入力に対して、呼び出された関数を無視しても、セマンティック クローン作成では同じ結果が生成されるはずです。
(2) 異なるコード ベースのバイナリ コードを一致させる場合、すべてをインライン化する戦略を採用します。つまり、呼び出されるすべての関数が命令の実行をシミュレートするためにインライン化されます。その理由は、異なるコード ベースからコンパイルされたバイナリ セグメントは、異なる syscall またはライブラリ呼び出しを呼び出すことが多いためです。これらを無視すると、たとえ 2 つのバイナリ セグメントがセマンティック クローンであっても、エラーが発生し、同じ入力に対して異なる結果が生じます。
シミュレートされた入力では、3 つの完全に異なる入力値を使用する戦略を採用します。シミュレーションで照合する 2 つのバイナリ関数には、すべての値が 0x0000、すべての値が 0x1111、すべての値がランダム値の 3 種類の入力を提供します。2 つのバイナリ セグメントが 3 種類すべての入力の低レベルの意味特徴と一致する場合、一致するとみなします。
実験
堅牢性
図 10 は、coreutils バイナリの平均結果 (選択的インライン展開の前後) をまとめたもので、上位にランク付けされた関数 (つまり、最も一致する関数) の割合を報告しています。図では、バー G64 ～ G32 (インライン化後) は、x86 の場合、gcc を使用して関数がコンパイルされるときに、64 ビット アーキテクチャが署名として使用されると解釈されます。x86 の場合、gcc を使用してコンパイルされた関数の約 55% が署名として使用されます。 32 ビット アーキテクチャがランク 1 に到達します。ARM バイナリ関数をシグネチャとして使用すると、全体の結果が大幅に低下することがわかります。x86 32 ビットおよび 64 ビット アーキテクチャでは約 41% であるのに対し、1 位にランクされる関数はわずか 18% です。また、ARM と x86 64 ビット バイナリの間の (インライン化後の) マッチングにより、ARM と x86 32 ビット バイナリよりも高いランキングが得られることにも注目します。その根拠は、ARM および x86 64 ビット バイナリは、x86 32 ビット バイナリに比べてレジスタを大量に使用するためです。ARM および x86 64 ビット アーキテクチャには 16 個の汎用レジスタがあるため、x86 32 ビット バイナリよりもレジスタが使用されます。多くの場合、後者には 8 しかありません。
図 11 は、coreutils バイナリでの選択的インライン化後の BINGO と BINGO-e の平均結果を示しています。上位にランク付けされた関数 (つまり、同じソース コードからバイナリ関数をマッピングする場合の最良の一致) の割合のみを計算することに注意してください。図 11 に、クロスアーキテクチャ コード マッチングで考えられる 16 のシナリオを示します。
表 4 は、x86 32 ビット アーキテクチャのさまざまなコンパイラ (gcc および Clang) およびさまざまな最適化レベル (O0、O1、O2、および O3) について BINGO によって得られた結果をまとめたものです。ここで、表の各行と各列は、それぞれ署名関数とターゲット関数をコンパイルするために使用されるコンパイラー (最適化レベルを含む) を表します。たとえば、2 行目の 5 列目 (C1G0) で表されるセルは、シグネチャ関数を最適化レベル O1 の Clang でコンパイルした結果と、ターゲット関数を最適化レベル O0 の gcc でコンパイルした結果を示します。表から、関数の 41.5% がランク 1 (x86 32 ビット用にコンパイルされたすべてのバイナリ実験の平均) を達成しており、上位 10 ヒットの中でこれは 84% に増加しており、非常に有望であることがわかります。 。
表 6 は、x86 32 ビット アーキテクチャの coreutils でさまざまなコンパイラ (gcc および Clang) およびさまざまな最適化レベル (O0、O1、O2、および O3) に対して bino-e によって得られた結果をまとめたものです。行は署名関数の最適化レベルを表し、列は目的関数の最適化レベルを表します。一般に O1 または O2 が最も効果的であることがわかりました。O3 を使用すると、gcc と Clang の両方で最悪の結果が得られます (80% 未満)。C2 から G1 へ、または G2 から C1 へでも 88% 以上の精度を達成できます。したがって、コンパイラ間のマッチングでは、コンパイラの違いの影響は最適化レベルの影響ほど重要ではないことがわかります。
最先端のツールとの比較。BINGO-E を最先端のツールと比較するために、業界標準のバイナリ比較ツール BINDIFF6 と公的に入手可能な学術ツール TRACY [10] を使用して上記の実験を繰り返します。BINDIFF (v4.1.0) は、mcvcrt の表 8 および表 9 の関数を libc の対応する関数と正しく一致させることができません。その失敗は、プログラム構造と呼び出しグラフ パターンに大きく依存していることが原因であり、まったく異なるソース コード ベースからコンパイルされたバイナリには保存される可能性が低いです。TRACY の場合、最初の 50 個の位置のうち、正しく一致した関数は 27 個だけでした。
アプリケーション
BINGO-E を適用して、同じまたは類似のコードベースを共有する可能性のある 2 つのプロジェクト間のコードの盗用を検出します。この実験では、CoP [4] で使用したものと同じターゲット プロジェクト、つまり thttpd-2.25b および sthttpd-2.26.4 を採用しました。sthttpd はメンテナンスのために thttpd からフォークされました。
表 10 は、署名関数として thttpd、ターゲット関数として sthttpd を使用したマッチング結果を示し、表 11 は逆マッチング結果を示します。表 10 および表 11 では、行は署名関数のコンパイルに使用されるコンパイラ (最適化レベルを含む) を示し、列はターゲット関数のコンパイルに使用されるコンパイラを示します。
2 つのテーブルの結果はかなり一貫しています。理由は 2 つあります: a) thttpd と sthttpd の関数は完全に複製されており、そのほとんどが同一です; b) BINGO-E の結果は対称であるため、一致する場合に署名関数とターゲット関数の結果が逆転します。違い。
同じ最適化レベルでは、2 つのプロジェクトの機能はエラーなく完全に一致します。この完璧な結果は、同じ最適化レベルによりバイナリ内で同じ BB 構造が得られるためです。
一般に、同じ最適化レベルを使用することを除けば、gcc G0 ～ G2 間の一致により最良の結果が得られました (結果は太字で示されています)。つまり、表 10 と表 11 では平均で 93.8% と 93.4% でした。
表 10 および表 11 の C2 から C3 または C3 から C2 の精度は 100% です。これは、clang-C2 と Clang-C3 の効果が類似していることを示しています。
表 12 は、2 つのバージョンの BusyBox での BINGO-E、TRACY、および BINDIFF の照合結果を示しています。まず、ソース (バージョン 1.20.0) のすべての関数をターゲット (バージョン 1.21) のすべての関数と照合します。3 つのツールのうち、最も類似した関数をチェックする際に BINDIFF が最高の精度を示し、1 位にランクされました。BINGO-E の精度は BINDIFF の精度よりわずかに低くなります。ただし、1 ～ 3 レベルと 1 ～ 10 レベルの精度も BINDIFF レベル 1 よりも高くなります。
スケーラビリティ
1 つのアーキテクチャ向けにコンパイルされた coreutils スイート全体 (合計 103 バイナリ、それぞれに平均 250 の関数が含まれる) を比較すると、クロスアーキテクチャ分析では平均 485.2 ミリ秒かかりますが、クロスコンパイラ分析では 404.6 ミリ秒に短縮されます。OS 間でマッチングする実験の場合、libc バイナリ全体と msvcrt の比較には 123.70 秒かかります。BusyBox (約 3250 関数、39179 基本ブロック) などの他の大きなバイナリの場合、すべての関数を並べ替えるのに 1307.92 秒かかります (関数ごとに 402.4 ミリ秒)。
BINGO-E の主なオーバーヘッドは、シミュレーションを使用して低レベルの意味論的特徴を抽出することです。たとえば、2611 個の libc 関数からセマンティック特徴を抽出するには 2334.4 秒かかります。実験では、ロバスト性を向上させるために 16 回のシミュレーションを実行しました。1 回だけ実行した場合、結果はあまり変わらないことがわかりました。同様に、1220 個の関数を含む msvcrt からセマンティック特徴を 787.96 秒で抽出できます。その他のオーバーヘッドとしては、msvcrt から 3D-CFG 機能を抽出するのに 334.73 秒かかりますが、他の高度なセマンティック機能の取得には約 147.67 秒かかります。実際には、特徴抽出プロセスは 1 回限りのジョブであり、簡単に並列化できます。
要約する
参考文献
[1] gpl-violations.org プロジェクト、[オンライン]。入手可能: http://gplviolations.org/、アクセス日: 2016 年 9 月 22 日
[4] L. Luo、J. Ming、D. Wu、P. Liu、および S. Zhu、「Semantics-based obfuscation-resilient」ソフトウェア盗作検出のためのアプリケーションとのバイナリ コード類似性比較」、Proc. 第22回ACM SIGSOFT Int. 症状 見つかった。ソフトウェア。Eng.、2014、pp. 389–400
[9] J. Pewny、B. Garmany、R. Gawlik、C. Rossow、および T. Holz、「バイナリ実行可能ファイルのクロスアーキテクチャ バグ検索」、Proc. IEEE 記号。『セキュリティ プライバシー』、2015 年、709 ～ 724 ページ。[オンライン]。利用可能: http://dx.doi.org/10.1109/SP.2015.49
[10] Y. David および E. Yahav、「実行可能ファイル内のトレースベースのコード検索」、Proc. ACM シグプラン会議 プログラム。言語の説明 実装、2014 年、アート。いいえ。37. [オンライン]。利用可能: http://doi.acm.org/10.1145/2594291.2594343
[12] T. Kamiya、S. Kusumoto、および K. Inoue、「CCfinder: 大規模ソース コード用の多言語トークンベースのコード クローン検出システム」 IEEEトランス。ソフトウェア。工学、vol. 28、いいえ。7、654–670ページ、2002年7月。[オンライン]。入手可能:http://doi.ieeecomputersociety.org/10.1109/TSE.2002.1019480
[13] L. Jiang、G. Misherghi、Z. Su、および S. Glondu、「DECKARD: コード クローンのスケーラブルで正確なツリーベースの検出」 」、Proc。第29回国際 会議 ソフトウェア。工学、2007 年、96 ～ 105 ページ。[オンライン]。利用可能:http://dx.doi.org/10.1109/ICSE.2007.30
[14] PPF Chan および CS Collberg、「CFG 比較アルゴリズムを評価する方法」、Proc. 第14回国際 会議 『Quality Software』、2014 年、95 ～ 104 ページ。[オンライン]。入手可能: http://dx.doi.org/10.1109/QSIC.2014.28
[15] M. Gabel、L. Jiang、および Z. Su、「セマンティック クローンのスケーラブルな検出」、Proc. 第30回国際 会議 ソフトウェア。工学、2008 年、321 ～ 330 ページ。[オンライン]。入手可能: http://doi.acm.org/10.1145/1368088.1368132
[20] M. Egele、M. Woo、P. Chapman、および D. Brumley、「ブランケット実行: プログラム バイナリと
コンポーネントの動的類似性テスト」手順 USENIX セキュリティ シンボル、2014 年、303 ～ 317 ページ。
[21] E. セバスチャン、Y. カレド、G.-P. Elmar、「DiscovRE: バイナリ コードのバグの効率的なクロスアーキテクチャ識別」、Proc. 23日のネット。配布します。システム。『セキュリティ シンプ』、2016 年、1 ～ 15 ページ。
[22] Y. David、N. Partush、および E. Yahav、「バイナリの統計的類似性」、Proc. 第37回ACM SIGPLAN会議 プログラム。言語の説明 『実装』、2016 年、266 ～ 280 ページ。[オンライン]。入手可能: http://doi.acm.org/10.1145/2908080.2908126
[23] M. Chandramohan、Y. Xue、Z. Xu、Y. Liu、CY Choo、HBK Tan、「Bingo: Cross-architecture Cross-OS」二分探索」、Proc. 第24回ACM SIGSOFT Int. 症状 見つかった。ソフトウェア。工学、2016、pp. 678 ～ 689 年。
[24] H. Flake、「実行可能オブジェクトの構造比較」、Proc. 「検出侵入マルウェア脆弱性評価」、GI SIG SIDAR ワークショップ、2004 年、161 ～ 173 ページ。[オンライン]。利用可能: http://subs.emis.de/LNI/Proceedings/Proceedings46/article2970.html
[26] K. Chen、P. Liu、および Y. Zhang、「Android マーケットでのアプリケーション クローンの検出で精度とスケーラビリティを同時に達成する」、Proc. 第36回国際 会議 ソフトウェア。Eng.、2014、175–186 ページ。[オンライン]。入手可能: http://doi.acm.org/10.1145/2568225.2568286
[27] Unicorn: 究極の CPU エミュレーター、[オンライン]。入手可能: http://www.unicorn-engine.org/、アクセス日: 2016 年 9 月 22 日。
[28] Interactive Disassembler Professional、[オンライン]。入手可能: https://www.hex-rays.com/products/ida/、アクセス日: 2017 年 11 月 2 日
[29] Dyninst for Program Binary Analysis and Instrumentation、[オンライン]。入手可能: https://github.com/dyninst、アクセス日:
2017 年 11 月 2 日
[30] Angr: バイナリを分析するための Python フレームワーク、[オンライン]。利用可能: https://angr.io/、アクセス日: 2017 年 11 月 2 日
[31] K. Chen、P. Liu、および Y. Zhang、「Android マーケットでのアプリケーション クローンの検出における精度とスケーラビリティの同時達成」、Proc. 第36回国際 会議 ソフトウェア。工学、2014 年、175 ～ 186 ページ。
[32] QEMU: 汎用のオープンソース マシン エミュレーターおよびバーチャライザー、[オンライン]。利用可能: https://www.qemu.org/、
アクセス日: 2017 年 11 月 2 日
洞察
(1) UniCorn を使用して、埋め込み用の取得関数の動的セマンティクスをシミュレートおよび実行できます
(2) 3D-CFG 手法は、バイトコード マッチングによって提案された手法です。関連する問題に関する文献を検索し、パフォーマンスを向上させるための新しい手法を学ぶことができます。そして効率性。