工控CTF_MMS

工控CTF_MMS

参考文章

https://blog.csdn.net/song123sh/article/details/127358610

概况

MMS工控协议是基于MMS和TCP等的基础上,开发的一套移动消息交互解决方案

基本信息:

• initiate（可以理解为握手）

initiate-RequestPDU

initiate-ResponsePDU

• confirmed（可以理解为交互，即传数据）

confirmed-RequestPDU

confirmed-ResponsePDU

通常情况为

1轮initiate：即发送1个initiate-RequestPDU，接收1个initiate-ResponsePDU

n轮confirmed：直到会话主动关闭或被动断开即confirmed-RequestPDU和confirmed-ResponsePDU交替发送和接收

工控消息分类

在MMS工控协议中,对工控消息进行分类,引入了confirmedService和unconfirmedService两种消息服务类型

confirmedService:确认型消息服务。这类消息会在接收方产生确认信息,发送回发送方。

它包含以下3种消息类型:

1. Acknowledgement:消息确认。发送方发送一条消息后,接收方返回的确认信息。它确认接收方已经正确接收该消息。

2. DeliveryReport:投递报告。当接收方用户 확定已阅读某条消息时,可以选择返回一条投递报告给发送方。它报告消息的阅读状态。

3. ReadReplyReport:阅读回复报告。接收方在阅读完一条消息的全部内容后,可以选择返回一条阅读回复报告,表明消息的阅读进度。

所以,confirmedService类型的消息都会在接收方产生某种形式的确认响应,并发送回发送方。这可以让发送方确定重要消息的接收、阅读等状态,实现可靠的消息交互。

常见的confirmedService有

对象操作
    getNameList (1)
    read (4)
    write (5)
    getVariableAccessAttributes (6)
    getNamedVariableListAttributes (12)
文件操作
    fileOpen (72)
    fileRead (73)
    fileClose (74)
    fileDirectory (77)

在wireshark显示为 confirmedServiceRequest 与 confirmedServiceResponse

unconfirmedService表示非确认类型消息服务。这类消息在接收方不产生任何确认信息返回给发送方。

它包含以下2种消息类型:

1. SIMPLE:简单消息。用于发送一般性消息,没有要求返回确认信息。
2. ENHANCED:增强消息。支持发送富文本、图片、视频等多媒体消息,也没有要求返回确认信息。

所以,unconfirmedService类型的消息发送后,发送方无法确定其接收状态和阅读状态。这类消息主要用于发送一般性信息,没有严格要求可靠送达

实例

HNGK-MMS

经过“握手”、“分手”后开始传输数据

具体分析一条MMS

MMS
    confirmed-RequestPDU
        invokeID: 1
        confirmedServiceRequest: read (4)
            read
                variableAccessSpecificatn: listOfVariable (0)
                    listOfVariable: 1 item
                        listOfVariable item
                            variableSpecification: name (0)
                                name: domain-specific (1)
                                    domain-specific
                                        domainId: IEDRelay1
                                        itemId: LLN0$DC$Diag$dU

1. 消息类型:Confirmed-RequestPDU。这是一条确认消息,属于confirmedService消息类型。

2. invokeID:1。该消息的唯一标识,用于匹配确认响应。

3. 服务类型:read (4)。这是一条读变量值的请求消息。

4. 变量访问规格:listOfVariable (0)。消息请求读取的变量采用listOfVariable类型的变量访问规格。

5. 变量数量:1 item。消息请求读取的变量有1个。

6. 变量规格:name (0)。该变量使用name类型的变量规格进行表示。

7. 域ID:IEDRelay1。该变量对应的域ID为IEDRelay1,表示它属于IEDRelay1这个设备或系统。8.

8. 项ID:LLN0$DC$Diag$dU。该变量的项ID为LLN0$DC$Diag$dU,表示其全路径名称。

多查看几条，发现confirmedService的值均为4，这时就要用筛选语句了

(mms) && (mms.confirmedServiceRequest != 4)

无数据，说明信息藏在数据流里

那就对domainID和itemID进行筛选

(mms) && (mms.domainId != "IEDRelay1")

无数据，说明domainID都是一样的值

itemID不同，但开头都是LLN0

(mms) && (mms.domainId == "IEDRelay1") && !(mms.itemId contains "LLN0")

将结果拼接处理得到flag