工控CTF之协议分析2——MMS

协议分析

流量分析

主要以工控流量和恶意流量为主，难度较低的题目主要考察Wireshark使用和找规律，难度较高的题目主要考察协议定义和特征
简单只能简单得干篇一律，难可以难得五花八门

常见的工控协议有：Modbus、MMS、IEC60870、MQTT、CoAP、COTP、IEC104、IEC61850、S7comm、OMRON等

由于工控技术起步较早但是统一的协议规范制定较晚，所以许多工业设备都有自己的协议，网上资料数量视其设备普及程度而定，还有部分协议为国家制定，但仅在自己国内使用，网上资料数量视其影响力而定

CTF之协议分析文章合集

工控CTF之协议分析1——Modbus
工控CTF之协议分析2——MMS
工控CTF之协议分析3——IEC60870
工控CTF之协议分析4——MQTT
工控CTF之协议分析5——COTP
工控CTF之协议分析6——s7comm
工控CTF之协议分析7——OMRON
工控CTF之协议分析8——特殊隧道
工控CTF之协议分析9——其他协议
文中题目链接如下
站内下载
网盘下载：https://pan.baidu.com/s/1vWowLRkd0IdvL8GoMxG-tA?pwd=jkkg
提取码：jkkg

MMS

工控领域的TCP协议，有时wireshark会将response包解析为tcp协议，影响做题，如果筛选mms时出现连续request包，考虑wireshark解析错误，将筛选条件删除手动看一下

• initiate（可以理解为握手）

  initiate-RequestPDU

  initiate-ResponsePDU

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

  confirmed-RequestPDU

  confirmed-ResponsePDU

通常情况为

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

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

交互时的指令称为confirmedService

常见的confirmedService有

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

例题1 HNGK-MMS

经过“握手”“分手”后开始传输数据，发现confirmedService的值均为4，查看是否有不是4的数据包(mms) && (mms.confirmedServiceRequest != 4)

发现均为4，无异常，那么flag基本就藏在数据流中了，一层一层查看数据

发现domainID和itemID，分别对其过滤查看

((mms)) && (mms.domainId != "IEDRelay1") 发现domainID都是一样的值

再对itemID过滤，这里发现虽然itemID均不相同，但是都是LLN0开头的

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

66是flag中f的ascii码，猜测可能是十六进制，但是i、j明显不在此范围内，猜测可能存在偏移，这里猜测偏移6，因为字母l的十六进制为6c

发现fl和ag，猜测前后每两字节取值，因为两数据取自不同的itemID，拼接flag并加上{}即可

例题2 HNGK-流量分析

发现大部分均为getNameList获取对象名，回复包也是get到的数据，先查询有无包含flag字符串

既然有列出目录再往后找，找到fileopen flag.txt

查看返回值，得到一个打开该文件的句柄或者ID

往后发现再次列出目录打开flag.txt，尝试找是否有读文件操作即fileOpen，mms.fileOpen == frsmID，依次尝试得到的几个id，在第二次打开中即frsmID=87504092找到读文件操作

找到这串请求的返回包即序号1801，得到一串图片base64

将base64转图片得到flag

判断题目类型

可以在wireshark—统计—协议分级中查看各协议占比