[原创]艾默生DeltaV DCS控制器固件安全分析研究-IoT安全-看雪安全社区

# 1 前言
艾默生 DeltaV分布式控制系统（DCS）是全球流程工业（如石油化工、制药、电力等）中广泛使用的核心控制平台。作为整个生产过程的“大脑”，DeltaV系统中的控制器（如MD Plus系列）负责执行复杂的逻辑控制、数据采集与现场总线通信。由于其直接关系到关键基础设施的稳定运行，一旦控制器遭到恶意攻击或篡改，可能会导致严重的生产事故甚至环境灾难。
 ![图片描述](upload/attach/202607/907750_XRRUQ25FQNTGFRW.webp)
近年来，随着工业网络与IT网络的深度融合，针对DCS系统的网络威胁日益增加。然而，由于DCS系统生态相对封闭，针对其底层固件的深度安全研究在公开领域并不多见。出于对关键基础设施安全的关注，笔者近期对艾默生 DeltaV控制器的固件进行了深度的逆向分析与安全研究。本文将以DeltaV MD Plus控制器为例，从固件获取、自定义格式解密、符号恢复以及安全面探索等角度，分享工控设备固件分析的研究思路与实操方法。

# 2 信息收集与固件获取
开展固件分析的第一步是获取目标固件。DeltaV系统采用中心化的固件分发架构，控制器的固件更新通常通过DeltaV工作站经以太网下发至现场控制器。

笔者通过对DeltaV工作站软件的安装目录进行梳理，在工程师站点的安装目录下发现了完整的固件文件集合。
 ![图片描述](upload/attach/202607/907750_XDJJDZQK8SRZ596.webp)
研究对象MD Plus控制器最核心的两个文件是 rev7-AppR.srec（应用层固件）和 rev7-OSR.srec（QNX IFS操作系统镜像）。值得注意的是，这些固件文件以明文形式直接存储于工作站的磁盘目录中，无需任何额外的认证或权限即可获取。这种在分发和存储链路中缺乏访问控制保护的设计，为后续的安全研究提供了直接的切入点。
# 3. 固件格式分析与解密思路
获取到的固件文件采用了Motorola S-Record（SREC）格式，这是一种古老的ASCII编码二进制传输格式。首先编写Python脚本，将SREC文件中的地址、校验和等封装信息剥离，还原出了精确的10MB纯二进制镜像数据。
 ![图片描述](upload/attach/202607/907750_GNW3KFVCYJRUY5M.webp)
如图所示，每一行代表一条记录，以第2行为例：起始的S3表示记录类型（32位地址数据记录）；紧随其后的25为字节计数（十六进制0x25，表示后续内容的字节总数）；00400000为32位目标地址，指示该段数据应烧录至内存的起始位置；中间长串的十六进制字符为实际的数据载荷；行末的B2为校验和，用于验证该行数据在传输过程中的完整性。通过解析SREC格式，剥离地址、类型和校验信息，即可还原出连续的二进制镜像文件。

## 3.1 多条目打包结构发现
对10MB的二进制镜像进行初步分析时，发现其中散布着大量可读的ASCII字符串（如“bootscript2”、“login”、“DvApp”等）。进一步观察发现，这些字符串总是出现在某个固定模式的8字节标记（Marker）之前，随后紧跟对应的数据内容。
 ![图片描述](upload/attach/202607/907750_FRJYSHKCAKYDUDT.webp)
这表明整个镜像并非一个单一的文件，而是一个多条目打包容器。通过编写自动化扫描脚本，笔者成功识别并提取了镜像中的全部109个命名条目，涵盖了启动脚本、用户认证程序、网络工具以及最核心的主控应用程序 DvApp。其中，DvApp条目占据了约50%的空间（约5.2MB），包含了控制器的核心工业协议栈与业务逻辑。
 ![图片描述](upload/attach/202607/907750_444CZYKQVC4PTRJ.webp)

## 3.2 自定义压缩算法识别
尝试使用 binwalk、file 等常规工具对 DvApp 数据进行分析，均无法识别其格式，且未发现任何标准压缩文件（如 ZIP、GZIP）的魔数签名。通过十六进制编辑器直接观察文件头部（如下图所示），我们发现前 16 字节具有明显的结构化特征，而非随机数据，这暗示了自定义封装协议的存在。
 ![图片描述](upload/attach/202607/907750_YC5KRGPUSSTWA4R.webp)
