Android逆向之旅---动态方式破解apk终极篇 加固apk破解方式

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

               

一、前言

今天总算迎来了破解系列的最后一篇文章了，之前的两篇文章分别为：

第一篇：如何使用Eclipse动态调试smali源码 

第二篇：如何使用IDA动态调试SO文件

现在要说的就是最后一篇了，如何应对Android中一些加固apk安全防护，在之前的两篇破解文章中，我们可以看到一个是针对于Java层的破解，一个是针对于native层的破解，还没有涉及到apk的加固，那么今天就要来介绍一下如何应对现在市场中一些加固的apk的破解之道，现在市场中加固apk的方式一般就是两种：一种是对源apk整体做一个加固，放到指定位置，运行的时候在解密动态加载，还有一种是对so进行加固，在so加载内存的时候进行解密释放。我们今天主要看第一种加固方式，就是对apk整体进行加固。

二、案例分析

按照国际惯例，咋们还是得用一个案例来分析讲解，这次依然采用的是阿里的CTF比赛的第三题：

题目是：要求输入一个网页的url，然后会跳转到这个页面，但是必须要求弹出指定内容的Toast提示，这个内容是：祥龙！

了解到题目，我们就来简单分析一下，这里大致的逻辑应该是，输入的url会传递给一个WebView控件，进行展示网页，如果按照题目的逻辑的话，应该是网页中的Js会调用本地的一个Java方法，然后弹出相应的提示，那么这里我们就来开始操作了。

按照我们之前的破解步骤：

第一步：肯定是先用解压软件搞出来他的classes.dex文件，然后使用dex2jar+jd-gui进行查看java代码

擦，这里我们看到这里只有一个Application类，从这里我们可以看到，这个apk可能被加固了，为什么这么说呢？因为我们知道一个apk加固，外面肯定得套一个壳，这个壳必须是自定义的Application类，因为他需要做一些初始化操作，那么一般现在加固的apk的壳的Application类都喜欢叫StubApplication。而且，这里我们可以看到，除了一个Application类，没有其他任何类了，包括我们的如可Activity类都没有了，那么这时候会发现，很蛋疼，无处下手了。

第二步：我们会使用apktool工具进行apk的反编译，得到apk的AndroidManifest.xml和资源内容

反编译之后，看到程序会有一个入口的Activity就是MainActivity类，我们记住一点就是，不管最后的apk如何加固，即使我们看不到代码中的四大组件的定义，但是肯定会在AndroidManifest.xml中声明的，因为如果不声明的话，运行是会报错的。那么这里我们也分析完了该分析的内容，还是没发现我们的入口Activity类，而且我们知道他肯定是放在本地的一个地方，因为需要解密动态加载，所以不可能是放在网上的，肯定是本地，所以这里就有一些技巧了：

当我们发现apk中主要的类都没有了，肯定是apk被加固了，加固的源程序肯定是在本地，一般会有这么几个地方需要注意的：

1、应用程序的asset目录，我们知道这个目录是不参与apk的资源编译过程的，所以很多加固的应用喜欢把加密之后的源apk放到这里

2、把源apk加密放到壳的dex文件的尾部，这个肯定不是我们这里的案例，但是也有这样的加固方式，这种加固方式会发现使用dex2jar工具解析dex是失败的，我们这时候就知道了，肯定对dex做了手脚

3、把源apk加密放到so文件中，这个就比较难了，一般都是把源apk进行拆分，存到so文件中，分析难度会加大的。

一般都是这三个地方，其实我们知道记住一点：就是不管源apk被拆分，被加密了，被放到哪了，只要是在本地，我们都有办法得到他的。

好了，按照这上面的三个思路我们来分析一下，这个apk中加固的源apk放在哪了？

通过刚刚的dex文件分析，发现第二种方式肯定不可能了，那么会放在asset目录中吗？我们查看asset目录：

看到asset目录中的确有两个jar文件，而且我们第一反应是使用jd-gui来查看jar，可惜的是打开失败，所以猜想这个jar是经过处理了，应该是加密，所以这里很有可能是存放源apk的地方。但是我们上面也说了还有第三种方式，我们去看看libs目录中的so文件：

擦，这里有三个so文件，而我们上面的Application中加载的只有一个so文件：libmobisec.so，那么其他的两个so文件很有可能是拆分的apk文件的藏身之处。

