來源

本文要實(shí)驗(yàn)的方案同樣來源于CSDN大牛Jack_Jia的一篇翻譯博文：
Android4.0內(nèi)存Dex數(shù)據(jù)動(dòng)態(tài)加載技術(shù)

原文的地址是 http://2013.hackitoergosum.org/presentations/Day1-05.Nifty%20stuff%20that%20you%20can%20still%20do%20with%20Android%20by%20Xavier%20Martin.pdf
著重參考了看雪論壇的兩篇帖子：

【求助】Dex內(nèi)存加載的Native實(shí)現(xiàn)過程中出現(xiàn)的問題

【原創(chuàng)】DEX文件內(nèi)存加載實(shí)現(xiàn)中的數(shù)據(jù)構(gòu)造（C部分）

方案

從上一篇，基礎(chǔ)加殼的思路最后得出的結(jié)果是方案還不夠完善。因?yàn)槭褂玫南到y(tǒng)DexClassLoader提供的接口必須要求源程序保存在文件系統(tǒng)中，對(duì)手一旦過了萊茵河馬其諾防線就沒啥意義了。所以在前一篇的基礎(chǔ)上，又有上面來源方案中的思路，即通過jni調(diào)用底層接口，在內(nèi)存中加載dex文件。步驟如下：

獲取Dalvik_dalvik_system_DexFile_openDexFile_bytearray方法指針；

調(diào)用Dalvik_dalvik_system_DexFile_openDexFile_bytearray方法解析Dex數(shù)據(jù)；

實(shí)現(xiàn)JAVA層Dex ClassLoader完成類的加載；

方案本身是譯文，而且沒有介紹細(xì)節(jié)上的實(shí)現(xiàn)。不能像上一篇那樣直接copy代碼，那就只能老老實(shí)實(shí)的先搞清楚原理。通過短短的幾百字譯文，可以總結(jié)出一下幾點(diǎn)：
該方案只是針對(duì)實(shí)現(xiàn)內(nèi)存加載dex文件，對(duì)于加殼來說這只是其中的一部分、最重要的一部分；
方案的技術(shù)點(diǎn)在于通過dlopen、dlsym方法，拿到系統(tǒng)動(dòng)態(tài)庫(kù)libdvm.so中的內(nèi)存加載dex文件的方法，該方法位于源碼 ：dalvik/vm/native/ dalvik_system_DexFile.cpp 類中，名稱是：Dalvik_dalvik_system_DexFile_openDexFile_bytearray；并且只在4.0以上版本開放；
底層加載dex文件后，會(huì)得到一個(gè)int型的cookie值，java層的自定義DexClassLoader需要根據(jù)該值能夠拿到已加載好的dex內(nèi)容才能把整個(gè)流程拼接起來；

實(shí)現(xiàn)

雖然從方案分析上看，這個(gè)加載實(shí)現(xiàn)是有系統(tǒng)版本局限性的，不過通過dlsym方法拿到系統(tǒng)動(dòng)態(tài)庫(kù)函數(shù)指針然后來使用的思路對(duì)一個(gè)中間層認(rèn)識(shí)有限的土錘來說還從來沒嘗試過，并且，通用的方法應(yīng)該也離不開這種模式，所以完全有理由去實(shí)現(xiàn)它，作為一個(gè)中間過程。
所有嘗試都是基于上一篇的基礎(chǔ)班加殼的實(shí)現(xiàn)上，不要忘記我們的最終目的是實(shí)現(xiàn)APK加殼，內(nèi)存加載dex文件只是其中的一部分。

殼工程的迭代

本地代碼

Jni關(guān)鍵代碼基本都在譯文博客中了，我們要做的是讓它通過編譯、得到so庫(kù)。本地代碼當(dāng)然要有與之對(duì)應(yīng)的java代碼去加載才能用，通過上面對(duì)因?yàn)榈目偨Y(jié)，可以先這樣定義本地方法：

static native int loadDex(byte[] dex,long dexlen);

