Academic Research

Large language model-driven network protocol reverse engineering and security testing methods

  • Zhang Dong ,
  • Zhan Yichen ,
  • Bai JiaJu , * ,
  • Guan Zhenyu
Expand
  • School of Cyber Science and Technology, Beihang University, Beijing 100191, China

Online published: 2026-02-03

Copyright

Copyright ©2026 Journal of Aeronautical Materials. All rights reserved.

Abstract

To systematically explore the input and state space of HTTP protocol implementations and automate vulnerability discovery, a large language model-driven network protocol reverse engineering security testing method (LPRT), was proposed. Targeting text-based protocols such as HTTP in network devices, the method built an intelligent agent system centered on the DeepSeek model. It semantically analyzed limited captured traffic to infer protocol message formats. Based on these inferred formats, the system generated test requests, sent them to the server, and captured responses. The agent iteratively analyzed the responses to expand the protocol’s input and state space. On this basis, it autonomously generated test cases likely to trigger security flaws and detected potential vulnerabilities. Experimental results showed that the method could explore a broader range of request types and parameter combinations, even with minimal traffic samples, and uncovered ten security vulnerabilities on network devices. These findings demonstrate the effectiveness of large language models in protocol security testing and provide a novel intelligent approach to protocol analysis and vulnerability discovery.

Cite this article

Zhang Dong , Zhan Yichen , Bai JiaJu , Guan Zhenyu . Large language model-driven network protocol reverse engineering and security testing methods[J]. Journal of Cybersecurity, 2026 , 4(1) : 1 -12 . DOI: 10.20172/j.issn.2097-3136.251015

0 引言

随着物联网设备以及工业控制系统的广泛部署,其安全问题日益突出[1]。攻击者往往利用网络设备协议中的漏洞发动严重的网络安全事件,对互联网中的基础设施造成了巨大威胁。例如,2016年发生的Mirai僵尸网络攻击事件,攻击者入侵了大量物联网设备并实施了大规模DDoS(distributed denial of service)攻击,导致美国域名解析服务商Dyn一度瘫痪,造成了北美和欧洲大范围的网络服务中断以及严重的业务损失[2]。这一事件凸显了网络设备协议漏洞的严重性,促使安全领域更加关注针对网络设备协议的安全测试。
越来越多的网络设备开始向智能化发展,远程管理功能也使网络设备在使用中更加便捷,大多数路由器及物联网设备在通信和配置管理过程中采用私有协议。这些私有协议通常基于HTTP、WebSocket等应用层协议,在消息体部分嵌套结构化文本(如JSON-RPC、XML等)以实现复杂的指令和参数交互[3]。由于协议文档未公开、接口设计复杂多样,协议内容呈现较强的封闭性和多样性,给后续的安全测试与协议分析带来了诸多挑战[4]
协议逆向工程与安全测试是预防此类安全问题的重要技术手段,在保障网络设备安全中发挥关键作用。国内外学者与业界工程师围绕协议逆向与漏洞挖掘,提出多种自动化分析与模糊测试工具。例如,基于网络流量分析和消息结构推断的Netzob[5],能够自动提取未知协议的报文语法和字段划分,为后续的协议解析和状态建模提供基础;Boofuzz[6]作为主流的开源模糊测试框架,通过自动生成和变异协议消息,针对路由器、摄像头、IoT终端等各类设备进行大规模协议模糊测试。近年来,有研究者将大语言模型(large language model,LLM)应用于协议的安全测试。ChatHTTPFuzz[7]通过二进制逆向目标设备的固件代码来获取协议实现逻辑,模型根据代码中的分支条件和常量等信息,有针对性地生成更多符合业务逻辑的HTTP模糊测试用例。NeTestLLM[8]依赖RFC(request for comment)文档相关信息生成并验证测试用例,该方法先对RFC文档进行清理和分割,再结合大语言模型提取相关信息生成并验证测试用例。ChatHTTPFuzz利用LLM的代码理解能力推断字段约束与业务逻辑,生成高效测试用例,但无法适用于缺乏固件或代码的场景。NeTestLLM利用LLM的规范理解能力解析RFC等标准文档,生成合规性测试序列,但难以应对缺乏标准文档的私有协议。相比之下,本文方法利用LLM的协议语义推理能力,直接从通信报文的交互痕迹中逆向构建协议字段语义模型,适用于无法获取固件且无标准文档的协议安全测试场景。
尽管上述工具和方法在协议逆向与漏洞挖掘领域取得了长足进展,但实际应用中仍面临诸多挑战。一方面,网络设备固件提取及分析难度大,尤其是本文实验选取的商用路由设备,固件分析需丰富的二进制逆向专家经验。另一方面,设备协议类型繁杂,尤其是大量采用私有协议或厂商自定义的变种协议,缺乏公开文档和协议结构说明。当前主流的协议逆向和模糊测试工具多针对HTTP、FTP、Modbus等常见文本协议或结构较为标准的协议[9-11],对高度定制化或自适应变形的私有协议的自动识别与测试效果有限。此外,许多协议逆向工具(如Netzob)依赖足够多的流量样本,在设备初次部署、缺乏历史通信数据的情况下,协议逆向分析的准确率显著下降,易出现字段识别错误或状态机推断不完整等问题[12]
针对以上挑战,本文提出了一种基于DeepSeek大语言模型驱动的网络协议逆向与安全测试方法。该方法利用仅有的少量文本格式协议流量数据,借助DeepSeek强大的语言理解和生成能力自动推断协议结构语法,生成符合协议标准的测试请求,并对服务器响应进行语义分析,从中识别新的协议行为和潜在安全漏洞。与传统方法相比,该方案显著提升了协议分析的自动化程度和测试用例有效率[13]。首先,DeepSeek模型无需手工编写特征提取脚本,就能根据少量样本智能推理协议字段含义和格式约束;其次,模型能够根据推理的协议格式自动生成多样化的测试用例,覆盖更多异常场景,从而提高漏洞挖掘的深度和广度;再次,该方法对未知协议具有较强适应性,即使在缺乏文档或先验知识的情况下,也可以在短时间内基于几条通信记录建立协议模型并开展安全测试。这种大语言模型驱动的策略大大降低了人工参与需求,能够有效满足私有协议安全分析需求。近年来大型语言模型在代码理解与安全分析领域展现出巨大潜力,为新方法提供了技术可行性支撑[14-15]。本文研究思路融合了前沿人工智能技术与网络安全需求,旨在突破当前协议安全分析的瓶颈,提供一种高效且创新的技术手段来保障网络设备的协议安全。
本文的主要贡献如下:
1)提出了一种基于DeepSeek-V3.2-Exp大语言模型的安全测试方法,在少量流量样本下,能够测试协议中更多的请求类型与参数组合,挖掘潜在漏洞威胁。
2)实现了无需人工特征工程的自动化协议分析流程,能够在缺乏协议文档和样本有限的情况下提升协议分析效率,适用于私有HTTP文本协议及其衍生协议。
3)在实际网络设备的安全测试场景下,发现了若干此前未公开的安全漏洞,验证了该方法在自动化安全测试领域的有效性。

