工控CTF中常见题型介绍(上)

前言

去年参加了几场工控CTF比赛,基本都在坐牢。闲暇之余对工控CTF中常见的题型进行学习。

赛事介绍

工控CTF题目主要以流量分析、无线电分析、组态分析、梯形图等方向为主,偶尔有逆向分析、日志分析等相关分析题目。
相关赛事较少,赛事主办方以政府为主,常见的有每年的ICSC/IISC国赛及其各省的选拔赛/省赛。
线下赛有工业网络渗透实战、工业应急响应等赛制,主要考察渗透和运维能力。

工控协议分析

常见的工控协议有:Modbus、MMS、MQTT、COTP、IEC104、IEC61850、S7COMM、OMRON等。由于工控技术起步较早但是统一的协议规范制定较晚,所以许多工业设备都有自己的协议。
题目考点主要以工控流量和恶意流量为主,主要考察Wireshark使用和找规律,部分难度较高的题目主要考察协议定义和特征。

Modbus

Modbus协议是工控领域最常见的协议之一,也算是工控CTF中最常见题型。

  1. Modbus/RTU
从机地址1B+功能码1B+数据字段xB+CRC值2B
最大长度256B,所以数据字段最大长度252B
  1. Modbus/ASCII
由Modbus/RTU衍生,采用`0123456789ABCDEF`表示原本的从机地址、功能码、数据字段,并添加开始结束标记,所以长度翻倍
开始标记`:`1B+从机地址2B+功能码2B+数据字段xB+LRC值2B+结束标记`\r\n`2B
最大长度513B,因为数据字段在RTU中是最大252B,所以在ASCII中最大504B
  1. Modbus/TCP
不再需要从机地址,改用UnitID;不再需要CRC/LRC,因为TCP自带校验
传输标识符2B+协议标识符2B+长度2B+从机ID 1B+功能码1B+数据字段xB

题目中最常见的是Modbus/TCP协议,主要原因是抓包方便。
Modbus常见功能码:

1:读线圈
2:读离散输入
3:读保持
4:读输入
5:写单个线圈
6:写单个保持
15:写多个线圈
16:写多个保持
IISC河南省赛2022初赛《HNGK-Modbus协议分析》

题目要求:分析文件找出flag

  1. 首先依次筛选常见功能码,筛选到功能码为3的返回包:可以选择筛选返回包中的来源ip地址,来筛选出response包
((modbus) && (modbus.func_code == 3)) && (ip.src == 192.168.161.2)

-w1391

  1. 因为功能码显示read,所以判断看返回包,发现有报错的数据包。
    通过筛选byte count字段,筛选出有数据的响应包
(((modbus) && (modbus.func_code == 3)) && (ip.src == 192.168.161.2)) && (modbus.byte_cnt)

-w1431

  1. 查看响应包数据,发现响应包每条会增加一些字符

-w1179

  1. 将值复制出来
#=$@%&$&#=!!%!!$! "=$&$!""#!"@$@!'% $$#

但是发现复制的值中间有欠缺,所以复制hex16进制,然后找过字符的开头和结尾进行去除,然后转码

0023003d0024004000250026002400260023003d00210021002500210021001f0024001f002100200022003d0024002600240021002200220023001f0021001e00220040002400400021002700250020002400240023
  1. 以下步骤目的是为了将00去除
    第一步:将hex转换

-w1443
第二步:将值转换成hex,并设置一行2个bytes
-w1426
第三步:使用take bytes将字节取不是00的第二位 并设置为一行2个
-w1428
第四步:然后再转换为hex,得出完整的字符串

#=$@%&$&#=!!%!!.$.! "=$&$!""#.!."@$@!'% $$#

-w1409
第五步:将字符串转换为10进制,发现61 64
-w1418
第六步:转换为16进制
得到5a6d78685a33733161324a68634451304d6d3972665
-w1431
第七步:得到的5a6d78685a33733161324a68634451304d6d3972665疑似16进制字符串,然后再进行hex解码得到ZmxhZ3s1a2JhcDQ0Mm9rf.
-w1396
第八步:base64解码获取flag
-w1798

