andorid apk反逆向解决方案

Andorid APK反逆向解决方案：梆梆加 固原理探寻 2013-06-27 09:33 Jack_Jia 看雪安全论坛 字号：T | T 梆梆是一个面向 Android开发者的应用保护解决方案，它可以有效的阻止 Android APK包 被逆向工程破解，从而保护开发者的利益，防治打包党。那么它到底是如何实现这一效果 的呢，梆梆的解决方案真的无懈可击吗？来看网友对其技术实现的分析。 AD： 2013云计算架构师峰会课程资料下载 一、序言 目前 Android市场充斥着大量的盗版软件，开发者的官方应用被“打包党”们恶意篡改。如何使程序代码 免受盗版篡改就成了开发者面临的头等大事，今天我们将分析一个不错的解决方案-梆梆加固 （/appProtect/）。 通过对 App进行加固保护。梆梆可以有效防止移动应用在运营推广过程中被破解、盗版、二次打包、注入、 反编译等破坏，保障程序的安全性、稳定性，对移动应用的整体逻辑结构进行保护，保证了移动应用的用 户体验。 二、梆梆加固逆向分析过程 首先我们通过对 APK加固前后文件结构的比较，来了解梆梆加固对 APK文件所做的处理。为了使分析过程 足够简单，我新建一个最简单的测试程序，并上传到梆梆加固，整个加固过程大概需要 4天的时间才可以 完成，这是一个漫长的等待过程。 该测试程序包含了 Activity、Service、ContentProvider、BroadcastRecevier 四大组件、 Application、普通类、Jni 调用等 7类对象，目的就是全面的了解梆梆的加固效果。 1、apk 加固前后静态文件结构及动态运行时对比分析 （1） 加固前后静态文件结构变化（左为加固前，右为加固后） 加固后 apk新增以下文件： assetsmeta-datamanifest.mf /APK文件列表 SHA1-Digest assetsmeta-datarsa.pub /RSA公钥信息 assetsmeta-datarsa.sig /数字签名文件 assetsclasses.jar /已加密原 classes.dex文件 assetscom.example.hellojni /ARM平台二进制可执行文件 assetscom.example.hellojni.x86 /x86功能同上 libsarmeabilibsecexe.so /ARM平台共享库文件 libsx86libsecexe.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查看启动参数： 初步怀疑该进程为 assetscom.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加壳技术方案”中提出了一种使 DexClassLoader加载组件类具有生命周期的方法。 运行加固后的程序并通过 Mat内存分析工具查看类加载情况： 如上图所示，组件类的加载类已经被修改为 com.secapk.wrapper.MyClassLoader类，可以得出结论，该 方式和我提出方式基本相同，通过修改系统组件类 ClassLoader来实现。 （2）如何混淆 native方法在 so库函数对应关系？ jni方法注册方式有两种： 1、通过 javah产生函数头，该种方式产生的方法具有固定的格式。该方式使逆向分析人员比较容易获取 java层 native方法对应的本地方法。 2、在 JNI_OnLoad方法中手动注册 jni方法，不易查找对应关系。 使用第二种方式可以实现混淆 java层 native方法和 so函数的对应关系。 1. #include 2. #include 3. 4. JNIEXPORT jstring JNICALL abcdefghijklmn( JNIEnv* env,jobject thiz ) 5. 6. return (*env)-NewStringUTF(env, “Hello from JNI !“); 7. 8. 9. JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved) 10. 11. JNIEnv* env = NULL; 12. jint result = -1; 13. 14. if (*vm)-GetEnv(vm, (void*) 16. 17. JNINativeMethod gMethods = 18. “stringFromJNI“, “()Ljava/lang/String;“, (void*)abcdefghijklmn , 19. ; 20. jclass clazz = (*env)-FindClass(env, “com/example/hellojni/HelloJni“); 21. 22. if (clazz = NULL) 23. return JNI_ERR; 24. 25. if (*env)-RegisterNatives(env, clazz, gMethods, sizeof(gMethods) / sizeof(gMethods0) 0) 26. return JNI_ERR; 27. 28. /* success - return valid version number */ 29. result = JNI_VERSION_1_4; 30. return result; 31. 以上代码中的字符串都是明文（比如“stringFromJNI”），如果这些文明字符串都换成密文的话，再通 过运行时解密，相应的对应关系更不易看出。 （3）如何使 DexClassLoader加载加密的 dex文件？ 虽然不了解梆梆加固是怎么做的，不过通过分析它的运行逻辑，我推测了一种可行的实现方案：了解该方 案需要对 Android DexClassLoader 的整个加载流程需要有清 晰的了解。 首先推断 assetsclasses.jar是一个加密的 jar包。 正常的 DexClassLoader加载的流程如下：会有一个 DexOpt产生 odex过程 但是梆梆加固后的应用 DexClassLoader加载过程并没有该过程的 log信息。 推断加密的 jar包里面含有 odex文件，如果不是 odex文件的话，DexClassLoader 肯定会在运行时释放 未加密的 odex文件到目录，这样的话被保护的逻辑也就泄露了。 DexClassLoader加载过程会在 java层和 C层产生不同的数据结构，java 层并没有实质性的数据， 所有 的数据都在 c层，我们可用通过底层代码完成 dex数据的解析。底层 dex分析是可以支持 byte数组的， 解密 odex 数据，传递过去就行了。这样 java层就可以调用了。 以下是大概伪代码实现步骤： 1. int loadDex(char * dexFileName) 2. 3. char *dvm_lib_path = “/system/lib/libdvm.so“; 4. void * handle; 5. DvmGlobals gDvm; 6. handle = dlopen( dvm_lib_path, int mode); 1、读取 dexFileName文件内容并解密到 byte数组。 2、调用 dexFileParse函数解析 byte数组为 DexFile dalviklibdexDexFile.c DexFile* dexFileParse(const u1* data, size_t length, int flags)/dlsym(handle, “dexFileParse“); 3、调用 allocateAuxStructures转换 DexFile为 DvmDex，（由于该方法为 static方法，因此需要按照 其逻辑自行实现） dalvikvmDvmDex.c static DvmDex* allocateAuxStructures(DexFile* pDexFile) 4、添加 DvmDex到 gDvm.userDexFiles dalvikvmInit.c struct DvmGlobals gDvm; /gDvm = dlsym(handle, “gDvm“); 5、修改 MyDexClassLoader中的 mDexs对象的 mCookie值，mCookie 主要用于映射底层 DvmDex数据 DexClassLoader.mDexs0.mCookie值 （4）so 如何实现程序的反调试？ 同 linux反调试基本原理相同，这里提供一种方式就是在 JNI_Onload中调用 ptrace方 法，ptrace 被广 泛用于调试（比如 IDA）和进程代码注入（比如 LBE,金山等权限管理功能实现），一个进程只能被一个进 程 ptrace，如果你自己 调用 ptarce，这样其它程序就无法通过 ptrace调试或者 向您程序进程注入代码。 ptrace(PTRACE_TRACEME,0 ,0 ,0); 通过本人实验，该种方式可以实现 so的反调试。 三、总结 通过以上分析，梆梆加固的确可以有效防止移动应用在运营推广过程中被破解、盗版、二次打包、注入、 反编译等破坏，不过如果 Android恶 意软件也通过这种方式加固