1 相关工作

随着网络设备和通信协议的复杂性不断增加,协议安全愈发重要。协议安全测试技术经历了从人工审计、静态分析到动态分析与智能化模糊测试的演进。为系统梳理本文研究的技术背景,本节从3个方面展开:首先介绍安全测试方法的发展,分析符号执行、污点分析及模糊测试在漏洞挖掘中的应用与不足;其次综述协议逆向辅助安全测试的优势,探讨动态分析与流量聚类协议逆向工程的局限;最后总结大语言模型在协议解析与测试用例生成中的新兴应用。

1.1 安全测试方法

在网络设备及其通信协议的安全测试领域,测试方法经历了从人工检查与静态分析到动态分析,再到智能化自动测试的演进过程[16],各种技术手段相互融合,逐步提升了安全测试的深度和广度。
早期的安全检测主要依赖安全工程师人工审计代码或配置,随后,静态分析工具开始兴起,例如静态应用安全测试[17]能够在不运行程序的情况下扫描源代码或二进制文件,从语法模式和规则入手检测潜在漏洞。动态分析通过在实际运行环境中评估目标系统的安全性来发现漏洞。测试人员从攻击者视角出发,模拟各种恶意输入或攻击手段对网络设备施压,以观察其运行状态和防护机制[18]
符号执行通过将输入抽象为符号变量,系统地探索程序的不同执行路径,并借助约束求解生成能够触发特定路径的具体输入,其代价是面对复杂程序时会出现路径爆炸问题[19-20]。污点分析通过跟踪不可信输入数据在程序中的传播,快速定位可能存在漏洞的代码路径,迅速缩小了符号执行需要深入搜索的路径空间,避免了对海量无关路径的盲目分析[21]
在安全测试方法演进的第3个阶段,模糊测试及其改进成为研究焦点。早期的模糊测试主要依赖基于生成的黑盒方法(如PROTOS[22]、Peach[23]等),它们要求人工提供协议规格或模型来生成测试用例,这一过程烦琐且易出错,限制了测试效率。直到AFL(american fuzzy lop)[24]的出现,才带来了突破。AFL引入了覆盖引导的灰盒模糊测试理念,在不断根据执行反馈调整输入方面取得重大成功,被认为是近年来模糊测试领域的里程碑。然而,AFL对于网络协议测试存在局限性。
为了解决上述问题,模糊测试工具开始在支持协议结构和状态建模等方面不断演进。BooFuzz[6]是网络协议黑盒模糊测试的代表性工具,它利用测试人员预先定义的模板生成和变异测试用例,从而在一定程度上确保测试数据符合协议格式要求,并可针对有状态的交互协议进行模糊测试。AFLNet[25]被认为是首个针对网络协议实现的灰盒模糊测试器。它以AFL为基础,引入了对协议状态的反馈机制,不仅监控目标进程的代码覆盖率,还结合协议的消息交互顺序和状态转移情况,对每一个会话的多步请求和响应进行智能引导。这一设计使AFLNet能够自动发现隐藏在多阶段网络交互的深层漏洞中,极大提升了协议模糊测试的深度和广度[26]
虽然现有安全测试方法在漏洞检测上取得显著成果,但是依赖较强的协议先验知识、代码可见性或人工模板,难以适应私有协议。与符号执行、污点分析及传统模糊测试相比,本文方法在自动化程度、样本依赖性、协议泛化能力和深层漏洞发现能力方面具有显著优势,为私有协议场景下的网络设备安全测试提供了新的解决方案。

1.2 协议逆向辅助安全测试

为支撑网络协议的安全分析,并为模糊测试提供结构化输入,研究者发展出协议逆向工程技术,这为本文提出的基于大语言模型的协议逆向与漏洞挖掘方案提供了理论基础和技术参考。
Discoverer[27]首次实现了通过动态监测服务器程序处理网络输入的过程,从程序执行中自动推导有状态协议的规范,提取包括消息格式和状态迁移规则在内的协议要素。随后,Prospex[28]在此基础上进一步拓展该思路,提出一种更系统的动态分析方法,能够更高效地从服务端程序行为中抽取有状态协议的完整规范。
将协议逆向得到的结构信息应用于模糊测试,是提高测试效率和有效性的一种重要思路。一方面,详细的协议格式可用于构造有效的测试输入,避免盲目变异;另一方面,协议状态机模型可指导测试覆盖更多的状态迁移。Snipuzz[29]针对物联网设备的黑盒模糊测试提出了“消息片段推断”的新方法。它的核心思想是在不掌握协议细节的情况下,通过目标设备对畸形输入的响应来动态推断消息结构。但由于其强调基于约束条件生成“有效”输入,Snipuzz生成的测试样本可能在结构上趋同,导致未覆盖边界或异常路径。Netzob[5]致力于通过被动流量分析来逆向通信协议:首先对收集的报文进行聚类分析和分组,推测不同报文类型的“词汇”(vocabulary);随后利用字节分布、模式匹配等技术将报文划分为字段,恢复各字段的边界和类型,从而建立消息格式模型。在此基础上,Netzob尝试推导消息交互的顺序规则,即协议的“语法”(grammar)与状态机模型,并支持用户通过交互方式完善和验证模型。Netzob可结合生成的协议结构化描述,指导后续模糊测试有针对性地构造测试用例,优先变异协议关键字段。但是,如果样本不完整(如缺失某些边界情况、异常路径、特殊命令),Netzob难以推导出完整格式,导致无法生成高覆盖率、高效的测试用例。
与传统协议逆向方法相比,本文提出的方法在两方面具有显著优势:首先,利用大语言模型对有限报文样本进行语义推理,可在样本不完整或缺乏文档的情况下自动推断消息结构和字段约束;其次,通过动态执行反馈对生成的协议结构和测试用例进行验证与优化,从而提高逆向准确性和漏洞触发效率。相比Snipuzz和Netzob,本文方法不仅能生成更多覆盖边界和异常路径的测试用例,还具备更强的私有协议适应性,为网络设备安全测试提供了更高的自动化和智能化的能力。

