基于Binder的Android支付信息安全的研究

劉子煜 吳健學

摘要：隨著移動互聯網的發展，Android手機平臺內越來越多的APP具有移動支付功能。移動支付涉及到金融交易，支付信息安全顯得尤為重要。本文分析了Android的Binder機制，通過將監控代碼動態注入目標模塊，對進程間的通信數據進行提取，通過比對既有信息，分析是否有惡意軟件竊取目標APP的用戶隱私信息。在支付環節之前將檢測結果對用戶給予提示，且對支付過程無較大影響，一定程度上保障了用戶支付信息的安全。

關鍵詞：Android系統;Binder;動態注入;信息提取

中圖分類號：TN918.9

文獻標志碼：A

1 引 言

基于Android系統龐大的使用人群，各應用公司開發了各式各樣的APP為人們的生活提供了便利。但隨著Android應用數量的急劇上升，應用質量參差不齊，惡意軟件嚴重威脅著終端用戶的財產和隱私安全，也制約著移動終端應用的進一步發展[1][2]。根據360互聯網安全中心發布的《2016年安卓惡意軟件專題報告》，2016年全年，Android平臺新增惡意程序樣本1403.3萬個，平均每天新增3.8萬惡意程序樣本。

隨著手機支付功能的普遍化，惡意代碼藏匿于普通應用程序盜取用戶賬戶信息和密碼的現象時有發生，惡意程序威脅著正常的支付功能，泄露了用戶的敏感信息，對用戶直接或間接造成經濟損失[3]。手機支付越來越受到人們重視，使用的場景越來越多，但手機安全卻阻礙其突破性發展。

目前應用市場上存在手機管家，手機安全衛士等安全應用來管理和保護用戶的手機，但安裝這些安全應用會對手機產生一定的額外開銷，且針對特定APP中的敏感信息無法做到精準的保護[4]。本文針對這一現象，為Android系統中涉及支付功能的應用提出一種支付信息的保護方式，通過比對進程間的通信數據，找到獲取隱私信息的惡意APP，提醒用戶進行處理，以此保障用戶的信息安全。

2 Binder通信機制

Android系統是由谷歌公司基于Linux內核開發的智能操作系統，在Linux系統中，進程間的通信機制有很多種，包括pipe（管道）通信，socket（套接字）通信，signal（信號）通信這些傳統IPC（Inter Process Communication進程間通信）。Android為每個APP分配了一個區分進程身份的屬性-UID，傳統的IPC只能由用戶在數據包里填入UID/PID[5-6]，但這樣容易被惡意程序所利用。由IPC機制在內核中添加的屬性才是最可靠的。Binder的出現滿足了Android對通信方式，傳輸性能和安全性的要求，與其他進程間通信方式相比，Binder通信機制更安全、簡潔、高效、快速，消耗的內存資源更少。

Binder通信是Android系統的基礎通信機制，轉發應用之間的通信信息。Binder在完成本身轉發信息的功能之外，在底層拷貝應用之間的通信信息，用戶在使用手機過程中并不會察覺到。Binder在Android的各個版本中很少變動，因此基于Binder機制的方案便于移植到Android的各版本，具有很好的兼容性，可實現更多種類Android移動終端的覆蓋。[7]

圖1表示了Binder基于Client-Server的通信模式，傳輸過程只需一次拷貝，為發送方添加UID/PID身份，既支持實名Binder也支持匿名Binder，安全性高。Binder的CS架構由四大部分組成，分別是服務端、客戶端、服務管理器和內核空間里的Binder驅動[8]。

服務端Server提供服務，一個或多個Client客戶端向服務發起請求，通信過程由Binder接口實現，數據的交互與處理在Binder驅動中完成。服務需在服務管理器Service Manager中進行注冊，Service Manager是Android系統中的守護進程，負責監聽客戶端的請求。

3 系統設計與實現

3.1 整體設計方案

本方案設計的支付信息保護模塊依托于APP的支付功能，整體流程如圖2所示。

