深度揭秘高通移动基带 最便宜的5G安然检测对象_基带_状况机

近日，阿里安全发布了一项新一代安全架构前沿技能成果，研究职员首次对高通4/5G移动基带进行了深度解析，基于研究事理打造了低本钱的5G安全威胁检测工具，保护大众的通信安全，助力新基建安全培植。

目前市场上只有个别厂商的少量机型利用自研基带，打造谢绝wei基站旗子暗记要求的手机，大部分机型依然利用该基带。
安全专家认为，对手机基带深入阐发，体系化地对抗5G时期攻击者开辟新路径进行的通信攻击十分主要。

阿里安全资深安全专家侯客对高通基带底层硬件芯片、软件操作系统到上层业务逻辑进行了系统研究，不仅能进一步研发具备强有力的移动通信根本设备的安全测试工具，也能将其改造成具备威胁检测能力的防护工具，对通信安全研究具有主要意义，基于硬件打造的低本钱通信威胁检测工具便是对基带进行深度研究的成果之一。

以下为阿里安全对高通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封装简介：

//旗子暗记发送int rex_send_sigs(utcb dst_task_obj,unsigned int signal_id);//第一个参数为向目标任务发送的构造定义，第二个参数为要发送的旗子暗记idint rex_wait_sigs(unsigned int recv_sigs_masks);//第一个参数为可以许可接管旗子暗记id的掩码，每个任务最多可以设置可接管旗子暗记id个数为32个，每个任务可以接管多个旗子暗记id时，通过旗子暗记id的或操作来得到该任务可以接管旗子暗记的掩码，返回值为接管到的旗子暗记id//如果是带数据的旗子暗记发送，封装底层API，类似如下int send_sigs_with_dat(utcb dst_task_obj,unsigned int signal_id,data_queue send_data_queue);int recv_sigs_with_dat(unsigned int recv_sigs_masks,data_queue recv_data_queue);

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

1. 系统功能任务

2. 通信技能协议栈分层任务

GSM/WCDMA/TDSCDMA/LTE L1/L2/L3干系的协议栈的任务等

3. 上层运用任务

IMS volte/ecall/数据做事/经办事等

4. 外设干系的任务

UIM/SIO/A2等

我在https://github.com/vessial/baseband/blob/master/dump_task.svg记录了高通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的值与相应的命名规则如下。

Name

offset and length

Comment

tech_id

24~31 8bits

eg, LTE->0x04, IMS->0x15, MDM9607 0x1b, SDX55 0x20

mod_id

16~23 8bits

eg, 0xd -> RRC 0xf -> MAC 0x11-> RLC DL

type_id

8~15 8bits