1.3 基于大语言模型的网络协议安全测试

前沿研究开始探索将大语言模型应用于协议分析和安全测试,利用其强大的理解和生成能力来辅助漏洞挖掘。
一项突出进展是利用LLM来解析协议语法并生成测试用例。ChatHTTPFuzz[7]通过二进制逆向获取目标设备的固件代码,LLM根据代码逻辑来指导测试用例生成,将GPT系列模型引入物联网HTTP服务的模糊测试,模型根据代码中的分支条件和常量等信息,有针对性地生成更符合业务逻辑的HTTP请求变种,从而丰富种子模板。NeTestLLM[8]依赖RFC文档相关信息生成并验证测试用例。该方法分为两个阶段,在测试用例生成阶段,先对RFC文档进行清理和分割,再提取相关信息生成并验证测试用例;在测试代码生成阶段,则通过多次迭代,结合检索到的API接口、代码示例以及运行日志等生成改进建议,直至生成的代码通过验证。大模型在理解协议结构和推理程序逻辑方面展现出独特优势,其可自动完成以往需人工介入的模板编写和语义分析工作,大幅减少无效测试用例的产生[14-15]。ChatHTTPFuzz依赖固件静态分析,但固件往往获取困难、流程复杂;NeTestLLM依赖RFC文档,无法处理私有协议,泛化能力较弱,难以覆盖实际网络设备中常见的未知或非标准协议场景。
已有研究虽在协议逆向和安全测试领域取得了重要进展,但仍普遍面临自动化能力有限、对协议样本和人工特征工程依赖较重,以及难以适配未知或缺乏文档的网络设备协议等问题[4,30-31]。因此,亟须一种能够在缺乏协议文档和样本有限条件下,实现协议结构自动推断、测试请求自动生成与安全威胁智能分析的创新方法。
针对上述需求,本文提出的方法结合大语言模型的语义推理能力,引入一种协议逆向动态反馈机制。一方面,LLM可从有限样本自动推断协议结构和字段约束,无需依赖完整RFC文档或固件;另一方面,通过动态验证和反馈闭环优化生成的测试用例,提高测试覆盖率和漏洞触发率。与现有ChatHTTPFuzz和NeTestLLM方法相比,本文方法对私有协议适应性方面更具优势。

2 方法设计

本节首先介绍大语言模型驱动的网络协议逆向与安全测试(LPRT)方法的工作流程,然后介绍攻击模型和LPRT系统的设计细节。
图1给出LPRT模型结构。在协议逆向部分,系统首先通过抓包工具采集目标网络设备的少量通信流量作为初始流量样本,并对样本进行清洗、配对和格式标准化预处理。随后,利用DeepSeek-V3.2-Exp大语言模型对处理后的流量样本进行语义解析与协议预推理,智能识别消息类型、参数结构及字段语义,构建初始协议知识库与状态集合。在此基础上,系统通过智能代理生成多样化的测试请求并发送至目标设备,同时捕获响应结果。每一轮响应均由大语言模型进行协议逆向分析,识别新的协议结构、路径或状态转移,持续迭代优化协议模型,实现协议功能空间的动态扩展。在安全测试阶段,系统依据更新后的协议模型,自动生成针对边界条件、异常参数与非法请求等容易触发漏洞的调用用例,通过分析测试响应完成漏洞分析,从而有效提升检测覆盖率和漏洞发现能力。
图 1 LPRT模型结构

Fig.1 Architecture of the LPRT

2.1 攻击模型

本文关注黑盒安全测试场景,即假设攻击者无法获取设备固件源代码或完整协议文档,仅能通过正常用户界面或网络通信接口与目标设备交互。在此威胁模型下,攻击者通过抓取少量合法流量(如网页配置、移动App操作等)获得有限的协议交互流量样本。随后,依托大语言模型自动推断协议结构与参数分布,主动生成针对性的测试用例,以发现功能缺陷或安全漏洞。因此,本系统具备在样本极少、协议未公开、权限受限等约束下自动挖掘协议潜在风险的能力。主要漏洞目标包括:未授权访问、认证绕过、配置泄露等常见类型。
以路由器管理接口为例,其通常采用HTTP协议进行通信,而HTTP请求的消息体(body)部分通常采用JSON-RPC、XML等结构化文本格式。实际安全测试或功能测试过程中,由于协议文档缺失、接口繁多、参数复杂,测试人员很难仅凭手工方式或常规自动化工具覆盖全部可能的请求类型与参数组合。这不仅限制了测试的广度,也容易导致部分边界场景、异常路径或潜在安全隐患被遗漏。为提升协议分析和测试的广度与深度,有必要针对消息体部分的协议结构开展自动化协议逆向工程,通过分析和扩展已观测到的通信样本,推断协议格式和参数规律,并自动探索和生成新的消息体内容集合,从而系统性地扩展测试空间,提升未知功能及漏洞的发现概率。

2.2 数据采集与预处理

在网络协议安全测试流程中,数据采集与预处理是基础环节,其质量直接影响后续协议结构推断和测试用例生成的效果。
本方法主要针对HTTP这一典型文本协议,设计了适配网络设备实际场景的数据采集与预处理机制。

2.2.1 流量采集流程

测试人员通过被测系统的客户端(如Web管理页面、移动APP等)与目标网络设备进行交互操作。利用抓包工具Wireshark实时捕获通信过程中的HTTP等文本协议流量。针对文本协议的特点,抓取的数据通常以明文、结构化的形式呈现。
为保证采集样本的代表性,尽可能覆盖设备的主要功能模块及常用业务流程,如路由器配置查询、Wi-Fi参数获取、日志导出等。对于需认证的接口,需同步记录认证过程产生的关键信息(如会话令牌、Cookie等),确保后续请求的完整性与可复现性。

2.2.2 数据预处理方法

