分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow
也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!
一、前言
今天总算迎来了破解系列的最后一篇文章了,之前的两篇文章分别为:
第二篇:如何使用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键,跳转:
跳转到dvmDexFileOpenPartial函数处,下断点:
第五步:点击运行按钮或者F9运行程序
之前的jdb命令就连接上了:
IDA出现如下界面,不要理会,一路点击取消按钮即可