type <= 0x09) || (type >= 0x11 && type <= 0x17,totally 0x11 type_ids

op_type_id

4~8 4bits

Op entity ,eg IRAT_FROM_LTE_TO_G

op_id

0~3 4bits

Opcode seq, eg abort/search/startup/deinit/init/cfg etc

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

Type_name

value

Comment

CMD

1

Command primitive

REQ

2

request

RSP

3

response

IND

4

indication

DLM

7

downlink message

CNF

8

confirm

TMR

9

timer

REQI

0x12

request Internal

RSPI

0x13

Response internal

INDI

0x14

indication internal

CNFI

0x15

confirm internal

TMRI

0x16

timer internal

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

name

value

LTE

0x04

RRC

0x0d

REQI

0x12

RESEL

0x0

IRAT_FROM_LTE_TO_G

0x0e

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

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

tech_id

Tech_name

0

MCS(Modem Common Service)

2

MM_CM(0x201) UI(0x20a) (Unnumbered Information) MM_DOM(0x202),MM_MMOC(0x251)

4

LTE

5

FTM

6

rfa_tech （0x600 rf_fwrsp,0x603 rfgsm, 0x604 rf_1x ,0x601 0x605 rf_hdr ,0x606 rfgsm_ftm,0x607 rf_lte,0x608 rf_lte_ftm,0x60b rf_qmi, 0x60c rf_meas,0x40f/0x1a04 rf_lte ,0x120f rf_tdscdma）

7

cdma

8

hdr

9

gsm

0x0a

location(gps/gnss)

0x0b

wcdma

0x0c

ds(data service)

0x0d

1x(csfb)

0x0f

nas(0xf19 mm, 0xf1c esm)

0x10

gstk(Generic SIM Application Toolkit)

0x12

tdscdma

0x13

wms

0x15

ims

0x16

qmi

0x17

ecall 0x1701 ecall_app ,0x1702 ecall_ivs

0x18

policyman

0x1a

rflm

模块ID

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

tech_id+mod_id

name

0x401

ML1 MGR

0x407

LL1_SRCH

0x408

LL1_DL

0x409

LL1_UL

0x40a

LL1_SYS

0x40b

LL1_Async

0x40d

RRC

0x40f

MAC

0x411

RLC DL

0x412

RLC UL

0x413

PDCP DL

0x414

PDCP UL

0x41b

ML1_GM

0x41e

SW.app

0x420

ML1_GM_SCHDLR

0x427

TLB(Test Loop )

0x42b

ML1_GM_Sleep

0x434

ML1_AFC

0x43b

PDCP offload

0x43e

ML1 offload

0x43f

ML1 Co-existence

0x441

ML1 GM MSMGR

0x442

PDCPCOMP

0x445

ML1 SM FSCAN

关键发送API:

msgr_send(umsg buf,uint32 buf_size);struct umsg{ struct msgr_hdr_struct_type{uint32 dest_umid; //offset 0 ，要发送的UMID号uint16 src_tech_mod_id; //offset 4，发送源tech_mod_id的标识 uint8 num_attach;// offset 7 uint8 tail_flag ;// offset 8 ，头部结尾标志0x7fuint8 inst_id;// offset 9，} uint8 send_dsm_flag;//offset 0x10 ,置1表示发送数据通过dsm构造承载的标志 dsm dsm_obj;//offset 0x14 , 发送数据dsm构造指针 }msgrq_wait(void msgr_client_ptr,void msg_recv_buf,uint32 msg_recv_buf_size,uint32 msg_recvd_size_ptr);//接管的函数msgr_register(uint16 mod_id,void msgr_client_ptr,void mailbox_obj,uint32 umid);//msgr_client注册umid的路由

路由

map_name

map_size

key

value

value_size

Memory Attribution

techs_map

techs 8

tech_id

module_counts, modules_map

8 bytes

Read Only

modules_map

module_counts 0x11 2

(mod_id 0x11+type_id) 2

types_map_id

2 bytes

Read Only

types_map

types_map_ids 0x20

types_map_id 0x20 +(op_type_id&0x1e)

tech_mod_type_seq

2 bytes

Read/Write

umids_map

umid_seq_id 0x8

8 (tech_mod_type_seq+op_id)

umid, next_umid_seq_id,msgr_client_id

8 bytes

Read/Write

msgr_clients_map

0x34total_msgr_client_counts

msgr_client_seq_id

msgr_client_desc

0x34

Read/Write

struct msgr_client_desc{ //全局msgr_client构造描述 uint32 umids_registered; uint16 msgr_client_reg_type;//1 ->msgrq_sig type,2-> rexq_sig uint16 tech_mod_id;// union msg_sig_p{ //offset 0x10 struct msgrq_sig msgq_p;//msgr reg type 1,4G及往后利用的mailbox通报系统 struct rexq_sig rexq_p;//msgr reg type 2,兼容2G/3G时期利用的Rex IPC通报系统 } struct msgrq msgrq_p;//offset 0x14 ,if reg type 1 struct msgr_client_obj msgr_client_obj_ptr;//offset 0x30 } struct msgr_client_obj{//msgr_client构造体 unsigned int msgr_client_reg_type;//1-> msgrq aka mailbox,2->rex_q,接管的办法 unsigned int register_umid_counts;//offset 8 ,接管器注册的umid的总数 unsigned int total_reged_recv_signal_counts;//offset 0x0c,注册的接管的signal的个数 union sig_recv_obj{ msgrq_sig msgrq_signal_obj;// offset 0x10 msgrq_sig type,4/5G未来的主流类型 rexq_sig rex_signal_obj;//offset 0x10 rexq_sig type ,这个紧张是为了兼容之前2/3G的系统的数据构造 } unsigned int task_recv_signal_set_mask;//offset 0x14 ,注册的接管的signal号的掩码 uint32 err_counts;//offset 0x18 unsigned int recvd_signal_id;//offset 0x1c,当前接管到的signal id,msgr_client_reg_type为1 struct msgrq recvd_msgrq_ptr;//offset 0x20,当前接管承载的msgrq工具,msgr_client_reg_type为1 struct msgrq msgrq_first_entry;// offset 0x24,接管msgrq链表构造指针,msgr_client_reg_type为1 unsigned int total_msgrq_counts;//offset 0x28, 可以接管msgrq的总数,通过可以task_recv_signal_set_mask来确定,msgr_client_reg_type为1 } struct msgrq_sig{ uint32 sig_ready_flag;//must be 1 struct sig_def{ uint32 signal_id_for_recv;//offset 8 uint32 signal_reged_wait_mask;//offset 0xc void kernel_msg_queue; unsigned int attribute; }; } struct rexq_sig{ //size 0x1c, 兼容2/3G系统的数据构造 utcb msgr_client_utcb_ptr;//offset 0 任务接管利用的utcb标识 uint32 msgr_client_signal_id;//offset 4 接管利用的signal id msg_queue msgr_out_msg_q;//offset 0x8 msg_queue rex_msg_in_q;//offset 0xc uint16 msg_data_q_used_size;//offset 0x10 uint16 rexq_id;//offset 0x12 uint16 msg_data_q_size;//offset 0x14 } struct msg_data_q{ struct msg_data_q prev_q; struct msg_data_q next_q; char data[msg_data_q_size-8]; } struct msg_queue{ struct msg_data_q headp; struct msg_data_q tailp; uint32 total_q_counts; } struct msgrq{ void msg_recv_buf_header;//offset 0 void msg_recv_end_buf;//offset 4 char msgrq_name[16];//offset 0x10 int msgrq_recvd_seq;//ofset 0x18 unsigned int reged_recv_signal_id_mask;//offset 0x1c,可供接管signal的掩码 void msgr_buf_remain_ptr;//offset 0x20,可供接管的剩余空间起始地址 void msgr_recv_buf;//offset 0x24,当前接管到的buf地址 uint32 msgr_buf_remain_size;//offset 0x28 unsigned int total_msg_recv_buf_size;//offset 0x30 int8 is_buf_in_use;//offset 0x70 ,0-> in use, 1-> not in use uint32 recvd_msg_blocks;//offset 0x58 ,收到的次数总和 struct msgrq next_msgrq;//offset 0x74 }

为了更方便的理解上述的数据构造的关系与操作算法，画了一张大略的图来加深该系统的理解。
通过以上算法和数据构造，可以很方便的完成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进行查看。

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

struct sm_state_instance{ //eg ,size 0x1c struct sm_obj sm;//状态机工具定义 unsigned int current_state_id;//状态机当前所处的状态id unsigned int recvd_umid_in_sm_entity_seq;//offset 8, 状态机当前收到的umid所在状态机umid列表中的序列号 unsigned int instance_id;// 状态机实例编号 uint8 sm_state_lock;//offset 0x11 0->state unlock,1-> state lock 状态机锁的状态 void stm_idle_buf;//offset 0x14 状态机操作可能须要的buf空间 unsigned int debug_code;//offset 0x18 状态机调试码 } struct sm_obj{ //状态机的定义构造 struct msgr_stm_obj stm; unsigned char stm_obj_name; //状态机的名称，例如LTE_RRC_SIB_SM unsigned int stm_obj_name_hash; //状态机名称的hash值 unsigned int stm_inst_id;//stm instance id ，状态机的实例编号，状态机可能存在多个实例，通过这个编号来差异不同的状态机实体 } struct msgr_stm_obj { int instance_counts; //该状态机支持的实例个数 int state_cnts; //该状态机的状态数量 struct state_status_def state_def;//状态机每个不同状态的定义的数据构造,size state_cnts0x10 int umid_cnts;//状态机注册的可接管umid总数 struct umid_msg_list umid_msg_def;//存储umid和umid描述信息的指针,size umid_cnts8 struct umid_msg_states_func_cb_list umid_in_state_cb;//存储着所有umid对应每个状态的回调操作函数 void cb_func1;// stm enter //offset 0x18 ,进入该状态机的回调函数 void cb_func2;// stm exit //offset 0x1c ,退出该状态机的回调函数 void cb_func3;// stm error //offset 0x20 ,状态机出错的回调函数 void cb_func4; //stm debug //offset 0x24 ,状态机调试的回调函数 unsigned int init_state_id; // default 0 ,状态机初始默认状态id } struct umid_msg_states_func_cb_list {//状态机在接管到相应的umid后的原语操作回调函数 void umid_msg_in_states_1_cb_list[umid_cnts]; void umid_msg_in_states_2_cb_list[umid_cnts]; void umid_msg_in_states_3_cb_list[umid_cnts]; ... void umid_msg_in_states_state_cnts_cb_list[umid_cnts]; } struct state_status_def{//每个状态的定义 unsigned char state_name; //状态名称，eg,active/inactive etc void cb_func1; //state enter //状态机进入该状态的回调函数 void cb_func2; //state exit //状态机退出该状态的回调函数 void cb_func3; //state debug ?//可能是调试函数 } struct umid_msg_list{//状态机可接管的umid定义 unsigned char umid_msg_name; //umid对应的描述名称 unsigned int umid; //umid } 关键API描述 stm_instance_activate(struct sm_state_instance sm_st_inst,uint32 inst_id,uint32 initial_state_id);//初始化状态机实例 stm_instance_process_input(uint32 state_id,struct sm_state_instance sm_st_inst,uint32 sm_inst_id,uint32 umid_input,void stm_payload_ptr);//对状态机接管到的umid和数据进行原语操作

我从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_SMstate name: LTE_RRC_DT_SM //state name: LTE_RRC_IRAT_TO_G_MGR_SMstate name: LTE_RRC_LLC_SMstate name: LTE_RRC_CAPABILITIES_SMstate name: LTE_RRC_IRAT_FROM_1X_MGR_SMstate name: LTE_RRC_SEC_SM //sim认证和密钥协商管理干系的状态机state name: LTE_RRC_CRP_SMstate 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_SMstate name: LTE_RRC_MISC_SMstate name: LTE_RRC_MEAS_SMstate name: LTE_RRC_CEP_SMstate name: LTE_RRC_IRAT_TO_1X_MGR_SMstate name: LTE_RRC_IRAT_FROM_W_MGR_SMstate name: LTE_RRC_MDT_SMstate name: LTE_RRC_IRAT_TO_DO_MGR_SMstate name: LTE_RRC_CONTROLLER_SM //关键的LTE的掌握状态机，掌握做事的停滞和开启state name: LTE_RRC_IRAT_TO_TDS_MGR_SMstate name: LTE_RRC_IRAT_TO_W_MGR_SM //从LTE切换到WCDMA的管理状态机state name: LTE_RRC_EMP_SMstate name: LTE_RRC_MH_SMstate 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状态机定义作例子与之对应的数据构做作解析

LTE_RRC_PAGING_SM addr 0xd10b35e0 state machine name: LTE_RRC_PAGING_SM inst_cnts 1 total states 3 total umid 10 state name: INITIAL state enter 0xd0b923a8 state exit 0xd0b923c8 state debug 0x0 state name: IDLE_CAMPED state enter 0xd0b923e0 state exit 0xd0b92400 state debug 0x0 state name: CONNECTED state enter 0xd0b92418 state exit 0xd0b92450 state debug 0x0 0x040d140c LTE_RRC_CAMPED_INDI 0x040d0207 LTE_RRC_DRX_INFO_REQ 0x040d0206 LTE_RRC_SIM_UPDATE_REQ 0x040d0401 LTE_RRC_SERVICE_IND 0x040d0710 LTE_RRC_PAGING_DLM 0x040d1405 LTE_RRC_CONNECTED_INDI 0x040d022a LTE_RRC_MTC_CFG_REQ 0x040d1400 LTE_RRC_STOPPED_INDI 0x040d140b LTE_RRC_NOT_CAMPED_INDI 0x040d1402 LTE_RRC_SIB_UPDATED_INDI

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

状态机操作实例

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

发送端

接管端

接管UMID号

处理状态机

描述信息

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_CSP_SM

LTE_RRC_SERVICE_REQ

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_IRAT_FROM_W_MGR_SM

LTE_RRC_SERVICE_REQ

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_IRAT_FROM_G_MGR_SM

LTE_RRC_SERVICE_REQ

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_IRAT_FROM_TDS_MGR_SM

LTE_RRC_SERVICE_REQ

0x40d LTE_RRC

LTE_RRC

0x40d1442

LTE_RRC_MEAS_SM

LTE_RRC_CLEAR_DEPRI_FREQ_INDI

0x40d LTE_RRC

LTE_RRC

0x40d120d

LTE_RRC_CONTROLLER_SM

LTE_RRC_MODE_CHANGE_REQI

0x40f LTE_MAC

LTE_RRC

0x40f0803

LTE_RRC_CONTROLLER_SM

LTE_MAC_START_CNF

0x412 LTE_RLCUL

LTE_RRC

0x4120801

LTE_RRC_CONTROLLER_SM

LTE_RLCUL_START_CNF

0x411 LTE_RLCDL

LTE_RRC

0x4110801

LTE_RRC_CONTROLLER_SM

LTE_RLCDL_START_CNF

0x413 LTE_PDCPDL

LTE_RRC

0x4130806

LTE_RRC_CONTROLLER_SM

LTE_PDCPDL_START_CNF

0x414 LTE_PDCPUL

LTE_RRC

0x4140807

LTE_RRC_CONTROLLER_SM

LTE_PDCPUL_START_CNF

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0801

LTE_RRC_CONTROLLER_SM

LTE_CPHY_START_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1513

LTE_RRC_CSP_SM

LTE_RRC_MODE_CHANGE_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0809

LTE_RRC_CSP_SM

LTE_CPHY_SYSTEM_SCAN_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0800

LTE_RRC_CSP_SM

LTE_CPHY_ACQ_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1202

LTE_RRC_SIB_SM

LTE_RRC_GET_SIBS_REQI

0x403 LTE_ML1_DLM

LTE_RRC

0x40c0402

LTE_RRC_SIB_SM

LTE_CPHY_MIB_IND

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

BCCH DL SCH SIB1

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0823

LTE_RRC_SIB_SM

LTE_CPHY_TDD_CFG_CNF

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

BCCH DL SCH SI

0x40d LTE_RRC

LTE_RRC

0x40d1514

LTE_RRC_CSP_SM

LTE_RRC_GET_SIBS_CNFI

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

BCCH DL SCH SIB1

0x40c LTE_ML1_MGR

LTE_RRC

0x40c080a

LTE_RRC_CSP_SM

LTE_CPHY_CELL_SELECT_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0804

LTE_RRC_LLC_SM

LTE_CPHY_COMMON_CFG_CNF

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0805

LTE_RRC_LLC_SM

LTE_CPHY_DEDICATED_CFG_CNF

0x40f LTE_MAC

LTE_RRC

0x40f0801

LTE_RRC_LLC_SM

LTE_MAC_CFG_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1516

LTE_RRC_CSP_SM

LTE_RRC_CFG_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_SIB_SM

LTE_RRC_CAMPED_INDI

inactive

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_SIB_SM

LTE_RRC_CAMPED_INDI

active

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_MEAS_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_CAPABILITIES_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_CEP_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_MISC_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1516

LTE_RRC_CONTROLLER_SM

LTE_RRC_CFG_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_CSP_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_CEP_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_PAGING_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_MEAS_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_CSG_ASF_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_IRAT_TO_G_MGR_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_IRAT_TO_TDS_MGR_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40D0401

LTE_RRC_CSG_ASF_SM

LTE_RRC_SERVICE_IND

0x40d LTE_RRC

LTE_RRC

0x40D0401

LTE_RRC_PAGING_SM

LTE_RRC_SERVICE_IND

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0815

LTE_RRC_MEAS_SM

LTE_CPHY_IDLE_MEAS_CFG_CNF

0x40d LTE_RRC

LTE_RRC

0x40d0225

LTE_RRC_CSP_SM

LTE_RRC_AVOIDANCE_REQ

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

SI

0x40d LTE_RRC

LTE_RRC

0x40d1437

LTE_RRC_CSP_SM

LTE_RRC_INTERFREQ_LIST_UPDATE_INDI

0xf19 EMM

LTE_RRC

0x40d0200

LTE_RRC_CEP_SM

LTE_RRC_CONN_EST_REQ

Attach Request NAS msg

0x40d LTE_RRC

LTE_RRC

0x40D1404

LTE_RRC_CONTROLLER_SM

LTE_RRC_CONN_ESTABLISHMENT_STARTED_INDI

RRC Connection Request

0x40d LTE_RRC

LTE_RRC

0x40D143d

LTE_RRC_CONTROLLER_SM

LTE_RRC_TRM_PRIORITY_CHANGE_INDI

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_CONTROLLER_SM

LTE_RRC_SIM_UPDATE_REQ

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_PAGING_SM

LTE_RRC_SIM_UPDATE_REQ

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_SEC_SM

LTE_RRC_SIM_UPDATE_REQ

SIM Update Req received from NAS

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_CAPABILITIES_SM

LTE_RRC_SIM_UPDATE_REQ

0x404 LTE_ML1_ULM

LTE_RRC

0x40c0421

LTE_RRC_CEP_SM

LTE_CPHY_RACH_MSG1_SCHED_IND

LTE MAC RACH Attempt

0x40f LTE_MAC

LTE_RRC

0x40f0800

LTE_RRC_CEP_SM

LTE_MAC_ACCESS_CNF

0x40f LTE_MAC

LTE_RRC

0x40f0405

LTE_RRC_MH_SM

LTE_MAC_RRC_CCCH_DL_DATA_IND

CCCH RRC Connection Setup

0x40d LTE_RRC

LTE_RRC

0x40d0703

LTE_RRC_CEP_SM

LTE_RRC_RRC_CONNECTION_SETUP_DLM

CCCH RRC Connection Setup

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40d LTE_RRC

LTE_RRC

0x40D1408

LTE_RRC_CSP_SM

LTE_RRC_PROCEED_WITH_RESEL_INDI

0x411 LTE_RLCDL

LTE_RRC

0x4110800

LTE_RRC_LLC_SM

LTE_RLCDL_CFG_CNF

0x412 LTE_RLCUL

LTE_RRC

0x4120800

LTE_RRC_LLC_SM

LTE_RLCUL_CFG_CNF

0x413 LTE_PDCPDL

LTE_RRC

0x4130800

LTE_RRC_LLC_SM

LTE_PDCPDL_CFG_CNF

0x414 LTE_PDCPUL

LTE_RRC

0x4140800

LTE_RRC_LLC_SM

LTE_PDCPUL_CFG_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1516

LTE_RRC_CEP_SM

LTE_RRC_CFG_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d1200

LTE_RRC_MH_SM

LTE_RRC_SEND_UL_MSG_REQI

0x40d LTE_RRC

LTE_RRC

0x40d1405

LTE_RRC_SIB_SM

LTE_RRC_CONNECTED_INDI

0x414 LTE_PDCPUL

LTE_RRC

0x4140802

LTE_RRC_MH_SM

LTE_PDCPUL_SDU_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1504

LTE_RRC_CEP_SM

LTE_RRC_RRC_CONNECTION_SETUP_COMPLETE_CNFI

UL_DCCH RRC connection Setup Complete

0x413 LTE_PDCPDL

LTE_RRC

0x4130400

LTE_RRC_MH_SM

LTE_PDCPDL_SDU_IND

DL_DCCH info Transfer

0x40d LTE_RRC

LTE_RRC

0x40d0705

LTE_RRC_DT_SM

LTE_RRC_DL_INFORMATION_TRANSFER_DLM

DL_DCCH Auth Request Msg recvd

0x40d LTE_RRC

LTE_RRC

0x40d141f

LTE_RRC_MH_SM

LTE_RRC_DLM_PROCESSED_INDI

0xF19 EMM

LTE_RRC

0x40d0201

LTE_RRC_DT_SM

LTE_RRC_UL_DATA_REQ

send Auth Resp data

0x40d LTE_RRC

LTE_RRC

0x40d1200

LTE_RRC_MH_SM

LTE_RRC_SEND_UL_MSG_REQI

UL_DCCH ULinfo Transfer send NAS Auth resp

0x414 LTE_PDCPUL

LTE_RRC

0x4140802

LTE_RRC_MH_SM

LTE_PDCPUL_SDU_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1509

LTE_RRC_DT_SM

LTE_RRC_UL_INFORMATION_TRANSFER_CNFI

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安全测试体系，通过对基带系统的深刻认知，可以更好的对基站系统和核心网系统进行安全评估。

末了，附上5G安全威胁硬件检测工具原型图。
只要搭载通信运营商供应给普通用户的5G sim卡，插入电脑，就可完成对附近通信安全威胁的检测，该工具也可改造成通过电池供电的独立检测、便携式设备。

本文作者：阿里安全