针对初步采集到的原始流量数据,系统自动完成以下预处理步骤。
1)请求与响应配对。将每个请求与其对应响应进行自动配对,确保后续分析过程中的语义完整性。例如,对于HTTP POST请求体为JSON-RPC格式的报文,系统通过唯一标识(ID字段或请求时序)完成一一对应。
2)数据去噪与去重。移除无效请求、重复报文以及无关流量(如静态资源加载、无效心跳包等),仅保留核心业务通信样本。
3)格式化与规范化。对采集到的文本协议报文进行结构化处理,包括字段值类型校验及标准化、统一日期和数字格式、统一采用UTF-8规范化。
4)敏感信息脱敏。对涉及设备敏感配置(如密钥、密码、真实令牌等)的内容进行脱敏处理,仅保留其格式和结构特征,防止隐私泄露。
5)样本集构建。预处理后的有效请求—响应对按业务逻辑归类,组成初始通信样本集,并为后续大语言模型推理和自动测试提供高质量输入数据。
以上全部预处理流程均可通过Python编程实现。具体而言,利用requests、json、re等标准库结合pandas进行数据读写,采用scapy库解析流量;通过自定义脚本实现请求—响应配对,使用集合和哈希去除无效或重复数据,借助正则表达式和类型校验函数进行字段标准化和敏感字段脱敏,最终按业务规则分组,输出结构化样本集。
以Netcore路由器HTTP请求体的JSON-RPC为例,预处理后的样本格式如表1所示。样本经预处理后保留核心业务字段及参数,有助于后续协议结构归纳与测试用例生成。
表 1 NetCore路由器交互示例

Table 1 Interaction examples of Netcore routers

请求方向 消息内容
SEND {"jsonrpc":"2.0","method":"call","params":["TOKEN","routerd","param_status",{"action":"get"}]}
RECV {"jsonrpc":"2.0","id":null,"result":[0,{"initialized":1,"ExamFlag":false}]}

2.3 智能代理系统的模块设计

智能代理系统是大语言模型驱动的网络协议逆向与安全测试方案的关键执行载体。其核心任务是在协议推断、测试请求生成、交互执行、响应分析及协议模型迭代的过程中,实现全流程的自动化与智能化控制,从而不断扩展协议认知空间并高效挖掘潜在安全威胁。

2.3.1 协议结构与语义推断模块

该模块以预处理后的样本集 $ {S}_{0} $ 为输入,基于大语言模型 $ {f}_{{\mathrm{LLM}}} $,对协议报文的层次结构、字段含义、参数关系等进行归纳与语义标注。推断过程可形式化为:
$ \begin{array}{c}{M}_{0}={f}_{{\mathrm{LLM}}}\left({S}_{0}\right)\end{array} $
其中,$ {M}_{0} $ 由大语言模型推理获得,表示初始协议结构模型,包括字段集合、消息类型和参数分布等元信息。在此基础上,系统利用大语言模型的协议知识和泛化能力,进一步探索并生成潜在的协议输入空间与状态空间。经过 $ t $ 轮迭代更新,最终获得更完备的协议模型$ {M}_{t} $

2.3.2 测试请求生成模块

在获得协议模型 $ {M}_{t} $ 的基础上,测试请求生成模块根据当前模型自动构造多样化且合法的测试输入集合 $ {Q}_{t}={q}_{1},{q}_{2},\cdots ,{q}_{K} $,并可针对边界条件、异常参数、未见命令等敏感场景设计特定变异用例。
请求生成过程可表示为:
$ \begin{array}{c}{Q}_{t}={g}_{{\mathrm{gen}}}\left({M}_{t}\right)\end{array} $
其中,$ {g}_{{\mathrm{gen}}}(\cdot ) $ 为由大语言模型与策略算法共同驱动的请求生成函数,综合利用结构化模板、历史交互上下文与领域知识,动态生成覆盖性更广的测试数据集。

2.3.3 交互执行与响应采集模块

该模块负责将测试请求 $ {Q}_{t} $ 依次发送至目标系统,通过标准网络通信协议(如HTTP POST、TCP等)进行交互,并实时采集响应 $ {R}_{t}={s}_{1}^\prime,{s}_{2}^\prime,\cdots ,{s}_{K}^\prime $。系统对每组 $ ({q}_{i},{s}_{i}^\prime) $ 进行本地记录,确保测试轨迹可追溯,并对异常行为进行实时标记。

2.3.4 响应分析与协议模型迭代模块

响应分析模块将新采集的请求—响应对 $ {E}_{i}=({q}_{i},{s}_{i}^\prime) $ 输入协议推断引擎,判断是否存在新的报文结构、字段变体或状态路径。大语言模型结合历史模型 $ {M}_{i} $ 和最新交互 $ {E}_{i} $,生成更新后的协议模型 $ {M}_{i+1} $,即:
$ \begin{array}{c}{M}_{i+1}={f}_{{\mathrm{LLM}}}({M}_{i}\cup {E}_{i})\end{array} $
该迭代过程推动协议模型逐步收敛于真实协议空间,发现更多隐含的命令、状态转移或功能边界。

2.3.5 安全性评估与漏洞标记模块

在协议模型持续完善的过程中,本模块基于新生成的协议路径、参数边界和异常响应,主动检测未授权访问、认证绕过、输入验证不足等安全隐患。结合大语言模型的漏洞推理能力,对疑似漏洞实现智能标记和优先级排序,为人工审核和自动报告输出提供依据。所有测试交互、协议结构、推断结论和漏洞线索均自动归档于本地知识库,支持结果复现、统计分析与后续知识迁移,为大规模协议安全测试与研究积累基础数据资源。
通过上述各模块的协同工作,智能代理系统实现了协议推断、请求生成、执行反馈与模型自进化的闭环流程,在极少人工参与的条件下,大幅提升了协议逆向与漏洞挖掘的效率与智能化水平。

2.4 关键实现细节

2.4.1 协议推断

