协议分析
流量分析
主要以工控流量和恶意流量为主，难度较低的题目主要考察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
判断题目类型文章来源：https://uudwc.com/A/BvkDZ
可以在wireshark—统计—协议分级中查看各协议占比文章来源地址https://uudwc.com/A/BvkDZ