當用戶生成訂單信息時，支付信息保護模塊同時開始工作，從生成敏感信息時開始監控信息的流向。當用戶發起支付時，客戶端首先調用APP后臺服務器接口，APP向后臺接口傳入等待付款的訂單號，支付方式及一系列業務相關的參數，服務器收到請求后返回JSON格式數據。若請求成功，JSON數據里包括服務器根據訂單號查詢到的商品信息，交易的標題，訂單金額等等。客戶端收到成功的指令后，根據用戶選擇的支付方式準備調用相應的第三方支付平臺的接口。根據支付平臺的要求，需要傳入JSON格式數據里的敏感信息。

在敏感信息的流動過程中，支付信息保護模塊同步檢測敏感信息是否被其他惡意應用竊取，支付環境是否安全，將檢測結果在頁面予以顯示，告知用戶。支付信息保護模塊同步覆蓋支付的整個流程。

3.2 代碼注入

代碼注入是Linux系統提供的Ptrace系統調用，在目標內存空間進行hook操作。Android的動態鏈接器為Linker[9]，可以實現ELF格式鏈接庫的加載與鏈接。Ptrace使用PTRACE—ATTACH模式跟蹤正在運行的進程，使其變為可控子進程[10]。具體過程如下：

（1）調用Ptrace的PTRACE_ATTACH模式關聯到目標進程;

（2）獲取目標進程的子進程、內存及寄存器信息并保存;

（3）裝載指定的共享庫，將代碼寫入到目標進程上完成加載;

（4）將函數重定向，使用新函數。主要修改PLT表和GOT表;

（5）調用Ptrace的PTRACE_DETACH脫離目標進程。

當客戶端生成訂單信息時，系統同時調用支付信息保護模塊，首先將監控代碼注入到對應模塊。當目標進程被動態注入后，執行ioctl函數（i/o通道控制函數）時會跳到共享庫中對應的重定向函數hooked_ioctl位置上執行。利用欄截到的ioctl函數返回的數據對進程間通信的數據進行解析，從而提取出應用程序在運行時刻的行為參數，可以進行提前預判和管理。ioctl函數的調用方式為intioctl（int fd， int cmd， struct binder___ write_read*bwr），第一個參數是文件描述符;cmd是用戶程序對設備的控制命令，一般分為GET（從內核讀數據）、SET（向內核寫數據）等命令;第三個參數為類型為binder_write_read結構的數據流指針。

由Binder通信機制，應用程序使用服務時會優先同Service Manager進程通信來獲取相應服務信息。Service Manager的Binder進程間通信數據流采用結構體binder_transaction_data表示，保存在結構體binder_write_read中的write_buffer和read_buffer所指向的字節緩沖區域。在應用同Service Manager進行交互時，Service Manager用read_buffer記錄應用的IPC數據。所以接下來要通過結構體binder_transaction_data來解析read_buffer中指向的緩沖區域的數據。

3.3 數據提取與比較

binder—transaction__ data包含成員變量target，target是一個聯合體，表示一個目標Binder對象，Binder驅動根據其中的handle找到應該由哪個進程處理該事件;code是一個命令，它描述了Binder對象執行的操作，當應用程序需要ServiceManager來查詢相應的服務時，code為GET—SERVICE—TRANSACTION; sender _pid和sender euid為發起請求進程的PID和UID，用于識別應用的身份;data是一個聯合體，存放數據，data_size表示數據的大小，其結構體ptr中的buffer保存通信數據。下面的偽代碼用于提取buffer中的數據。

//定義數據包保存提取的數據

