CopperDroid: Automatic Reconstruction of Android Malware Behaviors 閱讀筆記

問題：Android app的特性決定了我們很難依靠傳統的基於systemcall的動態分析系統。比如：Android系統通過Binder進行進程內（IPC）和進程間（RPC）通信。僅僅依靠systemcall無法還原這些高級語義。

解決：設計了CopperDroid，基於虛擬機的動態系統。CopperDroid通過直接監測System call，不但可以判斷操作系統的一些動作（比如進程創建、文件創建），還可以判斷進程內部的動作（比如短信發送，這種行為和Android的對象有關），最終產生詳細的、並且有意義的，有語義的行為信息。

意義：再現了復雜的Android對象，豐富了重建OS和Android的具體行為的語義。此外，還展示了如何對系統調用（包括自動跟蹤，並行IPC與RPC合作）進行剖析。

主要貢獻：

1)Automatic IPC Unmarshalling 自動IPC解組

2) Value-based Data Flow Analysis 基於數據流的值的分析

3) Behavioral Reconstruction (Combine system call and Binder) 結合系統調用和Binder的行為重現

1、 背景

1)每個應用程序都有獨立的沙箱，應用程序之間可以通過api進行交互。

2)Binder：android系統依靠binder作為優化的inter-process communications和remoteprocedure call機制。發送的數據叫做Parcel，binderkernel driver通過ioctl system call調度消息。當一個service需要提供binder，必須定義client-service接口。如果這個service被其他app使用，或者涉及多線程，則接口需要由Android InterfaceDefinition Language (AIDL)定義。

3)Android Interface Definition Language (AIDL)

? Android系統中的進程之間不能共享內存，因此，需要提供一些機制在不同進程之間進行數據通信。為了使其他的應用程序也可以訪問本應用程序提供的服務，Android系統采用了遠程過程調用（Remote Procedure Call，RPC）方式來實現。Android使用一種接口定義語言（Interface Definition Language，IDL）來公開服務的接口。

? AIDL規定哪個服務(which)會被以怎樣(how)的方式遠程調用

? 描述方法參數如何排列

? 對AIDL剖析器(parser)修改使其可以理解排列的Binders(marshalled Binders)

2、 CopperDroid概述

 

CopperDroid系統架構如圖，將沒有修改過的系統鏡像運行在一個特別修改定制的Android模擬器中。模擬器會將APP在系統中運行時的system call 記錄並傳遞給分析模塊進行分析，並最終輸出APP的惡意行為。在這裡，APP的惡意行為主要分為兩種：系統相關的行為（OS-specific events）和Android相關的行為（Android-specific events）。針對系統相關行為, CopperDroid采用value-based數據流分析來重構行為。而針對Android相關的行為，CopperDroid重點分析Binder相關的行為。

? 只需對 QEMU進行小修改即可運行CopperDroid plugin

? 不需要對Android image修改

? 可移植性強，運行負載低

 

1)Tracking system call invocations 跟蹤系統請求調用

 

? instruments QEMU'semulation of theswiinstruction：ARM 提供了swi (SoftWare Interrupt)指令來調用system calls。我們安裝了QEMU來攔截，當swi指令執行的時候。並且使用CopperDroid攔截CPU級別的轉換。

? instruments QEMUto intercept everycpsr_write(Kernel→User):當cpsr寄存器從supervisor換成user模式時（cpsr_write），可以檢索系統調用的返回值。

 

2)Behavior reconstruction 行為重現

右上：解組的數據庫，左上：CopperDroid模擬器，下：即時分析重現惡意程序的行為

? 所有的行為都通過system call實現

? App的行為都可以由system call與其參數描述，其中還包括了從Binder解組數據中提取的高級別語義。

? Serialized parameter values followingthe token are stored and sent to the Oracle for post-processing (Figure 2leftmost RSP line and leftmost TCP line).

 

 

3、 Automatic IPC Unmarshalling

? Unmarshalling Oracle(解組數據庫)是一個java應用程序，運行在vanilla安卓模擬器上。Oracle可以接收每個Binder方法的簽名和實參，然後返回方法的自定義表示和所有參數值。

? 解析AIDL文件（使用改進的AIDL解析器）自動生成每個方法每個接口的簽名。這些簽名具有某一版本的Android系統的特征，可以用於協助解組過程（unmarshalling process）。

? 這些簽名發送到unmarshallingOracle，運行在同樣版本的但不同一個的安卓系統的CopperDroid模擬器上。隨著AIDL簽名，從ioctl提取的數據也發送給Oracle，通過自動解包的binder數據來判斷方法參數的值。

