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 协议规范出发用 hampiasn1-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 RulesuPER编码——这是 LTE RRC 层在线路上的实际字节编码方式因此生成的代码必须按 uPER 而非 BER/DER 对齐解码规范文件按 3GPP 发布版本成套维护。仓库 telcom-parser/specs 目录下保存了 5 份 ASN.1 规范源文件合计约 7 万行规范文件行数内容EUTRA-RRC-Definitions.asn181494G 主协议 RRC 消息定义绝对主体EUTRA-InterNodeDefinitions.asn670网际X2接口定义EUTRA-Sidelink-Preconf.asn274侧行链V2X预配置EUTRA-UE-Variables.asn240UE 变量定义PC5-RRC-Definitions.asn45PC5 侧行 RRC 定义从依赖声明看telcom-parser/Cargo.toml该 crate 依赖asn1-compiler、asn1-codecs、asn1_codecs_derive三个 0.7.1 版本库即 hampi 工具链的运行时组件、bitvec位级运算、serde与thiserror版本 0.12.0Rust edition 2024。解析器的生成流程README 给出了两步再生成流程1. 安装 hampi 编译器cargo install asn1-compilerasn1-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 decodeT(data: [u8]) - ResultT, ParsingError where T: UperCodecOutput 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 专门用一节解释了规范文件的来源这也是该模块的一个实务要点3GPP4G 及其他所有代际移动通信标准的制定方把各协议的 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_MessageLTE 广播控制信道下行共享信道消息即 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::decodeGmtapType::LteRrc(lte_rrc_subtype) { let lte match lte_rrc_subtype { L::DlCcch R::DlCcch(decode(gsmtap_msg.payload)?), L::DlDcch R::DlDcch(Boxlte_rrc::DL_DCCH_Message), // ... 共 16 种终止消息类型 } }从源码结构看被解码的终止消息类型共 16 种覆盖 LTE RRC 的全部逻辑信道方向组合DL_CCCH_Message、DL_DCCH_Message、UL_CCCH_Message、UL_DCCH_Message、BCCH_BCH_MessageMIB、BCCH_DL_SCH_MessageSIB1/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 中的 TODOREADME 末尾保留了原计划的 TODOimplement 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rayhunter telcom-parser 模块解析：ASN.1 规范到 uPER 解码器的生成式 RRC 解析
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 协议规范出发用 hampiasn1-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 RulesuPER编码——这是 LTE RRC 层在线路上的实际字节编码方式因此生成的代码必须按 uPER 而非 BER/DER 对齐解码规范文件按 3GPP 发布版本成套维护。仓库 telcom-parser/specs 目录下保存了 5 份 ASN.1 规范源文件合计约 7 万行规范文件行数内容EUTRA-RRC-Definitions.asn181494G 主协议 RRC 消息定义绝对主体EUTRA-InterNodeDefinitions.asn670网际X2接口定义EUTRA-Sidelink-Preconf.asn274侧行链V2X预配置EUTRA-UE-Variables.asn240UE 变量定义PC5-RRC-Definitions.asn45PC5 侧行 RRC 定义从依赖声明看telcom-parser/Cargo.toml该 crate 依赖asn1-compiler、asn1-codecs、asn1_codecs_derive三个 0.7.1 版本库即 hampi 工具链的运行时组件、bitvec位级运算、serde与thiserror版本 0.12.0Rust edition 2024。解析器的生成流程README 给出了两步再生成流程1. 安装 hampi 编译器cargo install asn1-compilerasn1-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 decodeT(data: [u8]) - ResultT, ParsingError where T: UperCodecOutput 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 专门用一节解释了规范文件的来源这也是该模块的一个实务要点3GPP4G 及其他所有代际移动通信标准的制定方把各协议的 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_MessageLTE 广播控制信道下行共享信道消息即 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::decodeGmtapType::LteRrc(lte_rrc_subtype) { let lte match lte_rrc_subtype { L::DlCcch R::DlCcch(decode(gsmtap_msg.payload)?), L::DlDcch R::DlDcch(Boxlte_rrc::DL_DCCH_Message), // ... 共 16 种终止消息类型 } }从源码结构看被解码的终止消息类型共 16 种覆盖 LTE RRC 的全部逻辑信道方向组合DL_CCCH_Message、DL_DCCH_Message、UL_CCCH_Message、UL_DCCH_Message、BCCH_BCH_MessageMIB、BCCH_DL_SCH_MessageSIB1/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 中的 TODOREADME 末尾保留了原计划的 TODOimplement 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考