一、前言
今天总算迎来了破解系列的最后一篇文章了,之前的两篇文章分别为:
第一篇:如何使用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键,跳转:
跳转到dvmDexFileOpenPartial函数处,下断点:
第五步:点击运行按钮或者F9运行程序
之前的jdb命令就连接上了:
IDA出现如下界面,不要理会,一路点击取消按钮即可
运行到了dvmDexFileOpenPartial函数处:
使用F8进行单步调试,但是这里需要注意的是,只要运行过了PUSH命令就可以了,记得不要越过下面的BL命令,因为我们没必要走到那里,当执行了PUSH命令之后,我们就是使用脚本来dump处内存中的dex数据了,这里有一个知识点,就是R0~R4寄存器一般是用来存放一个函数的参数值的,那么我们知道dvmDexFileOpenPartial函数的第一个参数就是dex内存起始地址,第二个参数就是dex大小:
那么这里就可以使用这样的脚本进行dump即可:
static main(void)
{
auto fp, dex_addr, end_addr;
fp = fopen(“F:\\dump.dex”, “wb”);
end_addr = r0 + r1;
for ( dex_addr = r0; dex_addr < end_addr; dex_addr ++ )
fputc(Byte(dex_addr), fp);
}
脚本不解释了,非常简单,而且这个是固定的格式,以后dump内存中的dex都是这段代码,我们将dump出来的dex保存到F盘中。
然后这时候,我们使用:Shirt+F2 调出IDA的脚本运行界面:
点击运行,这里可能需要等一会,运行成功之后,我们去F盘得到dump.dex文件,其实这里我们的IDA使命就完成了,因为我们得到了内存的dex文件了,下面开始就简单了,只要分析dex文件即可
四、分析正确的dex文件内容
我们拿到dump.dex之后,使用dex2jar工具进行反编译:
可惜的是,报错了,反编译失败,主要是有一个类导致的,开始我以为是dump出来的dex文件有问题,最后我用baksmali工具得到smali文件是可以的,所以不是dump出来的问题,我最后用baksmali工具将dex转化成smali源码:
java -jar baksmali-2.0.3.jar -o C:\classout/ dump.dex
得到的smali源码目录classout在C盘中:
我们得到了指定的smali源码了。
那么下面我们就可以使用静态方式分析smali即可了:
首先找到入口的MainActivity源码:
这里不解释了,肯定是找按钮的点击事件代码处,这里是一个btn_listener变量,看这个变量的定义:
是MainActivity$1内部类定义,查看这个类的smali源码,直接查看他的onClick方法:
这里可以看到,把EditText中的内容,用Intent传递给WebViewActivity中,但是这里的intent数据的key是加密的。
下面继续看WebViewActivity这个类:
我们直接查找onCreate方法即可,看到这里是初始化WebView,然后进行一些设置,这里我们看到一个@JavascriptInterface
这个注解,我们在使用WebView的时候都知道,他是用于Js中能够访问的设置了这个注解的方法,没有这个注解的方法Js是访问不了的
注意:
我们知道这个注解是在SDK17加上的,也就是Android4.2版本中,那么在之前的版本中没有这个注解,任何public的方法都可以在JS代码中访问,而Java对象继承关系会导致很多public的方法都可以在JS中访问,其中一个重要的方法就是 getClass()。然后JS可以通过反射来访问其他一些内容。那么这里就有这个问题了:比如下面的一段JS代码:
看到了,这段js代码很危险的,使用getClass方法,得到这个对象(java中的每个对象都有这个方法的),用这个方法可以得到一个java对象,然后我们就可以调用这个对象中的方法了。这个也算是WebView的一个漏洞了。
所以通过引入 @JavascriptInterface注解,则在JS中只能访问 @JavascriptInterface注解的函数。这样就可以增强安全性。
回归到正题,我们上面分析了smali源码,看到了WebView的一些设置信息,我们可以继续往下面看:
这里的我们看到了一些重要的方法,一个是addJavascriptInterface,一个是loadUrl方法。
我们知道addjavaascriptInterface方法一般的用法:
mWebView.addJavascriptInterface(new JavaScriptObject(this), "jiangwei");
第一个参数是本地的Java对象,第二个参数是给Js中使用的对象的名称。然后js得到这个对象的名称就可以调用本地的Java对象中的方法了。
看了这里的addjavaascriptInterface方法代码,可以看到,这里用
ListViewAutoScrollHelpern;->decrypt_native(Ljava/lang/String;I)Ljava/lang/String;
将js中的名称进行混淆加密了,这个也是为了防止恶意的网站来拦截url,然后调用我们本地的Java中的方法。
注意:
这里又存在一个关于WebView的安全问题,就是这里的js访问的对象的名称问题,比如现在我的程序中有一个Js交互的类,类中有一个获取设备重要信息的方法,比如这里获取设备的imei方法,如果我们的程序没有做这样名称的混淆的话,破解者得到这个js名称和方法名,然后就伪造一个恶意url,来调用我们程序中的这个方法,比如这样一个例子:
然后在设置js名称:
我们就可以伪造一个恶意的url页面来访问这个方法,比如这个恶意的页面代码如下:
运行程序:
看到了,这里恶意的页面就成功的调用了程序中的一个重要方法。
所以,我们可以看到,对Js交互中的对象名称做混淆是必要的,特别是本地一些重要的方法。
回归到正题,我们分析完了WebView的一些初始化和设置代码,而且我们知道如果要被Js访问的方法,那么必须要有@JavascriptInterface注解 因为在Java中注解也是一个类,所以我们去注解类的源码看看那个被Js调用的方法:
这里看到了有一个showToast方法,展示的内容:\u7965\u9f99\uff01 ,我们在线转化一下:
擦,这里就是题目要求展示的内容。
好了,到这里我们就分析完了apk的逻辑了,下面我们来整理一下:
1、在MainActivity中输入一个页面的url,跳转到WebViewActivity进行展示
2、WebViewActivity有Js交互,需要调用本地Java对象中的showToast方法展示消息
问题:
因为这里的js对象名称进行了加密,所以这里我们自己编写一个网页,但是不知道这个js对象名称,无法完成showToast方法的调用
五、破解的方法
下面我们就来分析一下如何解决上面的问题,其实解决这个问题,我们现有的方法太多了
第一种方法:修改smali源码,把上面的那个js对象名称改成我们自己想要的,比如:jiangwei,然后在自己编写的页面中直接调用:jiangwei.showToast方法即可,不过这里需要修改smali源码,在使用smali工具回编译成dex文件,在弄到apk中,在运行。方法是可行的,但是感觉太复杂,这里不采用
第二种方法:利用Android4.2中的WebView的漏洞,直接使用如下Js代码即可
这里根本不需要任何js对象的名称,只需要方法名就可以完成调用,所以这里可以看到这个漏洞还是很危险的。
第三种方法:我们看到了那个加密方法,我们自己写一个程序,来调用这个方法,尽然得到正确的js对象名称,这里我们就采用这种方式,因为这个方式有一个新的技能,所以这里我就讲解一下了。
那么如果用第三种方法的话,就需要再去分析那个加密方法逻辑了:
android.support.v4.widget.ListViewAutoScrollHelpern在这个类中,我们再去查找这个smali源码:
这个类加载了libtranslate.so库,而且加密方法是native层的,那么我们用IDA查看libtranslate.so库:
我们搜一下Java开头的函数,发现并没有和decrypt_native方法对应的native函数,说明这里做了native方法的注册混淆,我们直接看JNI_OnLoad函数:
这里果然是自己注册了native函数,但是分析到这里,我就不往下分析了,为什么呢?因为我们其实没必要搞清楚native层的函数功能,我们知道了Java层的native方法定义,那么我们可以自己定义一个这么个native方法来调用libtranslate.so中的加密函数功能:
我们新建一个Demo工程,仿造一个ListViewAutoScrollHelpern类,内部在定义一个native方法:
然后我们在MainActivity中加载libtranslate.so:
然后调用那个native方法,打印结果:
这里的方法的参数可以查看smali源码中的那个方法参数:
点击运行,发现有崩溃的,我们查看log信息:
是libtranslate.so中有一个PagerTitleStripIcsn类找不到,这个类应该也有一个native方法,我们在构造这个类:
再次运行,还是报错,原因差不多,还需要在构造一个类:TaskStackBuilderJellybeann
好了,再次点击运行:
OK了,成功了,从这个log信息可以看出来了,解密之后的js对象名称是:SmokeyBear,那么下面就简单了,我们在构造一个url页面,直接调用:SmokeyBear.showToast即可。
注意:
这里我们看到,如果知道了Java层的native方法的定义,那么我们就可以调用这个native方法来获取native层的函数功能了,这个还是很不安全的,但是我们如何防止自己的so被别人调用呢?之前的一篇文章:Android中的安全攻防之战 已经说过了,可以在so中的native函数做一个应用的签名校验,只有属于自己的签名应用才能调用,否则直接退出。
六,开始测试
上面已经知道了js的对象名称,下面我们就来构造这个页面了:
那么这里又有一个问题了,这个页面构造好了?放哪呢?有的同学说我有服务器,放到服务器上,然后输入url地址就可以了,的确这个方法是可以的,但是有的同学没有服务器怎么办呢?这个也是有方法的,我们知道WebView的loadUrl方法是可以加载本地的页面的,所以我们可以把这个页面保存到本地,但是需要注意的是,这里不能存到SD卡中,因为这个应用没有读取SD的权限,我们可以查看他的AndroidManifest.xml文件:
我们在不重新打包的情况下,是没办法做到的,那么放哪呢?其实很简单了,放在这个应用的/data/data/com.ali.tg.testapp/目录下即可,因为除了SD卡位置,这个位置是最好的了,那么我们知道WebView的loadUrl方法在加载本地的页面的格式是:
file:///data/data/com.ali.tg.testapp/crack.html
那么我们直接输入即可
注意:
这里在说一个小技巧:就是我们在一个文本框中输入这么多内容,是不是有点蛋疼,我们其实可以借助于命令来实现输入的,就是使用:adb shell input text ”我们需要输入的内容“。
具体用法很简单,打开我们需要输入内容的EditText,点击调出系统的输入法界面,然后执行上面的命令即可:
不过这里有一个小问题,就是他不识别分号:
不过我们直接修改成分号点击进入:
运行成功,看到了toast的展示。
手痒的同学可以戳这里:http://download.csdn.net/detail/jiangwei0910410003/9543445
七、内容整理
到这里我们就破解成功了,下面来看看整理一下我们的破解步骤:
1、破解的常规套路
我们按照破解惯例,首先解压出classses.dex文件,使用dex2jar工具查看java代码,但是发现只有一个Application类,所以猜测apk被加壳了,然后用apktool来反编译apk,得到他的资源文件和AndroidManifest.xml内容,找到了包名和入口的Activity类。
2、加固apk的源程序一般存放的位置
知道是加固apk了,那么我们就分析,这个加固的apk肯定是存放在本地的一个地方,一般是三个地方:
1》应用的asset目录中
2》应用的libs中的so文件中
3》应用的dex文件的末尾
我们分析了一下之后,发现asset目录中的确有两个jar文件,但是打不开,猜测是被经过处理了,所以我们得分析处理逻辑,但是这时候我们也没有代码,怎么分析呢?所以这时候就需要借助于dump内存dex技术了:
不管最后的源apk放在哪里,最后都是需要经历解密动态加载到内存中的,所以分析底层加载dex源码,知道有一个函数:dvmDexFileOpenPartial 这个函数有两个重要参数,一个是dex的其实地址,一个是dex的大小,而且知道这个函数是在libdvm.so中的。所以我们可以使用IDA进行动态调试获取信息
3、双开IDA开始获取内存中的dex内容
双开IDA,走之前的动态破解so方式来给dvmDexFileOpenPartial函数下断点,获取两个参数的值,然后使用一段脚本,将内存中的dex数据保存到本地磁盘中。
4、分析获取到的dex内容
得到了内存中的dex之后,我们在使用dex2jar工具去查看源码,但是发现保存,以为是dump出来的dex格式有问题,但是最后使用baksmali工具进行处理,得到smali源码是可以的,然后我们就开始分析smali源码。
5、分析源码了解破解思路
通过分析源码得知在WebViewActivity页面中会加载一个页面,然后那个页面中的js会调用本地的Java对象中的一个方法来展示toast信息,但是这里我们遇到了个问题:Js的Java对象名称被混淆加密了,所以这时候我们需要去分析那个加密函数,但是这个加密函数是native的,然后我们就是用IDA去静态分析了这个native函数,但是没有分析完成,因为我们不需要,其实很简单,我们只需要结果,不需要过程,现在解密的内容我们知道了,native方法的定义也知道了,那么我们就去写一个简单的demo去调用这个so的native方法即可,结果成功了,我们得到了正确的Js对象名称。
6、了解WebView的安全性
WebView的早期版本的一个漏洞信息,在Android4.2之前的版本WebView有一个漏洞,就是可以执行Java对象中所有的public方法,那么在js中就可以这么处理了,先获取geClass方法获取这个对象,然后在调用这个对象中的一些特定方法即可,因为Java中所有的对象都有一个getClass方法,而这个方法是public的,同时能够返回当前对象。所以在Android4.2之后有了一个注解:
@JavascriptInterface ,只有这个注解标识的方法才能被Js中调用。
7、获取输入的新技能
验证结果的过程中我们发现了一个技巧,就是我们在输入很长的文本的时候,比较繁琐,可以借助adb shell input text命令来实现。
八、技术点概要
1、通过dump出内存中的dex数据,可以佛挡杀佛了,不管apk如何加固,最终都是需要加载到内存中的。
2、了解到了WebView的安全性的相关知识,比如我们在WebView中js对象名称做一次混淆还是有必要的,防止被恶意网站调用我们的本地隐私方法。
3、可以尝试调用so中的native方法,在知道了这个方法的定义之后
4、adb shell input text 命令来辅助我们的输入
九、总结
这里就介绍了Android中如何dump出那些加固的apk程序,其实核心就一个:不管上层怎么加固,最终加载到内存的dex肯定不是加固的,所以这个dex就是我们想要的,这里使用了IDA来动态调试libdvm.so中的dvmDexFileOpenPartial函数来获取内存中的dex内容,同时还可以使用gdb+gdbserver来获取,这个感兴趣的同学自行搜索吧。结合了之前的两篇文章,就算善始善终,介绍了Android中大体的破解方式,当然这三种方式不是万能的,因为加固和破解是相生相克的,没有哪个有绝对的优势,只是两者相互进步罢了,当然还有很多其他的破解方式,后面如果遇到的话,会在详细说明,我们的目的不是编写应用,而且让别人的应用变成炮灰!!