? 發短信的例子：

 

所有的binder事件（包括發短信）都涉及ioctl system call。比如：當短信發送時，一個ioctl定位短信服務，另一個ioctl請求sendTextMessage方法。第二個會被解組，發送到數據庫。

 

1)AIDL Parser（interface parser）：AIDL文件定義了一個給定的接口的方法，參數和返回值的類型。Android平台包括AIDL Parser，給定一個AIDL文件，會產生Stub和Proxy類。

?Stub (client)：method calls

?Proxy (server)：perform actions

CopperDroid包含修改過的AIDL parser以獲取：方法名、參數、返回值，構建代碼和方法之間的映射。

 

2)Oracle Input 數據庫輸入

?Binder method signature

?Marshalled parcel blob

 

3)Oracle Inner Workings and Output 數據庫的工作原理與輸出

? 算法：

UnmarshallingOracle的工作細節:用不同的辦法判斷解組Binder通信對象：數據類型是primitive還是basic；是Androidclass object還是Binder reference object。

? 輸出：

? Custom representation of themethod ）（方法自定義表示）

?All parameter values

 

4)Recursive Printing遞歸輸出：只留下本質細節，過濾掉不相關的flags和empty files

4、觀察結果

1、 觀察結果

 

、 觀察結果

1、 觀察結果

Hierarchical map of behaviors 行為層次圖

圖中有六大類的行為，每類行為包括一種或多種行為模型（behavioralmodels），行為模型是通過一組actions定義。Actions被CopperDroid 跟蹤，可以屬於任意級別的抽象。(e.g. OS- andAndroid-specific behaviors)

1)App Stimulation

? 傳統的可執行程序一般只有一個入口，但是android程序可以有多個。

? 當副 activities被系統或者其他app觸發、執行，可能就再不通過main，從而錯過一些行為。——這個問題一直影響著傳統的動態分析方法。

? 為了解決動態代碼覆蓋問題，CopperDroid通過人為的刺激來分析惡意軟件。注入的事件如打電話、接收短信等。

? CopperDroid檢查apk的manifest提取events和permission有關信息來驅動對惡意軟件的刺激。

 

主要刺激及其參數

2)Value-based Data Flow Analysis

? CopperDroid執行基於值的數據流分析，建立相關系統調用的數據依賴圖和定義使用鏈。

? 通過觀測系統調用設置構建數據依賴關系圖，並進行了切片，我們可以創建文件系統相關的事件和實際所需要的資源。我們的分析保留刪除的文件和具有相同文件名的資源的多個版本。

5、 評估

? 每個鏡像都包括了個人信息，比如聯系人、短信、呼叫日志和圖片，盡可能地模擬真實的手機。

? 每個被分析的惡意軟件都被安裝在鏡像中，通過CopperDroid跟蹤直到時間耗盡（默認10分鐘）

? 為了防止干擾條件，每個sample都被執行分析6次：三次沒有刺激，三次有刺激。

1)可用性

 

三個數據集對於刺激的響應情況如表2所示

 

每行標識一類行為，以及有多少樣本在總數裡表現出至少一個這樣的行為。可以觀察到的，最受影響的行為類是訪問個人信息，其次是Make/Alter呼叫。

2)性能

運行環境：GNU/Linux Debian64-bit system，Intel 3.30GHz core (i5) and 3GB of RAM

兩組對照實驗：

? Binder Macrobenchmark：測試CopperDroid對於普通安卓特有行為的開銷（比如讀取聯系人和發送短信）

三個不同設置:

? without CopperDroid——baseline

? on a CopperDroid監控測試應用程序——CD (targeted))

? on a CopperDroid跟蹤全系統事件——(CD (full)).

 

? System Call Microbenchmark：CopperDroid需要分析系統調用的一個子集並計算時間要求。

第二組實驗中測量CopperDroid檢查一個子系統調用需要的平均時間。本實驗收集了150000多個系統調用，通過運行應用程序，並使他們服從任意的工作負載。跟蹤系統調用需要攔截進入和退出執行點。平均時間是0.091ms和0.092ms。

 

Conclusion

?CopperDroid可以通過分析APP執行過程中的系統調用，來重構出APP的惡意行為。由於CopperDroid是通過分析底層的system call來發現惡意行為，因此可以有效的抵抗上層的代碼混淆，native code等防護措施，同時，系統屬於動態分析系統，因此還能夠抵抗代碼的動態加載。CopperDroid不需要對系統源碼進行修改，因此部署方便且適應性強。