深度揭密高通4/5G移动基带消息系统和状态机

​ 阿里安全 谢君

背景

本技术分析文章通过对高通的4/5G移动基带系统进行深入逆向工程提示其内部消息通信机制以及核心架构设计逻辑，本文的研究基于高通的4G基带MDM9707以及5G基带模块sdx55的固件之上分析完成，高通基带系统现在都是基于高通主流的hexagon DSP指令架构来实现，该架构非常适合应用于音视频编解码，计算机视觉等，软件无线电等应用中的浮点和向量计算，在高通骁龙处理器的子系统中大量使用，大多应用于手机，汽车，可穿戴设备以及移动通信设备中，Hexagon DSP相关信息可以从这里获取，运行在Hexagon DSP芯片上的操作系统QuRT是由高通设计的实时操作系统，高通基带系统所有的上层业务将会运行在该操作系统之上，阅读该技术分析文章之前，假定你已经对操作系统的原理有所了解，例如CPU调度，IPC(进程间通信)，以及基本的数据队列enqueue/dequeue的操作。

消息机制简介

一个系统里面运行着不同的任务，不同任务在不同的运行状态在处理相应的业务逻辑时可能需要与其它任务交换数据或者同步信息，这里面就需要操作系统的底层IPC机制来完成了，3GPP组织定义了不同移动通信技术从物理层/链路层/逻辑处理层等各种标准，例如（5GNR/4GLTE/3G WCDMA/TD-SCDMA/CDMA2000/2G /GSM等通信技术），这些技术标准在基带系统里面实现会被划分成不同的任务来维护不同的状态，处理不同的消息信令，以及维护不同通信技术的切换等操作，比如现在的大部分智能手机基带系统基本上都支持2/3/4G通信相关的技术，这些基带系统根据移动运营商支持的移动通信技术和国家区域支持的标准的不同会使用相应的移动通信技术，比如中国在3G时代中国移动使用的TD-SCDMA，而中国联通使用的是WCDMA技术，为了保证移动设备的一些基本功能的可用性（语音通信和sms短信息），比如某些地方部署了4G基站，你可以在那里使用4G LTE的（Voice-over-IP/SMS-over-IP）通信技术，在一些偏远的地区可能只部署了2G基站，这时基带系统根据环境切换到GSM的协议栈，这些功能的维护与切换从基带系统层面来讲都需要系统消息机制来配合完成。

高通基带系统的消息机制建立在运行的实时操作系统QuRT之上，之前我有一篇文章有简单介绍过底层IPC机制，今天我将详细介绍上层业务逻辑相关的消息传递机制与数据结构。我们把运行在基带系统上的业务逻辑实体的最小单位定义为线程（thread），根据线程生命周期的不同分为以下两大类：

• 短生命周期线程
  • 驱动/任务初始化线程（Driver initiator/Services Launcher)
  • 中断服务例程（IST)
• 长生命周期线程
  • 阻塞型消息接受线程

消息通信底层API封装简介：

而根据任务线程的业务功能的不同划分成以下几大类：

• 系统功能任务
• 通信技术协议栈分层任务
  • GSM/WCDMA/TDSCDMA/LTE L1/L2/L3相关的协议栈的任务等
• 上层应用任务
  • IMS volte/ecall/数据服务/包服务等
• 外设相关的任务
  • UIM/SIO/A2等

我在这里记录了高通MDM9607基带系统一次实时运行的任务快照列表。

高通基带系统消息机制

消息通信核心架构设计逻辑

• 兼容性
  • 在新的基带芯片上面开发新的移动通信技术单元的同时，保证老的功能模块能够正常使用，例如在开发5G功能的同时，以往的4G/3G/2G功能都能够正常使用和切换。
• 可扩展性
  • 在已有的功能模块上增加新的功能，具备灵活的扩展性，而不需要作太大的软件和硬件改动。
• 低耦合性
  • 新增的功能模块与已有系统上功能模块的耦合度低，接口少，减少引入问题的接口点和测试成本。

基于以上的设计理念，高通设计一套灵活的消息通信系统，一直到现在5GNR的基带系统也在用，接下来我将详细介绍该消息系统的架构，相关的算法和数据结构。

消息通信架构

