“暗隱間諜”--利用NDK NativeActivity技術實現Android加固

標籤：android病毒   nativeactivity   加固   

近日，百度安全實驗室發現了一款被不同病毒家族利用的新型代碼加固方式，該種代碼加固方式巧妙的利用了Android系統提供的NativeActivity特性完成惡意代碼的解固。目前主流的加固方案代碼邏輯分為java層和native層兩部分。而該種加固方式實現了代碼的全部native化，java層未包含任何代碼邏輯。以下為傳統加固方案與新型加固方案的對比：
 

主流加固方案                                                                                                          新型加固方案

 
 
一、簡介
 
Google推出NDK（Native Development Kit）後，使用C/C++的很多開發人員開始使用這種更高效的方式來進行Android程式的開發。在Android 2.3中Google開始逐漸的放寬NDK功能，新增的NativeActivity類允許Android開發人員使用C/C++在NDK環境中處理 Activity的生命週期。具體NaviteActivity開發流程可查看：
http://api.apkbus.com/reference/android/app/NativeActivity.html
 
使用該開發模式的病毒，執行邏輯可分為兩個部分：
1、DEX載入器libdexloader.so：實現Payload DEX檔案的解密、動態載入。
2、Payload DEX：執行具體的惡意行為。Payload DEX存在於assets目錄下，其中DEX中的方法指令已被加密處理。
 
其中DEX載入器利用Android NativeActivity開發模式開發。系統提供的NativeActivity作為libdexloader.so的java端進入點觸發libdexloader.so的邏輯。libdexloader.so執行流程為：
1、 載入Payload DEX檔案到記憶體。
2、 解析Payload DEX檔案，解密DEX檔案中的方法指令。
3、 記憶體載入解密後的Payload Dex資料。載入這些DEX資料，能夠做到檔案系統無解密DEX檔案存在（註：記憶體載入僅適合android4.0-android4.4版本,相關技術可參考:http://blog.csdn.net/androidsecurity/article/details/9674251）。
4、 調用惡意代碼。

 

 
二、惡意案例程式碼分析
 
使用該類開發模式加固的惡意樣本家族中，我們選取其中一類竊取使用者連絡人的家族進行分析，反編譯classes.dex可見，主要惡意行為的代碼並不在classes.dex中：
 

classes.dex的類結構，未包含任何有意義代碼

 

而實際運行，該病毒的邏輯如所示：

 
 

1、入口

該程式在AndroidManifest.xml檔案中註冊”android.app.NativeActivity”，並配置meta-data的name與value的值，從而載入ELF可執行檔作為入口：

 

ELF檔案載入後，即會執行入口函數android_main，該函數會啟動DexService和DexLoader類中的方法進行dex檔案的解密和載入：

 

2、assets中的檔案類型為dex，但實際上，方法結構中的ushort insns部分已被加密，因此不能直接被載入。為MainActivity的exec_post方法被加密的方法指令：

被加密的方法指令

 

3、libdexloader.so運行後，將DEX檔案ushort insns部分解密，並重新合成一個正確的DEX檔案，然後載入至記憶體運行。為還原後的正確的DEX的方法指令：

還原後的方法指令

 

4、經過解密，我們得出完整JAVA層代碼：

 

分析可知該病毒主要行為是讀取連絡人資訊，然後將這些資訊發送到指定網址：

讀取連絡人和本機號碼

 

發送至遠端地址

 

“暗隱間諜”--利用NDK NativeActivity技術實現Android加固