IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码

现在网上有很多类似的文章、其实这一篇也借鉴了很多其他博主的文章。

写这篇文章的重点是在于解析功能和报文、对MMS这个协议并不会做很多介绍。

好了,我们开始吧。

MMS协议的协议规范取决于IEC61850规范

从报文来看mms协议共有tpkt cotp mms  下图为mms协议整体报文结构

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第1张图片

之前的tpkt 和 cotp这一块的就不展开进行介绍了,可以自行去了解一下(我们主要是讲MMS这一层)

Initiate

发包

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第2张图片

Byte[0] a8 消息的类型

Byte[1]26 mms消息的大小

Byte[2]80 LocalDetailCalling参数的类型

Byte[3]03 LocalDetailCalling参数的长度

Byte[4]-[6]04 e2 00 LocalDetailCalling本地详细信息调用参数的值 这个字节数不固定 取决于后面数字的大小

Byte[7]81 proposedMaxServOutstandingCalling参数的类型

Byte[8]01 proposedMaxServOutstandingCalling参数的长度

Byte[9]01 proposedMaxServOutstandingCalling译提出的最大服务端呼叫数值的值

Byte[10]82 proposedMaxServOutstandingCalled参数的类型

Byte[11]01 proposedMaxServOutstandingCalled的长度

Byte[12]01 proposedMaxServOutstandingCalled译提出的最大服务端被呼叫数值的值

Byte[13]83 proposedDataStructureNestingLevel 参数的类型

Byte[14]01 proposedDataStructureNestingLevel 参数的长度

Byte[15]05 proposedDataStructureNestingLevel 译预先编码的数据结构嵌套级别的值

Byte[16]a4 初始请求详细信息类型

Byte[17]16 初始请求详细信息的长度 也就是以后的字节长度

Byte[18]80 proposedVersionNumber参数的类型

Byte[19]01 proposedVersionNumber 参数的长度

Byte[20]01 proposedVersionNumber 译 提出的版本号的值

Byte[21]81 padding参数的类型

Byte[22]03 padding和proposedParmeterCBB的长度 (这里为什么是两个参数的长度呢,因为Wireshark解析错了 这俩个参数是在一个结构体内的)

Byte[23]05 padding 译 填充的值

Byte[24][25] f1 00 proposedParmeterCBB 译 提出的参数cbb

Byte[26] 82 padding或servicesSupportedCalling参数的类型

Byte[27]0c 自此往后的长度

Byte[28] 03 padding 译 填充的值

Byte[29]-[39] servicesSupportedCalling服务支持的呼叫的值

回包

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第3张图片

 可以看到的是 基本是一收一发 所有的参数都是与发包时候对应 那么就不在一个字节一个字节的阐述了

需要注意的是mms协议Wireshark解析的并不完整、有很多字节是没有解析到的,要注意观察,比如某某值的长度某某值的type都是没有解析到的。

Read

在介绍一个就够了,这些都是互通的,能认出来一个那么就能认出来其它的。

发包

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第4张图片

 上面的几层我就不截图了

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第5张图片

这样看会直观一些,我现在点的是InvokeID这一块,他的值为04 d0 但是他前面还有a0 27 02 02 是在mms协议的结构体内但是Wireshark没有解析到,这种情况会很经常发生,基本上与我上面说的一样,type和length都没有解析到。

A0 也即为消息的类型 27也即为消息的长度 那么02也即为Invokid的类型 下一个02也即为Invokid的长度

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第6张图片

 我现在点击的是confirmedServiceRequest那么可以看到又有两个数值没有解析到 a4 与 21 直接拿之前的经验往上套 那么a4 即为confirmedServiceRequest消息的类型 21即为confirmedServiceRequest消息的长度

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第7张图片

Read是与confirmedServiceRequest一个结构体内所以他俩的数值是一样。

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第8张图片

现在我点击的是 specificationWithResult 那么又可以看到遗留了两个数值80 与 01,80还是为specificationWithResult类型 那么01即为mms.specificationWithResult消息的长度

按照这个找法其实这些都是一样的 我就不继续往下阐述了。

回包

IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码_第9张图片

与发包也是一发一收 没有很大的变化 只是多了个读取到的数值

剩下的自己对照Wireshark就可以发现 都是一致的,剩下的我也就不再说了

 

你可能感兴趣的:(IEC6180-MMS协议简单解析 —— 利用Wireshark对报文逐字节进行解析详细解析IEC6180-MMS所含功能码)