MMS

MMS主要有2种类型:

  1. initiate(可以理解为握手)
initiate-RequestPDU
initiate-ResponsePDU
  1. confirmed(可以理解为交互)
confirmed-RequestPDU
confirmed-ResponsePDU

通常情况为:

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

交互时的指令称为confirmedService

  1. 对象操作
read (4)
write (5)
getVariableAccessAttributes (6)
getNamedVariableListAttributes (12)
  1. 文件操作
fileOpen (72)
fileRead (73)
fileClose (74)
fileDirectory (77)
IISC河南省赛2022复赛《HNGK-MMS》

题目要求:分析文件找出flag

  1. 根据题目名称过滤出MMS数据包,发现前两个包为请求握手,观察第三个包发现read为4
    -w1100
  2. 过滤read不是4的包,发现没有。证明全是4
(mms) && (mms.confirmedServiceRequest != 4)
  1. 然后再找其他数据段发现itemId数据不一样,仔细观察都是LLN0开头
    -w1163
  2. 过滤LLN0开头的数据

选中过滤器

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

-w1222

  1. 然后过滤一下非FFNO的数据,发现三条数据
(mms) && mms.itemId &&!(mms.itemId contains "LLN0")

-w1216

  1. 通过观察比较发现数据疑似ascii码,因为ascii码中f为66、l为6c
    itemId: LLN666i5250356j4249
    itemId: LLN616732557968356j
    itemId: LLAy7sxCA9wSYrVLCbr
  2. 将字符串中的字母部分转换,构建为666c为flag的fl开头
  • 所以使用正则先将字母提取出来,然后进行减法,让i变为c发现减6变成c
  • 然后使用merge合并,转成hex发现得到flRP5mBIag2Uyh5m
    -w1020
  • 观察发现应该为2个字节换了下一段
    flRP5mBI
    ag2Uyh5m
  1. 拼接后flag为:
    -w172

IEC60870

  1. 子协议
IEC 101(任务相关)
IEC 102(电量相关)
IEC 103(保护相关)
IEC 104(101的网络版)
IEC ASDU(基于101/104的应用服务数据单元传输)
  1. 主要技巧
筛选`iec60870_asdu`
关注IOA的值
可尝试用type进行分类
IISC河南省赛2022复赛《HNGK-IEC协议分析》
  1. 过滤协议发现有错误的数据包,并且随便点数据包,发现分组不同
    说明建立了很多不同的连接

-w904

  1. 过滤分组为0的数据包,这样得到的为同一个连接的数据包,数据也是连贯的
iec60870_asdu && tcp.stream == 0
  1. 然后筛选有IOA Value值的数据
  2. 再去筛选TypeId: M_ME_TD_1 (34)发现对应的ioa的值,无规则,并且右下角数据包过多

-w948

  1. 继续筛选除去TypeId: M_ME_TD_1 (34)后的包,发现TypeId: M_ME_TD_1 (9)也有100多数据包,然后除去34和9,之后发现只剩18条数据
(((iec60870_asdu && tcp.stream == 0) && (iec60870_asdu.normval)) && !(iec60870_asdu.typeid == 34)&& !(iec60870_asdu.typeid == 9)) 

-w1239

  1. 将值提取,base64解码后发现为乱码

Mzhx3ZKtTOTJ0VadnNYdVSnlUUBNQf==
-w1031

  1. 分析发现两个字节组成一个数据,猜测为颠倒数据(两字节一数据有可能为颠倒的)

-w1272

  1. 调换位置获取flag

mZhx3ZKtTOTJ0VadnNYdVSnlUUBNQf==
ZmxhZ3tKOTJTV0daNndYSVlnUUNBfQ==
flag{J92SWGZ6wXIYgQCA}

MQTT

