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

一、序言

 

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

       通過對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的反調試。
三、總結
       通過以上分析，梆梆加固的確可以有效防止移動應用在運營推廣過程中被破解、盜版、二次打包、注入、反編譯等破壞，不過如果Android惡意軟件也通過這種方式加固保護，這將會給移動安全分析人員帶來巨大的挑戰，因為安全分析人員經常使用的代碼靜態邏輯分析和動態調試分析在該情況下都失效了。
       梆梆官方聲稱不會對惡意軟件進行加固，的確在加固的過程中發現存在安全軟件掃描信息和雲測試處理流程，不過這些措施只能減少而不能徹底杜絕惡意軟件通過梆梆加固保護。如何不被惡意軟件利用是梆梆需要解決的問題。