对可编程控制器的专有协议进行模糊处理找到影响物理控制相关的漏洞

对可编程控制器的专有协议进行模糊处理找到影响物理控制相关的漏洞

原文
Fuzzing proprietary protocols of programmable controllers to find vulnerabilities that affect physical control
申明
版权归原文作者及出版单位所有，如有侵权请联系删除。

概述

​ 可编程控制器是工业控制系统（ICS）的关键部件，是网络空间和物理世界之间的桥梁。随着工业物联网（IIoT）的发展，它们不再是物理隔离的，允许远程黑客利用漏洞攻击它们。然而，由于可编程控制器的高度私有化和复杂的工作流程，现有的工作并不适合发现可编程控制器的漏洞。在我们的研究中，我们为可编程控制器提出了一种流量驱动的协议模糊方法。具体来说，我们通过选择设备的种子和引导状态，对网络守护程序进行专有协议模糊处理。在模糊处理过程中，除了监测网络状态外，还使用示波器自动监测底层控制服务的状态。这些漏洞的触发使可编程控制器对执行器的控制失效，并直接影响物理世界。此外，要恢复被破坏的设备的正常生产任务是非常困难的。我们在六个流行的制造商的15个真实世界的可编程控制器上评估了我们的原型。根据分析结果，我们发现了26个漏洞，其中20个可以直接导致物理控制服务崩溃。

1. 简介

​ 工业控制系统（ICS）被广泛用于关键的基础设施，如发电厂、水处理厂、铁路和其他对我们现代生活至关重要的工业过程。可编程控制器，即可编程逻辑控制器（PLC）和可编程自动化控制器（PAC），是ICS的关键组成部分，用于自动收集传感器数据和控制执行器。对可编程控制器的任何干扰都会对资产、环境和生命造成重大损害。为了提高生产效率和降低成本，互联网技术（IT）和操作技术（OT）的整合已经成为一种趋势。工业4.0和工业物联网（IIoT）等智能制造方案被提出。然而，这也给可编程控制器带来了安全风险，使其比以往更容易受到网络攻击。攻击，如委内瑞拉和乌克兰的停电事件，将变得容易和频繁[1,2]。以前的ICS攻击利用设备功能（如关闭、清除程序）来完成敲诈、数据伪造和控制程序的篡改[3-5]。然而，在这方面有严格的要求对手，如了解工厂的业务，甚至需要与攻击目标进行物理接触。请注意，这些针对ICS的攻击的目的是为了影响物理世界。因此，我们试图在满足以下要求的可编程控制器中找到跨越网络物理的漏洞。(i) 这些漏洞存在于设备系统中，与运行中的逻辑程序无关；(ii) 这些漏洞可以通过网络通信被远程利用；(iii) 最重要的是，这种漏洞在被触发后可以导致物理控制的失败。同时，设备也很难恢复生产任务。

​ 协议模糊法被广泛用于发现嵌入设备的漏洞。目前，基于仿真的技术[6-8]、基于源代码的技术[9-11]和基于通信软件的技术[12,13]是流行的解决方案。不幸的是，可编程控制器的高度私有化和大规模的通信软件使得这些现有的方法不适合于可控的控制器。具体来说，对可编程控制器的协议模糊化在可编程序控制器方面，面临着以下挑战：(i) 不同的制造商为可编程序控制器配置了专有协议来进行通信。这些专有协议是以二进制格式设计的，没有有意义的信息。这使得自动分析通信和提取有效信息以协助模糊处理变得很困难；(ii) 可编程控制器内部有严格的执行状态限制。同时，为了确保可编程控制器的可用性，制造商使用保护机制来确保网络服务的崩溃不会影响控制服务。因此，如果不满足状态约束，控制服务中的漏洞就很难通过网络交互被发现；（iii）监测模糊测试期间触发的嵌入式设备漏洞具有挑战性。简单地使用网络消息监测器只能发现影响网络服务的漏洞。因此，影响控制服务的漏洞将被忽略。

​ 为了克服上述挑战，我们利用工程软件和可编程控制器之间的流量来驱动模糊处理过程。在本文中，我们设计了一种基于字节特征的多步骤聚类方法，以实现大量请求信息中的信息过滤和种子选择。同时，确定了与种子对应的指导消息序列。为了保证状态引导的有效性，我们系统地研究了防重放机制，并提供相应的配置文件来完成规避。然后，在相应的状态引导完成后，基于一个种子生成的测试案例被发送。在后端，设备网络服务的状态是由连接和响应信息来监控的。此外，我们利用示波器来收集输出模块的物理信号，以实现控制服务的状态监测。最后，我们根据不同的行为结合漏洞触发后的恢复难度对漏洞进行区分。我们实现了可编程控制器模糊器（PCFuzzer），并测试了六家流行的制造商（包括西门子、艾伦-布拉德利、三菱电机等）使用的七个专有协议。PCFuzzer在15个真实设备上发现了18个0天漏洞和2个N天漏洞（已经确认）。每个设备都有通过网络交互影响物理控制的漏洞。通过与KittyFuzzer[14]、BooFuzz[15]和Pulsar[16]的比较，PCFuzzer在相同的时间预算内发现了更多漏洞。此外，我们通过利用场景解释了所发现的漏洞的价值。最后，我们提出了几个缓解机制，以预测可编程控制器中漏洞的发现和利用。本文的主要贡献有以下几点。

​ • 我们提出了一种新的技术，利用可编程控制器专有协议流量中的字节特征，选择种子和指导信息序列来驱动模糊测试。

​ • 我们设计并实现了PCFuzzer，它利用状态引导和网络/物理状态监测来有效地检测可编程控制器的脆 弱 性 。

​ • 我们在15个真实世界的可编程控制器上评估了PCFuzzer，发现了26个漏洞，包括20个影响物理控制的漏洞。

​ 路线图。第2节介绍了工业控制系统和可编程控制器的基本背景知识。第3节展示了利用可编程控制器中的漏洞的威胁模型。第4节介绍了PCFuzzer的设计和实现。第5节提供了PCFuzzer的评估结果。我们在第6节中讨论了缓解机制和未来工作。第7节展示了相关工作。第8节是本文的结论。

2. 背景结构

2.1 网页行业架构

​ IIoT强调的是曾经孤立的工厂或机器的整合[17]。通过增加设备之间的互连，可以实现更有效的数据收集和分析。这有助于提高生产效率，降低生产成本。一个典型的工业网络如图1所示。它可以分为企业级、管理级、主管级、控制级和现场级。企业级促进了企业的信息流动，并管理着与外部利益相关者的联系。根据企业级的计划，管理层完成生产调度、生产统计、资源管理和其他任务。工程工作站包含通信软件，如工程软件，对应于不同品牌的可编程控制器。在生产开始之前，操作人员需要使用工程软件来初始化和配置设备。监督控制和数据采集系统（SCADA）负责监测和控制地理上分散的工业场所。当发现异常情况时，操作人员可以在控制和现场层面进行远程干预。控制和现场层面主要包括可编程控制器和各 种 传感器/执行器。可编程控制器执行控制逻辑并与传感器/执行器协调，以实现现实世界中的感知和操作。

