管理书籍排行榜,神武八荒一颗小说,欢乐颂第一季

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

AndoridAPK反逆向解決方案：梆梆加固原理探尋

一、序言

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

公司主營業(yè)務(wù)：成都做網(wǎng)站、網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出崇左免費(fèi)做網(wǎng)站回饋大家。

通過對App進(jìn)行加固保護(hù)。梆梆可以有效防止移動應(yīng)用在運(yùn)營推廣過程中被破解、盜版、二次打包、注入、反編譯等破壞，保障程序的安全性、穩(wěn)定性，對移動應(yīng)用的整體邏輯結(jié)構(gòu)進(jìn)行保護(hù)，保證了移動應(yīng)用的用戶體驗(yàn)。

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

首先我們通過對APK加固前后文件結(jié)構(gòu)的比較，來了解梆梆加固對APK文件所做的處理。為了使分析過程足夠簡單，我新建一個最簡單的測試程序，并上傳到梆梆加固，整個加固過程大概需要4天的時間才可以完成，這是一個漫長的等待過程。

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

1、apk加固前后靜態(tài)文件結(jié)構(gòu)及動態(tài)運(yùn)行時對比分析

（1）加固前后靜態(tài)文件結(jié)構(gòu)變化（左為加固前，右為加固后）

加固后apk新增以下文件：

                  assets\meta-data\manifest.mf  //APK文件列表SHA1-Digest
                  assets\meta-data\rsa.pub        //RSA公鑰信息
                  assets\meta-data\rsa.sig         //數(shù)字簽名文件
                  assets\classes.jar                    //已加密原classes.dex文件
                  assets\com.example.hellojni    //ARM平臺二進(jìn)制可執(zhí)行文件
                  assets\com.example.hellojni.x86  //x86功能同上
                  libs\armeabi\libsecexe.so        //ARM平臺共享庫文件
                  libs\x86\libsecexe.so               //x86功能同上

加固后修改文件：

                 AndroidMainfest.xml  //（如果應(yīng)用配置有Application信息，則該文件加固前后相同，如果應(yīng)用未配置Application信息，則該文件加固前后不相同，梆梆會配置Application信息為自己實(shí)現(xiàn)類）
                 classes.dex

對classes.dex進(jìn)行反編譯，觀察代碼樹結(jié)構(gòu)變化：（左為加固前，右為加固后）

（2）加固前后動態(tài)運(yùn)行時變化

運(yùn)行原程序，系統(tǒng)僅創(chuàng)建一個相關(guān)進(jìn)程，但是加固的程序，系統(tǒng)會為其同時創(chuàng)建三個相關(guān)程序進(jìn)程：

進(jìn)程啟動順序：597進(jìn)程創(chuàng)建605進(jìn)程，605進(jìn)程又創(chuàng)建了607進(jìn)程

通過查看maps文件獲取597進(jìn)程映射文件信息

通過map文件可以看出，597進(jìn)程為主進(jìn)程，android各組件在該進(jìn)程中運(yùn)行。

605和607進(jìn)程并無與apk文件相關(guān)文件信息，通過cmdline查看啟動參數(shù)：

初步懷疑該進(jìn)程為assets\com.example.hellojni 可執(zhí)行文件運(yùn)行結(jié)果。

2、梆梆加固保護(hù)效果分析

我們通過逆向分析加固后的app，來看看梆梆加固對app的保護(hù)效果。

程序代碼的第一執(zhí)行點(diǎn)是Application對象，首先查看TestApplication類對象。

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

ACall類主要完成對libsecexe.so JNI的調(diào)用：

查看libsecexe.so文件導(dǎo)出函數(shù)，發(fā)現(xiàn)所有函數(shù)名都經(jīng)過加密處理，與我們平時jni調(diào)用產(chǎn)生的函數(shù)名并不同。平時jni產(chǎn)生的函數(shù)名應(yīng)該為這樣格式Java_com_secapk_wrapper_ACall_{函數(shù)名}

抗靜態(tài)分析：

Util類通過MyClassLoader完成對加密classes.jar的動態(tài)加載，內(nèi)存中解密classes.jar，完成動態(tài)加載。

jni方法對應(yīng)so函數(shù)名的混淆。

抗動態(tài)調(diào)試：

當(dāng)使用IDA動態(tài)調(diào)試該程序時，程序無法建立連接調(diào)試。

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

#p#

三、梆梆加固技術(shù)實(shí)現(xiàn)關(guān)鍵點(diǎn)猜想

（1）如何使DexClassLoader動態(tài)加載組件具有生命周期？

根據(jù)APK文件是否在AndroidManifest.xml配置Applicaiton信息，梆梆加固會做不同的處理：

通過上傳Applicaiton不同配置的APK文件，我們發(fā)現(xiàn)：

當(dāng)APK配置有Applicaition信息時，梆梆加固重寫Application類

當(dāng)APK未配置Application信息時，梆梆加固新建類，并在AndroidManifest.xml中配置自己Application類

因此Applicaiton就是程序的第一執(zhí)行點(diǎn)。

我們知道DexClassLoader加載的類是沒有組件生命周期的，也就是說即使DexClassLoader通過對dex的動態(tài)加載完成了對組件類的加載，當(dāng)系統(tǒng)啟動該組件時，還會出現(xiàn)加載類失敗的異常。我已經(jīng)在“Android APK加殼技術(shù)方案”中提出了一種使DexClassLoader加載組件類具有生命周期的方法。

