freeBuf
主站

分類

漏洞 工具 極客 Web安全 系統安全 網絡安全 無線安全 設備/客戶端安全 數據安全 安全管理 企業安全 工控安全

特色

頭條 人物志 活動 視頻 觀點 招聘 報告 資訊 區塊鏈安全 標準與合規 容器安全 公開課

官方公眾號企業安全新浪微博

FreeBuf.COM網絡安全行業門戶,每日發布專業的安全資訊、技術剖析。

FreeBuf+小程序

FreeBuf+小程序

深度揭秘高通移動基帶 我造出了最便宜的5G安全檢測工具
2021-04-09 15:20:21

HW期間,為防范釣魚,即日起FreeBuf將取消投稿文章的一切外部鏈接。給您帶來的不便,敬請諒解~

一夜醒來,黑灰產通過wei基站進行短信嗅探讓用戶電子賬戶的錢不翼而飛。在2G、3G、4G時代,都出現過wei基站等通信安全威脅,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)

長生命周期線程

阻塞型消息接受線程

image-20210308164203970

消息通信底層API封裝簡介:

//信號發送
int rex_send_sigs(utcb *dst_task_obj,unsigned int signal_id);
//第一個參數為向目標任務發送消息的結構定義,第二個參數為要發送的信號id
int 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的值與相應的命名規則如下。

UMID由32位組成,結構如下表

Nameoffset and lengthComment
tech_id24~31 8bitseg, LTE->0x04, IMS->0x15, MDM9607 0x1b, SDX55 0x20
mod_id16~23 8bitseg, 0xd -> RRC 0xf -> MAC 0x11-> RLC DL
type_id8~15? 8bitstype <= 0x09) || (type >= 0x11 && type <= 0x17,totally 0x11 type_ids
op_type_id4~8??? 4bitsOp entity ,eg IRAT_FROM_LTE_TO_G
op_id0~3??? 4bitsOpcode 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_namevalueComment
CMD1Command primitive
REQ2request
RSP3response
IND4indication
DLM7downlink message
CNF8confirm
TMR9timer
REQI0x12request Internal
RSPI0x13Response internal
INDI0x14indication internal
CNFI0x15confirm internal
TMRI0x16timer internal

舉個例子UMID 0x40D120E 對應的描述原語是LTE_RRC_IRAT_FROM_LTE_TO_G_RESEL_REQI,拆分結果如下:

namevalue
LTE0x04
RRC0x0d
REQI0x12
RESEL0x0
IRAT_FROM_LTE_TO_G0x0e

注:這種UMID值的解析方法在某些定義里面并不適用,比如LTE_ML1_DLM_TST_SKIP_RACH_REQ的值為6,就沒法用上面的方法解析,有些值并不嚴格遵循這種解析算法,可能是由于歷史原因,定義UMID值的規則不一樣。

基帶系統把任務標示為多個不同的技術大類,來標示和模塊化相應的子功能,以MDM9607為例:

tech_idTech_name
0MCS(Modem Common Service)
2MM_CM(0x201) UI(0x20a) (Unnumbered Information) MM_DOM(0x202),MM_MMOC(0x251)
4LTE
5FTM
6rfa_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)
7cdma
8hdr
9gsm
0x0alocation(gps/gnss)
0x0bwcdma
0x0cds(data service)
0x0d1x(csfb)
0x0fnas(0xf19 mm, 0xf1c esm)
0x10gstk(Generic SIM Application Toolkit)
0x12tdscdma
0x13wms
0x15ims
0x16qmi
0x17ecall? 0x1701 ecall_app ,0x1702 ecall_ivs
0x18policyman
0x1arflm

模塊ID

下圖是MDM9607 LTE的部分子模塊ID的對應關系

tech_id+mod_idname
0x401ML1 MGR
0x407LL1_SRCH
0x408LL1_DL
0x409LL1_UL
0x40aLL1_SYS
0x40bLL1_Async
0x40dRRC
0x40fMAC
0x411RLC DL
0x412RLC UL
0x413PDCP DL
0x414PDCP UL
0x41bML1_GM
0x41eSW.app
0x420ML1_GM_SCHDLR
0x427TLB(Test Loop )
0x42bML1_GM_Sleep
0x434ML1_AFC
0x43bPDCP offload
0x43eML1 offload
0x43fML1 Co-existence
0x441ML1 GM MSMGR
0x442PDCPCOMP
0x445ML1 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 ,頭部結尾標志0x7f
				uint8    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的消息路由

消息路由

我們已經了解到UMID所對應原語操作的含義,如果需要執行相應的原語操作,只需要向注冊過UMID的模塊發送umid消息即可,接下來我們需要了解umid消息是如何路由到相應模塊(tech_mod_id)的消息接收器(msgr_client)的,下面會詳細介紹相應的算法和數據結構,我整理了幾張表來描述。