大语言模型能够实现协议结构的自动推断,其机制源于大规模预训练所内化的分布式语义知识与序列建模能力。LLM通过在海量异构语料(包括互联网文本、技术文档、源代码乃至网络数据包捕获日志)上进行自监督预训练,隐式地学习到了多种结构化模式的通用模板。当模型接收到协议交互的示例数据(如请求—响应字节流)时,它会利用其在代码、标记化数据格式及自然语言描述中学习到的分界符识别(如空格、换行、特定字节)、长度编码模式(如大端序/小端序数值)和上下文关键词关联(如“HTTP/1.1”与后续状态码的对应关系)等能力,对输入流进行潜在的语法解析。另外,Transformer架构的核心组件——自注意力机制,赋予了模型跨位置依赖建模的强大能力,这使得模型能够捕捉协议数据中存在的长程约束关系。例如,载荷长度字段的数值与实际数据部分字节数的一致性、校验和的计算范围,乃至序列历史(如TCP会话状态)的动态格式转换。这种推断本质上是基于统计关联的隐式结构归纳,而非基于显式的协议规范理解。
然而,该过程并非完全可靠,这种推断具有显著的概率特征与幻觉风险。由于模型缺乏对协议语义的符号化理解与确定性逻辑推理能力,其生成的结构假设可能仅满足表面上的局部一致性,有可能生成看似合理的键值对,但键名不符合实际协议定义,或在面对嵌套TLV编码或加密载荷训练数据中低频出现的复杂约束时失效。例如,在分析某路由设备管理协议时,模型在推断嵌套结构时,可能错误地认为“config”字段内部包含“network”“system”“security”等子对象,但真实协议仅支持“config”的扁平结构。此类错误结构在后续生成阶段可能导致解析异常,影响字段偏移分析及协议结构建模。这类过度泛化推断即构成了典型的幻觉负例。为缓解此问题,本文采用反馈迭代更新协议模型,通过判断服务器的真实响应,判断LLM生成用例的有效性,并进行及时调整。
具体实现中,系统首先将预处理后的少量网络流量样本通过API接口输入大语言模型 $ {f}_{{\mathrm{LLM}}} $,通过精心设计的Prompt,使模型归纳出消息体的结构模式、字段排列顺序、参数类型及其取值分布。模型可自动识别报文类型(如请求/响应、命令/查询)、字段顺序与嵌套关系、关键参数的含义与作用、潜在的操作分支。利用DeepSeek模型归纳推理与上下文泛化能力,对未见过的功能或参数组合进行补全。例如,基于表1中观测到的“action”: “get”,大语言模型能够推断出可能还存在“action”:“set”,“action”:“delete”等其他操作类型,通过发送至服务端并验证响应,从而自动扩展协议的操作集合和功能空间。

2.4.2 测试用例生成

基于推断出的协议模型 $ {M}_{t} $,代理系统与大语言模型协作,自动设计多样化测试用例集,覆盖正常流程与异常场景。以表1为例,具体包括如下内容。
边界值用例。针对数值、字符串等参数,生成最大、最小、超长、空值等边界输入,检验协议实现的健壮性与容错性。例:"param":"aaaaaaaaa...aaaa"(超长字符串),"value":65535
类型异常用例。生成非法类型或格式错误的参数,测试协议解析与类型校验机制。例:"count":"not_a_number","enable":null。
权限测试用例。在不同认证状态或权限等级下,尝试访问敏感命令或资源,检测权限校验机制是否完善。如去除TOKEN字段或用无效TOKEN访问正常访问接口。
语义变异用例。组合或构造未出现过的命令、参数、字段组合,探索协议未公开路径或隐藏功能。例:"method":"call","params":["TOKEN","routerd","hidden_cmd",{}]。

2.4.3 多轮Prompt设计

针对协议结构归纳、字段识别、语义推断和异常检测等不同分析目标,系统采用多轮分层Prompt策略。即将复杂协议分析任务拆分为若干子目标,分步引导大语言模型递进归纳与结构化输出,从而提升模型在协议推断和功能泛化能力方面的准确性和可控性。图2为多轮Prompt示例。
图 2 多轮Promopt示例

Fig.2 Example of multi-turn prompts

通过递进提问和结构化回答,使协议结构、参数含义和功能空间被逐步归纳和拓展。

2.4.4 动态知识库更新

系统内置协议知识库模块,动态归档所有在测试过程中自动发现的新命令、参数和响应类型,并为后续测试与协议推断提供实时上下文。
假设初始测试仅发现命令“param_status,log_dump”及参数“action”,知识库内容为:
命令集:{param_status, log_dump};
参数集:{action}。
后续测试发现新命令“wificfg_get”和新参数“section”,系统自动将其添加至知识库:
命令集:{param_status, log_dump, wificfg_get};
参数集:{action, section}。
新生成的测试用例可基于最新知识库自动组合多样化请求,持续扩展协议空间覆盖率。该动态更新机制实现了协议测试过程的自学习与可追溯性,有助于长期测试和跨设备迁移应用。

2.4.5 异常与漏洞自动标记

为自动定位潜在风险,系统根据响应内容预设多维判据,一旦检测到未授权访问、系统异常或权限绕过等高危现象,自动进行标记,并在测试结果中突出提示,辅助安全人员高效定位关键风险点。
由于部分异常响应可能与协议错误、服务超时或环境噪声等非安全因素相关,系统在早期测试阶段存在一定比例的误报。为此,系统引入基于规则匹配与统计学习相结合的误报抑制机制,通过多轮响应比对,自动识别并过滤假阳性结果,从而显著降低误报率。实验结果表明,该机制在保证高风险检测率的同时,可将总体误报率控制在较低水平。

3 实验设计

3.1 实验目标

本实验旨在验证LPRT在网络设备漏洞发现方面的有效性。通过对多种常见网络设备进行协议安全测试,评估该方法相对于传统模糊测试工具在漏洞挖掘数量和严重性上的提升程度。实验的目标是确定该LLM引导的方法能否针对未知或文档不详的协议,在有限初始信息下,提高生成测试用例的有效率,并发现更多漏洞。这一目标聚焦于网络设备常见通信接口HTTP协议的安全性,旨在证明大语言模型融合安全测试能够提高漏洞发现的效率和质量。

3.2 实验对象与场景

设备覆盖了典型的协议场景,即传统Web接口,(如路由器的HTTP表单和CGI请求)。每种设备均运行真实最新版本的固件,以保证实验发现的漏洞具有实际意义。通过在不同设备和协议上的测试,能够全面评估LPRT方法在异构网络设备上的通用漏洞挖掘能力。实验环境如图3所示。
图 3 实验环境

Fig.3 Experimental environment

3.3 对比实验

