「求人募集中」

angrは巨大なプロジェクトで，保守するのは大変です． コミュニティに貢献し，願わくばフィードバックを得たいという思いから，私たちはここに，遠大なTODOリストを掲載します． 幅広い難易度の，すべてのスキルレベルに応じた課題が（きっと）あるはずです．

ドキュメンテーション

angrはさまざまな要素でドキュメント不足に悩まされています．私たちは必死にコミュニティの助けを求めています．

API

私たちはつねにドキュメンテーションに遅れを取っています． 私たちは現状のドキュメントに何が欠けているか把握するため，githubでissueをトラッキングしています：

  1. angr
  2. simuvex
  3. claripy
  4. cle
  5. pyvex

GitBook

本書にはいくらか核心部分の抜けがあります． 具体的には，下記の要素に改善の余地があります：

  1. あちこちに残されたTODOを完遂する．
  2. 実例のページを理にかなったやり方で整理する．いまのところ実例のほとんどは極めて冗長で，大部分をシンプルな表にまとめられれば，ページ数をいくらか削減できるかもしれない．

angr学習コース

angr初学者に向けた「コース」なるものの開発は，必ずや有益な取り組みとなることでしょう． これは，こちらの方向性に沿って実現されつつありますが，さらなる拡張が見込まれます．

回を重ねるごとに難易度が上昇し，段階的にangrの機能を学べるようなハンズオンが理想です．

既存研究の再実装

残念ながら，誰もがangrをベースに研究を進めているわけではありません． それらが改善されるまで，定期的に関連研究をangrの上に再実装し，フレームワークの一部として再利用できるようにしておかなければなりません． このセクションでは，angrで再実装する機が熟した関連研究の一部を示します．

動的シンボリック実行のための冗長な状態の検知 (Redundant State Detection for Dynamic Symbolic Execution)

Bugrara, et al.は，プログラムの冗長な状態を特定し，トリムすることで，シンボリック実行の速度を50倍，カバレッジを4%向上させる手法を提案しています． angrのExploration Techniquesにこの手法があると素敵です． 論文はこちら：http://nsl.cs.columbia.edu/projects/minestrone/papers/atc13-bugrara.pdf

ソフトウェアシステムのIn-Vivoマルチパス解析 (In-Vivo Multi-Path Analysis of Software Systems)

すべてのシステムコールについて記号値サマリ (symbolic summaries) を作成するのではなく，私たちはS2Eで提案された，必要なデータを具体値として扱い，OS自体にディスパッチする手法を利用できます． これにより，現在分析できるものよりはるか大規模なバイナリの集合に対してangrを適用できるようになるでしょう．

この手法はシステムコールに対して最も有用でしょうが，一度実装してしまえば，コードのどの箇所（すなわち，ライブラリ関数）にも自明に適用できます． どのライブラリ関数をこのように扱うか注意深く選べば，angrのスケーラビリティは大幅に向上するでしょう．

開発

開発に労力を要することを念頭に置いたいくつかのプロジェクトがあります．

angr-management

angrのGUIであるangr-managementには多大な伸びしろがあります．

これはangr-managementに欠けている要素の，網羅的ではないリストです：

  • IDA Proのナビゲーションツールバーのように，プログラムのメモリ空間の内容を示すツールバー．
  • テキストベースの逆アセンブル結果のビュー．
  • 変更可能なレジスタビュー，メモリビュー，ファイルファイルディスクリプタビューなどを含む，パス探索時におけるプログラム状態のよりよい詳細ビュー．
  • クロスリファレンスのためのGUI.

angrの機能を適切に可視化する手法はきっと有用です！

IDAプラグイン

angrの機能の多くはIDAにエクスポーズできます． たとえば，angrのデータ依存グラフはアノテーションを通じてIDAにエクスポーズできますし，難読化された値をシンボリック実行によって解決することもできます．

アーキテクチャサポートの追加

新しいアーキテクチャに対応すれば，angrはより有用なものとなるでしょう．それには，下記の作業を伴います：

  1. アーキテクチャの情報をarchinfoに追加する．
  2. IR変換処理をangr.Blockに追加する．
  3. IRパーサをsimuvexに追加する（おそらくはsimuvex.SimRunのさらなるサブクラスとして）．
  4. SimProcedures対応のために（システムコールを含む）呼び出し規約をsimuvex.SimCCに追加する．
  5. 初期化処理対応のためにangr.SimOSを追加・改変する．
  6. バイナリをロードするCLEバックエンドを作成する．バイナリがELFフォーマットであれば，CLE ELFバックエンドを拡張すればよい．

手順2および3は，アーキテクチャのネイティブコードからVEXへの変換器を書いて済ませることもできます．PyVEX構造体を出力するだけなら，Pythonで事足ります．

