Andorid APK反逆向解決方案---梆梆加固原理探尋

一、序言

 

       目前Android市場充斥著大量的盜版軟體，開發人員的官方應用被“打包黨”們惡意篡改。如何使程式碼免受盜版篡改就成了開發人員面臨的頭等大事，今天我們將分析一個不錯的解決方案---梆梆加固（http://www.secneo.com/appProtect/）。

       通過對App進行加固保護。梆梆可以有效防止行動裝置 App在運營推廣過程中被破解、盜版、二次打包、注入、反編譯等破壞，保障程式的安全性、穩定性，對行動裝置 App的整體邏輯結構進行保護，保證了行動裝置 App的使用者體驗。

 

二、梆梆加固逆向分析過程

 

      首先我們通過對APK加固前後檔案結構的比較，來瞭解梆梆加固對APK檔案所做的處理。為了使分析過程足夠簡單，我建立一個最簡單的測試程式，並上傳到梆梆加固，整個加固過程大概需要4天的時間才可以完成，這是一個漫長的等待過程。

      該測試程式包含了Activity、Service、ContentProvider、BroadcastRecevier四大組件、Application、普通類、Jni調用等7類對象，目的就是全面的瞭解梆梆的加固效果。

 

      1、apk加固前後靜態檔案結構及動態運行時對比分析

 

           （1） 加固前後靜態檔案結構變化（左為加固前，右為加固後）

 

 

            

           

 

            加固後apk新增以下檔案：

                  assets\meta-data\manifest.mf  //APK檔案清單SHA1-Digest

                  assets\meta-data\rsa.pub        //RSA公開金鑰資訊

                  assets\meta-data\rsa.sig         //數位簽章檔案

                  assets\classes.jar                    //已加密原classes.dex檔案

                  assets\com.example.hellojni    //ARM平台二進位可執行檔

                  assets\com.example.hellojni.x86  //x86功能同上

                  libs\armeabi\libsecexe.so        //ARM平台共用庫檔案

                  libs\x86\libsecexe.so               //x86功能同上

            加固後修改檔案：

                 AndroidMainfest.xml  //（如果應用配置有Application資訊，則該檔案加固前後相同，如果應用未配置Application資訊，則該檔案加固前後不                                                   //相同，梆梆會配置Application資訊為自己實作類別）

                 classes.dex

 

            對classes.dex進行反編譯，觀察代碼樹結構變化：（左為加固前，右為加固後）

 

                                                     
                                                                     

         （2）加固前後動態運行時變化

 

                 運行原程式，系統僅建立一個相關進程，但是加固的程式，系統會為其同時建立三個相關程式進程：

                 進程啟動順序：597進程建立605進程，605進程又建立了607進程

 

 

 

 

                

                通過查看maps檔案擷取597進程對應檔資訊

 

          

                  通過map檔案可以看出，597進程為主進程，android各組件在該進程中運行。

                  605和607進程並無與apk檔案相關檔案資訊，通過cmdline查看啟動參數：

 

 

 

 

 

 

                  初步懷疑該進程為assets\com.example.hellojni 可執行檔運行結果。

 

     2、梆梆加固保護效果分析

 

          我們通過逆向分析加固後的app，來看看梆梆加固對app的保護效果。

          程式碼的第一執行點是Application對象，首先查看TestApplication類對象。

          

           

             程式的Util類完成大部分的java層邏輯，

 

 

 

  

    ACall類主要完成對libsecexe.so JNI的調用：

 

 

   

       

    查看libsecexe.so檔案匯出函數，發現所有函數名都經過加密處理，與我們平時jni調用產生的函數名並不同。平時jni產生的函數名應該為這樣格式Java_com_secapk_wrapper_ACall_{函數名}

 

            

             

              

     抗靜態分析：

         Util類通過MyClassLoader完成對加密classes.jar的動態載入，記憶體中解密classes.jar，完成動態載入。

         jni方法對應so函數名的混淆。

     抗動態調試：

         當使用IDA動態調試該程式時，程式無法建立串連調試。

 

    梆梆加固可以有效常用的逆向分析方法。

 