生成好對(duì)應(yīng)的.h、.c文件之后把譯文中給出的核心代碼填上，下面才是難題，許多類型都是unknown的，ndk編譯器會(huì)告訴你它不認(rèn)識(shí)這些亂七八糟的玩意兒。接下來就是挨個(gè)補(bǔ)充定義了。
看著u4、u1這些從java程序猿眼中怪怪的類型我不禁長(zhǎng)出一口氣——幸虧當(dāng)年是C出身的。溯本清源，在源碼 /dalvik/vm/Common.h 類中找到了這群貨的宏定義，于是照葫蘆畫瓢，在jni目錄里弄了一個(gè)偽造版的Common.h，搜刮了一下所有需要定義的類型之后，這個(gè)文件基本上是這個(gè)樣子的：

#ifndef DALVIK_COMMON_H_ #define DALVIK_COMMON_H_#include <stdbool.h> #include <stdint.h> #include <stdio.h> #include <assert.h>static union { char c[4]; unsigned long mylong; }endian_test = {{ 'l', '?', '?', 'b' } }; #define ENDIANNESS ((char)endian_test.mylong)//#if ENDIANNESS == "l" #define HAVE_LITTLE_ENDIAN //#else //#define HAVE_BIG_ENDIAN //#endif#if defined(HAVE_ENDIAN_H) # include <endian.h> #else /*not HAVE_ENDIAN_H*/ # define __BIG_ENDIAN 4321 # define __LITTLE_ENDIAN 1234 # if defined(HAVE_LITTLE_ENDIAN) # define __BYTE_ORDER __LITTLE_ENDIAN # else # define __BYTE_ORDER __BIG_ENDIAN # endif #endif /*not HAVE_ENDIAN_H*/#if !defined(NDEBUG) && defined(WITH_DALVIK_ASSERT) # undef assert # define assert(x) \ ((x) ? ((void)0) : (ALOGE("ASSERT FAILED (%s:%d): %s", \ __FILE__, __LINE__, #x), *(int*)39=39, (void)0) ) #endif#define MIN(x,y) (((x) < (y)) ? (x) : (y)) #define MAX(x,y) (((x) > (y)) ? (x) : (y))#define LIKELY(exp) (__builtin_expect((exp) != 0, true)) #define UNLIKELY(exp) (__builtin_expect((exp) != 0, false))#define ALIGN_UP(x, n) (((size_t)(x) + (n) - 1) & ~((n) - 1)) #define ALIGN_DOWN(x, n) ((size_t)(x) & -(n)) #define ALIGN_UP_TO_PAGE_SIZE(p) ALIGN_UP(p, SYSTEM_PAGE_SIZE) #define ALIGN_DOWN_TO_PAGE_SIZE(p) ALIGN_DOWN(p, SYSTEM_PAGE_SIZE)#define CLZ(x) __builtin_clz(x)/** If "very verbose" logging is enabled, make it equivalent to ALOGV.* Otherwise, make it disappear.** Define this above the #include "Dalvik.h" to enable for only a* single file.*/ /* #define VERY_VERBOSE_LOG */ #if defined(VERY_VERBOSE_LOG) # define LOGVV ALOGV # define IF_LOGVV() IF_ALOGV() #else # define LOGVV(...) ((void)0) # define IF_LOGVV() if (false) #endif/** These match the definitions in the VM specification.*/ typedef uint8_t u1; typedef uint16_tu2; typedef uint32_tu4; typedef uint64_tu8; typedef int8_t s1; typedef int16_t s2; typedef int32_t s4; typedef int64_t s8;/** Storage for primitive types and object references.** Some parts of the code (notably object field access) assume that values* are "left aligned", i.e. given "JValue jv", "jv.i" and "*((s4*)&jv)"* yield the same result. This seems to be guaranteed by gcc on big- and* little-endian systems.*/#define OFFSETOF_MEMBER(t, f) \(reinterpret_cast<char*>( \&reinterpret_cast<t*>(16)->f) - \reinterpret_cast<char*>(16))#define NELEM(x) ((int) (sizeof(x) / sizeof((x)[0])))union JValue { #if defined(HAVE_LITTLE_ENDIAN)u1 z;s1 b;u2 c;s2 s;s4 i;s8 j;float f;double d;void* l; #endif #if defined(HAVE_BIG_ENDIAN)struct {u1_z[3];u1z;};struct {s1_b[3];s1b;};struct {u2_c;u2c;};struct {s2_s;s2s;};s4 i;s8 j;float f;double d;void* l; #endif };/** Array objects have these additional fields.** We don't currently store the size of each element. Usually it's implied* by the instruction. If necessary, the width can be derived from* the first char of obj->clazz->descriptor.*/ typedef struct {void*clazz;u4 lock;u4 length;u1* contents; }ArrayObject ;#endif // DALVIK_COMMON_H_

