一文读懂工控安全MMS协议

近来看了看工控安然相关内容,在此进行简单阐发。 MMS简介 MMS(Manufacturing Message Specification)中文翻译为 制造 报文规范,在先容MMS之前我们先简单科普一下IEC61850标准。 IEC61850是电力...


当前位置: 主页 > qyt118群英堂 >

近来看了看工控安然相关内容,在此进行简单阐发。

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等协议相关题目都可以经由过程这样实现。

总结

MMS协议作为一个公有协议,但实施光阴还不是很长,还有许多破绽点可以掘客,这篇文章只是按照我小我的思路基础的先容了一下MMS这个协议,有一部分内容是根据相关资料自行总结预测得出,有纰谬的地方盼望各位可以指出。

发表评论
加载中...

相关文章