恶意软件配置与有效载荷提取
沙箱用于在隔离环境中执行恶意文件， 同时对其动态行为进行插桩并收集取证痕迹。
CAPE 源自 Cuckoo v1，在 Windows 平台上具有以下核心能力：
CAPE 在 Cuckoo 传统沙箱输出的基础上补充了若干关键功能：
有一个任何人都可以使用的免费在线演示实例：
https://capesandbox.com - 如需激活账户请联系 https://twitter.com/capesandbox
Cuckoo Sandbox 于 2010 年作为 The Honeynet Project 内的 Google Summer of Code 项目启动。 它最初由 Claudio Guarnieri 设计和开发，第一个 beta 版本于 2011 年发布。2014 年 1 月， Cuckoo v1.0 发布。
2015 年是关键的一年，Cuckoo 的历史出现了重大分叉。
原始 monitor 和 API hooking 方法的开发在主 Cuckoo 项目中停止。
它被一个替代 monitor 取代，
该 monitor 使用基于 restructuredText 的签名格式，通过 Linux 工具链编译，
由 Jurriaan Bremer 创建。
大约在同一时间，一个名为 Cuckoo-modified 的分叉由 Brad 'Spender' Spengler 创建，继续开发原始 monitor， 并带来了重大改进，包括 64 位支持，以及重要的是引入了 Microsoft 的 Visual Studio 编译器。
同年，在 Context Information Security，Kevin O'Reilly 开始开发一个名为 CAPE 的动态命令行配置与载荷 提取工具。 该名称是 'Config And Payload Extraction' 的首字母缩写，最初的研究重点是利用 Microsoft Detours 库提供的 API hook 来捕获脱壳后的恶意软件载荷和配置。然而，人们逐渐发现， 仅靠 API hook 无法提供足够的能力和精度，来从任意恶意软件中脱壳载荷或配置。
因此，研究开始转向一种新颖的调试器概念，以便在避免使用 Microsoft 调试接口的同时， 对恶意软件进行精确控制和插桩，从而尽可能隐蔽。该调试器被集成到基于 Detours 的概念验证命令行工具中， 与 API hook 相结合，产生了非常强大的能力。
当初步工作表明可以用 Cuckoo-modified 的 API hooking 引擎 替换 Microsoft Detours 时，CAPE Sandbox 的想法诞生了。随着调试器、自动化脱壳、 基于 YARA 的分类和集成配置提取的加入，2016 年 9 月在 44con 上，CAPE Sandbox 首次 公开发布：CAPE 版本 1。
2018 年夏天，该项目有幸迎来了 Andriy 'doomedraven' Brukhovetskyy 开始做出巨大 贡献，他是一位长期的 Cuckoo 贡献者。2019 年，他开始了将 CAPE 移植到 Python 3 的 艰巨任务，并于当年 10 月发布了 CAPEv2。
CAPE 一直在持续开发和改进，以跟上恶意软件和操作系统能力的进步。 2021 年，新增了在引爆期间通过动态 YARA 扫描对 CAPE 调试器进行编程的能力， 从而可以为反沙箱技术创建动态绕过。Windows 10 成为默认操作系统，其他重要新增功能包括交互式桌面、 AMSI（反恶意软件扫描接口）载荷捕获、基于 Microsoft Nirvana 的 'syscall hooking'， 以及基于调试器的直接/间接系统调用对抗措施。
2024 年，enzok 创建了 CAPEsolo，这是 CAPE 的交互式 Windows 桌面版本， 使用 wxPython 作为图形界面，并引入了 64 位客户机 Python 兼容性。 2026 年，新增了对所有 Windows 10 版本和 Windows 11 23H2 的支持。
在 CAPE 中可以通过三种机制对恶意软件进行分类：
解析可以使用 CAPE 自己的框架完成，或者支持以下框架：RATDecoders、DC3-MWCP、MalDuck，或 MaCo
CAPE 的核心和社区配置解析器维护在单独的
CAPE-parsers 仓库中，并作为
CAPE-parsers 依赖安装。请在那里提交对这些解析器的新增和修复；
其 README 描述了预期的配置字段。
def extract_config(data):，将由 cape_utils.py 调用，零复杂性。
CAPE 利用许多恶意软件技术或行为来捕获脱壳后的载荷：
这些行为将导致捕获被注入、提取或解压的载荷，以供进一步分析。此外，CAPE 会自动为每个进程创建进程转储，或者，对于 DLL，则创建该 DLL 在内存中的模块映像。这对于使用简单加壳器打包的样本很有用，因为模块映像转储通常已完全脱壳。
除了 CAPE 默认的“被动”脱壳机制外，还可以启用“主动”脱壳，它使用断点来检测对新分配或受保护内存区域的写入，以便在执行前尽早捕获脱壳后的载荷。这可以通过 Web 提交复选框启用，或通过指定选项 unpacker=2 启用，默认关闭，因为它可能影响引爆质量。
CAPE 可以通过 YARA 签名进行编程，以脱壳特定的加壳器。例如，UPX 类型加壳器非常常见，尽管在 CAPE 中它们会导致脱壳后的载荷被被动捕获，但默认捕获是在脱壳后的载荷已经开始执行之后进行的。因此，通过自定义 YARA 签名动态检测 UPX 派生的加壳器，并在最终加壳器指令处设置断点，就可以在载荷开始执行之前在其原始入口点（OEP）捕获载荷。
dump-on-api 选项允许在模块调用特定 API 函数时转储该模块，该 API 函数可以在 Web 界面中指定（例如 dump-on-api=DnsQuery_A）。
调试器使 CAPE 能够继续超越其原始能力发展，现在包括动态反规避绕过。由于现代恶意软件通常试图逃避沙箱内的分析，例如通过使用虚拟化计时陷阱或 API hook 检测，CAPE 允许开发动态对抗措施，将调试器操作与 Yara 签名相结合，以在规避性恶意软件引爆时检测它，并执行控制流操纵，以强制样本完全引爆或跳过规避行为。
通过提交选项 bp0 到 bp3 可以快速访问调试器，这些选项接受 RVA 或 VA 值来设置断点，随后将输出一段简短的指令跟踪，由 count 和 depth 选项控制（例如 bp0=0x1234,depth=1,count=100）。
要在模块入口点设置断点，使用 ep 代替地址（例如 bp0=ep）。或者 break-on-return 允许在已 hook API 的返回地址处设置断点（例如 break-on-return=NtGetContextThread）。可选的 base-on-api 参数允许通过 API 调用设置 RVA 断点的映像基址（例如 base-on-api=NtReadFile,bp0=0x2345）。
选项 action0 - action3 允许在命中断点时执行操作，例如转储内存区域（例如 action0=dumpebx）或更改执行控制流（例如 action1=skip）。CAPE 的文档包含此类操作的更多示例。
包含 CAPE monitor 代码的仓库是独立的。
有一个签名社区仓库，包含由 CAPE 社区开发的数百个签名。所有新的社区功能都应推送到该仓库。之后，如果开发者有能力并愿意维护它们，可以将其移至核心。
请通过帮助为更多恶意软件家族创建新签名、解析器或绕过来为该项目做出贡献。目前有许多正在进行中，敬请关注。
非常感谢 @D00m3dR4v3n 独自将 CAPE 移植到 Python 3。
Python3
只有 rooter 应以 root 身份执行，其余以 cape 用户身份执行。以 root 运行会搞乱权限。
conf 文件夹内的所有__配置文件！kvm-qemu.sh 和 cape2.sh __应该__从 tmux 会话中执行，以防止 ssh 连接中断时出现任何操作系统问题。<username> 替换为真实模式。<WOOT>！sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf 文件夹内的配置文件来配置 CAPE。systemctl restart <service_name>journalctl -u <service_name>-h 获取帮助菜单。以调试模式（-d）运行服务也会有所帮助。-h，但请检查脚本以 理解 它们在做什么。git pullpython3 utils/community.py -waf，请先查看 -h 以确保你理解