​ 各级之间的通信是通过路由器、交换机和代理服务器等实现的。除了企业级连接互联网外，管理级、主管级、甚至控制级的设备都有可能因为工作需要或配置错误而连接到互联网[18,19]。这就增加了系统的安全风险。尤其是作为网络空间和物理世界的桥梁的可编程控制器，更有可能成为攻击者的目标。

图1 工业网络结构

2.2 可编程控制概述

​ 可编程控制器是用于各种控制系统的基本组件，如调节生产过程或控制关键基础设施。可编程控制器分为PLC和PAC。PLC是一种专用的嵌入式设备，旨在执行逻辑控制功能。与PLC相比，PAC的性能更好，支持更多的I/O接口。PLC和PAC的结构和工作流程是相似的。

​ 可编程控制器的结构如图2所示。一般来说，可编程控制器包含电源、CPU模 块 、通信模块和I/O模块。为了更好地讨论，设备提供的服务被分为三类。

​ (i) 通信服务负责与网络空间的信息交流，如工程软件通信服务。

​ (ii) 控制服务与物理世界中执行器的控制逻辑有关，如执行控制程序服务、控制设备状态服务；

​ (iii)不直接参与网络通信或物理控制的其他服务。

图2 可编程控制器

​ 可编程控制器的工作流程如下。首先，我们使用制造商的专用工程软件，通过专有协议通信来配置设备。例如，西门子使用TIA软件与S7Comm协议或S7Comm-Plus协议进行通信，而施耐德使用Unity Pro XL与UMAS协议进行通信。虽然这些软件不同，但它们都为项目文件提供了一个编程和配置环境。项目文件包含设备配置、逻辑控制程序、地址映射等。除了编程和下载项目文件外，工程软件还提供控制设备状态（如运行、停止、编程）、获取设备信息（如固件版本、地址映射）的功能。表），并迫使I/O寄存器。其次，可编程控制器通过网络服务接收项目文件，并利用控制服务来执行它们。然后，可编程控制器以循环扫描的方式进行。(i) 可编程控制器逐一扫描输入端口，并将输入信号的当前状态保存到相应的存储区；(ii) 执行存储器中的逻辑控制程序，并将计算结果刷新到相应的输出图像寄存器；(iii) 控制器将输出图像寄存器的内容转移到输出锁存器，并通过输出信号驱动外部执行器。输出锁存器保持其状态直到下一个周期。

3. 威胁模式

​ 如果对手发现了可编程控制器的网络物理漏洞，影响攻击可行性 的唯一关键因素是能否与目标建立网络连接。随着IIoT的发展，对手有更多机会与可编程控制器建立连接。具体来说，它可以分为直接连接和间接连接。直接连接：通过使用Shodan[18]，我们发现有超过10万个可编程控制器暴露在互联网上。攻击者可以直接与他们建立连接并发起攻击；间接连接：工业网络中的计算机可以被用作攻击可编程控制器的跳板。例如，真正的攻击是通过被感染的U盘[3]和社会工程[2]完成对工业主机的控制。当对手进入工业网络，他们可以利用设备的指纹信 息 来发现攻击目标。这部分工作可以通过使用侦察工具，如PLCScan[20]和Nmap[21]来完成。因此，该威胁模型假设对手有能力与可编程控制器建立网络连接。

​ 传统的ICS攻击通过将特定的过程参数修改为不适当的值来破坏可编程控制器[3]。这种攻击要求对手了解业务情况并拥有先进的分析技术。此外，目前的ICS配备了安全保障措施，可以及时发现生产过程中的异常情况。因此，被攻击的设备将很快恢复到正常工作状态。在我们的威胁模型，对手利用漏洞对控制服务造成崩溃，特别是达到永久崩溃的目的。具体来说，我们发现在可编程控制器中存在一个普遍的漏 洞 ，无法通过设备重启或网络通信恢复。永久性崩溃的恢复往往需要重新下载设备固件，但可编程控制器制造商通常不提供固件。因此，即使安全措施检测到异常，安全措施也只能防止生命和环境受到伤害，但生产无法恢复。此外，导致设备崩溃的攻击有效载荷与正常数据包相似（相差几个字节），可以逃避安全措施的检查。

4. 发现方法