为了区分不同任务所接受到的消息以及任务所能处理相应消息的原语操作权限，通过接受到的消息来区分消息来源以及接受到相应消息后的相应的处理动作，高通的消息系统引入了任务消息接受体（msgr_client）和UMID（Unique Message ID）的机制，任务消息接受体由相应的任务创建生成，并通过初始注册可接受消息UMID来设置任务相应原语操作的权限，每个任务可以创建一个或者多个msgr_client，每一个UMID消息也可以注册给多个msgr_client，每一个UMID消息标示着一次相应的原语操作，在MDM9607里面定义的UMID数量多达1万多个，而在最新高通的5G基带里面可使用的UMID高达2万多，每个UMID背后都对应着相应的原语操作，UMID的值与相应的命名规则如下。

UMID由32位组成，结构如下表

注：if type_id>9 ,type_id=type_id-6
offset bit 8~15 8bits type_id list

举个例子UMID 0x40D120E 对应的描述原语是LTE_RRC_IRAT_FROM_LTE_TO_G_RESEL_REQI，拆分结果如下:

注：这种UMID值的解析方法在某些定义里面并不适用，比如LTE_ML1_DLM_TST_SKIP_RACH_REQ的值为6，就没法用上面的方法解析，有些值并不严格遵循这种解析算法，可能是由于历史原因，定义UMID值的规则不一样。

基带系统把任务标示为多个不同的技术大类，来标示和模块化相应的子功能，以MDM9607为例：

模块ID

下图是MDM9607 LTE的部分子模块ID的对应关系

关键消息发送API:

消息路由

我们已经了解到UMID所对应原语操作的含义，如果需要执行相应的原语操作，只需要向注册过UMID的模块发送umid消息即可，接下来我们需要了解umid消息是如何路由到相应模块(tech_mod_id)的消息接收器(msgr_client)的，下面会详细介绍相应的算法和数据结构，我整理了几张表来描述。

为了更方便的理解上述的数据结构的关系与操作算法，画了一张简单的图来加深该消息系统的理解。
通过以上算法和数据结构，可以很方便的完成UMID与tech_mod_id的消息路由的注册，消息发送等操作。

需要说明的一点就是一个tech_mod_id可能会关联多个msgr_client，所以msgr_client_id就成了消息传递的唯一标识，通过msgr_client_id得到全局的msgr_client_desc的结构定义，该结构体里面包含接受消息的任务utcb和接受消息的signal id，这里通过tech_mod_id 0xf19对应的MM（Mobility Management）任务进行举例。

我在一个实时运行的MDM9607系统上面，描绘出所有UMID和tech_mod_id之间的消息路由情况，由于实在太大，
可以在https://github.com/vessial/baseband/blob/master/umid_pro.svg 进行查看。

消息状态机（State Machine）

高通基带系统里面的消息状态机，是实现3GPP定义功能最重要的组成部分，消息状态机在移动通信系统里面扮演着非常重要的角色，也是多模移动通信系统的核心，3GPP在定义的多个移动通信技术的分层协议栈时，不同的通信技术模式之间切换，会通过状态机来维护相应的分层逻辑的状态和可操作功能，接下来将重要介绍高通基带系统使用的状态机数据结构以及相关算法，本文将研究主要流4G LTE和5G NR系统上使用的第二代状态机消息系统，老的第一代状态机系统不在这里介绍了。

我从MDM9607固件里面提取的详细的状态机信息可以在https://github.com/vessial/baseband/blob/master/lte_sm.log 进行查看。

3GPP定义的L3层的RRC(Radio Resource Control)的状态机是最为复杂的，高通在实现4G LTE的RRC时使用了大量的状态机进行功能管理。
MDM9607 4G LTE RRC状态机类型如下:
state name: LTE_RRC_CSG_ASF_SM
state name: LTE_RRC_DT_SM //
state name: LTE_RRC_IRAT_TO_G_MGR_SM
state name: LTE_RRC_LLC_SM
state name: LTE_RRC_CAPABILITIES_SM
state name: LTE_RRC_IRAT_FROM_1X_MGR_SM
state name: LTE_RRC_SEC_SM //sim认证和密钥协商管理相关的状态机
state name: LTE_RRC_CRP_SM
state name: LTE_RRC_IRAT_FROM_DO_MGR_SM //负责从CDMA-EVDO切换到LTE的管理状态机
state name: LTE_RRC_IRAT_FROM_TDS_MGR_SM //负责从TDSCDMA切换到LTE的状态机
state name: LTE_RRC_PAGING_SM //寻呼管理的状态机
state name: LTE_RRC_CONFIG_SM
state name: LTE_RRC_MISC_SM
state name: LTE_RRC_MEAS_SM
state name: LTE_RRC_CEP_SM
state name: LTE_RRC_IRAT_TO_1X_MGR_SM
state name: LTE_RRC_IRAT_FROM_W_MGR_SM
state name: LTE_RRC_MDT_SM
state name: LTE_RRC_IRAT_TO_DO_MGR_SM
state name: LTE_RRC_CONTROLLER_SM //关键的LTE的控制状态机，控制服务的停止和开启
state name: LTE_RRC_IRAT_TO_TDS_MGR_SM
state name: LTE_RRC_IRAT_TO_W_MGR_SM //从LTE切换到WCDMA的管理状态机
state name: LTE_RRC_EMP_SM
state name: LTE_RRC_MH_SM
state name: LTE_RRC_UEINFO_SM //UE信息管理的状态机
state name: LTE_RRC_SIB_SM //系统信息块的管理状态机
state name: LTE_RRC_PLMN_SEARCH_SM //搜索网络使用的状态机
state name: LTE_RRC_IRAT_FROM_G_MGR_SM //从GSM切换到LTE的状态机
state name: LTE_RRC_CSP_SM //cell search plmn状态机
state name: LTE_RRC_ESMGR_SM // EMBMS管理状态机
state name: LTE_RRC_CRE_SM

