decaf-project/decafDECAF（Dynamic Executable Code Analysis Frameworkの略）は、QEMUベースのバイナリ解析プラットフォームです。ここはまた、DroidScope動的Androidマルウェア解析プラットフォームの本拠地でもあります。DroidScopeは現在、DECAFの拡張機能となっています。
DECAF（Dynamic Executable Code Analysis Frameworkの略）は、QEMUベースのバイナリ解析プラットフォームです。
DECAF++（DECAFの新バージョン）は、汚染解析が約2倍高速化され、我々の知る限り最速の全システム動的汚染解析フレームワークです。これにより、疑わしい（汚染された）入力が存在しない場合、わずか4％のオーバーヘッド（SPEC CPU2006）しか課さず、はるかに優れたユーザビリティを実現します。重い汚染解析ワークロード下でも、DECAF++はその伸縮性によりnbenchで約25％高速と、はるかに優れたパフォーマンスを発揮します。DECAF++の伸縮性は、入力を選択的に解析するセキュリティ解析タスク（例えば、良性トラフィックをフィルタリングする侵入検知システム（IDS）など）に非常に適しています。詳細な技術情報については、RAID 2019論文を参照してください。最適化を有効にするには、DECAF++ wikiページを参照してください。
Ali Davanian, Zhenxiao Qi, Yu Qu, and Heng Yin, DECAF++: Elastic Whole-System Dynamic Taint Analysis, In the 22nd International Symposium on Research in Attacks, Intrusions and Defenses (RAID), September 2019. （DECAFの新しい最適化バージョンを引用する場合は、この論文を引用してください）
"Make it work, make it right, make it fast: building a platform-neutral whole-system dynamic binary analysis platform", Andrew Henderson, Aravind Prakash, Lok Kwong Yan, Xunchao Hu, Xujiewen Wang, Rundong Zhou, and Heng Yin, to appear in the International Symposium on Software Testing and Analysis (ISSTA'14), San Jose, CA, July 2014. （DECAFを引用する場合は、この論文を引用してください）
Lok Kwong Yan, Andrew Henderson, Xunchao Hu, Heng Yin, and Stephen McCamant?.On soundness and precision of dynamic taint analysis. Technical Report SYR-EECS-2014-04, Syracuse University, January 2014.
DroidScope: Seamlessly Reconstructing OS and Dalvik Semantic Views for Dynamic Android Malware Analysis", Lok-Kwong Yan and Heng Yin, in the 21st USENIX Security Symposium, Bellevue, WA, August 8-10, 2012.
Luo, L., Fu, Y., Wu, D., Zhu, S., & Liu, P. (2016, June). Repackage-proofing android apps. In 2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN) (pp. 550-561). IEEE.
Wei, J., Yan, L. K., & Hakim, M. A. (2015, December). Mose: Live migration based on-the-fly software emulation. In Proceedings of the 31st Annual Computer Security Applications Conference (ACSAC) (pp. 221-230).
Carmony, C., Hu, X., Yin, H., Bhaskar, A.V., & Zhang, M. (2016). Extract Me If You Can: Abusing PDF Parsers in Malware Detectors. In Proceedings of 2016 Network and Distributed System Security Symposium (NDSS).
Feng, Q., Prakash, A., Yin, H., & Lin, Z. (2014, December). Mace: High-coverage and robust memory analysis for commodity operating systems. In Proceedings of the 30th annual computer security applications conference (pp. 196-205)
Alwabel, A., Shi, H., Bartlett, G., & Mirkovic, J. (2014). Safe and automated live malware experimentation on public testbeds. In 7th Workshop on Cyber Security Experimentation and Test (CSET'14).
DECAF（Dynamic Executable Code Analysis Framework）は、Heng YinがDawn Song率いるBitBlazeプロジェクトの一環として取り組んだ、TEMU（BitBlazeの動的解析コンポーネント）向けに開発されたバイナリ解析技術の後継です。DECAFはTEMUを基盤としています。このプロジェクトにご協力いただいたすべての方々に感謝します。
図1 DECAFの全体アーキテクチャ
図1はDECAFの全体アーキテクチャを示しています。DECAFはプラットフォームに依存しない全システム動的バイナリ解析フレームワークです。以下の主要機能を提供します。
TEMUとは異なり、DECAFはOSレベルのセマンティクスを取得するためにゲストドライバを使用しません。DECAFのVMIコンポーネントは、バイナリ解析をサポートするために、プロセス、スレッド、コードモジュール、シンボルを含む仮想マシンの最新のOSレベルビューを再構築できます。さらに、複数のアーキテクチャとオペレーティングシステムをサポートするために、プラットフォームに依存しない設計になっています。OSレベルのセマンティック情報を抽出するためのワークフローは、複数のアーキテクチャとオペレーティングシステムで共通です。プラットフォーム固有の処理は、カーネルデータ構造と情報を抽出するフィールドにのみ存在します。
理想的には、同じ解析コード（最小限のプラットフォーム固有コード）が異なるCPUアーキテクチャ（例：x86とARM）や異なるオペレーティングシステム（例：WindowsとLinux）で動作することを望んでいます。そのためには、解析フレームワークがアーキテクチャやOS固有の詳細を解析プラグインから隠蔽する必要があります。さらに、解析フレームワーク自体を保守可能にし、新しいアーキテクチャやOSに拡張可能にするために、フレームワーク内のプラットフォーム固有コードも最小限にする必要があります。DECAFは複数のアーキテクチャと複数のオペレーティングシステムの両方をサポートできます。現在、DECAFは32ビットWindows XP/Windows 7/Linuxおよびx86/ARMをサポートしています。
DECAFは、CPUレジスタとメモリに対してビットレベルの精度を維持し、変換されたコードブロックに正確な汚染ルールをインライン化することで、正確な汚染を保証します。これにより、各CPUレジスタとメモリ位置の汚染状態は、仮想マシンのコード実行中に同期的に処理および更新されます。汚染ラベルの伝播は非同期方式で行われます。このような汚染ロジックを主に中間表現レベル（より具体的にはTCG IRレベル）で実装することにより、新しいCPUアーキテクチャへの汚染サポートの拡張が容易になります。
DECAFはイベント駆動型プログラミングインターフェースを提供します。これは、変換フェーズでの「インストルメント」と実行フェーズでの「分析」というパラダイムが解析プラグインから見えないことを意味します。解析プラグインは、関心のあるイベントを登録し、対応するイベント処理関数を実装するだけで済みます。コードインストルメンテーションの詳細はフレームワークが処理します。
実行時オーバーヘッドを削減するために、インストルメンテーションコードは必要な場合にのみ変換コードに挿入されます。例えば、プラグインが関数のエントリポイントに関数フックを登録すると、このフックのインストルメンテーションコードは関数のエントリポイントにのみ配置されます。プラグインがこの関数フックを登録解除すると、インストルメンテーションコードは変換コードからも適宜削除されます。プラグインの開発を容易にするために、動的コードインストルメンテーションの管理はフレームワーク内で完全に処理され、プラグインからは見えません。
ヘルプドキュメントについては、wikiページを参照してください。