這里面還有個(gè)大小端的問題，不過為求實(shí)驗(yàn)先通過就先定義死，過了再說。
還有個(gè)值得一提的結(jié)構(gòu)就是最后面的ArrayObject，這玩意定義在源碼的/dalvik/vm/oo/Object.h 中，原本的定義是這樣的：

struct Object {ClassObject*clazz;u4 lock; };struct ArrayObject : Object {u4 length;u8 contents[1]; };

如果還實(shí)實(shí)在在的去弄一個(gè)ClassObject，那就是java中毒已深的表現(xiàn)，根據(jù)看雪里面的相關(guān)討論（就是文首提到的兩篇），直接如上定義了。得到最后的C代碼如下：

#include "com_android_dexunshell_NativeTool.h" #include <stdlib.h> #include <dlfcn.h> #include <stdio.h>JNINativeMethod *dvm_dalvik_system_DexFile; void (*openDexFile)(const u4* args,union JValue* pResult);int lookup(JNINativeMethod *table, const char *name, const char *sig,void (**fnPtrout)(u4 const *, union JValue *)) {int i = 0;while (table[i].name != NULL) {LOGI("lookup %d %s" ,i,table[i].name);if ((strcmp(name, table[i].name) == 0)&& (strcmp(sig, table[i].signature) == 0)) {*fnPtrout = table[i].fnPtr;return 1;}i++;}return 0; }/* This function will be call when the library first be load.* You can do some init in the libray. return which version jni it support.*/ JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {void *ldvm = (void*) dlopen("libdvm.so", RTLD_LAZY);dvm_dalvik_system_DexFile = (JNINativeMethod*) dlsym(ldvm,"dvm_dalvik_system_DexFile");if(0 == lookup(dvm_dalvik_system_DexFile, "openDexFile", "([B)I",&openDexFile)){openDexFile = NULL;LOGE("method does not found ");}else{LOGI("method found ! HAVE_BIG_ENDIAN");}LOGI("ENDIANNESS is %c" ,ENDIANNESS );void *venv;LOGI("dufresne----->JNI_OnLoad!");if ((*vm)->GetEnv(vm, (void**) &venv, JNI_VERSION_1_4) != JNI_OK) {LOGE("dufresne--->ERROR: GetEnv failed");return -1;}return JNI_VERSION_1_4; }JNIEXPORT jint JNICALL Java_com_android_dexunshell_NativeTool_loadDex(JNIEnv * env, jclass jv, jbyteArray dexArray, jlong dexLen) {// header+dex contentu1 * olddata = (u1*)(*env)-> GetByteArrayElements(env,dexArray, NULL);char* arr;arr=(char*)malloc(16+dexLen);ArrayObject *ao=(ArrayObject*)arr;ao->length=dexLen;memcpy(arr+16,olddata,dexLen);u4 args[] = { (u4) ao };union JValue pResult;jint result;LOGI("call openDexFile 33..." );if(openDexFile != NULL){openDexFile(args,&pResult);}else{result = -1;}result = (jint) pResult.l;LOGI("Java_com_android_dexunshell_NativeTool_loadDex %d" , result);return result; }

ArrayObject之后的數(shù)據(jù)拷貝是從看雪上抄來的，剛開始不求甚解，后來看了源碼中的調(diào)用方法就慢慢明白了：