三、梆梆加固技術實現關鍵點猜想

   

     （1）如何使DexClassLoader動態載入組件具有生命週期？

            根據APK檔案是否在AndroidManifest.xml配置Applicaiton資訊，梆梆加固會做不同的處理：

            通過上傳Applicaiton不同配置的APK檔案，我們發現：

                  當APK配置有Applicaition資訊時，梆梆加固重寫Application類

                  當APK未配置Application資訊時，梆梆加固建立類，並在AndroidManifest.xml中配置自己Application類

 
 

            因此Applicaiton就是程式的第一執行點。

            我們知道DexClassLoader載入的類是沒有組件生命週期的，也就是說即使DexClassLoader通過對dex的動態載入完成了對組件類的載入，              當系統啟動該組件時，還會出現載入類失敗的異常。我已經在“Android APK加殼技術方案”

            （http://blog.csdn.net/jiazhijun/article/details/8809542）中提出了一種使DexClassLoader載入組件類具有生命週期的方法。

           運行加固後的程式並通過Mat記憶體分析工具查看類載入情況：

 

           

      

                  如所示，組件類的載入類已經被修改為com.secapk.wrapper.MyClassLoader類，可以得出結論，該方式和我提出方式基本相同，通過             修改系統組件類ClassLoader來實現。

 

          （2）如何混淆native方法在so庫函數對應關係？

                   jni方法註冊方式有兩種，

                          1、通過javah產生函數頭，該種方式產生的方法具有固定的格式。該方式使逆向分析人員比較容易擷取java層native方法對應的本地方                                法。

                          2、在JNI_OnLoad方法中手動註冊jni方法，不易尋找對應關係。

                    使用第二種方式可以實現混淆java層native方法和so函數的對應關係。

                   

[cpp] #include <string.h>  
#include <jni.h>  
 
JNIEXPORT jstring JNICALL abcdefghijklmn( JNIEnv* env,jobject thiz ) 
{ 
    return (*env)->NewStringUTF(env, "Hello from JNI !"); 
} 
 
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved) 
{ 
    JNIEnv* env = NULL; 
    jint result = -1; 
 
    if ((*vm)->GetEnv(vm, (void**) &env, JNI_VERSION_1_4) != JNI_OK) { 
        return JNI_ERR; 
    } 
    JNINativeMethod gMethods[] = { 
        { "stringFromJNI", "()Ljava/lang/String;", (void*)abcdefghijklmn }, 
    }; 
    jclass clazz = (*env)->FindClass(env, "com/example/hellojni/HelloJni"); 
     
    if (clazz == NULL) { 
        return JNI_ERR; 
    } 
    if ((*env)->RegisterNatives(env, clazz, gMethods, sizeof(gMethods) / sizeof(gMethods[0])) < 0){ 
        return JNI_ERR; 
    } 
    /* success -- return valid version number */ 
    result = JNI_VERSION_1_4; 
    return result; 
} 

#include <string.h>
#include <jni.h>