具体解析这 16 字节头部数据（均为小端序）：
偏移 0x00-0x03 (78 3A 86 00)：解析值为 0x00863A78，即十进制的 8,796,792。这代表解压后的固件总大小。
偏移 0x04-0x05 (00 20)：解析值为 0x2000，即 8,192。这代表每个压缩块解压后的固定输出大小。
偏移 0x06-0x07 (01 00)：解析值为 1，标识压缩格式的版本号。
偏移 0x0A-0x0B (5E 0C)：解析值为 0x0C5E（3166），这是链式结构的第一个跳转参数（w1）。

观察头部之后的数据，呈现出典型的高熵特征，符合强压缩数据的特征。通过对压缩数据流的比特流模式进行进一步的手动分析与交叉比对，确认其底层采用了 UCL NRV2B 轻量级压缩算法。然而，DeltaV 并未直接套用标准的 UPX 格式，而是基于上述 16 字节头部进行了完全自定义的分块封装（每块固定输出 8KB），这正是导致 binwalk 无法识别、UPX 无法解压等所有标准工具全部失效的根本原因。

## 3.3 分块链式结构破解
为了还原数据，必须搞清楚其分块结构。通过对比压缩块末尾与下一个有效块开始之间的数据，发现每个块之间存在一个8字节的固定格式结构体，被命名为 Inter-Block Header（IB）。
如下图所示，IB的8字节结构为：
w1字段（示例值0x0C5E），表示从前一个IB到当前IB的距离
w2字段（示例值0X0BE9），表示从当前IB到下一个IB的距离
固定标记 00 20 00 20（0x0020 = 8192，确认每块解压输出大小）
 ![图片描述](upload/attach/202607/907750_XBUHUXKN6HJ95GX.webp)

在5.2MB的数据流中搜索该固定模式，共定位到1,072个有效IB。
 ![图片描述](upload/attach/202607/907750_T4JKZG3P2622DAC.webp)
这些IB通过特定的偏移字段形成了28条独立的链（段）。基于此规律，编写脚本可实现所有压缩块起始位置的精准定位。
## 3.4 跨块字典引用与完整恢复
在实现解压器时遇到了一个核心难题：部分压缩块在解压时，其LZ77匹配引用的回退距离超出了当前块已产生的输出数据量。经过深入分析发现，该固件的压缩字典窗口跨越了多个块的输出。

为此，在解压器中引入了全局缓冲区机制，将所有已解压块的输出按顺序拼接，供后续块引用历史数据。针对少数段边界块出现的非压缩数据间隙，采取了部分解压加零填充的兼容性处理策略。
 ![图片描述](upload/attach/202607/907750_NT4BPX9W98Y3YAZ.webp)
最终，成功将5.2MB的压缩数据完整还原为8,796,792字节的PowerPC大端ELF二进制文件。通过解析ELF文件中的DYNAMIC段，成功恢复了476个动态链接符号和313个PLT重定位条目，完成了从“黑盒”到“白盒”的关键转变。
 ![图片描述](upload/attach/202607/907750_TKB3AZWRA65ZXYV.webp)

# 4  固件初步分析与实战探索
将恢复出的完整ELF文件导入分析工具进行静态分析。首先通过架构特征确认其为PowerPC大端序，与目标硬件MPC8360E处理器完全匹配。随后，利用恢复出的符号表编写脚本，在IDA中批量进行函数重命名，大幅提升了逆向分析的效率。
 ![图片描述](upload/attach/202607/907750_DRM4HSTTUHPQANH.webp)
在此基础上，我们对固件的安全攻击面进行了初步探索：
## 4.1 网络通信模块分析
工控设备的网络服务往往是外部攻击的首选目标。通过定位固件中的网络监听与处理函数，发现控制器开放了多个用于诊断和协议通信的网络端口。如私有协议通信端口18507
 ![图片描述](upload/attach/202607/907750_FQRDABKYYC675VU.webp)
分析表明，部分网络服务在处理外部请求时，缺乏严格的身份认证机制。同时，在某些协议解析逻辑中，存在对外部输入数据长度和边界校验不严的情况。这种设计缺陷在特定条件下可能被恶意利用，导致控制器网络服务异常甚至引发拒绝服务（DoS）风险。
 ![图片描述](upload/attach/202607/907750_G9T3CCHRWTJ4BME.webp)
## 4.2 危险函数与系统命令分析
通过对固件全量代码进行敏感函数扫描，发现固件在实现部分业务逻辑时，直接使用了不安全的字符串处理函数（如未限制长度的复制和格式化函数）。
 ![图片描述](upload/attach/202607/907750_ZWQ2KMMPPYV4KVJ.webp)