主要数据交互的消息类型为PUBLISH

  • 筛选mqtt.msgtype == 3

服务端有若干个主题(topic)可供客户端订阅

  • 客户端订阅后可以收到来自服务端关于这个主题的消息(message)
  • 一个主题可以持续产生消息
ICSC济南站2020《工业物联网智能网关数据分析》

首先查看协议占比,大致判断为mqtt的题目
1、筛选mqtt.msgtype == 3的时候有数据

(mqtt) && (mqtt.msgtype == 3)

-w1048
2、依次尝试复制出明文进行hex转码,发现为无用数据
-w1399
3、直到发现504B0304的一段数据内容,hex之后为PK的头,504B0304一般为zip文件的头
-w1057

放入010粘粘hex,然后保存为rar,解压发现文件损坏
-w629
4、猜测该rar不完整,然后发现该rar的数据是在f中的数据包
-w1064
5、拼凑为flag,依次提取数据包的内容,然后粘贴到010保存为rar,发现需要密码
6、尝试使用数据包中的字符串当作密码,发现成功解压出flag文件
-w988
6、发现flag图片损坏
-w419
使用其他工具,发现只显示了一半二维码,猜测需要更改高度
-w389
使用010更改高度为260
-w713
保存打开发现还是不全
-w317
7、使用Stegsolve打开
浏览发现Red、Green、Blue 0的时候上方都有数据显示
-w319
然后使用数据提取,将RGB为0勾选
然后点击preview
-w695
最后save bin保存出png图片,发现为后半段的二维码
-w339
拼接扫描二维码得到LSB_is_easy}
最后拼接上半段flag最终得到
flag{21png_LSB_is_easy}

COTP

  • COTP可以理解为基于TCP的工控TCP
  • COTP主要有五种类型:
CR Connect Request (0x0e)
CC Connect Confirm (0x0d)
DT Data (0x0f)
UD User Data (0x04)
ED Expedited Data (0x01)
  • CR和CC只在建立连接时由双方发送,发起方发送CR,被动方发送CC,后续数据主要走DT
  • 因为协议类似于TCP,较为底层,所以没有其他比较有用的协议字段可供解题
ICSC济南站2020《COTP》

题目:找到黑客流量,flag为后90字节的16进制
1、过滤cotp流量,发现第一个流量包没有请求握手流量,反而直接是数据传输
-w1070

2、过滤掉分组0,查看其他分组cotp && tcp.stream != 0
发现是一个完整的请求
-w1194
3、然后尝试提取字节16进制,提交flag。最后发现该数据包为黑客流量
-w1104

31312d31424535312d30584230203b56332e308240001505323b32383882410003000300a20000000072010000

S7comm

  1. S7基于COTP
  2. 主要有3种类型(ROSCTR)
    • Job (1) - Ack_Data (3) / Ack (2)10种功能(Function)
      • Setup communication (0xf0)
      • Read Var (0x04)
      • Write Var (0x05)
      • 下载
        • Request download (0x1a)
        • Download block (0x1b)
        • Download ended (0x1c)
      • 上传
        • Start upload (0x1d)
        • Upload (0x1e)
        • End upload (0x1f)
      • PI-Service (0x28)
    • Userdata (7)6种功能组(Function group)
      • Mode-transition (0)
      • Programmer commands (1)
      • Block functions (3)
      • CPU functions (4)
      • Security (5)
      • Time functions (7)
ICSC湖州站2020《工控协议数据分析》

题目:通过协议分析获取flag
1、查看协议占比发现该题考察点为s7comm,然后通过筛选发现read中data没有flag的痕迹
-w1190
2、发现在write中data数据为01开头
-w1116
3、提取hex并转换二进制,发现为f
-w937
依次提取write中的data转换为flag

011001100110110001100001011001110111101101100110011011000110000101100111010111110110100101110011010111110110100001100101011100100110010101111101

-w1262

OMRON FINS

Command CODE比较多,关注点主要在读写,如:

