企业官网建设流程全解析

Rayhunter telcom-parser 模块解析：ASN.1 规范到 uPER 解码器的生成式 RRC 解析

【免费下载链接】rayhunterRust tool to detect cell site simulators on an orbic mobile hotspot项目地址: https://gitcode.com/GitHub_Trending/ra/rayhunter

本文讲解 Rayhunter 中telcom-parser这个独立 crate 的完整技术链路：如何从 3GPP 的 ASN.1 协议规范出发，用 hampi（asn1-compiler）自动生成 Rust 解析代码，再以未对齐紧凑编码（uPER）解码 LTE RRC 信令报文，并作为 Rayhunter 蜂窝协议分析（空加密检测、IMSI 采集请求检测、重定向降级检测等）的类型基础。读完后你将掌握该 crate 的依赖关系、解析器再生成命令、ASN.1 规范的获取途径，以及它在 Rayhunter 分析管线中被实际调用的位置。

模块定位与核心结论

telcom-parser crate 的定位在官方 README 中一句话概括：包含各类电信消息载荷的 ASN.1 规范，以及由规范自动生成的 Rust 解析代码。其核心设计决策有两条：

• 解析器是生成的，不是手写的。README 明确说明使用 hampi 作为 parser generator，并且 3GPP 协议采用unaligned Packed Encoding Rules（uPER）编码——这是 LTE RRC 层在线路上的实际字节编码方式，因此生成的代码必须按 uPER 而非 BER/DER 对齐解码；
• 规范文件按 3GPP 发布版本成套维护。仓库 telcom-parser/specs 目录下保存了 5 份 ASN.1 规范源文件，合计约 7 万行：

从依赖声明看（telcom-parser/Cargo.toml），该 crate 依赖asn1-compiler、asn1-codecs、asn1_codecs_derive三个 0.7.1 版本库（即 hampi 工具链的运行时组件）、bitvec（位级运算）、serde与thiserror，版本 0.12.0，Rust edition 2024。

解析器的生成流程

README 给出了两步再生成流程：

1. 安装 hampi 编译器：

cargo install asn1-compiler

asn1-compiler安装后提供rs-asn1c可执行文件（名称沿用 ASN.1 社区asn1c的命名习惯）。

2. 生成 LTE RRC 解析器：

rs-asn1c --codec uper --module src/lte_rrc.rs -- specs/EUTRA* specs/PC5-RRC-Definitions.asn

各参数含义：

• --codec uper：指定输出代码实现 uPER 编解码接口（对应运行时库asn1-codecs中的UperCodectrait），与 LTE RRC 在线路上的编码方式一致；
• --module src/lte_rrc.rs：指定生成的 Rust 模块输出路径；
• 其余位置参数是输入规范文件，specs/EUTRA*通配展开为 EUTRA 的 4 份 .asn 文件，再显式追加 PC5-RRC 定义。

生成产物 telcom-parser/src/lte_rrc.rs 长达 51188 行，文件头注释明确声明：