更为值得关注的是，固件中存在多处直接调用系统命令执行函数的情况。虽然部分调用使用的是硬编码的内部管理命令，但也有部分调用的参数来源于外部网络交互或动态拼接。如果攻击者能够控制这些参数的来源，则可能引发命令注入等严重安全问题，进而影响控制器的底层操作系统环境。
 ![图片描述](upload/attach/202607/907750_QB744H8F3RZFYPH.webp)
# 5  防护建议
针对DeltaV系统及类似DCS控制器的潜在安全风险，工控系统用户及运维人员应采取积极的纵深防御措施：

严格的网络隔离：将DCS控制器部署在独立的安全控制区，通过工业防火墙严格限制外部网络（尤其是办公网和互联网）对控制器的直接访问。
安全监控与审计：部署工控安全监测与审计系统，对网络中的异常通信流量、非法的端口扫描以及异常的固件升级行为进行实时监控与告警。
厂商侧安全加固建议：建议设备厂商在后续产品设计中，引入强加密算法与数字签名机制以保护固件的机密性与完整性；同时在代码层面全面替换不安全函数，并为所有网络服务增加强制身份认证机制。

# 6 总结
本文以艾默生DeltaV DCS系统的MD Plus控制器为研究对象，从固件获取、自定义分块压缩格式解密、全局跨块解压、符号表恢复等多个角度，全方位阐述了工控安全研究中固件深度分析的思路与方法。通过一系列技术攻关，成功突破了厂商自定义的压缩保护壁垒，还原了完整的可分析固件，并初步揭示了其在网络通信与代码实现层面存在的潜在安全风险。

在AI时代，本文所揭示的这些脆弱性正变得越来越危险。大语言模型和自动化攻击工具的快速发展，已经能够自动分析二进制代码、识别漏洞模式、生成针对性攻击载荷。原本需要数周手工逆向的工作可能被压缩到数小时，原本需要深厚专业知识的漏洞挖掘可能变成"一键式"自动化攻击。而我们的工业控制器呢？它们依然运行着多年前的实时操作系统，依然使用没有边界检查的字符串函数，依然在没有身份认证的网络端口上监听请求。这种"AI武装的攻击者"与"脆弱不堪的控制器"之间的巨大鸿沟，正是未来工控安全面临的最大挑战。

我们不能再指望"隐蔽即安全"，不能再依赖"攻击者不懂工控协议"的侥幸心理。厂商必须从设计阶段就引入纵深防御理念，采用硬件级安全启动与固件签名验证；用户需要部署基于行为分析的异常检测系统，建立固件完整性校验机制等等。工业控制系统承载着国家关键基础设施的运行，在AI浪潮席卷而来之际，我们必须行动起来，筑牢工业控制系统的防线。

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最新回复 (9)
xingbing 雪币： 158 活跃值： (5786) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 2 楼学习！ 2026-7-10 15:36 0
wx_WantC 雪币： 772 活跃值： (578) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 43 粉丝 1 关注私信	wx_WantC 3 楼感谢楼主，学习学习 2026-7-12 15:26 0
mb_egojlewe 雪币：能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 21 粉丝 0 关注私信	mb_egojlewe 4 楼学习，感谢 2026-7-18 12:57 0
mb_evdofnub 雪币：能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	mb_evdofnub 5 楼 666 2026-7-18 13:31 0
Gryffindoss 雪币： 635 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 126 粉丝 0 关注私信	Gryffindoss 6 楼 66 2026-7-19 19:02 0
anywhere杨雪币： 206 活跃值： (1323) 能力值： ( LV4，RANK：40 ) 在线值：发帖 58 回帖 449 粉丝 3 关注私信	anywhere杨 7 楼 666 2026-7-20 17:58 0
LoginUser 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 48 粉丝 0 关注私信	LoginUser 8 楼感谢分享 2026-7-22 09:21 0
黄鹏骏雪币： 244 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	黄鹏骏 9 楼我将辞职在家好好研究研究这个文章 2026-7-24 10:58 0
方向感雪币： 1920 活跃值： (6233) 能力值： ( LV3，RANK：30 ) 在线值：发帖 41 回帖 739 粉丝 26 关注私信	方向感 10 楼 666 2026-7-25 11:02 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

[原创]艾默生DeltaV DCS控制器 固件安全分析研究

[原创]艾默生DeltaV DCS控制器固件安全分析研究