typedef struct Packet{

pid__t sender__ pid;

uid_t sender_euid;

charservice_name;

）packet;

char*ptr;

//遍歷read_buffer緩沖區存放進一個移動指針

for（i=O;1< READ_BUFFER_SIZE;i++）{

ptr = read buffer＼[i＼];

//當與協議值相同時移動4字節

if（isMatch（*ptr， BR_TRANSACTION））{

ptr - ptr+1;

//當應用程序請求服務的對象是ServiceManager時移動4字節

if（target.handle一一O）{

ptr - ptr+1;

//當參數滿足要求時移動4字節

if（isMatch（*ptr，"android.os.IServiceMarrager"）&&code一一GET_SERVICE_TRANS-ACTION）f

ptr=ptr+1;

//若為有效字符串，更新packet成員

if（isValid（*ptr））{

update（ packet）;）

）

）

）

）

解析完參數信息后，創建一個子線程將數據通過UNIX套接字的方式傳入上層。首先填寫地址創建socket，socket監聽是否有連接，packet更新后被發送到socket接收端。

將數據傳到客戶端應用層，編碼循環遍歷敏感數據。檢測提取的通信數據是否包含敏感支付信息。本次實驗的敏感數據包括手機號，手機MAC地址，IMEI號，支付接口傳輸的用戶名，訂單號，支付賬號等等。

4 應用測試

在Ubuntu操作系統中安裝配置Android集成開發工具Android Studio，在工具中新建一個購物應用，然后按照第三方支付平臺的要求集成APP支付功能。此時通過開發工具打包生成不含支付信息保護模塊的基本應用TEST BASE.apk。

在基本應用的基礎上，動態注入由監控代碼生成的庫文件，再次打包生成含支付信息保護模塊TEST_BONUS.apk。

測試時將Android模擬器和兩部手機作為測試平臺。

在測試平臺上安裝TEST_BONUS.apk，作為待測試APP，同時安裝三個有已知惡意行為的APP和三個健康的APP。在測試APP中模擬購物，生成訂單，發起支付。支付信息保護模塊對用戶的提示信息如圖3所示。

綜合測試結果如表1所示，“√”表示在十輪模擬支付環節中，支付信息保護模塊成功檢測出對應的惡意程序。

同時為了測試敏感信息提取和比對過程對用戶的影響，我們在相同的環境分別安裝TEST—BASE.apk和TEST _BONUS. apk做對比實驗。表1中額外耗時即為加入支付保障模塊后，信息的提取與檢測對用戶操作的平均影響時間。

5 結 論

針對Android手機支付時容易被盜取個人信息的情況，對Android的Binder機制進行研究，實現了一個Android進程間通信數據提取分析的方法。通過對目標進程注入代碼，分析提取應用程序間通信的數據，對數據進行分析匹配，當敏感數據有泄露的危險時，給予用戶提示，保障支付信息安全。此信息保護模塊內置于APP中，對特定的支付信息予以保護。相比額外安裝手機管家更便捷。實驗結果表示，該方案在一定程度上保證了用戶支付信息的安全，對支付過程無較大影響，有很強的應用前景。

參考文獻

[1] JIMENEZ L M，OCHOA M，RUEDA S J.Jif-based Verifica-tion of Information Flow Policies for Android Apps [J].International Journal of Secure Software Engineering （IJSSE），2017，8（1）：28-42.

[2] 吳丹，惡意程序威脅互聯網安全手機“植毒”已現利益鏈[Nl.信息通報，2017-04-26（B06）.

[3] GU J， XU Y，XU H， et al.Privacy concerns for mobile appdownload： An elaboration likelihood model perspective[Jl.Decision Support Systems， 2016，94：19-28.

[4]焦丹丹，張曉東，李大尉，等，基于安卓的手機安全衛士[J].黑龍江科學，2016，7（14）：4-5.

[5]張俊浩.Android智能支付終端安全機制的研究與實現[D].南京：東南大學，2015.

[6]張晶，針對Android的惡意代碼檢測方案設計與實現[D].貴陽：貴州大學，2016.

[7] 曾寰.Android平臺的惡意程序檢測研究[D].成都：電子科技大學，2016.

[8]甄鑫，基于Binder的Android用戶隱私數據安全增強技術實現[D].南京：東南大學，2015.

[9]王濤.移動辦公智能終端環境安全研究[D].南京：東南大學，2014.

[10] 溫圣召，基于Android平臺的軟件保護技術研究[D].北京： 北京郵電大學，2014.