運(yùn)行加固后的程序并通過Mat內(nèi)存分析工具查看類加載情況：

如上圖所示，組件類的加載類已經(jīng)被修改為com.secapk.wrapper.MyClassLoader類，可以得出結(jié)論，該方式和我提出方式基本相同，通過修改系統(tǒng)組件類ClassLoader來實(shí)現(xiàn)。

（2）如何混淆native方法在so庫函數(shù)對應(yīng)關(guān)系？

jni方法注冊方式有兩種：

1、通過javah產(chǎn)生函數(shù)頭，該種方式產(chǎn)生的方法具有固定的格式。該方式使逆向分析人員比較容易獲取java層native方法對應(yīng)的本地方法。

2、在JNI_OnLoad方法中手動注冊jni方法，不易查找對應(yīng)關(guān)系。

使用第二種方式可以實(shí)現(xiàn)混淆java層native方法和so函數(shù)的對應(yīng)關(guān)系。

 
 
 
 
  
  
  
  #include   
  
  
  
  #include   
  
  
  
    
  
  
  
  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”），如果這些文明字符串都換成密文的話，再通過運(yùn)行時解密，相應(yīng)的對應(yīng)關(guān)系更不易看出。

（3）如何使DexClassLoader加載加密的dex文件？

雖然不了解梆梆加固是怎么做的，不過通過分析它的運(yùn)行邏輯，我推測了一種可行的實(shí)現(xiàn)方案：了解該方案需要對 Android DexClassLoader的整個加載流程需要有清晰的了解。

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

正常的DexClassLoader加載的流程如下：會有一個DexOpt產(chǎn)生odex過程

但是梆梆加固后的應(yīng)用DexClassLoader加載過程并沒有該過程的log信息。

推斷加密的jar包里面含有odex文件，如果不是odex文件的話，DexClassLoader肯定會在運(yùn)行時釋放未加密的odex文件到目錄，這樣的話被保護(hù)的邏輯也就泄露了。

DexClassLoader加載過程會在java層和C層產(chǎn)生不同的數(shù)據(jù)結(jié)構(gòu)，java層并沒有實(shí)質(zhì)性的數(shù)據(jù)，所有的數(shù)據(jù)都在c層，我們可用通過底層代碼完成dex數(shù)據(jù)的解析。底層dex分析是可以支持byte[]數(shù)組的，解密 odex數(shù)據(jù)，傳遞過去就行了。這樣java層就可以調(diào)用了。

以下是大概偽代碼實(shí)現(xiàn)步驟：

 
 
 
 
  
  
  
  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文件內(nèi)容并解密到byte數(shù)組。

2、調(diào)用dexFileParse函數(shù)解析byte數(shù)組為DexFile

\dalvik\libdex\DexFile.c

DexFile* dexFileParse(const u1* data, size_t length, int flags)//dlsym(handle, "dexFileParse");

3、調(diào)用allocateAuxStructures轉(zhuǎn)換DexFile為DvmDex，（由于該方法為static方法，因此需要按照其邏輯自行實(shí)現(xiàn)）

\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數(shù)據(jù)DexClassLoader.mDexs[0].mCookie值

（4）so如何實(shí)現(xiàn)程序的反調(diào)試？

同linux反調(diào)試基本原理相同，這里提供一種方式就是在JNI_Onload中調(diào)用ptrace方法，ptrace被廣泛用于調(diào)試（比如IDA）和進(jìn)程代碼注入（比如LBE,金山等權(quán)限管理功能實(shí)現(xiàn)），一個進(jìn)程只能被一個進(jìn)程ptrace，如果你自己調(diào)用ptarce，這樣其它程序就無法通過ptrace調(diào)試或者向您程序進(jìn)程注入代碼。

ptrace(PTRACE_TRACEME,0 ,0 ,0);

通過本人實(shí)驗(yàn)，該種方式可以實(shí)現(xiàn)so的反調(diào)試。

三、總結(jié)

通過以上分析，梆梆加固的確可以有效防止移動應(yīng)用在運(yùn)營推廣過程中被破解、盜版、二次打包、注入、反編譯等破壞，不過如果Android惡意軟件也通過這種方式加固保護(hù)，這將會給移動安全分析人員帶來巨大的挑戰(zhàn)，因?yàn)榘踩治鋈藛T經(jīng)常使用的代碼靜態(tài)邏輯分析和動態(tài)調(diào)試分析在該情況下都失效了。

梆梆官方聲稱不會對惡意軟件進(jìn)行加固，的確在加固的過程中發(fā)現(xiàn)存在安全軟件掃描信息和云測試處理流程，不過這些措施只能減少而不能徹底杜絕惡意軟件通過梆梆加固保護(hù)。如何不被惡意軟件利用是梆梆需要解決的問題。

網(wǎng)頁名稱：AndoridAPK反逆向解決方案：梆梆加固原理探尋
本文來源：http://fisionsoft.com.cn/article/djhpchj.html

新聞中心

一、序言

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

三、梆梆加固技術(shù)實(shí)現(xiàn)關(guān)鍵點(diǎn)猜想

三、總結(jié)

其他資訊

一、序言

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

三、梆梆加固技術(shù)實(shí)現(xiàn)關(guān)鍵點(diǎn)猜想