ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

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

2020-07-08 15:41:15  阅读:659  来源: 互联网

标签:01 IEC6180 MMS 参数 mms 长度 Byte 解析


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

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

好了,我们开始吧。

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

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

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

Initiate

发包

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服务支持的呼叫的值

回包

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

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

Read

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

发包

 上面的几层我就不截图了

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

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

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

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

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

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

回包

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

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

 

标签:01,IEC6180,MMS,参数,mms,长度,Byte,解析
来源: https://www.cnblogs.com/Db2k/p/13267175.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有