为评估LPRT方法的优势,本文选择了3款主流的协议模糊测试或逆向分析工具进行对比实验。同时,在对比实验中,为评估将大语言模型融入传统被动逆向工具对协议逆向与后续模糊测试能力的提升效果,本文增加了一组对比工具,将DeepSeek-V3.2-Exp用于协议逆向的LLM-Netzob方案。所选工具及方案在业界和学界具有代表性,对比工具如表2所示。
表 2 对比工具

Table 2 Comparison tools

工具 初始操作 输入 时间
Boofuzz 手动编写测试脚本 10条样本 24 h
Snipuzz 手动编写测试脚本 10条样本 24 h
Netzob 手动编写测试脚本 10条样本 24 h
LLM-Netzob LLM生成模板 10条样本 24 h
LLM-Netzob方案首先根据预处理后的少量流量样本,利用大语言模型生成协议逆向后的适用于Netzob的结构化模板,并将该模板作为后续自动化分析与模糊测试的语义约束器。随后系统以两条并行路径推进,一方面基于LLM生成的结构化模板,采用Netzob的模糊测试器进行测试;另一方面直接采用Netzob的聚类和分割模块进行协议逆向,生成结构化模板后直接利用自身模糊测试器进行测试。
为了公平比较,各工具对每台设备的测试都采用统一的策略。
相同初始输入。各工具均从相同的合法通信种子开始,针对不同的被测设备,分别使用同一组相同的HTTP请求/响应样本集,样本为预处理后的10条不同功能请求数据。
相等测试强度。本文为每个工具分配相等的模糊测试时间和资源,各工具针对每台设备统一测试24 h,避免测试时间差异导致结果偏颇。
一致监测标准。所有工具对漏洞的判定标准一致,即以设备崩溃、异常重启、未授权操作成功等作为潜在漏洞触发的标志,并记录相关数据。
通过这样的对比方案设计,确保实验结果能客观反映各方法在测试用例有效率和漏洞发现能力上的差异。

3.3.1 测试用例有效率

在实验过程中,针对每台测试目标设备或服务,记录模糊测试工具所生成并发送的全部测试用例及其对应的HTTP响应。根据前述有效性标准,判断每个测试用例是否被目标系统成功解析,并进入业务逻辑处理流程。若服务器返回2xx、3xx或5xx状态码,或返回带有语义错误提示的4xx响应(排除401与403),则该测试用例被计为有效;否则(如返回400、401、403状态码,或响应体为空、为默认错误模板等情况)则视为无效。该标准确保测试用例能够真实反映模糊测试工具对协议格式和语义的理解程度,用例有效率越高,表明工具在协议语法约束、字段组合、参数变异方面越精准,生成的用例质量越高,更有效探索程序逻辑路径,从而提高漏洞发现概率。
在每轮测试结束后,统计该工具在该测试目标下的测试用例总数与有效用例数量,据此计算测试用例有效率(Effectiveness Rate, ER):
$ {\mathrm{ER}}=\frac{{N}_{{\mathrm{valid}}}}{{N}_{{\mathrm{total}}}}\times 100\% $
最终对所有目标的ER取算术平均,作为该工具的平均测试用例有效率,用于横向对比不同工具生成高质量测试输入的能力。
考虑到LLM-Netzob与LPRT在生成过程中可能受到大语言模型“幻觉”及随机性影响,导致相同Prompt下结果略有差异,本文在每组实验中重复运行3次,选取有效率最高的一轮结果进行统计,以减少随机波动对实验结论的干扰。而传统模糊测试方法基于固定策略变异,输入生成过程不存在“幻觉”问题。
各工具测试用例有效率如表3所示。造成差异的原因如下:Boofuzz在默认配置下依赖盲目的变异策略,缺乏对协议语义的理解,因此其生成的大量测试用例会违反协议格式约束。相比纯随机变异,Snipuzz虽具备反馈引导机制,但协议字段识别不够精细,部分用例仍无法通过语法校验。Netzob尽管基于协议逆向,但自动推导的协议模型精确性有限,部分变异仍超出目标应用允许范围。LLM-Netzob通过将大语言模型生成的协议模板融入Netzob,提升了协议语义约束能力,从而使生成用例更符合目标协议格式。相比之下,LPRT依靠探索性变异与动态模板优化,使种子变异约束有所增强。
表 3 各工具测试用例有效率

Table 3 Test case validity rate of different tools

网络设备 Boofuzz Snipuzz Netzob LLM-Netzob LPRT
ToToLink A720R8.08%23.06%11.83%35.84%42.18%
ToToLink A3300R6.12%17.60%11.01%36.25%47.36%
ToToLink A3600R6.12%13.41%15.72%37.42%44.92%
NetCore POWER4S9.49%18.63%10.21%35.96%49.87%
NetCore POWER9S PRO7.32%16.38%11.18%37.13%53.11%
Linksys EA7500 V28.65%17.43%13.66%36.50%53.72%
平均值7.63%17.75%12.27%36.52%48.53%

3.3.2 漏洞数量

本文提出LPRT方法共发现了10个安全漏洞。在相同实验环境与输入条件下,对比工具Boofuzz、Snipuzz、Netzob均未发现任何漏洞,而LLM‑Netzob在该条件下发现了3个漏洞。造成这种差异的主要原因如下。
Boofuzz等传统生成式模糊测试工具高度依赖手工定义的协议模板和用例变异规则,难以覆盖协议中未公开的接口、隐藏的参数组合及边界场景;对于无文档、无先验知识的私有协议,其测试用例空间严重受限,易遗漏敏感功能和非公开命令。Snipuzz等黑盒片段推断方法仅依靠设备对畸形输入的简单反馈来划分报文结构,缺乏对协议字段语义、命令空间和权限关系的深入理解,难以系统地组合出能够触发权限绕过和信息泄露的复杂请求。Netzob虽具备较强的被动协议格式归纳能力,但本质上不具备主动测试和深层应用逻辑测试能力,无法针对协议的异常分支和未授权访问路径进行针对性的安全验证。
在小样本流量条件下,LLM-Netzob相较于传统纯统计和聚类方法的优势尤为明显。传统Netzob在协议逆向中高度依赖流量样本的覆盖率与数量,当样本量有限时,字段划分的准确性和状态机抽取的完整性往往受限,容易出现字段切分错误、状态遗漏或冗余状态。相比之下,将大语言模型引入后,LLM-Netzob可以利用预训练模型中蕴含的语言与逻辑归纳能力对有限样本进行语义推断,从而在样本稀缺的情况下仍能生成更完整的协议格式模板,同时发现了部分漏洞。
相比之下,本系统依托于大语言模型强大的语义理解与泛化能力,能够根据少量样本推断协议结构、参数关系与命令空间,并自动生成覆盖多样化场景的测试请求,尤其擅长探索权限边界和异常路径。因此,本系统在测试范围和深度上,显著优于依赖静态模板或单纯变异的传统工具,能有效挖掘难以通过常规方法发现的高危安全漏洞。
实验中,LPRT工具共触发16条潜在漏洞警告,经人工复核后确认其中10条为真实漏洞,其余6条为误报,整体误报率约为37.5%。误报主要来源于两类情况:一是输入样本量有限导致模型在协议推断阶段生成不存在的字段或操作路径,从而触发异常响应;二是协议实现允许一定范围的异常输入场景,但系统判定为潜在风险。人工复核有效降低了误报干扰,确保报告中标注的高危问题具有较高可信度。

