博客文章地址：
此 YouTube 视频演示链接：
更多面向模糊测试活动/反馈/测试工具的功能：
Mutiny Fuzzing Framework 是一个网络模糊测试器，它通过重放 PCAP 数据包并使用变异模糊测试器进行操作。目标是以尽可能快的速度开始网络模糊测试，但会牺牲测试的全面性。
Mutiny 的一般工作流程是：获取合法流量的样本（例如浏览器请求），将其输入到预处理脚本中以生成 .fuzzer 文件。然后，可以运行 Mutiny 并使用此 .fuzzer 文件生成针对目标主机的流量，用户可以选择对任意数据包进行变异。
还有一些扩展可以改变 Mutiny 的行为，包括根据输入/输出更改消息、更改 Mutiny 对网络错误的响应方式，以及在单独的线程中监控目标。
Mutiny 使用 Radamsa 执行变异操作。
Decept Proxy 是一个多用途网络代理，它可以将来自明文或 TLS TCP/UDP/域套接字连接的流量转发到另一明文或 TLS TCP/UDP/域套接字连接，除此之外还有其他功能。它是 Mutiny 的好搭档，因为它可以直接生成 .fuzzer 文件（对模糊测试 TLS 连接特别有帮助），并允许 Mutiny 与 TLS 主机通信。
sample_apps 文件夹提供了基本示例，展示了一些可以用该模糊测试器完成的操作，以及几个供测试的应用程序/客户端。
由 James Spadaro ([email protected]) 和 Lilith Wyatt ([email protected]) 编写。
确保已安装 python 和 scapy。
解压 Radamsa 并执行 make （不必执行 make install，除非你想将其安装到 /usr/bin 中 - 它将使用本地的 Radamsa）。如果更改了 Radamsa 路径，请更新 mutiny.py。
将 pcap 文件保存到文件夹中。对 <XYZ>.pcap 运行 mutiny_prep.py（另外，如果有自定义处理器，可以选择传入其目录，详情见下文）。回答提示的问题，最终在与 pcap 相同的文件夹中得到一个 <XYZ>.fuzzer 文件。
运行 mutiny.py <XYZ>.fuzzer <targetIP>。这将开始模糊测试。日志将保存在同一文件夹下的目录 <XYZ>_logs/<time_of_session>/<seed_number> 中。
.fuzzer 文件是人类可读且带注释的。它们允许在单个 .fuzzer 文件的基础上更改各种选项，包括对哪些消息或消息部分进行模糊测试。
.fuzzer 文件中包含消息内容。这些内容只是以 'inbound' 或 'outbound' 开头的行，表示消息的方向。它们采用 Python 字符串格式，非打印字符使用 '\xYY' 表示。这些由 'mutiny_prep.py' 和 Decept 自动生成，但有时需要手动修改。
如果某条消息的 'outbound' 后面带有 'fuzz' 关键字，则表示该消息将通过 Radamsa 进行模糊测试。消息可以换行继续，只需在新的一行用引号包含更多消息数据即可。在这种情况下，第二行将与第一行合并。
另外，可以使用 'sub' 关键字来表示子组件。这允许指定消息的一个单独组件，目的是只模糊测试某些部分，或者在消息处理器中方便使用。
以下是一个任意消息数据的示例：
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
这将导致 Mutiny 发送 say hi and fuzz this but not this(0xdeadbeef)。0xdeadbeef 将以 4 个十六进制字节的形式发送。and fuzz this 将通过 Radamsa 进行模糊测试，而 say hi 和 but not this(0xdeadbeef) 则保持不变。
由于存在 'inbound' 行，Mutiny 将在发送上述单条消息后等待服务器响应。服务器预期的响应是 this is the server's expected response。Mutiny 不会对此数据进行太多处理，只会检查服务器实际发送的内容是否与该字符串匹配。如果发生崩溃，Mutiny 会将预期输出和服务器实际回复的内容都记录下来。
mutiny_classes/ 目录包含消息处理器、监控器和异常处理器的基类。这些文件中的任何一个都可以复制到与 .fuzzer 相同的文件夹（默认情况）中，或者复制到 .fuzzer 文件中 'processor_dir' 指定的单独子文件夹中。
这三个类分别允许：存储服务器响应并更改传出消息、在单独的线程上监控目标、以及更改 Mutiny 处理异常的方式。
消息处理器定义了在模糊测试运行期间调用的多个回调函数。在这些回调函数中，可以运行任何 Python 代码。根据经验，它们主要有三种用途。
最常见的用途是当服务器发送需要在后续出站消息中添加的令牌时。例如，如果 Mutiny 的第一条消息执行登录操作，服务器响应了一个会话 ID，则可以使用 postReceiveProcess() 回调来存储该会话 ID。然后，在 preSendProcess() 中，可以使用该会话 ID 修复传出数据。sample_apps/session_server 中有一个示例。
消息处理器的另一个常见用途是限制或更改已模糊测试的消息。例如，如果服务器总是丢弃大于 1000 字节的消息，则可能不值得发送任何大消息。可以使用 preSendProcess() 在模糊测试之后、发送之前对消息进行缩短，或者抛出异常。
抛出异常引出了消息处理器的最后一种常见用法。在回调中，可以抛出 mutiny_classes/mutiny_exceptions.py 中定义的任何自定义异常。有几个异常（均已注释），它们会导致 Mutiny 产生不同的行为。这些行为通常涉及日志记录、重试或中止当前运行。
监控器有一个 monitorTarget() 函数，它在与主 Mutiny 模糊测试器不同的线程上运行。目的是实现一个长时间运行的过程，以某种方式监控目标主机。这可以是任何 Python 能做的事情，例如与目标上运行的监控守护进程通信、读取长文件，甚至只是重复 ping 目标主机，具体取决于模糊测试会话的要求。
如果监控器检测到崩溃，它可以随时调用 signalMain()。这将向主 Mutiny 线程发送信号，指示发生了崩溃，并记录该崩溃。此函数通常应以无限循环方式运行，因为返回将导致线程终止且不会重新启动。
异常处理器决定 Mutiny 在模糊测试会话期间遇到给定异常时应如何处理。从最一般的意义上讲，processException() 函数会尽可能将 Python 和操作系统级别的异常转换为 Mutiny 的错误处理操作。
例如，如果 Mutiny 收到 'Connection Refused'，默认响应是假设目标服务器已不可恢复地关闭，因此 Mutiny 将记录上一次运行并停止。在大多数情况下确实如此，但可以根据需要将此行为更改为 mutiny_classes/mutiny_exceptions.py 中任意异常的行为，从而允许针对崩溃检测和错误纠正进行定制。