static void Dalvik_dalvik_system_DexFile_openDexFile_bytearray(const u4* args, JValue* pResult) {ArrayObject* fileContentsObj = (ArrayObject*) args[0];u4 length;u1* pBytes;…length = fileContentsObj->length;pBytes = (u1*) malloc(length);…memcpy(pBytes, fileContentsObj->contents, length);… ｝

Java層

底層代碼基本了然，也就是說譯文提供的思路基本實(shí)現(xiàn)，剩下其他加殼的事兒還要自己動(dòng)腦筋補(bǔ)上。現(xiàn)在java層我們有一個(gè)可以使用的以byte數(shù)組為參數(shù)的加載dex的接口了：
static native int loadDex(byte[] dex,long dexlen);
要知道我們花這么大力氣實(shí)現(xiàn)的這個(gè)方法，實(shí)際意義在于讓源程序的dex數(shù)據(jù)在內(nèi)存中傳遞，而不是必須保存在某個(gè)地方、以文件的方式。也就是說，我們需要一個(gè)新的DexClassLoader，去替換在上一篇提到的基礎(chǔ)加殼方案中自定義Application—— ProxyApplication 類，通過反射設(shè)置到”android.app.LoadedApk”中mClassLoder屬性的那個(gè)系統(tǒng)DexClassLoader，即至少那一段應(yīng)該改成這樣：

DynamicDexClassLoder dLoader = new DynamicDexClassLoder(base,srcdata,libPath, (ClassLoader) RefInvoke.getFieldOjbect("android.app.LoadedApk", wr.get(), "mClassLoader"),getPackageResourcePath(),getDir(".dex", MODE_PRIVATE).getAbsolutePath() );RefInvoke.setFieldOjbect("android.app.LoadedApk", "mClassLoader",wr.get(), dLoader);

沒錯(cuò)，DynamicDexClassLoder 它的構(gòu)造參數(shù)中應(yīng)當(dāng)去接收源程序的dex數(shù)據(jù)，以byte數(shù)組的形式，這樣、相關(guān)把dex數(shù)組保存為文件那段代碼可以刪除，/data/data 中相關(guān)目錄就找不到緩存dex文件的身影了；

替換DexClassLoader，要知道相對(duì)于系統(tǒng)版本的加載器我們的少了什么，又多出了什么，在一一對(duì)接上，就沒問題了。少了什么呢？是dex文件路徑、多出了什么呢？是dex byte數(shù)組，考慮到已經(jīng)實(shí)現(xiàn)的jni庫(kù)，那就是多了一個(gè)加載好的dex文件對(duì)應(yīng)的cookie值。那么，這個(gè)
Cookie 是否能夠完成替換呢？這需要到源碼中找答案。
源碼路徑：libcore/dalvik/src/main/java/dalvik/system ，生成類圖，取出DexClassLoader相關(guān)的一部分：

走讀幾遍代碼基本就能了解，對(duì)于dex文件加載而言，DynamicDexClassLoder需要做的實(shí)際上只有一件事，復(fù)寫findClass方法，使APK運(yùn)行時(shí)能夠找到和加載源程序dex中的類，至于如何實(shí)現(xiàn)，從類圖上就可以看出，最后實(shí)際上追溯到DexFile類，可以利用到j(luò)ni加載到的cookie，通過反射DexFile中的方法，實(shí)現(xiàn)我們的預(yù)期，具體實(shí)現(xiàn)如下：

package com.android.dexunshell;import java.io.IOException; import java.net.URL; import java.util.Enumeration;import com.eebbk.mingming.k7utils.ReflectUtils;import android.content.Context; import android.util.Log; import android.view.LayoutInflater;import dalvik.system.DexClassLoader; import dalvik.system.DexFile;public class DynamicDexClassLoder extends DexClassLoader {private static final String TAG = DynamicDexClassLoder.class.getName();private int cookie;private Context mContext;/*** 原構(gòu)造** @param dexPath* @param optimizedDirectory* @param libraryPath* @param parent*/public DynamicDexClassLoder(String dexPath, String optimizedDirectory,String libraryPath, ClassLoader parent) {super(dexPath, optimizedDirectory, libraryPath, parent);}/*** 直接從內(nèi)存加載 新構(gòu)造** @param dexBytes* @param libraryPath* @param parent* @throws Exception*/public DynamicDexClassLoder(Context context, byte[] dexBytes,String libraryPath, ClassLoader parent, String oriPath,String fakePath) {super(oriPath, fakePath, libraryPath, parent);setContext(context);setCookie(NativeTool.loadDex(dexBytes, dexBytes.length));}private void setCookie(int kie) {cookie = kie;}private void setContext(Context context) {mContext = context;}private String[] getClassNameList(int cookie) {return (String[]) ReflectUtils.invokeStaticMethod(DexFile.class,"getClassNameList", new Class[] { int.class },new Object[] { cookie });}private Class defineClass(String name, ClassLoader loader, int cookie) {return (Class) ReflectUtils.invokeStaticMethod(DexFile.class,"defineClass", new Class[] { String.class, ClassLoader.class,int.class }, new Object[] { name, loader, cookie });}@Overrideprotected Class<?> findClass(String name) throws ClassNotFoundException {Log.d(TAG, "findClass-" + name);Class<?> cls = null;String as[] = getClassNameList(cookie);for (int z = 0; z < as.length; z++) {if (as[z].equals(name)) {cls = defineClass(as[z].replace('.', '/'),mContext.getClassLoader(), cookie);} else {defineClass(as[z].replace('.', '/'), mContext.getClassLoader(),cookie);}}if (null == cls) {cls = super.findClass(name);}return cls;}@Overrideprotected URL findResource(String name) {Log.d(TAG, "findResource-" + name);return super.findResource(name);}@Overrideprotected Enumeration<URL> findResources(String name) {Log.d(TAG, "findResources ssss-" + name);return super.findResources(name);}@Overrideprotected synchronized Package getPackage(String name) {Log.d(TAG, "getPackage-" + name);return super.getPackage(name);}@Overrideprotected Class<?> loadClass(String className, boolean resolve)throws ClassNotFoundException {Log.d(TAG, "loadClass-" + className + " resolve " + resolve);Class<?> clazz = super.loadClass(className, resolve);if (null == clazz) {Log.e(TAG, "loadClass fail,maybe get a null-point exception.");}return clazz;}@Overrideprotected Package[] getPackages() {Log.d(TAG, "getPackages sss-");return super.getPackages();}@Overrideprotected Package definePackage(String name, String specTitle,String specVersion, String specVendor, String implTitle,String implVersion, String implVendor, URL sealBase)throws IllegalArgumentException {Log.d(TAG, "definePackage" + name);return super.definePackage(name, specTitle, specVersion, specVendor,implTitle, implVersion, implVendor, sealBase);}

}

加密工具的跟進(jìn)

加密工具需要變化的是，加入殼程序dex的加密數(shù)據(jù)不再是整個(gè)源程序的APK，而是源程序中的dex文件。這一點(diǎn)修改加密代碼中的目標(biāo)文件、并修改操作腳本即可，無需多說。

小結(jié)

結(jié)合譯文方案，實(shí)現(xiàn)了內(nèi)存加載dex文件，并通過自定義DexClassLoader的方式，鞏固了之前的加殼方案，使源程序不在以文件的形式出現(xiàn)。殼的意義也在于此，至于防止內(nèi)存中獲取dex這種高級(jí)的破解方法，殼似乎略顯無力，所以先放到后面考慮。目前的問題是，內(nèi)存加載dex所依賴的底層方法，只在4.0以上幾個(gè)版本存在，5.0沒有查詢還是未知數(shù)，還沒能滿足通用性的要求，要需要進(jìn)一步尋找方案。

原文地址： http://taoyuanxiaoqi.com/2015/01/16/apkshell2/

總結(jié)

以上是生活随笔為你收集整理的APK加壳【2】内存加载dex实现详解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。