​ 在本文中，我们的目标是以一种有效的方式找到跨越网络物理漏洞。为此，我们设计了PCFuzzer，一个用于可编程控制器的流量驱动的专有协议模糊器。PCFuzzer的概述见图3。作为第一步，PCFuzzer获取原始输入流量，这可以帮助测试状态的探索和测试案例的生成。(第4.1节）。从大量的输入流量中，PCFuzzer然后提取种子和指导序列（第4.2节）。指导序列可以在每次模糊化迭代后加速状态恢复过程。之后，PCFuzzer形成测试序列，其中最重要的是绕过防重放机制，有效地完成状态引导（第4.3节）。为了检测设备的异常情况，PCFuzzer不仅监测网络行为，还利用数字示波器监测设备的物理行为。同时，我们测量设备的反应，以进一步选择新的指导序列来指导模糊器（第4.4节）。最后，PCFuzzer通过对异常情况的不同观察来识别独特的漏洞（第4.5节）。实现方法见第4.6节。

图3 PCFuzzer的概述

4.1 输入流量获取

​ PCFuzzer首先获取原始的输入流量，这些流量可以触发可编程控制器的各 种 状态。为了在设备中达到一个状态，输入需要满足一个特定的要求，我们称之为状态约束。状态约束可以分为两类。协议状态约束与协议的会话机制有关，涉及识别、握手、交互前信息等的安排。例如，在通用电气公司使用的专有协议中，首先需要发送一个内容为’0x00’×56的消息。根据设备的型号发送一些规定的消息后，握手步骤就完成了。功能状态约束是指在与设备进行交互时，某些功能必须在另一个功能完成后执行。例如，当我们想把设备切换到运行状态时，我们必须首先发送相关消息来执行连接和在线功能。然后设备才能正确解析切换状态消息。

​ 为了获得满足设备的协议和功能状态约束的输入流量，我们建议利用工程软件的GUI来自动生成输入流量。设备中的程序执行会受到所接收信息的顺序的影响。由于可编程控制器的工作取决于专用的工程软件配置，它们不能像移动电话那样实现自我配置。因此，我们可以通过利用工程软件的功能达到协议状态和功能状态。具体来说，我们通过自动触发相关GUI的按钮来激活不同的功能。请注意，对GUI的按钮操作的限制反映了状态的约束。如图4所示，在连接按钮被点击后，断开、诊断、在线、显示状态等按钮变得可点击。其他按钮是灰色的（不可点击）。在我们点击在线按钮后，强制I/O寄存器、上传文件、切换模式等将成为可点击的。因此，我们使用深度优先原则，至少自动进行三次点击操作。因此，所有与设备互动的按钮将至少可点击一次。当GUI的按钮处于可点击状态时，嗅探到的流量就有能力将设备状态引导到相关程序进行测试。这使得模糊测试更加有效。

图4 功能按钮的激活关系

4.2 种子和引导序列识别

​ 在获得可能触发可编程控制器不同状态的原始输入流量后，PCFuzzer进一步过滤掉流量中不相关的信息，以加速每次模糊化迭代中的状态恢复过程（第4.2.1节）。同时，PCFuzzer从所有候选信息中选择种子，并形成相应的指导序列，用于指导模糊处理并有效探索输入空间（第4.2.2节）。

4.2.1 信息过滤器

​ 我们使用嗅探流量中的请求消息进行测试，但许多消息对设备状态没有影响，如心跳消息、设备时间读取消息、状态同步消息等。这些消息被用来确定连接的存续情况或获得工程软件上显示的信息。没有这些消息不会影响之后发送的消息的结果。因此，我们过滤那些与状态指导无关的消息，以提高测试效率。我们分析了不同制造商提供的流量，并得出以下观察结论。

​ • 观察1：在专有协议的流量中，来自相同功能的信息具有类似的格式。具体来说，报文有相同的长度，并使用固定的字段位置。这些消息中的字段内容是固定的或循环变化的。

​ • 观察2：不相关信息的数量远远超过功能产生的信息的数量。

基于观察1，我们进行相似性分析，对来自相同功能的信息进行分组。基于观察2，我们通过过滤掉高密度的集群来识别不相关的信息群。

​ 请注意，控制协议被设计为二进制格式，不包含有意义的字符串。因此，我们设计了一种基于字节特征的多步骤聚类方法来实现消息过滤。首先，我们初始化空字符串（用十六进制数字0x00填充），并计算流量中具有相同长度的消息之间的汉明距离。然后，我们计算消息的分数。由于所有信息的分数都可能大于零，我们需要区 分 和分离 "最重要 "的分数类别。为此，我们利用DBSCAN基于密度的聚类算法[22]，将分数接近的信息分组。之后，我们选择高密度聚类中的信息进行第二步分析。在第二步中，我们记录字节字段在信息之间变化的位置（偏移）。同时，计算当该位置为某一数值时，消息中其他字节字段的变化数量。我们用<偏移量，值，数>这三个词来表达。最后，我们计算每个消息的相似度。我们仍然面临刚才的问题，所以我们还利用DBSCAN基于密度的聚类算法对高密度聚类中的消息进行分类和过滤。整个过滤过程如图5所示，其中分数和相似度的计算如算法1所示。

图5 筛选过程的例子

4.2.2 鉴定

图6 流量处理实例。 嗅探器获得的信息是A-H。B和E被过滤为不相关信息。A、C、F和H被选为测试状态。红色表示随机数据。

​ 在过滤的结果中，有许多重复的状态。例如，当我们下载项目文件时，多个文件被分别发送。在每个文件之前，都会发送一个预交互信息。假设部分消息如图6所示，A、D、G是预交互消息，C、F、H是文件下载消息。我们对A、C、F和H进行模糊测试。H状态。因为预交互消息所执行的功能是重复的，而且它们使设备进入同一功能代码的接收状态。为了减少重复状态摸索造成的时间消耗，我们选择激活不同状态的消息作为测试的种子。

​ 事实上，种子的选择是为了衡量信息之间的相似性。但我们需要考虑不同序列（不同前缀或后缀）中的类似信息的情况。我们使用汉明距离来衡量信息的相似度（算法2）。类 似 性 阈值被设置为过滤分析所产生的三联体中最小的数字。在找到满足相似条件的信息后，我们进一步测量相邻信息的相似性。如果相邻信息的长度过长（超过相似信息长度的2倍），我们认为相邻信息是相似的，因为它们是状态或文件传输信息。如果相邻的相似性条件得到满足，我们就不会根据相似信息进行模糊处理。目前的阈值是通过对不同的专有协议和功能进行多次实验得到的保守设置。最后，我们得到要测试的种子，并使用种子之前的消息作为其指导序列。

4.3 放回放规避

​ 在获得引导序列后，我们利用它们来引导设备进入我们试图测试的状态。例如，如图6所示，在对状态F进行模糊测试时，我们需要先重放消息A、C、D，然后再发送由种子F产生的测试用例。然而，通信协议通常配备了防重放机制，以确保通信的合法性。在状态引导过程中，它极大地挑战了进入特定状态的过程。根据我们的观察和研究，防重放机制可以系统地归纳为以下四类。

​ • 序列号：序列号在每个请求信息中都是按顺序增加的。当请求信息的序列号

​ •时间戳：消息的发送时间被编码为内容，接受方根据预设的超时时间确定消息的有效性。

​ • 会话/连接ID：当我们请求建立一个会话或执行某种功能时，设备会分配一个随机值作为ID。在发送给对等体之前，应在请求信息中填写该ID。如果ID与分配的ID不一致，信息将被认为是无效的。

​ • 挑战-回应：在建立连 接 的过程中，设备会发送一个随机字符串。通信软件使用内置算法、密钥和字符串来计算结果，然后将结果作为响应发送给设备。响应被正确验证后，会话将被建立。

​ 我们分析了可编程控制器协议中的防重放机制的实现。对于前两种防重放机制，制造商在实际使用中没有验证序列号和时间戳字段，因此这些机制可以被直接规避。具体来说，序列号和时间戳字段存在于控制协议中。然而，考虑到控制系统的高可用性，制造商并没有在设备中设计验证机制。当我们破坏了上述字段，并不影响后续的执行结果。

​ 会话/连接ID和挑战-回应适用于控制协议。它们可以有效地防止重放攻击。在重放过程中，我们发现Ethernet/IP CIP、S7Comm-Plus（V2）和UMAS流量中存在会话/连接ID机制。此外，Ethernet/IP CIP也有一个挑战-回应机制。为了规避sees- sion/connection ID机制，PCFuzzer首先通过比较重放信息和原始信息的响应，找到固定的ID字段位置。然后，它自动发送指定的请求以获得ID，并在随后的消息中填写收到的ID。同样地，挑战-回应机制的规避方法与会话/连接ID机制的规避方法相同。然而，结果的计算取决于存储在工程软件中的算法和密钥。因此，PCFuzzer进一步利用反向工程工具来协助计算结果[23,24]。为了使PCFuzzer更具可扩展性，我们为这两种机制 提供了模板化的配置文件，并在模糊处理过程中自动完成对相应协议的验证。对于其他协议，分析者可以通过修改配置文件完成验证互动。

4.4 网络和物理状态监控

​ 为了全面检测嵌入式设备的异常情况，我们建议同时监测设备的网络和物理状态。此外，我们测量测试中响应信息的相似性，以进一步生成种子和指导序列。

4.4.1 网络监控

​ 我们通过分析网络连接条件和响应信息来确定设备的网络状态。据我们所知，所有用于工程软件和可编程控制器之间通信的专有协议都支持TCP/IP。因此，我们在模糊测试中通过发送SYN、FIN和心跳信息来检查网络状态。这个想法常用于嵌入式设备的协议模糊测试，我们将不做详细介绍[12,13]。此外，我们使用设备检测消息来获取设备型号和制造商信息。如果不能正确获得这些信息，就意味着工程软件无法连接到设备。

​ 在模糊处理过程中，网络监控模块将测试案例的响应传递给流量分析模块。我们利用响应信息的相似性来帮助模糊器探索更多的状态。因为设备给出不同的响应通常意味着在设备中执行了不同的功能或状态[25,26]。具 体 来说，我们计算通过嗅探获得的响应信息和测试案例之间的相似性。相似性计算方法使用种子选择算法，没有相邻的比较步骤。如果不符合相似性，我们将保存相应的测试用例和引导信息，用于后续模糊处理。

4.4.2 物理检测器

​ 我们使用数字示波器来监测可编程控制器输出模块的信号。该信号反映了控制服务的 状态。信号波形的变化可分为以下两类。

​ • 瞬态干扰是指波形瞬间有一个台阶或衰减，然后又恢复正常。这种变化不能反映在示波器计算的波形参数中。

​ • 稳态干扰是指波形有一个持久的变化，这直接反映在波形的参数上（如频率和峰-峰值）。

​ 我们采用一种保守的监测策略，使用波形参 数 来确定控制服务状态。因为如果对瞬态干扰进行监测，会产生许多假阳性结果。漏洞、电磁干扰、制造水平等都可能导致瞬态干扰。在机械领域，设备被设计成可以容忍瞬态干扰，所以即使是由漏洞引起的干扰也很难影响实际控制。为了便于监测，我们将可编程控制器设定为工作状态，并输出频率为1Hz的方波（见图9）。然而，由于机械设计上的缺陷，输出波形会出现波动。数字示波器在计算参数时使用滤波算法和傅里叶来减少干扰效应。因此，这些波动的影响是可以忽略不计的。根据奈奎斯特定律，我们将采样频率设定为大于信号频率的两倍。监测器使用数字示波器的通信服务，自动获得信号的频率和峰-峰值进行比较。根据多次实验，我们发现波形的频率波动范围被设定为±5 mHZ，峰-峰波动范围被设定为±1伏。如果波形变化超过波动范围，该模块将发出警报并记录测试信息。通过这种方式，我们可以自动监测影响物理世界的漏洞。

图9 数字示波器屏幕截图

4.5 独特的脆弱性识别

​ PCFuzzer通过网络和物理状态监测检测到异常后，我们通过各种警报来识别真正的独特漏洞。嵌入式设备的协议模糊技术在没有程序执行跟踪或固件的情况下，无法确定异常的原因并有效识别真正的独特漏洞。请注意，各种警报很可能与同一个漏洞有关。例如，设备没有验证字段的长度或内容，所以所有字段在相同状态下变化的测试案例都可能触发相同的漏洞。在本文中，我们使用了一种保守的、经验性的方法来确定独特的漏洞超过警报。更具体地说，我们利用以下四个外部行为来确定是否触发了一个独特的漏洞。

​ • B1:设备不能对PING作出反应。我们通过网络状态监控器检测到它。

​ • B2: 工程软件不能连接到设备。我们通过网络响应监控器检测到它。

​ • B3：输出信号的波形发生变化。我们通过数字示波器的显示器来检测它。

​ • B4：在异常行为被触发后，我们计算出恢复设备所需的成本。

​ 对于前三种行为，它们与可编程控制器中的不同服务有关。例如，当只观察到B2时，它表明网络服务已经崩溃。当只观察到B3时，它表明控制服务已经崩溃。对于B4，我们对漏洞触发后使设备恢复工作的难度进行排序。如表1所示，设备恢复的难度从R1增加到R5。具体来说，R1意味着设备不能处理大量的信息，设备可以通过暂时中止服务或自动重启来恢复。R2意味着设备的网络服务不受影响，我们可以通过工程软件重新配置或清除错误。R3和R4意味着网络服务无法连接，或系统故障无法通过工程软件清除。因此，工程师需要到工业现场重新启动设备，或取出设备电池放电。如果上述方法不能使设备重新工作，我们必须通过设备的管理界面或存储卡重新下载固件。当制造商没有提供这种方式时，我们需要使用专业工具提取备份设备闪存芯片中的固件，并将其刻录到被破坏的设备上。

4.6 PCFuzzer的实现

​ 我们写了大约2000行的python代码来实现PCFUzzer。源流量的获取是通过aoutIT[27]实现软件的自动交互，使用Scapy[28]进行嗅探。测试用例生成的变异策略是基于KittyFuzzer实现的。每个种子的变异数量与长度成正比。在状态引导和模糊处理的过程中，网络状态、响应信息和输出信号参数被监测。PyVisa[29]被用来实现基于TCP/IP的数字示波器信号信息的获取。我们利用获得的信息来判断设备是否异常。然后，我们用日志来记录模糊测试过程中的测试顺序和报警信息，以帮助验证漏洞，并在中断后继续测试。

5. 评价

​ 数据集。我们选择了市场占有率前六位的制造商[30]的15个不同模式或固件版本的可编程控制器作为我们的模糊测试目标，其中涉及7个专有原件（表2）。设备照片和真实测试环境见附录B。

​ 基线。表3中的五种方法支持对专有协议进行模糊处理。其中，Peach、KittyFuzzer和Boo- Fuzz需要依赖协议知识并手动构建测试案例生成模板。我们选择了目前正在维护的KittyFuzzer和BooFuzz作为基线。为了构建有效的测试用例生成模板，我们使用Netzob[31]，一个先进的开源协议自动逆向工程工具，来分析协议的语法和状态机。Pulsar可以直接作为基线比较。PropFuzz的论文并没有描述模糊器的设计细节。根据其流程，它与我们接下来设置的Unguided-PCFuzzer类似。为了公平比较，我们为每个基线增加了网络和物理状态监控

​ 为了进一步证明PCFuzzer中每个模块的重要性，我们设置了NaivePCFuzzer和Unguided-PCFuzzer作为比较。Naive-PCFuzzer不进行消息过滤和选 择 ，它直接使用起源流量 进行状态引导和模糊处理。Unguided-PCFuzzer不进行状态引导，直接进行模糊处理。此外，还有许多其他流行的模糊测试工具能够通过网络通信来测试嵌入式设备，如IOTfuzzer[12]和DINAE[13]。然而，当我们复制他们的方案并将其应用于工程软件时，由于软件的复杂性和大规模，它们变得不可行。

​ 配置。我们使用泰克公司的DPO 3052数字示波器进行信号采集。我们进行模糊测试的计算机配置是CPU：i7-8750H @ 2.2 GHz和32G内存。

5.2 发现现实周围的漏洞

​ 如表2所示，PCFuzzer总共检测到26个独特的漏洞。在这些漏洞中，有20个漏洞直接影响物理世界（包括B3）。在这20个漏洞中，有13个漏洞导致了控制服务的崩溃，而不影响网络服务。换句话说，它们只能通过数字式示波器来监测。此外，在检测到的漏洞中，有16个漏洞不能通过远程操作使设备在被触发后恢复到正常工作状态。该结果表明，PCFuzzer可以有效地发现可编程控制器中的网络物理漏洞。

为了证明所发现的漏洞存在于设备系统中，与设备的控制程序无关，我们在替换了不同的控制逻辑后验证了所发现的漏洞。结果表明，由PCFuzzer发现的漏洞在任何控制逻辑下都能导致设备崩溃。然后，我们将发现的漏洞披露给相应的制造商。其中，施耐德、西门子和三菱对我们做出了回应。他们总共确认了两个0day漏洞，两个nday漏洞，其中一个已经在最新版本中修复。对于30天内没有收到回复的漏洞，我们进一步向CNVD（中国国家漏洞数据库）[32]披露。最后，有16个漏洞被分配了CNVD编号。在这些漏洞中，有4个是高危漏洞。漏洞确认的细节见附录C。

5.3 漏洞发现的效率

​ 在我们的评估中，我们选择每个制造商中发现的漏洞最多的设备作为目标。考虑到模糊处理的随机性，我们对每种方法在不同的设备上进行了三次24小时的测试。为了公平比较，我们还对KittyFuzzer和BooFuzz采取了不同的变异策略，如整体变异和逐个字节变异。最后，我们选择了最大数量的警报作为比较结果。

​ 如图7所示，在相同的时间预算内，PCFuzzer报告的警报比基线多。Pulsar没有发现任何异常，所以它和那些没有报告警报的方法都没有出 现在 图 中。在我 们根据判断 标准区分了警 报信息后，PCFuzzer也发现了更多的漏洞。我们用×来标记不同漏洞首次被发现的时间。Naive-PCFuzzer有可能发现同样的漏洞，但它会花费更长的时间。这是由于过多的不相关信息导致的吞吐量下降（第5.5节）。此外，Unguided-PCFuzzer很难发现漏洞，除非这些漏洞出现在会话建立阶段。否则，由于状态限制，几乎不可能测试出有漏洞的程序。

图7 效率评估图

5.4 流量处理效率

​ 在输入流量获取阶段（第4.1节），不同工程软件产生的信息数量约为700-1500条。为了衡量流量处理的效率（第4.2节），我们通过保持连接和嗅探大约20,000条消息来评估流量分析的成本。不同协议的流量处理时间小于两秒。PCFuzzer可以处理大量的消息。

​ 在对七种专有协议和多种功能进行实验后，多步骤聚类方法可以过滤掉不同专有协议流量中20%-40%的信息。此外，这种方法不会引入误报（由于格式相似，不同功能的消息会被过滤掉）。过滤后的结果仍然可以完成原始流量的功能，而不影响状态转移（如停止可编程控制器）。然而，在我们随机过滤10%的消息后，重新播放过滤后的流量不能完成原始功能的收集流量。这表明该过滤方法是有效的。关于种子选择方法，NaivePCFuzzer在进行所有测试后没有发现PCFuzzer发现的任何不同的漏洞

​ PCFuzzer需要重放消息来指导模糊测试期间的设备状态，这将降低吞吐量。我们设计了消息过滤和选择算法来减少对吞吐量的影响。PC- Fuzzer 是 在 KittyFuzzer 的 基 础 上 开 发 的，所以我 们 使 用KittyFuzzer作为基准，并计算每分钟发送的测试案例数量的比率。我们比较了PCFuzzer和Naive-PCFuzzer的吞吐量（图8）。开始时，三种方法的吞吐量是一样的，因为没有消息重放。随着需要重放的消息数量的增加，测试用例的发送时间间隔会变长。在完成原始标记元组测试后，新元组测试的吞吐量将得到一定程度的改善。与NaivePCFuzzer相比，PCFuzzer可以减少重放对吞吐量的影响。与KittyFuzzer相比，PCFuzzer的吞吐量有所下降。然而，状态引导使PCFuzzer能够更快地探索空间，以弥补吞吐量的减少。

5.6 漏洞利用

​ 所有发现的漏洞都可以用来触发设备的崩溃，但对现实世界的影响是不同的。对于ICS来说，导致控制服务崩溃的漏 洞 比网络服务更严重。原因是，当漏洞只导致网络服务停止工作时，可编程控制器仍然可以按照预设的逻辑正常控制执行器。所以影响物理控制将对现实世界造成更大的损失。此外，当导致物理控制崩溃的漏洞被远程触发时，工程师恢复设备的时间越长，对企业的影响就越大。这也是利用重放来停止服务和利用漏洞使服务崩溃之间的区别。

​ 除了导致设备崩溃外，这些漏洞还可能导致其他风险。由于控制服务或操作系统内存的损坏，设备无法进行物理控制。因此，如果可以构建有效的数据，我们可以通过网络通信来篡改设备的控制逻辑。然后，我们进一步分析RX7i的其中一个漏洞。在没有设备调试信息的情况下，我们通过流量分析和工程软件完成一个漏洞的利用。

​ 案例研究。我们分析了会导致崩溃的测试案例。我们发现其基于突变的信息包含两个字节50 4B（ASCII码为’PK’）和有意义的字符串SYMBOLICVARTABLE。SMT。我们提取了消息的内容并以ZIP格式解压。我们在流量中搜索具有这种特征的信息，最后，我们提取了八个文件，如MAIN.BLZ和VARIABLES.VDZ。它们是设备的项目文件，所以它们必须包含控制逻辑。我们可以通过两种方式修改项目文件。(i): 直接修改设备内存中的关键数据。(ii): 通过再次下载项目文件覆盖原始内容。我们选择了第二种方法，因为它的分析成本低，适合于黑箱。我们分析了SRTP协议，并通过构建上传请求信息获得存储在设备中的文件。然后我们用工程软件解析了八个上传的文件。我们将定时器参数从0.5秒改为2秒，并使用工程软件重新生成项目文件。最后，我们修改了流量中下载信息的文件校验和字段、长度字段和数据字段。完成上述工作后，设备输出信号周期从1秒变为4秒，我们用工程软件分析和修改项目文件。这部分工作可以通过对报文的反向分析和工程软件来实现自动化。已经有相关研究在不依赖官方工程软件的情况下反汇编和修改西门子项目文件[33-35]。这样一来，对手只需要向工业网络中的主机发送恶意软件。恶意软件可以自动上传、分析、修改和下载项目文件，而不依靠命令和控制。

5.7 扩展性

​ 为了说明PCFuzzer的可扩展性，我们测试了六个流行制造商使用的七个不同的专有协议。由于定制化和专业化的原因，目前关于可调节控制器的研究工作通常只验证两种以上的设备型号，而且很难迁移到其他型号[36-38]。

​ 然后，我们评估了为说明可扩展性所需的人力工作。如果一个分析员想分析其他具有防重放机制的专有协议，他需要进行一些必要的 人工工作。分析时间取决于防重放机制。我们使用文件比较工具，如Beyond Compare [39]，来比较重放产生的流量和原始流量。我们可以清楚地发现交互过程中的验证信息。从开始比较到完成对PCFuzzer配置文件的修改，大约需要5分钟。但与人工反向协议的语法和语义相比，这些工作是微不足道的。此外，这也是一个一次性的工作。在修改了几个在模板化的配置文件中，PCFuzzer可以为制造商的所有设备自动生成防重放规避实现。

​ 当检测到一个漏洞时，PCFuzzer会产生一个警报。分析师利用日志来重现和验证警报。此外，分析人员需要恢复设备，使其重新工作，并启动模糊器继续测试。在目前发现嵌入式设备漏洞的工作中[12,13]，这是一个需要完成的普通工作。对于不需要重新下载固件的异常情况，我们使用一个具有通信功能的开关来自动恢复设备并继续测试。对于永久性的 崩溃，我们会购买一个新的设备，并使用专业的工具来提取固件并刻录到被破坏的设备上进行恢复。在实践中，找到解决方案后，我们花了大约8个小时来完成这项工作。

6. 讨论

6.1 防御机制

​ 除了在工业网络中添加防火墙和入侵检测系统外，我们认为使可编程控制器具有有效的防御机制更为可靠。在本文中，提出了以下建议。

​ (1) 在设备和工程软件之间的连接过程中，应增加认证和加密机制。Allen Bradley使用的Ethernet/IP CIP协议引入了挑战-回应机制。西门子最新的通信协议S7Comm-Plus（V3）使用了加密保护和身份验证机制（它已经被对手破解了[40]）。它们被设计用来对抗会话劫持和重放攻击。然而，这些保护机制也是脆弱的。因为工程软件中使用的密钥是固定的。对手通过逆向工程获得密钥和算法后，他们可以与制造商的所有设备建立通信。我们建议增加一个设备和软件绑定机制。通过绑定设备的序列号和软件的激活码，可以防止流氓工程软件的连接。这也确保对手不能通过分析一个设备来威胁其他设备。

​ (2)在设备中读取和写入数据时，应划分权限。制造商应该提供密码保护来限制用户操作。此外，制造商应该在设备端增加一个数据正确性和有效性的验证机制，特别是对于项目文件。目前，设备中的非网络服务无条件地信任通过网络服务写入内存的数据。数据的正确性只在工程软件中检查。我们建议，当设备收到数据时，应该检查其格式和校验。

​ (3) 固件的分析要比工程软件复杂得多。制造商对固件使用专有的加密和压缩算法。因此，制造商应在设备中存储重要的算法或密钥。此外，应在软件中加入反调试和反拆卸保护。

6.2 局限性和未来开展工作

​ 可编程控制器的私有化和定制化给漏洞的发现带来了巨大的困难。通过使用网络和物理监控器的流量来驱动PCFuzzer，我们发现并区分了可编程控制器中的漏洞。然而，PCFuzzer的工作过程需要琐碎的手工作业。此外，对真实设备的依赖也是它的一个局限性原因。因此，对于可编程控制器来说，研究具有可移植性和保真度的仿真方案是非常必要的。在未来的工作中，我们计划研究实时操作系统的仿真方案，如VxWorks、FreeRtos和ThreadX。这种类型的操作系统被广泛用于时间关键型设备中。作为单片机系统，应用程序和内核是在一个二进制文件中编译的，而且没有用户模式和内核模式之分。然后我们根据仿真方案发现并分析基于实时操作系统的二进制程序的漏洞。

7. 相关工作

7.1 攻击和防御

​ 我们把对可编程控制器的攻击分为两类。本地攻击，对手通过寻找硬件接口的物理访问来完成攻击。JTAG是制造商隐藏在设备主板上的一个调试接口。Zachry等人[36]和Garcia等人[5]在Allen Bradley的1769上发现了隐藏的JTAG，证明了通过该接口伪造固件攻击的可能性。这些工作没有资格在实际环境中实施，因为物理访问和完全拆卸设备的条件很严格。远程攻击，对手通过网络修改控制程序是很常见的。Johannes Klick等人[51]使用STL语言（可编程控制器的本地编程语言）来实现S7-300的后门。基于这项工作，Ralf Spenneberg等人[37]实现了蠕虫病毒在西门子S7-1200中的传播。此外，通过篡改控制程序[35,52,53]或利用第三方库的漏洞[54,55]，也有可能劫持可编程控制器。上述攻击对对手的要求很高，需要很多逆向分析来协助生成恶意代码。此外，这些攻击方法也是定制的。它不适合于实验中的其他型号的设备。

​ 对应上述的攻击，我们对防御措施的总结如下。对于本地攻击，引入数字签名、可信计算等来防止对手的恶意篡改和替换[56,57]。对于远程攻击，研究人员通过减少加密和认证的开销，使保护机制适用于ICS中的网络通信[58-60]。同时，通过流量过滤非法数据监控和入侵监测也是一种有效的保护方案[61,62]。对于通过篡改控制程序的后门和蠕虫等攻击，K Yau等人[63]和H. Senyondo等人[64]提出使用符号执行或机器学习方法进行检测。此外，蜜罐通常被部署在ICS中，以诱捕攻击并收集对手的信息[65]。上述防御措施不能有效防止对手使用类似于正常信息的有效载荷来发动崩溃攻击。

7.2 漏洞发现

​ 协议摸索是一种有效的方法来发现嵌入式设备的漏洞。如表3所示，我们根据ICS设备协议模糊测试的评估标准[42]对我们的工作进行了比较。从结果中，我们可以发现，我们的工作优于所有现有的技术。标准解释如下。

​ • 输入工艺：根据不同的场景，测试用例要么根据协议知识的模板生成，要么根据选定的种子进行突变。此外，测试用例的生成是在发送时计算（在线）还是预先计算（离线）是影响测试效率的一个重要因素。

​ • 操作模式：为了有效地模糊有状态协议，模糊器必须跟踪被测协议的状态。后置测距意味着模糊器支持序列，而不是用单个消息进行模糊测试。重新排列的模糊测试只与有状态的协议有关，因为有状态的协议可能有一个错误的有效数据顺序。此外，模糊器在与被检查设备的互动中必须是自适应的。这使模糊器能够对设备的响应作出反应，并且需要在有状态协议中达到某些状态。指导性模糊器使用被测设备的反应来生成新的种子，以指导模糊器探索更多的输入空间。如果模糊器配备了特殊的手段来监测ICS的输出，而不是基于以太网的输出，就可以提供ICS的监测。

​ • 可扩展性：如果模糊器是学习型的，它可以根据协议的特点开始有效的模糊，而不依赖协议知识。相比之下，其他模糊器则依赖专家知识。有些模糊器是为一组特定的协议量身定做的。另一些则提供了扩展协议的机会。此外，专有协议在ICS中广泛存在，模糊器应具备支持有效测试的能力。

​ 仿真是一种流行的方法，用于协助嵌入式设备的模糊测试。然而，全系统仿真方案不能轻易实现对定制的实时操作系统的仿真[6]。此外，目前的仿真技术不能提供完全虚拟化的高保真仿真技术[7,38]。因此，依赖代码执行反馈的技术，如AFLfast[66]、AFLpro[67]和StFuzzer[68]，并不适合这种设备模糊测试。ICSFUZZ[69]和RVFuzzer[8]提出了部分二进制文件模拟。但它们只适合于发现控制文件中的漏洞，系统漏洞无法发现。对于家用嵌入式设备，如路由器和摄像头，IoTFuzzer[12]和Diane[13]通过分析通信APP协助生成测试案例。这些方法可以应用于专有协议的模糊测试。然而，工业软件的大规模和高复杂性使其无法进行自动分析。Hui Zhao等人[70]提出通过机器学习提取协议特征来辅助模糊分析。然而，这种方法在文本协议中效果良好。对于二进制协议，很难有效地获得协议特征。在本文中，我们利用专有协议的流量来驱动模糊器，并设计过滤和选择方法来有效地模糊可编程控制器。

​ 对于静态分析，嵌入式设备固件的污点分析也是一种流行的技术。Dtaint[71]利用别名分析技术恢复了路由器固件的Web服务器的数据流，然后追踪网络数据流以检测污点型漏洞。Karonte[72]和Satc[73]利用关键字和进程间通信范式，恢复了固件中不同二进制文件之间的数据关系，并基于符号执行进行污点分析。然而，可编程控制器的固件很少在互联网上公开。即使我们能从设备上得到固件，未知的程序加载信息（如加载基础广告架构和分段信息）、固件加密和剥离的二进制文件使我们无法使用静态分析方法。此外，对于这样的逻辑设备，往往需要配合运行信息才能准确找到漏洞。

8. 总结

​ 虽然IIOT的发展带来了生产效率的提高，但它也给工业生产带来了风险。由于可编程控制器是网络空间和物理世界之间的通信桥梁，它们更有可能成为攻击的目标。然而，可编程控制器的高度定制化和私有化使得目前流行的 漏洞发现方案不适合或没有效率。在本文中，我们建议对与可编程控制器相关的工程软件进行操作，以产生能够触发设备关键状态的原始流量，然后推断出能够快速引导目标进入不同状态的最小序列，从而进行有效的模糊处理。同时，对设备的网络和物理行为进行监测，以发现异常情况。我们实现了PCFuzzer，它有效地发现了可编程控制器的网络物理漏洞。这些漏洞可以被对手重新利用，而不需要了解业务，导致设备失去对执行器的控制。此外，被攻击的设备需要大量的时间来恢复正常运行，这严重影响了现实世界。PCFuzzer在六个流行制造商的15个设备中发现了26个漏洞，其中20个可以直接影响物理控制。

[1] Ricardo Vaz, et al., Venezuela’s power grid disabled by cyber attack, Green LeftWkly (1213) (2019) 15.
[2] Defense Use Case, Analysis of the cyber attack on the Ukrainian power grid,2016, Electricity Information Sharing and Analysis Center (E-ISAC), 388.
[3] R. Langner, Stuxnet: Dissecting a cyberwarfare weapon, IEEE Secur. Privacy 9(3) (2011) 49–51.
[4] David Formby, Srikar Durbha, Raheem Beyah, Out of control: Ransomware forindustrial control systems, in: RSA Conference, Vol. 4, no. 6, Computer Science,Singapore, 2017.
[5] Luis Garcia, Ferdinand Brasser, Mehmet Hazar Cintuglu, Ahmad-Reza Sadeghi,Osama A Mohammed, Saman A Zonouz, Hey, my malware knows physics!attacking PLCs with physical model aware rootkit, in: NDSS, NDSS, San Diego,California, 2017.
[6] Yaowen Zheng, Ali Davanian, Heng Yin, Chengyu Song, Hongsong Zhu, LiminSun, Firm-AFL: high-throughput greybox fuzzing of iot firmware via augmentedprocess emulation, in: 28th {𝑈𝑆𝐸𝑁𝐼𝑋} Security Symposium ({𝑈𝑆𝐸𝑁𝐼𝑋}Security 19), USENIX, SANTA CLARA, CA, USA, 2019, pp. 1099–1114.
[7] Bo Yu, Pengfei Wang, Tai Yue, Yong Tang, Poster: Fuzzing iot firmware viamulti-stage message generation, in: Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, Association for ComputingMachinery, New York, NY, USA, 2019, pp. 2525–2527.
[8] Taegyu Kim, Chung Hwan Kim, Junghwan Rhee, Fan Fei, Zhan Tu, GregoryWalkup, Xiangyu Zhang, Xinyan Deng, Dongyan Xu, RVFuzzer: Finding inputvalidation bugs in robotic vehicles through control-guided testing, in: 28thUSENIX Security Symposium (USENIX Security 19), USENIX Association, SantaClara, CA, ISBN: 978-1-939133-06-9, 2019, pp. 425–442, URL https://www.usenix.org/conference/usenixsecurity19/presentation/kim.
[9] W. You, X. Wang, S. Ma, J. Huang, X. Zhang, X. Wang, B. Liang, Profuzzer: Onthe-fly input type probing for better zero-day vulnerability discovery, in: 2019IEEE Symposium on Security and Privacy, SP, IEEE, San Francisco, CA, 2019,pp. 769–786, http://dx.doi.org/10.1109/SP.2019.00057.
[10] Z. Luo, F. Zuo, Y. Shen, X. Jiao, W. Chang, Y. Jiang, ICS protocol fuzzing:Coverage guided packet crack and generation, in: 2020 57th ACM/IEEE DesignAutomation Conference (DAC), IEEE, San Francisco, California, 2020, pp. 1–6,http://dx.doi.org/10.1109/DAC18072.2020.9218603.
[11] Yuekang Li, Bihuan Chen, Mahinthan Chandramohan, Shang-Wei Lin, YangLiu, Alwen Tiu, Steelix: Program-state based binary fuzzing, in: Proceedingsof the 2017 11th Joint Meeting on Foundations of Software Engineering, in:ESEC/FSE 2017, Association for Computing Machinery, New York, NY, USA,ISBN: 9781450351058, 2017, pp. 627–637, http://dx.doi.org/10.1145/3106237.3106295.
[12] Jiongyi Chen, Wenrui Diao, Qingchuan Zhao, Chaoshun Zuo, Zhiqiang Lin,XiaoFeng Wang, Wing Cheong Lau, Menghan Sun, Ronghai Yang, Kehuan Zhang,IoTFuzzer: Discovering memory corruptions in IoT through app-based fuzzing, in:NDSS, NDSS, San Diego, California, 2018.
[13] Nilo Redini, Andrea Continella, Dipanjan Das, Giulio De Pasquale, Noah Spahn,Aravind Machiry, Antonio Bianchi, Christopher Kruegel, Giovanni Vigna, DIANE:Identifying fuzzing triggers in apps to generate under-constrained inputs for IoTdevices, in: Proceedings of the IEEE Symposium on Security and Privacy, IEEE,virtual, 2021.
[14] Cisco, Kittyfuzzer, 2020, https://kitty.readthedocs.io/en/latest/.
[15] Joshua Pereyda, Boofuzz, 2020, https://github.com/jtpereyda/boofuzz.
[16] Hugo Gascon, Christian Wressnegger, Fabian Yamaguchi, Daniel Arp, KonradRieck, Pulsar: Stateful black-box fuzzing of proprietary network protocols, in:Bhavani Thuraisingham, XiaoFeng Wang, Vinod Yegneswaran (Eds.), Securityand Privacy in Communication Networks, Springer International Publishing,Cham, ISBN: 978-3-319-28865-9, 2015, pp. 330–347.
[17] Li Da Xu, Wu He, Shancang Li, Internet of things in industries: A survey, IEEETrans. Ind. Inf. 10 (4) (2014) 2233–2243.
[18] SHODAN, Shodan, 2021, URL https://www.shodan.io/explore/category/industrial-control-systems.
[19] A. Mirian, Z. Ma, D. Adrian, M. Tischer, T. Chuenchujit, T. Yardley, R. Berthier,J. Mason, Z. Durumeric, J.A. Halderman, M. Bailey, An internet-wide view ofICS devices, in: 2016 14th Annual Conference on Privacy, Security and Trust,PST, 2016, pp. 96–103, http://dx.doi.org/10.1109/PST.2016.7906943.
[20] Justin Searle, Plcscan, 2015, https://github.com/meeas/plcscan.
[21] Gordon Fyodor Lyon, Nmap Network Scanning: the Official Nmap Project Guideto Network Discovery and Security Scanning, Insecure, USA, 2009.
[22] Martin Ester, Hans-Peter Kriegel, Jörg Sander, Xiaowei Xu, et al., A density-basedalgorithm for discovering clusters in large spatial databases with noise, in: Kdd,Vol. 96, no. 34, 1996, pp. 226–231.
[23] Hex rays, IDA pro, 2020, https://hex-rays.com/ida-pro/.
[24] OllyDbg, Ollydbg, 2014, https://www.ollydbg.de/.
[25] Xiaotao Feng, Ruoxi Sun, Xiaogang Zhu, Minghui Xue, Sheng Wen, Dongxi Liu,Surya Nepal, Yang Xiang, Snipuzz: Black-box fuzzing of IoT firmware via messagesnippet inference, 2021, arXiv preprint arXiv:2105.05445.
[26] Shuangpeng Bai, Dongliang Fang, Yue Sun, Hui Wen Puzhuo Liu, Limin Sun,DSS: Discrepancy-aware seed selection method for ICS protocol fuzzing, in: 19thInternational Conference on Applied Cryptography and Network Security, ACNS,Kamakura, Japan, 2021.
[27] AutoIt, Autoit tools, 2020, URL https://www.autoitscript.com/site/.
[28] Philippe Biondi and the Scapy community, Scapy, 2020, https://scapy.net/.
[29] Torsten Bronger, Pyvisa, 2020, https://pyvisa.readthedocs.io/en/latest/.
[30] PLC manufacturers: The latest PLC brands, rankings and revenues, 2020, https://ladderlogicworld.com/plc-manufacturers/.
[31] Georges Bossert, Netzob: Protocol reverse engineering, modeling and fuzzing,2020, URL https://github.com/netzob/netzob.
[32] CNCERT/CC, China national vulnerability database, 2020, URL https://www.cnvd.org.cn/.
[33] pnfsoftware, JEB decompiler for S7 PLC, 2021, URL https://www.pnfsoftware.com/jeb/plc.
[34] Anastasis Keliris, Michail Maniatakos, Icsref: A framework for automated reverseengineering of industrial control systems binaries, in: NDSS, NDSS, San Diego,California, 2018.
[35] Sushma Kalle, Nehal Ameen, Hyunguk Yoo, Irfan Ahmed, Clik on plcs! attackingcontrol logic with decompilation and virtual plc, in: Binary Analysis Research(BAR) Workshop, Network and Distributed System Security Symposium, NDSS,NDSS, San Diego, California, 2019.
[36] Zachry Basnight, Jonathan Butts, Juan Lopez Jr., Thomas Dube, Firmwaremodification attacks on programmable logic controllers, Int. J. Crit. Infrastruct.Prot. 6 (2) (2013) 76–84.
[37] Ralf Spenneberg, Maik Brüggemann, Hendrik Schwartke, Plc-blaster: A wormliving solely in the plc, Black Hat Asia 16 (2016) 1–16.
[38] Marius Muench, Dario Nisi, Aurélien Francillon, Davide Balzarotti, Avatar2: Amulti-target orchestration platform, in: Proc. Workshop Binary Anal. Res., Vol.18, Colocated NDSS Symp., NDSS, San Diego, USA, 2018, pp. 1–11.
[39] Scooter Software, Beyond compare, 2021, https://www.scootersoftware.com/.
[40] Eli Biham, Sara Bitan, Aviad Carmel, Alon Dankner, Uriel Malin, Avishai Wool,Rogue7: Rogue engineering-station attacks on S7 simatic PLCs, in: USA Blackhat,Blackhat, USA, 2019.
[41] Serge Gorbunov, Arnold Rosenbloom, Autofuzz: Automated network protocolfuzzing framework, IJCSNS 10 (8) (2010) 239.
[42] Steffen Pfrang, David Meier, Michael Friedrich, Jürgen Beyerer, Advancingprotocol fuzzing for industrial automation and control systems, in: ICISSP, 2018,pp. 570–580.