[出自:jiwo.org]

MMS简介

MMS(Manufacturing Message Specification)中文翻译为制造报文规范，在介绍MMS之前我们先简单科普一下IEC61850标准。

IEC61850是电力系统自动化领域唯一的全球通用标准，而本文主要介绍的MMS就是运用在IEC61850标准站控层和间隔层之间，MMS通过对实际设备进行面向对象建模方法，实现了网络环境下不同制造设备之间的互操作。在2015年前MMS在电力系统远动通信协议中并未应用，但是IEC61850标准将其引入电力自动化领域，将其核心ACSI服务直接映射到MMS标准

由于MMS是由ISO技术委员会184(TC184)开发和维护的一种涉及用来在设备或程序之间传送实时数据和监督信息的信息传递系统的国际标准，它的定义如下。

每个设备中必须存在一组标准对象(standard objects)，可以执行如，读写事件信令(event signaling)等操作。

VMD是主要对象，诸如变量，域，日志，文件等都属于VMD范围内。

在客户端和服务器站之间有一组用来监视或控制上述对象的一组标准信息。

一组用于在传输时将信息映射到位和字节的编码规则。

说完MMS的定义后，我们来看一看MMS的协议栈。其实早在1990年就已经根据ISO / IEC 9506-1和ISO / IEC 9506-2两个标准进行了标准化，但是由于OSI的实施不是很简单，所以这个原始版本并没有流行。现在流行的MMS是于1999年波音公司根据互联网协议创建的全新版本。以下是新版MMS堆栈。

相比于以前的版本，新版协议的前三层没有变化，使用了与以前相同的OSI协议，而底层四层则更依赖于TCP ARP等协议而非原本的RFC1006。

MMS协议

介绍完之前的一些基础，终于要开始分析MMS数据包了，我们先来看下面这个IEC61850的数据包。

我们能清楚地看到这个数据包的组成,首先是TCP的三次握手，建立连接，这段内容是计算机网络的核心知识，相信大家都有所了解，这里就不再多说了。接下来是两个COTP包。

COTP

简单的介绍一下，COTP(ISO 8073/X.224 COTP Connection-Oriented Transport Protocol)，翻译为面向连接的传输协议，这个协议的作用就是进行传输连接的建立，我们仔细观察上图中的两个COTP包，分别被标记为CR和CC,是connect request和connet confirm，功能就是COTP的连接包和返回包。一下我们来分别看一下他们的结构组成。

1. COTP Connection Packet

我们从上面的图可以看出，主要由如下的结构(前方数字代表对应字节)。

0 Length:无符号整型，1byte，用于标记COTP不包括length的后续内容长度，一般为17byte(但我看到的几个包都是14…)

1 PDU Type:无符号整型，1byte，标记状态，注意上图中这行后面的0x0e，代表连接请求，还有其他类型如下所示。

• 0×1: ED Expedited Data，加急数据
• 0×2: EA Expedited Data Acknowledgement，加急数据确认
• 0×4: UD，用户数据
• 0×5: RJ Reject，拒绝
• 0×6: AK Data Acknowledgement，数据确认
• 0×7: ER TPDU Error，TPDU错误
• 0×8: DR Disconnect Request，断开请求
• 0xC: DC Disconnect Confirm，断开确认
• 0xD: CC Connect Confirm，连接确认
• 0xE: CR Connect Request，连接请求
• 0xF: DT Data，数据传输
• 2~3 Destination reference:2bytes,目的地参照符，用来标识目标。
• 4~5 Source reference:2bytes,来源参考，用来标识来源。
• 6 option:1byte，其中有Extended formats和No explicit flow control,值是布尔型。
• 7~ parameter :参数，一般为11bytes,一般包含Parameter code,Parameter length,Parameter data三部分。

这些就是CR包的组成部分，接下来我们看看CC包。

2. COTP Fuction Packet

其实这两个包并没有什么区别，我们对比一下这两个包，主要就是在PDU Type上由0x0e变成0x0d，标志着由连接包变成返回包。

到这里我们这COTP也基本分析完成了，接下来终于要进入我们正题MMS了。

MMS

我们看一下下面的数据包，