新しいアーキテクチャのアイデア

  • PIC, AVR, その他組み込みアーキテクチャ
  • SPARC（libVEXのSPARCサポートを準備中です）

新しいIRのアイデア

  • LLVM IR（に対応できれば，angrをバイナリ解析プラットフォームからプログラム解析プラットフォームへと拡張し，さまざまな機能を追加できるようになります！）
  • SOOT（そうするためにはメモリモデルの拡張が必要となりますが，angrがJavaコードを分析できない理由はありません）

環境サポート

私たちは，オペレーティングシステム（すなわち，そのシステムコールによる影響）とライブラリ関数の環境をモデル化するため，「機能の概要」というコンセプトを採用しています． この拡張は，angrのユーティリティを発展させる大きな助けとなるでしょう． 機能の概要についてはこちらを参照のこと．

機能の概要の具体的なサブセットはシステムコールを単位としています． SimProduresのライブラリ関数（これがなくともangrは実際の関数を実行可能です）もさることながら，私たちは未実装のシステムコールを回避する策を少ししか持ち合わせていません． システムコールの実装次第で，angrの扱えるバイナリの幅が広がります！

設計上の課題

angrへの追加機能の統合に関する，いくつかの目立った設計上の課題があります．

型アノテーションと型情報の使用法

ヘッダファイルからパースできるような型情報のサポートは始まったばかりで，有用な情報を使いこなせていません． このサポートを改善することで，たとえば，特定の型情報を用いて特定のメモリに注釈をほどこし，それらとよりかしこくやりとりできるようになるでしょう．

考えてみてください．たとえば，こんなリンクリストとのやりとり：print state.memory[state.regs.rax:].next.next.value．

研究上の挑戦

歴史的に，angrはプログラム解析の新分野を研究する過程で進展してきました． ここで，取り組むことのできるいくつかの自己完結型の研究を示します．

意味論的な関数の特定・差分取得

現在の関数差分取得技術（TODO: いくつか例を示す）は欠点を有しています． CGCのために，私たちは意味論ベースのバイナリ特定エンジンを開発しました．これは，テストケースにもとづいてバイナリ中の関数を特定するものです． これに関して，2つの分野に改善の余地があります．どちらも独自の研究プロジェクトです：

  1. 現在，このコンポーネントで使用するテストケースは人間が生成しています．しかし，シンボリック実行を用いれば，他のバイナリ内の与えられた関数を例として，自動的にテストケースを生成することができます．
  2. 与えられた関数について十分高いカバレッジを達成するテストケースを作成するべく，同じ機能の別の実装に対してテストケースを適用し，コードカバレッジにおける変化を計測することで，機能の変更を検出できます．これを用いれば，意味論的な関数の差分取得が可能になります．

シンボリック実行へのAFLのパス選択基準の適用

AFLはすべてのパスについて制御フローの遷移を追跡することで，ファジング中に「ユニークな」パスを特定するというすばらしい仕事をしています． 同様の基準をシンボリック探索に対して適用できます．それがどれだけ単純か考えれば，きっと気が滅入るほどのよい仕事をしてくれるでしょう．

包括的な研究の方向性

よく探求されていないプログラム解析の分野はまだ残されています． ここに研究の一般的な方向性を示しますが，これらはおそらく博士論文まるごとの取り組みになる可能性を留意しておいてください．

プロセス間の相互作用

バイナリ解析の研究のほとんどは単一のバイナリを扱っていますが，しばしば現実的ではないことがあります． たとえば，CGIプログラムに渡すことのできる入力の型は，ウェブサーバによる前処理に依存します． 現在，angrで複数の並行プロセスを分析することはできません．そして，その分野の多くの課題に対応していません（すなわち，並行処理のモデル化）．

プロセス内の並行性

プロセス間の相互作用のモデル化と同様に，同じプロセスの並行スレッドの動作を理解する取り組みは少ししか進んでいません． 現在，angrは並行スレッドを分析する機能を備えていません．そして，分析を可能にする理論的枠組みは明らかになっていません．

シグナルハンドラ（またはハードウェア割り込み）の分析もまた，並行スレッドの課題の一部といえます． 各シグナルハンドラはシグナルをいつでも受け取ることができ，いつでも実行できるスレッドとしてモデル化できます． これらのハンドラをいつ分析すれば有用といえるのかは未解決の問題です． 割り込みの影響を推理しているシステムとしては，FIEがあります．

パス爆発

（Veritestingのような）多くのアプローチでは，シンボリックにおけるパス爆発の回避を試みてきました．

しかしながら，それらの努力にも関わらず，パス爆発はいまだにシンボリック実行における主な課題であり続けています．

angrはパス爆発に対応する新手法を実装するための優れた基盤を提供しています． ほとんどのアプローチはExploration Techniquesとして簡単に実装できます．そして，速やかに評価できます（たとえば，CGC datasetによって）．

results matching ""

    No results matching ""