Memory Area Read (0x0101)
Memory Area Write (0x0102)
Multiple Memory Area Read (0x0104)
Memory Area Transfer (0x0105)
Parameter Area Read (0x0201)
Parameter Area Write (0x0202)
Data Link Table Read (0x0220)
Data Link Table Write (0x0221)
Program Area Read (0x0306)
Program Area Write (0x0307)
ICSC线上2021《Fins协议通讯》

打开压缩包发现key
-w777
1、打开数据包过滤command。发现全为read,没有write
-w1149
2、然后再筛选response,发现数据包比较多
-w1104
3、通过长度排序,然后发现了加密字符串数据
-w1133
得到U2FsdGVkX1/bWSZYUeFDeonQhK0AUHr9Tm7Ic20PRXxlPvlwG6a4fQ==
4、观察发现开头为U2Fsd
因U2Fsd疑似网站https://www.sojson.com的特征,并且压缩包里存在key:jnds
因此使用aes算法解密,发现失败,尝试tripledes解密成功,获取flag
-w968

特殊协议

基于各类数据传输协议的数据传输功能,实现的数据传输都可以称为隧道。
如:基于TCP的隧道、基于UDP的隧道、基于ICMP的隧道。

CISC兰州站2021《DNS》

1、通过大致翻阅,发现查询了奇怪的域名
-w1461
2、筛选出所有的流量

(dns) && (dns.resp.name contains ".in-addr.arpa")

-w14443、全选该数据,使用正则提取
然后0x去掉,得到16进制
然后转hex发现有flag痕迹
-w1428
然后猜测为shellcod,解码发现需改为32位,并且出现多处push
-w1430
将push数据提取出来
from hex之后为
X9RTM1QTMxkWYs9WYk1SZklmbtcmbplXLuFWdo1iZ0NWdz5WYnt3ZhxmZ
将数据进行反转进行base64转码得到flag:
-w1111

罕见协议

某行业特有的一些通信协议,比较少见。

ICSC济南站2020《司机的身份》

题目要求:找到卡车司机的身份信息
下载文件附件t808_info,为交通运输行业标准和流量包
-w649
导入流量包发现wireshark筛选不到该t808协议,但t808基于tcp
使用wireshark筛选带有数据的tcp数据包
规则使用长度比0大(tcp.len > 0)
-w1350
通过查找数据包内容0702发现数据包
-w622
发现驾驶员身份信息采集上报的消息ID为0702,找到该数据包
-w1391
提取hex

7e070240eb010000000001777064121100720120062709485600b48af896b850e7964d543d8af89640646996b850e77f3d85a9985876a4802876a4773e52ab963f621176a46167963f4ea676a4621154c6515c964d56a47957610d76a48fe695cd773e76a496404ea6805e5ba354a48fe652ab85a956c9610d805e980876a4585e8fe676a48ae64ea652ab4ea676a495cd985876a454a44fee95cd85a956a45ba376a4621183e983e976a48fe6805e8ae65a464ea6805e76a4963f85a96240985859827a7a5982598256d176a456d131313031303131393939303530353132313500000cb9e3b6abcaa1bdbbcda8ccfc20300505131182198502039877a67e

-w695
提取出姓名的16进制
然后from hex发现乱码。使用magic功能尝试发现得到了类似与佛论禅的编码,
因magic显示不全,所以使用具体的utf-168e进行解码
-w1035
-w669
然后通过base64解码,发现全是大写的。再使用base32得到flag
-w853

总结

本篇因csdn存在图片数量限制,本篇只是总结了工控ctf中协议分析相关题目的解题方法。对于工控ctf中逆向分析、组态分析、梯形图相关题目放到下一章节进行讲解。

今天只要你给我的文章点赞,我私藏的网安学习资料一样免费共享给你们,来看看有哪些东西。

网络安全学习资源分享:

最后给大家分享我自己学习的一份全套的网络安全学习资料,希望对想学习 网络安全的小伙伴们有帮助!