我们拿LTE_RRC_PAGING_SM状态机定义作例子与之对应的数据结构作解析

下图为MDM9607 4G LTE_RRC的状态机图谱

状态机操作实例

为了更直观的理解消息状态机的操作过程，我这里提供了一个例子来展示消息传递过程以及状态机的处理过程，这个过程是在基带处理IDLE状态下，没有接入任何移动通信网络，到基带一次接入4G LTE网络到SIM认证的过程，这里只提供RRC的状态机的处理过程。

DL_DCCH的Information Transfer字段里面包含了来自MME发送过来的认证请求数据(LTE NAS EMM信令消息id 0x52)，包含有nas key set id,
16个字节的认证随机数据auth_param rand，以及16个字节的auth param AUTN数据，SIM卡通过收到的这两个关键信息进行认证，
并计算生成Auth_resp发送给MME进行比较完成本地端和服务器端的认证，本地端计算如下。

本地端收到的rand(16bytes)+AUTN(16bytes)
K为sim卡和MME都持有的sim卡的唯一隐私数据，sim卡端只有sim卡芯片可以读取。

SIM卡端密钥派生认证过程，f1/2/3/4/5为sim卡的计算功能函数

AK=f5(K,rand)

IK=f4(K,rand)

CK=f3(K,rand)

RES=f2(K,rand) //计算给MME进行认证SIM卡的数据

SQN=AUTN^AK (6bytes)
AMF=AUTN[6:8]

MAC=f1(K,SQN,rand,AMF)

SIM卡端认证MME端过程

sim_autn=SQN^AK(6bytes)+AMF(2bytes)+MAC(8bytes)

比较MME发过来的AUTN和sim_autn ，相等则认为MME合法。

基带把sim卡计算得到的RES通过LTE NAS EMM 信令消息号0x53包裹到UL_DCCH的InformationTransfer字段里面发给基站进而到MME进行认证。

MME认证SIM卡的过程就比较简单了。
MME端计算XRES=f2(K,rand)，然后比较收到的RES，相等表示MME认证SIM卡成功，至此认证完成。
由于上述操作涉及EMM和RRC之间的交互过程比较复杂，这里只是简单提一下，EMM的状态机会在下一篇文章里面单独详细介绍。

结语

由于从全球公开的信息渠道中并不能获取高通基带系统的深入信息，所以花费1年多的时间通过对底层操作系统和上层3GPP实现的业务系统进行深度逆向工程，这篇文章只是系统性的介绍了高通4/5G基带系统的消息机制和消息状态机，我认为这是一个关键的架构设计，梳理清楚其消息架构对于理解3GPP实现的消息原语操作以及对移动通信技术的多模分层设计有非常大的帮助，该消息系统架构设计具有非常好的扩展性，可以很灵活的增加新的功能到该消息框架中去，可以很好的减少系统测试成本，有很多设计理念值得学习和借鉴，由于现今高通5G基带所支持的UMID操作数高达2万多个，所以这里的展示的例子只是揭示了状态机功能操作的冰山一角，后续会持续研究对于状态机安全漏洞的挖掘研究，实现高效的5G安全测试体系，通过对基带系统的深刻认知，可以更好的对基站系统和核心网系统进行安全评估。

[培训]二进制漏洞攻防（第3期）；满10人开班；模糊测试与工具使用二次开发；网络协议漏洞挖掘；Linux内核漏洞挖掘与利用；AOSP漏洞挖掘与利用；代码审计。