map_namemap_sizekeyvaluevalue_sizeMemory Attribution
techs_maptechs * 8tech_idmodule_counts, modules_map8 bytesRead Only
modules_mapmodule_counts * 0x11 * 2(mod_id * 0x11+type_id) * 2types_map_id2 bytesRead Only
types_maptypes_map_ids * 0x20types_map_id * 0x20 +(op_type_id&0x1e)tech_mod_type_seq2 bytesRead/Write
umids_mapumid_seq_id * 0x88 * (tech_mod_type_seq+op_id)umid, next_umid_seq_id,msgr_client_id8 bytesRead/Write
msgr_clients_map0x34*total_msgr_client_countsmsgr_client_seq_idmsgr_client_desc0x34Read/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的消息路由的注冊,消息發送等操作。

image-20210322162235900

需要說明的一點就是一個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系統上使用的第二代狀態機消息系統,老的第一代狀態機系統不在這里介紹了。

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_cnts*0x10 int umid_cnts;//狀態機注冊的可接受umid總數 struct umid_msg_list *umid_msg_def;//存儲umid和umid描述信息的指針,size umid_cnts*8 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_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狀態機定義作例子與之對應的數據結構作解析

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 emmLTE_RRC0x40d0204LTE_RRC_CSP_SMLTE_RRC_SERVICE_REQ
0xF19 emmLTE_RRC0x40d0204LTE_RRC_IRAT_FROM_W_MGR_SMLTE_RRC_SERVICE_REQ
0xF19 emmLTE_RRC0x40d0204LTE_RRC_IRAT_FROM_G_MGR_SMLTE_RRC_SERVICE_REQ
0xF19 emmLTE_RRC0x40d0204LTE_RRC_IRAT_FROM_TDS_MGR_SMLTE_RRC_SERVICE_REQ
0x40d LTE_RRCLTE_RRC0x40d1442LTE_RRC_MEAS_SMLTE_RRC_CLEAR_DEPRI_FREQ_INDI
0x40d LTE_RRCLTE_RRC0x40d120dLTE_RRC_CONTROLLER_SMLTE_RRC_MODE_CHANGE_REQI
0x40f LTE_MACLTE_RRC0x40f0803LTE_RRC_CONTROLLER_SMLTE_MAC_START_CNF
0x412 LTE_RLCULLTE_RRC0x4120801LTE_RRC_CONTROLLER_SMLTE_RLCUL_START_CNF
0x411 LTE_RLCDLLTE_RRC0x4110801LTE_RRC_CONTROLLER_SMLTE_RLCDL_START_CNF
0x413 LTE_PDCPDLLTE_RRC0x4130806LTE_RRC_CONTROLLER_SMLTE_PDCPDL_START_CNF
0x414 LTE_PDCPULLTE_RRC0x4140807LTE_RRC_CONTROLLER_SMLTE_PDCPUL_START_CNF
0x40c LTE_ML1_MGRLTE_RRC0x40c0801LTE_RRC_CONTROLLER_SMLTE_CPHY_START_CNF
0x40d LTE_RRCLTE_RRC0x40d1513LTE_RRC_CSP_SMLTE_RRC_MODE_CHANGE_CNFI
0x40d LTE_RRCLTE_RRC0x40d1206LTE_RRC_LLC_SMLTE_RRC_CFG_REQI
0x40c LTE_ML1_MGRLTE_RRC0x40c0809LTE_RRC_CSP_SMLTE_CPHY_SYSTEM_SCAN_CNF
0x40d LTE_RRCLTE_RRC0x40d1206LTE_RRC_LLC_SMLTE_RRC_CFG_REQI
0x40c LTE_ML1_MGRLTE_RRC0x40c0800LTE_RRC_CSP_SMLTE_CPHY_ACQ_CNF
0x40d LTE_RRCLTE_RRC0x40d1202LTE_RRC_SIB_SMLTE_RRC_GET_SIBS_REQI
0x403 LTE_ML1_DLMLTE_RRC0x40c0402LTE_RRC_SIB_SMLTE_CPHY_MIB_IND
0x40F LTE_MACLTE_RRC0x40f0406LTE_RRC_SIB_SMLTE_MAC_RRC_BCCH_DL_DATA_INDBCCH DL SCH SIB1
0x40c LTE_ML1_MGRLTE_RRC0x40c0823LTE_RRC_SIB_SMLTE_CPHY_TDD_CFG_CNF
0x40F LTE_MACLTE_RRC0x40f0406LTE_RRC_SIB_SMLTE_MAC_RRC_BCCH_DL_DATA_INDBCCH DL SCH SI
0x40d LTE_RRCLTE_RRC0x40d1514LTE_RRC_CSP_SMLTE_RRC_GET_SIBS_CNFI
0x40F LTE_MACLTE_RRC0x40f0406LTE_RRC_SIB_SMLTE_MAC_RRC_BCCH_DL_DATA_INDBCCH DL SCH SIB1
0x40c LTE_ML1_MGRLTE_RRC0x40c080aLTE_RRC_CSP_SMLTE_CPHY_CELL_SELECT_CNF
0x40d LTE_RRCLTE_RRC0x40d1206LTE_RRC_LLC_SMLTE_RRC_CFG_REQI
0x40c LTE_ML1_MGRLTE_RRC0x40c0804LTE_RRC_LLC_SMLTE_CPHY_COMMON_CFG_CNF
0x40c LTE_ML1_MGRLTE_RRC0x40c0805LTE_RRC_LLC_SMLTE_CPHY_DEDICATED_CFG_CNF
0x40f LTE_MACLTE_RRC0x40f0801LTE_RRC_LLC_SMLTE_MAC_CFG_CNF
0x40d LTE_RRCLTE_RRC0x40d1516LTE_RRC_CSP_SMLTE_RRC_CFG_CNFI
0x40d LTE_RRCLTE_RRC0x40d140cLTE_RRC_SIB_SMLTE_RRC_CAMPED_INDIinactive
0x40d LTE_RRCLTE_RRC0x40d140cLTE_RRC_SIB_SMLTE_RRC_CAMPED_INDIactive
0x40d LTE_RRCLTE_RRC0x40d140cLTE_RRC_MEAS_SMLTE_RRC_CAMPED_INDI
0x40d LTE_RRCLTE_RRC0x40d140cLTE_RRC_CAPABILITIES_SMLTE_RRC_CAMPED_INDI
0x40d LTE_RRCLTE_RRC0x40d140cLTE_RRC_CEP_SMLTE_RRC_CAMPED_INDI
0x40d LTE_RRCLTE_RRC0x40d140cLTE_RRC_MISC_SMLTE_RRC_CAMPED_INDI
0x40d LTE_RRCLTE_RRC0x40d1516LTE_RRC_CONTROLLER_SMLTE_RRC_CFG_CNFI
0x40d LTE_RRCLTE_RRC0x40d1402LTE_RRC_CSP_SMLTE_RRC_SIB_UPDATED_INDI
0x40d LTE_RRCLTE_RRC0x40d1402LTE_RRC_CEP_SMLTE_RRC_SIB_UPDATED_INDI
0x40d LTE_RRCLTE_RRC0x40d1402LTE_RRC_PAGING_SMLTE_RRC_SIB_UPDATED_INDI
0x40d LTE_RRCLTE_RRC0x40d1402LTE_RRC_MEAS_SMLTE_RRC_SIB_UPDATED_INDI
0x40d LTE_RRCLTE_RRC0x40d1402LTE_RRC_CSG_ASF_SMLTE_RRC_SIB_UPDATED_INDI
0x40d LTE_RRCLTE_RRC0x40d1402LTE_RRC_IRAT_TO_G_MGR_SMLTE_RRC_SIB_UPDATED_INDI
0x40d LTE_RRCLTE_RRC0x40d1402LTE_RRC_IRAT_TO_TDS_MGR_SMLTE_RRC_SIB_UPDATED_INDI
0x40d LTE_RRCLTE_RRC0x40D0401LTE_RRC_CSG_ASF_SMLTE_RRC_SERVICE_IND
0x40d LTE_RRCLTE_RRC0x40D0401LTE_RRC_PAGING_SMLTE_RRC_SERVICE_IND
0x40c LTE_ML1_MGRLTE_RRC0x40c0815LTE_RRC_MEAS_SMLTE_CPHY_IDLE_MEAS_CFG_CNF
0x40d LTE_RRCLTE_RRC0x40d0225LTE_RRC_CSP_SMLTE_RRC_AVOIDANCE_REQ
0x40F LTE_MACLTE_RRC0x40f0406LTE_RRC_SIB_SMLTE_MAC_RRC_BCCH_DL_DATA_INDSI
0x40d LTE_RRCLTE_RRC0x40d1437LTE_RRC_CSP_SMLTE_RRC_INTERFREQ_LIST_UPDATE_INDI
0xf19 EMMLTE_RRC0x40d0200LTE_RRC_CEP_SMLTE_RRC_CONN_EST_REQAttach Request NAS msg
0x40d LTE_RRCLTE_RRC0x40D1404LTE_RRC_CONTROLLER_SMLTE_RRC_CONN_ESTABLISHMENT_STARTED_INDIRRC Connection Request
0x40d LTE_RRCLTE_RRC0x40D143dLTE_RRC_CONTROLLER_SMLTE_RRC_TRM_PRIORITY_CHANGE_INDI
0xF19 EMMLTE_RRC0x40d0206LTE_RRC_CONTROLLER_SMLTE_RRC_SIM_UPDATE_REQ
0xF19 EMMLTE_RRC0x40d0206LTE_RRC_PAGING_SMLTE_RRC_SIM_UPDATE_REQ
0xF19 EMMLTE_RRC0x40d0206LTE_RRC_SEC_SMLTE_RRC_SIM_UPDATE_REQSIM Update Req received from NAS
0xF19 EMMLTE_RRC0x40d0206LTE_RRC_CAPABILITIES_SMLTE_RRC_SIM_UPDATE_REQ
0x404 LTE_ML1_ULMLTE_RRC0x40c0421LTE_RRC_CEP_SMLTE_CPHY_RACH_MSG1_SCHED_INDLTE MAC RACH Attempt
0x40f LTE_MACLTE_RRC0x40f0800LTE_RRC_CEP_SMLTE_MAC_ACCESS_CNF
0x40f LTE_MACLTE_RRC0x40f0405LTE_RRC_MH_SMLTE_MAC_RRC_CCCH_DL_DATA_INDCCCH RRC Connection Setup
0x40d LTE_RRCLTE_RRC0x40d0703LTE_RRC_CEP_SMLTE_RRC_RRC_CONNECTION_SETUP_DLMCCCH RRC Connection Setup
0x40d LTE_RRCLTE_RRC0x40d1206LTE_RRC_LLC_SMLTE_RRC_CFG_REQI
0x40d LTE_RRCLTE_RRC0x40D1408LTE_RRC_CSP_SMLTE_RRC_PROCEED_WITH_RESEL_INDI
0x411 LTE_RLCDLLTE_RRC0x4110800LTE_RRC_LLC_SMLTE_RLCDL_CFG_CNF
0x412 LTE_RLCULLTE_RRC0x4120800LTE_RRC_LLC_SMLTE_RLCUL_CFG_CNF
0x413 LTE_PDCPDLLTE_RRC0x4130800LTE_RRC_LLC_SMLTE_PDCPDL_CFG_CNF
0x414 LTE_PDCPULLTE_RRC0x4140800LTE_RRC_LLC_SMLTE_PDCPUL_CFG_CNF
0x40d LTE_RRCLTE_RRC0x40d1516LTE_RRC_CEP_SMLTE_RRC_CFG_CNFI
0x40d LTE_RRCLTE_RRC0x40d1200LTE_RRC_MH_SMLTE_RRC_SEND_UL_MSG_REQI
0x40d LTE_RRCLTE_RRC0x40d1405LTE_RRC_SIB_SMLTE_RRC_CONNECTED_INDI