零基础入门

对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。

【点击领取】CSDN大礼包:《黑客&网络安全入门&进阶学习资源包》免费分享

1.学习路线图

在这里插入图片描述

攻击和防守要学的东西也不少,具体要学的东西我都写在了上面的路线图,如果你能学完它们,你去接私活完全没有问题。

2.视频教程

网上虽然也有很多的学习资源,但基本上都残缺不全的,这是我自己录的网安视频教程,上面路线图的每一个知识点,我都有配套的视频讲解。【点击领取视频教程】

在这里插入图片描述

技术文档也是我自己整理的,包括我参加大型网安行动、CTF和挖SRC漏洞的经验和技术要点,电子书也有200多本【点击领取技术文档】

在这里插入图片描述

(都打包成一块的了,不能一一展开,总共300多集)

3.技术文档和电子书

技术文档也是我自己整理的,包括我参加大型网安行动、CTF和挖SRC漏洞的经验和技术要点,电子书也有200多本【点击领取书籍】

在这里插入图片描述

4.工具包、面试题和源码

“工欲善其事必先利其器”我为大家总结出了最受欢迎的几十款款黑客工具。涉及范围主要集中在 信息收集、Android黑客工具、自动化工具、网络钓鱼等,感兴趣的同学不容错过。

在这里插入图片描述

最后就是我这几年整理的网安方面的面试题,如果你是要找网安方面的工作,它们绝对能帮你大忙。

这些题目都是大家在面试深信服、奇安信、腾讯或者其它大厂面试时经常遇到的,如果大家有好的题目或者好的见解欢迎分享。

参考解析:深信服官网、奇安信官网、Freebuf、csdn等

内容特点:条理清晰,含图像化表示更加易懂。

内容概要:包括 内网、操作系统、协议、渗透测试、安服、漏洞、注入、XSS、CSRF、SSRF、文件上传、文件下载、文件包含、XXE、逻辑漏洞、工具、SQLmap、NMAP、BP、MSF…

在这里插入图片描述

因篇幅有限,仅展示部分资料,需要点击下方链接即可前往获取
CSDN大礼包:《黑客&网络安全入门&进阶学习资源包》免费分享

在这里插入图片描述

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
CTF(Capture The Flag,夺旗赛)是一种网络安全竞赛,其涉及到图片隐写术的应用。图片隐写是一种将信息隐藏在图像的技术,使得除了原本的图像外,其他人很难察觉到存在着隐藏的信息。 在CTF常见的图片隐写术包括: 1. LSB隐写:最常见的图片隐写术之一,通过修改图像像素的最低有效位来隐藏信息。这种方法对于人眼来说几乎不可察觉,而且可以应用于不同的图片格式。 2. 色彩平面隐写:将隐藏信息分散在各个色彩平面上,通过修改色彩通道的最低有效位来隐藏信息。相比于LSB隐写,这种方法在保持图像视觉质量的同时使得隐藏的信息更难被发现。 3. 频域隐写:利用图像的频域信息,如傅立叶变换等,将隐藏信息嵌入图像。通过对频域进行操作,隐藏的信息可以更加难以被探测到。 4. 容器隐写:将隐藏信息嵌入到图片文件的非图像数据部分,如EXIF信息、文件尾端等。这种方法可以绕过对图像本身的修改检测。 5. 混合隐写:结合多种隐写术的方法,将隐藏信息嵌入图像。例如,可以先通过LSB隐写将信息嵌入到图像,然后再通过频域隐写对图像进行处理。 在CTF比赛,参赛选手可能需要进行图片隐写的解密任务,以获取隐藏的信息。他们可以使用各种工具和技术来查看和修改图像,以寻找隐藏的信息。常用的图片隐写相关工具包括Steghide、Stegsolve等。另外,了解常用的隐写术原理,对于解决隐写任务也是非常有帮助的。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

网络安全技术库

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值