3.4 漏洞发现

表4所示,LPRT成功识别了2种不同品牌5种不同型号的网络设备中的10个未公开安全漏洞。具体包括:2个信息泄露漏洞、2个未授权访问漏洞、2个拒绝服务漏洞、2个协议逻辑缺陷,以及2个远程代码执行(RCE)漏洞。信息泄露与未授权访问漏洞揭示了协议设计或权限校验中的严重缺陷,DoS漏洞可能导致设备不可用,逻辑缺陷影响协议稳定性与正确性,RCE漏洞则直接威胁设备系统的整体安全。这些漏洞涵盖了网络设备协议安全的多个关键风险点,均可实现本地PoC验证,部分漏洞具有极高的危害性,上述漏洞均已提交至国家信息安全漏洞共享平台(CNVD),其中5个已分配CNVD编号信息如表5所示。
表 4 已发现的未公开漏洞

Table 4 Unreported vulnerabilities revealed

厂商 设备 固件版本 LLM-Netzob LPRT发现漏洞
ToToLink A720R V4.1.5cu.630 1 4
A3300R V17.0.0cu.596_B20250515 0 1
A3600R V5.9c.4959 2 4
NetCore POWER4S V3.0.4.59435 0 0
POWER9S PRO V1.0.0.221114.103550 0 1
表 5 CNVD编号信息

Table 5 CNVD identification number

CNVD编号 漏洞类型 危害级别
CNVD-2025-19011 信息泄露 中危
CNVD-2025-19450 拒绝服务 高危
CNVD-2025-19451 未授权访问 中危
CNVD-2025-21915 代码执行 中危
CNVD-2025-22880 未授权访问 高危
以某路由器中发现的认证绕过漏洞为例,LPRT系统在仅观察到少量初始请求样本的情况下,通过大语言模型对参数语义进行自动推理,生成了{"topicurl":"getInitCfg"}的测试用例。该请求被发送至设备的web接口后,系统成功获取包含有效认证令牌(token)的响应数据。分析表明,该接口未对请求主体进行任何身份认证判断,攻击者可在无需登录的前提下获取“token”,并据此访问所有受保护的管理接口,构成典型的认证绕过与信息泄露风险。该漏洞危害极大,不仅暴露了设备内部配置信息,还可被用于进一步伪造恶意管理操作请求,实现设备配置篡改、敏感信息窃取乃至远程控制。在未经固件反编译或协议文档的辅助下,LPRT能够通过自动生成的语义请求精准触发漏洞,展现出模型在协议逆向与安全测试任务中的强大语义表达能力与泛化能力。目前该漏洞已获CNVD确认,并分配编号为CNVD-2025-19451。
本方法能够发现信息泄露、未授权访问等此类型漏洞,根本原因在于大语言模型驱动的方法能够根据少量流量样本智能推断协议结构,自动扩展请求类型和参数组合,具备强大的语义理解和动态反馈能力,从而系统地覆盖传统工具难以覆盖的协议输入和状态空间以及异常路径,尤其在物联网设备协议复杂、文档缺失、实现多样场景下,更能有效挖掘深层次的安全隐患。

4 结束语

本文提出了一种大语言模型驱动的网络协议逆向与安全测试方法,通过引入DeepSeek智能代理,实现了文本类网络协议结构的自动推断与用例生成,显著提升了基于协议逆向的安全漏洞自动发现效率。实验在多种真实网络设备上发现了多个高危安全漏洞,验证了本文方法的有效性,充分展示了大语言模型在协议分析和智能化安全测试领域的潜力。
然而,本文方法仍存在若干有待进一步解决的问题。首先,当前方案主要针对文本协议,对于二进制类协议的结构推断与适配能力尚有限。其次,现有方法对协议状态机的建模和多轮会话支持有限。实验表明Prompt设计对模型生成质量和漏洞发现效果具有显著影响,不同Prompt表达方式会导致模型在语义泛化与异常输入生成上的差异。因此,未来可结合长上下文追踪、专用状态建模机制与自适应Prompt优化策略,重点研究面向二进制的自动推断与测试技术,以及基于状态感知和Prompt自进化的多轮交互协议建模方法。这些改进将有助于进一步提升系统在复杂协议环境下的通用性与漏洞挖掘能力。
未来可进一步引入多类型大语言模型对比实验,如Gemini、Claude、ChatGPT等大语言模型,与DeepSeek在相同测试框架下进行横向评估。通过比较不同模型在协议字段识别准确率、生成样本有效率、幻觉率及漏洞触发数量等维度的表现,可揭示模型结构与训练机制对协议理解能力的影响。这类跨模型实验可进一步揭示大语言模型在不同任务子空间(结构推断、状态建模、安全推理)中的性能差异,为模型架构选择、微调策略设计及专用安全模型构建提供指导。
值得深入研究的是,大语言模型在通用语料上训练得到的推理与归纳能力,虽然可较好地识别协议结构模式,但在安全检测等垂直领域任务中的表现仍可能受限于领域知识覆盖度与安全语料稀缺性。因此,一个重要的研究方向是针对安全检测任务开展垂域微调。通过引入包含漏洞描述、协议规范、攻击样本、安全日志与PoC语料的高质量安全数据集,可使模型在参数层面学习到更精准的协议语义表示与漏洞模式识别特征,从而提升其在安全场景下的泛化能力与可解释性。
1
Fernandes E, Paupore J, Rahmati A, et al. A security analysis of emerging smart home applications[C]//IEEE Symposium on Security and Privacy (S&P). Piscataway, NJ: IEEE, 2016: 636-654.