This file was autogenerated using hampi (https://github.com/ystero-dev/hampi), do not modify!

从源码结构看，该文件由三类内容构成：数千个从 ASN.1 约束推导出的pub const MAX_*上限常量（如MAX_BANDS: i64 = 64、MAX_CSI_IM_R12: i64 = 4）；把 ASN.1 SEQUENCE/MAP 翻译成 Rust 结构体、把 CHOICE 翻译成枚举的类型定义（如pub enum SecurityConfigHOHandoverType { IntraLTE(...), InterRAT(...) }，每个变体又对应展开的结构体）；以及为每个类型生成的 uPER 编解码实现。生成器给该文件统一加了#[allow(warnings, unused, unreachable_patterns, non_camel_case_types)]（见 telcom-parser/src/lib.rs 第 3 行），因为规范中的命名风格（如intraLTEKeyChangeIndicator）不符合 Rust 惯例且大量辅助类型只用于编码路径。

lib.rs：极薄的公开 API 面

telcom-parser/src/lib.rs 全文只有 18 行，是整个 crate 唯一的"手写"部分，定义了对外暴露的两样东西：

pub mod lte_rrc; #[derive(Error, Debug)] pub enum ParsingError { #[error("Failed to decode UPER data: {0}")] UperDecodeError(PerCodecError), } pub fn decode<T>(data: &[u8]) -> Result<T, ParsingError> where T: UperCodec<Output = T>, { let mut asn_data = PerCodecData::from_slice_uper(data); T::uper_decode(&mut asn_data).map_err(ParsingError::UperDecodeError) }

decode函数是所有 uPER 解码的统一入口：用PerCodecData::from_slice_uper把原始字节切片包装成位级游标，再调用目标类型实现的UperCodec::uper_decode。错误被收敛为单一变体ParsingError::UperDecodeError，底层错误细节由asn1-codecs的PerCodecError携带。这个泛型签名意味着任何由 hampi 生成的类型都可以作为解码目标——上层只需用不同的类型参数区分消息种类。

ASN.1 规范从哪里来

README 专门用一节解释了规范文件的来源，这也是该模块的一个实务要点：

• 3GPP（4G 及其他所有代际移动通信标准的制定方）把各协议的 ASN.1 规范发布在 Word 文档里（README 原文措辞相当直白："these horrific Microsoft Word docs"）；
• 文档中的 ASN.1 代码块以--ASN1START/--ASN1STOP文本标记界定，因此可以用脚本（例如 hampi 仓库自带的examples/specs/parse_spec.py）自动抽取；
• Rayhunter 没有自己写抽取脚本，而是直接从第三方 ASN.1 库（obj-sys 维护的 3GPP LTE ASN.1 集合）获取了这些 .asn 文件，存放在specs/目录。

理解这一点很重要：规范文件属于上游标准的快照，其正确性取决于来源与 3GPP Release 版本的一致性；rs-asn1c生成命令中--codec uper与这些规范文件是配套的整体，替换规范文件后必须重新生成src/lte_rrc.rs。

集成验证：一条 SIB1 报文的 uPER 解码

telcom-parser/tests/lte_rrc_test.rs 是模块自带的集成测试，验证"十六进制字节流 → uPER → 结构化 RRC 消息"的完整链路：

#[test] fn test() { let data = hex_to_bin("484c469010600018fd1a9207e22103108ac21bdc09802292cdd20000"); let mut asn_data = PerCodecData::from_slice_uper(&data); let sib1 = BCCH_DL_SCH_Message::uper_decode(&mut asn_data); dbg!(&sib1); }

测试选取的目标类型是BCCH_DL_SCH_Message（LTE 广播控制信道下行共享信道消息，即 SIB 的承载），解码成功后用dbg!打印结构体——从源码结构看，该类型形如pub struct BCCH_DL_SCH_Message { pub message: BCCH_DL_SCH_MessageType }，其内部的 CHOICE 枚举再经C1(...)变体展开为具体的 SIB 类型。测试同时演示了直接调用uper_decode与通过lib.rs的decode::<T>(data)辅助函数两种等价用法（后者由 Rayhunter 主体代码统一使用）。

在 Rayhunter 分析管线中的实际消费

telcom-parser 的价值最终体现在它如何被 Rayhunter 的分析层消费。libcrate 通过telcom-parser = { path = "../telcom-parser" }依赖它（lib/Cargo.toml），并在 lib/src/lib.rs 中直接 re-export（注释说明原因："we use its types in our API"），使分析 API 对外可见生成的 RRC 类型。

核心消费点是 lib/src/analysis/information_element.rs：它把 GSMTap pcap 抓包中捕获的各类 RRC 消息按信道类型分派解码，全部走telcom_parser::decode：

GmtapType::LteRrc(lte_rrc_subtype) => { let lte = match lte_rrc_subtype { L::DlCcch => R::DlCcch(decode(&gsmtap_msg.payload)?), L::DlDcch => R::DlDcch(Box<lte_rrc::DL_DCCH_Message>), // ... 共 16 种终止消息类型 } }

从源码结构看，被解码的终止消息类型共 16 种，覆盖 LTE RRC 的全部逻辑信道方向组合：DL_CCCH_Message、DL_DCCH_Message、UL_CCCH_Message、UL_DCCH_Message、BCCH_BCH_Message（MIB）、BCCH_DL_SCH_Message（SIB1/SIBx）、PCCH_Message、MCCH_Message、SC_MCCH_Message_r13及各类 MBMS/sidelink 变体。仓库中的 tools/asn1grep.py 脚本维护了同一份"终止类型"清单，并基于 asn1tools 在这两份主规范（EUTRA-RRC 与 PC5-RRC）上做类型层级搜索——这是开发期确认"某字段在哪个消息路径下可达"的实用工具。

在此之上，Rayhunter 的各项诊断分析（位于 lib/src/analysis 目录）直接模式匹配生成的 RRC 结构体：

• null_cipher.rs 解析SecurityConfigHOHandoverType（含IntraLTE/InterRAT变体）判断切换时的密钥重派生配置，支撑"空加密"检测；
• imsi_requested.rs 使用BCCH_DL_SCH_MessageType、PLMN_Identity、MCC_MNC_Digit等类型提取网络身份与 IMSI 采集请求特征；
• incomplete_sib.rs 与 connection_redirect_downgrade.rs 基于BCCH_DL_SCH_MessageType_c1检测 SIB 不完整及向 2G/3G 的重定向降级行为；
• priority_2g_downgrade.rs 同样以生成的 RRC 结构体为输入分析优先级降级。

这条链路解释了 telcom-parser 的架构意义：它把"解析 3GPP 二进制信令"这件通常依赖 Wireshark 等外部工具的事，变成了 Rayhunter 进程内的纯 Rust 类型运算——pcap 抓包（GSMTap 封装）→telcom_parser::decodeuPER 解码 → 对生成的枚举/结构体做模式匹配 → 输出诊断结论。

已知边界与 README 中的 TODO

README 末尾保留了原计划的 TODO："implement proof of concept binary using this to parse QMDL, summarize the packets"——即用同一套方法解析 T-Mobile 网关的 QMDL 私有协议并汇总报文。需要说明的是，仓库中并不存在独立的 QMDL 解析二进制；从源码结构看，QMDL 相关功能由 daemon/src/qmdl_store.rs 等模块以手工解析的方式承担，而非经由 telcom-parser 的生成管线。这一条 TODO 应视为文档层面的遗留规划，不代表当前代码状态。

另外两点适用前提：

• 本 crate 目前只生成了解码能力的使用（decode/uper_decode），编解码器虽由 hampi 双向生成，但 Rayhunter 侧只消费解码路径；
• 若替换specs/下的 .asn 文件（例如升级到更新的 3GPP Release），必须重新运行rs-asn1c生成命令，且由于 51188 行的src/lte_rrc.rs是生成物，任何手工修改都会在重新生成时丢失——这是生成式解析器的固有约定。

小结

telcom-parser 是 Rayhunter 蜂窝协议理解能力的基石：specs/目录的 3GPP ASN.1 规范经rs-asn1c --codec uper生成 5 万余行的lte_rrc模块，lib.rs用 18 行代码收敛出decode::<T>这一统一解码入口，再由lib/src/analysis下的各检测器对结构化 RRC 消息做模式匹配，完成空加密、IMSI 采集请求、不完整 SIB、重定向降级等诊断。对希望扩展 Rayhunter 分析能力的读者，入口是三处文件：telcom-parser/specs（协议字段查什么）、tools/asn1grep.py（按类型名在规范层级中定位）、telcom-parser/tests/lte_rrc_test.rs（解码链路的可运行验证范例）。

【免费下载链接】rayhunterRust tool to detect cell site simulators on an orbic mobile hotspot项目地址: https://gitcode.com/GitHub_Trending/ra/rayhunter