0x414 LTE_PDCPULLTE_RRC0x4140802LTE_RRC_MH_SMLTE_PDCPUL_SDU_CNF
0x40d LTE_RRCLTE_RRC0x40d1504LTE_RRC_CEP_SMLTE_RRC_RRC_CONNECTION_SETUP_COMPLETE_CNFIUL_DCCH RRC connection Setup Complete
0x413 LTE_PDCPDLLTE_RRC0x4130400LTE_RRC_MH_SMLTE_PDCPDL_SDU_INDDL_DCCH info Transfer
0x40d LTE_RRCLTE_RRC0x40d0705LTE_RRC_DT_SMLTE_RRC_DL_INFORMATION_TRANSFER_DLMDL_DCCH Auth Request Msg recvd
0x40d LTE_RRCLTE_RRC0x40d141fLTE_RRC_MH_SMLTE_RRC_DLM_PROCESSED_INDI
0xF19 EMMLTE_RRC0x40d0201LTE_RRC_DT_SMLTE_RRC_UL_DATA_REQsend Auth Resp data
0x40d LTE_RRCLTE_RRC0x40d1200LTE_RRC_MH_SMLTE_RRC_SEND_UL_MSG_REQIUL_DCCH ULinfo Transfer send NAS Auth resp
0x414 LTE_PDCPULLTE_RRC0x4140802LTE_RRC_MH_SMLTE_PDCPUL_SDU_CNF
0x40d LTE_RRCLTE_RRC0x40d1509LTE_RRC_DT_SMLTE_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卡,插入電腦,就可完成對附近通信安全威脅的檢測,該工具也可改造成通過電池供電的獨立檢測、便攜式設備。

本文作者:, 轉載請注明來自FreeBuf.COM

# 基帶
被以下專輯收錄,發現更多精彩內容
+ 收入我的專輯
評論 按熱度排序

登錄/注冊后在FreeBuf發布內容哦

相關推薦
  • 0 文章數
  • 0 評論數
  • 0 關注者
文章目錄
登錄 / 注冊后在FreeBuf發布內容哦
收入專輯
四月天小说网