沙箱用于在隔离环境中执行恶意文件，同时检测其动态行为并收集取证痕迹。
CAPE 源自 Cuckoo v1，在 Windows 平台上具备以下核心功能：
CAPE 通过以下几个关键补充，扩展了 Cuckoo 传统的沙箱输出：
有一个免费的在线演示实例，任何人都可以使用：
https://capesandbox.com - 账户激活请联系 https://twitter.com/capesandbox
Cuckoo 沙箱最初是 2010 年在 Honeynet 项目内的一个 Google Summer of Code 项目。最初由 Claudio Guarnieri 设计和开发，第一个测试版于 2011 年发布。2014 年 1 月，Cuckoo v1.0 发布。
2015 年是关键的一年，Cuckoo 历史上出现了一个重要的分支。原始监控器和 API 挂钩方法的开发在主 Cuckoo 项目中停止。取而代之的是由 Jurriaan Bremer 创建的一个替代监控器，该监控器使用基于 restructuredText 的签名格式，并通过 Linux 工具链编译。
大约在同一时间，一个名为 Cuckoo-modified 的分支由 Brad 'Spender' Spengler 创建，继续开发原始监控器，并进行了重大改进，包括 64 位支持，最重要的是引入了 Microsoft Visual Studio 编译器。
同年，Kevin O'Reilly 在 Context Information Security 开始开发一种名为 CAPE 的动态命令行配置和有效载荷提取工具。其名称是 'Config And Payload Extraction' 的缩写，最初的研究重点是利用 Microsoft 的 Detours 库提供的 API 挂钩来捕获解包后的恶意软件有效载荷和配置。然而，显然仅凭 API 挂钩不足以提供足够的能力和精度来解包任意恶意软件的有效载荷或配置。
因此，开始研究一种新型调试器概念，以精确控制和检测恶意软件，同时避免使用 Microsoft 的调试接口，力求尽可能隐蔽。该调试器被集成到基于 Detours 的概念验证命令行工具中，与 API 挂钩相结合，从而产生非常强大的能力。
当初步工作表明可以用 Cuckoo-modified 的 API 挂钩引擎 替换 Microsoft Detours 时，CAPE 沙箱的想法诞生了。随着调试器、自动解包、基于 YARA 的分类和集成配置提取的加入，CAPE 沙箱于 2016 年 9 月在 44con 上首次公开发布：CAPE 版本 1。
2018 年夏天，项目有幸迎来了 Andriy 'doomedraven' Brukhovetskyy 的巨大贡献的开始，他是 Cuckoo 的长期贡献者。2019 年，他开始将 CAPE 移植到 Python 3 的艰巨任务，并在同年 10 月发布了 CAPEv2。
CAPE 不断开发和改进，以跟上恶意软件和操作系统能力的进步。2021 年，增加了通过动态 YARA 扫描在引爆过程中编程 CAPE 调试器的能力，从而可以为反沙箱技术创建动态绕过。Windows 10 成为默认操作系统，其他重大补充包括交互式桌面、AMSI（反恶意软件扫描接口）有效载荷捕获、基于 Microsoft Nirvana 的 'syscall hooking' 以及基于调试器的直接/间接系统调用对抗措施。
在 CAPE 中，可以通过三种机制对恶意软件进行分类：
可以使用 CAPE 自身的框架进行解析，此外，还支持以下框架：RATDecoders、DC3-MWCP、MalDuck 或 MaCo
def extract_config(data):，由 cape_utils.py 调用，且零复杂度。
CAPE 利用多种恶意软件技术或行为来实现解包后有效载荷的捕获：
这些行为将导致被注入、提取或解压缩的有效载荷被捕获，以供进一步分析。此外，CAPE 会自动为每个进程创建进程转储，或者对于 DLL，创建 DLL 在内存中的模块映像。这对于使用简单加壳器的样本非常有用，因为通常模块映像转储是完全解包的。
除了 CAPE 默认的“被动”解包机制外，还可以启用“主动”解包，该机制使用断点检测对新分配或受保护的内存区域的写入，从而在执行之前尽可能早地捕获解包后的有效载荷。这可以通过网页提交复选框启用，或通过指定选项 unpacker=2 启用，默认情况下不启用，因为它可能会影响引爆质量。
CAPE 可以通过 YARA 签名进行编程，以解包特定的加壳器。例如，UPX 类型的加壳器非常常见，尽管在 CAPE 中这些会导致解包后的有效载荷被被动捕获，但默认捕获是在解包后的有效载荷开始执行之后进行的。因此，通过自定义 YARA 签名动态检测源自 UPX 的加壳器，并在加壳器的最后一条指令上设置断点，可以在有效载荷开始执行之前在其原始入口点（OEP）捕获它。
dump-on-api 选项允许在模块调用特定 API 函数时进行转储，该 API 函数可以在网页界面中指定（例如 dump-on-api=DnsQuery_A）。
调试器使 CAPE 能够超越其原始能力不断发展，现在包括动态的逃避绕过措施。由于现代恶意软件通常试图在沙箱内逃避分析，例如使用虚拟化计时陷阱或 API 挂钩检测，CAPE 允许开发动态对抗措施，将调试器操作与 Yara 签名相结合，以在恶意软件引爆时检测逃避行为，并执行控制流操作，强制样本完全引爆或跳过逃避行为。
通过提交选项 bp0 到 bp3 可以快速访问调试器，这些选项接受 RVA 或 VA 值来设置断点，此时会输出简短的指令跟踪，该跟踪由 count 和 depth 选项控制（例如 bp0=0x1234,depth=1,count=100）。
要在模块入口点设置断点，使用 ep 代替地址（例如 bp0=ep）。另外，break-on-return 允许在被挂钩 API 的返回地址上设置断点（例如 break-on-return=NtGetContextThread）。可选的 base-on-api 参数允许通过 API 调用设置 RVA 断点的映像基址（例如 base-on-api=NtReadFile,bp0=0x2345）。
选项 action0 - action3 允许在命中断点时执行操作，例如转储内存区域（例如 action0=dumpebx）或更改执行控制流（例如 action1=skip）。CAPE 的文档中提供了更多此类操作的示例。
包含 CAPE 监控器代码的仓库是独立的。
有一个社区签名仓库，包含由 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 以确保你理解git add --all
git commit -m '[STASH]'
git pull --rebase origin master
# 如需要，解决冲突（rebase）
git reset HEAD~1
# 确保 kevoreilly 仓库已添加为远程仓库（只需执行一次）
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# 确保你所有更改已提交到将要合并的分支上
git commit -a -m '<你的提交信息>'
# 从 kevoreilly 仓库获取更改
git fetch kevoreilly
# 将 kevoreilly 的 master 分支合并到当前分支
git merge kevoreilly/master
# 如需要，解决合并冲突
# 如需要，推送到你的仓库
git push
如果您在研究中使用了 CAPEv2，请按照 GitHub 菜单中的“Cite this repository”指定方式引用它。
pefile 的依赖，因为每个依赖都固定了它们想要的版本。
pefile 依赖，因为您已经安装了它。这样就不会再有麻烦。