我们能看到其中包括四种MMS包，分别是initiate-RequestPDU(启动-请求PDU)、confirmed-RequestPDU(确认-请求PDU)、initiate-ResponsePDU(启动-应答PDU)、confirmed-ResponsePDU(确认-应答PDU)，接下来我们来详细的看一下这四种。

1. initiate-RequestPDU

首先看一下这个包，我们可以看到它的组成有以下几个方面

• 5~7 localDetailingCalling: 本地详细呼叫，这个字节数不固定，取决于后面数字大小，根据国家规定通用MMS要求里写的这个值不应小于64，但推荐至少支持512个8位位组。
• 10 proposedMaxServOutstandingCalling：提出最大服务端呼叫，这个和下面部分内容都和confirmed-RequestPDU有着联系，具体放到下面再讲。
• 13 proposedMaxServOutstandingCalled: 提出最大服务端被呼叫
• 15 propodedDataStructureNestingLevel:预先编码的数据结构嵌套级别,下面简单提一下这个嵌套级别。

对于结构类型数据，如SEQUENCE OF内容Value字段中是一个或多个数据的TLV，形成分层结构，从外层开始层层嵌套最后嵌套成最简单的数据类型为止。如下图所示。

最后一部分是MMSInitRequestDetail(MMS初始请求详细信息)主要由proposedVersionNumber、proposedParameterCBB、services Supported Calling组成，分别标识 相关参数和服务支持的参数，我们着重看一下最后一部分，存在着identify、fileopen等参数，很明显这部分就是标记着全包内容的管理。

2. initiate-ResponsePDU

我们再来看看initiate-ResponsePDU的内容，总体结构和initiate-RequestPDU相似，重复之处就不再多说了，这里重点看一下这几个部分。

• negociatedMaxServoutstandingCalling:议最大服务端呼叫
• negociatedMaxServoutstandingCalling：议最大服务端被呼叫
• negociatedDataStructureNestingLevel：相关的数据结构嵌套级别

我们可以发现，initiate-ResponsePDU的这三条和上面initiate-RequestPDU的内容是相对应的，这是因为initiate-ResponsePDU的作用就是对initiate-RequestPDU的内容进行应答，所以要将传递内容进行检测，这也是为什么连这三条后面参数也是一致的。

再看mmsInitResponseDetail的内容，前两条也是作为对之前内容回答，内容一致就不分析了。直接看最后的serviceSupportedCalled,这一段内容里存在很多参数，主要作用就是对之前包中内容的回应，传递一个回复服务端呼叫的内容。

3. confirmed-RequestPDU

相比于之前的两个包，剩下的就简单多了，还是先看内容。

• invokeID:调用者ID，作为数据包唯一标识存在
• confirmedServiceRequest：确认服务请求，后接服务内容，如本次就是getNameList,像这样的服务还有诸如read、write、getVariableAccessAttributes、getNamedVariableListAttributes、fileOpen、fileRead、fileClose、fileDirectory接下来就是getNameList内容参数，如扩展对象类和扩展范围。

4. confirmed-ResponsePDU

基本内容和confirmed-Request一样，只是由confirmed-RequestPDU->confirmed-ResponsePDU、confirmedServiceRequest->confirmedServerResponse，具体的内容也由上个包的提出变成回答，这两个包都是相对应的，一问一答的形式存在。

2018年工业信息安全技能大赛(东北赛区)协议分析

关于MMS的基础知识上文已经介绍完毕了，下面我们来看一下一个工业协议分析题目。题目首先给出了一个智能电厂项目的IEC61850数据包，由于题目中已经提示MMS了，所以我们直接筛选所有MMS。一共不到两千个MMS数据包

首先尝试搜索flag关键字。

发现存在flag.txt，接着搜索，在1771包处发现一个confirmed-Request数据包，这个包的作用是fileopen，这只是告诉了我们存在这样一个有着flag.txt的文件，我们暂时没法看到，还得找到fileread或者filewrite,根据fileopen后面的72我们可以推测一下fileread和filewrite的位置，应该是在70~75之间，而且要在1764后面那么我们尝试找一下73。

可以看到invokeID=527,我们之前已经介绍过了invokeID的作用，所以直接根据这个查找对应的confirmed-Resonse包。

可以看到fileData,进行asc解码即可得到答案。

这题的另一种解法是通过MMS协议的结构编写脚本得到答案，像S7comm等协议相关题目都可以通过这样实现