通过上面的分析之后，我们大致知道了两个地方很有可能是源apk的藏身地方，一个是asset目录，一个是libs目录，那么分析完了之后，我们发现现在面临两个问题：

第一个问题：asset目录中的jar文件被处理了，打不开，也不知道处理逻辑

第二个问题：libs目录中的三个so文件，唯一加载了libmobisec.so文件了

那么这里现在的唯一入口就是这个libmobisec.so文件了，因为上层的代码没有，没法分析，下面来看一下so文件：

擦，发现蛋疼的是，这里没有特殊的方法，比如Java_开头的什么，所以猜测这里应该是自己注册了native方法，混淆了native方法名称，那么到这里，我们会发现我们遇到的问题用现阶段的技术是没法解决了。

三、获取正确的dex内容

分析完上面的破解流程之后，发现现在首要的任务是先得到源apk程序，通过分析知道，处理的源apk程序很难找到和分析，所以这里就要引出今天说的内容了，使用动态调试，给libdvm.so中的函数：dvmDexFileOpenPartial 下断点，然后得到dex文件在内存中的起始地址和大小，然后dump处dex数据即可。

那么这里就有几个问题了：

第一个问题：为何要给dvmDexFileOpenPartial 这个函数下断点？

因为我们知道，不管之前的源程序如何加固，放到哪了，最终都是需要被加载到内存中，然后运行的，而且是没有加密的内容，那么我们只要找到这的dex的内存位置，把这部分数据搞出来就可以了，管他之前是如何加固的，我们并不关心。那么问题就变成了，如何获取加载到内存中的dex的地址和大小，这个就要用到这个函数了：dvmDexFileOpenPartial 因为这个函数是最终分析dex文件，加载到内存中的函数：

int dvmDexFileOpenPartial(const void* addr, int len, DvmDex** ppDvmDex);

第一个参数就是dex内存起始地址，第二个参数就是dex大小。

第二个问题：如何使用IDA给这个函数下断点

我们在之前的一篇文章中说到了，在动态调试so，下断点的时候，必须知道一个函数在内存中的绝对地址，而函数的绝对地址是：这个函数在so文件中的相对地址+so文件映射到内存中的基地址，这里我们知道这个函数肯定是存在libdvm.so文件中的，因为一般涉及到dvm有关的函数功能都是存在这个so文件中的，那么我们可以从这个so文件中找到这个函数的相对地址，运行程序之后，在找到libdvm.so的基地址，相加即可，那么我们如何获取到这个libdvm.so文件呢？这个文件是存放在设备的/system/lib目录下的：

那么我们只需要使用adb pull 把这个so文件搞出来就可以了。

好了，解决了这两个问题，下面就开始操作了：

第一步：运行设备中的android_server命令，使用adb forward进行端口转发

这里的android_server工具可以去ida安装目录中dbgsrv文件夹中找到

第二步：使用命令以debug模式启动apk

adb shell am start -D -n com.ali.tg.testapp/.MainActivity

因为我们需要给libdvm.so下断点，这个库是系统库，所以加载时间很早，所以我们需要像之前给JNI_OnLoad函数下断点一样，采用debugger模式运行程序，这里我们通过上面的AndroidManifest.xml中，得到应用的包名和入口Activity：

而且这里的android:debuggable=true，可以进行debug调试的。

第三步：双开IDA，一个用于静态分析libdvm.so，一个用于动态调试libdvm.so

通过IDA的Debugger菜单，进行进程附加操作：

第四步：使用jdb命令启动连接attach调试器

jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700

但是这里可能会出现这样的错误：

这个是因为，我们的8700端口没有指定，这时候我们可以通过Eclipse的DDMS进行端口的查看：

看到了，这里是8600端口，但是基本端口8700不在，所以这里我们有两种处理方式，一种是把上面的命令的端口改成8600，还有一种是选中这个应用，使其具有8700端口：

点击这个条目即可，这时候我们在运行上面的jdb命令：

处于等待状态。

第四步：给dvmDexFileOpenPartial函数下断点

使用一个IDA静态分析得到这个函数的相对地址：43308

在动态调试的IDA解密，使用Ctrl+S键找到libdvm.so的在内存中的基地址：41579000

然后将两者相加得到绝对地址：43308+41579000=415BC308，使用G键&#x