2
Antonakakis M, April T, Bailey M, et al. Understanding the mirai botnet[C]//Proceedings of the 26th USENIX Security Symposium (USENIX Security 17). Berkeley, CA: USENIX Association, 2017: 1093-1110.

3
Kumar K, Bose J, Tripathi S. A unified web interface for the Internet of Things[C]//Proceedings of 2016 IEEE India Conference (INDICON). Piscataway, NJ: IEEE, 2016: 1-6.

4
Duchêne J, Le Guernic C, Alata E, et al. State of the art of network protocol reverse engineering tools[J]. Journal of Computer Virology and Hacking Techniques, 2018, 14 (1): 53- 68.

DOI

5
Bossert G, Guihéry F, Hiet G, et al. Towards automated protocol reverse engineering using semantic information[C]//Proceedings of the 9th ACM Symposium on Information, Computer and Communications Security (ASIACCS). New York: ACM, 2014: 51-62.

6
Pereyda J. Boofuzz: A network protocol fuzzing framework[EB/OL]. (2017-05-16)[2025-07-31]. https://github.com/jtpereyda/boofuzz.

7
Yang Z, Peng H, Jiang Y, et al. ChatHTTPFuzz: large language model-assisted IoT HTTP fuzzing[J]. International Journal of Machine Learning and Cybernetics, 2025: 1-22.

8
Wei Y, Chi K, Du S, et al. Large language model driven automated network protocol testing[C]//Proceedings of the 2025 Applied Networking Research Workshop (ANRW). New York: ACM, 2025: 32-38.

9
Gascon H, Wressnegger C, Yamaguchi F, et al. PULSAR: stateful black-box fuzzing of proprietary network protocols[C]//Proceedings of the 11th EAI International Conference on Security and Privacy in Communication Networks (SecureComm). Cham: Springer, 2015: 330-347.

10
Feng Y, Lai Y, Liu Z. Vulnerability mining for modbus TCP based on exception field positioning[J]. Simulation Modelling Practice and Theory, 2020, 102, 101989.

DOI

11
Lin P Y, Tien C W, Huang T C, et al. ICPFuzzer: proprietary communication protocol fuzzing by using machine Learning and Feedback Strategies[J]. Cybersecurity, 2021, 4 (1): 28.

DOI

12
Kleber S, Maile L, Kargl F. Survey of protocol reverse engineering algorithms: decomposition of tools for static traffic analysis[J]. IEEE Communications Surveys & Tutorials, 2019, 21 (1): 526- 561.

13
Zhang A, Zhang Y, Xu Y, et al. Machine learning-based fuzz testing techniques: a survey[J]. IEEE Access, 2023, 12, 14437- 14454.

14
Meng R, Mirchev M, Böhme M, et al. Large language model guided protocol fuzzing[C]//Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS). Reston, VA: The Internet Society, 2024.

15
Ma X, Luo L, Zeng Q, et al. LLM-assisted fuzzing of matter IoT devices [C]//Proceedings of the 33rd USENIX Security Symposium (USENIX Security). Berkeley, CA: USENIX Association, 2024: 4783-4800.

16
Cui L, Cui J, Hao Z, et al. An empirical study of vulnerability discovery methods over the past ten years[J]. Computers & Security, 2022, 120, 102817.

17
Aloraini B, Nagappan M, German D M, et al. An empirical study of security warnings from static application security testing tools[J]. Journal of Systems and Software, 2019, 158, 110427.

DOI

18
Doupé A, Cova M, Vigna G. Why Johnny can’t pentest: an analysis of black-box web vulnerability scanners[C]//Proceedings of the 7th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA). Berlin: Springer, 2010: 111-131.

19
Godefroid P, Levin M Y, Molnar D. Automated whitebox fuzz testing[C]//Proceedings of the Network and Distributed System Security Symposium (NDSS). Reston, VA: The Internet Society, 2008.

20
Cadar C, Dunbar D, Engler D R. KLEE: unassisted and automatic generation of high-coverage tests[C]//Proceedings of the 8th USENIX Symposium on Operating Systems Design and Implementation(OSDI) . Berkeley, CA: USENIX Association, 2008: 209-224.

21
Newsome J, Song D. Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits[C]//Proceedings of the Network and Distributed System Security Symposium (NDSS). Reston, VA: The Internet Society, 2005: 37-52.

22
Kaksonen R, Laakso M, Takanen A. A functional method for assessing protocol implementation security[M]. Oulu: VTT Publications, 2001.

23
Eddington M. Peach fuzzing platform[EB/OL].(2011-04-18)[2025-07-31]. Available: https://peachtech.gitlab.io/.

24
Zalewski M. American fuzzy lop: a fuzzer tool[EB/OL]. (2014-11-01)[2025-07-31]. http://lcamtuf.coredump.cx/afl.

25
Pham V T, Böhme M, Roychoudhury A. AFLNET: a greybox fuzzer for network protocols[C]//Proceedings of the 13th IEEE International Conference on Software Testing, Verification and Validation (ICST). Piscataway, NJ: IEEE, 2020: 460-465.

26
Natella R, Cotroneo D, Acri G, et al. StateAFL: greybox fuzzing for stateful network servers[J]. Empirical Software Engineering, 2022, 27 (4): 191.

27
Cui W, Kannan J, Wang H. Discoverer: automatic protocol reverse engineering from network traces[C]//Proceedings of the 16th USENIX Security Symposium. Berkeley, CA: USENIX Association, 2007: 199-212.

28
Comparetti P M, Wondracek G, Krügel C, et al. Prospex: protocol specification extraction[C]//Proceedings of the 30th IEEE Symposium on Security and Privacy (S&P). Piscataway, NJ: IEEE, 2009: 110-125.

29
Feng X, Sun R, Zhu X, et al. Snipuzz: black-box fuzzing of IoT firmware via message snippet inference[C]//Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS) . New York: ACM, 2021: 337-350.

30
Alshmrany K, Cordeiro L. Finding security vulnerabilities in network protocol implementations[EB/OL]. (2020-01-28)[2025-07-31]. Available: https://arxiv.org/abs/2001.09592.

31
Bermudez I, Tongaonkar A, Iliofotou M, et al. Towards automatic protocol field inference[J]. Computer Communications, 2016, 84, 66- 79.

Outlines

/