基于Wireshark的铁路信号协议解析器的设计与实现.pdf

80U城轨交通RBAN RAIL TRANSIT基于Wireshark的铁路信号协议解析器的设计与实现董渠江1,陆志伟1,曾庆文2,刘 晨1（1卡斯柯信号(成都)有限公司，成都 610083;2卡斯柯信号有限公司，上海 200071）摘要：Wireshark 在网络包捕获以及协议解析方面有着广泛的应用，在分析 RSSP-I 协议以及TCC 外部接口应用数据的基础上，基于 Wireshark 采用 Lua 脚本语言实现一种可配置的接口协议启发式解析插件，能对 RSSP-I、RSSP-II 等多种协议以及多种接口应用数据进行同时解析。测试结果表明该解析器具备较好的可扩展性和易用性，对联锁、列控工程设计人员具备较大的实用价值。关键词：Wireshark;Lua 脚本;RSSP;协议自适应解析器中图分类号：U284.48 文献标志码：A 文章编号：1673-4440(2023)07-0080-07Design and Implementation of Rail Signal Interface Protocol Parser Based on WiresharkDong Qujiang1,Lu Zhiwei1,Zeng Qingwen2,Liu Chen1(1.CASCO Signal(Chengdu)Ltd.,Chengdu 610083,China)2.CASCO Signal Ltd.,Shanghai 200071,China)Abstract:Wireshark has been widely used in network packet capture and protocol parse.Based on the analysis of the RSSP-I protocol and TCC external interface application data,this paper uses the Lua scripts to implement a confi gurable interface protocol heuristic parser based on Wireshark.It can be used to parse many protocols synchronously,including RSSP-I and RSSP-II,as well as several interface application data.The test result shows that the parser has good scalability and usability,and it is useful for engineering designers of interlocking and train control systems.Keywords:wireshark;lua scripts;RSSP;heuristic protocol parserDOI:10.3969/j.issn.1673-4440.2023.07.015收稿日期：2022-02-21；修回日期：2023-05-11基金项目：卡斯柯信号有限公司科研项目（RA.11119002）第一作者：董渠江（1994），男，硕士，主要研究方向：城市轨道交通列控系统仿真，邮箱：DongQuJ。目 前，列 控 中 心(Train Control Center，TCC)、联锁系统(Computer Based Interlocking，CBI)与外部接口之间多采用铁路信号安全协议(Railway Signal Safety Protocol-I，RSSP-I)进行通信，在遇到故障时，由于外部接口众多，如何铁路通信信号工程技术(RSCE)2023年7月，第20卷第7期81城轨交通URBAN RAIL TRANSIT快速定位问题亟需解决，即需能解析私有协议的工具以提高效率。而 Wireshark 软件对私有协议解析提供了方案，曹利等人1通过对 Wireshark 的二次开发，实现了私有协议解析器的开发，对于私有协议解析插件开发具有一定的借鉴意义，但二次开发流程较为复杂。此外，张海斌等人2研究了协议解析插件的功能组成，对于 Lua 插件开发方法进行测试，表明简单高效的 Lua 插件是解析私有协议的一种方法。采用 Lua 插件对铁路信号私有协议的解析在国内已有较多研究，在国铁信号系统方面，胡鹏3、黄鲁江等人4采用Lua 脚本语言分别实现了 TCC 与临时限速服务器(Temporary Speed Restrict Server，TSRS)、CBI 之间的通信协议解析；在地铁信号系统方面，唐辉5、陈昕6等人对地铁信号系统进行了应用协议的解析，从而降低开发周期或提高故障定位效率。但在实际情况中，系统与外部系统之间常用一个端口进行通信，而上述文献方法无法实现端口复用情况下的多种协议或数据的同时解析，因此对于启发式协议解析插件的研究具有一定的实用价值。1基于RSSP-I的外部接口分析1.1通信系统结构CBI 与外部系统之间的通信协议主要采用RSSP-I 或 RSSP-II 协议、TCC 与外部接口间多采用 RSSP-I 协议。本文以 RSSP-I 协议为例进行分析，文献 7 固定了该协议的安全通信系统总体结构，该结构重点对 RSSP-I 安全协议机制的安全功能模块（C 接口），以及置信传输的协议数据单元（E 接口）的功能进行了要求。该体系结构分为 3层，从上至下为应用层、安全层以及通信层，3 层之间的接口(B 接口、D 接口)由应用程序实现；而两实体之间安全相关协议数据单元接口（C 接口）采用 RSSP-I 安全协议机制进行实现7。如图 1 所示，安全通信系统总体结构中的安全功能模块主要由 RSSP-I 协议的安全校验层实现，该层通过对接收端的信息进行信息真实性、完整性、实时性以及有序性检查，降低了封闭传输系统所受的数据帧重复、数据帧丢失以及数据帧插入等 6 类威胁。对于网络通信，CBI 与 CBI、TCC 与 CBI、TCC 以及 TSRS 之间的通信协议分层结构均按图 1所示的分层结构进行信息传输。图网络协议分层结构Fig.1 Hierarchical structure of network protocol物理层数据链路层数据链路层网络层网络层传输层传输层安全校验层安全校验层应用层应用层IP协议UDP协议RSSP-I协议1.2RSSP-I协议1.2.1 报文结构RSSP-I 协议的报文结构包括报文头、安全校验域、用户数据包以及报文尾。报文头定义了协议交互的类型、报文类型、以及发送方与接收方，以鉴别数据是否安全、有效，以及物理通道是否连接正常。安全校验域由序列号、安全数据长度以及安全校验通道等组成，是 RSSP-I 中主要的安全防御技术。基于报文结构中前述所有数据，报文尾 CRC根据多项式生成。1.2.2报文分类RSSP-I 协议在通信交互过程中，传输 3 种报文，分别为：用于传输安全用户数据的实时安全数据（RSD）；接收端检验到当前安全数据报文时序已超过预定的容忍范围时，需向发送的时序校正请求（SSE）；用于回应时序校正请求的时序校正应答(SSR)。RSD 除去固定的报文头、安全校验域以及 CRC 尾，还存在用户数据包，由于应用数据主要依靠 RSD 进行传输，且 RSD 的总长度不大于 546 Byte。因此，对于 RSSP-I 协议，应用数据解析主要体现在对 RSD 的用户数据包的解析。No.7董渠江，陆志伟，曾庆文，刘晨：基于Wireshark的铁路信号协议解析器的设计与实现82U城轨交通RBAN RAIL TRANSIT1.3应用数据层根据采用 RSSP-I 协议的 CBI 以及 TCC 的外部接口规范8，可将 TCC 以及 CBI 与外部网口通信应用数据总结为两类：定长型应用数据与变长型应用数据。1.3.1定长型应用数据定长型应用数据为 CBI 与 CBI、TCC 与 TCC、CBI 之间的通信应用数据，若不满足对应的长度要求，则会补齐至规定长度。系统之间的通信应用数据长度如表 1 所示。表1TCC与外部接口应用数据包 Tab.1 Application messages between TCC and external interface类型描述长度/ByteTCC-TCCTCC 发送或接收的应用数据250CBI TCCTCC 收到 CBI 发送的应用数据450TCC CBITCC 发给 CBI 的应用数据300CBI-CBICBI 接收或发给 CBI 发来的应用数据601.3.2变长型应用数据变长型应用数据为 TCC 与 TSRS 之间的通信，由于文献 8 将 TCC-TSRS 之间的每个周期交互的消息拆分为若干通用应用层（GAL），且TSRS、TCC 每个周期最多允许发送 1 个 GAL，而每个 GAL 信息包的总长度不得超过 200 Byte，不足 200 Byte 将按 0 补齐，又因 RSD 的用户数据包总数为 480 Byte，因此，GAL 包字节长度为 200 480 Byte。2启发式解析器的设计启发式协议解析器总体流程设计如图 2 所示，总体包括读取配置文件、得到配置文件中 UDP/TCP 协议的组件 data 以及启发式解析器。协议启发式解析器包括 3 部分：协议检测模块、协议解析模块以及应用数据解析模块。协议检测从 UDP 或TCP 协议解析获得其用户数据的组件，然后检测并解析 RSSP-I 协议（或其他协议），而应用数据解析模块的主要功能为基于对应应用层协议检测并解析应用层数据，有 CBI 与 CBI、TCC 与 TCC、CBI以及 TSRS 之间的应用数据。图启发式协议解析器总体流程设计Fig.2 Overall process design of Heuristic Protocol Parser开始结束协议注册与解析得到UDP/TCP协议组件data应用层数据检测与解析协议检测读取配置文件2.1 协议检测模块协议检测模块实现的功能主要包括：协议检测、协议注册以及调用对应协议解析器进行协议帧头的解析。2.1.1协议检测协 议 检 测 通 过 对 应 的 检 测 函 数 实 现，以RSSP-I 协议为例。RSSP-I 协议检测通过 RSSP_I_Checker 函数实现，该函数逻辑为：如果应用数据的长度不满足 RSSP-I 规定的数据长度范围，返回 false，否则判断 UDP 应用数据是否符合 RSD的报文头特征以及安全数据长度要求、是否符合SSE 的报文头字段以及长度要求、是否符合 SSR的报文头字段与长度要求，若满足其中之一，则返回 true，否则返回 false。2.1.2注册为启发式协议若采用常规的注册方式，一个端口只有一种协议插件会起作用，为了实现端口复用，如图 3 所示，通过 Rail_Proto:register_heuristic(udp，RSSP_I_Checker)将 Rail_Proto 协议以启发式方式注册到 UDP 端口，当 RSSP_I_Checker 函数返回 true 时，该协议就会被注册为 RSSP-I 协议，此种启发式方式注册结合应用数据解析的模块化设计，便于多种协议的解析。与此类似，RSSP_II_Checker 函数返回 true 时，将 RSSP-II 协议注册铁路通信信号工程技术(RSCE)2023年7月83城轨交通URBAN RAIL TRANSIT至 TCP 对应端口。2.1.3调用协议解析器Rail_Proto.dissectoe 函数根据协议检测函数返回值调用协议解析模块中的协议解析器对对应协议进行解析。2.2协议解析模块协议解析模块由脚本文件 M_XXXX.lua 实现(XXXX 为 协 议 名)，首 先 通 过 Dissector.get(data)函数调用对应协议中的应用数据组件以完成准备工作，协议解析模块部分关键脚本如图 4 所示。协议解析模块中也需要将对应的协议注册到对应协议上，解析时的重点为协议各层帧头的解析，如图 4 所示，以 RSSP-I 协议为例。RSSP_I.dissector 函数调用 RSSP_I_Head_dissector 函数对 RSD、SSE 以及 SSR 3 类数据进行解析，需要注意 RSSP-I 协议字段采用小端字节序进行传输。除此之外，需要对采用该协议的应用数据类型进行判断。以上文分析的 RSSP-I 协议中的应用数据为例，对于定长型应用数据，主要通过 RSD 中用户数据的长度进行判断，如表 1 所示，该应用数据属于何种应用层协议，而对于变长型应用数据，通过判断 GAL 包的报文类型是否属于 0X8003，以及GAL 包长度是否处于 200 Byte 与 GAL 最大长度之间的条件进行判断。应用数据解析函数通过调用对应数据解析层实现，如图 4 所示，RSSP_I_TCC_TCC.dissector(buf，pkt，root)为数据解析模块图协议检测模块Fig.3 Protocol check module-加载应用协议解析模块require(“M_RSSP_I”)require(“M_RSSP_II”)-协议声明local Rail_Proto=Proto(ALL_PROTO,铁路信号通信协议)-定义协议字段proto_data=ProtoField.bytes(ALL_PROTO.proto_data,铁路信号通信数据,base.NONE)-注册解析字段Rail_Proto.fields=proto_data-获得UDP/TCP协议解析组件data_rssp=Dissector.get(data)-协议解析器实现function Rail_Proto.dissector(tvbuf,pktinfo,root)-根据检测函数分别调用对应的协议解析器 endRail_Proto.fields=proto_data-RSSP-I协议检测function RSSP_I_Checker(buf,pinfo,tree)end-RSSP-II协议检测function RSSP_II_Checker(buf,pinfo,tree)end-FSFB/协议等-协议注册udp_port=DissectorTable.get(udp.port)tcp_port=DissectorTable.get(tcp.port)-根据配置文件将协议注册至UDP/TCP对应端口addpoto(t)-协议检测部分Rail_Proto:register_heuristic(udp,Rail_Proto_Checker)Rail_Proto:register_heuristic(tcp,Rail_Proto_Checker)No.7董渠江，陆志伟，曾庆文，刘晨：基于Wireshark的铁路信号协议解析器的设计与实现84U城轨交通RBAN RAIL TRANSIT中 TCC 与 TCC 之间的应用数据解析函数。2.3数据解析模块采用 RSSP-I 协议的 TCC 外部接口应用数据解析模块中，数据解析模块通过脚本文件 M_TCC_XXX.lua 以模块方式存在(XXX 为与 TCC 通过网口采用 RSSP-I 协议交互的系统)。根据 1.3 小结所述，数据解析协议也分为固定字长以及变长型，定长型应用数据解析根据固定字节偏移量进行解析，以 TCC 与 TCC 之间应用数据解析为例，脚本总体结构与图 4 类似。首先定义全局模块（如果定义成局部模块，则脚本最后一行需添加 return 进行返回），后续的协议声明、字段定义等均与协议解析模块类似；差异在于数据解析模块需要根据对应应用层接口规范编写数据块的解析函数，比如 TCC 与 TCC 之间的应用层数据解析需要编写线路边界信息、线路改方等数据块的解析函数；最后也要对应用数据类型进行检查（与协议检测函数类似），并注册到对应协议上，但无需注册到端口。变长型应用数据为 TCC 与TSRS 之间的应用数据，由于数据包以 GAL 方式存在，一个 GAL 可包含多个信息包，因此，参考定长型应用数据解析器的实现方式，在该应用数据解析器内部添加一层循环判断即可，判断条件为剩余未解析应用数据的长度是否合法以及该段数据的信息类型。若满足该条件，则进入对应的信息包解析函数进行解析，并返回偏移量，否则结束循环，完成解析。3解析案例在 Wireshark 安装目录下新建 lua 文件夹，将编写的协议解析模块、数据解析模块放在 lua 文件下，将协议检测模块放在 Wireshark 安装目录的全局插件 plugins 文件夹下，所有脚本文件以 UTF-8编码方式保存，然后在 Wireshark 的 init.lua 配置文件中开启 lua 支持的配置项，配置文件按行配置需要注册的端口与协议，最后打开 Wireashark 对抓包的数据进行解析测试。部分解析结果如图 5 7 所示，其中，图 5 的(a)为 RSSP-I 协议解析显示效果（该图为 TCC 与TCC 之间应用数据解析的一个实例）。图 6 为 TCC图协议解析模块脚本(部分)Fig.4 Lua scripts of protocol parse module-加载应用数据解析层require(“M_TCC_TCC”)-协议声明local RSSP_I=Proto(RSSP-I,铁路信号安全协议-I)-定义协议字段p_proto_interactive_type=ProtoField.uint(RSSP-I.proto_interactive_type,协议交互类型,base.HEX)-注册解析字段RSSP_I.fields=p_proto_interactive_type,-获得UDP协议解析组件data_rssp=Dissector.get(data)-协议解析器实现function RSSP_I.dissector(buf,pkt,root)-TCC-TCC应用数据解析 RSSP_I_TCC_TCC.dissector(buf,pkt,root)end-RSSP协议解析function RSSP_I_Head_Dissector(buf,pkt,root,off)end-RSSP-I协议检测函数function RSSP_I_Checker(buf,pkt,root)endRSSP_I:register_heuristic(udp,RSSP_I_Checker)铁路通信信号工程技术(RSCE)2023年7月85城轨交通URBAN RAIL TRANSIT图RSSP-I协议以及RSSP-II协议（示意）解析结果Fig.5 Result of RSSP-I and RSSP-II parsing(a)RSSP-I协议以及应用数据解析示意(a)RSSP-I protocol and application data parsing diagram(b)RSSP-II协议解析示意(b)RSSP-II protocol parsing diagram图TCC与TSRS、TCC应用数据解析示意(部分)Fig.6 Result of TCC,TSRS,TCC application data parsing(a)TCC与TSRS之间的应用数据(a)Application data between TCC and TSRS(b)TCC与TCC之间的应用数据(b)Application data between TCC and TCC与 TSRS、TCC 之间应用数据解析示意，图 7 为TCC 与 CBI 之间应用数据解析结果。此外，还实现了采用 RSSP-I 协议的 CBI 与 CBI 应用数据解析。为验证该设计能否对多种协议进行同时解析，对采用 RSSP-II 协议进行通信的协议帧头数据进行了简单解析测试，如图 5(b)所示。协议以及应用数据解析结果呈树形状显示，逻辑结构清晰；应用数据解析全面且明了，易于相关人员分析定位。4结论本文分析并阐述了 RSSP-I 协议与列控系统外部接口应用数据，基于 Wireshark 设计了可配置的启发式的协议解析器，解析器在协议检测模块完成多种协议检测与注册；协议解析模块完成对应协议No.7董渠江，陆志伟，曾庆文，刘晨：基于Wireshark的铁路信号协议解析器的设计与实现86U城轨交通RBAN RAIL TRANSIT图TCC与CBI之间应用数据解析示意（部分）Fig.7 Result between TCC and CBI application data parsing的协议帧头的解析；应用数据解析模块同时有效解析多种应用层数据。此种方式解决了端口复用下的无法实现多种协议解析的问题，具备更好的自适应性，并且设计更加模块化，结构更加清晰，可为铁路信号工程技术人员提供较好的实用价值，但也存在抓包数据量较大时，解析时间较长的不足之处。参考文献1 曹利，王丹丹.基于 Wireshark 的协议解析器开发研究和实现 J.计算机时代，2015（6）：13-16.Cao Li,Wang Dandan.Research and Implementation of Protocol Parser Based on WiresharkJ.Computer Era,2015(6):13-16.2 张海斌，周翔，张松，等.基于 Wireshark 和Lua 的数据链协议解析插件开发 J.中国新通信，2017，19（15）：58-59.Zhang Haibin,Zhou Xiang,Zhang Song,et al.Development of Data Link Protocol Parsing Plug-in Based on Wireshark and LuaJ.China New Telecommunications,2017,19(15):58-59.3 胡鹏.基于 Wireshark 的列控中心以太网通信协议解析器的研究与实现 J.铁道通信信号，2020，56（6）：48-51.Hu Peng.Research and Implementation of Ethernet Communication Protocol Parser of Train Control Center Based on WiresharkJ.Railway Signalling&Communication,2020,56(6):48-51.4 黄鲁江，雷烨，成燚.Wireshark 协议解析在网络故障排查中的应用 J.铁道通信信号，2016，52（10）：52-55.Huang Lujiang,Lei Ye,Cheng Yi.Application of Wireshark Protocol Dissectors in Network TroubleshootingJ.Railway Signalling&Communication,2016,52(10):52-55.5 唐辉.基于 Wireshark 二次开发的地铁信号系统应用协议解析插件 J.交通与运输(学术版)，2016（1）：84-88.Tang Hui.Wireshark Based Plugin Implementation on Railway Signal System Application Datas DissectionJ.Traffi c&Transportation,2016(1):84-88.6 陈昕，谭力天，李澎东，等.基于脚本语言的互联互通通信数据解析插件 J.铁路通信信号工程技术，2020，17（2）：94-98.Chen Xin,Tan Litian,Li Pengdong,et al.Resolution Plug-in for Interoperability Communication Data Based on Script LanguageJ.Railway Signalling&Communication Engineering,2020,17(2):94-98.7 中华人民共和国国家铁路局.铁路信号安全通信协议 第 1 部分:I 型协议:TB/T 3528.1-2018S.北京:中国铁道出版社，2018.8 中国铁路总公司.高铁列控中心暂行技术规范：TJ/DW 172-2015S.北京：中国铁路总公司，2015.铁路通信信号工程技术(RSCE)2023年7月