JNIEXPORT jstring JNICALL abcdefghijklmn( JNIEnv* env,jobject thiz )
{
    return (*env)->NewStringUTF(env, "Hello from JNI !");
}

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)
{
 JNIEnv* env = NULL;
 jint result = -1;

 if ((*vm)->GetEnv(vm, (void**) &env, JNI_VERSION_1_4) != JNI_OK) {
  return JNI_ERR;
 }
    JNINativeMethod gMethods[] = {
     { "stringFromJNI", "()Ljava/lang/String;", (void*)abcdefghijklmn },
    };
 jclass clazz = (*env)->FindClass(env, "com/example/hellojni/HelloJni");
 
 if (clazz == NULL) {
  return JNI_ERR;
 }
 if ((*env)->RegisterNatives(env, clazz, gMethods, sizeof(gMethods) / sizeof(gMethods[0])) < 0){
  return JNI_ERR;
 }
 /* success -- return valid version number */
 result = JNI_VERSION_1_4;
 return result;
}              以上代碼中的字串都是明文（比如“stringFromJNI”），如果這些文明字串都換成密文的話，再通過運行時解密，相應的對應關係更不易看出。

          （3）如何使DexClassLoader載入加密的dex檔案？

                   雖然不瞭解梆梆加固是怎麼做的，不過通過分析它的運行邏輯，我推測了一種可行的實現方案：瞭解該方案需要對Android                                        DexClassLoader的整個載入流程需要有清晰的瞭解。

                    首先推斷assets\classes.jar是一個加密的jar包。

                    正常的DexClassLoader載入的流程如下：會有一個DexOpt產生odex過程

                   

                   但是梆梆加固後的應用DexClassLoader載入過程並沒有該過程的log資訊。

                   推斷加密的jar包裡面含有odex檔案，如果不是odex檔案的話，DexClassLoader肯定會在運行時釋放未加密的odex檔案到目錄，這樣的話                  被保護的邏輯也就泄露了。

                   DexClassLoader載入過程會在java層和C層產生不同的資料結構，java層並沒有實質性的資料，所有的資料都在c層，我們可用通過底層代                碼完成dex資料的解析。底層dex分析是可以支援byte[]數組的，解密odex資料，傳遞過去就行了。這樣java層就可以調用了。

                   以下是大概虛擬碼實現步驟：

                   int loadDex(char * dexFileName)
{
    char *dvm_lib_path = "/system/lib/libdvm.so";
void * handle;
DvmGlobals gDvm;
    handle = dlopen( dvm_lib_path, int mode);

1、讀取dexFileName檔案內容並解密到byte數組。
2、調用dexFileParse函數解析byte數組為DexFile
\dalvik\libdex\DexFile.c
DexFile* dexFileParse(const u1* data, size_t length, int flags)//dlsym(handle, "dexFileParse");

3、調用allocateAuxStructures轉換DexFile為DvmDex，（由於該方法為static方法，因此需要按照其邏輯自行實現）
\dalvik\vm\DvmDex.c
static DvmDex* allocateAuxStructures(DexFile* pDexFile)

4、添加DvmDex到gDvm.userDexFiles
\dalvik\vm\Init.c
struct DvmGlobals gDvm; //gDvm = dlsym(handle, "gDvm");

5、修改MyDexClassLoader中的mDexs對象的mCookie值，mCookie主要用於映射底層DvmDex資料
DexClassLoader.mDexs[0].mCookie值

}

          （4）so如何?程式的反調試？
                    同linux反調試基本原理相同，這裡提供一種方式就是在JNI_Onload中調用ptrace方法，ptrace被廣泛用於調試（比如IDA）和進程代碼注入（比如LBE,金山等許可權管理功能實現），一個進程只能被一個進程ptrace，如果你自己調用ptarce，這樣其它程式就無法通過ptrace調試或者 向您程式進程注入代碼。
                        ptrace(PTRACE_TRACEME,0 ,0 ,0);
                    通過本人實驗，該種方式可以實現so的反調試。
三、總結
       通過以上分析，梆梆加固的確可以有效防止行動裝置 App在運營推廣過程中被破解、盜版、二次打包、注入、反編譯等破壞，不過如果Android惡意軟體也通過這種方式加固保護，這將會給Mobile Security分析人員帶來巨大的挑戰，因為安全分析人員經常使用的代碼靜態邏輯分析和動態調試分析在該情況下都失效了。
       梆梆官方聲稱不會對惡意軟體進行加固，的確在加固的過程中發現存在安全軟體掃描資訊和雲測試處理流程，不過這些措施只能減少而不能徹底杜絕惡意軟體通過梆梆加固保護。如何不被惡意軟體利用是梆梆需要解決的問題。